Re: [Rats] Definition of an Attesting Environment (and layered attestation)

["Smith, Ned" <[e-mail]>]

It is good to cite counter examples. There are cases where a composite device will have a target environment that is measured so it isn’t an incorrect statement. The RATS architecture isn’t trying to be normative or exclusionary. So any cases to the contrary are also reasonable.

From: Laurence Lundblade <[e-mail]>
Date: Friday, July 16, 2021 at 11:24 AM
To: "Smith, Ned" <[e-mail]>
Cc: Thomas Fossati <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Rats] Definition of an Attesting Environment (and layered attestation)


On Jul 15, 2021, at 10:55 AM, Smith, Ned <[e-mail]<mailto:[e-mail]>> wrote:

The Arch draft captures two duties of an Attesting Env fairly clearly (1- collect Claims, 2- create Evidence). In a layering context the Attesting Env has another duty (3- pass execution thread to the Target Env).

#3 is probably also true for composite device as well, though in composite device the Attesting Env retains a thread of control.

Does the list believe these points should be in the arch draft or are they reasonably inferred?

Hi Ned,

I don’t think #3 should be part of RATS.

- It is not necessary in composite devices
- Many devices using composite attestation will not do it

Here’s an example of a mobile phone. It has three Attesting Environments:
- A TrustZone-based TEE that is the lead Attester
- The HLOS, say Android
- A Secure Element soldered to the PCB

The Secure Element boots fully on its own using SW from the Secure Element vendor. The HW and SW on the Secure Element is certified to EAL 5 or such. The TEE and HLOS have no role in its security or its startup.

The Secure Element is connected to the TEE by HW that can’t be manipulated by the HLOS.

The Secure Element produces full, proper signed Attestation Evidence. That goes to the Attester on the TEE and gets cryptographically bound into the Attestation Evidence produced by the TEE as a nested token.

The Endorser for the Secure Element is one that just handles Secure Elements, knows about their certification levels and such. It is separate from the Endorser for the TEE.


That is the main point about #3. To go a little further…

The HLOS also has an attester that collects evidence about itself and about apps.

It feeds its Attestation Evidence to the TEE, but this is probably not signed and secured as a nested token. It’s just a common submodule as per EAT.

Perhaps the TEE was involved in the start up and validation of the HLOS. Perhaps it wasn’t. It can work either way if the Endorsements are done right.


Note also that all three of the Attestation Environments are up and running all the time. None are short-lived running only during the boot cycle.

A good use of this architecture is to produce fully live Attestation Evidence each time a payment is made by the user of the mobile phone. This is a useful thing to do because payment app, the HLOS, the TEE, the fingerprint authentication in the TEE and the Secure Element all are used to make the payment.

So new fresh attestations of large parts of the system are produced day in and day out. It’s not just re sending the measurements that were taken and stored when the device booted.

(Any interest in this as an example as an addition to section 3 next to the layered attestation example?)

LL