Post-Quantum Crypto Meets a Non-Extractable TPM Key

In the realm of cryptography, combining two valuable features can be tricky. During a project involving device-bound encryption, the author sought to address two objectives simultaneously: a key-establishment process impervious to future quantum-enabled adversaries, and a device identity with its private P-256 key securely residing within the machine's Trusted Platform Module (TPM). Each objective had its own familiar solution; however, fusing them into a single key-establishment flow proved to be the challenging part.

TPM's proficiency was already evident on Windows platforms, where the Microsoft Platform Crypto Provider could employ a TPM for cryptographic operations. When an application requests an Elliptic Curve Diffie-Hellman (ECDH) P-256 key, the private key remains within the TPM, eliminating the need for the application to export it. This feature is beneficial for device binding, as the application does not require copying of the private key material.

However, the P-256 key is based on classical elliptic-curve cryptography (ECC). A sufficiently powerful quantum computer could alter the underlying assumptions of ECC-based cryptography. Thus, the author aimed to incorporate a post-quantum component into the design. The Modular Lattice Key Encapsulation Mechanism (ML-KEM) with a 768-bit security level, specified in FIPS 203, offered a promising solution.

ML-KEM-768 allows a party to encapsulate a shared secret using a public key, with the other party decapsulating it using the corresponding private key. This provides a post-quantum component to the design, though the ML-KEM private key remains managed by software and can potentially be copied if the machine or process exposes it.

The author recognized that wrapping the same content key twice—once under ML-KEM and once under P-256—would not yield a robust design. Instead, both components should contribute to a hybrid key-establishment construction. The ML-KEM decapsulation provides a shared secret, which is then fed into a specified hybrid key derivation function (KDF) to generate the final secret. This design ensures that both components play a role in the final shared secret, preventing any single point of failure.

Implementing this design required preserving the TPM boundary while adhering to the hybrid construction. The recipient side's pseudocode illustrates the process: first, the ML-KEM decapsulation obtains a shared secret; next, the platform provider performs an ECDH operation with the TPM-held key, yielding another shared secret; finally, a hybrid KDF combines these secrets to generate the final secret.

The crucial point is that the TPM's P-256 private scalar is never exported; instead, the TPM returns the result of an operation, keeping the key material independent from the ML-KEM private key.

A crucial aspect of this hybrid design is ensuring that the two private keys are generated independently. Deriving an ML-KEM key from the P-256 secret could lead to a situation where exposing the classical secret would also expose the post-quantum key derived from it. Two algorithms alone do not guarantee two independent failure domains. Instead, both key materials should be generated with appropriate randomness and procedures, ensuring that a failure in one component does not compromise the other.