Remote Attestation - Liam Wisehart
Liam Wisehart
SubscribeSign in
Remote Attestation<br>If it quacks like a duck...
Liam Wisehart<br>Jul 09, 2026
Share
A host connects to your network. It looks like part of your fleet, but is it really? It runs your software, or at least enough of it to start serving traffic. It quacks like a duck. But what’s on the inside?
I’m surprised ChatGPT agreed to make that one.
But seriously. How do you know that your data isn’t sitting on a compromised stack? How do you know that you aren’t trying to schedule workloads on an attacker controlled machine? How do you know any of your security controls are actually in place on a host? And once an attacker has taken over a host, there are endless places to hide and persist through upgrades and reboots.<br>Most setups have a lot of faith in hosts once they have been provisioned. Hosts are placed in the trust boundary and then just remain there, regardless of whatever has happened in the mean time. If they even should have been there in the first place.<br>Enter the wonderful world of remote attestation which (mostly) solves this problem. Using a TPM, we can remotely, cryptographically prove a couple of things:<br>The host has the expected hardware
The host has the expected firmware
The host has the expected kernel and init image
The host has the expected root filesystem (depends on the setup)
The host passed arbitrary checks that we define
This means that after a reboot, we know the exact state a host is in. Without extensive physical modifications and tampering, a fresh boot either puts us in a trusted state or fails and breaks trust in the host.<br>The measure boot cycle is different then trusted boot, it relies on signed measurements, not signed artifacts like secure boot. It offers a much bigger coverage surface at the cost of considerable complexity. Even malicious, signed, drivers and rootkits can be caught.<br>But what’s the point of measuring if we don’t block boot like secure boot does? What does measurement get us?<br>This gets into how you trust hosts. You can use your TPM to encrypt all or part of your root-fs (where all your keys and data are), so that a host is functionally inoperable without the measured boot succeeding. Your RA can refuse to issue certificates to a host that doesn’t provide correct measurements (you are using mTLS right?). You can even back TLS x509 certs with the TPM so an incorrectly rebooted host can’t authenticate over mTLS at all. This offers extremely strong guarantees about the initial state of hosts, so you can trust that your workloads and data are in an environment you trust.<br>This isn’t a perfect solution. Physical attacks (like memory taps) are still a problem. But coupled with robust EDR and a good LSM policy, you have no closed the door on a huge number of issues, in particular nasty kernel and driver supply chain attacks that bypass all of your nice userland defenses.<br>But what about attacks after boot?<br>That’s your EDR’s problem. Trusted boot provides the bedrock to build a bunch of other primitives on top of. Including cryptographic proof your EDR is installed and running (at boot), immutable filesystems (verified at boot), signed upgrades, confidential computing, etc. Without it you can’t trust your hosts themselves and can’t make further security guarantees. Houses built on sand and all that.<br>Just use remote attestation, it is easy
Unfortunately, remotely measuring every step of your boot process, for every host in your organization, is a tremendous undertaking . It goes into how you build and distribute firmware, init images, kernels. On the plus side, it will give you a chance to clean up a bunch of legacy cruft and also probably reveal a bunch of supply chain issues you weren’t thinking about.<br>How it works
TPM magic more or less. TPMs expose a limited interface of cryptographic operations to the host, and that interface is locked down sufficiently that it controls your access to cryptographic material. They are also resistant to physical attacks, but the main function is to mitigate software attacks, not physical. Even kernel code can’t dig into a TPM and extract private material.<br>The TPM comes with a set of PCRs (Platform Configuration Registers). Their only function is to store hashes. They only go forward, you can measure new hashes into a PCR and it hashes the previous value with the new one, yielding a unique result. No going backwards. Different artifacts get measured into the different PCRs during boot and init, and similar to secure boot, each phase measures the next phase.<br>Breaking this chain anywhere will taint the PCR values.<br>The TPM cares about these values. You can do a couple thing based on them:<br>TPM sealing: material can be stored in the TPM and only unlocked if the PCRs (the ones you chose) check out.
TPM quotes: the values can be signed with a key resident to the TPM. Your RA knows the providence of that key (more in a moment) and this offers strong proof that the...