]> arm

mathias.brossard@arm.com

Linaro

thomas.fossati@linaro.org

hannes.tschofenig@gmx.net

henk.birkholz@ietf.contact

ionut.mihalcea@arm.com

Security Remote ATtestation ProcedureS evidence key attestation TLS This document defines an evidence format for key attestation based on the Entity Attestation Token (EAT). 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 This document defines an evidence format for key attestation based on EAT .

Terminology The following terms are used in this document:

Root of Trust (RoT):

A set of software and/or hardware components that need to be trusted to act as a security foundation required for accomplishing the security goals of a system. In our case, the RoT is expected to offer the functionality for attesting to the state of the platform, and indirectly also to attest the integrity of the IK (public as well as private key) and the confidentiality of the IK private key.

Attestation Key (AK):

Cryptographic key belonging to the RoT that is only used to sign attestation tokens.

Platform Attestation Key (PAK):

An AK used specifically for signing attestation tokens relating to the state of the platform.

Key Attestation:

Evidence containing properties of the environment(s) in which the private keys are stored. For example, a Relying Party may want to know whether a private key is stored in a hardware security module and cannot be exported in unencrypted fashion.

Key Attestation Key (KAK):

An AK used specifically for signing KATs. In some systems only a single AK is used. In that case the AK is used as a PAK and a KAK.

Identity Key (IK):

The IK consists of a private and a public key. The private key is used by the usage protocol. The public key is included in the Key Attestation Token. The IK is protected by the RoT.

Usage Protocol:

A (security) protocol that requires demonstrating possession of the private IK.

Attestation Token (AT):

A collection of claims that a RoT assembles (and signs) with the purpose of informing - in a verifiable way - relying parties about the identity and state of the platform. Essentially a type of Evidence as per the RATS architecture terminology .

Platform Attestation Token (PAT):

An AT containing claims relating to the security state of the platform, including software constituting the platform trusted computing base (TCB). The process of generating a PAT typically involves gathering data during measured boot.

Key Attestation Token (KAT):

An AT containing a claim with a public key. The KAT may also contain other claims, such as those indicating its validity. The KAT is signed by the KAK. The key attestation service, which is part of the platform root of trust (RoT), conceptually acts as a local certification authority since the KAT behaves like a certificate.

Combined Attestation Bundle (CAB):

A structure used to bundle a KAT and a PAT together for transport in the usage protocol. If the KAT already includes a PAT, in form of a nested token, then it already corresponds to a CAB. A CAB is equivalent to a certificate that binds the identity of the platform's TCB with the IK public key.

Presenter:

Party that proves possession of a private key to a recipient of a KAT.

Recipient:

Party that receives the KAT containing the proof-of-possession key information from the presenter.

Key Attestation Service (KAS):

The issuer that creates the KAT and bundles a KAT together with a PAT in a CAB.

The reader is assumed to be familiar with the vocabulary and concepts defined in . CDDL is used to describe the data formats and the examples in use CBOR diagnostic notation defined in and . 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.

Architecture Key attestation is an extension to the attestation functionality described in . We describe this conceptually by splitting the internals of the attester into two parts, platform attestation and key attestation. This is shown in . These are logical roles and implementations may combine them into a single physical entity. Security-sensitive functionality, like attestation, has to be placed into the trusted computing base. Since the trusted computing base itself may support different isolation layers, the design allows platform attestation to be separated from key attestation whereby platform attestation requires more privilege than the key attestation code. Cryptographic services, used by key attestation and by platform attestation, are separated although not shown in the figure. The protocol used for communication between the Presenter and the Recipient is referred as usage protocol. The usage protocol, which is outside the scope of this specification, needs to support proof-of-possession of the private key (explained further below). An example usage protocol is TLS with the extension defined in .

Architecture | Recipient | | | | | '-----------------' '-----------------' ]]>

The Presenter triggers the generation of the IK. The IK consists of a public key (pIK) and a private key (sIK). The Presenter may, for example, use the following API call to trigger the generation of the key pair for a given algorithm and to obtain a key handle (key_id). The private key is created and stored such that it is only accessible to the KAS rather than to the Presenter. Next, the KAS needs to trigger the creation of the Platform Attestation Token (PAT) by the Platform Attestation Service. The PAT needs to be linked to the Key Attestation Token (KAT) and this linkage can occur in a number of ways. One approach is described in this specification in . The Key Attestation Token (KAT) includes the public key of the IK (pIK) and is then signed with the Key Attestation Key (KAK). To ensure freshness of the PAT and the KAT a nonce is used, as suggested by the RATS architecture . Here is the symbolic API call to request a KAT and a PAT, which are concatenated together as the CAB. Once the CAB has been sent by the Presenter to the Recipient, the Presenter has to demonstrate possession of the private key. The signature operation uses the private key of the IK (sIK). How this proof-of-possession of the private key is accomplished depends on the details of the usage protocol and is outside the scope of this specification. The Recipient of the CAB and the proof-of-possession data (such as a digital signature) first extracts the PAT and the KAT. The PAT and the KAT may need to be conveyed to a Verifier. If the PAT is in the form of attestation results the checks can be performed locally at the Recipient, whereby the following checks are made:

• The signature protecting the PAT MUST pass verification when using available trust anchor(s).
• The chaining of PAT and KAT MUST be verified. The detailed verification procedure depends on the chaining mechanism utilized.
• The claims in the PAT MUST be matched against stored reference values.
• The signature protecting the KAT MUST pass verification.
• The KAT MUST be checked for replays using the nonce included in the KAT definition (see ).

Once all these steps are completed, the verifier produces the attestation result and includes (if needed) the IK public key (pIK).

Key Attestation Token Format

Proof-of-Possession The KAT utilizes the proof-of-possession functionality defined in to encode the public key of the IK (pIK).

KAT Definition bstr .size (8..64) &(cnf: 8) => ak-pub &(kak-pub: 2500) => COSE_Key } ak-pub = cnf-map cnf-map = { &(cose-key: 1) => COSE_Key } ]]>

The claims in the KAT are as follows:

• eat_nonce: challenge from the relying party
• cnf: the key confirmation of the pIK, encoded as COSE_Key
• kak-pub: the public part of the KAK (used for verification of the KAT), encoded as COSE_Key

Platform Attestation Token Format There are no strict requirements regarding the composition of the platform attestation token's claims-set, except for the presence of the eat_nonce claim used for binding (). An example of PAT could be the PSA Token .

KAT-PAT Bundle The KAT and PAT tokens are combined in a CMW "collection" as shown in .

KAT Bundle Definition ] "pat": [ "application/eat+cwt", bytes .cbor cose_sign1 ] "__cmwc_t": "tag:ietf.org,2024-02-29:rats/kat" } ]]>

KAT-PAT linkage KAT and PAT are a form of layered attestation (). For the scheme to be secure, it is crucial that their linkage is captured in their combined wire image. The way this is achieved is by hashing the CBOR-encoded COSE_Key corresponding to the KAK (i.e., the kak-pub claim in the KAT) and using it to populate the eat_nonce claim in the PAT. The signature on the PAT seals the image of the used KAK and therefore the linkage between the two layers.

Examples

KAT

Minimal PAT

CMW Collection combining KAT and PAT >, / signature / h'56F50D131FA83979AE064E76E70DC75C070B6D991A EC08ADF9F41CAB7F1B7E2C47F67DACA8BB49E3119B7BAE77AEC6C89162713E0C C6D0E7327831E67F32841A' ] >> ], "pat": [ "application/eat+cwt", << [ / protected / h'A10126', / unprotected / {}, / payload (PAT Claims-Set) / << { / eat_nonce / 10: h'5CA3750DAF829C30C20797EDDB7949B1FD028C 5408F2DD8650AD732327E3FB64' / further platform specific claims / } >>, / signature / h'F9F41CAB7F1B7E2C47F67DACA8BB49E3119B7BAE77AE C6C89162713E0CC6D0E7327831E67F32841A56F50D131FA83979AE064E76E70D C75C070B6D991AEC08AD' ] >> ], "__cmwc_t": "tag:ietf.org,2024-02-29:rats/kat" } ]]>

Security Considerations

Semantics of Key Attestation The semantics of the KAT, i.e. what exact properties are attested, is highly implementation dependent. At the very least, the platform MUST NOT sign the KAT unless the IK's private key is generated by the Trusted Computing Base and is never exported in the clear. The Identity Key, when it is ephemeral, is used to secure specific protocol sessions. However in general, protocol security depends on much more than the key's security. A vulnerable protocol stack (e.g. an insecure TLS library) may leak sensitive network traffic or may not protect its integrity. As a result, the Verifier's policy must take system-level security considerations into account when deciding whether or not to accept the CAB for a particular use case. In pratice this means that in order to trust the Attester, the Verifier must have some knowledge about its internal architecture and the security threats it is subject to.

IANA Considerations TODO IANA

References Normative References 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 Independent Linaro University of Applied Sciences Bonn-Rhein-Sieg Google LLC The Conceptual Messages introduced by the RATS Architecture (RFC9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. By introducing a shared message format like the CMW, we can consistently support different attestation message types, evolve message serialization formats without breaking compatibility, and avoid having to redefine how messages are handled in each protocol. 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. This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). 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. 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. 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. 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 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. 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. Intuit Arm Limited Arm Limited Arm Limited Huawei Linaro The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using attestation which is a process by which an entity produces evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of protocol extensions to the TLS 1.3 handshake that enables the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and mutually.

Amalgamated CDDL ] "pat": [ "application/eat+cwt", bytes .cbor cose_sign1 ] "__cmwc_t": "tag:ietf.org,2024-02-29:rats/kat" } ;# import rfc9052 kat = { &(eat_nonce: 10) => bstr .size (8..64) &(cnf: 8) => ak-pub &(kak-pub: 2500) => COSE_Key } ak-pub = cnf-map cnf-map = { &(cose-key: 1) => COSE_Key } pat = { &(eat_nonce: 10) => bstr .size (8..64) * (int / text) => any } cose_sign1 = [ Headers payload: bytes .cbor C signature: bytes ] ]]>

Acknowledgments Yaron Sheffer.

Contributors arm