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