[要約] この文書は、Trusted Computing Group（TCG）によって定義されたTrusted Platform Modules（TPMs）を含むネットワークデバイスにインストールされたファームウェアとソフトウェアの整合性をリモートで証明するワークフローについて説明しています。
Internet Engineering Task Force (IETF) G. C. Fedorkow, Ed.
Request for Comments: 9683 Juniper Networks, Inc.
Category: Informational E. Voit
ISSN: 2070-1721 Cisco
J. Fitzgerald-McKay
National Security Agency
December 2024
This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules (TPMs), as defined by the Trusted Computing Group (TCG), or equivalent hardware implementations that include the protected capabilities, as provided by TPMs.
このドキュメントは、トラステッドコンピューティンググループ（TCG）によって定義されているトラステッドプラットフォームモジュール（TPM）や、TPMが提供する保護された機能を含む同等のハードウェア実装を搭載するネットワークデバイスにインストールされたファームウェアとソフトウェアの整合性をリモートで検証するワークフローについて説明します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準トラック仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の成果物です。IETFコミュニティの総意を反映しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）によって発行が承認されました。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補となるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9683.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9683で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書の著者として特定された者。無断転載を禁じます。
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.
このドキュメントは、BCP 78および本書の公開日に有効なIETFトラストのIETFドキュメントに関する法的規定（https://trustee.ietf.org/license-info）に従うものです。これらのドキュメントは、本書に関するあなたの権利と制限を説明していますので、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントは、トラスト法的規定のセクション4.eに記載されている改訂BSDライセンスのテキストを含める必要があり、改訂BSDライセンスに記載されているように、保証なしで提供されます。
1. Introduction
1.1. Requirements Notation
1.2. Terminology
1.3. Document Organization
1.4. Goals
1.5. Description of Remote Integrity Verification (RIV)
1.6. Solution Requirements
1.7. Scope
1.7.1. Out of Scope
2. Solution Overview
2.1. RIV Software Configuration Attestation Using TPM
2.1.1. What Does RIV Attest?
2.1.2. Notes on PCR Allocations
2.2. RIV Keying
2.3. RIV Information Flow
2.4. RIV Simplifying Assumptions
2.4.1. Reference Integrity Manifests (RIMs)
2.4.2. Attestation Logs
3. Standards Components
3.1. Prerequisites for RIV
3.1.1. Unique Device Identity
3.1.2. Keys
3.1.3. Appraisal Policy for Evidence
3.2. Reference Model for Challenge-Response
3.2.1. Transport and Encoding
3.3. Centralized vs. Peer-to-Peer
4. Privacy Considerations
5. Security Considerations
5.1. Keys Used in RIV
5.2. Prevention of Spoofing and Person-in-the-Middle Attacks
5.3. Replay Attacks
5.4. Owner-Signed Keys
5.5. Other Factors for Trustworthy Operation
6. IANA Considerations
7. Conclusion
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Supporting Materials
A.1. Using a TPM for Attestation
A.2. Root of Trust for Measurement (RTM)
A.3. Layering Model for Network Equipment Attester and Verifier
A.4. Implementation Notes
Acknowledgements
Authors' Addresses
There are many aspects to consider in fielding a trusted computing device, from operating systems to applications. Mechanisms to prove that a device installed at a customer's site is authentic (i.e., not counterfeit) and has been configured with authorized software, all as part of a trusted supply chain, are just a few of the many aspects that need to be considered concurrently to have confidence that a device is truly trustworthy.
オペレーティングシステムからアプリケーションまで、信頼できるコンピューティングデバイスを展開する際に考慮すべき多くの側面があります。顧客のサイトにインストールされているデバイスが本物であり（つまり、偽造ではない）、信頼できるサプライチェーンの一部として認定ソフトウェアで構成されていることを証明するメカニズムは、デバイスが本当に信頼できると確信するためには、同時に考慮する必要がある多くの側面のほんの一部にすぎません。
A generic architecture for remote attestation has been defined in [RFC9334]. Additionally, use cases for remotely attesting networking devices are discussed within Section 5 of [RATS-USECASES]. However, these documents do not provide sufficient guidance for network equipment vendors and operators to design, build, and deploy interoperable devices.
リモートアテステーションのための一般的なアーキテクチャは、[RFC9334]で定義されています。さらに、ネットワークデバイスをリモートで証明するユースケースは、[RATS-USECASES]のセクション5で議論されています。ただし、これらのドキュメントでは、ネットワーク機器ベンダーとオペレーターが相互運用可能なデバイスを設計、構築、展開するための十分なガイダンスを提供していません。
The intent of this document is to provide such guidance. It does this by outlining the Remote Integrity Verification (RIV) problem and then by identifying the necessary elements to get the complete, scalable attestation procedure working with commercial networking products such as routers, switches, and firewalls. An underlying assumption is the availability within the device of a cryptoprocessor that is compatible with the Trusted Platform Module specifications [TPM-1.2] [TPM-2.0] to enable the trustworthy, remote assessment of the device's software and hardware.
このドキュメントの目的は、そのようなガイダンスを提供することです。リモート整合性検証（RIV）の問題を概説し、ルーター、スイッチ、ファイアウォールなどの商用ネットワーク製品で機能する完全でスケーラブルなアテステーション手順を実現するために必要な要素を特定することで、これを実現します。根本的な仮定は、デバイスのソフトウェアとハードウェアの信頼できるリモート評価を可能にするために、トラステッドプラットフォームモジュール仕様[TPM-1.2][TPM-2.0]と互換性のある暗号プロセッサがデバイス内で利用可能であることです。
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.
「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL」のキーワードは、本書で示されているようにすべて大文字で表記されている場合にのみ、BCP 14 [RFC2119] [RFC8174]で説明されているとおりに解釈されます。
A number of terms are reused from [RFC9334]. These include Appraisal Policy for Evidence, Attestation Result, Attester, Evidence, Reference Value, Relying Party, Verifier, and Verifier Owner.
[RFC9334]から多くの用語が再利用されます。これらには、証拠の評価ポリシー、アテステーション結果、アテスター、証拠、参照値、依拠当事者、検証者、および検証者オーナーが含まれます。
Additionally, this document defines the following term:
さらに、このドキュメントは次の用語を定義します。
Attestation:
証明：
The process of generating, conveying, and appraising claims, backed by evidence, about device trustworthiness characteristics, including supply chain trust, identity, device provenance, software configuration, device composition, compliance to test suites, functional and assurance evaluations, etc.
サプライチェーンの信頼、アイデンティティ、デバイスの来歴、ソフトウェア構成、デバイスの構成、テストスイートへの準拠、機能評価および保証評価など、デバイスの信頼性特性に関する、証拠に裏付けられた主張を生成、伝達、および評価するプロセス。
The goal of attestation is simply to assure an administrator or auditor that the device's configuration and software were authentic and unmodified when the device started. The determination of software authenticity is not prescribed in this document, but it's typically taken to mean a software image generated by an authority trusted by the administrator, such as the device manufacturer.
アテステーションの目標は、デバイスの構成とソフトウェアがデバイス開始時に真正であり、改ざんされていないことを管理者または監査人に保証することです。ソフトウェアの真正性の決定は本書では規定されていませんが、通常、デバイスメーカーなどの管理者が信頼する当局によって生成されたソフトウェアイメージを意味すると解釈されます。
Within the context of the Trusted Computing Group (TCG), the scope of attestation is typically narrowed to describe the process by which an independent Verifier can obtain cryptographic proof as to the identity of the device in question, evidence of the integrity of the device's software that was loaded upon startup, and verification that the current configuration matches the intended configuration. For network equipment, a Verifier capability can be embedded in a Network Management Station, a posture collection server, or other network analytics tool (such as a software asset management solution, or a threat detection and mitigation tool, etc.). This document focuses on a specific subset of attestation tasks, defined here as Remote Integrity Verification (RIV), and informally referred to as attestation. RIV in this document takes a network-equipment-centric perspective that includes a set of protocols and procedures for determining whether a particular device was launched with authentic software, starting from Roots of Trust. While there are many ways to accomplish attestation, RIV sets out a specific set of protocols and tools that work in environments commonly found in network equipment. RIV does not cover other device characteristics that could be attested (e.g., geographic location or connectivity; see [RATS-USECASES]), although it does provide evidence of a secure infrastructure to increase the level of trust in other device characteristics attested by other means (e.g., by Entity Attestation Tokens [RATS-EAT]).
トラステッドコンピューティンググループ（TCG）のコンテキストでは、アテステーションの範囲は通常、独立した検証者が、問題のデバイスのアイデンティティ、起動時にロードされたデバイスソフトウェアの整合性の証拠、および現在の構成が意図された構成と一致することの検証に関する暗号化された証明を取得するプロセスを記述するために絞り込まれます。ネットワーク機器の場合、検証機能はネットワーク管理ステーション、ポスチャ収集サーバー、またはその他のネットワーク分析ツール（ソフトウェア資産管理ソリューション、脅威検出および緩和ツールなど）に組み込むことができます。このドキュメントでは、リモート整合性検証（RIV）としてここで定義され、非公式にはアテステーションと呼ばれる特定のサブセットのアテステーションタスクに焦点を当てています。本書のRIVは、信頼の基点から始まる真正なソフトウェアで特定のデバイスが起動されたかどうかを判断するための一連のプロトコルと手順を含む、ネットワーク機器中心の視点を取り入れています。アテステーションを達成する方法は多数ありますが、RIVはネットワーク機器で一般的に見られる環境で機能する特定のプロトコルとツールのセットを定めています。RIVは、アテステーション可能な他のデバイス特性（例：地理的位置や接続性。 [RATS-USECASES]を参照）を対象としていませんが、他の手段（例：エンティティアテステーショントークン[RATS-EAT]による）でアテステーションされる他のデバイス特性に対する信頼度を高めるためのセキュアなインフラストラクチャの証拠は提供します。
In line with definitions found in [RFC9334], this document uses the term Endorser to refer to the role that signs identity and attestation certificates used by the Attester, while Reference Values are signed by a Reference Value Provider. Typically, the manufacturer of a network device would be accepted as both the Endorser and Reference Value Provider, although the choice is ultimately up to the Verifier Owner.
[RFC9334]の定義に沿って、本書では、アテスターが使用するIDおよびアテステーション証明書に署名する役割を「エンダーサー」という用語で参照し、参照値は参照値プロバイダーによって署名されます。通常、ネットワークデバイスの製造元は、エンダーサーと参照値プロバイダーの両方として受け入れられますが、最終的な選択は検証者オーナーに委ねられています。
The remainder of this document is organized into several sections:
このドキュメントの残りの部分は、いくつかのセクションに編成されています。
* The remainder of this section covers goals and requirements, plus a top-level description of RIV.
* このセクションの残りの部分では、目標と要件、およびRIVのトップレベルの記述を扱っています。
* The Solution Overview section (Section 2) outlines how RIV works.
* ソリューションの概要セクション（セクション2）では、RIVの仕組みの概要を説明します。
* The Standards Components section (Section 3) links components of RIV to normative standards.
* 標準コンポーネントセクション（セクション3）は、RIVのコンポーネントを規範的標準にリンクします。
* The Privacy and Security Considerations sections (Sections 4 and 5) shows how specific features of RIV contribute to the trustworthiness of the Attestation Result.
* プライバシーとセキュリティの考慮事項セクション（セクション4および5）は、RIVの特定の特徴が認証結果の信頼性にどのように貢献するかを示しています。
* Supporting material is in an appendix (Appendix A).
* サポート資料は付録（付録A）にあります。
Network operators benefit from a trustworthy attestation mechanism that provides assurance that their network comprises authentic equipment and has loaded software free of known vulnerabilities and unauthorized tampering. In line with the overall goal of assuring integrity, attestation can be used to assist in asset management, vulnerability and compliance assessment, plus configuration management.
ネットワークオペレーターは、ネットワークが本物の機器で構成され、既知の脆弱性や不正な改ざんのないソフトウェアをロードしたという保証を提供する信頼できるアテステーションメカニズムの恩恵を受けます。完全性を保証するという全体的な目標に沿って、資産管理、脆弱性、コンプライアンス評価、および構成管理を支援するためにアテステーションを使用できます。
The RIV attestation workflow outlined in this document is intended to meet the following high-level goals:
このドキュメントで概説されているRIVアテステーションワークフローは、次の高レベルの目標を満たすことを目的としています。
* Provable Device Identity - This specification requires that an Attester (i.e., the attesting device) includes a cryptographic identifier unique to each device. Effectively, this means that the device's TPM must be provisioned with this during the manufacturing cycle.
* 証明可能なデバイスID - この仕様では、Attester（すなわち、アテステーションを行うデバイス）が各デバイスに固有の暗号化識別子を含むことを要求します。事実上、これは製造サイクル中にデバイスのTPMにこれがプロビジョニングされている必要があることを意味します。
* Software Inventory - Key goals are to identify the software release(s) installed on the Attester and to provide evidence that the software stored within hasn't been altered without authorization.
* ソフトウェアインベントリ - 重要な目標は、Attesterにインストールされたソフトウェアリリースを特定し、内部に保存されているソフトウェアが許可なしに変更されていないという証拠を提供することです。
* Verifiability - Verification of the device's software and configuration shows that the software that the administrator authorized for use was actually launched.
* 検証可能性 - デバイスのソフトウェアと構成の検証は、管理者が使用することを許可したソフトウェアが実際に起動されたことを示しています。
In addition, RIV is designed to operate either in a centralized environment, such as with a central authority that manages and configures a number of network devices, or "peer-to-peer", where network devices independently verify one another to establish a trust relationship. (See Section 3.3.)
さらに、RIVは、多数のネットワークデバイスを管理および構成する中央機関などの集中環境、またはネットワークデバイスが相互に独立して検証し、信頼関係を確立する「ピアツーピア」環境のいずれでも動作するように設計されています。（セクション3.3を参照してください。）
Attestation requires two interlocking mechanisms between the Attester network device and the Verifier:
アテステーションには、Attesterネットワークデバイスと検証者の間に2つの連動メカニズムが必要です。
* Device Identity is the mechanism that provides trusted identity, which can reassure network managers that the specific devices they ordered from authorized manufacturers for attachment to their network are those that were installed and that they continue to be present in their network. As part of the mechanism for Device Identity, cryptographic proof of the manufacturer's identity is also provided.
* デバイスIDは、信頼できるアイデンティティを提供するメカニズムであり、ネットワークマネージャーは、許可されたメーカーからネットワークへの接続のために注文した特定のデバイスがインストールされ、ネットワーク内に存在し続けていることを確認できます。デバイスIDメカニズムの一部として、メーカーのアイデンティティの暗号学的証明も提供されます。
* Software Measurement is the mechanism that reports the state of mutable software components on the device and that can assure administrators that they have known, authentic software configured to run in their network.
* ソフトウェア測定は、デバイス上の変更可能なソフトウェアコンポーネントの状態を報告し、管理者が既知の真正なソフトウェアがネットワーク内で動作するように設定されていることを保証できるメカニズムです。
By using these two interlocking mechanisms, RIV, which is a component in a chain of procedures, can assure a network operator that the equipment in their network can be reliably identified and that authentic software of a known version is installed on each device. Equipment in the network includes devices that make up the network itself, such as routers, switches, and firewalls.
これら2つの連動メカニズムを使用することで、一連の手順のコンポーネントであるRIVは、ネットワークオペレーターに対し、ネットワーク内の機器が確実に識別され、既知のバージョンの真正なソフトウェアが各デバイスにインストールされていることを保証できます。ネットワーク内の機器には、ルーター、スイッチ、ファイアウォールなど、ネットワーク自体を構成するデバイスが含まれます。
Software used to boot a device can be identified by a chain of measurements, anchored at the start by a Root of Trust for Measurement (RTM) (see Appendix A.2). An attestation function embedded in each stage, verified by the previous stage, measures the next stage and records the result in tamper-resistant storage. A measurement signifies the identity, integrity, and version of each software component registered with an Attester's TPM [TPM-1.2] [TPM-2.0] so that a subsequent verification stage can determine if the software installed is authentic, up-to-date, and free of tampering.
デバイスの起動に使用されるソフトウェアは、測定のための信頼の基点（RTM）によって開始時に固定された一連の測定によって識別できます（付録A.2を参照）。前の段階で検証された各段階に組み込まれたアテステーション機能は、次の段階を測定し、結果を耐タンパー性ストレージに記録します。測定は、AttesterのTPM [TPM-1.2] [TPM-2.0]に登録された各ソフトウェアコンポーネントのID、整合性、およびバージョンを示し、これにより後続の検証段階でインストールされたソフトウェアが真正で最新であり、改ざんされていないかを判断できます。
RIV includes several major processes, which are split between the Attester and Verifier:
RIVにはいくつかの主要なプロセスが含まれます。これらはAttesterとVerifierの間で分担されます。
1. Generation of Evidence is the process whereby an Attester generates cryptographic proof (Evidence) of claims about device properties. In particular, the device identity and its software configuration are both of critical importance.
1. 証拠の生成とは、Attesterがデバイスの特性に関する主張の暗号学的証明（証拠）を生成するプロセスです。特に、デバイスのIDとそのソフトウェア構成はどちらも非常に重要です。
2. Device Identification refers to the mechanism assuring the Relying Party (ultimately, a network administrator) of the identities of devices, and the identities of their manufacturers, that make up their network.
2. デバイス識別とは、依拠当事者（最終的にはネットワーク管理者）に対して、ネットワークを構成するデバイスのIDと、その製造元のIDを保証するメカニズムを指します。
3. Conveyance of Evidence reliably transports the collected Evidence from the Attester to a Verifier to allow a management station to perform a meaningful appraisal in Step 4. The transport is typically carried out via a management network. Although not required for reliable attestation, an encrypted channel may be used to provide integrity, authenticity, or confidentiality once attestation is complete. It should be noted that critical attestation evidence from the TPM is signed by a key known only to TPM, and is not dependent on encryption carried out as part of a reliable transport.
3. 証拠の伝達は、収集された証拠をAttesterからVerifierに確実に転送し、ステップ4で管理ステーションが意味のある評価を実行できるようにします。転送は通常、管理ネットワークを介して行われます。信頼できるアテステーションには必須ではありませんが、アテステーション完了後には、完全性、真正性、または機密性を提供するために暗号化されたチャネルを使用できます。TPMからの重要なアテステーション証拠は、TPMのみに知られているキーによって署名されており、信頼できる転送の一部として実行される暗号化に依存しないことに注意する必要があります。
4. Finally, appraisal of evidence occurs. This is the process of verifying the Evidence received by a Verifier from the Attester and using an Appraisal Policy to develop an Attestation Result, which is used to inform decision-making. In practice, this means comparing the Attester's measurements reported as Evidence with the device configuration expected by the Verifier. Subsequently, the Appraisal Policy for Evidence might match Evidence found against Reference Values (aka Golden Measurements), which represent the intended configured state of the connected device.
4. 最後に、証拠の評価が行われます。これは、AttesterからVerifierが受け取った証拠を検証し、評価ポリシーを使用して意思決定に情報を提供するために使用されるアテステーション結果を開発するプロセスです。実際には、これは、Attesterの証拠として報告された測定値をVerifierが期待するデバイス構成と比較することを意味します。その後、証拠の評価ポリシーは、接続されたデバイスの意図された構成状態を表す参照値（別名ゴールデン測定）に対して見つかった証拠と一致する可能性があります。
All implementations supporting this RIV specification require the support of the following three technologies:
このRIV仕様をサポートするすべての実装には、次の3つのテクノロジーのサポートが必要です。
1. Identity: Device identity in RIV is based on Device Identity (DevID) defined by IEEE Std 802.1AR [IEEE-802-1AR], coupled with careful supply-chain management by the manufacturer. The Initial DevID (IDevID) certificate contains a statement by the manufacturer that establishes the identity of the device as it left the factory. Some applications with a more complex post-manufacture supply chain (e.g., value added resellers), or with different privacy concerns, may want to use alternative mechanisms for platform authentication (for example, TCG Platform Certificates [PLATFORM-CERTS] or post-manufacture installation of Local DevID (LDevID)).
1. ID：RIVにおけるデバイスIDは、IEEE Std 802.1AR [IEEE-802-1AR]で定義されたデバイスID（DevID）に基づいており、製造元による慎重なサプライチェーン管理と組み合わされています。初期DevID（IDevID）証明書には、工場出荷時のデバイスのIDを確立する製造元によるステートメントが含まれています。より複雑な製造後サプライチェーン（例：付加価値再販業者）を持つアプリケーション、または異なるプライバシー懸念を持つアプリケーションでは、プラットフォーム認証に代替メカニズム（例えば、TCGプラットフォーム証明書[PLATFORM-CERTS]や製造後のローカルDevID（LDevID）のインストールなど）を使用したい場合があります。
2. Platform attestation provides evidence of configuration of software elements present in the device. This form of attestation can be implemented with TPM Platform Configuration Registers (PCRs) and Quote and Log mechanisms, which provide cryptographically authenticated evidence to report what software was started on the device through the boot cycle. Successful attestation requires an unbroken chain from a boot-time Root of Trust through all layers of software needed to bring the device to an operational state, in which each stage computes the hash of components of the next stage, then updates the attestation log and the TPM. The TPM can then report the hashes of all the measured hashes as signed evidence called a Quote (see Appendix A.1 for an overview of TPM operation or [TPM-1.2] and [TPM-2.0] for many more details).
2. プラットフォームアテステーションは、デバイスに存在するソフトウェア要素の構成の証拠を提供します。この形式のアテステーションは、TPMプラットフォーム構成レジスタ（PCR）とクォートおよびログメカニズムで実装でき、これらはブートサイクルを通じてデバイスで起動されたソフトウェアを報告するための暗号学的に認証された証拠を提供します。成功したアテステーションには、デバイスを運用状態にするために必要なすべてのソフトウェア層を介した、ブート時の信頼の基点からの途切れないチェーンが必要です。各段階では、次の段階のコンポーネントのハッシュを計算し、アテステーションログとTPMを更新します。TPMはその後、測定されたすべてのハッシュのハッシュを、クォートと呼ばれる署名された証拠として報告できます（TPM操作の概要については付録A.1を、詳細は[TPM-1.2]および[TPM-2.0]を参照してください）。
3. Signed Reference Values (aka reference integrity measurements) must be conveyed from the Reference Value Provider (the entity accepted as the software authority, often the manufacturer of the network device) to the Verifier.
3. 署名された参照値（別名参照整合性測定値）は、参照値プロバイダー（ソフトウェアの権威と認められているエンティティであり、多くの場合ネットワークデバイスの製造元）から検証者に転送する必要があります。
RIV must address the "Lying Endpoint" problem, in which malicious software on an endpoint may subvert the intended function and also prevent the endpoint from reporting its compromised status. (See Section 5 for further Security Considerations.)
RIVは、「Lying Endpoint」問題に対処する必要があります。これは、エンドポイント上の悪意のあるソフトウェアが意図された機能を妨害し、エンドポイントがその侵害された状態を報告するのを防ぐ可能性がある問題です。（さらなるセキュリティに関する考慮事項については、セクション5を参照してください。）
RIV attestation is designed to be simple to deploy at scale. RIV should work "out of the box" as far as possible, that is, with the fewest possible provisioning steps or configuration databases needed at the end user's site. Network equipment is often required to "self-configure", to reliably reach out without manual intervention to prove its identity and operating posture, then download its own configuration, a process which precludes pre-installation configuration. See [RFC8572] for an example of Secure Zero Touch Provisioning (SZTP).
RIVアテステーションは、大規模に展開を容易にするように設計されています。RIVは、可能な限り「箱から出して」動作するべきであり、つまり、エンドユーザーのサイトで必要なプロビジョニング手順や設定データベースを最小限に抑えるべきです。ネットワーク機器はしばしば「自己構成」が求められ、手動介入なしにそのIDと動作状況を確実に証明し、自身の構成をダウンロードする必要があります。このプロセスは、事前インストール構成を排除します。安全なゼロタッチプロビジョニング（SZTP）の例については、[RFC8572]を参照してください。
The need for assurance of software integrity, addressed by Remote Attestation, is a very general problem that could apply to most network-connected computing devices. However, this document includes several assumptions that limit the scope to network equipment (e.g., routers, switches, and firewalls):
リモートアテステーションによって対処されるソフトウェアの整合性を保証する必要性は、ほとんどのネットワーク接続コンピューティングデバイスに適用できる非常に一般的な問題です。ただし、このドキュメントには、ネットワーク機器（例：ルーター、スイッチ、ファイアウォールなど）に範囲を制限するいくつかの仮定が含まれています。
* This solution is for use in non-privacy-preserving applications (for example, networking or industrial Internet of Things (IoT) applications), which avoids the need for a Privacy Certification Authority (also called an Attestation CA) for Attestation Keys (AKs) [AIK-ENROLL] or TCG Platform Certificates [PLATFORM-CERTS].
* このソリューションは、プライバシーを保護しないアプリケーション（例えば、ネットワーキングや産業用モノのインターネット（IoT）アプリケーション）で使用するためのものであり、アテステーションキー（AK）[AIK-ENROLL]またはTCGプラットフォーム証明書[PLATFORM-CERTS]のためのプライバシー認証局（アテステーションCAとも呼ばれる）の必要性を回避します。
* This document assumes network protocols that are common in network equipment such as YANG [RFC7950] and Network Configuration Protocol (NETCONF) [RFC6241], but not generally used in other applications.
* このドキュメントでは、YANG [RFC7950]やネットワーク構成プロトコル（NETCONF）[RFC6241]などのネットワーク機器で一般的なネットワークプロトコルを想定していますが、他のアプリケーションでは一般的には使用されていません。
* The approach outlined in this document mandates the use of a TPM [TPM-1.2] [TPM-2.0] or a compatible cryptoprocessor.
* このドキュメントで概説されているアプローチでは、TPM [TPM-1.2] [TPM-2.0]または互換性のある暗号化プロセッサの使用が義務付けられています。
Run-Time Attestation:
ランタイムアテステーション：
The Linux Integrity Measurement Architecture [IMA] attests each process launched after a device is started (and is in scope for RIV in general), but continuous run-time attestation of Linux or other multi-threaded operating system processes after the OS has started considerably expands the scope of the problem. Many researchers are working on that problem, but this document defers the problem of continuous, in-memory run-time attestation.
Linux Integrity測定アーキテクチャ[IMA]は、デバイス起動後に開始された各プロセスをアテステーションします（そして一般的にRIVの範囲内です）が、OSが起動した後のLinuxまたはその他のマルチスレッドオペレーティングシステムプロセスの継続的なランタイムアテステーションは、問題の範囲を大幅に拡大します。多くの研究者がその問題に取り組んでいますが、このドキュメントは、継続的なメモリ内ランタイムアテステーションの問題を後回しにします。
Multi-Vendor Embedded Systems:
マルチベンダー埋め込みシステム：
Additional coordination would be needed for devices that themselves comprise hardware and software from multiple vendors and are integrated by the end user. Although out of scope for this document, these issues are accommodated in [RFC9334].
複数のベンダーからのハードウェアとソフトウェアで構成され、エンドユーザーによって統合されているデバイスには、追加の調整が必要です。このドキュメントの範囲外ですが、これらの問題は[RFC9334]で対応されています。
Processor Sleep Modes:
プロセッサスリープモード：
Network equipment typically does not "sleep", so sleep and hibernate modes are not considered. Although out of scope for RIV in this document, TCG specifications do encompass sleep and hibernate states, which could be incorporated into remote attestation for network equipment in the future, given a compelling need.
ネットワーク機器は通常「スリープ」しないため、スリープモードとハイバネートモードは考慮していません。このドキュメントのRIVの範囲外ではありますが、TCG仕様にはスリープ状態とハイバネート状態が含まれており、将来的に強力な必要性があれば、ネットワーク機器のリモートアテステーションに組み込むことができます。
Virtualization and Containerization:
仮想化とコンテナ化：
In a non-virtualized system, the host OS is responsible for measuring each user-space file or process throughout the operational lifetime of the system. For virtualized systems, the host OS must verify the hypervisor, but then the hypervisor must manage its own chain of trust through the virtual machine. Virtualization and containerization technologies are increasingly used in network equipment, but are not considered in this document.
非仮想化システムでは、ホストOSは、システムの運用寿命を通じて各ユーザースペースファイルまたはプロセスを測定する責任があります。仮想化システムの場合、ホストOSはハイパーバイザーを検証する必要がありますが、ハイパーバイザーは仮想マシンを介して独自の信頼チェーンを管理する必要があります。仮想化およびコンテナ化技術は、ネットワーク機器でますます使用されていますが、このドキュメントでは考慮されていません。
RIV Attestation is a process that can be used to determine the identity of software running on a specifically identified device. The Remote Attestation steps of Section 1.5 are split into two phases as shown in Figure 1:
RIVアテステーションは、特定されたデバイス上で実行されているソフトウェアのIDを決定するために使用できるプロセスです。セクション1.5のリモートアテステーション手順は、図1に示すように2つのフェーズに分割されます。
* During system startup, or Boot Phase, each distinct software object is "measured" by the Attester. The object's identity, hash (i.e., cryptographic digest), and version information are recorded in a log. Hashes are also extended into the TPM (see Appendix A.1 for more on extending hashes) in a way that can be used to validate the log entries. The measurement process generally follows the layered chain-of-trust model used in Measured Boot, where each stage of the system measures the next one, and extends its measurement into the TPM, before launching it. See Section 3.2 of [RFC9334], "Layered Attestation Environments", for an architectural definition of this model.
* システム起動時、またはブートフェーズ中に、各個別のソフトウェアオブジェクトはAttesterによって「測定」されます。オブジェクトのID、ハッシュ（すなわち、暗号学的ダイジェスト）、およびバージョン情報はログに記録されます。ハッシュは、ログエントリの検証に使用できる方法でTPMに拡張されます（ハッシュの拡張については付録A.1を参照）。測定プロセスは一般に、Measured Bootで使用される階層化された信頼チェーンモデルに従います。このモデルでは、システムの各段階が次の段階を測定し、それを起動する前にその測定値をTPMに拡張します。このモデルのアーキテクチャの定義については、[RFC9334]のセクション3.2「Layered Attestation Environments」を参照してください。
* Once the device is running and has operational network connectivity, verification can take place. A separate Verifier, running in its own trusted environment, will interrogate the network device to retrieve the logs and a copy of the digests collected by hashing each software object, signed by an attestation private key secured by, but never released by, the TPM. The YANG model described in [RFC9684] facilitates this operation.
* デバイスが実行され、運用可能なネットワーク接続があれば、検証が行われます。独自の信頼された環境で実行されている別の検証者は、ネットワークデバイスを照会して、各ソフトウェアオブジェクトをハッシュすることで収集されたダイジェストのログとコピーを取得します。これらは、TPMによって保護され、決して公開されないアテステーション秘密鍵によって署名されます。[RFC9684]で記述されているYANGモデルは、この操作を容易にします。
The result is that the Verifier can verify the device's identity by checking the subject [RFC5280] and signature of the certificate containing the TPM's attestation public key. The Verifier can then verify the log's correctness by accumulating all the hashes in the log and comparing that to the signed digests from the TPM. From there, the Verifier can validate the launched software by comparing the digests in the log with Reference Values.
その結果、検証者は、TPMのアテステーション公開鍵を含む証明書のサブジェクト[RFC5280]と署名をチェックすることにより、デバイスのIDを検証できます。次に、検証者は、ログ内のすべてのハッシュを累積し、それをTPMからの署名されたダイジェストと比較することにより、ログの正確性を検証できます。そこから、検証者は、ログ内のダイジェストを参照値と比較することにより、起動されたソフトウェアを検証できます。
It should be noted that attestation and identity are inextricably linked; signed Evidence that a particular version of software was loaded is of little value without cryptographic proof of the identity of the Attester producing the Evidence.
アテステーションとアイデンティティは不可分に結びついていることに注意すべきです。特定のバージョンのソフトウェアがロードされたという署名された証拠は、証拠を生成するAttesterのアイデンティティの暗号学的証明なしにはほとんど価値がありません。
+-------------------------------------------------------+
| +---------+ +--------+ +--------+ +---------+ |
| |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | |
| +---------+ +--------+ +--------+ +---------+ |
| | | | |
| | | | |
| +------------+-----------+-+ |
| Boot Phase | |
| V |
| +--------+ |
| | TPM | |
| +--------+ |
| Router | |
+--------------------------------|----------------------+
|
| Verification Phase
| +-----------+
+--->| Verifier |
+-----------+
Reset---------------flow-of-time-during-boot...--------->
Figure 1: Layered RIV Attestation Model
図1：層状のRIV証明モデル
In the Boot Phase, measurements are "extended", or hashed, into the TPM as processes start, which result in the TPM containing hashes of all the measured hashes. Later, once the system is operational, signed digests are retrieved from the TPM during the Verification Phase for off-box analysis.
ブートフェーズでは、プロセスが開始されると、測定値がTPMに「拡張」またはハッシュされます。これにより、TPMにはすべての測定ハッシュのハッシュが含まれます。その後、システムが動作すると、署名されたダイジェストは、オフボックス分析のために検証フェーズ中にTPMから取得されます。
TPM attestation is focused on PCRs, but those registers are only vehicles for certifying accompanying Evidence conveyed in log entries. It is the hashes in log entries that are extended into PCRs, where the final PCR values can be retrieved in the form of a structure called a Quote, which is signed by an AK known only to the TPM. The use of multiple PCRs serves only to provide some independence between different classes of object so that one class of objects can be updated without changing the extended hash for other classes. Although PCRs can be used for any purpose, this section outlines the objects within the scope of this document that may be extended into the TPM.
TPMアテステーションはPCRに焦点を当てていますが、これらのレジスタはログエントリで伝えられる付属の証拠を認証するための手段にすぎません。PCRに拡張されるのはログエントリ内のハッシュであり、最終的なPCR値は、TPMのみが知るAKによって署名されたクォートと呼ばれる構造の形式で取得できます。複数のPCRを使用する目的は、異なる種類のオブジェクト間にある程度の独立性を提供し、他の種類の拡張ハッシュを変更することなく、ある種類のオブジェクトを更新できるようにすることです。PCRはあらゆる目的に使用できますが、このセクションでは、TPMに拡張できる本書の範囲内のオブジェクトの概要を説明します。
In general, assignment of measurements to PCRs is a policy choice made by the device manufacturer, selected to independently attest three classes of object:
一般に、PCRへの測定の割り当ては、デバイスメーカーによって行われるポリシーの選択であり、3つの種類のオブジェクトを独立してアテステーションするように選択されます。
Code:
コード：
Instructions to be executed by a CPU.
CPUによって実行される指示。
Configuration:
構成：
Many devices offer numerous options controlled by non-volatile configuration variables that can impact the device's security posture. These settings may have vendor defaults, but often can be changed by administrators, who may want to verify via attestation that the operational state of the settings match their intended state.
多くのデバイスは、デバイスのセキュリティポスチャに影響を与える可能性のある不揮発性構成変数によって制御される多数のオプションを提供しています。これらの設定にはベンダーのデフォルトがある場合がありますが、多くの場合、設定の運用状態が意図した状態と一致することをアテステーションを通じて検証したい管理者によって変更される可能性があります。
Credentials:
資格：
Administrators may wish to verify via attestation that public keys and credentials outside the Root of Trust have not been subject to unauthorized tampering. (By definition, keys protecting the Root of Trust can't be verified independently.)
管理者は、アテステーションを通じて、信頼の基点外の公開鍵と資格情報が不正な改ざんの対象になっていないことを確認したいと考えるかもしれません。（定義上、信頼の基点を保護する鍵は独立して検証できません。）
The "TCG PC Client Specific Platform Firmware Profile Specification" [PC-CLIENT-BIOS-TPM-2.0] details what is to be measured during the Boot Phase of platform startup using a Unified Extensible Firmware Interface (UEFI) BIOS (<www.uefi.org>), but the goal is simply to measure every bit of code executed in the process of starting the device, along with any configuration information related to security posture, leaving no gap for unmeasured code to remain undetected and potentially subverting the chain.
「TCG PCクライアント固有のプラットフォームファームウェアプロファイル仕様」[PC-CLIENT-BIOS-TPM-2.0]は、Unified Extensible Firmware Interface (UEFI) BIOS (<www.uefi.org>) を使用したプラットフォーム起動のブートフェーズ中に測定されるべき内容を詳述していますが、その目的は、デバイス起動のプロセスで実行されるすべてのコードと、セキュリティポスチャに関連するあらゆる構成情報を測定することであり、未測定のコードが検出されずにチェーンを潜在的に転覆させる隙間を残さないことです。
For devices using a UEFI BIOS, [PC-CLIENT-BIOS-TPM-2.0] and [PC-CLIENT-EFI-TPM-1.2] give detailed normative requirements for PCR usage. For other platform architectures, where TCG normative requirements currently do not exist, Table 1 gives non-normative guidance for PCR assignment that generalizes the specific details of [PC-CLIENT-BIOS-TPM-2.0].
UEFI BIOSを使用したデバイスの場合、[PC-CLIENT-BIOS-TPM-2.0]および[PC-CLIENT-EFI-TPM-1.2]は、PCR使用に関する詳細な規範的要件を提供します。TCGの規範的要件が現在存在しない他のプラットフォームアーキテクチャの場合、表1は[PC-CLIENT-BIOS-TPM-2.0]の具体的な詳細を一般化するPCR割り当てに関する非規範的なガイダンスを提供します。
By convention, most PCRs are assigned in pairs, with the even-numbered PCR used to measure executable code and the odd-numbered PCR used to measure whatever data and configuration are associated with that code. It is important to note that each PCR may contain results from dozens (or even thousands) of individual measurements.
慣例により、ほとんどのPCRはペアで割り当てられ、偶数番号のPCRは実行可能コードを測定するために使用され、奇数番号のPCRはそのコードに関連付けられたデータと構成を測定するために使用されます。各PCRには、数十（または数千）の個々の測定結果が含まれる場合があることに注意することが重要です。
+===========================================+======================+
| | Assigned PCR # |
+===========================================+======+===============+
| Function | Code | Configuration |
+===========================================+======+===============+
| Firmware Static Root of Trust (i.e., | 0 | 1 |
| initial boot firmware and drivers) | | |
+-------------------------------------------+------+---------------+
| Drivers and initialization for optional | 2 | 3 |
| or add-in devices | | |
+-------------------------------------------+------+---------------+
| OS loader code and configuration (i.e., | 4 | 5 |
| the code launched by firmware) to load an | | |
| operating system kernel. These PCRs | | |
| record each boot attempt, and an | | |
| identifier for where the loader was found | | |
+-------------------------------------------+------+---------------+
| Vendor-specific measurements during boot | 6 | 6 |
+-------------------------------------------+------+---------------+
| Secure Boot Policy. This PCR records | | 7 |
| keys and configuration used to validate | | |
| the OS loader | | |
+-------------------------------------------+------+---------------+
| Measurements made by the OS loader (e.g., | 8 | 9 |
| GRUB2 for Linux) | | |
+-------------------------------------------+------+---------------+
| Measurements made by OS (e.g., Linux IMA) | 10 | 10 |
+-------------------------------------------+------+---------------+
Table 1: Attested Objects
表1：アテステーションされたオブジェクト
It is important to recognize that PCR[0] is critical. The first measurement into PCR[0] is taken by the Root of Trust for Measurement, which is code that, by definition, cannot be verified by measurement. This measurement establishes the chain of trust for all subsequent measurements. If the PCR[0] measurement cannot be trusted, the validity of the entire chain is called into question.
PCR [0]が重要であることを認識することが重要です。PCR [0]への最初の測定は、測定のための信頼の基点によって取得されます。これは、定義上、測定では検証できないコードです。この測定により、その後のすべての測定の信頼の連鎖が確立されます。PCR [0]測定値を信頼できない場合、チェーン全体の有効性が疑問視されます。
Distinctions between PCR[0], PCR[2], PCR[4], and PCR[8] are summarized below:
PCR [0]、PCR [2]、PCR [4]、およびPCR [8]の区別を以下にまとめます。
PCR[0]
PCR [0]
typically represents a consistent view of rarely changed boot components of the host platform, which allows Attestation policies to be defined using the less changeable components of the transitive trust chain. This PCR typically provides a consistent view of the platform regardless of user-selected options.
通常、ホストプラットフォームのめったに変更されないブートコンポーネントの一貫したビューを表し、これにより推移的な信頼チェーンの変更が少ないコンポーネントを使用してアテステーションポリシーを定義できます。このPCRは通常、ユーザーが選択したオプションに関係なく、プラットフォームの一貫したビューを提供します。
PCR[2]
PCR [2]
is intended to represent a "user-configurable" environment where the user has the ability to alter the components that are measured into PCR[2]. This is typically done by adding adapter cards, etc., into user-accessible Peripheral Component Interconnect (PCI) or other slots. In UEFI systems, these devices may be configured by Option ROMs measured into PCR[2] and executed by the UEFI BIOS.
は、ユーザーがPCR[2]に測定されるコンポーネントを変更する能力を持つ「ユーザー設定可能」な環境を表すことを意図しています。これは通常、ユーザーアクセス可能なPeripheral Component Interconnect (PCI)またはその他のスロットにアダプターカードなどを追加することによって行われます。UEFIシステムでは、これらのデバイスは、PCR[2]に測定されUEFI BIOSによって実行されるOption ROMによって構成される場合があります。
PCR[4]
PCR [4]
is intended to represent the software that manages the transition between the platform's pre-OS start and the state of a system with the OS present. This PCR, along with PCR[5], identifies the initial OS loader (e.g., GRUB for Linux).
は、プラットフォームのPre-OS起動とOSが存在するシステムの状態との間の移行を管理するソフトウェアを表すことを意図しています。このPCRは、PCR[5]とともに、初期OSローダー（例：LinuxのGRUB）を識別します。
PCR[8]
PCR [8]
is used by the OS loader (e.g., GRUB) to record measurements of the various components of the operating system.
OSローダー（GRUBなど）で使用され、オペレーティングシステムのさまざまなコンポーネントの測定値を記録します。
Although [PC-CLIENT-BIOS-TPM-2.0] specifies the use of the first eight PCRs very carefully to ensure interoperability among multiple UEFI BIOS vendors, it should be noted that embedded software vendors may have considerably more flexibility. Verifiers typically need to know which log entries are consequential and which are not (possibly controlled by local policies), but the Verifier may not need to know what each log entry means or why it was assigned to a particular PCR. Designers must recognize that some PCRs may cover log entries that a particular Verifier considers critical and other log entries that are not considered important, so differing PCR values may not on their own constitute a check for authenticity. For example, in a UEFI system, some administrators may consider booting an image from a removable drive, something recorded in a PCR, to be a security violation, while others might consider that operation to be an authorized recovery procedure.
[PC-CLIENT-BIOS-TPM-2.0]は、複数のUEFI BIOSベンダー間の相互運用性を確保するために最初の8つのPCRの使用を非常に慎重に指定していますが、組み込みソフトウェアベンダーははるかに柔軟性がある可能性があることに注意してください。検証者は通常、どのログエントリが結果に影響を与えるもので、どれがそうでないか（おそらくローカルポリシーによって制御される）を知る必要がありますが、各ログエントリが何を意味するのか、なぜ特定のPCRに割り当てられたのかを知る必要はないかもしれません。設計者は、一部のPCRが特定の検証者が重要とみなすログエントリと、重要とみなさないログエントリの両方を含む場合があることを認識する必要があります。したがって、PCR値が異なること自体が真正性のチェックにはならない場合があります。例えば、UEFIシステムでは、一部の管理者は、PCRに記録されたリムーバブルドライブからのイメージの起動をセキュリティ違反とみなすかもしれませんが、他の管理者はその操作を許可されたリカバリ手順とみなすかもしれません。
Designers may allocate particular events to specific PCRs in order to achieve a particular objective with local attestation (e.g., allowing a procedure to execute, or releasing a particular decryption key, only if a given PCR is in a given state). It may also be important to designers to consider whether streaming notification of PCR updates is required (see [RATS-NET-DEV-SUB]). Specific log entries can only be validated if the Verifier receives every log entry affecting the relevant PCR, so (for example) a designer might want to separate rare, high-value events, such as configuration changes, from high-volume, routine measurements such as IMA logs [IMA].
設計者は、ローカルアテステーションで特定の目的を達成するために（例：特定のPCRが特定の状態にある場合にのみ、手順の実行や特定の復号鍵のリリースを許可する）、特定のイベントを特定のPCRに割り当てることができます。また、設計者にとっては、PCR更新のストリーミング通知が必要かどうかを検討することも重要かもしれません（[RATS-NET-DEV-SUB]を参照）。特定のログエントリは、検証者が関連するPCRに影響を与えるすべてのログエントリを受信した場合にのみ検証できるため、（例えば）設計者は、構成変更のような稀で価値の高いイベントを、IMAログ[IMA]のような大量で日常的な測定値から分離したいと考えるかもしれません。
RIV attestation relies on two credentials:
RIVアテステーションは、2つの資格情報に依存しています。
* An identity key pair and matching certificate is required to certify the identity of the Attester itself. RIV specifies the use of an IEEE 802.1AR DevID [IEEE-802-1AR] that is signed by the device manufacturer and contains the device serial number. This requirement goes slightly beyond 802.1AR; see Section 2.4 for notes.
* Attester自体の身元を証明するには、ID鍵ペアと適合する証明書が必要です。RIVは、デバイス製造元によって署名され、デバイスのシリアル番号を含むIEEE 802.1AR DevID [IEEE-802-1AR]の使用を規定しています。この要件は802.1ARをわずかに超えています。注釈については、セクション2.4を参照してください。
* An Attestation key pair and matching certificate is required to sign the Quote generated by the TPM to report evidence of software configuration.
* TPMによって生成されたクォートに署名し、ソフトウェア構成の証拠を報告するには、アテステーション鍵ペアと適合する証明書が必要です。
In a TPM application, both the Attestation private key and the DevID private key MUST be protected by the TPM. Depending on other TPM configuration procedures, the two keys are likely to be different; some of the considerations are outlined in the "TPM 2.0 Keys for Device Identity and Attestation" document [PLATFORM-DEVID-TPM-2.0].
TPMアプリケーションでは、アテステーション秘密鍵とDevID秘密鍵の両方がTPMによって保護されなければなりません。他のTPM構成手順によっては、2つの鍵が異なる可能性があります。考慮事項の一部は、「TPM 2.0 Keys for Device Identity and Attestation」ドキュメント[PLATFORM-DEVID-TPM-2.0]で概説されています。
The "TPM 2.0 Keys for Device Identity and Attestation" document [PLATFORM-DEVID-TPM-2.0] specifies further conventions for these keys:
「TPM 2.0 Keys for Device Identity and Attestation」ドキュメント[PLATFORM-DEVID-TPM-2.0]は、これらの鍵に関するさらなる慣例を規定しています。
* When separate Identity and Attestation keys are used, the AK and its X.509 certificate should parallel the DevID, with the same unique device identification as the DevID certificate (that is, the same subject and subjectAltName (if present), even though the key pairs are different). By examining the corresponding AK certificate, the Verifier can directly link a device's quote, which was signed by an AK, to the device that provided it. If the subject in the AK certificate doesn't match the corresponding DevID certificate, or if they're signed by different authorities, the Verifier may signal the detection of an Asokan-style person-in-the-middle attack (see Section 5.2).
* 個別のID鍵とアテステーション鍵を使用する場合、AKとそのX.509証明書はDevIDと並行し、DevID証明書と同じ一意のデバイス識別（つまり、鍵ペアが異なっていても同じサブジェクトとsubjectAltName（存在する場合））を持つべきです。対応するAK証明書を調べることで、検証者はAKによって署名されたデバイスのクォートを、それを提供したデバイスに直接関連付けることができます。AK証明書のサブジェクトが対応するDevID証明書と一致しない場合、または異なる機関によって署名されている場合、検証者はAsokanスタイルの中間者攻撃の検出を通知する場合があります（セクション5.2を参照）。
* Network devices that are expected to use SZTP as specified in [RFC8572] MUST be shipped by the manufacturer with pre-provisioned keys (Initial DevID and Initial AK, called IDevID and IAK, respectively). IDevID and IAK certificates MUST both be signed by the Endorser (typically the device manufacturer). Inclusion of an IDevID and IAK by a vendor does not preclude a mechanism whereby an administrator can define LDevID and Local Attestation Keys (LAK) if desired.
* [RFC8572]で指定されているSZTPを使用すると予想されるネットワークデバイスは、製造元によって事前にプロビジョニングされた鍵（Initial DevIDおよびInitial AK、それぞれIDevIDおよびIAKと呼ばれる）とともに供給される必要があります。IDevIDおよびIAK証明書は両方ともエンダーサー（通常はデバイス製造元）によって署名されなければなりません。ベンダーによるIDevIDおよびIAKの組み込みは、管理者が希望に応じてLDevIDおよびローカルアテステーション鍵（LAK）を定義できるメカニズムを排除するものではありません。
RIV workflow for network equipment is organized around a simple use case where a network operator wishes to verify the integrity of software installed in specific, fielded devices. A normative taxonomy of terms is given in [RFC9334], but as a reminder, this use case implies several roles and objects:
ネットワーク機器のRIVワークフローは、ネットワークオペレーターが特定のフィールドデバイスにインストールされたソフトウェアの整合性を検証したいというシンプルなユースケースを中心に構成されています。用語の規範的な分類は[RFC9334]で提供されていますが、念のため、このユースケースはいくつかの役割とオブジェクトを意味します。
Attester:
アテスター：
The device that the network operator wants to examine.
ネットワークオペレーターが調べたいデバイス。
Verifier:
Verifier：
Which might be a Network Management Station and is somewhat separate from the Device that will retrieve the signed evidence and measurement logs, and analyze them to pass judgment on the security posture of the device.
これはネットワーク管理ステーションである可能性があり、署名された証拠と測定ログを取得し、それらを分析してデバイスのセキュリティポスチャに関する判断を下すデバイスとは多少分離されています。
Relying Party:
頼るパーティー：
Can act on Attestation Results. Interaction between the Relying Party and the Verifier is considered out of scope for RIV.
アテステーション結果に基づいて行動できます。依拠当事者と検証者間の相互作用はRIVの範囲外と見なされます。
Signed Reference Integrity Manifests (RIMs):
署名された参照整合性マニフェスト（RIMS）：
Contains Reference Values. RIMs can either be created by the device manufacturer and shipped along with the device as part of its software image, or alternatively, could be obtained several other ways (direct to the Verifier from the manufacturer, from a third party, from the owner's concept of a "known good system", etc.). Retrieving RIMs from the device itself allows attestation to be done in systems that may not have access to the public Internet, or by other devices that are not management stations per se (e.g., a peer device; see Section 3.1.3). If Reference Values are obtained from multiple sources, the Verifier may need to evaluate the relative level of trust to be placed in each source in case of a discrepancy.
参照値が含まれています。RIMは、デバイスメーカーによって作成され、ソフトウェアイメージの一部としてデバイスとともに出荷されるか、あるいは他のいくつかの方法（製造元から検証者へ直接、第三者から、所有者の「既知の良好なシステム」という概念からなど）で取得できます。デバイス自体からRIMを取得することで、パブリックインターネットにアクセスできないシステムや、管理ステーション自体ではない他のデバイス（例：ピアデバイス。セクション3.1.3を参照）でアテステーションを行うことができます。複数のソースから参照値が取得される場合、検証者は、不一致の場合に各ソースに置かれる信頼の相対的なレベルを評価する必要がある場合があります。
These components are illustrated in Figure 2.
これらのコンポーネントを図2に示します。
+----------------+ +-------------+ +---------+--------+
|Reference Value | | Attester | Step 1 | Verifier| |
|Provider | | (Device |<-------| (Network| Relying|
|(Device | | under |------->| Mgmt | Party |
|Manufacturer | | attestation)| Step 2 | Station)| |
|or other | | | | | |
|authority) | | | | | |
+----------------+ +-------------+ +---------+--------+
| /\
| Step 0 |
-----------------------------------------------
Figure 2: RIV Reference Configuration for Network Equipment
図2：ネットワーク機器のRIV参照構成
Step 0: The Reference Value Provider (the device manufacturer or other authority) makes one or more RIMs, which correspond to the software image expected to be found on the device and are signed by the Reference Value Provider, available to the Verifier. (See Section 3.1.3 for "in-band" and "out of band" ways to make this happen.)
ステップ0：参照値プロバイダー（デバイスメーカーまたはその他の機関）は、デバイス上で見つかることが予想されるソフトウェアイメージに対応し、参照値プロバイダーによって署名された1つ以上のRIMを検証者が利用できるようにします。（これを実現するための「インバンド」および「アウトオブバンド」の方法については、セクション3.1.3を参照してください。）
Step 1: On behalf of a Relying Party, the Verifier (Network Management Station) requests DevID, Measurement Values, and possibly RIMs from the Attester.
ステップ1：依拠当事者に代わって、検証者（ネットワーク管理ステーション）は、AttesterからDevID、測定値、および場合によってはRIMを要求します。
Step 2: The Attester responds to the request by providing a DevID, quotes (measured values that are signed by the Attester), and optionally RIMs.
ステップ2：Attesterは、DevID、クォート（Attesterによって署名された測定値）、およびオプションでRIMを提供することにより、要求に応答します。
The use of the following standards components allows for interoperability:
次の標準コンポーネントを使用すると、相互運用性が可能になります。
1. TPM keys MUST be configured according to [PLATFORM-DEVID-TPM-2.0] or [PLATFORM-ID-TPM-1.2].
1. TPM鍵は、[PLATFORM-DEVID-TPM-2.0]または[PLATFORM-ID-TPM-1.2]に従って構成する必要があります。
2. For devices using UEFI and Linux, measurements of firmware and bootable modules MUST be taken according to "TCG EFI Platform Specification" [PC-CLIENT-EFI-TPM-1.2] or "TCG PC Client Specific Platform Firmware Profile Specification" [PC-CLIENT-BIOS-TPM-2.0], and Linux IMA [IMA].
2. UEFIおよびLinuxを使用するデバイスの場合、ファームウェアおよび起動可能なモジュールの測定は、「TCG EFI Platform Specification」[PC-CLIENT-EFI-TPM-1.2]または「TCG PC Client Specific Platform Firmware Profile Specification」[PC-CLIENT-BIOS-TPM-2.0]、およびLinux IMA [IMA]に従って行う必要があります。
3. DevID MUST be managed as DevID certificates as specified in IEEE Std 802.1AR [IEEE-802-1AR], with keys protected by TPMs.
3. DevIDは、IEEE Std 802.1AR [IEEE-802-1AR]で指定されているDevID証明書として、TPMによって保護された鍵を使用して管理する必要があります。
4. Attestation logs from Linux-based systems MUST be formatted according to the "Canonical Event Log Format" [CEL]. UEFI-based systems MUST use the TCG UEFI BIOS event log [PC-CLIENT-EFI-TPM-1.2] for TPM 1.2 systems and the "TCG PC Client Specific Platform Firmware Profile" [PC-CLIENT-BIOS-TPM-2.0] for TPM 2.0 systems.
4. Linuxベースのシステムからのアテステーションログは、「Canonical Event Log Format」[CEL]に従ってフォーマットする必要があります。UEFIベースのシステムは、TPM 1.2システムにはTCG UEFI BIOSイベントログ[PC-CLIENT-EFI-TPM-1.2]を、TPM 2.0システムには「TCG PC Client Specific Platform Firmware Profile」[PC-CLIENT-BIOS-TPM-2.0]を使用する必要があります。
5. Quotes MUST be retrieved from the TPM according to the TCG Trusted Attestation Protocol Information Model (TAP IM) [TAP] and the Challenge-Response-based Remote Attestation (CHARRA) YANG model [RFC9684]. While the TAP IM gives a protocol-independent description of the data elements involved, it's important to note that quotes from the TPM are signed inside the TPM and MUST be retrieved in a way that does not invalidate the signature, to preserve the trust model. The CHARRA YANG model [RFC9684] is used for this purpose. (See Section 5, Security Considerations).
5. クォートは、TCG Trusted Attestation Protocol Information Model (TAP IM) [TAP]およびチャレンジ応答ベースのリモートアテステーション (CHARRA) YANGモデル [RFC9684]に従ってTPMから取得する必要があります。TAP IMは関連するデータ要素のプロトコルに依存しない記述を提供しますが、TPMからのクォートはTPM内部で署名されており、信頼モデルを維持するために署名を無効にしない方法で取得する必要があることに注意することが重要です。この目的には、CHARRA YANGモデル[RFC9684]が使用されます。（セクション5、セキュリティに関する考慮事項を参照）。
6. Reference Values MUST be encoded as defined in the TCG RIM document [RIM], typically using Software Identification (SWID) tags [SWID] [NIST-IR-8060] or Concise SWID (CoSWID) tags [RFC9393].
6. 参照値は、TCG RIMドキュメント[RIM]で定義されているようにエンコードする必要があります。通常、ソフトウェア識別（SWID）タグ[SWID] [NIST-IR-8060]または簡潔なSWID（COSWID）タグ[RFC9393]を使用する必要があります。
This document makes the following simplifying assumptions to reduce complexity:
このドキュメントでは、複雑さを軽減するために次の単純化のための仮定を設けています。
* The product to be attested MUST be shipped by the equipment vendor with both a DevID as specified by IEEE Std 802.1AR and an IAK, with certificates in place. The IAK certificate must contain the same identity information as the DevID (specifically, the same subject and subjectAltName (if used), signed by the manufacturer). The IAK is a type of key that can be used to sign a TPM Quote, but not other objects (i.e., it's marked as a TCG "Restricted" key; this convention is described in "TPM 2.0 Keys for Device Identity and Attestation" [PLATFORM-DEVID-TPM-2.0]). For network equipment, which is generally not privacy sensitive, shipping a device with both an IDevID and an IAK already provisioned substantially simplifies initial startup.
* アテステーションされる製品は、IEEE Std 802.1ARで指定されているDevIDおよびIAKの両方を、証明書を配置した状態で機器ベンダーから出荷される必要があります。IAK証明書には、DevIDと同じID情報（具体的には、製造元によって署名された同じサブジェクトとsubjectAltName（使用されている場合））が含まれている必要があります。IAKは、TPMクォートに署名するために使用できる鍵の一種ですが、他のオブジェクトには使用できません（つまり、TCGの「制限付き」鍵としてマークされています。この慣例は「TPM 2.0 Keys for Device Identity and Attestation」[PLATFORM-DEVID-TPM-2.0]で記述されています）。一般的にプライバシーに敏感ではないネットワーク機器の場合、IDevIDとIAKの両方がすでにプロビジョニングされたデバイスを出荷することで、初期起動が大幅に簡素化されます。
* IEEE Std 802.1AR does not require a product serial number as part of the subject, but RIV-compliant devices MUST include their serial numbers in the DevID/IAK certificates to simplify tracking logistics for network equipment users. All other optional 802.1AR fields remain optional in RIV.
* IEEE Std 802.1ARは、サブジェクトの一部として製品のシリアル番号を要求しませんが、RIV準拠デバイスは、ネットワーク機器ユーザーの追跡管理を簡素化するために、DevID/IAK証明書にシリアル番号を含める必要があります。その他のすべてのオプションの802.1ARフィールドは、RIVではオプションのままです。
It should be noted that the use of X.509 certificate fields as specified by IEEE Std 802.1AR is not identical to that described in [RFC9525] for representation of application service identity.
IEEE STD 802.1ARで指定されているX.509証明書フィールドの使用は、アプリケーションサービスIDを表現するために[RFC9525]で説明されているものと同一ではないことに注意してください。
* The product MUST be equipped with an RTM, a Root of Trust for Storage, and a Root of Trust for Reporting (as defined in [SP800-155]), which together are capable of conforming to the TCG TAP IM [TAP].
* 製品には、RTM、ストレージの信頼の基点、およびレポートのための信頼の基点（[SP800-155]で定義されている）が装備されている必要があり、これらは合わせてTCG TAP IM [TAP]に準拠できるものでなければなりません。
* The authorized software supplier MUST make available Reference Values in the form of signed SWID or CoSWID tags.
* 承認されたソフトウェアサプライヤーは、署名されたSWIDまたはCoSWIDタグの形式で参照値を提供する必要があります。
[RFC9684] focuses on collecting and transmitting evidence in the form of PCR measurements and attestation logs. But the critical part of the process is enabling the Verifier to decide whether the measurements are "the right ones" or not.
[RFC9684]は、PCR測定とアテステーションログの形で証拠を収集および送信することに焦点を当てています。しかし、プロセスの重要な部分は、検証者が測定値が「正しいもの」であるかどうかを決定できるようにすることです。
While it must be up to network administrators to decide what they want on their networks, the software supplier should supply the Reference Values, in signed RIMs, that may be used by a Verifier to determine if evidence shows known good, known bad, or unknown software configurations.
ネットワーク上で何を望むかを決定するのはネットワーク管理者の責任ですが、ソフトウェアサプライヤーは、証拠が既知の良好な、既知の不正な、または未知のソフトウェア構成を示しているかどうかを検証者が判断するために使用される、署名されたRIMで参照値を提供する必要があります。
In general, there are two kinds of reference measurements:
一般的に、参照測定には2種類あります。
1. Measurements of early system startup (e.g., BIOS, boot loader, OS kernel) are essentially single threaded and executed exactly once, in a known sequence, before any results can be reported. In this case, while the method for computing the hash and extending relevant PCRs may be complicated, the net result is that the software (more likely, firmware) vendor will have one known good PCR value that "should" be present in the relevant PCRs after the box has booted. In this case, the signed reference measurement could simply list the expected hashes for the given version. However, a RIM that contains the intermediate hashes can be useful in debugging cases where the expected final hash is not the one reported.
1. 初期システム起動（例：BIOS、ブートローダー、OSカーネル）の測定は、本質的にシングルスレッドであり、結果が報告される前に既知のシーケンスで正確に1回実行されます。この場合、ハッシュの計算と関連PCRの拡張方法は複雑である可能性がありますが、最終的な結果として、ソフトウェア（より可能性が高いのはファームウェア）ベンダーは、起動後に該当するPCRに「存在すべき」既知の良好なPCR値を持つことになります。この場合、署名された参照測定は、特定のバージョンに期待されるハッシュを単純にリストすることができます。ただし、中間ハッシュを含むRIMは、期待される最終ハッシュが報告されない場合のデバッグに役立ちます。
2. Measurements taken later in operation of the system, once an OS has started (for example, Linux IMA [IMA]), may be more complex, with unpredictable "final" PCR values. In this case, the Verifier must have enough information to reconstruct the expected PCR values from logs and signed reference measurements from a trusted authority.
2. OSが起動した後（例えばLinux IMA [IMA]）のシステム動作で取得される測定は、予測不可能な「最終」PCR値を持つため、より複雑になる可能性があります。この場合、検証者は、ログと信頼できる当局からの署名された参照測定値から予想されるPCR値を再構築するために十分な情報を持っている必要があります。
In both cases, the expected values can be expressed as signed SWID or CoSWID tags, but the SWID structure in the second case is somewhat more complex, as reconstruction of the extended hash in a PCR may involve thousands of files and other objects.
どちらの場合も、予想される値は署名されたSWIDまたはCoSWIDタグとして表現できますが、PCRでの拡張ハッシュの再構築が数千のファイルやその他のオブジェクトが関与する可能性があるため、2番目のケースのSWID構造はやや複雑です。
TCG has published an information model defining elements of RIMs under the title "TCG Reference Integrity Manifest (RIM) Information Model" [RIM]. This information model outlines how SWID tags should be structured to allow attestation, and it defines "bundles" of SWID tags that may be needed to describe a complete software release. The RIM contains metadata relating to the software release it belongs to, plus hashes for each individual file or other object that could be attested.
TCGは、「TCG Reference Integrity Manifest (RIM) Information Model」[RIM]というタイトルでRIMの要素を定義する情報モデルを公開しています。この情報モデルは、アテステーションを可能にするSWIDタグの構造を概説し、完全なソフトウェアリリースを記述するために必要となるSWIDタグの「バンドル」を定義しています。RIMには、それが属するソフトウェアリリースに関連するメタデータと、アテステーション可能な各個別ファイルまたはその他のオブジェクトのハッシュが含まれています。
Many network equipment vendors use a UEFI BIOS to launch their network operating system. These vendors may want to also use the "TCG PC Client Reference Integrity Manifest Specification" [PC-CLIENT-RIM], which focuses specifically on a SWID-compatible format suitable for expressing measurement values expected from a UEFI BIOS.
多くのネットワーク機器ベンダーは、UEFI BIOSを使用してネットワークオペレーティングシステムを起動しています。これらのベンダーは、UEFI BIOSから予想される測定値を表現するのに適したSWID互換形式に特に焦点を当てた「TCG PCクライアントリファレンスインテグリティマニフェスト仕様」[PC-Client-RIM]を使用することもできます。
Quotes from a TPM can provide evidence of the state of a device up to the time the evidence was recorded. However, to make sense of the quote in cases where several events are extended into one PCR, an event log that identifies which software modules contributed which values to the quote during startup must also be provided. When required, the log MUST contain enough information to demonstrate its integrity by allowing exact reconstruction of the digest conveyed in the signed quote (that is, calculating the hash of all the hashes in the log should produce the same values as contained in the PCRs; if they don't match, the log may have been tampered with. See Appendix A.1).
TPMからのクォートは、証拠が記録された時点までのデバイスの状態の証拠を提供できます。ただし、いくつかのイベントが1つのPCRに拡張される場合にクォートを理解するためには、起動中にどのソフトウェアモジュールがクォートにどの値を提供したかを特定するイベントログも提供する必要があります。必要に応じて、ログには、署名されたクォートで伝達されたダイジェストの正確な再構築を可能にすることで、その完全性を示すのに十分な情報が含まれている必要があります（つまり、ログ内のすべてのハッシュのハッシュを計算すると、PCRに含まれる値と同じ値が生成されるはずです。一致しない場合、ログは改ざんされている可能性があります。付録A.1を参照）。
There are multiple event log formats that may be supported as viable formats of Evidence between the Attester and Verifier; however, to simplify interoperability, RIV focuses on just three:
AttesterとVerifierの間で証拠の実行可能な形式としてサポートされる可能性のある複数のイベントログ形式がありますが、相互運用性を簡素化するために、RIVは3つに焦点を当てています。
1. TCG UEFI BIOS event log for TPM 2.0 ("TCG PC Client Specific Platform Firmware Profile Specification") [PC-CLIENT-BIOS-TPM-2.0]
1. TPM 2.0のTCG UEFI BIOSイベントログ（ "TCG PCクライアント固有のプラットフォームファームウェアプロファイル仕様"）[PC-Client-BIOS-TPM-2.0]
2. TCG UEFI BIOS event log for TPM 1.2 ("TCG EFI Platform Specification" for TPM Family 1.1 or 1.2, Section 7) [PC-CLIENT-EFI-TPM-1.2]
2. TPM 1.2のTCG UEFI BIOSイベントログ（TPMファミリー1.1または1.2、セクション7の「TCG EFIプラットフォーム仕様」）[PC-Client-EFI-TPM-1.2]
3. TCG "Canonical Event Log Format" [CEL]
3. TCG "Canonical Event Log Format" [CEL]
The Reference Interaction Model for Challenge-Response-based Remote Attestation ([RATS-INTERACTION-MODELS]) is based on the standard roles defined in [RFC9334]. However, additional prerequisites have been established to allow for interoperable implementations of RIV use cases. These prerequisites are intended to provide sufficient context information so that the Verifier can acquire and evaluate measurements collected by the Attester.
チャレンジ応答ベースのリモートアテステーションの参照相互作用モデル（[RATS-INTERACTION-MODELS]）は、[RFC9334]で定義されている標準的な役割に基づいています。ただし、RIVユースケースの相互運用可能な実装を可能にするために、追加の前提条件が確立されています。これらの前提条件は、検証者がAttesterによって収集された測定値を取得および評価できるように、十分なコンテキスト情報を提供することを目的としています。
A DevID in the form of a DevID certificate as specified by IEEE Std 802.1AR [IEEE-802-1AR] must be provisioned in the Attester's TPMs.
IEEE Std 802.1AR [IEEE-802-1AR]で指定されているDevID証明書の形式のDevIDは、AttesterのTPMにプロビジョニングする必要があります。
The AK and certificate must also be provisioned on the Attester according to [PLATFORM-DEVID-TPM-2.0] or [PLATFORM-ID-TPM-1.2].
AKと証明書は、[PLATFORM-DEVID-TPM-2.0]または[PLATFORM-ID-TPM-1.2]に従って、Attesterにもプロビジョニングする必要があります。
It MUST be possible for the Verifier to determine that the Attester's AKs are resident in the same TPM as its DevID keys (see Section 2.2 and Section 5, Security Considerations).
Verifierは、AttesterのAKがそのDevID鍵と同じTPMに存在することを判断できる必要があります（セクション2.2およびセクション5、セキュリティに関する考慮事項を参照）。
As noted in Section 2.3, the Verifier may obtain Reference Values from several sources. In addition, administrators may make authorized, site-specific changes (e.g., keys in key databases) that could impact attestation results. As such, there could be conflicts, omissions, or ambiguities between some Reference Values and collected Evidence.
セクション2.3で述べたように、検証者はいくつかのソースから参照値を取得する場合があります。さらに、管理者は、アテステーション結果に影響を与える可能性のある、許可されたサイト固有の変更（例：鍵データベース内の鍵）を行う場合があります。そのため、いくつかの参照値と収集された証拠の間には、対立、省略、または曖昧さがある可能性があります。
The Verifier MUST have an Appraisal Policy for Evidence to evaluate the significance of any discrepancies between different reference sources, or between Reference Values and evidence from logs and quotes. While there must be an Appraisal Policy, this document does not specify the format or mechanism to convey the intended policy, nor does RIV specify mechanisms by which the results of applying the policy are communicated to the Relying Party.
検証者は、異なる参照ソース間、または参照値とログおよびクォートからの証拠との間の不一致の重要性を評価するために、証拠の評価ポリシーを持っている必要があります。評価ポリシーは必須ですが、このドキュメントは、意図されたポリシーを伝達するための形式やメカニズムを規定しておらず、RIVは、ポリシー適用結果が依拠当事者に伝達されるメカニズムも規定していません。
Once the prerequisites for RIV are met, a Verifier is able to acquire Evidence from an Attester. Figure 3 illustrates a RIV information flow between a Verifier and an Attester, derived from Section 7.1 of [RATS-INTERACTION-MODELS]. In this diagram, each event with its input and output parameters is shown as "Event(input-params)=>(outputs)". The event times shown correspond to the time types described within Appendix A of [RFC9334]:
RIVの前提条件が満たされると、検証者はAttesterから証拠を取得できます。図3は、[RATS-INTERACTION-MODELS]のセクション7.1から派生した、VerifierとAttester間のRIV情報フローを示しています。この図では、入力パラメーターと出力パラメーターを持つ各イベントは、「Event(input-params)=>(outputs)」として表示されます。示されているイベント時間は、[RFC9334]の付録Aに記載されている時間タイプに対応しています。
.----------. .-----------------------.
| Attester | | Relying Party/Verifier |
'----------' '------------------------'
time(VG) |
generateClaims(attestingEnvironment) |
| => claims, eventLogs |
| |
| time(NS)
| <-- requestAttestation(handle, authSecIDs, claimSelection) |
| |
time(EG) |
collectClaims(claims, claimSelection) |
| => collectedClaims |
| |
generateEvidence(handle, authSecIDs, collectedClaims) |
| => evidence |
| time(RG,RA)
| evidence, eventLogs -------------------------------------> |
| |
| appraiseEvidence(evidence, eventLogs, refValues)
| attestationResult <= |
| |
~ ~
| time(RX)
Figure 3: IETF Attestation Information Flow
図3：IETF証明情報フロー
Step 1 (time(VG)):
ステップ1（時間（VG））：
One or more attesting network device PCRs are extended with measurements. RIV provides no direct link between the time at which the event takes place and the time that it's attested, although streaming attestation as described in [RATS-NET-DEV-SUB] could.
1つ以上のアテステーションネットワークデバイスのPCRが測定値で拡張されます。RIVは、イベント発生時刻とアテステーション時刻の間に直接的なリンクを提供しませんが、[RATS-NET-DEV-SUB]で説明されているストリーミングアテステーションであれば可能です。
Step 2 (time(NS)):
ステップ2（時間（ns））：
The Verifier generates a unique random nonce ("number used once") and makes a request for one or more PCRs from an Attester. For interoperability, this must be accomplished as specified in "A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs)" [RFC9684]. Both TPM 1.2 and TPM 2.0 allow nonces as large as the operative digest size (i.e., 20 or 32 bytes; see [TPM-1.2] Part 2, Section 5.5, and [TPM-2.0] Part 2, Section 10.4.4).
検証者は、一意のランダムなnonce（「一度だけ使用される数値」）を生成し、Attesterから1つ以上のPCRを要求します。相互運用性のために、これは「A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs)」[RFC9684]で指定されているとおりに達成されなければなりません。TPM 1.2とTPM 2.0の両方で、実効ダイジェストサイズ（すなわち、20または32バイト。 [TPM-1.2]パート2、セクション5.5、および[TPM-2.0]パート2、セクション10.4.4を参照）と同じ大きさのnonceを許可しています。
Step 3 (time(EG)):
ステップ3（時間（例））：
On the Attester, measured values are retrieved from the Attester's TPM. This requested PCR evidence along with the Verifier's nonce is called a Quote and is signed by the AK associated with the DevID. Quotes are retrieved according to the CHARRA YANG model [RFC9684]. At the same time, the Attester collects log evidence showing the values have been extended into that PCR. Appendix A.1 gives more detail on how this works and includes references to the structure and contents of quotes in TPM documents.
Attesterでは、測定値がAttesterのTPMから取得されます。この要求されたPCR証拠とVerifierのnonceはクォートと呼ばれ、DevIDに関連付けられたAKによって署名されます。クォートはCHARRA YANGモデル[RFC9684]に従って取得されます。同時に、Attesterは、値がそのPCRに拡張されたことを示すログ証拠を収集します。付録A.1では、これがどのように機能するかについてさらに詳しく説明し、TPMドキュメントにおけるクォートの構造と内容への参照を含んでいます。
Step 4:
ステップ4：
The collected Evidence is passed from the Attester to the Verifier.
収集された証拠は、AttesterからVerifierに渡されます。
Step 5 (time(RG,RA)):
ステップ5（時間（RG、RA））：
The Verifier reviews the Evidence and takes action as needed. As the interaction between Relying Party and Verifier is out of scope for RIV, this can be described as one step.
Verifierは証拠を確認し、必要に応じて行動を起こします。依拠当事者とVerifier間の相互作用はRIVの範囲外であるため、これは1つのステップとして説明できます。
* If the signature covering TPM Evidence is not correct, the device SHOULD NOT be trusted.
* TPMの証拠をカバーする署名が正しくない場合、デバイスを信頼してはなりません。
* If the nonce in the response doesn't match the Verifier's nonce, the response may be a replay, and the device SHOULD NOT be trusted.
* 応答のnonceがVerifierのnonceと一致しない場合、応答はリプレイである可能性があり、デバイスを信頼すべきではありません。
* If the signed PCR values do not match the set of log entries that have extended a particular PCR, the device SHOULD NOT be trusted.
* 署名されたPCR値が特定のPCRを拡張したログエントリのセットと一致しない場合、デバイスは信頼してはなりません。
* If the log entries that the Verifier considers important do not match known good values, the device SHOULD NOT be trusted. We note that the process of collecting and analyzing the log can be omitted if the value in the relevant PCR is already a known-good value.
* Verifierが重要と見なすログエントリが既知の良好な値と一致しない場合、デバイスは信頼すべきではありません。関連するPCRの値がすでに既知の良好な値である場合、ログを収集および分析するプロセスは省略できることに注意してください。
* If the set of log entries are not seen as acceptable by the Appraisal Policy for Evidence, the device SHOULD NOT be trusted.
* ログエントリのセットが証拠のための評価ポリシーで受け入れられると見なされない場合、デバイスを信頼してはなりません。
* If time(RG)-time(NS) is greater than the Appraisal Policy for Evidence's threshold for assessing freshness, the Evidence is considered stale and SHOULD NOT be trusted.
* time(RG)-time(NS)が、新鮮さを評価するための証拠の評価ポリシーの閾値よりも大きい場合、その証拠は古くなっていると見なされ、信頼すべきではありません。
Network Management systems may retrieve signed PCR-based Evidence using NETCONF or RESTCONF with [RFC9684]. In either case, implementations must do so using a secure tunnel.
ネットワーク管理システムは、[RFC9684]を使用してNETCONFまたはRESTCONFを使用して、署名されたPCRベースの証拠を取得する場合があります。どちらの場合でも、実装はセキュアなトンネルを使用してこれを行う必要があります。
Log Evidence MUST be retrieved via log interfaces specified in [RFC9684].
[RFC9684]で指定されたログインターフェイスを介して、ログ証拠を取得する必要があります。
Figure 3 assumes that the Verifier is trusted, while the Attester is not. In a peer-to-peer application such as two routers negotiating a trust relationship, the two peers can each ask the other to prove software integrity. In this application, the information flow is the same, but each side plays a role both as an Attester and a Verifier. Each device issues a challenge, and each device responds to the other's challenge, as shown in Figure 4. Peer-to-peer challenges, particularly if used to establish a trust relationship between routers, require devices to carry their own signed reference measurements (RIMs). Devices may also have to carry an appraisal policy for evidence for each possible peer device so that each device has everything needed for remote attestation, without having to resort to a central authority.
図3は、検証者は信頼されているが、Attesterは信頼されていないと仮定しています。信頼関係を交渉する2つのルーターなどのピアツーピアアプリケーションでは、両方のピアが互いにソフトウェアの整合性を証明するよう要求できます。このアプリケーションでは、情報フローは同じですが、各サイドはAttesterとVerifierの両方の役割を果たします。図4に示すように、各デバイスはチャレンジを発行し、各デバイスは相手のチャレンジに応答します。ピアツーピアチャレンジは、特にルーター間の信頼関係を確立するために使用される場合、デバイスが独自の署名された参照測定値（RIM）を保持する必要があります。また、各デバイスは、中央機関に頼ることなくリモートアテステーションに必要なすべてを持つように、各可能なピアデバイスの証拠に対する評価ポリシーを保持する必要がある場合があります。
+---------------+ +---------------+
| RefVal | | RefVal |
| Provider A | | Provider B |
| Firmware | | Firmware |
| Configuration | | Configuration |
| Authority | | Authority |
| | | |
+---------------+ +---------------+
| |
| |Step 0B
| +------------+ +------------+ |
| | | Step 1 | | | \
| | Attester |<------>| Verifier | | |
| | |<------>| | | | Router B
+------>| | Step 2 | | | |- Challenges
Step 0A| | | | | | Router A
| |------->| | | |
|- Router A -| Step 3 |- Router B -| | /
| | | | |
| | | | |
| | Step 1 | | | \
| Verifier |<------>| Attester |<-+ | Router A
| |<------>| | |- Challenges
| | Step 2 | | | Router B
| | | | |
| |<-------| | |
+------------+ Step 3 +------------+ /
Figure 4: Peer-to-Peer Attestation Information Flow
図4：ピアツーピアの証明情報フロー
In this application, each device may need to be equipped with signed RIMs to act as an Attester, and to allow each device to act as a Verifier, each may need to be equipped with an Appraisal Policy for Evidence and a selection of trusted X.509 root certificates also. An existing link layer protocol such as 802.1X [IEEE-802.1X] or 802.1AE [IEEE-802.1AE], with Evidence being enclosed over a variant of the Extensible Authentication Protocol (EAP) [RFC3748] or Link Layer Discovery Protocol (LLDP) [LLDP], are suitable methods for such an exchange. Details of peer-to-peer operation are out of scope for this document.
このアプリケーションでは、Attesterとして機能するために各デバイスに署名されたRIMが装備されている必要があり、各デバイスがVerifierとして機能できるように、それぞれに証拠の評価ポリシーと信頼できるX.509ルート証明書の選択肢も装備されている必要があるかもしれません。802.1X [IEEE-802.1X]や802.1AE [IEEE-802.1AE]などの既存のリンク層プロトコルで、拡張認証プロトコル（EAP）[RFC3748]またはリンク層ディスカバリープロトコル（LLDP）[LLDP]のバリアントを介して証拠が封入されるのは、そのような交換に適した方法です。ピアツーピア運用の詳細は、このドキュメントの範囲外です。
Network equipment, such as routers, switches, and firewalls, has a key role to play in guarding the privacy of individuals using the network. Network equipment generally adheres to several rules to protect privacy:
ルーター、スイッチ、ファイアウォールなどのネットワーク機器は、ネットワークを使用して個人のプライバシーを守る上で重要な役割を果たします。ネットワーク機器は一般に、プライバシーを保護するためにいくつかのルールを順守します。
* Packets passing through the device must not be sent to unauthorized destinations. For example:
* デバイスを通過するパケットを不正な宛先に送信しないでください。例えば：
- Routers often act as Policy Enforcement Points, where individual subscribers may be checked for authorization to access a network. Subscriber login information must not be released to unauthorized parties.
- 多くの場合、ルーターはポリシー強制ポイントとして機能し、個々の加入者がネットワークへのアクセス権限を確認されることがあります。加入者のログイン情報は、許可されていない当事者に公開されてはなりません。
- Network equipment is often called upon to block access to protected resources from unauthorized users.
- ネットワーク機器は、許可されていないユーザーから保護されたリソースへのアクセスをブロックするためにしばしば求められています。
* Routing information, such as the identity of a router's peers, must not be leaked to unauthorized neighbors.
* ルーターのピアのIDなどのルーティング情報は、許可されていないネイバーに漏洩してはなりません。
* If configured, encryption and decryption of traffic must be carried out reliably, while protecting keys and credentials.
* 設定されている場合、鍵とクレデンシャルを保護しながら、トラフィックの暗号化と復号化を確実に行う必要があります。
Functions that protect privacy are implemented as part of each layer of hardware and software that makes up the networking device. In light of these requirements for protecting the privacy of users of the network, the network equipment must identify itself, and its boot configuration and measured device state (for example, PCR values), to the equipment's administrator so there's no uncertainty about the device's function and configuration. Attestation is a component that allows the administrator to ensure that the network provides individual and peer privacy guarantees, even though the device itself may not have a right to keep its identity secret.
プライバシーを保護する機能は、ネットワークデバイスを構成するハードウェアおよびソフトウェアの各層の一部として実装されます。ネットワークユーザーのプライバシーを保護するためのこれらの要件に鑑み、ネットワーク機器は、その機能と構成に関する不確実性がないように、自身のブート構成と測定されたデバイス状態（例えばPCR値）を機器の管理者に識別する必要があります。アテステーションは、デバイス自体がそのIDを秘密にする権利を持たない場合でも、管理者がネットワークが個人およびピアプライバシーの保証を提供することを確実にするためのコンポーネントです。
See [NET-EQ] for more context on privacy in networking devices.
ネットワークデバイスにおけるプライバシーの詳細なコンテキストについては、[NET-EQ]を参照してください。
While attestation information from network devices is not likely to contain privacy-sensitive content regarding network users, administrators may want to keep attestation records confidential to avoid disclosing versions of software loaded on the device, which is information that could facilitate attacks against known vulnerabilities.
ネットワークデバイスからのアテステーション情報には、ネットワークユーザーに関するプライバシーに敏感な内容が含まれている可能性は低いですが、管理者は、既知の脆弱性に対する攻撃を容易にする可能性がある情報であるデバイスにロードされたソフトウェアのバージョンを開示することを避けるため、アテステーション記録を機密として保持したいと考えるかもしれません。
Specifications such as TLS [RFC8446] and YANG [RFC7950] contain considerable advice on keeping network-connected systems secure. This section outlines specific risks and mitigations related to attestation.
TLS [RFC8446]やYANG [RFC7950]などの仕様には、ネットワーク接続システムを安全に保つためのかなりのアドバイスが含まれています。このセクションでは、アテステーションに関連する特定のリスクと緩和策の概要を説明します。
Attestation Evidence obtained by the RIV procedure is subject to a number of attacks:
RIV手順によって得られたアテステーション証拠は、いくつかの攻撃の対象となります。
* Keys may be compromised.
* 鍵が侵害される可能性があります。
* A counterfeit device may attempt to impersonate (spoof) a known authentic device.
* 偽造デバイスは、既知の本物のデバイスになりすます（スプーフィング）を試みる場合があります。
* Person-in-the-middle attacks may be used by a compromised device to attempt to deliver responses that originate in an authentic device.
* 中間者攻撃は、侵害されたデバイスによって、真正なデバイスから発信された応答を配信しようとするために使用される可能性があります。
* Replay attacks may be attempted by a compromised device.
* リプレイ攻撃は、侵害されたデバイスによって試行される場合があります。
Trustworthiness of RIV attestation depends strongly on the validity of keys used for identity and attestation reports. RIV takes full advantage of TPM capabilities to ensure that evidence can be trusted.
RIVアテステーションの信頼性は、アイデンティティおよびアテステーションレポートに使用される鍵の有効性に強く依存します。RIVは、証拠が信頼できることを保証するためにTPMの機能を最大限に活用します。
Two sets of key pairs are relevant to RIV attestation:
RIVアテステーションに関連する鍵ペアは2セットあります。
* A DevID key pair is used to certify the identity of the device in which the TPM is installed.
* DevID鍵ペアは、TPMがインストールされているデバイスのIDを証明するために使用されます。
* An AK key pair is used to certify attestation Evidence (i.e., quotes) and to provide evidence for integrity of the device software.
* AKキーペアは、証明の証拠（すなわち、引用）を証明し、デバイスソフトウェアの整合性の証拠を提供するために使用されます。
TPM practices usually require that these keys be different to ensure that a general-purpose signing key cannot be used to spoof an attestation quote.
TPMプラクティスでは、通常、これらのキーが異なることを要求して、一般的な署名キーを使用して証明の見積もりをスプーフィングできないことを確認します。
In each case, the private half of the key is known only to the TPM and cannot be retrieved externally, even by a trusted party. To ensure that's the case, specification-compliant private/public key pairs are generated inside the TPM, where they are never exposed and cannot be extracted (see [PLATFORM-DEVID-TPM-2.0]).
いずれの場合も、キーのプライベートハーフはTPMにのみ知られており、信頼できる当事者であっても外部から取得することはできません。それを確実にするために、仕様に準拠したプライベート/公開キーのペアがTPM内で生成され、そこで露出せず、抽出できません（[プラットフォーム-Devid-TPM-2.0を参照]）。
Keeping keys safe is a critical enabler of trustworthiness, but it's just part of attestation security; knowing which keys are bound to the device in question is just as important in an environment where private keys are never exposed.
キーを安全に保つことは、信頼性の重要なイネーブラーですが、それは証明のセキュリティの一部にすぎません。どのキーが問題のデバイスにバインドされているかを知ることは、プライベートキーが決して露出しない環境でも同様に重要です。
While there are many ways to manage keys in a TPM (see [PLATFORM-DEVID-TPM-2.0]), RIV includes support for "zero touch" provisioning (also known as zero touch onboarding) of fielded devices (e.g., SZTP [RFC8572]), where keys that have predictable trust properties are provisioned by the device vendor.
TPMでキーを管理する方法はたくさんありますが（[プラットフォーム-Devid-TPM-2.0]を参照）、RIVにはフィールドデバイスの「ゼロタッチ」プロビジョニング（ゼロタッチオンボーディングとも呼ばれます）のサポートが含まれています（例えば、SZTP [RFC85722]）、予測可能な信頼プロパティを持つキーがデバイスベンダーによってプロビジョニングされます。
Device identity in RIV is based on DevID defined by IEEE Std 802.1AR. This specification provides several elements:
RIVのデバイスアイデンティティは、IEEE STD 802.1ARによって定義されたDevidに基づいています。この仕様はいくつかの要素を提供します。
* A DevID requires a unique key pair for each device, accompanied by an X.509 certificate.
* devidには、x.509証明書を添付するデバイスごとに一意のキーペアが必要です。
* The private portion of the DevID key is to be stored in the device, in a manner that provides confidentiality (Section 6.2.5 of [IEEE-802-1AR]).
* Devidキーの私的部分は、機密性を提供する方法でデバイスに保存されます（[IEEE-802-1AR]のセクション6.2.5）。
The X.509 certificate contains several components:
X.509証明書にはいくつかのコンポーネントが含まれています。
* The public part of the unique DevID key assigned to that device allows a challenge of identity.
* そのデバイスに割り当てられた一意のdevidキーの公開部分は、アイデンティティの課題を可能にします。
* An identifying string that's unique to the manufacturer of the device. This is normally the serial number of the unit, which might also be printed on a label on the device.
* デバイスのメーカーに固有の識別文字列。これは通常、ユニットのシリアル番号であり、デバイス上のラベルにも印刷される場合があります。
* The certificate must be signed by a key traceable to the manufacturer's root key.
* 証明書は、メーカーのルートキーに追跡可能なキーによって署名する必要があります。
With these elements, the device's manufacturer and serial number can be identified by analyzing the DevID certificate plus the chain of intermediate certificates leading back to the manufacturer's root certificate. As is conventional in TLS or SSH connections, a random nonce must be signed by the device in response to a challenge, proving possession of its DevID private key.
これらの要素を使用すると、デバイスのメーカーとシリアル番号は、DevID証明書に加えて、メーカーのルート証明書に戻る中間証明書のチェーンを分析することで識別できます。TLSまたはSSH接続では従来のように、課題に応じてデバイスによってランダムなノンセに署名する必要があり、DevID秘密キーの所有を証明する必要があります。
RIV uses the DevID to validate a TLS or SSH connection to the device as the attestation session begins. Security of this process derives from TLS or SSH security, with the DevID, which contains a device serial number, providing proof that the session terminates on the intended device. See [RFC8446] [RFC4253].
RIVは、Devidを使用して、証明セッションが開始されるときにTLSまたはSSH接続をデバイスに検証します。このプロセスのセキュリティは、デバイスのシリアル番号を含むDevidを使用して、TLSまたはSSHセキュリティから派生し、セッションが意図したデバイスで終了することを証明します。[RFC8446] [RFC4253]を参照してください。
Evidence of software integrity is delivered in the form of a quote that is signed by the TPM itself and accompanied by an IAK certificate containing the same identity information as the DevID. Because the contents of the quote are signed inside the TPM, any external modification (including reformatting to a different data format) after measurements have been taken will be detected as tampering. An unbroken chain of trust is essential for ensuring that blocks of code that are taking measurements have been verified before execution (see Figure 1).
ソフトウェアの整合性の証拠は、TPM自体によって署名され、DevIDと同じID情報を含むIAK証明書が添付されている引用の形で配信されます。見積もりの内容はTPM内で署名されているため、測定が行われた後、外部変更（異なるデータ形式への再フォーマットを含む）が改ざんされたものとして検出されます。壊れていない信頼の連鎖は、測定を行っているコードブロックが実行前に検証されていることを確認するために不可欠です（図1を参照）。
Requiring measurements of the operating software to be signed by a key known only to the TPM also removes the need to trust the device's operating software (beyond the first measurement in the RTM; see below). If malicious software makes any changes to a quote in the device itself, or in the path back to the Verifier, the signature on the quote will be invalidated.
TPMにのみ既知のキーによって署名されるようにオペレーティングソフトウェアの測定が必要になると、デバイスのオペレーティングソフトウェアを信頼する必要性も削除されます（RTMの最初の測定を超えて、以下を参照）。悪意のあるソフトウェアがデバイス自体の見積もり、または検証器に戻るパスに変更を加えた場合、引用符の署名は無効になります。
A critical feature of the YANG model described in [RFC9684] is the ability to carry TPM data structures in their TCG-defined format, without requiring any changes to the structures as they were signed and delivered by the TPM. While alternate methods of conveying TPM quotes could reduce redundant information, or add another layer of signing using external keys, the implementation MUST preserve the TPM signing so that tampering anywhere in the path between the TPM itself and the Verifier can be detected.
[RFC9684]で説明されているYangモデルの重要な特徴は、TPMが署名および配信された構造に変更を必要とせずに、TCG定義形式でTPMデータ構造を運ぶ機能です。TPMの引用符を伝える代替方法は、冗長な情報を減らすか、外部キーを使用して署名の別のレイヤーを追加する可能性がありますが、実装はTPM自体と検証者の間のパスのどこにでも改ざんするようにTPMの署名を保持する必要があります。
Prevention of spoofing attacks against attestation systems is also important. There are several cases to consider:
認証システムに対するスプーフィング攻撃の防止も重要です。考慮すべきいくつかのケースがあります：
* The entire device could be spoofed. If the Verifier goes to appraise a specific Attester, it might be redirected to a different Attester.
* デバイス全体をスプーフィングできます。検証者が特定の攻撃を評価する場合、別の攻撃にリダイレクトされる可能性があります。
* A compromised device could have a valid DevID, but substitute a quote from a known-good device instead of returning its own, as described in [RFC6813].
* 侵害されたデバイスには有効な開発がありますが、[RFC6813]に記載されているように、独自のものを返す代わりに、既知の優れたデバイスからの引用を代用します。
* A device with a compromised OS could return a fabricated quote providing spoofed attestation Evidence.
* OSが侵害されたデバイスは、スプーフィングされた証拠の証拠を提供する製造された引用を返す可能性があります。
Use of the 802.1AR DevID in the TPM provides protection against the case of a spoofed device by ensuring that the Verifier's TLS or SSH session is in fact terminating on the right device.
TPMで802.1AR Devidを使用すると、検証者のTLSまたはSSHセッションが実際に適切なデバイスで終了していることを確認することにより、スプーフィングされたデバイスの場合に対する保護を提供します。
Protection against spoofed quotes from a device with valid identity is a bit more complex. An identity key must be available to sign any kind of nonce or hash offered by the Verifier, and consequently, could be used to sign a fabricated quote. To block a spoofed Attestation Result, the quote generated inside the TPM must be signed by a key, known as an AK, that's different from the DevID.
有効なアイデンティティを持つデバイスからのスプーフィングされた引用に対する保護は、もう少し複雑です。Verifierが提供するあらゆる種類のNONCEまたはハッシュに署名するためにIDキーを使用できる必要があります。その結果、製造された見積に署名するために使用できます。スプーフィングされた証明の結果をブロックするには、TPM内で生成された引用は、Devidとは異なるAKとして知られるキーによって署名する必要があります。
Given separate Attestation and DevID keys, the binding between the AK and the same device must also be proven to prevent a person-in-the-middle attack (e.g., the "Asokan Attack" [RFC6813]).
個別の証明とDevidキーを考えると、AKと同じデバイスの間の結合も、中間の攻撃を防ぐために証明する必要があります（例：「Asokan Attack」[RFC6813]）。
This is accomplished in RIV through use of an AK certificate with the same elements as the DevID (same manufacturer's serial number and signed by the same manufacturer's key), but containing the device's unique AK public key instead of the DevID public key. This binding between DevID and AK certificates is critical to reliable attestation.
これは、Devidと同じ要素を持つAK証明書を使用してRIVで達成されます（同じメーカーのシリアル番号と同じメーカーのキーで署名）が、Devid公開キーの代わりにデバイスのユニークなAK公開キーが含まれています。DevIDとAK証明書の間のこの拘束力は、信頼できる証明にとって重要です。
The TCG document "TPM 2.0 Keys for Device Identity and Attestation" [PLATFORM-DEVID-TPM-2.0] specifies OIDs for Attestation Certificates that allow the CA to mark a key as specifically known to be an AK.
TCGドキュメント「TPM 2.0デバイスのアイデンティティと証明のためのキー」[Platform-Devid-TPM-2.0]は、CAがAKであることが特別に知られているようにキーをマークすることを認める証明書のOIDを指定します。
These two key pairs and certificates are used together:
これらの2つの重要なペアと証明書は一緒に使用されます。
* The DevID is used to validate a TLS connection terminating on the device with a known serial number.
* DevIDは、既知のシリアル番号を使用してデバイス上で終了するTLS接続を検証するために使用されます。
* The AK is used to sign attestation quotes, which provides proof that the attestation evidence comes from the same device.
* AKは、証明の証拠が同じデバイスから得られることの証拠を提供する証明の引用に署名するために使用されます。
Replay attacks, where the results of a previous attestation are submitted in response to subsequent requests, are usually prevented by the inclusion of a random nonce in the request to the TPM for a quote. Each request from the Verifier includes a new random number (a nonce). The resulting quote signed by the TPM contains the same nonce, which allows the Verifier to determine freshness (i.e., that the resulting quote was generated in response to the Verifier's specific request). "Time-Based Uni-Directional Attestation" [RATS-TUDA] provides an alternate mechanism to verify freshness without requiring a request/response cycle.
以前の証明の結果がその後のリクエストに応じて提出されるリプレイ攻撃は、通常、見積もりのためにTPMへの要求にランダムな非CEを含めることにより防止されます。検証器からの各要求には、新しい乱数（nonce）が含まれます。TPMによって署名された結果の引用には、同じノンセが含まれているため、検証者は新鮮さを決定できます（つまり、結果の引用が検証剤の特定の要求に応じて生成されたことです）。「時間ベースの一方向の証明」[RATS-TUDA]は、要求/応答サイクルを必要とせずに鮮度を検証する代替メカニズムを提供します。
Although device manufacturers must pre-provision devices with easily verified DevID and AK certificates if SZTP such as described in [RFC8572] is to be supported, use of those credentials is not mandatory. IEEE Std 802.1AR incorporates the idea of an IDevID, which is provisioned by the manufacturer, and a LDevID, which is provisioned by the owner of the device. RIV and [PLATFORM-DEVID-TPM-2.0] extend that concept by defining an IAK and LAK with the same properties.
[RFC8572]に記載されているようなSZTPがサポートされる場合、デバイスメーカーは簡単に検証されたDevidおよびAK証明書を使用して、簡単に検証されたDevidおよびAK証明書を使用する必要がありますが、これらの資格情報の使用は必須ではありません。IEEE STD 802.1ARには、メーカーによってプロビジョニングされたIDEVIDのアイデアと、デバイスの所有者によってプロビジョニングされているLDEVIDのアイデアが組み込まれています。RIVと[Platform-Devid-TPM-2.0]は、同じプロパティでIAKとLAKを定義することにより、その概念を拡張します。
Device owners can use any method to provision the local credentials.
デバイスの所有者は、任意の方法を使用してローカル資格情報をプロビジョニングできます。
* The TCG document [PLATFORM-DEVID-TPM-2.0] shows how the IAKs can be used to certify LDevID and LAK keys. The use of the LDevID and LAK allows the device owner to use a uniform identity structure across device types from multiple manufacturers (in the same way that an "Asset Tag" is used by many enterprises to identify devices they own). The TCG document [PROV-TPM-2.0] also contains guidance on provisioning local identity keys in TPM 2.0. Owners should follow the same practice of binding LDevID and LAK as the manufacturer would for IDevID and IAK. See Section 2.2.
* TCGドキュメント[Platform-Devid-TPM-2.0]は、IAKを使用してLDEVIDおよびLAKキーを証明する方法を示しています。LDEVIDとLAKを使用すると、デバイスの所有者は、複数のメーカーのデバイスタイプ全体で均一なアイデンティティ構造を使用できます（多くの企業が所有するデバイスを特定するために「アセットタグ」が使用されるのと同じ方法で）。TCGドキュメント[Prov-TPM-2.0]には、TPM 2.0のローカルIDキーのプロビジョニングに関するガイダンスも含まれています。所有者は、メーカーがIDEVIDとIAKの場合と同じLDEVIDとLAKを拘束するのと同じ慣行に従う必要があります。セクション2.2を参照してください。
* Device owners, however, can use any other mechanism they want, including physical inspection and programming in a secure location, to assure themselves that local identity certificates are inserted into the intended device if they prefer to avoid placing trust in the manufacturer-provided keys.
* ただし、デバイスの所有者は、安全な場所での物理的検査やプログラミングなど、他のメカニズムを使用して、メーカーが提供するキーに信頼を置かないようにすることを好む場合、ローカルID証明書が意図したデバイスに挿入されることを保証することができます。
Clearly, local keys can't be used for SZTP; installation of the local keys can only be done by some process that runs before the device is installed for network operation, or by using procedures such as those outlined in Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995].
明らかに、ローカルキーはSZTPには使用できません。ローカルキーのインストールは、ネットワーク操作のためにデバイスがインストールされる前に実行されるプロセス、またはリモートセキュアなキーインフラストラクチャ（BRSKI）[RFC8995]で概説されている手順などの手順を使用することによってのみ実行できます。
On the other end of the device lifecycle, provision should be made to wipe local keys when a device is decommissioned to indicate that the device is no longer owned by the enterprise. The manufacturer's initial identity keys must be preserved, as they contain no information that's not already printed on the device's serial number plate.
デバイスライフサイクルのもう一方の端では、デバイスが廃止されている場合は、デバイスがエンタープライズによって所有されなくなったことを示すためにローカルキーを拭くために提供する必要があります。メーカーの最初のIDキーは、デバイスのシリアルナンバープレートにまだ印刷されていない情報が含まれていないため、保存する必要があります。
In addition to the trustworthy provisioning of keys, RIV depends on a number of other factors for trustworthy operation.
キーの信頼できるプロビジョニングに加えて、RIVは信頼できる操作のための他の多くの要因に依存します。
* Secure identity depends on mechanisms to prevent per-device secret keys from being compromised. The TPM provides this capability as a Root of Trust for Storage.
* 安全なアイデンティティは、デバイスごとの秘密キーが侵害されないようにするメカニズムに依存します。TPMは、ストレージの信頼のルートとしてこの機能を提供します。
* Attestation depends on an unbroken chain of measurements, starting from the very first measurement. See Appendix A.1 for background on TPM practices.
* 証明は、最初の測定から始まる壊れていない一連の測定に依存します。TPMプラクティスの背景については、付録A.1を参照してください。
* That first measurement is made by code called the RTM, typically done by trusted firmware stored in boot flash. Mechanisms for maintaining the trustworthiness of the RTM are out of scope for RIV, but could include immutable firmware, signed updates, or a vendor-specific hardware verification technique. See Appendix A.2 for background on Roots of Trust.
* その最初の測定は、通常、ブートフラッシュに保存されている信頼できるファームウェアによって行われるRTMと呼ばれるコードによって行われます。RTMの信頼性を維持するためのメカニズムは、RIVの範囲外ですが、不変のファームウェア、署名された更新、またはベンダー固有のハードウェア検証手法を含めることができます。Roots of Trustの背景については、付録A.2を参照してください。
* The device owner SHOULD provide some level of physical defense for the device. If a TPM that has already been programmed with an authentic DevID is stolen and is inserted into a counterfeit device, attestation of that counterfeit device may become indistinguishable from an authentic device.
* デバイスの所有者は、デバイスにある程度の物理的防御を提供する必要があります。すでに本物のDevidでプログラムされているTPMが盗まれ、偽造デバイスに挿入されている場合、その偽造デバイスの証明は、本物のデバイスと区別できない場合があります。
RIV also depends on reliable Reference Values, as expressed by the RIM [RIM]. The definition of trust procedures for RIMs is out of scope for RIV, and the device owner is free to use any policy to validate a set of reference measurements. It should also be noted that, while RIV can provide a reliable indication that a known software package is in use by the device and that the package has not been tampered with, it is the device owner's responsibility to determine that it's the correct package for the application.
RIVは、RIM [RIM]で表されるように、信頼できる参照値にも依存します。RIMSの信頼手順の定義はRIVの範囲外であり、デバイスの所有者は、あらゆるポリシーを使用して一連の参照測定値を検証できます。また、RIVは、既知のソフトウェアパッケージがデバイスによって使用されていること、およびパッケージが改ざんされていないという信頼できる兆候を提供できるが、それがそれが正しいパッケージであると判断することはデバイスの所有者の責任であることに注意する必要がありますが、それは注意する必要があります。応用。
RIMs may be conveyed either out-of-band or in-band as part of the attestation process (see Section 3.1.3). However, for network devices, where software is usually shipped as a self-contained package, RIMs signed by the manufacturer and delivered in-band may be more convenient for the device owner.
リムは、証明プロセスの一部として、帯域外または帯域内のいずれかを伝えることができます（セクション3.1.3を参照）。ただし、通常、ソフトウェアが自己完結型パッケージとして出荷されるネットワークデバイスの場合、メーカーが署名し、インバンド内で配信されるリムは、デバイスの所有者にとってより便利な場合があります。
The validity of RIV attestation results is also influenced by procedures used to create Reference Values:
RIVの認証結果の妥当性は、参照値を作成するために使用される手順の影響も受けます。
* While the RIM itself is signed, supply chains SHOULD be carefully scrutinized to ensure that the values are not subject to unexpected manipulation prior to signing. Insider attacks against code bases and build chains are particularly hard to spot.
* リム自体に署名されている間、サプライチェーンは、署名前に値が予期しない操作の対象ではないことを確認するために慎重に精査する必要があります。コードベースとビルドチェーンに対するインサイダー攻撃を見つけるのは特に困難です。
* Designers SHOULD guard against hash collision attacks. RIMs often give hashes for large objects of indeterminate size. If one of the measured objects can be replaced with an implant engineered to produce the same hash, RIV will be unable to detect the substitution. TPM 1.2 only uses SHA-1 hashes, which have been shown to be susceptible to collision attack. TPM 2.0 will produce quotes with SHA-256, which so far has resisted such attacks. Consequently, RIV implementations SHOULD use TPM 2.0.
* デザイナーは、ハッシュ衝突攻撃を防ぐ必要があります。リムは、しばしば不定サイズの大きなオブジェクトにハッシュを与えます。測定されたオブジェクトの1つを、同じハッシュを生成するように設計されたインプラントに置き換えることができる場合、RIVは置換を検出できません。TPM 1.2は、衝突攻撃の影響を受けやすいことが示されているSHA-1ハッシュのみを使用します。TPM 2.0は、SHA-256で引用符を作成します。これは、これまでこのような攻撃に抵抗しています。したがって、RIVの実装はTPM 2.0を使用する必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
TCG technologies can play an important part in the implementation of RIV. Standards for many of the components needed for implementation of RIV already exist:
TCGテクノロジーは、RIVの実装において重要な役割を果たすことができます。RIVの実装に必要な多くのコンポーネントの標準はすでに存在しています。
* Platform identity can be based on IEEE 802.1AR DevID, coupled with careful supply-chain management by the manufacturer.
* プラットフォームのアイデンティティは、IEEE 802.1AR Devidに基づいて、メーカーによる慎重な供給鎖管理と組み合わせています。
* Complex supply chains can be certified using TCG Platform Certificates [PLATFORM-CERTS].
* 複雑なサプライチェーンは、TCGプラットフォーム証明書[Platform-Certs]を使用して認定できます。
* The TCG TAP mechanism coupled with [RFC9684] can be used to retrieve attestation evidence.
* [RFC9684]と組み合わせたTCG TAPメカニズムを使用して、証拠の証拠を取得できます。
* Reference Values must be conveyed from the software authority (e.g., the manufacturer) in RIMs to the system in which verification will take place. IETF and TCG SWID and CoSWID work ([RFC9393] [RIM]) forms the basis for this function.
* 参照値は、RIMSのソフトウェア機関（メーカーなど）から、検証が行われるシステムに伝えられる必要があります。IETFおよびTCG SWIDおよびCOSWIDワーク（[RFC9393] [RIM]）は、この関数の基礎を形成します。
[CEL] Trusted Computing Group, "Canonical Event Log Format",
Version 1.0, Revision 0.41, February 2022,
<https://trustedcomputinggroup.org/wp-content/uploads/
TCG_IWG_CEL_v1_r0p41_pub.pdf>.
[IEEE-802-1AR]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Secure Device Identity", IEEE Std 802.1AR-2018,
DOI 10.1109/IEEESTD.2018.8423794, August 2018,
<https://doi.org/10.1109/IEEESTD.2018.8423794>.
[IMA] The kernel development community, "dm-ima", Linux Kernel
6.11, 15 September 2024,
<https://www.kernel.org/doc/html/v6.11/admin-guide/device-
mapper/dm-ima.html>. The latest version can be found at
https://docs.kernel.org/admin-guide/device-mapper/dm-
ima.html.
[PC-CLIENT-BIOS-TPM-2.0]
Trusted Computing Group, "TCG PC Client Specific Platform
Firmware Profile Specification", Family "2.0", Level 00,
Version 1.05, Revision 23, May 2021,
<https://trustedcomputinggroup.org/resource/pc-client-
specific-platform-firmware-profile-specification/>.
[PC-CLIENT-EFI-TPM-1.2]
Trusted Computing Group, "TCG EFI Platform Specification",
For TPM Family 1.1 or 1.2, Version 1.22, Revision 15,
January 2014, <https://trustedcomputinggroup.org/resource/
tcg-efi-platform-specification/>.
[PC-CLIENT-RIM]
Trusted Computing Group, "TCG PC Client Reference
Integrity Manifest Specification", Version 1.04, November
2020, <https://trustedcomputinggroup.org/resource/tcg-pc-
client-reference-integrity-manifest-specification/>.
[PLATFORM-DEVID-TPM-2.0]
Trusted Computing Group, "TPM 2.0 Keys for Device Identity
and Attestation", Version 1.00, Revision 12, October 2021,
<https://trustedcomputinggroup.org/resource/tpm-2-0-keys-
for-device-identity-and-attestation/>.
[PLATFORM-ID-TPM-1.2]
Trusted Computing Group, "TCG Infrastructure WG TPM Keys
for Platform Identity for TPM 1.2", Specification Version
1.0, Revision 3, August 2015,
<https://trustedcomputinggroup.org/resource/tpm-keys-for-
platform-identity-for-tpm-1-2-2/>.
[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/info/rfc2119>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[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/info/rfc5280>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[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/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[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/info/rfc9334>.
[RFC9393] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
Waltermire, "Concise Software Identification Tags",
RFC 9393, DOI 10.17487/RFC9393, June 2023,
<https://www.rfc-editor.org/info/rfc9393>.
[RFC9684] Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen,
B., Xia, L., Laffey, T., and G. C. Fedorkow, "A YANG Data
Model for Challenge-Response-Based Remote Attestation
(CHARRA) Procedures Using Trusted Platform Modules
(TPMs)", RFC 9684, DOI 10.17487/RFC9684, December 2024,
<https://www.rfc-editor.org/info/rfc9684>.
[RIM] Trusted Computing Group, "TCG Reference Integrity Manifest
(RIM) Information Model", Version 1.01, Revision 0.16,
November 2020,
<https://trustedcomputinggroup.org/resource/tcg-reference-
integrity-manifest-rim-information-model/>.
[SWID] ISO/IEC, "Information technology - IT asset management -
Part 2: Software identification tag", ISO/
IEC 19770-2:2015, October 2015,
<https://www.iso.org/standard/65666.html>.
[TAP] Trusted Computing Group, "TCG Trusted Attestation Protocol
(TAP) Information Model for TPM Families 1.2 and 2.0 and
DICE Family 1.0", Version 1.0, Revision 0.36, October
2018, <https://trustedcomputinggroup.org/wp-
content/uploads/
TNC_TAP_Information_Model_v1.00_r0.36-FINAL.pdf>.
[AIK-ENROLL]
Trusted Computing Group, "TCG Infrastructure Working Group
A CMC Profile for AIK Certificate Enrollment", Version
1.0, Revision 7, March 2011,
<https://trustedcomputinggroup.org/resource/tcg-
infrastructure-working-group-a-cmc-profile-for-aik-
certificate-enrollment/>.
[IEEE-802.1AE]
IEEE, "IEEE Standard for Local and metropolitan area
networks - Media Access Control (MAC) Security", IEEE Std
802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, 2018,
<https://doi.org/10.1109/IEEESTD.2018.8585421>.
[IEEE-802.1X]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Port-Based Network Access Control", IEEE Std
802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, February
2020, <https://doi.org/10.1109/IEEESTD.2020.9018454>.
[LLDP] IEEE, "IEEE Standard for Local and metropolitan area
networks - Station and Media Access Control Connectivity
Discovery", IEEE Std 802.1AB-2016,
DOI 10.1109/IEEESTD.2016.7433915, March 2016,
<https://doi.org/10.1109/IEEESTD.2016.7433915>.
[NET-EQ] Trusted Computing Group, "TCG Guidance for Securing
Network Equipment Using TCG Technology", Version 1.0,
Revision 29, January 2018,
<https://trustedcomputinggroup.org/resource/tcg-guidance-
securing-network-equipment/>.
[NIST-IR-8060]
Waltermire, D., Cheikes, B. A., Feldman, L., and G. Witte,
"Guidelines for the Creation of Interoperable Software
Identification (SWID) Tags", NIST NISTIR 8060,
DOI 10.6028/NIST.IR.8060, April 2016,
<https://nvlpubs.nist.gov/nistpubs/ir/2016/
NIST.IR.8060.pdf>.
[PLATFORM-CERTS]
Trusted Computing Group, "TCG Platform Attribute
Credential Profile", Specification Version 1.0, Revision
16, January 2018,
<https://trustedcomputinggroup.org/resource/tcg-platform-
attribute-credential-profile/>.
[PROV-TPM-2.0]
Trusted Computing Group, "TCG TPM v2.0 Provisioning
Guidance", Version 1.0, Revision 1.0, March 2017,
<https://trustedcomputinggroup.org/wp-content/uploads/TCG-
TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf>.
[RATS-EAT] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", Work in
Progress, Internet-Draft, draft-ietf-rats-eat-31, 6
September 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-eat-31>.
[RATS-INTERACTION-MODELS]
Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference
Interaction Models for Remote Attestation Procedures",
Work in Progress, Internet-Draft, draft-ietf-rats-
reference-interaction-models-11, 22 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
reference-interaction-models-11>.
[RATS-NET-DEV-SUB]
Birkholz, H., Voit, E., and W. Pan, "Attestation Event
Stream Subscription", Work in Progress, Internet-Draft,
draft-ietf-rats-network-device-subscription-05, 7 July
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
rats-network-device-subscription-05>.
[RATS-TUDA]
Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
"Time-Based Uni-Directional Attestation", Work in
Progress, Internet-Draft, draft-birkholz-rats-tuda-07, 10
July 2022, <https://datatracker.ietf.org/doc/html/draft-
birkholz-rats-tuda-07>.
[RATS-USECASES]
Richardson, M., Wallace, C., and W. Pan, "Use cases for
Remote Attestation common encodings", Work in Progress,
Internet-Draft, draft-richardson-rats-usecases-08, 2
November 2020, <https://datatracker.ietf.org/doc/html/
draft-richardson-rats-usecases-08>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.
[RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment
(NEA) Asokan Attack Analysis", RFC 6813,
DOI 10.17487/RFC6813, December 2012,
<https://www.rfc-editor.org/info/rfc6813>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
[SP800-155]
NIST, "BIOS Integrity Measurement Guidelines (Draft)",
NIST SP 800-155 (Draft), December 2011,
<https://csrc.nist.gov/files/pubs/sp/800/155/ipd/docs/
draft-sp800-155_dec2011.pdf>.
[SP800-193]
NIST, "Platform Firmware Resiliency Guidelines", NIST
SP 800-193, DOI 10.6028/NIST.SP.800-193, May 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-193.pdf>.
[SWID-GEN] Labs64, "SoftWare IDentification (SWID) Tags Generator
(Maven Plugin)",
<https://github.com/Labs64/swid-maven-plugin>.
[TCG-RT] Trusted Computing Group, "TCG Roots of Trust
Specification", (Draft), Family "1.0", Level 00, Revision
0.20, July 2018, <https://trustedcomputinggroup.org/wp-
content/uploads/
TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf>.
[TPM-1.2] Trusted Computing Group, "TPM 1.2 Main Specification",
Level 2, Version 1.2, Revision 116, March 2011,
<https://trustedcomputinggroup.org/resource/tpm-main-
specification/>.
[TPM-2.0] Trusted Computing Group, "Trusted Platform Module
Library", Family "2.0", Level 00, Revision 01.83, March
2024, <https://trustedcomputinggroup.org/resource/tpm-
library-specification/>.
The TPM and surrounding ecosystem provide three interlocking capabilities to enable secure collection of evidence from a remote device: PCRs, a Quote mechanism, and a standardized Event Log.
TPMと周囲のエコシステムは、リモートデバイスから証拠を安全に収集するための3つの連動する機能、すなわちPCR、クォートメカニズム、および標準化されたイベントログを提供しています。
Each TPM has at least eight and at most twenty-four PCRs (depending on the profile and vendor choices), each one large enough to hold one hash value (SHA-1, SHA-256, and other hash algorithms can be used, depending on TPM version). PCRs can't be accessed directly from outside the chip, but the TPM interface provides a way to "extend" a new security measurement hash into any PCR, a process by which the existing value in the PCR is hashed with the new security measurement hash, and the result placed back into the same PCR. The result is a composite fingerprint comprising the hash of all the security measurements extended into each PCR since the system was reset.
各TPMには、少なくとも8つ、最大24のPCR（プロファイルとベンダーの選択肢によって異なります）があり、それぞれが1つのハッシュ値を保持するのに十分な大きさです（SHA-1、SHA-256、およびその他のハッシュアルゴリズムはTPMのバージョンに応じて使用できます）。PCRにはチップの外側から直接アクセスすることはできませんが、TPMインターフェイスは、新しいセキュリティ測定ハッシュを任意のPCRに「拡張」する方法を提供します。このプロセスでは、PCR内の既存の値が新しいセキュリティ測定ハッシュとハッシュされ、その結果が同じPCRに戻されます。その結果、システムがリセットされて以来、各PCRに拡張されたすべてのセキュリティ測定のハッシュを含む合成されたフィンガープリントが作成されます。
Every time a PCR is extended, an entry should be added to the corresponding Event Log. Logs contain the security measurement hash plus informative fields offering hints as to which event generated the security measurement. The Event Log itself is protected against accidental manipulation, but it is implicitly tamper-evident: Any verification process can read the security measurement hash from the log events, compute the composite value, and compare that to what is in the PCR. If there's no discrepancy, the logs do provide an accurate view of what was placed into the PCR.
PCRが拡張されるたびに、対応するイベントログにエントリが追加されます。ログには、セキュリティ測定ハッシュと、セキュリティ測定を生成したイベントに関するヒントを提供する情報フィールドが含まれています。イベントログ自体は偶発的な操作から保護されていますが、暗黙的に改ざんを証明できます。任意の検証プロセスは、ログイベントからセキュリティ測定ハッシュを読み取り、合成値を計算し、それをPCRの値と比較できます。不一致がない場合、ログはPCRに配置された内容の正確なビューを提供します。
Note that the composite hash-of-hashes recorded in PCRs is order-dependent, resulting in different PCR values for different ordering of the same set of events (e.g., Event A followed by Event B yields a different PCR value than B followed by A). For single-threaded code, where both the events and their order are fixed, a Verifier may validate a single PCR value, and use the log only to diagnose a mismatch from Reference Values. However, operating system code is usually nondeterministic, meaning that there may never be a single "known good" PCR value. In this case, the Verifier may have to verify that the log is correct, and then analyze each item in the log to determine if it represents an authorized event.
PCRに記録されたハッシュの複合ハッシュは順序依存性であり、同じ一連のイベントの異なる順序付け（たとえば、イベントAの後にイベントBが続く場合と、イベントBの後にイベントAが続く場合とで、異なるPCR値が生成されます）に対して異なるPCR値をもたらすことに注意してください。イベントとその順序の両方が固定されているシングルスレッドコードの場合、検証者は単一のPCR値を検証し、参照値との不一致を診断するためにのみログを使用することができます。ただし、オペレーティングシステムコードは通常非決定的であるため、単一の「信頼できる」PCR値が存在しない場合があります。この場合、検証者はログが正しいことを確認し、その後、ログ内の各項目を分析して、それが承認されたイベントであるかどうかを判断する必要がある場合があります。
In a conventional TPM Attestation environment, the first measurement must be made and extended into the TPM by trusted device code (called the RTM). That first measurement should cover the segment of code that is run immediately after the RTM, which then measures the next code segment before running it, and so on, forming an unbroken chain of trust. See [TCG-RT] for more on Mutable vs. Immutable Roots of Trust.
従来のTPMアテステーション環境では、信頼できるデバイスコード（RTMと呼ばれる）が最初の測定を行い、TPMに拡張する必要があります。その最初の測定は、RTMの直後に実行されるコードセグメントをカバーし、そのセグメントが実行前に次のコードセグメントを測定するといった連鎖により、途切れることのない信頼のチェーンを形成します。可変な信頼の基点と不変な信頼の基点の詳細については、[TCG-RT]を参照してください。
The TPM provides another mechanism called a Quote that can read the current value of the PCRs and package them, along with the Verifier's nonce, into a TPM-specific data structure signed by an Attestation private key, known only to the TPM.
TPMは、PCRの現在の値を読み取り、検証者のnonceとともに、TPMのみが知るアテステーション秘密鍵によって署名されたTPM固有のデータ構造にパッケージ化できるクォートと呼ばれる別のメカニズムを提供します。
It's important to note that the Quote data structure is signed inside the TPM (see Section 5, Security Considerations). The trust model is preserved by retrieving the Quote in a way that does not invalidate the signature, as specified in [RFC9684]. The structure of the command and response for a quote, including its signature, as generated by the TPM, can be seen in Part 3, Section 16.5, of [TPM-1.2] and Section 18.4.2 of [TPM-2.0].
クォートデータ構造はTPM内で署名されていることに注意することが重要です（セクション5、セキュリティに関する考慮事項を参照）。信頼モデルは、[RFC9684]で指定されているように、署名を無効にしない方法でクォートを取得することで維持されます。TPMによって生成された、署名を含むクォートのコマンドと応答の構造は、[TPM-1.2]のパート3、セクション16.5、および[TPM-2.0]のセクション18.4.2で見ることができます。
The Verifier uses the Quote and Log together. The Quote contains the composite hash of the complete sequence of security measurement hashes, signed by the TPM's private AK. The Log contains a record of each measurement extended into the TPM's PCRs. By computing the composite hash of all the measurements, the Verifier can verify the integrity of the Event Log, even though the Event Log itself is not signed. Each hash in the validated Event Log can then be compared to corresponding expected values in the set of Reference Values to validate overall system integrity.
Verifierはクォートとログを一緒に使用します。クォートには、TPMのプライベートAKが署名したセキュリティ測定ハッシュの完全なシーケンスの複合ハッシュが含まれています。ログには、TPMのPCRに拡張された各測定の記録が含まれています。すべての測定値の複合ハッシュを計算することにより、イベントログ自体が署名されていない場合でも、Verifierはイベントログの整合性を検証できます。検証されたイベントログの各ハッシュは、参照値のセットの対応する期待値と比較して、システム全体の整合性を検証できます。
A summary of information exchanged in obtaining quotes from TPM 1.2 and TPM 2.0 can be found in [TAP], Section 4. Detailed information about PCRs and Quote data structures can be found in [TPM-1.2], [TPM-2.0]. Recommended log formats include [PC-CLIENT-BIOS-TPM-2.0], and [CEL].
TPM 1.2およびTPM 2.0からクォートを取得する際に交換される情報の要約は、[TAP]のセクション4で確認できます。PCRおよびクォートデータ構造の詳細情報は、[TPM-1.2]、[TPM-2.0]で確認できます。推奨されるログ形式には、[PC-Client-BIOS-TPM-2.0]および[CEL]が含まれます。
The measurements needed for attestation require that the device being attested is equipped with an RTM, that is, some trustworthy mechanism that can compute the first measurement in the chain of trust required to attest that each stage of system startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs) to record the results, and a Root of Trust for Reporting to report the results.
アテステーションに必要な測定では、アテステーション対象のデバイスに、システム起動の各段階が検証されていることを証明するために必要な信頼のチェーンで最初の測定値を計算できる信頼できるメカニズムであるRTM、結果を記録するためのストレージの信頼の基点（すなわち、TPM PCR）、および結果を報告するための報告の信頼の基点が装備されている必要があります。
While there are many complex aspects of Roots of Trust ([TCG-RT] [SP800-155] [SP800-193]), two aspects that are important in the case of attestation are:
信頼の基点には多くの複雑な側面がありますが（[TCG-RT] [SP800-155] [SP800-193]）、アテステーションの場合に重要な2つの側面は次のとおりです。
* The first measurement computed by the RTM and stored in the TPM's Root of Trust for Storage must be assumed to be correct.
* RTMによって計算され、TPMのストレージの信頼の基点に保存された最初の測定は、正しいと想定する必要があります。
* There must not be a way to reset the Root of Trust for Storage without re-entering the RTM code.
* RTMコードに再度入ることなく、ストレージの信頼の基点をリセットする方法が存在してはなりません。
The first measurement must be computed by code that is implicitly trusted; if that first measurement can be subverted, none of the remaining measurements can be trusted. (See [SP800-155].)
最初の測定は、暗黙的に信頼されるコードによって計算する必要があります。その最初の測定が改ざんされる可能性がある場合、残りの測定値はどれも信頼できません。（[SP800-155]を参照してください。）
It's important to note that the trustworthiness of the RTM code cannot be assured by the TPM or TPM supplier -- code or procedures external to the TPM must guarantee the security of the RTM.
RTMコードの信頼性はTPMまたはTPMサプライヤーによって保証されないことに注意することが重要です。TPMの外部のコードまたは手順は、RTMのセキュリティを保証する必要があります。
Retrieval of identity and attestation state uses one protocol stack, while retrieval of Reference Values uses a different set of protocols. Figure 5 shows the components involved.
IDとアテステーション状態の取得は1つのプロトコルスタックを使用し、参照値の取得は異なるプロトコルセットを使用します。図5は、関係するコンポーネントを示しています。
+-----------------------+ +-------------------------+
| | | |
| Attester |<-------------| Verifier |
| (Device) |------------->| (Management Station) |
| | | | |
+-----------------------+ | +-------------------------+
|
-------------------- --------------------
| |
------------------------------- ---------------------------------
| Reference Values | | Attestation |
------------------------------- ---------------------------------
********************************************************************
* IETF Remote Attestation Conceptual Data Flow *
* RFC9334, Figure 1 *
********************************************************************
......................... .........................
. Reference Integrity . . TAP Info .
. Manifest . . Model and Canonical .
. . . Log Format .
......................... .........................
************************* *************************
* YANG SWID Module * * YANG Attestation *
* RFC9393 * * Module *
* * * RFC9684 *
* * * *
************************* *************************
************************* *************************
* XML, JSON, CBOR, etc. * * XML, JSON, CBOR, etc. *
************************* *************************
************************* *************************
* RESTCONF/NETCONF * * RESTCONF/NETCONF *
************************* *************************
************************* *************************
* TLS, SSH * * TLS, SSH *
************************* *************************
Figure 5: RIV Protocol Stacks
図5：RIVプロトコルスタック
IETF documents are captured in boxes surrounded by asterisks. TCG documents are shown in boxes surrounded by dots.
IETFドキュメントは、アスタリスクに囲まれたボックスでキャプチャされます。TCGドキュメントは、ドットに囲まれたボックスに表示されます。
Table 2 summarizes many of the actions needed to complete an Attestation system, with links to relevant documents. While documents are controlled by several standards organizations, the implied actions required for implementation are all the responsibility of the manufacturer of the device, unless otherwise noted.
表2は、関連するドキュメントへのリンクを使用して、アテステーションシステムを完了するために必要なアクションの多くをまとめたものです。文書はいくつかの標準組織によって管理されていますが、特に明記しない限り、実装に必要とされる行動はすべてデバイス製造元の責任です。
As noted, SWID tags can be generated many ways, but one possible tool is [SWID-GEN].
前述のように、SWIDタグは多くの方法で生成できますが、可能なツールの1つは[Swid-Gen]です。
+========================================+==========================+
| Component | Controlling |
| | Specification |
+========================================+==========================+
| Make a Secure execution environment: | [TCG-RT] |
| | |
| * Attestation depends on a secure | <www.uefi.org> |
| RTM outside the TPM, as well as | |
| Roots for Storage and Reporting | |
| inside the TPM. | |
| | |
| * Refer to "TCG Roots of Trust | |
| Specification" [TCG-RT]. | |
| | |
| * [SP800-193] also provides | |
| guidelines on Roots of Trust. | |
+----------------------------------------+--------------------------+
| Provision the TPM as described in the | [PLATFORM-DEVID-TPM-2.0] |
| TCG documents. | |
| | [PLATFORM-CERTS] |
+----------------------------------------+--------------------------+
| Put a DevID or Platform Certificate | [PLATFORM-DEVID-TPM-2.0] |
| in the TPM: | |
| | [PLATFORM-CERTS] |
| * Install an IAK at the same time so | |
| that Attestation can work out of | |
| the box. | |
| | |
| * Equipment suppliers and owners may | |
| want to implement LDevID as well | |
| as IDevID. | |
| +--------------------------+
| | [IEEE-802-1AR] |
+----------------------------------------+--------------------------+
| Connect the TPM to the TLS stack: | Vendor TLS stack (This |
| | action configures TLS to |
| * Use the DevID in the TPM to | use the DevID as its |
| authenticate TAP connections, | client certificate.) |
| identifying the device. | |
+----------------------------------------+--------------------------+
| Make CoSWID tags for BIOS/Loader/ | [RFC9393] |
| Kernel objects: | |
| | [SWID] |
| * Add reference measurements into | |
| SWID tags. | [NIST-IR-8060] |
| | |
| * Manufacturer should sign the SWID | |
| tags. | |
| | |
| * The TCG RIM-IM [RIM] identifies | |
| further procedures to create | |
| signed RIM documents that provide | |
| the necessary reference | |
| information. | |
+----------------------------------------+--------------------------+
| Package the SWID tags with a vendor | Retrieve tags with |
| software release: | [RFC9393]. |
| | |
| * A tag-generator plugin such as | |
| [SWID-GEN] can be used. | |
| +--------------------------+
| | [PC-CLIENT-RIM] |
+----------------------------------------+--------------------------+
| Use PC Client measurement definitions | [PC-CLIENT-BIOS-TPM-2.0] |
| to define the use of PCRs (although | |
| Windows OS is rare on Networking | |
| Equipment, UEFI BIOS is not). | |
+----------------------------------------+--------------------------+
| Use TAP to retrieve measurements: | [RFC9684] |
| | |
| * Map to YANG. | [CEL] |
| | |
| * Use Canonical Log Format. | |
+----------------------------------------+--------------------------+
| A Verifier (as described in | |
| [RFC9334], Section 3) should request | |
| the attestation and analyze the | |
| result. The Verifier application | |
| might be broken down to several more | |
| components: | |
| | |
| * A Posture Manager Server that | |
| collects reports and stores them | |
| in a database. | |
| | |
| * One or more Analyzers that can | |
| look at the results and figure out | |
| what it means. | |
+----------------------------------------+--------------------------+
Table 2: Component Status
表2：コンポーネントステータス
The authors wish to thank numerous reviewers for generous assistance, including William Bellingrath, Mark Baushke, Ned Smith, Henk Birkholz, Tom Laffey, Dave Thaler, Wei Pan, Michael Eckel, Thomas Hardjono, Bill Sulzen, Willard (Monty) Wiseman, Kathleen Moriarty, Nancy Cam-Winget, and Shwetha Bhandari.
著者は、ウィリアム・ベリングラス、マーク・バウシュケ、ネッド・スミス、ヘンク・バークホルツ、トム・ラフィー、デイブ・ターラー、ウェイ・パン、マイケル・エッケル、トーマス・ハードジョノ、ビル・スルゼン、ウィラード（モンティ）ワイズマン、キャスリーン・モリアーティ、ナンシー・カム・ウィンゲット、シュエサ・バンダリの寛大な支援について、多数のレビュアーに感謝いたします。
Guy C. Fedorkow (editor)
Juniper Networks, Inc.
10 Technology Park Drive
Westford, Massachusetts 01886
United States of America
Email: gfedorkow@juniper.net
Eric Voit
Cisco Systems
Email: evoit@cisco.com
Jessica Fitzgerald-McKay
National Security Agency
9800 Savage Road
Ft. Meade, Maryland 20755
United States of America
Email: jmfitz2@nsa.gov