Messages in this thread | | | From | Pascal Van Leeuwen <> | Subject | RE: [PATCH] KEYS: asym_tpm: Switch to get_random_bytes() | Date | Wed, 9 Oct 2019 08:02:52 +0000 |
| |
> -----Original Message----- > From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> On Behalf Of > Jarkko Sakkinen > Sent: Wednesday, October 9, 2019 9:33 AM > To: Ken Goldman <kgold@linux.ibm.com> > Cc: Safford, David (GE Global Research, US) <david.safford@ge.com>; Mimi Zohar > <zohar@linux.ibm.com>; linux-integrity@vger.kernel.org; stable@vger.kernel.org; open > list:ASYMMETRIC KEYS <keyrings@vger.kernel.org>; open list:CRYPTO API <linux- > crypto@vger.kernel.org>; open list <linux-kernel@vger.kernel.org> > 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
| |