]> TU Dresden

muhammad_usama.sardar@tu-dresden.de

Stevens Institute of Technology

New York USA bluedognull@gmail.com

Independent

aurestarnull@gmail.com

Shanghai Guan An Information Technology Co., Ltd.

China havan12050544@gmail.com

RATS Working Group security considerations remote attestation This document aims to provide guidelines and best practices for writing security considerations for technical specifications for RATS targeting the needs of implementers, researchers, and protocol designers. In particular, it discusses some of the 'bottom turtle' issues. This is a work-in-progress, and the current version mainly presents an outline of the general security guidelines, baseline, or template for RATS that future versions will cover in more detail. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction

Need for Specialized Guidance in RATS Every Internet Draft needs to have a "Security Considerations" section. While general guidelines such as exist, the underlying threat model is that the endpoint is fully trusted (i.e., all software and hardware components in the device may access the keys). RATS has a primarily different threat model in the sense that only parts of the endpoint (called Attester) are trusted (i.e., only specific software and hardware components in the device may access the keys), and the goal is to establish the trustworthiness of the endpoint. In other words, deals with a network adversary, whereas RATS deals with an endpoint adversary, which may have root access or physical control over the device with which it can extract keys from software or hardware. Moreover, remote attestation has several distinguishing features that necessitate a separate document. One specific example of such a feature is the architectural complexity of the endpoint. While network protocols typically have 2 roles, RATS has additional roles, which complicates the picture. Unfortunately, no guidelines currently exist for remote attestation in RATS. This document aims to fill this gap.

Needs of the Target Audience of RATS Moreover, while the target audience of Internet Drafts is implementers, researchers, and protocol designers , RATS drafts generally do not fulfill these needs, in particular the needs of researchers and protocol designers. On the other hand, in our observation, implementers generally find it hard to relate the abstract concepts of RATS to the real-world systems. In general, implementers and protocol designers of RATS are thus left with little or no guidance.

Motivation Unverified protocol designs, imprecisely stated threat model and security goals have led to high and critical severity vulnerabilities related to remote attestation.

Concrete Motivational Example: Practical Exploits in Production Systems The formal analysis led to three orthogonal issues:

• Formal analysis found diversion attacks when unique hardware identifier is not included in Evidence. For technical details, please see the corresponding paper .
• Formal analysis of several production implementations of remote attestation led to the discovery of of CVSS 7.5 for relay attacks. For technical details, please see the corresponding paper .
• Further formal analysis of production implementation of remote attestation has led to discovery of another class of attacks and will potentially lead to three CVEs (currently under responsible disclosure) each with an expected CVSS 9.1.

This shows the value of precise threat model and formal analysis in the design of secure protocols to find subtle vulnerabilities, which could otherwise be missed. This draft aims to provide the baseline security considerations that other drafts can simply refer to.

Scope To improve the situation, this draft presents general security baseline that other drafts can simply point to, or guidelines or template that other drafts can use.

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.

General Hierarchy of Authentication Authentication is a term which is often ambiguous in RATS specifications. We propose general hierarchy of one-way authentication, which can help precisely state the intended level of authentication (in decreasing order):

• One-way injective agreement
• One-way non-injective agreement
• Aliveness

Recentness can be added to each of these levels of authentication. Details will be added in future versions.

Threat Modeling This section describes "What can go wrong?"

System Model See Section 4 of as an example.

Actors It has both legal and technical perspective.

Legal perspective

• Data subject is an identifiable natural person (as defined in Article 4 (1) of GDPR ).
• (Data) Controller (as defined in Article 4 (7) of GDPR ) manages and controls what happens with personal data of data subject.
• (Data) Processor (as defined in Article 4 (8) of GDPR ) performs data processing on behalf of the data controller.

Technical perspective

• Infrastucture Provider is a role which refers to the Processor in GDPR. An example of this role is a cloud service provider (CSP).

Threat Model See Section 6.1 of as an example.

Typical Security Goals See as an example.

Attacks Security considerations in RATS specifications need to clarify how the following attacks are avoided or mitigated:

(Evidence) Replay Attacks In this attack, a network or endpoint adversary -- with access to older Evidence -- can replay Evidence with stale Claims which no longer represent the actual state of the Attester, potentially resulting in exposure of confidential data . Replay of stale Evidence may be within the same connection or across multiple connections.

Diversion Attacks In this attack, a network adversary -- with Dolev-Yao capabilities and access (e.g., via Foreshadow ) to the attestation key of any machine in the world -- can redirect a connection intended for a specific Infrastructure Provider to the compromised machine, potentially resulting in exposure of confidential data . In the context of confidential computing and TLS as a transport protocol, we reported these attacks to the TLS WG in February 2025 . A formal proof is available for further research and development. Since reporting to TLS WG, these attacks have been practically exploited in TEE.fail, Wiretap.fail, and BadRAM.

Relay Attacks In this attack, a network or endpoint adversary -- with access to suitable binding material -- can relay an attestation request to a genuine Attester and present the genuine Evidence as its own, potentially resulting in impersonation of genuine Attester . Note that replay is about same Attester while relay attack is about different Attesters.

Potential Mitigations This section describes the countermeasures and their evaluation. To mitigate the above attacks, we propose post-handshake attestation. We are not aware of any attacks on post-handshake attestation. Post-handshake attestation avoids replay attacks by using a fresh attestation nonce. Moreover, considering TLS as the transport protocol, it avoids diversion and relay attacks by binding the Evidence to the underlying TLS connection, such as using Exported Keying Material (EKM) , as proposed in Section 9.2 of . and provide mechanisms for such bindings. Efforts for a formal proof of security of post-handshake attestation are ongoing.

Security Considerations All of this document is about security considerations.

IANA Considerations This document has no IANA actions.

References Normative 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. 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 All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Cryptography Consulting LLC Cloudflare, Inc. This document provides guidelines and best practices for writing technical specifications for cryptography protocols and primitives, targeting the needs of implementers, researchers, and protocol designers. It highlights the importance of technical specifications and discusses strategies for creating high-quality specifications that cater to the needs of each community, including guidance on representing mathematical operations, security definitions, and threat models. Arm Ltd Huawei Technologies France S.A.S.U. Huawei Technologies France S.A.S.U. Fraunhofer SIT IETF RATS Architecture, defines the key role of a Verifier. In a complex system, this role needs to be performed by multiple Verfiers coordinating together to assess the full trustworthiness of an Attester. This document focuses on various topological patterns for a multiple Verifier system. It only covers the architectural aspects introduced by the Multi Verifier concept, which is neutral with regard to specific wire formats, encoding, transport mechanisms, or processing details. Faculty of Computer Science, Technical University of Dresden, Dresden, Germany Huawei Technologies Oy, Helsinki, Finland Department of Computer Science, University of Applied Sciences Bonn-Rhein-Sieg and Siemens, Sankt Augustin, Germany Linaro, Lausanne, Switzerland Institute of Electrical and Electronics Engineers (IEEE) TU Dresden, Dresden, Germany Aalto University, Espoo, Finland Aalto University, Espoo, Finland ACM CVE Independent This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. This document describes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer. This document defines a channel binding type, tls-exporter, that is compatible with TLS 1.3 in accordance with RFC 5056, "On the Use of Channel Bindings to Secure Channels". Furthermore, it updates the default channel binding to the new binding for versions of TLS greater than 1.2. This document updates RFCs 5801, 5802, 5929, and 7677.

Acknowledgments The author wishes to thank Ira McDonald and Ivan Gudymenko for insightful discussions.

History -01

• Concrete text proposal for security and privacy considerations of multi-verifiers

-02

• Introduction and motivation
• Defined replay and relay attacks
• Added mitigations