linux-kernel - Re: TPMs and random numbers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrUMtrjHKkxdAEPmkkFG-ZWGZOf450cCP704Dv8mV6sxBA@mail.gmail.com>
Date:	Thu, 12 Sep 2013 16:38:19 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Jörn Engel <joern@...fs.org>
Cc:	David Safford <safford@...ibm.com>,
	"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 Thu, Sep 12, 2013 at 2:57 PM, Jörn Engel <joern@...fs.org> wrote:
> On Wed, 11 September 2013 14:47:04 -0400, David Safford wrote:
>>
>> But I also think that the existing (certified) TPMs are good enough
>> for direct use.
>
> That is equivalent to trusting the TPM chip not to be malicious.  It
> requires trusting the chip designer, trusting every single employee of
> the chip designer, as some of them may be plants from a random
> countries spook organization, trusting the fab where the chip was
> manufactured, trusting your local dealer not to replace one chip with
> another in a similar packaging, trusting third-party components the
> designers may have incorporated, trusting intermediate steps between
> designer and fab or fab and local dealer, trusting your own employees,
> etc.

I would argue that any TPM-using kernel code should go even further
than just not trusting its RNG.  We should be further wrapping the
TPM-generated keys so that even a complete leak of the SRK wouldn't
allow an adversary to unwrap the keys.

Of course, without blinded operations (which the TPM doesn't support),
we're always vulnerable to the TPM actively leaking private key bits,
but that seems less likely.

(I have a partial implementation of this called tpmkey -- some day I
hope to finish it.)

--Andy
--
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/