Remote attestation over EDHOC

Remote attestation over EDHOC Inria

yuxuan.song@inria.fr

Security Lightweight Authenticated Key Exchange Internet-Draft This document specifies how to perform remote attestation as part of the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote ATtestation procedureS (RATS) architecture. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Lightweight Authenticated Key Exchange Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Remote attestation is a security process which verifies and confirms the integrity and trustworthiness of a remote device or system in the network. This process helps establish a level of trust in the remote system before allowing the device to e.g. join the network or access some sensitive information and resources. The use cases that require remote attestation include secure boot and firmware management, cloud computing, network access control, etc. The IETF working group Remote ATtestation procedureS (RATS) has defined an architecture for remote attestation. The three main roles in the RATS architecture are the Attester, the Verifier and the Relying Party. The Attester generates the evidence concerning its identity and integrity, which must be appraised by the Verifier for its validity. Then, the Verifier produces the attestation result, which is consequently used by the Relying Party for the purposes of reliably applying application-specific actions. One type of interaction model defined in the RATS architecture is called the background-check model. It resembles the procedure of how employers perform background checks to determine the prospective employee's trustworthiness, by contacting the respective organization that issues a report. In this case, the employer acts as the Relying Party, the employee acts as the Attester and the organization acts as the Verifier. The Attester conveys evidence directly to the Relying Party and the Relying Party forwards the evidence to the Verifier for appraisal. Once the attestation result is computed by the Verifier, it is sent back to the Relying Party to decide what action to take based on the attestation result. This specification employs the RATS background check model. One way of conveying attestation evidence is the Entity Attestation Token (EAT) . It provides an attested claims set that describes the state and the characteristics of the Attester, which can be used to determine its level of trustworthiness. This specification relies on the EAT as the attestation evidence. Ephemeral Diffie-Hellman over COSE (EDHOC) is a lightweight authenticated key exchange protocol for highly constrained networks. In EDHOC, the two parties involved in the key exchange are referred to as the Initiator (I) and the Responder (R). EDHOC supports the transport of external authorization data, through the dedicated EAD fields. This specification delivers EAT through EDHOC. Specifically, EAT is transported as an EAD item. Typically, the Attester incorporates an internal attestation service, including a specific trusted element known as the "root of trust". Root of trust serves as the starting point for establishing and validating the trustworthiness appraisals of other components on the system. The measurements signed by the attestation service are referred to as the Evidence. The signing is requested through an attestation API. How the components are separated between the secure and non-secure worlds on a device is out of scope of this specification.

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. The reader is assumed to be familiar with the terms and concepts defined in EDHOC and RATS .

Problem Description This specification describes how to perform remote attestation over the EDHOC protocol according to the RATS architecture. Remote attestation protocol elements are carried within EDHOC's External Authorization Data (EAD) fields. More specifically, this specification supports the RATS background check model. It describes how the Attester (EDHOC Initiator) and Relying Party (EDHOC Responder) complete the EDHOC handshake complemented with remote attestation protocol elements.

Assumptions The details of the protocol between Relying Party and Verifier are out of the scope. The only assumption is that the Verifier outputs a fresh nonce and that same nonce is passed on to the EDHOC session. That is where the link between the two protocols comes in. The remainder, such as the evidence type selection is just the negotiation. In general, the Verifier is supposed to know how to verify more than one format of the evidence type. Therefore, the Verifier MUST send back at least one format to the Relying Party. We assume in this specification, the Relying Party also has knowledge about the Attester, so it can narrow down the type selection and send to the Attester only one format of evidnece type. The Attester should have an explicit relation with the Verifier, such as from device manufacuture, so that the Verifier can evaluate the Evidence that is produced by the Attester. The authentication between the Attester and the Relying Party is performed with EDHOC and defines the process of remote attestation using the External Authorization Data (EAD) fields defined in EDHOC.

The Protocol

Overview EDHOC Initiator plays the role of the RATS Attester. EDHOC Responder plays the role of the RATS Relying Party. An external entity, out of scope of this specification, plays the role of the RATS Verifier.

External Authorization Data 1 In EAD_1, the Attester transports the Proposed_EvidenceType object. It signals to the Relying Party the proposal to do remote attestation, as well as which attestation claims the Attester supports. The supported attestation claims are encoded in CBOR in the form of a sequence. The external authorization data EAD_1 contains an EAD item with

ead_label = TBD1
ead_value = Attestation_proposal, which is a CBOR byte string:

where

content-format is an array that contains all the supported evidence types by the Attester in decreasing order of preference.
There MUST be at least one item in the array.
content-format is an indicator of the format type (e.g., application/eat+cwt with an appropriate eat_profile parameter set).

The sign of ead_label MUST be negative to indicate that the EAT item is critical. If the receiver cannot recognize the critical EAD item, or cannot process the information in the critical EAD item, then the receiver MUST send an EDHOC error message back.

External Authorization Data 2 In EAD_2, the Relying Party signals to the Attester the supported and requested evidence types. In case none of the evidence types is supported, the Relying Party rejects the first message_1 with an error indicating support for another evidence type. EAD_2 carries the Selected_EvidenceType object. Similarly to EAD_1, Selected_EvidenceType object is encoded in CBOR. The external authorization data EAD_2 contains an EAD item with

ead_label = TBD2
ead_value = Attestation_request, which is a CBOR byte string:

where

content-format is the selected evidence type by the Relying Party and supported by the Verifier.
nonce is generated by the Verifier and forwarded by the Relying Party.

External Authorization Data 3 As a response to the attestation request, the Attester calls its local attestation service to generate and return the serialized EAT as Evidence. The external authorization data EAD_3 contains an EAD item with

ead_label = TBD3
ead_value is a serialized EAT.

Security Considerations TODO: Security considerations

IANA Considerations

EDHOC External Authorization Data Registry IANA is requested to register the following entry in the "EDHOC External Authorization Data" registry under the group name "Ephemeral Diffie-Hellman Over Cose (EDHOC)". The ead_label = TBD1 corresponds to the ead_value Attestation_proposal in EAD_1 with processing specified in . The ead_label = TBD2 corresponds to the ead_value Attestation_request in . The ead_label = TBD3 corresponds to the ead_value which carries the EAT, as specified in . Addition to the EDHOC EAD registry

Label	Value Type	Description
TBD1	bstr	Attestation Proposal
TBD2	bstr	Attestation Request
TBD3	bstr	Evidence for remote attestation

References Normative References Ephemeral Diffie-Hellman Over COSE (EDHOC) Ericsson AB Ericsson AB Ericsson AB This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios and a main use case is to establish an OSCORE security context. By reusing COSE for cryptography, CBOR for encoding, and CoAP for transport, the additional code size can be kept very low. The Entity Attestation Token (EAT) Security Theory LLC 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. Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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 Remote ATtestation procedureS (RATS) Architecture 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. Concise Binary Object Representation (CBOR) 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. CBOR Web Token (CWT) CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. CBOR Web Token (CWT) Claims IANA Arm's Platform Security Architecture (PSA) Attestation Token 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. CoAP Content-Formats n.d.

Example: Remote Attestation Flow | | | | | | | | | | | | | | | | | | +------------------>| | | | | | | | | | | | | | | | | | Body: { | | | | | | nonce, | | | | | EDHOC message_2 | types(a,b) | | | | | {...} | } | | | | | EAD_2( |<------------------+ | | | | nonce, | | | | | | type(a) | | | | | | ) | | | | | | Auth_CRED(Sig/MAC) | | | | | |<-----------------------+ | | | | Body:{ | | | | | | nonce, | | | | | | type(a) | | | | | | } | | | | | |<---------------+ | | | | | Body:{ | | | | | | nonce, | | | | | | Evidence | | | | | | } | | | | | +--------------->| | | | | | | EDHOC message_3 | | | | | | {...} | | | | | | EAT(nonce,Evidence) | | | | | | Auth_CRED(sig/MAC) | | | | | +----------------------->| | | | | | | | | '--+----------------+------------------------+-------------------+----' | | | | | | | Body: { | | | | EAT} | | | +------------------>| | | | Body: { | | | | att-result: AR{} | | | | } | | | |<------------------+ | | +---. | | | | | verify AR{} | | | |<--' | | | | | | | | | '----------------+------------------------+-------------------' | application data | |<---------------------->| | | ]]> {: #figure-iot-example title="Example of remote attestation."

Example: Firmware Version The goal in this example is to verify that the firmware running on the device is the latest version, and is neither tampered or compromised. A device acts as the Attester, currently in an untrusted state. The Attester needs to generate the Evidence to attest itself. A gateway that can communicate with the Attester and can control its access to the network acts as the Relying Party. The gateway will finally decide whether the device can join the network or not depending on the Attestation Result. The Attestation Result is produced by the Verifier, which is a web server that can be seen as the manufacturer of the device. Therefore it can appraise the Evidence that is sent by the Attester. The remote attestation session starts with the Attester sending EAD_1 in EDHOC message 1, as specified in . In EAD_1 field, the Attester indicates that the format of EAT is in CWT and the profile of EAT is Platform Security Architecture (PSA) attestation token . PSA attestation token contains the claims relating to the security state of the platform, which are provided by PSA's Initial Attestation API. Therefore, the EAD_1 in EDHOC message_1 is: According to , IANA is requested to register the Content-Format ID in the "CoAP Content-Formats" registry , for the application/eat+cwt media type with the eat_profile parameter equal to tag:psacertified.org,2023:psa#tfm. The Media Type equivalent is: If the Verifier and the Relying Party can support this evidence type that is proposed by the Attester, the Relying Party will include in the EAD_2 field the same evidence type, alongside a nonce for message freshness. The Evidence in EAD_3 field is the Platform Security Architecture (PSA) attestation token, which is the attestation of the platform state to assure the firmware integrity. This can be generated from Measured boot, which creates the measurements of loaded code and data during the boot process and make them part of an overall chain of trust. Each stage of the chain of trust stores the measurements in a local root of trust, then the Root of Trust for Report (RTR) of the device can use them as materials to generate the Evidence. The components of the Evidence should at least be: The Relying Party (co-located with the gateway) then treats the Evidence as opaque and sends it to the Verifier. Once the Verifier sends back the Attestation Result, the Relying Party can be assured on the version of the firmware that the device is running.

Acknowledgments The author would like to thank Thomas Fossati, Goran Selander, and Malisa Vucinic for the provided feedback.