Re: [Rats] attester vs measurement target (was Re: Use the term "attester" instead of root of trust)

["Oliver, Ian (Nokia - FI/Espoo)" <[e-mail]>]

I agree with that assertion. Just to add to the confusion, the role of some elements does change over time.

For example, one boot is complete on an x86 architecture, the TPM itself is now the root of trust and the measurement code in the BIOS does not take any more part in the process, thus the TPM is now the root-of-trust for reporting.

It is the "for reporting" that seems to be key here and I don't think these additional terms have been listed yet?

I agree with the Attestation Evidence being the TPMS_ATTEST structure/token.

The RATS definition verifier is interesting, as in the TPM case we have two possibilities.


  1.  use of LCPs, where the TPM itself is both ROT for reporting and ROT for verification
  2.  use of external ROT for verification (attestation server possibly?) and the TPM is the ROT for reporting.

t.

Ian


--

Dr. Ian Oliver

Cybersecurity Research

Distinguished Member of Technical Staff

Nokia Bell Labs

[phone]

________________________________
From: Laurence Lundblade <[e-mail]>
Sent: 08 September 2019 21:33
To: Oliver, Ian (Nokia - FI/Espoo) <[e-mail]>
Cc: Giridhar Mandyam <[e-mail]>; Smith, Ned <[e-mail]>; Ira McDonald <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [Rats] attester vs measurement target (was Re: Use the term "attester" instead of root of trust)

Thanks for writing that out...

On Sep 3, 2019, at 12:24 AM, Oliver, Ian (Nokia - FI/Espoo) <[e-mail]<mailto:[e-mail]>> wrote:

More thinking of this, sticking with the practical x86/TPM example for the moment - this generalises to other architectures and situations of course.

The Root of Trust is the code that measures the code that starts the systems, the initial read-only part of BIOS (and the measurement code itself). This code is also the measurement target. The next step is the storage of this measurement in a secure place, ie a TPM PCR (PCR 0).

After boot/measurement has been completed, the Root of Trust is then the TPM itself.

The TPM does not attest anything, but provides a mechanism for delivering an "attestation token" (in this case the TPMS_ATTEST structure) in a secure form, ie: signed by the TPM AK.

The attester in an external entity that requests this proof and verifies it against a known good value.

That definition of attester seems quite different from the one in draft-birkholz-rats-architecture-01<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01> and from the definition I’m advocating. Here’s the main part of the definition from draft-birkholz-rats-architecture-01<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01>


   Attester:  The producer of attestation evidence that has a root of
      trust for reporting (RTR) and implements a conveyance protocol,
      authenticates using an attestation credential, consumes assertions
      about itself and presents it to a consumer of evidence (e.g. a
      relying party or a verifier).  Every output of an attester can be
      appraised via reference values.

By this definition, it seems like the attester is the TPM and boot code that is tightly associated with the entity.  Attestation Evidence is signed token, TPMS_ATTEST.

The RATS definition of Verifier is:


   Verifier:  The consumer of attestation evidence that has a root of
      trust for verification (RTV), implements conveyance protocols,
      appraises attestation evidence against reference values or
      policies, and makes verification results available to relying
      parties.

So, approximately, RATS Attester == TCG RTR and RATS Verifier == TCG Attester?

Seems an unfortunate overlap of terms. Explains some of the confusion we encounter. I don’t have any better ideas so far...

LL