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）を含むネットワークデバイスにインストールされているファームウェアとソフトウェアの整合性をリモート認証するためのワークフローについて説明します。TPMSによって提供されます。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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-secases]のセクション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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "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]から多くの用語が再利用されます。これらには、証拠、証明の結果、attester、証拠、参照値、依存者、検証者、および検証者の所有者に関する評価ポリシーが含まれます。
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]で見つかった定義に沿って、このドキュメントでは、エンダーザーという用語を使用して、参照値は参照値プロバイダーによって署名されている間、Attesterが使用する証明書に署名する役割と証明証明書を参照します。通常、ネットワークデバイスのメーカーは、最終的には検証者の所有者次第ですが、[エンサーと参照価値プロバイダーの両方として受け入れられます。
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.
* デバイスのアイデンティティは、信頼できるアイデンティティを提供するメカニズムであり、ネットワークへの添付のために認可されたメーカーから注文した特定のデバイスがインストールされたものであり、ネットワークに存在し続けることをネットワークマネージャーに安心させることができます。デバイスアイデンティティのメカニズムの一部として、メーカーのアイデンティティの暗号化された証明も提供されます。
* 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を参照）。前の段階で検証された各段階に埋め込まれた証明関数は、次の段階を測定し、タンパー耐性ストレージの結果を記録します。測定は、Astesterの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. 証拠の生成とは、アテスターがデバイスプロパティに関する主張の暗号化された証明（証拠）を生成するプロセスです。特に、デバイスの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. デバイスの識別とは、ネットワークを構成するデバイスのアイデンティティの依存者（最終的にはネットワーク管理者）とメーカーのアイデンティティを保証するメカニズムを指します。
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. 証拠の伝達は、攻撃された証拠を、手順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の測定値を比較することを意味します。その後、証拠の評価ポリシーは、接続されたデバイスの意図した構成状態を表す基準値（別名ゴールデン測定）に対して見つかった証拠と一致する可能性があります。
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）証明書には、工場を離れたときにデバイスの身元を確立するメーカーによるステートメントが含まれています。より複雑な製造後のサプライチェーン（バリューアドレスリセラーなど）、またはさまざまなプライバシーの懸念を伴う一部のアプリケーションは、プラットフォーム認証に代替メカニズムを使用することをお勧めします（たとえば、TCGプラットフォーム証明書[プラットフォーム洞窟]または製造後の製造後ローカル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操作の概要については、[TPM-1.2]および[TPM-2.0]の詳細については、付録A.1を参照）。
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は、エンドポイント上の悪意のあるソフトウェアが意図した関数を破壊し、エンドポイントが侵害されたステータスを報告するのを防ぐ可能性がある「横になっているエンドポイント」の問題に対処する必要があります。（さらなるセキュリティに関する考慮事項については、セクション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は、可能な限り「箱から出して」作業する必要があります。つまり、エンドユーザーのサイトで必要な可能性のあるプロビジョニングステップまたは構成データベースが必要です。ネットワーク機器は、多くの場合、「自己構成」し、そのアイデンティティと動作姿勢を証明するために手動介入なしで確実に手を差し伸べ、その後、独自の構成をダウンロードするために必要です。安全なゼロタッチプロビジョニング（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）のためのプライバシー認証局（ATSETATIATIAN CAとも呼ばれます）の必要性を回避します。[AIK-Enroll]またはTCGプラットフォーム証明書[プラットフォームキャット]。
* 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に示すように、セクション1.5のリモート証明手順は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.
* システムスタートアップ、またはブートフェーズ中、各個別のソフトウェアオブジェクトは、アテスターによって「測定」されます。オブジェクトのアイデンティティ、ハッシュ（つまり、暗号化ダイジェスト）、およびバージョン情報はログに記録されます。ハッシュは、ログエントリの検証に使用できる方法で、TPM（拡張ハッシュの詳細については付録A.1を参照）に拡張されます。測定プロセスは、一般に、測定されたブートで使用される層状のトラストチェーンモデルに従います。ここで、システムの各段階が次の段階を測定し、測定をTPMに拡張してから起動します。このモデルのアーキテクチャの定義については、[RFC9334]のセクション3.2 [階層化された証明環境]を参照してください。
* 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.
* デバイスが実行され、運用上のネットワーク接続があると、検証が行われます。独自の信頼できる環境で実行される別の検証者は、ネットワークデバイスを尋問して、各ソフトウェアオブジェクトをハッシュすることによって収集されたダイジェストのコピーを取得します。[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.
その結果、検証者は、被験者[RFC5280]をチェックし、TPMの証明公開キーを含む証明書の署名をチェックすることにより、デバイスの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.
証明とアイデンティティは密接にリンクされていることに注意する必要があります。特定のバージョンのソフトウェアがロードされたという署名された証拠は、証拠を作成しているアテスターのアイデンティティの暗号化された証拠なしではほとんど価値がありません。
+-------------------------------------------------------+
| +---------+ +--------+ +--------+ +---------+ |
| |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の証明はPCRSに焦点を当てていますが、これらのレジスタは、ログエントリで伝えられる添付の証拠を証明するための手段のみです。PCRSに拡張されたのは、ログエントリのハッシュであり、最終的なPCR値を引用と呼ばれる構造の形で取得できます。複数のPCRの使用は、異なるクラスのオブジェクト間である程度の独立性を提供するためだけに機能し、他のクラスの拡張ハッシュを変更せずに1つのクラスのオブジェクトを更新できます。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:
一般に、PCRSへの測定の割り当ては、デバイスメーカーが作成したポリシーの選択であり、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]は、統一された拡張可能なファームウェアインターフェイス（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-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]。これは通常、アダプターカードなどをユーザーアクセス可能な周辺コンポーネントインターコネクト（PCI）またはその他のスロットに追加することによって行われます。UEFIシステムでは、これらのデバイスは、PCR [2]に測定され、UEFI BIOSによって実行されるオプション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の使用を非常に慎重に指定していますが、組み込まれたソフトウェアベンダーはかなり柔軟性があることに注意する必要があります。Verifiersは通常、どのログエントリが結果的であり、どのログエントリではないかを知る必要があります（おそらくローカルポリシーによって制御されます）が、検証者は、各ログエントリが何を意味するのか、なぜ特定の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アプリケーションでは、ATSETATIANS秘密キーとDevID秘密鍵の両方がTPMによって保護されなければなりません。他のTPM構成手順に応じて、2つのキーが異なる可能性があります。考慮事項のいくつかは、「デバイスのアイデンティティと証明のためのTPM 2.0キー」ドキュメント[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キー」ドキュメント[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証明書と同じ一意のデバイス識別（つまり、同じサブジェクトとsubjectaltname（存在する場合）である場合でも、devidと並行する必要があります。ペアは異なります）。対応するAK証明書を調べることにより、検証者は、AKによって署名されたデバイスの引用を、提供したデバイスに直接リンクできます。AK証明書の被験者が対応するDevid証明書と一致しない場合、または異なる当局によって署名されている場合、検証者はアソカンスタイルの中間攻撃の検出を信号することができます（セクション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を使用すると予想されるネットワークデバイスは、製造業者が事前に生成されたキー（初期devidおよびIdevidおよびIAKと呼ばれる初期AK）を備えた出荷する必要があります。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は、デバイスメーカーによって作成され、ソフトウェアイメージの一部としてデバイスとともに出荷することも、他のいくつかの方法を取得することもできます（製造業者から、第三者から、所有者の所有者の概念から、メーカーからの検証者に直接取得できます。「既知の良いシステム」など）。デバイス自体からリムを取得することで、パブリックインターネットにアクセスできないシステムや、管理ステーション自体ではない他のデバイス（例：ピアデバイス、セクション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：基準値プロバイダー（デバイスメーカーまたはその他の機関）は、デバイスにあると予想されるソフトウェア画像に対応し、検証者が利用できる参照値プロバイダーによって署名されます。（これを実現するための「インバンド」および「バンドから外れ」の方法については、セクション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：依存している当事者に代わって、検証者（ネットワーク管理ステーション）は、devid、測定値、および場合によってはアテスターにリムを要求します。
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が署名する測定値）、およびオプションでリムを提供することにより、リクエストに応答します。
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プラットフォーム仕様」[PC-Client-EFI-TPM-1.2]または「TCG PCクライアント固有のプラットフォームファームウェアプロファイル仕様」に従ってファームウェアと起動可能なモジュールの測定値を取得する必要があります[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は、TPMSで保護されているキーを使用して、IEEE STD 802.1AR [IEEE-802-1AR]で指定されているDevid証明書として管理する必要があります。
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 PCクライアント固有のプラットフォームファームウェアプロファイル」にTCG UEFI BIOSイベントログ[PC-Client-EFI-TPM-1.2]を使用する必要があります[PC-Client-BIOS-TPM-2.0]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の両方を使用して、証明書を設定したDevidを使用して、機器ベンダーが出荷する必要があります。IAK証明書には、Devidと同じID情報を含める必要があります（具体的には、メーカーが署名した同じ件名とsubjectaltname（使用する場合））。IAKは、TPMの見積もりに署名するために使用できるキーの一種ですが、他のオブジェクトではありません（つまり、TCG「制限付き」キーとしてマークされています。この規則は、「デバイスのアイデンティティと証明のためのTPM 2.0キー」で説明されています。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]で定義されている）を装備する必要があります。
* 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.
ネットワークで何を望んでいるかを決定するのはネットワーク管理者次第でなければなりませんが、ソフトウェアサプライヤーは、証拠が既知の良い、既知の悪い、または未知の証拠が示されるかどうかを判断するために使用される署名されたリムで、参照値を署名したリムで提供する必要があります。ソフトウェア構成。
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カーネル）は、結果を報告する前に、既知のシーケンスで本質的に単一のスレッド化および実行されます。この場合、ハッシュを計算して関連するPCRを拡張する方法は複雑な場合がありますが、最終的な結果は、ソフトウェア（より可能性が高い、ファームウェア）ベンダーが、関連するPCRに「」存在する必要がある良いPCR値を持つことになることです。ボックスが起動した後。この場合、署名された参照測定は、指定されたバージョンの予想ハッシュを単純にリストすることができます。ただし、中間のハッシュを含むリムは、予想される最終的なハッシュが報告されていないケースのデバッグに役立ちます。
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値がある場合（たとえば、Linux IMA [IMA]）、システムの操作後に取得された測定値がより複雑になる可能性があります。この場合、検証者は、ログから予想される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）情報モデル」というタイトルで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に拡張される場合の引用を理解するために、起動中の引用にどのソフトウェアモジュールが寄与したかを識別するイベントログも提供する必要があります。必要に応じて、ログには、署名された引用で伝えられたダイジェストの正確な再構成を許可することにより、その完全性を示すのに十分な情報を含める必要があります（つまり、ログ内のすべてのハッシュのハッシュを計算すると、PCRSに含まれるものと同じ値が生成されるはずです。それらが一致しない場合、ログに改ざんされている可能性があります。
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:
Adtesterと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ユースケースの相互運用可能な実装を可能にするために、追加の前提条件が確立されています。これらの前提条件は、検証者が攻撃者によって収集された測定値を取得および評価できるように、十分なコンテキスト情報を提供することを目的としています。
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のTPMSでプロビジョニングする必要があります。
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の前提条件が満たされると、検証剤は到達者から証拠を取得することができます。図3は、[rats-interaction-models]のセクション7.1から派生した、検証剤と攻撃者との間のRIV情報の流れを示しています。この図では、入力パラメーターと出力パラメーターを備えた各イベントは、「イベント（入力パラム）=>（出力）」として表示されます。示されているイベント時間は、[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).
検証剤は、一意のランダムなノンセ（「1回使用される」）を生成し、agettersから1つ以上のPCRをリクエストします。相互運用性のために、これは「信頼できるプラットフォームモジュール（TPMS）を使用したチャレンジ応答ベースのリモートアテスト（CHARA）手順のYangデータモデル」[RFC9684]で指定されているように達成する必要があります。TPM 1.2とTPM 2.0の両方が、手術ダイジェストサイズと同じくらい大きいノンセスを許可します（つまり、20または32バイト。[TPM-1.2]パート2、セクション5.5、および[TPM-2.0]パート2、セクション10.4.4を参照）。
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の証拠を要求し、引用と呼ばれ、Devidに関連付けられたAKによって署名されます。引用符は、Charra Yangモデル[RFC9684]に従って取得されます。同時に、Attesterは、値がそのPCRに拡張されていることを示すログの証拠を収集します。付録A.1では、これがどのように機能するかについての詳細を示し、TPMドキュメントの引用符の構造と内容への参照を含んでいます。
Step 4:
ステップ4：
The collected Evidence is passed from the Attester to the 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は証拠を確認し、必要に応じて行動を起こします。頼る当事者と検証者の間の相互作用は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が検証者の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は、検証剤が信頼されていると仮定していますが、攻撃はそうではありません。信頼関係を交渉する2つのルーターなどのピアツーピアアプリケーションでは、2つのピアがそれぞれソフトウェアの完全性を証明するように依頼することができます。このアプリケーションでは、情報の流れは同じですが、それぞれの側は、攻撃者と検証剤の両方として役割を果たします。各デバイスは課題を発行し、図4に示すように、各デバイスは相手の課題に応答します。特にルーター間の信頼関係を確立するために使用される場合、ピアツーピアの課題は、独自の参照測定値を運ぶためにデバイスが必要です（RIMS）。また、デバイスは、各デバイスが中央当局に頼ることなく、リモートの証明に必要なものすべてを持つように、可能な各ピアデバイスの証拠について評価ポリシーを携帯する必要がある場合があります。
+---------------+ +---------------+
| 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.
このアプリケーションでは、各デバイスに登録者として機能し、各デバイスが検証剤として機能するようにするために署名されたリムを装備する必要がある場合があります。509ルート証明書も。802.1x [IEEE-802.1x]または802.1AE [IEEE-802.1AE]などの既存のリンクレイヤープロトコル。拡張可能な認証プロトコル（EAP）[RFC3748]またはリンクレイヤー発見プロトコル（LLDPP）のバリアントに証拠が囲まれています。）[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.
* ルーターの仲間の身元などのルーティング情報は、不正な隣人に漏れてはなりません。
* 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値など）を機器の管理者に識別する必要があるため、デバイスの機能に関する不確実性はありませんおよび構成。証明は、デバイス自体にアイデンティティを秘密にする権利がない場合でも、管理者がネットワークが個人およびピアプライバシーの保証を提供できるようにするコンポーネントです。
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:
2セットのキーペアは、RIVの証明に関連しています。
* 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と周囲のエコシステムは、PCRS、引用メカニズム、標準化されたイベントログからの証拠の安全な収集を可能にする3つのインターロック機能を提供します。
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つ以下のPCR（プロファイルとベンダーの選択肢によって異なります）があり、それぞれが1つのハッシュ値を保持するのに十分な大きさです（SHA-1、SHA-256、およびその他のハッシュアルゴリズムは使用できます。TPMバージョンで）。PCRSにチップの外側から直接アクセスすることはできませんが、TPMインターフェイスは、新しいセキュリティ測定ハッシュを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.
PCRSで記録された複合ハッシュオブハッシュは順序依存性であり、同じ一連のイベントの異なる順序付けに対して異なるPCR値をもたらすことに注意してください（たとえば、イベントAが続くイベントBは、Bとは異なる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は、PCRSの現在の値を読み取り、検証者の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.
検証器は、引用とログを一緒に使用します。引用には、TPMのプライベートAKが署名したセキュリティ測定ハッシュの完全なシーケンスの複合ハッシュが含まれています。ログには、TPMのPCRSに拡張された各測定の記録が含まれています。すべての測定値の複合ハッシュを計算することにより、イベントログ自体が署名されていない場合でも、検証者はイベントログの整合性を検証できます。検証されたイベントログの各ハッシュは、参照値のセットの対応する期待値と比較して、システム全体の整合性を検証できます。
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にあります。PCRSおよび引用データ構造の詳細情報は、[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 PCRS）の場合、結果を記録し、結果を報告する報告のための信頼の根が記録されます。
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