-----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:42 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 10:33:15AM +0300, Jarkko Sakkinen wrote:
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-pro...
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.
Even with weaker entropy than TPM RNG it is still a better choice for *non-TPM* keys because of better trustworthiness. 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.
Please remember that a trusted key is not a TPM key. The reality distortion field is strong here it seems.
And why not use RDRAND on x86 instead of TPM RNG here? It is also FIPS compliant and has less latency than TPM RNG. :-) If we go with this route, lets pick the HRNG that performs best.
There's certification and certification. Not all certificates are created equally. But if it matches your specific requirements, why not. There's a _lot_ of HW out there that's not x86 though ...
And: is RDRAND certified for _all_ x86 processors? Or just Intel? Or perhaps even only _specific (server) models_ of CPU's? I also know for a fact that some older AMD processors had a broken RDRAND implementation ...
So the choice really should be up to the application or user.
Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com