FIPS compliance

[elmarco]

There are some concerns regarding implementation of crypto functions in libtpms in order to get FIPS compliancy.

Most of the crypto functions in libtpms come from the specification
https://trustedcomputinggroup.org/specifications-public-review/

and use openssl.

However, some crypto algorithm are open-coded, or use outdated openssl functions where better alternatives exist.

We need to identify those functions and provide alternatives when possible.
Since the code comes from the specification, we will have to discuss how the code changes can be integrated to the specification, before or after they are changed in libtpms etc.

[elmarco]

From IRC discussion with Stefan:

10:21 <stefan_berger> some of the crypt algorithms (like key generation) were probably opened up so they can be cancelled, which is a features stemming from the hw interface and is available via sysfs
10:22 <stefan_berger> though I don't support cancellation in swtpm (but only in the CUSE implementation)

[stefanberger]

To avoid using those opened-up crypto algorithms that keep on reading the cancel flag we could introduce a compile time flag like TPM_NO_COMMAND_CANCEL and use functions that rely on calling into OpenSSL functions. I suppose this would address at least some of your concerns.

[stefanberger]

Unfortunately it's not that simple with keys that need to be regenerateable from a template. They are derived from a random number generator based on a seed and a key derivation function (KDF). For those the call into OpenSSL wouldn't work since those keys need to be re-generateable. For keys that can be truly random a call into OpenSSL would work. CryptCreateObject() is the function that takes the rng as parameter.

[simo5]

@stefanberger hi, I asked @elmarco to look into some of this.
Our concerns are indeed open implemenation of cryptographic algorithms like RSA, HMAC, ECDSA, etc.. we'd like to be able to replace all of them with the equivalent validated cryptographic functions provided by OpenSSL. Key generation and KDFs themselves also falls within the purview of FIPS so would need to use OpenSSL provided functionality.
What KDF do you use that you see problems with ?

[stefanberger]

Keys themselves can also have seeds and these keys can be migrated from one TPM to another and always have to generate the same child keys using their seeds. So the function testing for prime numbers has to behave exactly the same way (on different vendor's implementations) so that the child keys can be repeatably generated. So OpenSSL RSA key generation function could be used as long as it produces always the same keys as the existing algorithm does.

[stefanberger]

@simo5 KDFa seems to be involved with symmetric keys and KDFe with ECC keys.

[simo5]

Looks like these KDFs have been implemnted in accord with the recommendations put forth in
NIST Special Publication 800-108, so they should be fine.
OpenSSL carries a number of KDFs already, and none matches thse we can propose new additions upstream.

I assume your previous comment about migration means these KDFs are set in stone and not changeable?

[simo5]

In fact, at least CryptKDFe looks like is an implementation of The Concatenation KDF decribed in SP 800 56 (I implemented this KDF in python cryptography a while ago and sounded familiar :-)

[stefanberger]

I think that's what key creation depends on and it needs to be repeatable for the same seeds using a KDF. The KDF will have to be the same then to get the same keys. From what I am hearing RSA keys cannot be derived from migrated keys.

[simo5]

Yes KDFs are deterministic, it's their purpose to be.
What do you mean with "RSA keys cannot be derived from migrated keys" ?

[stefanberger]

"NOTE 3 TPM2_CreateLoaded() can be used for creation of asymmetric keys but it may not be used for derivation of certain types of asymmetric keys. This limitation is because of the variability in algorithms for some asymmetric key types (such as RSA). " My guess it may be related to the prime number generation or testing that the could be slightly different and lead to different RSA keys.

[stefanberger]

Though we may have the constraint that if a user creates a derived RSA key with the current implementation and then upgrades the TPM 2 implementation to the FIPS one that derived RSA key would still have to be the same as with the old implementation.

[simo5]

From the FIPS point of view, this is not a problem, as you cannot "upgrade" to FIPS.
Keys that are not created in FIPS mode cannot be used anyway, so inability to migrate keys between FIPS and non-FIPS mode would be "ok".

[stefanberger]

I looked at the HMAC functionality and how it could be converted. I think the trouble lies in a function like TPM2_HMAC_Start() that would create an OpenSSL HMAC_CTX. Unfortunately this context is opaque so that it would prevent vTPM state suspend and resume because we wouldn't be able to take the HMAC state (it has pointers!) and resume it later on to finish the HMAC with TPM2_SequenceComplete.

[simo5]

Yes, all the new OpenSSL API is opaque and uses pointers. And there are no functions to export state.
How critical is this?