This is intended as a quick reference to the main concepts defined in the RATS architecture. All the pictures (except one) are taken from there.
The objective of the RATS architecture is to determine whether an Attester can be trusted by a Relying Party given the ability of the Attester to produce Evidence about its current state.
The objective is achieved by a two-stage appraisal process mediated by a trusted third party, called Verifier, with trusted links to the supply chain.
The two stages are as follows:
-
Evidence Appraisal is the evaluation of the trustworthiness of Evidence coming from an Attester. It takes Evidence as input and produces Attestation Results as output. It is conducted according to an Appraisal Policy for Evidence. Typically, Evidence is compared against any applicable Reference Values. Additionally, any Endorsements associated with the Attester are also supplied as input into the appraisal process.
-
Attestation Results Appraisal is the evaluation of the Attestation Results originating from a trusted Verifier and associated with the Attester's Evidence. The result of the appraisal process is a trust decision regarding the Attester. The appraisal is conducted according to an Appraisal Policy for Attestation Results.
The architecture pre-defines a number of fundamental roles (one per box in Figure 1). Note that in general roles can be coalesced into the same entity or split among different entities. For example, the same supply chain entity could be at the same time an Endorser and a Reference Value Provider, a Relying Party and a Verifier could be co-located, etc.
There are three main roles in the architecture:
-
A Verifier conducts Evidence Appraisal. The Verifier has trusted relationships with the supply chain (Endorsers and Reference Value Providers) through which it acquires accurate and timely information about Attesters. A Verifier Owner is authorised to configure Appraisal Policy for Evidence into the Verifier.
-
A Relying Party conducts Attestation Results Appraisal. A Relying Party Owner is authorised to configure Appraisal Policy for Attestation Results into the Relying Party.
The architecture defines two logical roles for supply chain actors according to the kind of input they supply:
-
An Endorser supplies Endorsements to the Verifier.
-
A Reference Value Provider supplies Reference Values to the Verifier.
Finally, the architecture defines two roles to model authorised administrative interactions with Verifiers and Relying Parties:
-
A Verifier Owner is authorised to configure Appraisal Policy for Evidence in a Verifier.
-
A Relying Party Owner is authorised to configure Appraisal Policy for Attestation Results in a Relying Party.
-
Evidence is a statement made by the Attester containing a set of trust metrics associated with the Attester's current state. Typically, such trust metrics are encoded into key/value pairs also known as attestation Claims. Claims may include measurements related to the boot sequence, measurements of the runtime state, and also telemetry (e.g., values sampled from a "secure" sensor).
-
An Attestation Result is a statement made by the Verifier regarding the trustworthiness of Evidence produced by an Attester. It is the result of the Evidence appraisal process (see Verifier). It is expected that Attestation Results are in a form that is simpler to consume than the raw Evidence. The Attestation Results may present a summarised or normalised set of Claims compared to those in the Attester Evidence.
-
Endorsements are Attester's features that are not explicitly found in attestation Evidence. For example: a public key coupled with the Attester's signing key, a security certification associated with the attesting device, etc.
-
Reference Values are "known good" values for the trust metrics reported by an Attester. They are "known good" in the sense that they describe the desired state of a trustable device. A number of related Claims are expected to be found in attestation Evidence which will be matched against the corresponding Reference Values during the Evidence Appraisal procedure.
-
An Appraisal Policy for Evidence is the set of rules that define the Evidence Appraisal procedure.
-
An Appraisal Policy for Attestation Results is the set of rules that define the Attestation Results Appraisal procedure.
An Attester consists of at least one Attesting Environment and at least one Target Environment.
-
An Attesting Environment is the measuring portion of an Attester. It collects the relevant information about the Target Environment by reading system registers and variables, calling into subsystems, taking measurements on code, memory, or other security related assets. It then formats the Claims appropriately, and typically uses private key material to generate attestation Evidence about itself.
-
A Target Environment represents the measured portion of an Attester. Anything that may have an impact on the correctness of the trusted computing base is a candidate target.
Note that Attesting and Target Environments may be combined. A single device could host more than one Attester. Attesters can be chained, e.g., DICE:
The architecture describes three methods to ascertain the point in time (called "epoch") an Evidence or Attestation Result has been produced.
Once that point in time is established, the freshness of the appraised Claims is assessed based on the Appraisal Policy for Evidence or Attestation Results that compares the estimated epoch against an "expiry" threshold defined locally to that policy.
The three methods can be distinguished into two categories: implicit (Nonce, Epoch Id) and explicit timekeeping (Timestamp).
The generating entity includes a signed timestamp in the produced Evidence or Attestation Result. This approach relies on synchronized and trustworthy clocks between the generating and appraising roles,
Note that the required trustworthy clock may not be available in the TEE.
A non-predictable nonce is sent by the appraising entity, and the nonce is then signed and included as one of the Claims in the Evidence or Attestation Result.
A trusted third party, the Epoch ID Distributor, broadcasts an unpredictable value (the epoch ID) at regular intervals.
The most recent Epoch ID is included in the produced Evidence or Attestation Results, and the appraising entity can compare the Epoch ID in received Evidence or Attestation Results against the latest Epoch ID it received from the Epoch ID Distributor to determine if it is within the current epoch.
An Epoch ID can be used more than once and can even be used by more than one entity at the same time. A direct consequence of that is that the state kept by the appraiser is independent of the number of Attesters or Verifiers from which it expects to receive Evidence or Attestation Results, as long as all use the same Epoch ID Distributor.
The architecture defines two basic interaction patterns which are given the names Background check and Passport.
These two basic patterns can be combined in more complicated topologies.
In Background check the Attester presents Evidence to the Relying Party which in turn asks the Verifier for appraisal.
When using the Passport pattern, the Attester presents Evidence to the Verifier which appraises it and returns an Attestation Result. Subsequently, when the Attester and Relying Party need to interact, the former presents the Attestation Result previously obtained to the latter.
