Attestation of Hardware Components
draft-paka-rats-hardware-component-attestation-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Antoine Poulain , Abdellah Kaci | ||
| Last updated | 2026-03-31 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-paka-rats-hardware-component-attestation-00
Remote ATtestation ProcedureS A. Poulain
Internet-Draft A. Kaci
Intended status: Standards Track Secure-IC
Expires: 2 October 2026 31 March 2026
Attestation of Hardware Components
draft-paka-rats-hardware-component-attestation-00
Abstract
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
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://github.com/antoinepoulain/hardware-component-
attestation/blob/main/draft-paka-rats-hardware-component-
attestation.txt. Status information for this document may be found
at https://datatracker.ietf.org/doc/draft-paka-rats-hardware-
component-attestation/.
Discussion of this document takes place on the Remote ATtestation
ProcedureS Working Group mailing list (mailto:rats@ietf.org), which
is archived at https://mailarchive.ietf.org/arch/browse/rats/.
Subscribe at https://www.ietf.org/mailman/listinfo/rats/.
Source for this draft and an issue tracker can be found at
https://github.com/antoinepoulain/hardware-component-attestation.
Poulain & Kaci Expires 2 October 2026 [Page 1]
Internet-Draft HW-attest March 2026
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 2 October 2026.
Copyright Notice
Copyright (c) 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Attester Model . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Abstract Representation . . . . . . . . . . . . . . . . . 7
4.2. Integration Models . . . . . . . . . . . . . . . . . . . 8
4.2.1. Embedded Measurement Unit . . . . . . . . . . . . . . 8
4.2.2. External Measurement Unit . . . . . . . . . . . . . . 8
4.3. Measurement Journey . . . . . . . . . . . . . . . . . . . 10
5. Inclusion in Conceptual Messages . . . . . . . . . . . . . . 13
5.1. Endorsement . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. Concise Reference Integrity Manifest (CoRIM) . . . . 13
5.2. Reference Value . . . . . . . . . . . . . . . . . . . . . 13
Poulain & Kaci Expires 2 October 2026 [Page 2]
Internet-Draft HW-attest March 2026
5.2.1. Concise Reference Integrity Manifest (CoRIM) . . . . 14
5.3. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3.1. Entity Attestation Token (EAT) . . . . . . . . . . . 14
5.3.2. X.509 Certificate . . . . . . . . . . . . . . . . . . 18
6. CDDL Definitions . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Measured Hardware Component Claim . . . . . . . . . . . . 18
6.1.1. Measurement Value . . . . . . . . . . . . . . . . . . 19
6.2. Inclusion in EAT Measurement Claim . . . . . . . . . . . 21
7. Practical Examples . . . . . . . . . . . . . . . . . . . . . 21
7.1. Monitoring Physical Properties . . . . . . . . . . . . . 22
7.1.1. Using a Discrete Component Sensor . . . . . . . . . . 22
7.1.2. Using an Embedded Sensor . . . . . . . . . . . . . . 22
7.2. Detection by Self-Testing . . . . . . . . . . . . . . . . 24
7.2.1. Using Built-In-Self-Tests (BIST) . . . . . . . . . . 24
7.2.2. TRNG Entropy Evaluation by an Embedded Measurement
Unit . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2.3. TRNG Entropy Evaluation by a Software Measurement
Unit . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2.4. TRNG Entropy Cross-Validation by Dual Measurement
Units . . . . . . . . . . . . . . . . . . . . . . . . 26
7.3. Detection of Active Tampering . . . . . . . . . . . . . . 27
7.4. Detection Using Traces . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8.1. Root of Trust Components . . . . . . . . . . . . . . . . 28
8.2. Multiple Attesting Environments . . . . . . . . . . . . . 29
8.3. Invasive Accesses . . . . . . . . . . . . . . . . . . . . 29
8.4. Threat Model . . . . . . . . . . . . . . . . . . . . . . 29
8.4.1. Software Attacks . . . . . . . . . . . . . . . . . . 29
8.4.2. Physical Attacks . . . . . . . . . . . . . . . . . . 29
8.4.3. Supply Chain Attacks . . . . . . . . . . . . . . . . 30
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30
10. Operational Considerations . . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Collected CDDL . . . . . . . . . . . . . . . . . . . 33
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. 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.
Poulain & Kaci Expires 2 October 2026 [Page 3]
Internet-Draft HW-attest March 2026
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 trust anchors and 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 Section 8). 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 address these limitations, this document defines a data model and
provides guidelines for including hardware component measurements in
attestation Evidence (Section 5.3), as described in the RATS
architecture [RFC9334]. 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
(Section 7). 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 (Section 4.1) and a data model for
obtaining and representing such measurements.
2. Terminology
Poulain & Kaci Expires 2 October 2026 [Page 4]
Internet-Draft HW-attest March 2026
2.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Definitions
The terminology defined in [RFC9334] 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 Section 4.1 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.
3. 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
Poulain & Kaci Expires 2 October 2026 [Page 5]
Internet-Draft HW-attest March 2026
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 Section 7.2.
4. Attester Model
The RATS architecture presented in [RFC9334] 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.
Poulain & Kaci Expires 2 October 2026 [Page 6]
Internet-Draft HW-attest March 2026
4.1. 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.
Poulain & Kaci Expires 2 October 2026 [Page 7]
Internet-Draft HW-attest March 2026
4.2. Integration Models
The following subsections present possible layouts for integrating a
Measurement Unit between the Attesting Environment and the target
hardware component.
4.2.1. 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.
+-------------------------+
+-------------+ Trigger | +---------------+ |
| | Measurement | | | |
| +---------------> | Target HW | |
| Attesting | | | Component | |
| Environment | | | (TE) | |
| | | +---------------+ |
| <---------------+ Measurement Unit |
+-------------+ Export | (AE) |
Measurement +-------------------------+
Figure 1: Abstract Representation of Embedded Measurement Unit
Ex: Different types of Built-In-Self-Tests (BIST) or Known Answer
Tests (KAT).
Note: As shown in Figure 1, 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 Section 8.4.3).
4.2.2. External Measurement Unit
In the following integration models, the Measurement Unit is external
to the target hardware component.
4.2.2.1. Discrete Component
The Measurement Unit is a discrete component external to the target
hardware component and to the Attesting Environment.
Poulain & Kaci Expires 2 October 2026 [Page 8]
Internet-Draft HW-attest March 2026
Trigger
+-------------+ Measurement +------------------+
| +----------------> |
| | | Measurement Unit |
| <----------------+ (AE) |
| | Export +---------^--------+
| Attesting | Measurement |
| Environment | | Data Exchange
| | |
| | +-------v-------+
| | | Target HW |
| | | Component |
+-------------+ | (TE) |
+---------------+
Figure 2: Abstract Representation of Discrete Measurement Unit
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 Section 8.
4.2.2.2. 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 Figure 3.
+-------------------+
| Attesting |
| Environment |
| |
| +-------------+ | Data +---------------+
| | Measurement | | Exchange | Target HW |
| | Unit <--+----------> Component |
| +-------------+ | | (TE) |
| | +---------------+
+-------------------+
Poulain & Kaci Expires 2 October 2026 [Page 9]
Internet-Draft HW-attest March 2026
Figure 3: Abstract Representation of Measurement Unit Integrated
in AE
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 Section 7.2.4).
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 [I-D.richardson-rats-composite-attesters].
4.3. 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.
Poulain & Kaci Expires 2 October 2026 [Page 10]
Internet-Draft HW-attest March 2026
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
Poulain & Kaci Expires 2 October 2026 [Page 11]
Internet-Draft HW-attest March 2026
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.
Figure 4 represents the steps of the measurement journey described
above.
+-------------------------+ Trigger
| Attesting Environment | Measurement +------------------------+
| +-------------> Measurement Unit |
| | | | |
| +---------------------+ | | Compute | |
| | [Optional] | | | Measurement| |
| | Measurement Storage <-+-------------+ +------------v-+ |
| +----------+----------+ | Export | | Target | |
| | | Measurement | | Hardware | |
| +----------v----------+ | | | Component | |
| |[Optional] Processing| | | +--------------+ |
| +----------+----------+ | +------------------------+
| | |
| +----------+----------+ |
| | +--------v--------+ | |
| | | Include | | |
| | | measurement in | | |
| | | Evidence | | |
| | +-----------------+ | |
| | | |
| | Sign Evidence | |
| +---------------------+ |
| |
+-------------------------+
Figure 4: Measurement Journey
Poulain & Kaci Expires 2 October 2026 [Page 12]
Internet-Draft HW-attest March 2026
5. Inclusion in Conceptual Messages
This section introduces standard claims to be included in RATS
Conceptual Messages. Conceptual Messages are defined in Section 8 of
[RFC9334]. 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 [I-D.ietf-rats-corim] and the
EAT is defined in [RFC9711].
To promote interoperability, the following sections showcase how to
use the CoRIM and EAT data models in the context of this document.
5.1. 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 environmental robustness properties (e.g.,
operating temperature range, resistance to environmental conditions),
Measurement Unit characteristics (e.g., accuracy, precision,
uncertainty, sampling rate, sample count, method), 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.
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
5.1.1. Concise Reference Integrity Manifest (CoRIM)
Endorsements can be written inside a CoMID Endorsed Values triple of
a CoRIM (see Section 5.1.6 of [I-D.ietf-rats-corim]). The Endorsed
Values triple holds one or more measurement-map that are used to
write the Endorsements.
5.2. Reference Value
Reference Values must be computed in a secure environment.
Poulain & Kaci Expires 2 October 2026 [Page 13]
Internet-Draft HW-attest March 2026
The Reference Value computed must correspond to the value that will
be outputted in the expected environment of the system once 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 Section 5.3.1.4.1.2). 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 can be a value or a range or a function* of the
operational context of the system and can correspond to a class, a
group or an instance of target hardware component.
*could even be a ML model to detect abnormal physical properties
depending on operational context of the system.
5.2.1. Concise Reference Integrity Manifest (CoRIM)
Reference Values can be written inside a CoMID Reference Values
triple of a CoRIM (see Section 5.1.5 of [I-D.ietf-rats-corim]). The
Reference Values triple holds one or more measurement-map that are
used to write the Reference Values.
5.3. 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.
5.3.1. Entity Attestation Token (EAT)
5.3.1.1. 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 [I-D.ietf-rats-eat-measured-component].
Poulain & Kaci Expires 2 October 2026 [Page 14]
Internet-Draft HW-attest March 2026
For instance, a custom measurement structure can be used to hold
hardware component measurement in the "measurement" field of the
"measured-component" structure from
[I-D.ietf-rats-eat-measured-component]. Also, the flag field can be
used to extend the measured-component base type with profile-defined
semantics.
5.3.1.2. 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 Section 4.2.17 of [RFC9711].
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.
5.3.1.3. 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 (Section 4.2.18 of [RFC9711]).
5.3.1.4. 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
[I-D.ietf-rats-eat-measured-component].
5.3.1.4.1. 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 Table 1.
Poulain & Kaci Expires 2 October 2026 [Page 15]
Internet-Draft HW-attest March 2026
+=============+=======================================+=============+
| IE | Description | Requirement |
| | | Level |
+=============+=======================================+=============+
| Component | The name given to the target | REQUIRED |
| Name | hardware component. | |
+-------------+---------------------------------------+-------------+
| Operational | Additional information on the | OPTIONAL |
| Context | operational context of the | |
| | component. | |
+-------------+---------------------------------------+-------------+
| Measurement | List of measurements for the | REQUIRED |
| List | target hardware component. | |
| | Each element of the list is | |
| | composed of a Measurement Type | |
| | and of a Measurement Value. | |
+-------------+---------------------------------------+-------------+
Table 1: Measured Hardware Component Information Elements
5.3.1.4.1.1. Component Name
Component Name is used to identify the target hardware component.
5.3.1.4.1.2. 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.
Poulain & Kaci Expires 2 October 2026 [Page 16]
Internet-Draft HW-attest March 2026
+============+=============+===================+
| Field Name | Description | Requirement Level |
+============+=============+===================+
+------------+-------------+-------------------+
Table 2: Fields of the Operational Context
Use case example: the measurement may be subject to variations
depending on environmental context such as temperature (ideally
specified in Endorsements, see Section 5.1). 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.
5.3.1.4.1.3. Measurement List
+=================+==================================+=============+
| Field Name | Description | Requirement |
| | | Level |
+=================+==================================+=============+
| Measurement | Identifier for the Measurement | REQUIRED |
| Unit Identifier | Unit used to obtain the | |
| | measurement | |
+-----------------+----------------------------------+-------------+
| Measurement | The type of the measurement. | REQUIRED |
| Type | | |
+-----------------+----------------------------------+-------------+
| Measurement | The Value of the measurement. | REQUIRED |
| Value | The content of this field | |
| | depends on the Measurement Type. | |
+-----------------+----------------------------------+-------------+
Table 3: Content of Elements of the Measurement List
* 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.
Poulain & Kaci Expires 2 October 2026 [Page 17]
Internet-Draft HW-attest March 2026
* 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 Section 6.1.1).
* Measurement Value:
The structure that holds the actual measurement. The structure of
the Measurement Value depends on the Measurement Type.
5.3.2. X.509 Certificate
Appendix C.3 of [RFC9711] describes methods to encode EAT claims in
an X.509 certificate. These methods can be used for the claims
presented in Section 5.3.1.
Ex: DICE uses X.509 certificates with a custom extension to carry
Evidence [TCG-DICE]. TLS and DTLS extended with remote attestation
also use X.509 certificates with an attestation extension
[I-D.fossati-tls-attestation].
6. CDDL Definitions
This section presents CDDL definitions for the Measured Hardware
Component claim to be included in EAT Measurement claim.
6.1. Measured Hardware Component Claim
Poulain & Kaci Expires 2 October 2026 [Page 18]
Internet-Draft HW-attest March 2026
measured-hw-component = {
component-id-label => 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
Figure 5: CDDL of Measured Hardware Component Claim
6.1.1. Measurement Value
6.1.1.1. Physical Property
CDDL definition of the structure of measurement-value when
measurement-type = mt-phys-prop.
mv-phys-prop = {
physical-property-id => tstr,
value => number / bstr / tstr,
; unit, precision, scale, uncertainty,
; are already specified in Endorsements
}
Figure 6: CDDL of Physical Property Measurement Value
Poulain & Kaci Expires 2 October 2026 [Page 19]
Internet-Draft HW-attest March 2026
6.1.1.2. Self-Test
CDDL definition of the structure of measurement-value when
measurement-type = mt-self-test.
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
Figure 7: CDDL of Self-Test Measurement Value
6.1.1.3. Event
CDDL definition of the structure of measurement-value when
measurement-type = mt-event.
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
Figure 8: CDDL of Event Measurement Value
6.1.1.4. Trace
CDDL definition of the structure of measurement-value when
measurement-type = mt-trace.
Poulain & Kaci Expires 2 October 2026 [Page 20]
Internet-Draft HW-attest March 2026
mv-trace = {
trace-type-label => trace-type,
trace-data => bstr / tstr
}
trace-type =
digest /
summary /
counter
Figure 9: CDDL of Trace Measurement Value
6.1.1.5. 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).
6.2. Inclusion in EAT Measurement Claim
The CDDL defined in Section 6.1 extends the $measurements-body-cbor
and $measurements-body-json EAT sockets to add support for the
measured-hw-component to the Measurements claim (Section 4.2.16 of
[RFC9711]).
mhwc-cbor = bytes .cbor measured-hw-component
mhhwc-json = text .json measured-hw-component
; EAT CBOR (`.feature "cbor"`)
$measurements-body-cbor /= mhwc-cbor
; EAT JSON (`.feature "json"`)
$measurements-body-json /= mhwc-json
Figure 10: CDDL Extension of EAT Measurement Body
7. Practical Examples
This section is for informational purposes only.
Note: There are many interesting examples of hardware monitoring in
[ISO5891] that are not covered here but fall in the scope of this
document.
Poulain & Kaci Expires 2 October 2026 [Page 21]
Internet-Draft HW-attest March 2026
7.1. Monitoring Physical Properties
7.1.1. 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 Section 4.2.2.1.
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 Section 5.1).
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
Section 8).
7.1.2. Using an Embedded Sensor
Poulain & Kaci Expires 2 October 2026 [Page 22]
Internet-Draft HW-attest March 2026
7.1.2.1. 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
Section 4.2.1.
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 Section 8.4.3.
7.1.2.2. 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
Section 4.2.1. 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
Poulain & Kaci Expires 2 October 2026 [Page 23]
Internet-Draft HW-attest March 2026
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.
7.2. Detection by Self-Testing
This section provides practical examples that demonstrate how self-
tests can be leveraged to measure a hardware component.
7.2.1. 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 Section 4.2.1.
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
Section 5.3.1.2 and Section 5.3.1.4.
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.
Poulain & Kaci Expires 2 October 2026 [Page 24]
Internet-Draft HW-attest March 2026
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.
7.2.2. 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 Section 4.2.1.
The Measurement Unit continuously or periodically evaluates the
entropy source by executing health tests and entropy estimators
(Section 4 of [NIST-SP-800-90B]). 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 Section 5.3.1.2 and
Section 5.3.1.4.
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.
7.2.3. 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 Section 4.2.2.2.
Poulain & Kaci Expires 2 October 2026 [Page 25]
Internet-Draft HW-attest March 2026
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
Section 8.1.
7.2.4. 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 Section 4.2.1 and Section 4.2.2.2.
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.
Poulain & Kaci Expires 2 October 2026 [Page 26]
Internet-Draft HW-attest March 2026
7.3. 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.
7.4. 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.
Poulain & Kaci Expires 2 October 2026 [Page 27]
Internet-Draft HW-attest March 2026
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.
8. Security Considerations
The security considerations of RATS architecture apply (Section 12 of
[RFC9334]). 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
(Section 5 of [I-D.ietf-rats-eat-measured-component]) when using EAT
Measured Component claim or Measured Hardware Component Claim.
The security considerations related to X.509 certificates apply
(Section 8 of [RFC5280]) when using X.509 certificates to carry
Evidence.
Security considerations of CoRIM apply (Section 11 of
[I-D.ietf-rats-corim]) 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 Section 4.3).
8.1. 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 !).
Poulain & Kaci Expires 2 October 2026 [Page 28]
Internet-Draft HW-attest March 2026
8.2. Multiple Attesting Environments
In case of multiple Attesting Environments, distribution of freshness
and binding of Evidence are discussed in
[I-D.richardson-rats-composite-attesters].
8.3. 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).
8.4. Threat Model
8.4.1. 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.
8.4.2. 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.
8.4.2.1. 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 Section 12.1.1 of [RFC9334].
Poulain & Kaci Expires 2 October 2026 [Page 29]
Internet-Draft HW-attest March 2026
8.4.2.2. 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 bypass 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).
Ex: Glitching, fault injections to induce malicious behavior. May
tamper with the target hardware component itself or the Measurement
Unit or the logic used to build Evidence.
Ex: Memory tampering attacks to modify stored measurements.
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, redundancy, sensors,
active meshes, nose injection, etc. Note that some of these
mitigations cannot directly prevent attacks but can be used for
detection.
8.4.3. Supply Chain Attacks
Each stage of the supply chain introduces a new opportunity for an
attacker to tamper with the produced system.
Supply chains attacks may lead to the injection of Trojans. Once a
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 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 Trojan, then it cannot be trusted.
9. Privacy Considerations
The privacy considerations of RATS architecture apply (Section 11 of
[RFC9334]).
Poulain & Kaci Expires 2 October 2026 [Page 30]
Internet-Draft HW-attest March 2026
The privacy considerations of EAT Measured Component apply (Section 6
of [I-D.ietf-rats-eat-measured-component]) when using EAT Measured
Component claim or Measured Hardware Component Claim.
Privacy considerations of CoRIM apply (Section 11 of
[I-D.ietf-rats-corim]) 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.
10. 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 that aging or environmental context affect
sensors.
These considerations must be taken into account and mitigated to an
acceptable level by the designer.
11. IANA Considerations
This document has no IANA actions. TODO need IANA actions for claims
defined in this document ?
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
Poulain & Kaci Expires 2 October 2026 [Page 31]
Internet-Draft HW-attest March 2026
12.2. Informative References
[I-D.fossati-tls-attestation]
Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I.,
Deshpande, Y., Niemi, A., and T. Fossati, "Using
Attestation in Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS)", Work in Progress,
Internet-Draft, draft-fossati-tls-attestation-09, 30 April
2025, <https://datatracker.ietf.org/doc/html/draft-
fossati-tls-attestation-09>.
[I-D.ietf-rats-corim]
Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and
W. Pan, "Concise Reference Integrity Manifest", Work in
Progress, Internet-Draft, draft-ietf-rats-corim-10, 2
March 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-rats-corim-10>.
[I-D.ietf-rats-eat-measured-component]
Frost, S., Fossati, T., Tschofenig, H., and H. Birkholz,
"Entity Attestation Token (EAT) Measured Component", Work
in Progress, Internet-Draft, draft-ietf-rats-eat-measured-
component-12, 20 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
eat-measured-component-12>.
[I-D.richardson-rats-composite-attesters]
Richardson, M., Birkholz, H., Deshpande, Y., and T.
Fossati, "Taxonomy of Composite Attesters", Work in
Progress, Internet-Draft, draft-richardson-rats-composite-
attesters-04, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-richardson-
rats-composite-attesters-04>.
[ISO5891] International Standards Organization, "ISO/IEC TR
5891:2024, Information security, cybersecurity and privacy
protection — Hardware monitoring technology for hardware
security assessment", April 2024,
<https://www.iso.org/fr/standard/81806.html>.
[NIST-SP-800-90B]
National Institute of Standards and Technology,
"Recommendation for the Entropy Sources Used for Random
Bit Generation", January 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
nist.sp.800-90b.pdf>.
Poulain & Kaci Expires 2 October 2026 [Page 32]
Internet-Draft HW-attest March 2026
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/rfc/rfc9711>.
[TCG-DICE] Trusted Computing Group, "DICE Attestation Architecture,
Version 1.00, Revision 0.23", March 2021,
<https://trustedcomputinggroup.org/wp-content/uploads/
DICE-Attestation-Architecture-r23-final.pdf>.
Appendix A. Collected CDDL
This appendix contains all the CDDL definitions included in this
document.
mhwc-cbor = bytes .cbor measured-hw-component
mhhwc-json = text .json measured-hw-component
; EAT CBOR (`.feature "cbor"`)
$measurements-body-cbor /= mhwc-cbor
; EAT JSON (`.feature "json"`)
$measurements-body-json /= mhwc-json
measured-hw-component = {
component-id-label => 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 /
Poulain & Kaci Expires 2 October 2026 [Page 33]
Internet-Draft HW-attest March 2026
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
Poulain & Kaci Expires 2 October 2026 [Page 34]
Internet-Draft HW-attest March 2026
}
trace-type =
digest /
summary /
counter
Acknowledgments
Many thanks to Sylvain Guilley for reviewing the document and
providing valuable comments.
Authors' Addresses
Antoine Poulain
Secure-IC
Email: antoine.poulain@secure-ic.com
Abdellah Kaci
Secure-IC
Email: abdellah.kaci@secure-ic.com
Poulain & Kaci Expires 2 October 2026 [Page 35]