]> Altera

andrew.draper@altera.com

Intel

ned.smith@intel.com

Security Remote ATtestation ProcedureS Evidence, RATS, attestation, verifier, supply chain, RIM, appraisal Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether to engage in secure interactions with it - or not. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires fresh Evidence from an Attester. Before a Verifier can appraise Evidence it may require transformation to an internal representation. This document specifies Evidence transformation methods for DICE and SPDM formats to the CoRIM internal representation.

Introduction Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether to engage in secure interactions with it - or not. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires fresh Evidence from an Attester. Before a Verifier can appraise Evidence it may require transformation to an internal representation. This document specifies Evidence transformation methods for DICE and SPDM formats to the CoRIM internal representation.

Terminology This document uses terms and concepts defined by the RATS architecture. For a complete glossary see . Addintional RATS architecture is found in . RATS architecture terms and concepts are always referenced as proper nouns, i.e., with Capital Letters. In this document, an Evidence structure describes an external representation. There are many possible Evidence structures including and . The bytes composing the CoRIM data structure are the same either way. The terminology from CoRIM , CBOR , CDDL and COSE applies. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Verifier Reconciliation This specification assumes the reader is familiar with Verifier Reconsiliation as described in . It describes how a Verifier should process the CoRIM to enable CoRIM authors to convey their intended meaning and how a Verifier reconciles its various inputs. Evidence is one of its inputs. The Verifier is expected to create an internal representation from an external representation. By using an internal representation, the Verifier processes Evidence inputs such that they can be appraised consistently. This specification defines format transformations for Evidence in DICE , SPDM , and concise evidence formats that are transformed into a Verifier's internal representation. This specification uses the CoMID internal representation () as the transformation target. Other internal representations are possible but out of scope for this specification.

Transforming DICE Certificate Extension Evidence This section defines how Evidence from an X.509 certificate containing a DICE certificate extension is transformed into an internal representation that can be processed by Verifiers. Verifiers supporting the DICE certificate extension Evidence SHOULD implement this transformation. This specification defines transformation methods for two DICE certificate extensions DiceTcbInfo and DiceMultiTcbInfo. These extensions are identified by the following object identifiers:

• tcg-dice-TcbInfo - "2.23.133.5.4.1"
• tcg-dice-MultiTcbInfo - "2.23.133.5.4.5"

Each DiceTcbInfo entry in a MultiTcbInfo is converted to a CoRIM ECT (see ) using the transformation steps in this section. Each DiceMultiTcbInfo entry is independent of the others such that each is transformed to a separate ECT entry. A list of Evidence ECTs (i.e., ae = [ + ECT]) is constructed using CoRIM attestation evidence internal representation (see ). For each DiceTcbInfo (DTI) entry in a DiceMultiTcbInfo allocate an ECT structure.

1. An ae entry is allocated.
2. The cmtype of the ECT is set to evidence.
3. The DiceTcbInfo (DTI) entry populates the ae ECT.

1. The DTI entry populates the ae ECT environment-map

• • copy(DTI.type, ECT.environment.environment-map.class-map.class-id). The binary representation of DTI.type MUST be equivalent to the binary representation of class-id without the CBOR tag.

• • copy(DTI.vendor, ECT.environment.environment-map.class-map.vendor).

• • copy(DTI.model, ECT.environment.environment-map.class-map.model).

• • copy(DTI.layer, ECT.environment.environment-map.class-map.layer).

• • copy(DTI.index, ECT.environment.environment-map.class-map.index).

1. The DTI entry populates the ae ECT elemenet-list.

• • copy(DTI.version, ECT.element-list.element-map.measurement-values-map.version-map.version).

• • copy(DTI.svn, ECT.element-list.element-map.measurement-values-map.svn).

• • copy(DTI.vendorInfo, ECT.element-list.element-map.measurement-values-map.raw-value).

• • Foreach FWID in FWIDLIST: copy(DTI.FWID.digest, ECT.element-list.element-map.measurement-values-map.digests.digest.val).

• • Foreach FWID in FWIDLIST: copy(DTI.FWID.hashAlg, ECT.element-list.element-map.measurement-values-map.digests.digest.alg).

1. The DTI entry populates the ae ECT elemenet-list.flags. Foreach f in DTI.OperationalFlags and each m in DTI.OperationalFlagsMask:

• • If m.notConfigured = 1 AND f.notConfigured = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-configured = FALSE).

• • If m.notConfigured = 1 AND f.notConfigured = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-configured = TRUE).

• • If m.notSecure = 1 AND f.notSecure = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-secure = FALSE).

• • If m.notSecure = 1 AND f.notSecure = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-secure = TRUE).

• • If m.recovery = 1 AND f.recovery = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-recovery = FALSE).

• • If m.recovery = 1 AND f.recovery = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-recovery = TRUE).

• • If m.debug = 1 AND f.debug = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-debug = FALSE).

• • If m.debug = 1 AND f.debug = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-debug = TRUE).

• • If m.notReplayProtected = 1 AND f.notReplayProtected = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-replay-protected = FALSE).

• • If m.notReplayProtected = 1 AND f.notReplayProtected = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-replay-protected = TRUE).

• • If m.notIntegrityProtected = 1 AND f.notIntegrityProtected = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-integrity-proteccted = FALSE).

• • If m.notIntegrityProtected = 1 AND f.notIntegrityProtected = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-integrity-proteccted = TRUE).

• • If m.notRuntimeMeasured = 1 AND f.notRuntimeMeasured = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-runtime-meas = FALSE).

• • If m.notRuntimeMeasured = 1 AND f.notRuntimeMeasured = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-runtime-meas = TRUE).

• • If m.notImmutable = 1 AND f.notImmutable = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-immutable = FALSE).

• • If m.notImmutable = 1 AND f.notImmutable = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-immutable = TRUE).

• • If m.notTcb = 1 AND f.notTcb = 1; set(ECT.element-list.element-map.measurement-values-map.flags.is-tcb = FALSE).

• • If m.notTcb = 1 AND f.notTcb = 0; set(ECT.element-list.element-map.measurement-values-map.flags.is-tcb = TRUE).

1. The signer of the certificate containing DTI is copied to the ECT.authority field. The signer identity MUST be expressed using $crypto-key-type-choice. A profile or other arrangement is used to coordinate which $crypto-key-type-choice is used for both Evidence and Reference Values.

The completed ECT is added to the ae list.

Transforming TCG Concise Evidence This section defines how Evidence from TCG is transformed into an internal representation that can be processed by Verifiers. Verifiers supporting the TCG Concise Evidence format SHOULD implement this transformation. Concise evidence may be recognized by any of the following registered types:

CBOR tag	C-F ID	TN Tag	Media Type
#6.571	10571	#6.1668557429	"application/ce+cbor"

A Concise Evidence entry is converted to a CoRIM ECT (see ) using the transformation steps in this section. A list of Evidence ECTs (i.e., ae = [ + ECT]) is constructed using CoRIM attestation evidence internal representation (see ). The Concise Evidence scheme uses CoRIM CDDL definitions to define several Evidence representations called triples. Cases where Concise Evidence CDDL is identical to CoRIM CDDL the transformation logic uses the structure names in common.

Transforming the ce.evidence-triples The ce.evidence-triples structure is a list of evidence-triple-record. An evidence-triple-record consists of an environment-map and a list of measurement-map. For each evidence-triple-record an ae ECT is constructed.

1. An ae ECT entry is allocated.
2. The cmtype of the ECT is set to evidence.
3. The Concise Evidence (CE) entry populates the ae ECT environment fields.

• • copy(CE.evidence-triple-record.environment-map, ECT.environment.environment-map).

1. For each ce in CE.[ + measurement-map]; and each ect in ECT.[ + element-list]:

• • copy(ce.mkey, ect.element-map.element-id)

• • copy(ce.mval, ect.element-map.element-claims`)

1. The signer of the envelope containing CE is copied to the ECT.authority field. For example, a CE may be wrapped by an EAT token or DICE certificate . The signer identity MUST be expressed using $crypto-key-type-choice. A profile or other arrangement is used to coordinate which $crypto-key-type-choice is used for both Evidence and Reference Values.
2. If CE has a profile, the profile is converted to a $profile-type-choice then copied to the ECT.profile` field.

The completed ECT is added to the ae list.

Transforming the ce.identity-triples The ce.identity-triples structure is a list of ev-identity-triple-record. An ev-identity-triple-record consists of an environment-map and a list of $crypto-key-type-choice. For each ev-identity-triple-record an ae ECT is constructed where the $crypto-key-type-choice values are copied as ECT Evidence measurement values. The ECT internal representation accommodates keys as a type of measurement. In order for the $crypto-key-type-choice keys to be verified a CoRIM identity-triples claim MUST be asserted.

1. An ae ECT entry is allocated.
2. The cmtype of the ECT is set to evidence.
3. The Concise Evidence (CE) entry populates the ae ECT environment fields.

• • copy(CE.ce-identity-triple-record.environment-map, ECT.environment.environment-map).

• • copy(null, ECT.element-list.element-map.element-id).

1. For each cek in CE.[ + $crypto-key-type-choice ]; and each ect in ECT.element-list.element-map.element-claims.intrep-keys.[ + typed-crypto-key ]:

• • copy(cek, ect.key)

• • set( &(identity-key: 1), ect.key-type)

1. The signer of the envelope containing CE is copied to the ECT.authority field. For example, a CE may be wrapped by an EAT token or DICE certificate . The signer identity MUST be expressed using $crypto-key-type-choice. A profile or other arrangement is used to coordinate which $crypto-key-type-choice is used for both Evidence and Reference Values.
2. If CE has a profile, the profile is converted to a $profile-type-choice then copied to the ECT.profile` field.

The completed ECT is added to the ae list.

Transforming the ce.attest-key-triples The ce.attest-key-triples structure is a list of ev-attest-key-triple-record. An ev-attest-key-triple-record consists of an environment-map and a list of $crypto-key-type-choice. For each ev-attest-key-triple-record an ae ECT is constructed where the $crypto-key-type-choice values are copied as ECT Evidence measurement values. The ECT internal representation accommodates keys as a type of measurement. In order for the $crypto-key-type-choice keys to be verified a CoRIM attest-key-triples claim MUST be asserted.

1. An ae ECT entry is allocated.
2. The cmtype of the ECT is set to evidence.
3. The Concise Evidence (CE) entry populates the ae ECT environment fields.

• • copy(CE.ce-attest-key-triple-record.environment-map, ECT.environment.environment-map).

• • copy(null, ECT.element-list.element-map.element-id).

1. For each cek in CE.[ + $crypto-key-type-choice ]; and each ect in ECT.element-list.element-map.element-claims.intrep-keys.[ + typed-crypto-key ]:

• • copy(cek, ect.key)

• • set( &(attest-key: 0), ect.key-type)

1. The signer of the envelope containing CE is copied to the ECT.authority field. For example, a CE may be wrapped by an EAT token or DICE certificate . The signer identity MUST be expressed using $crypto-key-type-choice. A profile or other arrangement is used to coordinate which $crypto-key-type-choice is used for both Evidence and Reference Values.
2. If CE has a profile, the profile is converted to a $profile-type-choice then copied to the ECT.profile` field.

The completed ECT is added to the ae list.

Transforming SPDM Evidence This section defines how Evidence from SPDM is transformed into an internal representation that can be processed by Verifiers. Verifiers supporting the SPDM Evidence format SHOULD implement this transformation. The SPDM measurements are converted to concise-evidence which has a format that is similar to CoRIM triples-map (their semantics follows the matching rules described above). The TCG DICE Concise Evidence Binding for SPDM specification describes a process for converting the SPDM Measurement Block to Concise Evidence. Subsequently the transformation steps defined in .

Security and Privacy Considerations There are no security and privacy considerations.

IANA Considerations There are no IANA considerations.

References Normative References Fraunhofer SIT Linaro arm Intel Huawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. Trusted Computing Group (TCG) Trusted Computing Group (TCG) In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. International Telecommunications Union Distributed Management Task Force Trusted Computing Group Armidale Consulting Fraunhofer SIT Linaro In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and, using Appraisal Policy typically with additional input from Endorsements and Reference Values, generates Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Trusted Computing Group Security Theory LLC Mediatek USA Qualcomm Technologies Inc. Red Hound Software, Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]

Contributors The authors would like to thank the following people for their valuable contributions to the specification. Henk Birkholz Email: henk.birkholz@ietf.contact Yogesh Deshpande Email: yogesh.deshpande@arm.com Thomas Fossati Email: Thomas.Fossati@linaro.org Dionna Glaze Email: dionnaglaze@google.com

Acknowledgments The authors would like to thank James D. Beaney, Francisco J. Chinchilla, Vincent R. Scarlata, and Piotr Zmijewski for review feedback.