Authentication Secret

[henkbirkholz]

Based on https://mailarchive.ietf.org/arch/msg/rats/okJriJPpapmZgeOfjbVGVP57bQk/

Authentication Secret: An Authentication Secret MUST be available exclusively to an Attester's Attesting Environment.

The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence. The Authentication Secret MUST be established before RATS can take place.

Does the Authentication Secret represent the identity of the Attesting Environment?

[henkbirkholz]

How to understand the Authentication Secret, and is it necessary all the time? For example, in our implementation, during the router booting up, the BIOS measures the BootLoader and records the measured hash value into the TPM, and the BootLoader measures the OS Kernel and records the measured hash value into the TPM as well. From the Layered Attestation perspective, I think (BIOS + TPM) is the Attesting Environment and (BootLoader + TPM) is also the Attesting Environment. But the Claims (measured hash values) aren’t protected separately, and they finally becomes the Evidence (TPM Quote) and it’s only protected by the TPM’s AIK. So, what is the Authentication Secret?

[eckelmeckel]

This comment also addresses #15.

TL;DR: A TPM AIK is an Authentication Secret.

In the first draft, I named this element just "Secret". And yes, an AIK (Attestation Identity Key) in TPM 1.2 terminology, or AK (Attestation Key) in TPM 2.0 terminology, can be such a "Secret". The "Secret ID" basically is a key identifier/ID, e.g., the fingerprint/hash of such a key or the public part of the AK. The TPM FAPI uses key paths, such as "HS/SRK/RSASignKey". These are also valid key/secret identifiers/IDs. There is no official (unique) way of identifying keys, except for the FAPI key -- but: You need to use the FAPI for that purpose which is not available on embedded devices with no OS (because it needs at least a filesystem). In summary, it can be stated that "Secret IDs" are application-specific.

Now, what is the matter with "Authentication Secret" and "Authentication Secret ID"? In a later draft I replaced "Secret (ID)" with "Authentication Secret (ID)" intentionally, after talking to a crypto colleague. "Authentication Secret" is more specific than just "secret". And, in fact, its purpose is to provide authentication, i.e. evidence must provide the security property of "authentication", so that one knows it originates from a valid/specific source, e.g. TPM. This can also be some kind of group key (or DAA key).

• "Authentication Secret": This element must be present in the attesting environment as it signs evidence (and a digital signature provides integrity and authentication).
• "Authentication Secret ID(s)": This element must be mandatory as it identifies the "Authentication Secret(s)".

[William-PanWei]

In our implementation, during the router booting up, the BIOS measures the BootLoader and records the measured hash value into the TPM, then the BootLoader measures the OS Kernel and records the measured hash value into the TPM as well.

Based on our implementation, I can see some inconsistencies from two different aspects:

• According to the definition of Layered Attestation, I think the Attesting Environments are BIOS and Bootloader.
• But, according to the definition of "Authentication Secret", because the TPM's AIK/AK signs Evidence so the TPM's AIK/AK is the Authentication Secret, and because "Each Authentication Secret is uniquely associated with a distinguishable Attesting Environment" so the TPM should be the Attesting Environment.

So, which one is correct?

[henkbirkholz]

After talking with Wei I came to realize (again) that the use of a TPM creates this "interesting" setup of the two layers of Attesting Environments:

Both the first layer that is the BIOS and the second layer that is the Bootloader share an Attesting Envirment component that is the TPM. In acronyms, the BIOS 's claim collection capability and the TPM that is an RTS and RTR compose the first Attesting Environment. The Bootloader's claim collection capability in combination with the identical TPM compose the seceond Attesting Environment. As a result, I agree that the sentence "Each Authentication Secret is uniquely associated with a distinguishable Attesting Environment" does not really allow for that scnerario and needs some help.

[henkbirkholz]

fixed in #44