On Fri, Oct 04, 2019 at 01:26:58PM +0000, Safford, David (GE Global Research, US) wrote: > As the original author of trusted keys, let me make a few comments. > First, trusted keys were specifically implemented and *documented* to > use the TPM to both generate and seal keys. Its kernel documentation > specifically states this as a promise to user space. If you want to have > a different key system that uses the random pool to generate the keys, > fine, but don't change trusted keys, as that changes the existing promise > to user space. TPM generating keys (i.e. the random number) would make sense if the key would never leave from TPM (that kind of trusted keys would not be a bad idea at all). > There are many good reasons for wanting the keys to be based on the > TPM generator. As the source for the kernel random number generator > itself says, some systems lack good randomness at startup, and systems > should preserve and reload the pool across shutdown and startup. > There are use cases for trusted keys which need to generate keys > before such scripts have run. Also, in some use cases, we need to show > that trusted keys are FIPS compliant, which is possible with TPM > generated keys. If you are able to call tpm_get_random(), the driver has already registered TPN as hwrng. With this solution you fail to follow the principle of defense in depth. If the TPM random number generator is compromissed (has a bug) using the entropy pool will decrease the collateral damage. > Second, the TPM is hardly a "proprietary random number generator". > It is an open standard with multiple implementations, many of which are > FIPS certified. > > Third, as Mimi states, using a TPM is not a "regression". It would be a > regression to change trusted keys _not_ to use the TPM, because that > is what trusted keys are documented to provide to user space. For asym-tpm.c it is without a question a regression because of the evolution that has happened after trusted keys. For trusted keys using kernel rng would be improvement. /Jarkko
