Date:	Wed, 11 Sep 2013 10:49:59 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	David Safford <safford@...ibm.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Leonidas Da Silva Barbosa <leosilva@...ux.vnet.ibm.com>,
	Ashley Lai <ashley@...leylai.com>,
	Rajiv Andrade <mail@...jiv.net>,
	Marcel Selhorst <tpmdd@...horst.net>,
	Sirrix AG <tpmdd@...rix.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jeff Garzik <jgarzik@...ox.com>, "Ted Ts'o" <tytso@....edu>,
	Kent Yoder <key@...ux.vnet.ibm.com>,
	David Safford <safford@...son.ibm.com>,
	Mimi Zohar <zohar@...ibm.com>,
	"Johnston, DJ" <dj.johnston@...el.com>
Subject: Re: TPMs and random numbers

On Wed, Sep 11, 2013 at 10:22 AM, David Safford <safford@...ibm.com> wrote:
>>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.

A TPM that has an excellent internal entropy source and is FIPS 140-2
compliant with no bugs whatsoever may still use Dual_EC_DRBG, which
looks increasingly likely to be actively malicious.

>
>>> 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.

I'd be *much* happier if my system read a few hundred random bytes
from the TPM at startup and fed those bytes into the kernel's entropy
pool.  This should IMO happen at startup as early as possible.

Ideally the kernel would then ban any subsequent attempts to read the
TPM's RNG directly to make it much harder to exploit any backdoors in
the RNG that may exist.  Barring that, using the added protection that
the kernel's RNG provides but seeding it with the TPM's RNG is
probably at least as safe, if not much safer, than using the kernel's
RNG without entropy from the TPM or using the TPM's without extra
mixing.

In any case, just because they TPM's private keys may or may not be
backdoored, the keys the wrap should be as safe as can be arranged.

--Andy

>
> dave
>



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

Powered by blists - more mailing lists