TLS using a private key store in a TPM

[AlexLaroche]

Describe the feature

Add support for TLS establishments by using a private key store in the TPM.

Use Case

Protect the private key by storing it in a TPM

Proposed Solution

No response

Other Information

No response

Acknowledgements

• [ ] I may be able to implement this feature request
• [ ] This feature might incur a breaking change

[bretambrose]

Is https://github.com/awslabs/aws-c-io/blob/main/include/aws/io/tls_channel_handler.h#L418-L499 insufficient?

[AlexLaroche]

No. If you use PKCS#11 to connect to the TPM, you must load an external library like this : https://github.com/tpm2-software/tpm2-pkcs11

The problem is that there are metadata specific to PKCS#11 that must be saved outside the TPM.

For the example library, it uses an SQLite database to store the metadata. There have been migration issues caused by this in the past with the specified library. In addition, key management in the TPM without going through this connector becomes almost impossible.

A TPM has an interface with very well standardized. We shouldn't need to go through an interface like PKCS#11.

[bretambrose]

No. If you use PKCS#11 to connect to the TPM, you must load an external library like this : https://github.com/tpm2-software/tpm2-pkcs11

Why is this problematic? It is very unlikely that we will ever directly embed device-specific TPM support in this library. Every single customer who has asked for TPM support has been satisfied with pkcs11 support.

The problem is that there are metadata specific to PKCS#11 that must be saved outside the TPM.

Needs more explanation how this is a problem.

A TPM has an interface with very well standardized. We shouldn't need to go through an interface like PKCS#11.

What is this standard you refer to? After all, Pkcs11 is an industry-wide standard for hardware security module access.

[AlexLaroche]

It is very unlikely that we will ever directly embed device-specific TPM support in this library.

You don’t need to embed “device-specific”TPM support in this library. As mentioned, TPM has standardized specification including the communication interface. Generic TPM integration could be supported by this library.

TPM specification :

https://trustedcomputinggroup.org/resource/tpm-library-specification/

It’s even standardized in a ISO standard (ISO/IEC 11889:2015).

Why is this problematic?

The problem is that there are metadata specific to PKCS#11 that must be saved outside the TPM. (It’s normally not the case for a hardware security module [HSM].)

For the example library (the only one we found doing what we want), it uses an SQLite database to store the metadata. There have been migration issues caused in the past with the specified library.

We want to store the private key to connect via MQTT to AWS IoT using the SDK provided by AWS which depends on this library. However, the risk of using a third party library to interface the TPM via PKCS#11 which could break due to a SQLite database migration problem in future really does not enchant us. We don’t want our manufactured devices to get bricked on the field.

Another issue is that we need to preserve the SQLite database in a no readonly storage and we also need to keep the SQLite database even in a factory reset and other operation because it’s represent the identity. It add a lot of complexity in the context.

Also, key management in the TPM without going through this connector becomes almost impossible. It’s quite useful to be able to call the TPM with standard tool like OpenSSL without breaking the PKCS#11 integration, but if you don’t use without the integration, it’s actually breaking everything.

[bretambrose]

I see.

Ultimately, this is an ask whose complexity is high enough that I think it would require you to go through a business-to-business contact (like a TAM or SA) for evaluation/movement.

As a feature request for others to +1, it's fine of course.