Distributed Remote Attestation
draft-wang-rats-distributed-remote-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.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Wangdonghui , Faye Liu | ||
| Last updated | 2025-07-06 | ||
| RFC stream | (None) | ||
| Formats | |||
| 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-wang-rats-distributed-remote-attestation-00
Remote ATtestation ProcedureS D. Wang
Internet-Draft F. Liu
Intended status: Standards Track Huawei
Expires: 6 January 2026 5 July 2025
Distributed Remote Attestation
draft-wang-rats-distributed-remote-attestation-00
Abstract
In the RATS architecture, remote attestation typically involves
multiple roles: verifier, attester, endorser, reference value
provider, and relying party. However, in complex networks, the large
number of entities in each role can significantly increase the cost
of communication and computational resources. This document proposes
a simplified remote attestation method based on distributed
ledger(DL) technology, which aims to reduce the overhead for
participants in multi-party networks.
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 6 January 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang & Liu Expires 6 January 2026 [Page 1]
Internet-Draft DRA July 2025
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
4. DRA patterns . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. on-chain-based publication/attestation and off-chain-based
verification . . . . . . . . . . . . . . . . . . . . . . 4
4.2. on-chain-based publication/attestation/verification . . . 6
4.3. on-chain-based publication and off-chain-based attestation/
verification . . . . . . . . . . . . . . . . . . . . . . 7
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Unpredictability of PC . . . . . . . . . . . . . . . . . 8
5.2. Freshness Analysis . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Consideration . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
In the current remote attestation procedures, the attester needs to
demonstrate the freshness of the evidence, which is achieved by
including some fresh data within the evidence. For instance, RFC
9334 [RFC9334] proposes may use a random number provided by the
verifier/relying party , or an epoch ID sended by a distributor as
the freshness proof. Since the freshness proofs are generated by a
specific verifier or distributed for a specific verifier, the AE
generated based on these freshness proofs cannot be verified by other
verifier. This means that the computational results cannot be
reused. For instance, when the attester needs to establish
communication with multiple verifiers, even if the AE is highly
similar, the attester still has to compute multiple AEs based on each
verifier's challenge which cost multiple computational resources.
Wang & Liu Expires 6 January 2026 [Page 2]
Internet-Draft DRA July 2025
To address this issue, it is reasonalble to introduce a trusted
institution that can periodically provide unpredictable public random
to the attester for generating a pulic AE that could be verified by
multiple verifiers. This document proposes a method that uses the
hash of the latest block in DL as a public challenge(PC). Since the
DL is maintained by multiple participants in the network based on a
consensus mechanism, it is trustworthy, and the hash of the block is
fresh because it has a timestamp that proves its generation time.
Thus, this hash can serve as a PC for the attester, eliminating the
need for the attester to repeatedly compute based on each verifier's
challenge thereby simplifying the computational load of the attester
and the communication between the verifiers and the attester.
In addition to serving as a PC provider, DL can offer more services
for RAT. For example, it can act as a secure and trustworthy
platform for information sharing. Reference value providers and
secure hardware platform manufacturers (endorsers) can publish their
reference values (RV) or public keys (PK) to reduce the workload for
verifiers to obtain them one by one. Furthermore, based on the DL,
verifiers can publish their attestation results (AR), allowing other
verifiers or relying parties to reuse these ARs.
Furthermore, smart contracts can be deployed on DL to execute AE
verification functions, which is more trustworthy compared to single
verifier verification. When a smart contract is executed, the
execution result must be agreed by the majority of nodes before it is
confirmed. Even if some nodes are compromised/attacked, other nodes
can still ensure continuous and accurate verification, avoiding the
impact of single-point failures. Finally, the smart contract
publishes the verified results on the DL for use by the relying
parties.
Based on the above research, this document describes various
combination patterns of the above three processes and existing
processes, there are three modes: on-chain-based publication/
attestation and off-chain-based verification, on-chain-based
publication and off-chain-based attestation/verification, and on-
chain-based publication/attestation/verification.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Wang & Liu Expires 6 January 2026 [Page 3]
Internet-Draft DRA July 2025
3. Conventions and Definitions
On-chain-based Publication: In DRA, this refers to the process for
publishing key data (e.g., PK and RV) used for verification or the
process for publishing verification results (AR).
On-chain-based Attestation: In DRA, this refers to the process in
which an attester generates AE using the DL hash as the challenge.
Off-chain-based Attestation: In DRA, this refers to the process in
which an attester generates AE via traditional methods, such as
responding to a challenge sended by the verifier or relying party.
On-chain-based Verification: In DRA, this refers to the process in
which a smart contract deployed on the DL verifies AE.
Off-chain-based Verification: In DRA, this refers to the process in
which a verifier verifies AE using conventional methods.
4. DRA patterns
4.1. on-chain-based publication/attestation and off-chain-based
verification
Wang & Liu Expires 6 January 2026 [Page 4]
Internet-Draft DRA July 2025
+-------------------+ +-------------------+
| Reference | | Endorsers |
| value providers | | |
+-------------------+ +-------------------+
| |
| |
| (0) RV | (0)PK
| |
+------- --v-------------------------------------------v-----------+
| |
| Distributed Ledger(Remote attestation service,RAS) |
| |
+-----------------------------------^------------------------------+
| | | |
| | | |
(1)PC | (4)VR,PK | | (5)AR |(6)AR
| | | |
| | | |
+--------v-----+ +-v---------+ +--------v-------+
| | (3)AE | | | Relying |
| Attester |-------->| Verifier | | party |
| | | | | |
+--------------+ +-----------+ +----------------+
(2)AE
Figure 1 on-chain-based publication/attestation and off-chain-based verification
As shown in Figure 1, one mode of DRA is on-chain-based publication/
attestation and off-chain-based verification.
0) Registration: Reference value providers and endorsers register RVs
and PKs with the DL.
1-2) AE Generation: The attester retrieves the latest block hash from
DL as a challenge to generate the AE. By leveraging the immutable
timestamp recorded in the block header of the DL, the generated AE is
inherently bound to the exact time of its creation, ensuring
verifiable freshness. The attester can initiate this process either
in response to a request from the verifier/relying Party or
proactively through an autonomous trigger mechanism.
3) AE Transmission: The attester sends the AE to the verifier. The
attester can reuse the same AE with multiple verifiers if need.
4) AE Verification: The verifier queries the DL to retrieve the RV,
PK and check the freshness of the challenge and verify the AE.
Wang & Liu Expires 6 January 2026 [Page 5]
Internet-Draft DRA July 2025
5) AR Generation: The verifier generates an attestation result after
a successful verification, then publishes it on the DL.
6) AR Acquisition: The Relying Party can directly query and obtain
the AR from the DL.
4.2. on-chain-based publication/attestation/verification
+-------------------+ +-------------------+
| Reference | | Endorsers |
| value providers | | |
+-------------------+ +-------------------+
| |
| |
| (0) RV | (0)PK
| |
+----------v-------------------------------------------v-----------+
| |
| +----------------+ +----------------+ |
| | Registration | | Verification | |
| | smart | | smart | |
| | contract | | contract | |
| +----------------+ +----------------+ |
| |
| Distributed Ledger(Remote attestation service,RAS) |
| |
+-------------^----------------------------------------------------+
| | |
| | |
(1) (PC)| | (2)AE |(3)AR
| | |
| | |
+---v----------+ +---------v--------+
| | | Verifier/Relying |
| Attester | | party |
| | | |
+--------------+ +------------------+
Figure 2 on-chain-based publication/attestation/verification
As shown in Figure 2, the second mode of DRA is n-chain-based
publication/attestation/verification.
0) Registration: Reference value providers and endorsers register RVs
and PKs with the DL.
Wang & Liu Expires 6 January 2026 [Page 6]
Internet-Draft DRA July 2025
1-2) AE Generation and Verification: The attester retrieves the
latest block hash from the DL as a challenge, generates the AE, and
publishes it to the DL by invoking the registration smart contract.
Subsequently, the verification smart contract——triggered either by
the Verifier or the registration smart contract——executes the AE
verification process.
3) AR Acquisition: The relying party can directly query and obtain
the attestation result from the DL.
4.3. on-chain-based publication and off-chain-based attestation/
verification
+-------------------+ +-------------------+
| Reference | | Endorsers |
| value providers | | |
+-------------------+ +-------------------+
| |
| |
| (0) RV | (0)PK
| |
+------- --v-------------------------------------------v-----------+
| |
| Distributed Ledger(Remote attestation service,RAS) |
| |
+-----------------------------------^------------------------------+
| | |
(3)VR,PK | | (4)AR |(6)AR
| | |
| | |
| | |
+------------+(1)challenge +--v--------+ +------v--------+
| |<------------| | | Relying |
| Attester | | Verifier | | party |
| |------------>| | | |
+------------+ (2)AE +-----------+ +---------------+
Figure 3 on-chain-based publication and off-chain-based attestation/verification
As shown in Figure 3, the third mode of DRA is on-chain-based
publication/attestation and off-chain-based verification.
0) Registration: Reference value providers and endorsers register RVs
and PKs with the DL.
Wang & Liu Expires 6 January 2026 [Page 7]
Internet-Draft DRA July 2025
1-2) AE Verification: Same as the existing verification process, the
verifier sends a challenge to the attester. In response, the
attester generates the AE and submits it directly to the verifier.
3) AR Generation: After an successful verification, the verifier
generates the AR.
4) AR publication: Verifier publishes AR to the DL.
5) AR AcquisitionThe relying party can directly obtain the result
from the DL.
5. Discussion
5.1. Unpredictability of PC
The block generation mechanism of DL is driven by a consensus
algorithm among nodes. Nodes package transaction data based on
established algorithmic logic, forming a block that includes the hash
of the previous block, a timestamp, and the current set of
transactions. After being verified by the majority of nodes in the
DL network, the block is added to the DL. Due to the uncertainty of
timestamps and transaction sets, DL nodes cannot predict the hash of
the next block in advance. Moreover, because of the one-way feature
of hash functions, attackers cannot predefine a hash and reverse-
engineer or construct the original data to generate the desired hash.
These characteristics collectively determine the uniqueness and
unpredictability of block hashes, thereby ensuring the security of
PC.
5.2. Freshness Analysis
For the DRA service, the blocks of the distributed ledger (DL) need
to be generated at appropriate time intervals, such as every few
seconds. The consensus rules trigger the new block generation
process periodically through preset time parameters. Even if there
is no transaction data within a specific period, nodes will still
generate an empty block containing basic information like the hash of
the previous block and timestamps according to established
algorithms. This approach aims to maintain the continuity of the DL
chain structure and the orderliness of timestamps, thereby ensuring
the freshness and validity of PC.
6. IANA Considerations
This document has no IANA considerations.
Wang & Liu Expires 6 January 2026 [Page 8]
Internet-Draft DRA July 2025
7. Security Consideration
TODO
8. References
8.1. Normative Reference
[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>.
8.2. Informative References
[RFC9334] Thaler, D., Richardson, M., Smith, M., and W. Pan, "Remote
ATtestation procedureS (RATS) Architecture", January 2023,
<https://datatracker.ietf.org/doc/rfc9334/>.
Acknowledgments
TODO
Authors' Addresses
Donghui Wang
Huawei
Email: wangdonghui124@huawei.com
Faye Liu
Huawei
Email: liufei19@huawei.com
Wang & Liu Expires 6 January 2026 [Page 9]