TPM2 Key Trust: where did Keylime go wrong

In my previous blog post , I explained how a verifier can get a signing key that it trusts is on a TPM for attestation (part 2 of the other post in the making). I have been contributing to a specific implementation of remote attestation for Linux, called Keylime . As part of the effort on porting the agent to Rust, I was looking into how the process works, and as part of that I identified a vulnerability in how Keylime deals with the TPM2 that breaks the Chain of Trust in two different places.

TPM2 Attestation Keys

Part 1 of a 2-part series on TPM attestation Background These days, the Trusted Platform Module (TPM) is a pretty ubiquitous piece of hardware. This is thanks in part due to Microsoft requiring it [since 2016 for Windows 10] (https://docs.microsoft.com/en-us/windows-hardware/design/minimum/minimum-hardware-requirements-overview#37-trusted-platform-module-tpm) . The TPM enables very interesting security features, like decryption/signing of data, key exchange protocols, and more, without handling the private key in software. One of the other big things a TPM can be used for is attesting a server to a remote server.

BIOS Security Settings

Over the years, I have given people advice over some settings in their laptops BIOS they might want to tweak for security purposes. I believe that many consumer devices ship with the secure settings (though I have none to test myself), but I know that at least some companies request custom configuration. As a consequence, I will list settings that I suggest to modify to improve security, and figured I might as well publish this, also so that I remember everything myself when I get a new laptop.