]> Guidelines for Security Considerations of RATS TU Dresden
muhammad_usama.sardar@tu-dresden.de
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. The current version presents an outline of the topics that future versions will cover in more detail.
  • Corrections in published RATS RFCs
  • Security concerns in two RATS drafts
  • General security guidelines, baseline or template for RATS
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 While excellent guidelines such as exist, remote attestation has several distinguishing features which necessitate a separate document. One specific example of such a feature is architectural complexity. The draft presents an outline of three topics that future versions will cover in more detail:
  • Corrections in published RATS RFCs , , and
  • Security concerns in one currently adopted RATS draft and one proposed for adoption RATS draft
  • General security guidelines, baseline or template that other drafts can simply point to
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 proposes 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?" TODO.
System Model TODO.
Actors TODO.
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.
TODO.
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).
TODO.
Threat Model TODO.
Typical Security Goals TODO.
Attacks Security considerations in RATS specifications need to clarify how the following attacks are avoided or mitigated:
Replay attacks See . TODO.
Relay attacks See . TODO.
Diversion attacks In this attack, a network adversary -- with Dolev-Yao capabilities and access (e.g., via Foreshadow ) to 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 . TODO.
Potential Mitigations This section will describe the countermeasures and their evaluation. See . TODO.
Examples of Specifications That Could Be Improved
RFC9334
Unprotected Evidence has:
A conveyance protocol that provides authentication and integrity protection can be used to convey Evidence that is otherwise unprotected (e.g., not signed).
Using a conveyance protocol that provides authentication and integrity protection, such as TLS 1.3 , to convey Evidence that is otherwise unprotected (e.g., not signed) undermines all security of remote attestation. Essentially, this breaks the chain up to the trust anchor (such as hardware manufacturer) for remote attestation. Hence, remote attestation effectively provides no protection in this case and the security guarantees are limited to those of the conveyance protocol only. In order to benefit from remote attestation, Evidence MUST be protected using dedicated keys chaining back to the trust anchor for remote attestation.
Missing definitions uses the term Conceptual Messages in capitalization without proper definition.
Missing Roles and Conceptual Messages
  • Identity Supplier and its corresponding conceptual message Identity are missing and need to be added to the architecture .
  • Attestation Challenge as conceptual message needs to be added to the architecture .
RFC9781 As argued above for RFC9334, security considerations in are essentially insufficient.
RFC9783 uses:
  • 3x epoch handle (with reference to and ) whereas RFC9334 never uses epoch handle at all!
  • 1x epoch ID with no reference and no explanation of how it is different from epoch handle
RFC9711
Inaccurate opinion has:
For attestation, the keys are associated with specific devices and are configured by device manufacturers.
The quoted text is inaccurate and just an opinion of the editors. It should preferably be removed from the RFC. For example, in SGX, the keys are not configured by the manufacturer alone. The platform owner can provide a random value called OWNER_EPOCH. For technical details and proposed text, see .
Inaccurate Privacy Considerations has:
The nonce claim is based on a value usually derived remotely (outside of the entity).
Attester-generated nonce does not provide any replay protection since the Attester can pre-generate an Evidence that might not reflect the actual system state, but a past one. See the attack trace for Attester-generated nonce at . For replay protection, nonce should always be derived remotely (for example, by the Relying Party).
Examples of Parts of Specifications That are Detrimental for Security We believe that the following parts of designs are detrimental for the RATS ecosystem:
Multi-Verifiers
Security Considerations We believe the security considerations of multi-verifiers must say: Compared to a single verifier, the use of multi-verifiers increases security risks in terms of increasing the Trusted Computing Base (TCB).
Privacy Considerations We believe the privacy considerations of multi-verifiers should say: Compared to a single verifier, the use of multi-verifiers may increase the privacy risks, as potentially sensitive information may be sent to multiple verifiers.
Open-source Besides, the rationale presented by the authors -- appraisal policy being the intellectual property of the vendors -- breaks the open-source nature of RATS ecosystem. This requires blindly trusting the vendors and increases the attack surface.
Aggregator-based design Aggregator in is an explicit trust anchor and the addition of new trust anchor needs to have a strong justification. Having a malicious Aggregator in the design trivially breaks all the guarantees. It should be clarified how trust is established between Aggregator and Verifier in the context of Confidential Computing threat model. The fact that Aggregator has collective information of Reference Values Providers and Endorsers makes it a special target of attack, and thus a single point of failure. It increases security risks because Aggregator can be compromised independent of the Reference Values Providers and Endorsers. That is, even if Reference Values Providers and Endorsers are secure, the compromise of Aggregator breaks the security of the system. Moreover, if Aggregator is not running inside a TEE, it is relatively easy to compromise the secrets.
Security Considerations All of this document is about security considerations.
IANA Considerations This document has no IANA actions.
References Normative 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. A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR Web Token Claims Sets (UCCS) This document defines the Unprotected CWT Claims Set (UCCS), a data format for representing a CBOR Web Token (CWT) Claims Set without protecting it by a signature, Message Authentication Code (MAC), or encryption. UCCS enables the use of CWT claims in environments where protection is provided by other means, such as secure communication channels or trusted execution environments. This specification defines a CBOR tag for UCCS and describes the UCCS format, its encoding, and its processing considerations. It also discusses security implications of using unprotected claims sets. The Entity Attestation Token (EAT) An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (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 a JSON Web Token (JWT) with attestation-oriented claims. Arm's Platform Security Architecture (PSA) Attestation Token Arm's Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, along with open-source reference implementations, aimed at helping device makers and chip manufacturers integrate best-practice security into their products. Devices that comply with PSA can generate attestation tokens as described in this document, which serve as the foundation for various protocols, including secure provisioning and network access control. This document specifies the structure and semantics of the PSA attestation token. The PSA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes the claims used in an attestation token generated by PSA-compliant systems, how these claims are serialized for transmission, 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. 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 The Transport Layer Security (TLS) Protocol Version 1.3 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 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Identity Crisis in Attested TLS for Confidential Computing Guidelines for Security Considerations of RATS Perspicuity of Attestation Mechanisms in Confidential Computing: Technical Concepts Perspicuity of Attestation Mechanisms in Confidential Computing: General Approach Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the pro- cessing of personal data and on the free movement of such data, and repealing Direc- tive 95/46/EC (General Data Protection Regulation) (Text with EEA relevance) On the security of public key protocols Foreshadow Guidelines for Writing Cryptography Specifications 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. Remote Attestation with Multiple Verifiers 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. Concise Selector for Endorsements and Reference Values Arm Linaro Fraunhofer SIT Fujitsu AMD Alibaba Cloud In the Remote Attestation Procedures (RATS) architecture, Verifiers require Endorsements and Reference Values to assess the trustworthiness of Attesters. This document specifies the Concise Selector for Endorsements and Reference Values (CoSERV), a structured query/result format designed to facilitate the discovery and retrieval of these artifacts from various providers. CoSERV defines a query language and corresponding result structure using CDDL, which can be serialized in CBOR format, enabling efficient interoperability across diverse systems. Clarifications in draft-ietf-rats-eat Security considerations of remote attestation (RFC9334)
Acknowledgments The author wishes to thank Ira McDonald and Ivan Gudymenko for insightful discussions. The author also wishes to thank the authors of (in particular Thomas Fossati and Paul Howard) for several discussions, which unfortunately could not resolve the above concerns, and hence led to this draft. The author also gratefully acknowledges the authors of , which serves as the inspiration of this work.