Message-ID: <1378920168.26698.64.camel@localhost>
Subject: Re: TPMs and random numbers
From: David Safford <safford@us.ibm.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
        Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>,
        Ashley Lai <ashley@ashleylai.com>, Rajiv Andrade <mail@srajiv.net>,
        Marcel Selhorst <tpmdd@selhorst.net>, Sirrix AG <tpmdd@sirrix.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Jeff Garzik <jgarzik@pobox.com>, "Ted Ts'o" <tytso@mit.edu>,
        Kent Yoder <key@linux.vnet.ibm.com>,
        David Safford <safford@watson.ibm.com>, Mimi Zohar <zohar@us.ibm.com>,
        "Johnston, DJ" <dj.johnston@intel.com>
Date: Wed, 11 Sep 2013 13:22:48 -0400
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2882
Lines: 61

>On 09/09/2013 02:11 PM, H. Peter Anvin wrote:
>> It recently came to my attention that there are no standards whatsoever
>> for random number generated by TPMs.  In fact, there *are* TPMs where
>> random numbers are generated by an encrypted nonvolatile counter (I do
>> not know which ones); this is apparently considered acceptable for the
>> uses of random numbers that TPMs produce.

The TPM specifications have extensive RNG requirements, and most 
major vendors do certify their RNG implementations to FIPS 140-2.
The current 1.2 spec has three pages of detailed RNG requirements. 
Even the earliest spec (1.1b from 2002) required FIPS 140-1 
compliant power-on self tests of the RNG, and since 2006 the specs 
have required full FIPS 140-2 RNG compliance for FIPS mode.

Back when TPMs were first added to Thinkpads, I did extensive 
testing of TPM RNG outputs, including start up entropy, and found
them to be an excellent source. There may well be bad TPMs out 
there (I've heard rumors too), but I haven't run into one.

>> There are two issues with this from a Linux point of view.  One, we
>> harvest supposed entropy from the TPM for /dev/*random use via
>> /dev/hwrng and rngd.  This was something I originally proposed because
>> on a lot of platforms it is the only available entropy source with any
>> significant bandwidth.  However, in light of the above it is
>> questionable at best, at least with entropy being credited.
>
>Presumably the "entropy" should be mixed in but not credited to the
>available entropy.
>
>> The other issue is that we use tpm_get_random() *directly* in
>> security/keys/trusted.c.
>
>I don't know whether this makes sense, but all but one call seem to be
>related to TPM transactions -- breaking the TPM's RNG won't have any
>effects beyond, say, breaking the TPM's SRK.
>
>The one that looks dangerous is the one just under case Opt_new: it's
>using tpm_get_random to create an encryption key *that's used by the
>kernel for software crypto*.  That's IMO bogus.
>
>--Andy

Conversely, other /dev/random sources can be slow to build entropy,
particularly in embedded systems (see
https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final228.pdf)

As author of trusted.c, I think that there are advantages and
disadvantages to the different random sources. Trusted keys
already depend on the quality of TPM private keys generated
from the TPM RNG, so trusting the same RNG for symmetric key
generation seems reasonable. Several embedded systems I have 
looked at are _really_ bad at gathering entropy, so the TPM, 
seems a reasonably safe and convenient default. 

dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/