TPM and Remote attestation

Question

I’m a little unclear on this subject:

TPM chips to enable remote attestation. This mechanism works as follows. At boot time, the host computes a measurement list ML consisting of a sequence of hashes of the software involved in the boot sequence, namely the BIOS, the bootloader, and the software implementing the platform. The ML is securely stored inside the host’s TPM. To attest to the platform, a remote party challenges the platform running at the host with a nonce nU . The platform asks the local TPM to create a message containing both the ML and the nU , encrypted with the TPM’s private EK. The host sends the message back to the remote party who can decrypt it using the EK’s corresponding public key, thereby authenticating the host. By checking that the nonces match and the ML corresponds to a configuration it deems trusted, a remote party can reliably identify the platform on an untrusted host.

Lets say a TPM is in one of the nodes of a cluster (in the infrastrusture of cloud) . we know during boot time TPM startes performing integrity measurements : basically two way of doing this; 1-SRTM (Static Root of Trust for Measurements) (bios-bootloader-kernel) 2-DRTM (Dynamic Root of Trust for Measurements).(running applications : thats something unclear to me too).

those measurements are finally extended to the TPM and saved in the PCRs.

A user is willing to verify the integrity of the cloud platform ,thus a trusted third party has to verify that for him.And finally attest him with a response of trusted/untrusted platform .Lets apply it on the 1st quote.

my questions:

• Remote attestation is for authenification or validating the integrity?
• Does the authenitification equals integrity of the platform?
• The TTP requests measurement list are those measurements meant to be hash values of SRTM and DRTM protocols?
• How does the trusted third party verifies those measurements?

Answer 1

encrypted with the TPM’s private EK

There's something wrong with the document you're reading. Encrypting with a private key is nonsense. A private key can be used to decrypt or to sign. Here, “signed” is clearly meant instead of “encrypted”. That's a sign that the author of the document doesn't know what they're talking about. I strongly recommend reading more reliable material.

In addition, the EK isn't used to sign a platform attestation. That's an AIK. Using an EK to sign a platform attestation would be a privacy violation. The EK is used inside the TPM to decrypt data as part of the AIK enrollment protocol.

The part about hashes of software is correct. The main CPU and the TPM cooperate to calculate a hash of all the code that is executing on the main CPU. Upon request, the TPM can sign a message that says “the hash of the code that is executing on the main CPU is …”. This message is signed with an AIK, which is a key pair for which only the TPM has the private part. When a verifier wants to know the state of the platform, it sends a request to the TPM containing a nonce. The nonce is included in the signed reply. $$ \mathsf{verifier} \rightarrow \mathsf{TPM}: \mathrm{nonce} \\ \mathsf{TPM} \rightarrow \mathsf{verifier}: \mathrm{hash}, [\mathrm{nonce}, \mathrm{hash}, \ldots]_{\mathrm{AIK}_{\mathrm{priv}}} \\ $$ The fact that the message has a correct signature guarantees that it was produced by the TPM at some point in the past. The fact that the correctly signed message includes the nonce guarantees that it was produced by the TPM at some point after the verifier generated the nonce: this prevents replay attacks.

A valid attestation authenticates the platform. In addition, it guarantees that the platform is in a certain state. This alone does not say anything about the integrity of the platform. In order to guarantee the integrity of the platform, the verifier must know what the correct value is for the hash of the platform state (or a set of correct values, if more than one value is possible).

This protocol does not require a trusted third party once the TPM has been provisioned with an AIK and the verifier has enrolled this AIK. However, in practice, an infrastructure will often separate the verifier from the relying party. The relying party is an entity that wants to communicate with the platform, and is only willing to do so if the platform is in a good state. However the relying party does not know what a good state is, so it relies on a trusted third party to perform the verification.

Answer 2

The TPM-JS playground created by Google is a good way to learn these concepts. That document explains all these steps clearly in elaborate manner.

To quote the relevant portion here, for the completeness sake:

The remote attester reads the boot event log and a fresh PCR quote. It validates the event log's integrity by comparing the actual PCR values to the expected ones from the log. It then evaluates the integrity state of the host: do we trust this particular firmware that was loaded? This particular boot loader and OS kernel? It can also set a policy around these measurements, and enforce, for instance, that an up-to-date kernel is running. A compromised host will be detected. An attacker can deny access to the TPM or to the boot event log, but this denial of service will result in an untrusted host.