Does "late launch"/"dynamic chain of trust" allow remote attestation?

Question

One of the features support by modern processes and Trusted Platform Modules is "dynamic chain of trust" (also known under the acronym DRTM, for dynamic root of trust measurement). This allows loading a critical piece of software in an isolated execution environment, where it can be protected from the rest of the software on the system.

The feature is initiated via the SENTER instruction (on Intel chips) or SKINIT instruction (on AMD). On Intel, this is part of Intel's Trusted Execution Technology (TXT). I've sometimes heard this technology under the name "late launch": e.g., if you want to start a hypervisor or other critical software while the system is already running, in a trusted way, you do a "late launch" of the hypervisor/software module.

DRTM/"late launch" provides isolation (so that other software components cannot tamper with the code or data of the trusted module that is launched in this way). It also provides sealed storage, so that the trusted module can store data in encrypted form, where the decryption key will be released to future invocations of the trusted module but not to any other software component.

Does "dynamic chain of trust" support remote attestation? Does it provide way to attest to the code of the trusted module that was launched in this way, to a third party?

Answer 1

Does "dynamic chain of trust" support remote attestation?

When a dynamic launch is used on an area of memory, specific PCR indexes in the TPM are used to used to record the state of that software. If these PCR indexes are included in the attestation request by the challenger, then that software would be attested to in the response. These PCR indexes are 17-22, as specified in the TCG's PCClient inplementation for BIOS spec, see page 30.

Does it provide way to attest to the code of the trusted module that was launched in this way, to a third party?

Intel's implementation of TXT support on Linux, tboot, has missed a detail, which they will hopefully fix soon. tboot doesn't expose the event log, which would show what software was extended into TPM PCRs as part of the TXT launch. This is a requirement for a remote challeneger to attest against dynamic launch PCRs, so at the moment, support isn't fully there. You can technically find the event log, but its not available in a TCG standard format, so all the common trusted computing tools that'd be used to parse it will not work ATM.

Answer 2

Yes.

You can see both functions as being really two separate things, i.e., DRTM (Dynamic Root of Trust for Measurement) is just another way to extend PCR values (17-22) (like SRTM) while Remote Attestation will take whatever PCR you wish to use (much like the SEAL operation). There’s no dependency or real link between those functionalities.

If you want more detail about the internals of DRTM and Remote Attestation I highly suggest reading Flicker’s project papers. Flicker use DRTM to prove to a 3rd party a particular D-MLE (Dynamic Measure Launch Environment) was executed. Short story: http://www.cs.unc.edu/~reiter/papers/2007/SP.pdf, Long story: https://web.archive.org/web/20151011011703/http://research.microsoft.com/pubs/138301/eurosys053-mccune-cr.pdf.

p.s. There seems to be an error in the long story where they say SRK (Storage Root Key) is created by the manufacturer while in reality it is created by the owner of the platform when he take ownership. Hopefully, they didn't use the SRK to prove it's a real/physical TPM. Only the EK (Endorsement Key) can prove a TPM to be genuine.

Answer 3

I'm not sure how it could without having some type of pre-shared key with the remote service or a reliably established private key that the TPM holds. I think the issue would be that there would be no way for the third party to know that it was the TPM executing the code as opposed to an altered variant modified to run in non-protected space. If the TPM had a trusted private key from the third party, then it would be possible for the third party to issue a challenge to the TPM which the TPM could only respond to within a signed, trusted process and that would accomplish the remote attestation goal, but I'm not seeing how that trusted private key would be established.

Note that I'm answering purely off the description of the crypto-system provided and my general knowledge of TPMs. I don't have any additional specific knowledge about what Trusted Execution supports, but I thought the main purpose of that was for DRM and code protection purposes rather than remote attestation, though it would certainly be a nice extension to it.

Found a document with more detail from CERT. CERT document on TPM capability.