> -----Original Message----- > From: linux-crypto-owner@xxxxxxxxxxxxxxx <linux-crypto-owner@xxxxxxxxxxxxxxx> On Behalf Of > Jarkko Sakkinen > Sent: Wednesday, October 9, 2019 9:33 AM > To: Ken Goldman <kgold@xxxxxxxxxxxxx> > Cc: Safford, David (GE Global Research, US) <david.safford@xxxxxx>; Mimi Zohar > <zohar@xxxxxxxxxxxxx>; linux-integrity@xxxxxxxxxxxxxxx; stable@xxxxxxxxxxxxxxx; open > list:ASYMMETRIC KEYS <keyrings@xxxxxxxxxxxxxxx>; open list:CRYPTO API <linux- > crypto@xxxxxxxxxxxxxxx>; open list <linux-kernel@xxxxxxxxxxxxxxx> > Subject: Re: [PATCH] KEYS: asym_tpm: Switch to get_random_bytes() > > On Wed, Oct 09, 2019 at 02:53:39AM +0300, Jarkko Sakkinen wrote: > > On Wed, Oct 09, 2019 at 02:49:35AM +0300, Jarkko Sakkinen wrote: > > > On Mon, Oct 07, 2019 at 06:13:01PM -0400, Ken Goldman wrote: > > > > The TPM library specification states that the TPM must comply with NIST > > > > SP800-90 A. > > > > > > > > https://trustedcomputinggroup.org/membership/certification/tpm-certified-products/ > > > > > > > > shows that the TPMs get third party certification, Common Criteria EAL 4+. > > > > > > > > While it's theoretically possible that an attacker could compromise > > > > both the TPM vendors and the evaluation agencies, we do have EAL 4+ > > > > assurance against both 1 and 2. > > > > > > Certifications do not equal to trust. > > > > And for trusted keys the least trust solution is to do generation > > with the kernel assets and sealing with TPM. With TEE the least > > trust solution is equivalent. > > > > Are you proposing that the kernel random number generation should > > be removed? That would be my conclusion of this discussion if I > > would agree any of this (I don't). > > The whole point of rng in kernel has been to use multiple entropy > sources in order to disclose the trust issue. > I do understand that, and combining multiple entropy sources, if you have them available to get _more_ entropy is a good idea, at least in theory. But ... How do I know the mixing of entropy happens properly? Especially if I'm not capable of judging this by myself. And how do I know the SW entropy pool and/or code cannot be influenced _somehow_? (either directly or indirectly by influencing one of the contributors). More code and/or HW involved means more attack vectors and complication of the review process. The point is, if you want to certify such an application, you would have to have _all_ contributors _plus_ the kernel rng code certified. And you would have to have it _recertified_ every time a _single_ component - including the kernel code itself! - changes. > Even with weaker entropy than TPM RNG it is still a better choice for > *non-TPM* keys because of better trustworthiness. > "Even with weaker entropy"? Now that's just silly. If you _know_ and _trust_ the TPM to have _better_ entropy, then obviously that is the better choice. I guess the key word being the trust you don't have. > Using only TPM RNG is > a design flaw that has existed probably because when trusted keys were > introduced TPM was more niche than it is today. > For non-TPM keys, possibly. Assuming the kernel RNG indeed adds (or at least does not weaken) entropy. And assuming I _can_ trust the kernel RNG implementation. Question is: why would I trust that more than the TPM implementation? Sure, I could look at the code, but would I truly and fully understand it? (so maybe _I_ would, but would Joe Random User?) > Please remember that a trusted key is not a TPM key. The reality > distortion field is strong here it seems. > Agree. But you should not mess with the possibility to generate keys based on _just_ the TPM RNG _where that is required_ (and perhaps _only_ where that is required, if possible) > /Jarkko Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
