Remote attestation over EDHOC

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 24 April 2025.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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 get access to 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 [RFC9334] 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. Another model is called passport model, where the Attester communicates directly with the Verifier. The Attester presents the evidence to the Verifier and gets an attestation result from the Verifier. Then the Attester conveys the attestation result to the Relying Party. This specification employs both the RATS background-check model and the passport model.¶

This document specifies the protocol between the Attester and the Relying Party. The details of the protocol between the Relying Party and the Verifier in the background-check model, and the protocol between the Attester and the Verifier in the passport model are out of the scope. This communication may be secured through protocols such as EDHOC, TLS or other security protocols that support the secure transmission to and from the Verifier.¶

One way of conveying attestation evidence or the attestation result is the Entity Attestation Token (EAT) [I-D.ietf-rats-eat]. It provides an attested claims set which can be used to determine a level of trustworthiness. This specification relies on the EAT as the format for attestation evidence and the attestation result.¶

Ephemeral Diffie-Hellman over COSE (EDHOC) [RFC9528] 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. This specification also defines new EAD items needed to perform remote attesation over EDHOC in Section 5.2.1.1 and Section 5.2.2.1.¶

For the generation of evidence, 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.¶

2. 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 [RFC2119] [RFC8174] 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 [RFC9528] and RATS architecture [RFC9334].¶

3. Overview

This specification describes how to perform remote attestation over the EDHOC protocol, following the RATS architecture. EDHOC provides the benefit of minimal message overhead and reduced round trips for a lightweight authentication. More importantly, by integrating remote attestation with EDHOC, attestation can be run in parallel with authentication, improving the efficiency and maintaining lightweight properties.¶

Remote attestation protocol elements are carried within EDHOC's External Authorization Data (EAD) fields. EDHOC [RFC9528] supports one or more EAD items in each EAD field.¶

In Section 5, this document defines three independent dimensions for performing remote attestation over EDHOC:¶

1. Target (see Section 5.1) defining the entity that undergoes the attestation process (IoT device or network service).¶

2. Model (see Section 5.2) defining the attestation model in use based on the RATS architecture (background-check model or passport model).¶

3. Message Flow (see Section 5.3) defining the EDHOC message flow in use (forward message flow or reverse message flow).¶

This document specifies the cases that are suited for constrained IoT environments.¶

EDITOR NOTE: add an overview figure¶

4. Assumptions

In background-check model, one assumption is that the Verifier outputs a fresh nonce and that same nonce is passed on to the EDHOC session. The Verifier is assumed to know how to verify multiple formats of the evidence type. This specification assumes that the Relying Party also has knowledge about the Attester, so it can narrow down the evidence type selection and send to the Attester only one format of the evidence type. The Attester should have an explicit relation with the Verifier, such as from device manufacturing, so that the Verifier can evaluate the Evidence that is produced by the Attester.¶

In the passport model, the credential identity of the Verifier is assumed to be stored at the Attester and the Relying Party, which means the Verifier is trusted by the Attester and the Relying Party to obtain the attestation result.¶

EDITOR NOTE: add attestation public key stored in Verifier¶

5. Remote Attestation in EDHOC

This section specifies three independent dimensions that characterize the remote attestation process over EDHOC.¶

Attestation_proposal = bstr .cbor Proposed_EvidenceType

Proposed_EvidenceType = [ + content-format ]

content-format = uint

Attestation_request = bstr .cbor Selected_EvidenceType

Selected_EvidenceType = (
  content-format: uint,
  nonce: bstr .size 8..64
)

Result_proposal = bstr .cbor Proposed_VerifierIdentity
Proposed_VerifierIdentity = [ + VerifierIdentity ]

VerifierIdentity = {
  label => values
}

Result_request = bstr .cbor Request_structure

Request_structure = {
  selected_verifier: VerfierIdentity
}

6. Instantiation of Remote Attestation Protocol

We use the format (Target, Model, Message Flow) to denote instantiations. For example, (IoT, BG, Fwd) represents IoT device attestation using the background-check model with forward EDHOC message flow.¶

Although there are 8 cases (IoT/Net, BG/PP, Fwd/Rev), this document specifies the most relevant instantiations for constrained IoT environments.¶

7. Mutual Attestation in EDHOC

Mutual attestation over EDHOC combines the cases where one of the EDHOC parties uses the IoT device attestation and the other uses the Network service attestation. Performing mutual attestation to a single EDHOC message flow acheives a lightweight use with reduced message overhead. Note that the message flow for the two parties in mutual attestation needs to be the same.¶

In this specification, we list the most relevant mutual attestation example for constrained IoT environments.¶

8. Error Handling

This section specifies a new EDHOC error code and how it is used in the proposed protocol.¶

9. Security Considerations

This specification is performed over EDHOC [RFC9528] by using EDHOC's EAD fields. The privacy considerations of EADs in EDHOC apply to this specification.¶

EAD_1 is not resistant to either active attackers or passive attackers, because neither the Initiator nor the Responder has been authenticated.¶

Although EAD_2 is encrypted, the Initiator has not been authenticated, rendering EAD_2 vulnerable against the active attackers.¶

The ead items in EAD_1 and EAD_2 MAY be very specific and potentially reveal sensitive information about the device. The leaking of the data in EAD_1 and/or EAD_2 MAY risk to be used by the attackers for malicious purposes. Data in EAD_3 and EAD_4 are protected between the Initiator and the Responder in EDHOC.¶

Mutual attestation carries a lower risk for EAD items when the Responder is the Attester. For the mutual attestation at the EDHOC Responder, only the Attestation_proposal/Result_proposal in EAD_2 is not protected to active attackers. Both the Attestation_request/Result_request in EAD_3 and the Evidence/Result in EAD_4 are protected.¶

10. IANA Considerations

11. References

Appendix A. Example: Remote Attestation Flow

Appendix B. Remote attestation in parallel with enrollment authorization

This section discusses the possibility of doing remote attestation in parallel with the enrollment authorization procedure defined in [I-D.ietf-lake-authz]. In this case, the message count is much decreased.¶

The detailed procedure is TBD.¶

Appendix C. 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.¶

An example of the EAD_1 in EDHOC message_1 could be:¶

[60,61,258]

If the Verifier and the Relying Party can support at least one 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.¶

(258, h'a29f62a4c6cdaae5')

The Evidence in EAD_3 field is an Entity Attestation Token (EAT) [I-D.ietf-rats-eat], with the measurements claim formatted in CoSWID[RFC9393]. The components of the Evidence should at least be:¶

{
/eat-nonce/                 10: h'a29f62a4c6cdaae5',
/ueid/                      256: 'aaabbcc',
/measurements/              273: [
  /CoAP Content-Format ID/        [ 258,
  /evidence in CoSWID/              {
                                      0: 'tagID'             /tag-id/
                                      12: 0                  /tag-version/
                                      1: "DotBot firmware"   /software-name/
                                      2: {                   /entity/
                                          31: "Attester"     /entity-name/
                                          33: 1              /role, must be "tag-creator" which is 1/
                                          },
                                      3: {                   /evidence/
                                          17: [              /file/
                                               {
                                                24: "partition0-nrf52840dk.bin",   /fs-name/
                                                7: [                               /hash of file/
                                                    1,                             /alg SHA-256/
                                                    h'06294f6806b9c685eea795048579cfd02a0c025bc8b5abca42a19ea0ec23e81a'
                                                    ]                              /hash value/
                                                }
                                               ]
                                          }
                                    }
                                  ]
                                 ]
}

The infomation above serves as the payload of the COSE object. The complete resulting COSE object is:¶

18([
    /*protected header*/
    h'a10127',

    /*unprotected header*/
    {},

    /*payload*/
    h'A30A48A29F62A4C6CDAAE519010047616161626263631901118182190102A50045746
    16749440C00016F446F74426F74206669726D7761726502A2181F684174746573746572
    18210103A11181A218187819706172746974696F6E302D6E72663532383430646B2E626
    96E078201582006294F6806B9C685EEA795048579CFD02A0C025BC8B5ABCA42A19EA0EC
    23E81A',

    /*signature*/
    h'd4100901f4c3e51312c3110c6ddc8dcf7f68d8f5d3791c19133f2f0ac158c1f5ee6ed
    afe9d7c3d6eb3d2d197f82e733d375fdda9fb258b304961dfc38558950d'
])

which has the following base16 encoding:¶

D28443A10127A05890A30A48A29F62A4C6CDAAE51901004761616162626363190111818
2190102A5004574616749440C00016F446F74426F74206669726D7761726502A2181F68
417474657374657218210103A11181A218187819706172746974696F6E302D6E7266353
2383430646B2E62696E078201582006294F6806B9C685EEA795048579CFD02A0C025BC8
B5ABCA42A19EA0EC23E81A5840D4100901F4C3E51312C3110C6DDC8DCF7F68D8F5D3791
C19133F2F0AC158C1F5EE6EDAFE9D7C3D6EB3D2D197F82E733D375FDDA9FB258B304961
DFC38558950D

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.¶

Appendix D. Open discussion: remote attestation over EDHOC/ over OSCORE

TBD¶

Acknowledgments

The author would like to thank Thomas Fossati, Goran Selander, Malisa Vucinic, Ionut Mihalcea, Muhammad Usama Sardar, Michael Richardson and Geovane Fedrecheski for the provided ideas and feedback.¶

Author's Address