]> Secure-IC

antoine.poulain@secure-ic.com

Secure-IC

abdellah.kaci@secure-ic.com

Security Remote ATtestation ProcedureS attestation hardware root of trust Hardware components constitute the foundation of all computations and therefore play a critical role in system integrity and reliability. Existing attestation mechanisms primarily rely on manufacturer Endorsements, which provide limited visibility into the runtime behavior of hardware. This document extends the Remote ATtestation procedureS (RATS) architecture by defining a data model and guidelines for including measurements of hardware components in attestation Evidence. These measurements may represent physical properties, results of self-tests, or behavioral observations. The document considers a threat model that includes both adversarial actions and physical phenomena such as environmental variations and aging. It proposes abstract interfaces for collecting measurements, enabling interoperability while remaining agnostic to implementation mechanisms, and outlines a security model for their use in appraisal. 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 Remote ATtestation ProcedureS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Hardware components form the foundation upon which all computations rely. Therefore, the correctness and integrity of software execution depend on the proper functioning of the underlying hardware, which can be considered a root of trust for computation. Modern systems increasingly adopt disaggregated architectures, such as chiplet-based designs and large-scale heterogeneous platforms. These systems integrate hardware components from multiple sources, introducing new attack surfaces. At the same time, zero trust principles encourage reducing reliance on static data such as Endorsements in favor of Evidence reflecting the actual runtime state of components, consequently enabling more dependable assessment of both security and safety properties. However, current attestation mechanisms for hardware components primarily rely on manufacturer-issued Endorsements, which capture properties established prior to deployment but provide limited visibility into runtime hardware behavior. This document considers a threat model in which hardware components may be affected not only by adversarial actions, but also by physical phenomena such as environmental variations, aging, and natural degradation (see ). This wider scope is motivated by the fact that hardware components, are directly influenced by physical conditions that can alter their behavior over time or under stress. Therefore, assessing the runtime state of hardware requires taking into account both intentional attacks and non-adversarial effects that may lead to faults or degraded operation. These aspects are particularly important in systems with strong safety and reliability requirements. To bridge this gap between static certification and dynamic threats across decentralized ecosystems, frameworks like propose continuous, hardware-backed attestation that aligns with zero-trust principles and international regulations (e.g., the EU Cyber Resilience Act and US Executive Order 14028). By leveraging both cryptographic measurements and Physical IP attestation of the Root of Trust (RoT), such architectures allow component trustworthiness and physical integrity to be queried on demand throughout the product's lifetime. This continuous verification approach is designed to scale across both SoC and modern disaggregated SiP platforms, extending traditional acceptance testing into the runtime lifecycle. To address these limitations, this document defines a data model and provides guidelines for including hardware component measurements in attestation Evidence (), as described in the RATS architecture . By incorporating runtime hardware measurements, attestation can provide improved visibility into the integrity and reliability of systems. This document also outlines a security model for such measurements and provides examples of existing technologies that can be leveraged to obtain them (). These examples are informational only and do not mandate specific implementations. Instead, this document remains agnostic to the underlying measurement mechanisms and focuses on defining abstract interfaces () and a data model for obtaining and representing such measurements.

Terminology

Requirements Notation 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.

Definitions The terminology defined in is reused throughout this document. Some definitions from RATS specifications are refined here to fit the context presented in this document.

• Measurement Unit: A hardware mechanism (a circuit) or software logic with the ability to measure a hardware component. Software logic used to trigger a measurement is not considered a Measurement Unit but rather the Attesting Environment end-point of the Trigger interface. See for details on the Trigger interface.
• Measurement: Term introduced by RATS. In the context of this document, it can mean a representation of a physical property, the result of a test, the detection of an event, etc.
• Target Hardware Component: A hardware component which is a Target Environment for an Attesting Environment.

Use Cases The solution presented in this document aims at mitigating two threats on hardware.

• Defective hardware components

Malfunctions of hardware components may be caused by environment and/or aging. Detection of such malfunctions is critical when relying on systems evolving in hazardous environments such as high pressure, extreme temperatures, contact with water, chemical substances or space radiations.

• Attacks on hardware components

Gaining control of the hardware of a system is particularly interesting for an attacker as it allows to tamper with the correct functioning of the system at a privileged level. Such control can be obtained by abusing software mechanisms or by having physical access to the system (particularly relevant for embedded systems) and using physical attack techniques. Security and Safety note: Undetected hardware defects can compromise the integrity of cryptographic operations, attestation chains, or safety-critical controls, turning a physical fault into a security vulnerability or a life-threatening failure. In adversarial contexts, hardware degradation may also be leveraged to bypass attestation mechanisms or force a system into an exploitable state. Timely and verifiable detection of hardware component malfunctions is therefore critical for maintaining both operational safety and the trustworthiness of any attestation claim issued by a system. For instance, environmental conditions and aging can alter the physical noise source of a TRNG, potentially reducing entropy and compromising the unpredictability required for security and safety. This TRNG example is extended in .

Attester Model The RATS architecture presented in introduces two types of environments in an Attester. The Attesting Environment (AE) and the Target Environment (TE). The Attesting Environment is in charge of collecting claims about a Target Environment. The Attesting Environment is then responsible for embedding those claims in an Evidence Conceptual Message. This document focuses on claims used to represent the state of a target hardware component. Said claims can be related to physical properties (electromagnetic or thermal signature, timing values, power consumption, etc.), results of integrated self-tests or collected traces. The goal of this section is to propose standard interfaces to trigger the computation of the measurement and to collect the computed measurement. Also, this section presents a mapping of Attesting Environments and Target Environments in different integration models of measurement mechanisms.

Abstract Representation Mechanisms for collecting measurements of hardware components may highly depend of the type of hardware component and on the desired type of measurement. Therefore, this document proposes an abstract representation of such mechanisms. Considering a measurement mechanism as a black box with common interfaces, allows the content of this document to remain agnostic of the underlying mechanism and of the type of measurement collected while promoting interoperability with different real world implementations. This document uses the following abstract objects:

• Measurement Unit

Black box used to represent a mechanism capable of computing measurements over a target. The Measurement Unit is part of the Attesting Environment.

• Trigger interface

To start the computation of a measurement, the Measurement Unit must be triggered. The trigger can follow an external request, a watchdog or any event set to trigger a measurement. The Measurement Unit receives a signal to start the computation of a measurement through the "Trigger" interface. This interface is optional. For instance, it may not be used in case of continuous monitoring.

• Export interface

The "Export" interface allows a measurement to be exported from the Measurement Unit to a controlled memory region in the trust boundary of the Attesting Environment.

• Data Exchange channel

The measurement mechanism needs to have physical access on the property that it is in charge of measuring. The flow of data exchanged between the Measurement Unit and the target hardware component is represented by the "Data Exchange" channel. This channel is not accessible by the Attesting Environment excepted by the Measurement Unit.

Integration Models The following subsections present possible layouts for integrating a Measurement Unit between the Attesting Environment and the target hardware component.

Embedded Measurement Unit In this integration model, the Measurement Unit is part of the target hardware component. The separation between Measurement Unit (part of the Attesting Environment) and the Target Environment is only logical. The target hardware component and the Measurement Unit are part of the same die. Due to the proximity between the Measurement Unit and the target hardware component, the Data Exchange channel is not represented.

Abstract Representation of Embedded Measurement Unit | Target HW | | | Attesting | | | Component | | | Environment | | | (TE) | | | | | +---------------+ | | <---------------+ Measurement Unit | +-------------+ Export | (AE) | Measurement +-------------------------+ ]]>

Ex: Different types of Built-In-Self-Tests (BIST) or Known Answer Tests (KAT). Note: As shown in , the Measurement Unit and target hardware component share the same die. Therefore, they are in the same physical security perimeter. This may have an impact on the trust model (see ).

External Measurement Unit In the following integration models, the Measurement Unit is external to the target hardware component.

Discrete Component The Measurement Unit is a discrete component external to the target hardware component and to the Attesting Environment.

Abstract Representation of Discrete Measurement Unit | | | | Measurement Unit | | <----------------+ (AE) | | | Export +---------^--------+ | Attesting | Measurement | | Environment | | Data Exchange | | | | | +-------v-------+ | | | Target HW | | | | Component | +-------------+ | (TE) | +---------------+ ]]>

Ex: Sensors added on top of hardware component, Power Management IC (PMIC), Baseboard Management Controller (BMC). In this integration model, the target hardware component and Measurement Unit can come from different sources (e.g., foundries). That can be leveraged to draw trust boundaries between the AE, TE and Measurement Unit. Using a discrete component implies the existence of physical communication channels between the AE, TE and Measurement Unit on which data such as measurement will transit. This introduces attack vectors. Refer to .

Integrated in Attesting Environment The Measurement Unit is physically integrated in the Attesting Environment. It can take the form of hardware circuitry or be a software component. As the Measurement Unit is integrated in the Attesting Environment, the Trigger and Export interfaces are not represented in .

Abstract Representation of Measurement Unit Integrated in AE Component | | +-------------+ | | (TE) | | | +---------------+ +-------------------+ ]]>

Ex: Software logic (e.g., FIPS KAT) Note: This integration model can be limiting in terms of what it is possible to measure. Of course, both embedded and external Measurement Units can be found in the same system and possibly, a combination of embedded and external can be used to measure a single Target Environment (see the practical example in ). A single Attesting Environment can be responsible for one or more target hardware components. The Attesting Environment is therefore responsible for building Evidence for all of its target hardware components. In addition to that, there may be multiple Attesting Environments. That case is discussed in .

Measurement Journey Measurements of hardware components must be included in the Evidence to be sent to a Verifier. This implies that the Attesting Environment possesses a way to start the computation of the measurement (trigger), to securely retrieve the measurement (collection) and to securely embed the measurement in Evidence. During the completion of all these steps, the attacker has many opportunities to tamper with the integrity of the measurement or the execution logic (hardware or software). Below are the identified steps of the journey of a measurement at the hardware level. These are important as this document implies a security model in which the attacker can tamper with hardware.

1. Trigger computation Measurement computation is triggered by an event (boot, external request, watchdog) or continuous. The Attesting Environment is able to trigger the computation of the measurement through the Trigger interface.
2. Compute measurement The measurement of the target hardware component is computed by the Measurement Unit.
3. Export measurement Once the measurement has been computed, it must be exported in order to be accessible by the Attesting Environment. The measurement transits from the Measurement Unit to the Attesting Environment through the export interface. Protection of the measurement in transit against tampering is critical for its trustworthiness. An attacker must not be able of tampering with the measurement in transit. This can be achieved by using bus protection techniques.
4. [optional] Store measurement It is possible that the measurement will not be directly included in Evidence but instead stored until it is effectively included in Evidence by the Attesting Environment. The measurement must be securely stored in the boundary of the Attesting Environment. An attacker must not be able of tampering with the measurement while it is at rest.
5. [optional] Process measurement It is possible that the measurement will not be directly included in Evidence as is but instead needs to be processed first before being effectively included in Evidence by the Attesting Environment. The processing of the measurement must be securely operated in the boundary of the Attesting Environment. An attacker must not be able of tampering with the processing logic.
6. Include measurement in Evidence The Attesting Environment is responsible for including the measurement data in Evidence. This operation must be carried out securely. An attacker must not be able to tamper with this logic. Note: At that point, the Evidence is not signed yet and could still be tampered by an attacker, possibly without being detected.
7. Sign Evidence The signature operation must be carried out securely. An attacker must not be able to modify the content of the Evidence or forging signature for compromised data. For instance, if the signature operation is offloaded to a remote hardware component and thus Evidence content must transit on a bus to reach this component, the attacker must not be able to manipulate data in transit (measurement, outputted signature). Once stored in signed Evidence, the measurement is considered safe from unauthorized modification. This is because the cryptographic signature of the Evidence ensures integrity protection.

represents the steps of the measurement journey described above.

Measurement Journey Measurement Unit | | | | | | | +---------------------+ | | Compute | | | | [Optional] | | | Measurement| | | | Measurement Storage <-+-------------+ +------------v-+ | | +----------+----------+ | Export | | Target | | | | | Measurement | | Hardware | | | +----------v----------+ | | | Component | | | |[Optional] Processing| | | +--------------+ | | +----------+----------+ | +------------------------+ | | | | +----------+----------+ | | | +--------v--------+ | | | | | Include | | | | | | measurement in | | | | | | Evidence | | | | | +-----------------+ | | | | | | | | Sign Evidence | | | +---------------------+ | | | +-------------------------+ ]]>

Inclusion in Conceptual Messages This section introduces standard claims to be included in RATS Conceptual Messages. Conceptual Messages are defined in . The RATS architecture does not mandate the usage of standard data formats for Conceptual Messages but protocols may require specific formats. Nonetheless, RATS proposed CoRIM for Endorsements and Reference Values and EAT for Evidence as standard data models. The CoRIM is defined in and the EAT is defined in . To promote interoperability, the following sections showcase how to use the CoRIM and EAT data models in the context of this document.

Endorsement Endorsements in the scope of this document contain metadata describing the characteristics of Measurement Units and target hardware components that are necessary for the Verifier to correctly appraise Evidence. These may include:

• Measurement Unit characteristics (e.g., accuracy, precision, uncertainty, sampling rate, sample count, method),
• Measurement Unit identification data (e.g., product identifier, implementation version),
• Environmental robustness properties (e.g., operating temperature range, resistance to environmental conditions),
• Calibration data (e.g., calibration coefficients and drift models over operational context),
• Semantics of measurements (e.g., unit, scale, interpretation) and where applicable, the characteristics of reference or behavioral models to be used by the Verifier during appraisal.

The exact set of endorsed data to be included in Endorsement depends on the type of measurement as well as the characteristics and operational constraints of the Measurement Unit and of the target environment. Endorsements must be generated in a secure environment. TODO: if the unit of the measurement is specified in here, is it possible to reuse IANA numbers for Sensor Measurement Lists: https://www.iana.org/assignments/senml/senml.xhtml

Concise Reference Integrity Manifest (CoRIM) Endorsements can be written inside a CoMID Endorsed Values triple of a CoRIM (see ). The Endorsed Values triple holds one or more measurement-map that are used to write the Endorsements.

Reference Value Reference Values represent expected measurement results or acceptable ranges under specific operational context of the system in mission. For instance, a measurement might be dependent of the environmental conditions surrounding the system. This must be taken into account as a measurement different from the Reference Value does not necessarily mean bad behavior. If such context-dependent parameters cannot be foreseen, it is possible to include additional data in Evidence to give details about the context in which the measurement has been computed (see ). The Verifier will then use these additional data to select the Reference Value that should be used in the context described by the additional data (kind of conditional Reference Values). This implies that attacker cannot modify these additional data otherwise, an attacker would be able to fool a Verifier into choosing Reference Values that don't correspond to the actual context of the system. Depending on the type of measurement and target hardware component, the Reference Value may be:

• a single value,
• a range of values,
• or a function of the operational context of the system (e.g, a mapping, a statistical distribution, an ML model).

Also, the Reference Value may apply to:

• a class of hardware components,
• a group of hardware components,
• or a single hardware component instance.

Reference Values must be computed in a secure environment.

Concise Reference Integrity Manifest (CoRIM) Reference Values can be written inside a CoMID Reference Values triple of a CoRIM (see ). The Reference Values triple holds one or more measurement-map that are used to write the Reference Values.

Evidence The current version of this document proposes several approaches for including hardware component measurements in Evidence. For now, these options are present as brainstorming, to explore the different possibilities and may be removed in future versions of this document.

Entity Attestation Token (EAT)

Using EAT Measured Component Claim It is possible for some measurements to be represented in an already existing EAT Measured Component. The EAT Measured Component is defined in . For instance, a custom measurement structure can be used to hold hardware component measurement in the "measurement" field of the "measured-component" structure from . Also, the flag field can be used to extend the measured-component base type with profile-defined semantics.

Using EAT Measurement Result Claim It is possible for some measurements to be represented in an already existing EAT Measurement Result. The EAT Measurement Result is defined in . This claim could be well-suited for measurements with on-device comparisons with reference values. For instance, self-tests (e.g., BIST, KAT) verify that the computed measurement corresponds to an expected value and output results such as "success" or "failure". In that case, a Measurement Result claim can be used.

Using EAT Submodule Claim TODO it seems that the EAT Submodule can be used to embed hardware components claims (maybe only more complete subsystems not simple hardware components). Research if it could be extended to include measurements. Especially relevant if the submodule does not have its own Attesting Environment ().

Using Measured Hardware Component Claims This section proposes a new claim, the "Measured Hardware Component", to represent what is described in this document. This claim is presented in case the already existing claims mentioned above are not sufficient to correctly report measurements of hardware components. The "measured hardware component" claim is inspired from the "measured component" claim introduced in .

Information Model This section presents the information model of a "measured hardware component". The information elements (IEs) that constitute a "measured hardware component" are described in . Measured Hardware Component Information Elements

IE	Description	Requirement Level
Component Name	The name given to the target hardware component.	REQUIRED
Operational Context	Additional information on the operational context of the component.	OPTIONAL
Measurement List	List of measurements for the target hardware component. Each element of the list is composed of a Measurement Type and of a Measurement Value.	REQUIRED

Component Name Component Name is used to identify the target hardware component.

Operational Context Additional information on the operational context of the component. These can be used by the Verifier to appraise measurements. By being placed at this level of the Measured Hardware Component claim, the operational context is shared by every measurement of the target hardware component. It is important that the operational context sampled corresponds to the actual operational context at the time of measurement computations (i.e., sampling of the operational context and computation of the measurements must be executed simultaneously (approximately). Otherwise, Time-Of-Check to Time-Of-Use (TOCTOU) attacks would be possible). A lot of data can be included in Operational Context such as environmental (e.g., temperature, humidity, radiation), electrical (e.g., voltage, clock frequency, power state), workload (e.g., workload level, type), temporal (timestamp, uptime), system operation (degraded mode, thermal throttling) contexts. TODO fill table. Operational Context is highly dependent on what is needed by Verifier which depends on what is measured and also what are the available sensors etc. so it will either contain a lot of optional fields or be profile-specific. Fields of the Operational Context

Field Name	Description	Requirement Level

Use case example: the measurement may be subject to variations depending on environmental context such as temperature (ideally specified in Endorsements, see ). A measurement value might be acceptable when computed in a context of extreme cold but not if computed at room temperature. The Verifier must therefore be aware of the temperature surrounding the component to decide if the measurement corresponds to good behavior or not. The Verifier will therefore base its appraisal on the environmental context reported in Operational Context. Note: Information in Operational Context is sensitive and must have the same level of protection as the measurements.

Measurement List Content of Elements of the Measurement List

Field Name	Description	Requirement Level
Measurement Unit Identifier	Identifier for the Measurement Unit used to obtain the measurement	REQUIRED
Measurement Type	The type of the measurement.	REQUIRED
Measurement Value	The Value of the measurement. The content of this field depends on the Measurement Type.	REQUIRED

• Measurement Unit Identifier:

Identifier for the Measurement Unit used to compute the measurement. For instance there may be multiple sensors used to measure a single property of the target hardware component. In that case, the Measurement Unit Identifier allows to identify the Measurement Unit that was used.

• Measurement Type:

Specifier for the type of the measurement. For example, the type can be used to specify if the measurement is the result of a self-test, the sampling of a physical property, a trace or an event (see ).

• Measurement Value:

The structure that holds the actual measurement. The structure of the Measurement Value depends on the Measurement Type.

X.509 Certificate describes methods to encode EAT claims in an X.509 certificate. These methods can be used for the claims presented in . Ex: DICE uses X.509 certificates with a custom extension to carry Evidence . TLS and DTLS extended with remote attestation also use X.509 certificates with an attestation extension .

CDDL Definitions This section presents CDDL definitions for the Measured Hardware Component claim to be included in EAT Measurement claim.

Measured Hardware Component Claim

CDDL of Measured Hardware Component Claim component-id ? operational-ctx-label => operational-ctx measurement-list-label => [ + hw-measurement ] } operational-ctx = { ; structure for operational context } hw-measurement = { measurement-unit-id => tstr measurement-type-label => measurement-type ; a choice measurement-value-label => measurement-value ; depends of type } measurement-type = mt-self-test / mt-phys-prop / mt-event / mt-trace / mt-other ; profile measurement-value = ; structure that depends of type mv-self-test / mv-phys-prop / mv-event / mv-trace / mv-other ; profile ]]>

Measurement Value

Physical Property CDDL definition of the structure of measurement-value when measurement-type = mt-phys-prop.

CDDL of Physical Property Measurement Value tstr, value => number / bstr / tstr, ; unit, precision, scale, uncertainty, ; are already specified in Endorsements } ]]>

Self-Test CDDL definition of the structure of measurement-value when measurement-type = mt-self-test.

CDDL of Self-Test Measurement Value tstr, test-result-label => self-test-result, } self-test-result = st-pass / st-fail / st-degraded / st-not-run / st-unknown ]]>

Event CDDL definition of the structure of measurement-value when measurement-type = mt-event.

CDDL of Event Measurement Value tstr, event-status-label => event-status, ? event-count => uint, ? event-time => int / uint } event-status = e-detected / e-not-detected / e-active / e-inactive / e-unknown ]]>

Trace CDDL definition of the structure of measurement-value when measurement-type = mt-trace.

CDDL of Trace Measurement Value trace-type, trace-data => bstr / tstr } trace-type = digest / summary / counter ]]>

Other CDDL definition of the structure of measurement-value when measurement-type = mt-other. TODO additional structures could be defined in a profile. Simply, the Measurement Value could be raw bytes that the Verifier would understand (by using a profile).

Inclusion in EAT Measurement Claim The CDDL defined in extends the $measurements-body-cbor and $measurements-body-json EAT sockets to add support for the measured-hw-component to the Measurements claim ().

CDDL Extension of EAT Measurement Body

Practical Examples This section is for informational purposes only. Note: There are many interesting examples of hardware monitoring in that are not covered here but fall in the scope of this document.

Monitoring Physical Properties

Using a Discrete Component Sensor In this scenario, the Measurement Unit is implemented as a discrete external sensor, such as a temperature sensor or a Power Monitoring Integrated Circuit (PMIC). The Target Environment is the hardware component under observation, for example a CPU. This corresponds to the integration model described in . The Measurement Unit observes physical properties of the Target Environment through a physical coupling, such as thermal conduction or electrical interaction (which in the model, corresponds to the Data Exchange channel), and exports digitized measurements to the Attesting Environment through the Export interface. The Attesting Environment collects these measurements and includes them in Evidence, along with, if possible, contextual information describing the operational conditions under which the measurements were obtained. In this model, the Measurement Unit is external to the Target Environment and may originate from a different manufacturer. As a result, the trustworthiness of the measurements depends on the integrity and characteristics of the sensor, which can be established through Endorsements describing its properties such as precision, calibration, and operating conditions (refer to ). During appraisal, the Verifier evaluates the measurements against Reference Values that may depend on the operational context. These Reference Values may be expressed as fixed ranges, condition-dependent functions, or behavioral models. The Verifier could use advanced models, including statistical or machine learning-based approaches, to detect anomalies (but such models would be part of the Appraisal Policy for Evidence and are not encoded in Evidence). Note: compared to embedded Measurement Units, this model introduces additional attack surfaces, including sensor spoofing, manipulation of communication channels, and environmental interference. These risks must be considered in the system design and threat model (see ).

Using an Embedded Sensor

Generic Example In this scenario, the Measurement Unit is implemented as an on-die sensor integrated within the target hardware component. This corresponds to the embedded Measurement Unit model described . The Measurement Unit observes physical properties of the Target Environment, such as temperature, voltage, or timing behavior, through direct internal coupling. Measurements are computed and made available to the Attesting Environment through internal interfaces, such as memory-mapped registers, without traversing external communication channels. The Attesting Environment collects these measurements and includes them in Evidence, optionally along with operational context information to support appraisal. As the Measurement Unit is physically integrated within the Target Environment, both share the same trust domain and physical security perimeter. The integrity of the Measurement Unit is typically established through Endorsements rather than through runtime measurement. During appraisal, the Verifier evaluates the measurements against Reference Values that may depend on the operational context. As with other physical measurements, these Reference Values may be expressed as ranges, condition-dependent functions, or behavioral models. Note: Compared to external sensors, this model reduces the attack surface by eliminating external communication channels and increasing the binding between the measurement and the component. However, it also reduces independence, as both the Target Environment and the Measurement Unit may be affected by the same faults or compromises. For instance, refer to .

Using a Ring Oscillator In this scenario, the Measurement Unit is implemented as a ring oscillator integrated within the Target Environment. This corresponds to the embedded Measurement Unit model described . The oscillator frequency depends on physical and electrical properties of the hardware, including voltage, temperature, and process variations. The Measurement Unit produces a digital representation of its oscillation frequency, which is collected by the Attesting Environment through an embodiment of the Export interface, then included in Evidence. These measurements provide an indirect observation of the physical state of the component and can be used to detect anomalies such as voltage glitches, thermal variations, or aging effects. During appraisal, the Verifier evaluates the reported frequency against Reference Values that depend on the operational context and calibration data provided through Endorsements. Note: As this model is very sensitive to physical perturbations, deviations may have multiple possible causes. Therefore, the interpretation of measurements requires operational context. Ring oscillator measurements can then be used to complement other measurement types by providing continuous monitoring of the hardware physical and electrical behavior.

Detection by Self-Testing This section provides practical examples that demonstrate how self-tests can be leveraged to measure a hardware component.

Using Built-In-Self-Tests (BIST) In this scenario, the Measurement Unit is implemented as Built-In Self-Test (BIST) circuitry integrated within the Target Environment, for example within a memory subsystem or a cryptographic accelerator. This corresponding to the embedded Measurement Unit integration model described in . The BIST logic executes predefined test patterns and compares the observed behavior of the component against expected results, producing a pass/fail outcome or a diagnostic signature. These tests may be executed at boot time or periodically during runtime. The Attesting Environment collects the BIST results and includes them in Evidence as measurements associated with the corresponding target hardware component structured according to a Measurement Result or a Measured Hardware Component claim defined respectively in and . During appraisal, the Verifier compares the reported test results against Reference Values, typically expecting a successful outcome. Unlike measurements of physical properties, BIST results are deterministic and do not require contextual interpretation. In such case, the operational context is not used. Note: This model provides strong assurance of functional correctness of the target hardware component and complements physical measurements by detecting faults that may not be observable through sensors.

TRNG Entropy Evaluation by an Embedded Measurement Unit In this scenario, the Target Environment is the TRNG hardware component, whose entropy source constitutes the subject of the measurement. The Measurement Unit is implemented as on-die hardware logic tightly coupled to the TRNG, corresponding to the embedded Measurement Unit integration model described in . The Measurement Unit continuously or periodically evaluates the entropy source by executing health tests and entropy estimators (Section 4 of ). Measurements are obtained through a Data Exchange channel, without traversing any software-accessible bus, and are exported directly to the Attesting Environment via the Export interface. The Attesting Environment is the system ROM, which collects the measurement outputs and embeds them into Evidence (EAT, X.509 certificate). The Evidence includes multiple measurements for the TRNG component, such as health test results and minimum entropy values, structured according to the Measurement Result or Measured Hardware Component claim defined respectively in and . During appraisal, the Verifier validates the signature using the manufacturer’s endorsement chain, then evaluates the measurements against Reference Values. Health test results are expected to indicate a passing state, and entropy values are compared against policy-defined thresholds. Note: In this integration model, the Measurement Unit and Target Environment share the same physical security perimeter. As a result, the integrity of the Measurement Unit is not independently verified at runtime but is instead covered by manufacturer endorsements.

TRNG Entropy Evaluation by a Software Measurement Unit In this scenario, the Target Environment is the TRNG, while the Measurement Unit is implemented as a software component executing within the Attesting Environment. This corresponds to the integration model described in . The Measurement Unit obtains raw samples from the TRNG via a software interface and computes entropy-related measurements. As the Measurement Unit operates in software, its integrity must be established before its output can be trusted. This falls in the category of classical software measurements already specified by RATS documents. The Evidence includes the entropy measurements produced by the software Measurement Unit. During appraisal, the Verifier first evaluates the integrity of the Measurement Unit by comparing the reported digest against reference values obtained from a CoRIM. Only if the Measurement Unit is recognized as intact does the Verifier proceed to evaluate the entropy measurements. This model introduces a dependency between the trustworthiness of the Measurement Unit and the validity of the measurements it produces. This dependency is always present but the trustworthiness of the MU is not always quantifiable (e.g., the MU cannot be measured), see .

TRNG Entropy Cross-Validation by Dual Measurement Units This scenario is a mix of the two previous ones. The Target Environment is the TRNG, while two Measurement Units operate concurrently: a hardware Measurement Unit embedded in the component and a software Measurement Unit integrated within the Attesting Environment. This corresponds to a combination of the integration models described in and . Each Measurement Unit independently computes entropy-related measurements based on the same underlying noise source. The Attesting Environment collects both sets of measurements, associates them with their respective Measurement Unit identifiers, and aggregates them into a single Evidence structure. This model enables cross-validation of measurements and allows the detection of silent failures affecting either one of the Measurement Units. A significant divergence between the two measurements may indicate faults, degradation, or inconsistencies in the measurement process, even when individual measurements satisfy their respective thresholds. The Evidence, in this case, contains multiple measurements for the same target hardware component, originating from distinct Measurement Units.

PUF Steadiness Evaluation with BIST In this scenario, the Target Environment is a Physical Unclonable Function (PUF) integrated within a hardware component and used for device identity or key derivation. The objective is to evaluate PUF steadiness (see ). The Measurement Unit is implemented as a BIST that performs runtime checks of the PUF behavior. This corresponds to the embedded Measurement Unit integration model described in . The Measurement Unit periodically or on-demand applies one or more selected challenges (or triggers a no-challenge PUF such as an SRAM PUF) and collects multiple responses under the current operational conditions. It then computes metrics that reflect the steadiness of the PUF, such as intra-device variation (e.g., Hamming distance between two responses), error correction activity, or decoding success rate. These computations aim at verifying that the PUF remains usable and stable enough for its purpose. The Attesting Environment collects the resulting metrics and includes them in Evidence with operational context. During appraisal, the Verifier evaluates the reported metrics against Reference Values or policy thresholds. For example, the Verifier may require that the intra-device variation remains below a given threshold, that error correction remains within acceptable range, or that response reconstruction succeeds under a fixed set of conditions. A deviation from these expectations may indicate abnormal behavior. Note: Environmental variations, aging, and physical attacks may affect PUF stability. Thus, interpreting the measurements requires consideration of operational context.

Detection of Active Tampering In this generic scenario, the Measurement Unit consists of tamper detection circuitry, such as an active mesh, voltage glitch detector, or light sensor, integrated within the hardware component. These mechanisms do not produce measurements of physical properties but instead generate event-driven signals indicating potential tampering or fault conditions. Such signals may be triggered by physical intrusion, abnormal voltage or clock conditions, or environmental disturbances. The Attesting Environment collects the status of these detectors and includes them in Evidence as security-relevant events or status indicators. During appraisal, the Verifier interprets these signals according to an Appraisal Policy, typically treating any indication of tampering as a critical failure condition. Unlike other measurements, the absence of an alert does not guarantee the absence of an attack, but the presence of an alert provides strong evidence of compromise. These mechanisms complement other measurement types by providing direct detection of active physical attacks and environmental anomalies.

Detection Using Traces In this generic scenario, the Measurement Unit consists of hardware trace logic integrated within the Target Environment, such as Arm CoreSight, Intel Processor Trace, or Nexus trace modules. These mechanisms observe the execution of the Target Environment and produce trace data reflecting instruction flow, memory accesses, or system events. Due to the high volume of trace data, the Attesting Environment typically processes or summarizes this information before including it in Evidence. The resulting measurements may consist of aggregated statistics, cryptographic digests of trace segments, or derived indicators of anomalous behavior. During appraisal, the Verifier evaluates these measurements against behavioral models describing expected execution patterns. These models may be expressed as statistical profiles or more advanced classifiers in the Appraisal Policy for Evidence. Trace-based measurements provide insight into the runtime behavior of the Target Environment and can reveal anomalies that are not detectable through static measurements or physical sensors. However, they require careful processing and interpretation and may introduce additional considerations related to data volume, confidentiality, and trust in the trace collection infrastructure.

Security Considerations The security considerations of RATS architecture apply (). This section also mentions protection against physical attacks. These attacks are particularly relevant for this draft as collecting claims about hardware components implies a risk of physical compromise. Aging and action of environment on the system are also considered threats. The security considerations of EAT Measured Component apply () when using EAT Measured Component claim or Measured Hardware Component Claim. The security considerations related to X.509 certificates apply () when using X.509 certificates to carry Evidence. Security considerations of CoRIM apply () when using CORIM for Endorsements and Reference Values. The following subsections are mainly focused on security considerations regarding the Attester during the steps of the Measurement Journey (see ).

Root of Trust Components Some components are essential for attestation (storage of attestation key, hardware Measurement Unit, etc.), if these are tampered with, there is no way to build trustworthy Evidence. These are considered the Root of Trust (RoT) for attestation because their correct functioning cannot be proved through attestation. These are to be put in contrast with other components that are not critical for attestation (although they can be critical for the security of the system itself !).

Multiple Attesting Environments In case of multiple Attesting Environments, distribution of freshness and binding of Evidence are discussed in .

Invasive Accesses An attacker must not be able to leverage a Measurement Unit to access protected assets. For instance, access to protected assets can happen when computing measurements by using internal debug mechanisms (e.g., TAP controllers).

Threat Model

Software Attacks There exist software attacks that can have a direct impact on hardware components’ behavior. These are ideally mitigated by good and secure development practices but in case they happen, these attacks can be detected by monitoring physical properties of the component (such as power consumption, thermal and electromagnetic signatures, timing). Ex: Software-induced Denial-of-Service (DoS). Ex: Manipulation of privileged power control interface.

Physical Attacks Physical attacks target the hardware of the system. They imply physical access to the system during its mission mode or while it is in the supply chain.

Passive Attacks Passive physical attacks are used by attackers to leak information through analysis of system physical properties. Passive attacks, by definition, do not modify behavior of the system and therefore cannot alter the correct functioning of the attestation flow. Ex: Side channel analysis of physical properties (EM emissions, power consumption, timing, temperature, probing, etc.) The danger with passive attacks resides in the extraction of sensitive assets and particularly attestation key used to sign Evidence, which can be used for impersonation and Evidence forgery. This is already tackled in .

Active Attacks Active physical attacks are the main problem since they allow an attacker (or a “natural” physical event) to tamper with the integrity of assets and execution flows of the system. These may therefore modify measurements in transit or at rest, inject arbitrary data in Evidence or modify the behavior of sensitive operations. Ex: Attacks on bus (Active man-in-the-middle (MITM), injection, probing) or anywhere measurements are in transit before being integrated in a structure that cannot be tampered or spoofed (signed Evidence). An example of an active bus attack is presented in . Ex: Glitching or fault injections to induce malicious behavior. May tamper with the target hardware component itself, the Measurement Unit or the logic used to build Evidence. See for example . Ex: Memory tampering attacks to modify stored measurements or execution logic. See for instance and . Some techniques to mitigate physical attacks are usage of a Trusted Platform Module (TPM) or secure element for storage and correct execution of protected logic, bus protections, implemented redundancy, sensors, active meshes, passive shields such as EMC shields () and PCB potting (), noise injection, etc. Note that some of these techniques are made to directly prevent attacks (e.g., passive shields) while others can only be used for detection (e.g., sensors, active meshes).

Supply Chain Attacks Each stage of the supply chain introduces a new opportunity for an attacker to tamper with the produced system. Supply chain attacks may lead to the injection of hardware trojans. Once the payload of a hardware trojan has been triggered, its activity may be reflected on the physical properties of the component (modified timing, different power consumption). It is therefore possible, in some cases, to detect an active hardware trojan by comparing the physical properties of the component when the trojan is active against the reference physical properties of the component. Note that, if the Measurement Unit is part of the component itself, which means that it has been integrated by the foundry that introduced the hardware trojan, then it cannot be trusted. Supply chain attacks can also lead to the generation of compromised Endorsements and Reference Values, especially if there are many hardware components coming from many sources. For instance, the attacker may be able to inject malicious behavioral models in Endorsements or relax the constraints specific to some operational contexts in Reference Value. In that case, the attestation cannot be trustworthy. Note that this security consideration is not specific to the subject of this document.

Privacy Considerations The privacy considerations of RATS architecture apply (). The privacy considerations of EAT Measured Component apply () when using EAT Measured Component claim or Measured Hardware Component Claim. Privacy considerations of CoRIM apply () when using CORIM for Endorsements and Reference Values. TODO for reused claims privacy considerations are probably specified in other documents so refer to them. TODO In new claims, some fields may be dangerous for privacy. Some fields may enable tracking.

Operational Considerations It is possible that some measurement mechanisms may not be fully deterministic or may fail on rare occurrences or raise false positives. It is also possible and expected that aging or environmental context affect sensors. These considerations must be taken into account and mitigated to an acceptable level by the designer.

IANA Considerations This document has no IANA actions. TODO need IANA actions for claims defined in this document ?

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 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. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Arm Linaro University of Applied Sciences Bonn-Rhein-Sieg Fraunhofer SIT The term "measured component" refers to an object within the attester's target environment whose state can be sampled and typically digested using a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document provides the information model for the "measured component" and two associated data models. This separation is intentional: the JSON and CBOR serializations, coupled with the media types and associated Constrained Application Protocol (CoAP) Content-Formats, enable the immediate use of the semantics within the Entity Attestation Token (EAT) framework. Meanwhile, the information model can be reused in future specifications to provide additional serializations, for example, using ASN.1. Fraunhofer SIT Linaro arm Independent Huawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. Sandelman Software Works Fraunhofer SIT Arm Linaro This document was attempting to clarifys and extends the meaning of Composite Attester from RFC9334. It has since been moved into the RATS wiki, and this I-D serves as a tombstone. A system of annotated diagram components is defined as a small language to explain the different ways that components can interact to form composites. These diagram components are then used to define a few popular classes of composites. Intuit Arm Limited Arm Limited Arm Limited Huawei Linaro This draft has been withdrawn. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/. Source for this draft and an issue tracker can be found at https://github.com/yaronf/draft-tls-attestation. International Standards Organization International Standards Organization Trusted Computing Group National Institute of Standards and Technology

Collected CDDL This appendix contains all the CDDL definitions included in this document. component-id ? operational-ctx-label => operational-ctx measurement-list-label => [ + hw-measurement ] } operational-ctx = { ; structure for operational context } hw-measurement = { measurement-unit-id => tstr measurement-type-label => measurement-type ; a choice measurement-value-label => measurement-value ; depends of type } measurement-type = mt-self-test / mt-phys-prop / mt-event / mt-trace / mt-other ; profile measurement-value = ; structure that depends of type mv-self-test / mv-phys-prop / mv-event / mv-trace / mv-other ; profile mv-phys-prop = { physical-property-id => tstr, value => number / bstr / tstr, ; unit, precision, scale, uncertainty, ; are already specified in Endorsements } mv-self-test = { test-id => tstr, test-result-label => self-test-result, } self-test-result = st-pass / st-fail / st-degraded / st-not-run / st-unknown mv-event = { event-id => tstr, event-status-label => event-status, ? event-count => uint, ? event-time => int / uint } event-status = e-detected / e-not-detected / e-active / e-inactive / e-unknown mv-trace = { trace-type-label => trace-type, trace-data => bstr / tstr } trace-type = digest / summary / counter ]]>

Acknowledgments Many thanks to Sylvain Guilley and Muhammad Usama Sardar for reviewing the document and providing valuable comments.