]> Arm

Simon.Frost@arm.com

Linaro

Thomas.Fossati@linaro.org

University of Applied Sciences Bonn-Rhein-Sieg

Hannes.Tschofenig@gmx.net

Fraunhofer SIT

henk.birkholz@ietf.contact

Security Remote ATtestation ProcedureS EAT measurements claim measured component The term "measured component" refers to an object within the attester's target environment whose state can be inspected and, typically, digested. A digest is computed through a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document defines a "measured component" format that can be used with the EAT Measurements claim. Discussion Venues Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction defines a Measurements claim that:

• "[c]ontains descriptions, lists, evidence or measurements of the software that exists on the entity or any other measurable subsystem of the entity."

This claim allows for different measurement formats, each identified by a different CoAP Content-Format (). Currently, the only specified format is CoSWID of type "evidence", as per . This document introduces a "measured component" format that can be used with the EAT Measurements claim in addition to or as an alternative to CoSWID. The term "measured component" refers to any measurable object on a target environment, that is, an object whose state can be sampled and, possibly, digested. This includes, for example: the invariant part of a firmware component that is loaded in memory at startup time, a run-time integrity check (RTIC), a file system object, or a CPU register.

Conventions and Definitions 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. In this document, CDDL is used to describe the data formats.

Information Model A "measured component" information element includes the component's sampled state (in digested or raw form) along with metadata that helps in identifying the component. Optionally, any entities responsible for signing the installed component can also be specified. The information model of a "measured component" is described in . Measured Component Information Elements

IE	Description	Requirement Level
Component Name	The name given to the measured component. It is important that this name remains consistent across different releases to allow for better tracking of the same measured item across updates. When combined with a consistent versioning scheme, it enables better signaling from the appraisal procedure to the relying parties.	REQUIRED
Component Version	A value representing the specific release or development version of the measured component. Using Semantic Versioning is RECOMMENDED.	OPTIONAL
Digested or Raw Value	Either the raw value or the digested value of the measured component.	REQUIRED
Digest Algorithm	Hash algorithm used to compute the Digest Value.	REQUIRED only if the value is in the digested form
Signers	One or more unique identifiers of entities signing the measured component.	OPTIONAL

The format SHOULD also allow a limited amount of extensibility to accommodate profile-specific semantics.

Data Model This section presents a JSON and CBOR data model that implements the information model outlined in . The data model is inspired by the "PSA software component" claim (), which has been refactored to take into account the recommendations about the design of new EAT claims described in . CDDL is used to express rules and constraints of the data model for both JSON and CBOR. These rules must be strictly followed when creating or validating "measured component" data items. When there is variation between CBOR and JSON, the JC<> CDDL generic defined in is used.

 Common Types The following three basic types are used at various places within the measured component data model:

The measured-component Data Item The measured-component data item is as follows: component-id measurement ? signers-label => [ + signer-type ] ? flags-label => flags-type } measurement //= ( digested-measurement-label => corim.digest ) measurement //= ( raw-measurement-label => bytes ) signer-type = eat.JC flags-type = eat.JC id-label = eat.JC<"id", 1> digested-measurement-label = eat.JC<"digested-measurement", 2> raw-measurement-label = eat.JC<"raw-measurement", 5> signers-label = eat.JC<"signers", 3> flags-label = eat.JC<"flags", 4> ]]> The members of the measured-component CBOR map / JSON object are:

"id" (index 1):

The measured component identifier encoded according to the format described in .

"measurement":

Either a digest value and algorithm (index 2), encoded using CoRIM digest format (), or the "raw" measurement (index 5), encoded as a byte string.

"signers" (index 3):

One or more signing entities, see .

"flags" (index 4):

a 64-bit field with profile-defined semantics, see .

Component Identifier The component-id data item is as follows:

name

A string that provides a human readable identifier for the component in question. Format and adopted conventions depend on the component type.

version

A compound version data item that reuses encoding and semantics of sw-version-type.

Signer A signer is an entity that digitally signed the measured component. Typically, the signature is verified during installation or when the measured component is executed by the boot ROM, operating system, or application launcher. For example, as in UEFI Secure Boot and Arm Trusted Board Boot . Another example may be the controlling entity in an app store. It is important to note that a signer is different from the identity of the manufacturer of the component, such as would be found in a manifest like a payload CoSWID. A signer is associated with a public key. It could be an X.509 certificate, a raw public key, a public key thumbprint, or some other identifier that can be uniquely associated with the signing entity. In some cases, multiple parties may need to sign a component to indicate their endorsement or approval. This could include roles such as a firmware update system, fleet owner, or third-party auditor. The specific purpose of each signature may depend on the deployment, and the order of signers within the array could indicate meaning. If an EAT profile () uses measured components, it MUST specify whether the signers field is used. If it is used, the profile MUST also specify what each of the entries in the signers array represents, and how to interpret the corresponding signer-type. The signer-type is defined as follows: ]]>

Profile-specific Flags This field contains at most 64-bit of profile-defined semantics. It can be used to carry information in fixed-size chunks, such as a bit mask or a single value within a predetermined set of codepoints. Regardless of its internal structure, the size of this optional field is exactly 8 bytes. The flags-type is defined as follows: ]]> If an EAT profile () uses measured components, it MUST specify whether the profile-flags field is used. If it is used, the profile MUST also specify how to interpret the 64 bits.

EAT measurements-format Extensions The CDDL in extends the $measurements-body-cbor and $measurements-body-json EAT sockets to add support for measured-components to the Measurements claim.

EAT measurements-format Extensions

Each socket is extended with two new types: a "native" representation that is used when measured-component and the EAT have the same serialization (e.g., they are both CBOR), and a "tunnel" representation that is used when the serializations differ.

measurements-format for CBOR EAT The entries in are the allowed content-type / content-format pairs when the measured-component is carried in a CBOR EAT. Note the use of the "native" and "tunnel" formats from , and how the associated CoAP Content-Format is used to describe the original serialization. measurement-format for EAT CWT

content-type (CoAP C-F equivalent)	content-format
application/measured-component+cbor	mc-cbor
application/measured-component+json	mc-json

measurements-format for JSON EAT is the equivalent of for JSON-serialized EAT. measurement-format for EAT JWT

content-type (CoAP C-F equivalent)	content-format
application/measured-component+json	mc-json
application/measured-component+cbor	tstr .b64u mc-cbor

EAT Profiles and Measured Components The semantics of the signers and profile flags fields are defined by the applicable EAT profile, i.e., the profile of the wrapping EAT. If the profile of the EAT is not known to the consumer and one or more Measured Components within that EAT include signers and/or profile flags, the consumer MUST reject the EAT.

Examples The example in is a digested measured component with all the fields populated.

Complete Measured Component

The example in is the same measured component as above but used as the format of a measurements claim in a EAT claims-set. The example uses TBD1 as the content-type value of the measurements-format entry. (This will change to the value assigned by IANA to the mc+cbor Content-Format.) Note that the array contains only one measured component, but additional entries could be added if the measured TCB is made of multiple, individually measured components.

EAT Measurements Claim using a Measured Component (CBOR) > ] ] } ]]>

The example in illustrates the inclusion of a JSON measured component inside a JSON EAT. The example uses TBD2 as the content-type value of the measurements-format entry. (This will change to the value assigned by IANA to the mc+json Content-Format.)

EAT Measurements Claim using a Measured Component (JSON)

The example in is a measured component representing a boot loader identified by its path name:

Digested Measured Component using File Path as Identifier

The example in is a raw measured component.

Raw Measured Component

Security and Privacy Considerations The Name and Version of a component can give an attacker detailed information about the software running on a device and its configuration settings. This information could offer an attacker valuable insights. Additionally, the stability requirement of the component's Name could potentially allow for tracking.

IANA Considerations RFC Editor: replace "RFCthis" with the RFC number assigned to this document.

Media Types Registrations IANA is requested to add the following media types to the "Media Types" registry . Measured Component Media Types

Name	Template	Reference
mc+cbor	application/measured-component+cbor	RFCthis
mc+json	application/measured-component+json	RFCthis

application/measured-component+cbor

Type name:

application

Subtype name:

measured-component+cbor

Required parameters:

n/a

Optional parameters:

n/a

Encoding considerations:

binary (CBOR)

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Attesters, Verifiers and Relying Parties

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/cbor". (No fragment identification syntax is currently defined for "application/cbor".)

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

application/measured-component+json

Type name:

application

Subtype name:

measured-component+json

Required parameters:

n/a

Optional parameters:

n/a

Encoding considerations:

binary (JSON is UTF-8-encoded text)

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Attesters, Verifiers and Relying Parties

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/json". (No fragment identification syntax is currently defined for "application/json".)

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

Measured Component Content-Format Registrations IANA is requested to register two Content-Format numbers in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry , as follows:

Content-Type	Content Coding	ID	Reference
application/measured-component+cbor	-	TBD1	RFCthis
application/measured-component+json	-	TBD2	RFCthis

If possible, TBD1 and TBD2 should be assigned in the 256..9999 range.

References Normative References The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. 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 Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed:.plus,.cat, and.det for the construction of constants;.abnf/.abnfb for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and.feature for indicating the use of a non-basic feature in an instance. Universität Bremen TZI Arm Limited At the time of writing, the Concise Data Definition Language (CDDL) is defined by RFC 8610 and RFC 9682 as well as RFC 9165 and RFC 9741. The latter two have used the extension point provided in RFC 8610, the _control operator_. As CDDL is being used in larger projects, the need for features has become known that cannot be easily mapped into this single extension point. The present document defines a backward- and forward-compatible way to add a module structure to CDDL. Universität Bremen TZI The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension point both in an application-specific and a more general way. The present document defines a number of additional generally applicable control operators for text conversion (Bytes, Integers, JSON, Printf-style formatting) and for an operation on text. 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. 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. 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. IANA IANA Informative References Arm Limited Arm Limited HP Labs Linaro The Arm Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, as well as open-source reference implementations, to help device makers and chip manufacturers build best-practice security into products. Devices that are PSA compliant can produce attestation tokens as described in this memo, which are the basis for many different protocols, including secure provisioning and network access control. This document specifies the PSA attestation token structure and semantics. The PSA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by PSA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected. This informational document is published as an independent submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF. ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. UEFI Forum, Inc. Arm Ltd

Open Issues The list of currently open issues for this documents can be found at . Note to RFC Editor: please remove before publication.

Acknowledgments The authors would like to thank Carl Wallace, Carsten Bormann, Dionna Glaze, Giridhar Mandyam, Laurence Lundblade and Michael Richardson for providing comments, reviews and suggestions that greatly improved this document.