[要約] RFC 9334 - Remote ATtestation procedureS (RATS) Architecture は、デバイスやシステムの信頼性を遠隔で証明するための枠組みを定義しています。このアーキテクチャは、セキュリティの確保が必要なあらゆる環境での信頼性の検証を目的としています。利用場面としては、クラウドコンピューティング、IoTデバイス、サプライチェーンセキュリティなどがあります。
Internet Engineering Task Force (IETF) H. Birkholz
Request for Comments: 9334 Fraunhofer SIT
Category: Informational D. Thaler
ISSN: 2070-1721 Microsoft
M. Richardson
Sandelman Software Works
N. Smith
Intel
W. Pan
Huawei
January 2023
In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.
ネットワークプロトコルのやり取りでは、通信の一方の端が他方が意図した動作状態にあるかどうかを知ることがしばしば役立ちます。この文書は、生成、伝達、および証拠の主張を評価するプロセスを通じてこのようなテストを可能にする関連するエンティティのアーキテクチャの概要を提供します。プロセッサアーキテクチャ、主張の内容、およびプロトコルに中立的なモデルを提供します。
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.
この文書はInternet Engineering Task Force（IETF）の製品です。IETFコミュニティの合意を表しています。公開レビューを受け、Internet Engineering Steering Group（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/rfc9334.
この文書の現在の状況、誤り訂正、フィードバックの方法についての情報は、https://www.rfc-editor.org/info/rfc9334 で入手できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
2023年IETF Trustおよび文書の著者として特定された個人による著作権。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なBCP 78およびIETF文書に関連するIETF信託の法的規定（https://trustee.ietf.org/license-info）の対象となります。これらの文書を注意深く確認してください。これらは、この文書に関するあなたの権利と制限を説明しています。この文書から抽出されたコードコンポーネントには、信託法的規定のセクション4.eに記載されているように、修正されたBSDライセンステキストを含める必要があり、修正されたBSDライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Reference Use Cases
2.1. Network Endpoint Assessment
2.2. Confidential Machine Learning Model Protection
2.3. Confidential Data Protection
2.4. Critical Infrastructure Control
2.5. Trusted Execution Environment Provisioning
2.6. Hardware Watchdog
2.7. FIDO Biometric Authentication
3. Architectural Overview
3.1. Two Types of Environments of an Attester
3.2. Layered Attestation Environments
3.3. Composite Device
3.4. Implementation Considerations
4. Terminology
4.1. Roles
4.2. Artifacts
5. Topological Patterns
5.1. Passport Model
5.2. Background-Check Model
5.3. Combinations
6. Roles and Entities
7. Trust Model
7.1. Relying Party
7.2. Attester
7.3. Relying Party Owner
7.4. Verifier
7.5. Endorser, Reference Value Provider, and Verifier Owner
8. Conceptual Messages
8.1. Evidence
8.2. Endorsements
8.3. Reference Values
8.4. Attestation Results
8.5. Appraisal Policies
9. Claims Encoding Formats
10. Freshness
10.1. Explicit Timekeeping Using Synchronized Clocks
10.2. Implicit Timekeeping Using Nonces
10.3. Implicit Timekeeping Using Epoch IDs
10.4. Discussion
11. Privacy Considerations
12. Security Considerations
12.1. Attester and Attestation Key Protection
12.1.1. On-Device Attester and Key Protection
12.1.2. Attestation Key Provisioning Processes
12.2. Conceptual Message Protection
12.3. Attestation Based on Epoch ID
12.4. Trust Anchor Protection
13. IANA Considerations
14. References
14.1. Normative References
14.2. Informative References
Appendix A. Time Considerations
A.1. Example 1: Timestamp-Based Passport Model
A.2. Example 2: Nonce-Based Passport Model
A.3. Example 3: Passport Model Based on Epoch ID
A.4. Example 4: Timestamp-Based Background-Check Model
A.5. Example 5: Nonce-Based Background-Check Model
Acknowledgments
Contributors
Authors' Addresses
The question of how one system can know that another system can be trusted has found new interest and relevance in a world where trusted computing elements are maturing in processor architectures.
別のシステムが信頼できるかどうかを知る方法の問題は、信頼できるコンピューティング要素がプロセッサアーキテクチャで成熟している世界で、新たな関心と関連性を見出しています。
Systems that have been attested and verified to be in a good state (for some value of "good") can improve overall system posture. Conversely, systems that cannot be attested and verified to be in a good state can be given reduced access or privileges, taken out of service, or otherwise flagged for repair.
確認され、良好な状態であると証明されたシステムは、全体的なシステムの姿勢を向上させることができます。逆に、良好な状態であることが確認されず、検証されないシステムは、アクセス権限を削減されたり、サービスから外されたり、修理のためにフラグが立てられたりする可能性があります。
For example:
例えば：
* A bank backend system might refuse to transact with another system that is not known to be in a good state.
* 銀行のバックエンドシステムは、状態が良好であるとは知られていない他のシステムとの取引を拒否する可能性があります。
* A healthcare system might refuse to transmit electronic healthcare records to a system that is not known to be in a good state.
* 医療システムは、状態が良好であるとは知られていないシステムに電子医療記録を送信することを拒否する可能性があります。
In Remote ATtestation procedureS (RATS), one peer (the "Attester") produces believable information about itself ("Evidence") to enable a remote peer (the "Relying Party") to decide whether or not to consider that Attester a trustworthy peer. Remote attestation procedures are facilitated by an additional vital party (the "Verifier").
リモートアテステーション手順（RATS）では、1つのピア（「アテスター」）が自身に関する信頼性のある情報（「エビデンス」）を生成し、リモートピア（「信頼する側」）がそのアテスターを信頼できるピアとして考慮すべきかどうかを決定できるようにします。リモートアテステーション手順は、追加の重要なパーティ（「検証者」）によって支援されています。
The Verifier appraises Evidence via appraisal policies and creates the Attestation Results to support Relying Parties in their decision process. This document defines a flexible architecture consisting of attestation roles and their interactions via conceptual messages. Additionally, this document defines a universal set of terms that can be mapped to various existing and emerging remote attestation procedures. Common topological patterns and the sequence of data flows associated with them, such as the "Passport Model" and the "Background-Check Model", are illustrated. The purpose is to define useful terminology for remote attestation and enable readers to map their solution architecture to the canonical attestation architecture provided here. Having a common terminology that provides well-understood meanings for common themes, such as roles, device composition, topological patterns, and appraisal procedures, is vital for semantic interoperability across solutions and platforms involving multiple vendors and providers.
Verifierアプリは、査定方針を通じて証拠を査定し、信頼する当事者が意思決定プロセスをサポートするための証明結果を作成します。この文書は、概念メッセージを介した証明役割とその相互作用からなる柔軟なアーキテクチャを定義しています。さらに、この文書は、さまざまな既存および新興のリモート証明手続きにマッピングできる一般的な用語セットを定義しています。"パスポートモデル"や"バックグラウンドチェックモデル"など、それらに関連する一般的なトポロジパターンとデータフローのシーケンスが示されています。目的は、リモート証明のための有用な用語を定義し、読者がここで提供されている標準的な証明アーキテクチャに自分たちのソリューションアーキテクチャをマッピングできるようにすることです。一般的なテーマ（役割、デバイス構成、トポロジパターン、査定手続きなど）に対するよく理解された意味を提供する共通の用語は、複数のベンダーやプロバイダーが関与するソリューションやプラットフォーム間でのセマンティックな相互運用性にとって重要です。
Amongst other things, this document is about trust and trustworthiness. Trust is a choice one makes about another system. Trustworthiness is a quality about the other system that can be used in making one's decision to trust it or not. This is a subtle difference; being familiar with the difference is crucial for using this document. Additionally, the concepts of freshness and trust relationships are specified to enable implementers to choose appropriate solutions to compose their remote attestation procedures.
この文書は、他のことに加えて、信頼と信頼性についてです。信頼は他のシステムについての選択です。信頼性は他のシステムについての質であり、それを信頼するかどうかの判断に使うことができます。これは微妙な違いです。この文書を使用するためには、その違いを理解することが重要です。さらに、新鮮さと信頼関係の概念が明確にされており、実装者が適切な解決策を選択してリモートアテステーション手順を構成するための支援をしています。
This section covers a number of representative and generic use cases for remote attestation, independent of specific solutions. The purpose is to provide motivation for various aspects of the architecture presented in this document. Many other use cases exist; this document does not contain a complete list. It only illustrates a set of use cases that collectively cover all the functionality required in the architecture.
このセクションでは、特定の解決策に依存しないリモートアテステーションの代表的な利用事例や一般的な利用事例について説明します。目的は、この文書で提示されているアーキテクチャのさまざまな側面に対する動機付けを提供することです。他にも多くの利用事例が存在しますが、この文書には完全なリストは含まれていません。これは、アーキテクチャで必要とされるすべての機能を網羅する一連の利用事例を示すだけです。
Each use case includes a description followed by an additional summary of the Attester and Relying Party roles derived from the use case.
各ユースケースには、説明が含まれ、その後にユースケースから派生したアテスターとリリングパーティーの役割の追加サマリーが続きます。
Network operators want trustworthy reports that include identity and version information about the hardware and software on the machines attached to their network. Examples of reports include purposes (such as inventory summaries), audit results, and anomaly notifications (which typically include the maintenance of log records or trend reports). The network operator may also want a policy by which full access is only granted to devices that meet some definition of hygiene, and so wants to get Claims about such information and verify its validity. Remote attestation is desired to prevent vulnerable or compromised devices from getting access to the network and potentially harming others.
ネットワークオペレーターは、ネットワークに接続された機器のハードウェアおよびソフトウェアに関する身元情報やバージョン情報を含む信頼性のあるレポートを求めています。レポートの例には、目的（例：在庫の要約）、監査結果、および異常通知（通常はログレコードの保守やトレンドレポートを含む）があります。ネットワークオペレーターは、一定の衛生基準を満たすデバイスにのみ完全アクセスが許可される方針を望んでおり、そのためにそのような情報に関するクレームを取得し、その有効性を検証したいと考えています。脆弱なまたは侵害されたデバイスがネットワークにアクセスして他の人に損害を与えることを防ぐために、リモートアテステーションが望まれています。
Typically, a solution starts with a specific component (sometimes referred to as a "root of trust") that often provides a trustworthy device identity and performs a series of operations that enables trustworthiness appraisals for other components. Such components perform operations that help determine the trustworthiness of yet other components by collecting, protecting, or signing measurements. Measurements that have been signed by such components are comprised of Evidence that either supports or refutes a claim of trustworthiness when evaluated. Measurements can describe a variety of attributes of system components, such as hardware, firmware, BIOS, software, etc., and how they are hardened.
通常、ソリューションは特定のコンポーネント（時には「信頼のルート」と呼ばれることもある）から始まり、しばしば信頼できるデバイスのアイデンティティを提供し、他のコンポーネントの信頼性評価を可能にする一連の操作を実行します。このようなコンポーネントは、測定値を収集、保護、または署名することで、他のコンポーネントの信頼性を決定するのに役立つ操作を実行します。このようなコンポーネントによって署名された測定値は、評価されたときに信頼性の主張を支持または否定するエビデンスで構成されています。測定値は、ハードウェア、ファームウェア、BIOS、ソフトウェアなどのシステムコンポーネントのさまざまな属性や、それらがどのように強化されているかを記述することができます。
Attester:
Attester:
A device desiring access to a network.
ネットワークへのアクセスを希望するデバイス。
Relying Party:
Relying Party: 信頼する側
Network equipment (such as a router, switch, or access point) that is responsible for admission of the device into the network.
ネットワーク機器（ルーター、スイッチ、アクセスポイントなど）は、デバイスをネットワークに接続するための責任を持っています。
A device manufacturer wants to protect its intellectual property. The intellectual property's scope primarily encompasses the machine learning (ML) model that is deployed in the devices purchased by its customers. The protection goals include preventing attackers, potentially the customer themselves, from seeing the details of the model.
デバイスメーカーは知的財産を保護したいと考えています。知的財産の範囲は、主に顧客が購入したデバイスに展開されている機械学習（ML）モデルを含んでいます。保護の目標には、攻撃者、おそらくは顧客自身がモデルの詳細を見ることを防ぐことが含まれています。
Typically, this works by having some protected environment in the device go through a remote attestation with some manufacturer service that can assess its trustworthiness. If remote attestation succeeds, then the manufacturer service releases either the model or a key to decrypt a model already deployed on the Attester in encrypted form to the requester.
通常、これは、デバイス内の保護された環境が、その信頼性を評価できる製造業者サービスを介してリモートアテステーションを行うことによって機能します。リモートアテステーションが成功すると、製造業者サービスは、リクエスターに対して、すでに暗号化された形でアテスターに展開されているモデルまたはそのモデルを復号化するためのキーのいずれかをリリースします。
Attester:
Attester:
A device desiring to run an ML model.
MLモデルを実行したいデバイス。
Relying Party:
Relying Party:
A server or service holding ML models it desires to protect.
MLモデルを保護したいサーバーまたはサービス。
This is a generalization of the ML model use case above where the data can be any highly confidential data, such as health data about customers, payroll data about employees, future business plans, etc. As part of the attestation procedure, an assessment is made against a set of policies to evaluate the state of the system that is requesting the confidential data. Attestation is desired to prevent leaking data via compromised devices.
これは、データが顧客の健康データ、従業員の給与データ、将来の事業計画など、高度に機密性の高いデータである場合に適用されるMLモデルのユースケースの一般化です。証明手続きの一環として、機密データを要求しているシステムの状態を評価するために、一連のポリシーに対して評価が行われます。証明は、侵害されたデバイスを介してデータが漏洩するのを防ぐために望まれます。
Attester:
Attester:
An entity desiring to retrieve confidential data.
機密データを取得したいエンティティ。
Relying Party:
Relying Party: 信頼する側
An entity that holds confidential data for release to authorized entities.
機密データを保持し、権限を持つエンティティにリリースするもの。
Potentially harmful physical equipment (e.g., power grid, traffic control, hazardous chemical processing, etc.) is connected to a network in support of critical infrastructure. The organization managing such infrastructure needs to ensure that only authorized code and users can control corresponding critical processes, and that these processes are protected from unauthorized manipulation or other threats. When a protocol operation can affect a critical system component of the infrastructure, devices attached to that critical component require some assurances depending on the security context, including assurances that a requesting device or application has not been compromised and the requesters and actors act on applicable policies. As such, remote attestation can be used to only accept commands from requesters that are within policy.
重要なインフラをサポートするために、潜在的に有害な物理機器（例：電力網、交通制御、危険な化学処理など）がネットワークに接続されています。このようなインフラを管理する組織は、対応する重要なプロセスを制御できるのは認可されたコードとユーザーだけであり、これらのプロセスが不正な操作やその他の脅威から保護されていることを確認する必要があります。プロトコルの操作がインフラの重要なシステムコンポーネントに影響を与える場合、その重要なコンポーネントに接続されたデバイスは、セキュリティコンテキストに応じていくつかの保証が必要とされます。これには、要求元のデバイスやアプリケーションが侵害されていないこと、要求元やアクターが適用可能なポリシーに従って行動していることを確認する保証が含まれます。そのため、リモートアテステーションは、ポリシー内にある要求元からのコマンドのみを受け入れるために使用できます。
Attester:
Attester:
A device or application wishing to control physical equipment.
物理機器を制御したいデバイスやアプリケーション。
Relying Party:
Relying Party:
A device or application connected to potentially dangerous physical equipment (hazardous chemical processing, traffic control, power grid, etc.).
潜在的に危険な物理機器（危険な化学処理、交通制御、電力グリッドなど）に接続されたデバイスまたはアプリケーション。
A Trusted Application Manager (TAM) server is responsible for managing the applications running in a Trusted Execution Environment (TEE) of a client device, as described in [TEEP-ARCH]. To achieve its purpose, the TAM needs to assess the state of a TEE or applications in the TEE of a client device. The TEE conducts remote attestation procedures with the TAM, which can then decide whether the TEE is already in compliance with the TAM's latest policy. If not, the TAM has to uninstall, update, or install approved applications in the TEE to bring it back into compliance with the TAM's policy.
信頼できるアプリケーションマネージャ（TAM）サーバーは、クライアントデバイスの信頼実行環境（TEE）で実行されているアプリケーションを管理する責任があります。その目的を達成するために、TAMはクライアントデバイスのTEEまたはTEE内のアプリケーションの状態を評価する必要があります。TEEはTAMとリモートアテステーション手順を実行し、TAMの最新ポリシーに準拠しているかどうかを判断できます。準拠していない場合、TAMはTEE内の承認されたアプリケーションをアンインストール、更新、またはインストールして、TEEをTAMのポリシーに準拠させる必要があります。
Attester:
Attester:
A device with a TEE capable of running trusted applications that can be updated.
信頼できるアプリケーションを実行できるTEEを搭載したデバイスで、アップデート可能です。
Relying Party:
Relying Party:
A TAM.
A TAM.
There is a class of malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. This can be a significant problem because it allows a fleet of devices to be held hostage for ransom.
デバイスを人質に取り、再起動を防ぐマルウェアの一種が存在します。これにより、更新プログラムの適用が阻害される可能性があります。これは、複数のデバイスが身代金の支払いを求められる人質にされる可能性があるため、重大な問題となり得ます。
A solution to this problem is a watchdog timer implemented in a protected environment, such as a Trusted Platform Module (TPM), as described in Section 43.3 of [TCGarch]. If the watchdog does not receive regular and fresh Attestation Results regarding the system's health, then it forces a reboot.
この問題の解決策は、信頼されたプラットフォームモジュール（TPM）などの保護された環境に実装された監視タイマーです。[TCGarch]のセクション43.3で説明されています。監視タイマーがシステムの健康状態に関する定期的で新鮮なアテステーション結果を受信しない場合、再起動を強制します。
Attester:
Attester:
The device that should be protected from being held hostage for a long period of time.
長期間人質にされるべきでないデバイス。
Relying Party:
Relying Party:
A watchdog capable of triggering a procedure that resets a device into a known, good operational state.
既知の良好な動作状態にデバイスをリセットする手順をトリガーすることができる監視犬。
In the Fast IDentity Online (FIDO) protocol [WebAuthN] [CTAP], the device in the user's hand authenticates the human user, whether by biometrics (such as fingerprints) or by PIN and password. FIDO authentication puts a large amount of trust in the device compared to typical password authentication because it is the device that verifies the biometric, PIN, and password inputs from the user, not the server. For the Relying Party to know that the authentication is trustworthy, the Relying Party needs to know that the Authenticator part of the device is trustworthy. The FIDO protocol employs remote attestation for this.
Fast IDentity Online（FIDO）プロトコル[WebAuthN] [CTAP]では、ユーザーの手にあるデバイスが、生体認証（指紋など）またはPINとパスワードによって人間のユーザーを認証します。 FIDO認証は、通常のパスワード認証と比較して、デバイスに大きな信頼を置いています。なぜなら、ユーザーからの生体認証、PIN、およびパスワードの入力を検証するのはサーバーではなくデバイスだからです。信頼する側（Relying Party）が認証が信頼できるかどうかを知るためには、信頼する側がデバイスのAuthenticator部分が信頼できるかどうかを知る必要があります。FIDOプロトコルは、これに対してリモートアテステーションを使用しています。
The FIDO protocol supports several remote attestation protocols and a mechanism by which new ones can be registered and added; thus, remote attestation defined by the RATS architecture is a candidate for use in the FIDO protocol.
FIDOプロトコルは複数のリモートアテステーションプロトコルをサポートし、新しいプロトコルを登録および追加する仕組みを提供しています。したがって、RATSアーキテクチャで定義されたリモートアテステーションは、FIDOプロトコルで使用する候補となります。
Attester:
Attester:
FIDO Authenticator.
FIDO Authenticator.
Relying Party:
Relying Party: 信頼する側
Any website, mobile application backend, or service that relies on authentication data based on biometric information.
生体認証情報に基づく認証データに依存するウェブサイト、モバイルアプリケーションのバックエンド、またはサービス。
Figure 1 depicts the data that flows between different roles, independent of protocol or use case.
図1は、プロトコルやユースケースに依存せず、異なる役割間を流れるデータを示しています。
.--------. .---------. .--------. .-------------.
| Endorser | | Reference | | Verifier | | Relying Party |
'-+------' | Value | | Owner | | Owner |
| | Provider | '---+----' '----+--------'
| '-----+---' | |
| | | |
| Endorsements | Reference | Appraisal | Appraisal
| | Values | Policy for | Policy for
| | | Evidence | Attestation
'-----------. | | | Results
| | | |
v v v |
.-------------------------. |
.------>| Verifier +-----. |
| '-------------------------' | |
| | |
| Evidence Attestation | |
| Results | |
| | |
| v v
.-----+----. .---------------.
| Attester | | Relying Party |
'----------' '---------------'
Figure 1: Conceptual Data Flow
図1：概念データフロー
The text below summarizes the activities conducted by the roles illustrated in Figure 1. Roles are assigned to entities. Entities are often system components [RFC4949], such as devices. As the term "device" is typically more intuitive than the term "entity" or "system component", device is often used as an illustrative synonym throughout this document.
以下のテキストは、図1に示された役割が実施した活動を要約しています。役割はエンティティに割り当てられます。エンティティはしばしばシステムコンポーネント[RFC4949]のようなものです。"デバイス"という用語は通常、"エンティティ"や"システムコンポーネント"よりも直感的であるため、この文書全体で説明的な同義語としてよく使用されます。
The Attester role is assigned to entities that create Evidence that is conveyed to a Verifier.
Attesterの役割は、Verifierに伝えられるEvidenceを作成するエンティティに割り当てられます。
The Verifier role is assigned to entities that use the Evidence, any Reference Values from Reference Value Providers, and any Endorsements from Endorsers by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester. This procedure is called the "appraisal of Evidence".
検証者の役割は、証拠、参照値プロバイダーからの参照値、およびエンドーサーからの推薦を使用して、証人の信頼性を評価するために証拠の評価ポリシーを適用するエンティティに割り当てられます。この手続きは「証拠の評価」と呼ばれます。
Subsequently, the Verifier role generates Attestation Results for use by Relying Parties.
その後、検証者の役割は、依存する関係者が使用するための証明結果を生成します。
The Appraisal Policy for Evidence might be obtained from the Verifier Owner via some protocol mechanism, configured into the Verifier by the Verifier Owner, programmed into the Verifier, or obtained via some other mechanism.
証拠の評価ポリシーは、検証者所有者からいくつかのプロトコルメカニズムを介して取得される可能性があります。検証者によって構成され、検証者によってプログラムされるか、または他のメカニズムを介して取得されるかもしれません。
The Relying Party role is assigned to an entity that uses Attestation Results by applying its own appraisal policy to make application-specific decisions, such as authorization decisions. This procedure is called the "appraisal of Attestation Results".
Relying Partyの役割は、自身の評価ポリシーを適用してアプリケーション固有の決定（認可決定など）を行うエンティティに割り当てられます。この手順は「Attestation Resultsの評価」と呼ばれます。
The Appraisal Policy for Attestation Results might be obtained from the Relying Party Owner via some protocol mechanism, configured into the Relying Party by the Relying Party Owner, programmed into the Relying Party, or obtained via some other mechanism.
Attestation Resultsの評価ポリシーは、信頼するパーティーの所有者から、いくつかのプロトコルメカニズムを介して取得されるか、信頼するパーティーの所有者によって信頼するパーティーに構成され、信頼するパーティーにプログラムされるか、または他のメカニズムを介して取得される可能性があります。
See Section 8 for further discussion of the conceptual messages shown in Figure 1. Section 4 provides a more complete definition of all RATS roles.
図1に示されている概念メッセージの詳細な議論についてはセクション8を参照してください。セクション4では、すべてのRATSの役割のより完全な定義が提供されています。
As shown in Figure 2, an Attester consists of at least one Attesting Environment and at least one Target Environment co-located in one entity. In some implementations, the Attesting and Target Environments might be combined into one environment. Other implementations might have multiple Attesting and Target Environments, such as in the examples described in more detail in Sections 3.2 and 3.3. Other examples may exist. All compositions of Attesting and Target Environments discussed in this architecture can be combined into more complex implementations.
図2に示されているように、Attesterは少なくとも1つのAttesting Environmentと少なくとも1つのTarget Environmentから構成され、それらは同じエンティティ内に共存しています。一部の実装では、Attesting EnvironmentとTarget Environmentが1つの環境に統合されることがあります。他の実装では、複数のAttesting EnvironmentとTarget Environmentが存在することがあります。これについて詳しく説明されている例は、3.2節と3.3節で詳細に説明されています。他にも例が存在するかもしれません。このアーキテクチャで議論されているAttesting EnvironmentとTarget Environmentのすべての構成は、より複雑な実装に組み合わせることができます。
.--------------------------------.
| |
| Verifier |
| |
'--------------------------------'
^
|
.-------------------------|----------.
| | |
| .----------------. | |
| | Target | | |
| | Environment | | |
| | | | Evidence |
| '--------------+-' | |
| | | |
| | | |
| Collect | | |
| Claims | | |
| | | |
| v | |
| .-------+-----. |
| | Attesting | |
| | Environment | |
| | | |
| '-------------' |
| Attester |
'------------------------------------'
Figure 2: Two Types of Environments within an Attester
図2：アテスタ内の2種類の環境
Claims are collected from Target Environments. That is, Attesting Environments collect the values and the information to be represented in Claims by reading system registers and variables, calling into subsystems, and taking measurements on code, memory, or other relevant assets of the Target Environment. Attesting Environments then format the Claims appropriately; typically, they use key material and cryptographic functions, such as signing or cipher algorithms, to generate Evidence. There is no limit or requirement on the types of hardware or software environments that can be used to implement an Attesting Environment. For example, TEEs, embedded Secure Elements (eSEs), TPMs [TCGarch], or BIOS firmware.
主張はターゲット環境から収集されます。つまり、証明環境は、システムレジスタや変数を読み取り、サブシステムにアクセスし、コード、メモリ、または他の関連する資産の測定を行うことで、主張に表現される値と情報を収集します。証明環境は、その後、主張を適切にフォーマットします。通常、鍵素材や暗号関数（署名や暗号アルゴリズムなど）を使用して、証拠を生成します。証明環境を実装するために使用できるハードウェアやソフトウェア環境の種類には制限や要件はありません。たとえば、TEE、組み込みセキュアエレメント（eSE）、TPM（TCGarch）、またはBIOSファームウェアなどがあります。
An arbitrary execution environment may not, by default, be capable of Claims collection for a given Target Environment. Execution environments that are designed specifically to be capable of Claims collection are referred to in this document as "Attesting Environments". For example, a TPM doesn't actively collect Claims itself. Instead, it requires another component to feed various values to the TPM. Thus, an Attesting Environment in such a case would be the combination of the TPM together with whatever component is feeding it the measurements.
任意の実行環境は、デフォルトでは特定のターゲット環境のクレーム収集ができない場合があります。クレーム収集が可能に設計された実行環境は、この文書では「証明環境」と呼ばれます。例えば、TPMは自らクレームを収集することはありません。代わりに、さまざまな値をTPMに供給する別のコンポーネントが必要です。したがって、このような場合の証明環境は、TPMとそれに測定値を供給するコンポーネントの組み合わせとなります。
By definition, the Attester role generates Evidence. An Attester may consist of one or more nested environments (layers). The bottom layer of an Attester has an Attesting Environment that is typically designed to be immutable or difficult to modify by malicious code. In order to appraise Evidence generated by an Attester, the Verifier needs to trust various layers, including the bottom Attesting Environment. Trust in the Attester's layers, including the bottom layer, can be established in various ways, as discussed in Section 7.4.
定義によると、Attesterの役割はEvidenceを生成します。Attesterは1つ以上の入れ子になった環境（レイヤー）で構成されることがあります。Attesterの最下層には通常、不変または悪意のあるコードによる変更が困難なAttesting Environmentがあります。Attesterによって生成されたEvidenceを評価するためには、Verifierは最下層のAttesting Environmentを含むさまざまなレイヤーを信頼する必要があります。Attesterのレイヤー、最下層を含む信頼は、セクション7.4で議論されているように、さまざまな方法で確立できます。
In layered attestation, Claims can be collected from or about each layer beginning with an initial layer. The corresponding Claims can be structured in a nested fashion that reflects the nesting of the Attester's layers. Normally, Claims are not self-asserted. Rather, a previous layer acts as the Attesting Environment for the next layer. Claims about an initial layer are typically asserted by an Endorser.
階層化された証明では、最初の層から始まり、各層からまたは各層についてクレームを収集することができます。対応するクレームは、アテスターの層の入れ子構造を反映した形で構造化されることがあります。通常、クレームは自己主張されるものではありません。むしろ、前の層が次の層の証明環境として機能します。最初の層に関するクレームは通常、エンドーサーによって主張されます。
The example device illustrated in Figure 3 includes (A) a BIOS stored in read-only memory, (B) a bootloader, and (C) an operating system kernel.
図3に示されている例のデバイスには、(A) 読み取り専用メモリに格納されたBIOS、(B) ブートローダー、および(C) オペレーティングシステムカーネルが含まれています。
.-------------. Endorsement for ROM
| Endorser +-----------------------.
'-------------' |
v
.-------------. Reference .----------.
| Reference | Values for | |
| Value +----------------->| Verifier |
| Provider(s) | ROM, bootloader, | |
'-------------' and kernel '----------'
^
.------------------------------------. |
| | |
| .---------------------------. | |
| | Kernel(C) | | |
| | | | | Layered
| | Target | | | Evidence
| | Environment | | | for
| '---------------+-----------' | | bootloader
| Collect | | | and
| Claims | | | kernel
| .---------------|-----------. | |
| | Bootloader(B) v | | |
| | .-----------. | | |
| | Target | Attesting | | | |
| | Environment |Environment+-----------'
| | | | | |
| | '-----------' | |
| | ^ | |
| '--------------+--|---------' |
| Collect | | Evidence for |
| Claims v | bootloader |
| .-----------------+---------. |
| | ROM(A) | |
| | | |
| | Attesting | |
| | Environment | |
| '---------------------------' |
| |
'------------------------------------'
Figure 3: Layered Attester
図3: レイヤードアテスター
The first Attesting Environment (the ROM in this example) has to ensure the integrity of the bootloader (the first Target Environment). There are potentially multiple kernels to boot; the decision is up to the bootloader. Only a bootloader with intact integrity will make an appropriate decision. Therefore, the Claims relating to the integrity of the bootloader have to be measured securely. At this stage of the boot cycle of the device, the Claims collected typically cannot be composed into Evidence.
最初の検証環境（この例ではROM）は、ブートローダー（最初のターゲット環境）の整合性を確保しなければなりません。起動するカーネルは複数あり得ますが、その決定はブートローダーに委ねられます。整合性が保たれたブートローダーのみが適切な決定を下します。したがって、ブートローダーの整合性に関連するクレームは安全に測定されなければなりません。デバイスのブートサイクルのこの段階では、通常、収集されたクレームを証拠に組み立てることはできません。
After the boot sequence is started, the BIOS conducts the most important and defining feature of layered attestation: the successfully measured bootloader now becomes (or contains) an Attesting Environment for the next layer. This procedure in layered attestation is sometimes called "staging". It is important that the bootloader not be able to alter any Claims about itself that were collected by the BIOS. This can be ensured having those Claims be either signed by the BIOS or stored in a tamper-proof manner by the BIOS.
起動シーケンスが開始されると、BIOSはレイヤー認証の最も重要で特徴的な機能を実行します：正常に測定されたブートローダーは次のレイヤーの認証環境となります（または含まれます）。この手順はレイヤー認証では「ステージング」と呼ばれることがあります。ブートローダーがBIOSによって収集された自身に関するいかなるクレームも変更できないようにすることが重要です。これは、それらのクレームがBIOSによって署名されるか、BIOSによって改ざん防止された方法で保存されることによって確認できます。
Continuing with this example, the bootloader's Attesting Environment is now in charge of collecting Claims about the next Target Environment. In this example, it is the kernel to be booted. The final Evidence thus contains two sets of Claims: one set about the bootloader as measured and signed by the BIOS and another set of Claims about the kernel as measured and signed by the bootloader.
この例を続けると、ブートローダーの検証環境は次のターゲット環境に関するクレームを収集する責任を持つようになりました。この例では、起動するカーネルです。したがって、最終的なエビデンスには、BIOSによって測定および署名されたブートローダーに関する1つのセットのクレームと、ブートローダーによって測定および署名されたカーネルに関するもう1つのセットのクレームが含まれます。
This example could be extended further by making the kernel become another Attesting Environment for an application as another Target Environment. This would result in a third set of Claims in the Evidence pertaining to that application.
この例は、カーネルを別のAttesting Environmentとしてアプリケーションの別のTarget Environmentにすることでさらに拡張することができます。これにより、そのアプリケーションに関連する証拠の第三のセットが生じます。
The essence of this example is a cascade of staged environments. Each environment has the responsibility of measuring the next environment before the next environment is started. In general, the number of layers may vary by device or implementation, and an Attesting Environment might even have multiple Target Environments that it measures, rather than only one as shown by example in Figure 3.
この例の要点は、段階的な環境の連鎖です。各環境は、次の環境が開始される前に次の環境を測定する責任があります。一般的に、層の数はデバイスや実装によって異なる場合があり、図3の例に示されているように、検証環境は1つだけでなく複数のターゲット環境を測定することもあります。
A composite device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal of all these sub-entities.
複合デバイスは、その信頼性がすべてのサブエンティティの評価によって決定される複数のサブエンティティで構成されたエンティティです。
Each sub-entity has at least one Attesting Environment collecting the Claims from at least one Target Environment. Then, this sub-entity generates Evidence about its trustworthiness; therefore, each sub-entity can be called an "Attester". Among all the Attesters, there may be only some that have the ability to communicate with the Verifier while others do not.
各サブエンティティには、少なくとも1つのアテスティング環境があり、少なくとも1つのターゲット環境からクレームを収集しています。その後、このサブエンティティは信頼性に関する証拠を生成します。したがって、各サブエンティティは「アテスター」と呼ばれることができます。すべてのアテスターの中には、一部は検証者と通信する能力を持っているものもありますが、他のものは持っていないかもしれません。
For example, a carrier-grade router consists of a chassis and multiple slots. The trustworthiness of the router depends on all its slots' trustworthiness. Each slot has an Attesting Environment, such as a TEE, collecting the Claims of its boot process, after which it generates Evidence from the Claims.
例えば、キャリアグレードのルーターはシャーシと複数のスロットで構成されています。ルーターの信頼性は、すべてのスロットの信頼性に依存します。各スロットには、ブートプロセスのクレームを収集するAttesting Environment（TEEなど）があり、その後クレームからエビデンスを生成します。
Among these slots, only a "main" slot can communicate with the Verifier while other slots cannot. However, other slots can communicate with the main slot by the links between them inside the router. The main slot collects the Evidence of other slots, produces the final Evidence of the whole router, and conveys the final Evidence to the Verifier. Therefore, the router is a composite device, each slot is an Attester, and the main slot is the lead Attester.
これらのスロットの中で、唯一「メイン」スロットが検証者と通信できますが、他のスロットはできません。ただし、他のスロットは、ルーター内部のリンクを介してメインスロットと通信できます。メインスロットは他のスロットのエビデンスを収集し、全体のルーターの最終エビデンスを生成し、最終エビデンスを検証者に伝えます。したがって、ルーターは複合デバイスであり、各スロットはアテスターであり、メインスロットはリードアテスターです。
Another example is a multi-chassis router composed of multiple single carrier-grade routers. Multi-chassis router setups create redundancy groups that provide higher throughput by interconnecting multiple routers in these groups, which can be treated as one logical router for simpler management. A multi-chassis router setup provides a management point that connects to the Verifier. Typically, one router in the group is designated as the main router. Other routers in the multi-chassis setup are connected to the main router only via physical network links; therefore, they are managed and appraised via the main router's help. Consequently, a multi-chassis router setup is a composite device, each router is an Attester, and the main router is the lead Attester.
もう1つの例は、複数の単一のキャリアグレードルータで構成されたマルチシャーシルータです。マルチシャーシルータのセットアップは、冗長性グループを作成し、これらのグループ内の複数のルータを相互接続することにより、より高いスループットを提供します。これらのグループ内の複数のルータを1つの論理ルータとして扱い、より簡単な管理のために統合します。マルチシャーシルータのセットアップは、Verifierに接続する管理ポイントを提供します。通常、グループ内の1つのルータがメインルータとして指定されます。マルチシャーシのセットアップ内の他のルータは、物理ネットワークリンクを介してメインルータにのみ接続されるため、メインルータの支援を受けて管理および評価されます。したがって、マルチシャーシルータのセットアップは複合デバイスであり、各ルータがAttesterであり、メインルータがリードAttesterです。
Figure 4 depicts the conceptual data flow for a composite device.
図4は複合デバイスの概念データフローを示しています。
.-----------------------------.
| Verifier |
'-----------------------------'
^
|
| Evidence of
| Composite Device
|
.----------------------------------|-------------------------------.
| .--------------------------------|-----. .------------. |
| | Collect .---------+--. | | | |
| | Claims .--------->| Attesting |<--------+ Attester B +-. |
| | | |Environment | | '-+----------' | |
| | .--------+-------. | |<----------+ Attester C +-. |
| | | Target | | | | '-+----------' | |
| | | Environment(s) | | |<------------+ ... | |
| | | | '------------' | Evidence '------------' |
| | '----------------' | of |
| | | Attesters |
| | lead Attester A | (via Internal Links or |
| '--------------------------------------' Network Connections) |
| |
| Composite Device |
'------------------------------------------------------------------'
Figure 4: Composite Device
図4：複合デバイス
In a composite device, each Attester generates its own Evidence by its Attesting Environment(s) collecting the Claims from its Target Environment(s). The lead Attester collects Evidence from other Attesters and conveys it to a Verifier. Collection of Evidence from sub-entities may itself be a form of Claims collection that results in Evidence asserted by the lead Attester. The lead Attester generates Evidence about the layout of the whole composite device, while sub-Attesters generate Evidence about their respective (sub-)modules.
合成デバイスでは、各アテスターは、それぞれのアテスティング環境によってクレームを収集し、自身のエビデンスを生成します。主要なアテスターは他のアテスターからエビデンスを収集し、それを検証者に伝えます。サブエンティティからのエビデンスの収集自体が、主要なアテスターによって主張されるエビデンスの形態である可能性があります。主要なアテスターは合成デバイス全体のレイアウトに関するエビデンスを生成し、サブアテスターはそれぞれの（サブ）モジュールに関するエビデンスを生成します。
In this scenario, the trust model described in Section 7 can also be applied to an inside Verifier.
このシナリオでは、セクション7で説明されている信頼モデルは、内部検証者にも適用できます。
An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time. Multiple entities can cooperate to implement a single RATS role as well. In essence, the combination of roles and entities can be arbitrary. For example, in the composite device scenario, the entity inside the lead Attester can also take on the role of a Verifier and the outer entity of Verifier can take on the role of a Relying Party. After collecting the Evidence of other Attesters, this inside Verifier uses Endorsements and appraisal policies (obtained the same way as by any other Verifier) as part of the appraisal procedures that generate Attestation Results. The inside Verifier then conveys the Attestation Results of other Attesters to the outside Verifier, whether in the same conveyance protocol as part of the Evidence or not.
エンティティは複数のRATSロール（例：Attester、Verifier、Relying Partyなど）を同時に担うことができます。複数のエンティティが協力して単一のRATSロールを実装することもできます。要するに、ロールとエンティティの組み合わせは任意です。たとえば、複合デバイスシナリオでは、リードAttester内のエンティティはVerifierの役割も担い、外部のVerifierエンティティはRelying Partyの役割を担うこともできます。他のAttesterのエビデンスを収集した後、この内部Verifierは、評価手続きの一部としてAttestation Resultsを生成する際に、Endorsementsと評価ポリシー（他のVerifierと同様に取得される）を使用します。内部Verifierは、他のAttesterのAttestation Resultsを外部Verifierに伝達し、エビデンスの一部として同じ伝達プロトコルであるかどうかにかかわらず、伝達します。
As explained in Section 4, there are a variety of roles in the RATS architecture; they are defined by a unique combination of artifacts they produce and consume. Conversely, artifacts are also defined by the roles that produce or consume them. To produce an artifact means that a given role introduces it into the RATS architecture. To consume an artifact means that a given role has responsibility for processing it in the RATS architecture. Roles also have the ability to perform additional actions, such as caching or forwarding artifacts as opaque data. As depicted in Section 5, these additional actions can be performed by several roles.
セクション4で説明されているように、RATSアーキテクチャにはさまざまな役割があります。これらの役割は、それらが生産および消費するアーティファクトのユニークな組み合わせによって定義されます。逆に、アーティファクトもそれを生産または消費する役割によって定義されます。アーティファクトを生産するとは、特定の役割がそれをRATSアーキテクチャに導入することを意味します。アーティファクトを消費するとは、特定の役割がそれをRATSアーキテクチャで処理する責任があることを意味します。役割には、アーティファクトを不透明なデータとしてキャッシュしたり転送したりするなど、追加のアクションを実行する能力もあります。セクション5に示されているように、これらの追加のアクションは複数の役割によって実行できます。
[RFC4949] has defined a number of terms that are also used in this document. Some of the terms are close to, but not exactly the same. Where the terms are similar, they are noted below with references. As explained in Section 2.6 of [RFC4949], when this document says "Compare:", the terminology used in this document differs significantly from the definition in the reference.
[RFC4949] は、この文書でも使用されているいくつかの用語を定義しています。いくつかの用語は似ていますが、完全に同じではありません。用語が類似している場合、参照を付けて以下に記載されています。[RFC4949] のセクション 2.6 で説明されているように、この文書が「比較：」と述べるとき、この文書で使用されている用語は、参照の定義とは大きく異なります。
This document uses the terms in the subsections that follow.
この文書は、以下のサブセクションで用語を使用しています。
Attester:
Attester:
A role performed by an entity (typically a device) whose Evidence must be appraised in order to infer the extent to which the Attester is considered trustworthy, such as when deciding whether it is authorized to perform some operation.
エビデンスを評価する必要があるエンティティ（通常はデバイス）が行う役割で、アテスターが信頼できると見なされる程度を推測するために使用されるもの、たとえば、特定の操作を実行する権限があるかどうかを決定する際に。
Produces:
生産します。
Evidence
証拠
Relying Party:
Relying Party:
A role performed by an entity that depends on the validity of information about an Attester for purposes of reliably applying application-specific actions. Compare: relying party [RFC4949].
信頼性の高いアプリケーション固有のアクションを確実に適用するために、アテスターに関する情報の妥当性に依存するエンティティによって実行される役割。比較：信頼する側[RFC4949]。
Consumes:
消費します。
Attestation Results, Appraisal Policy for Attestation Results
証明結果、証明結果の評価ポリシー
Verifier:
検証者:
A role performed by an entity that appraises the validity of Evidence about an Attester and produces Attestation Results to be used by a Relying Party.
証明者に関する証拠の妥当性を評価し、信頼する側が使用する証明結果を生成するエンティティによって実行される役割。
Consumes:
消費します。
Evidence, Reference Values, Endorsements, Appraisal Policy for Evidence
証拠、参照値、推薦、証拠の評価方針
Produces:
生産します。
Attestation Results
証明結果
Relying Party Owner:
Relying Party Owner:信頼する側の所有者
A role performed by an entity (typically an administrator) that is authorized to configure an Appraisal Policy for Attestation Results in a Relying Party.
信頼する側で、アプリケーションの評価ポリシーを構成する権限を持つエンティティ（通常は管理者）が実行する役割。
Produces:
生産します。
Appraisal Policy for Attestation Results
証明結果の評価ポリシー
Verifier Owner:
所有者を確認する人:
A role performed by an entity (typically an administrator) that is authorized to configure an Appraisal Policy for Evidence in a Verifier.
検証者でエビデンスの評価ポリシーを構成する権限を持つエンティティ（通常は管理者）によって実行される役割。
Produces:
生産します。
Appraisal Policy for Evidence
証拠の評価ポリシー
Endorser:
エンドーサー:
A role performed by an entity (typically a manufacturer) whose Endorsements may help Verifiers appraise the authenticity of Evidence and infer further capabilities of the Attester.
エンティティ（通常は製造業者）が行う役割は、検証者が証拠の信頼性を評価し、アテスターのさらなる能力を推測するのに役立つ可能性があります。
Produces:
生産します。
Endorsements
推薦、支持、是認
Reference Value Provider:
参照値プロバイダー:
A role performed by an entity (typically a manufacturer) whose Reference Values help Verifiers appraise Evidence to determine if acceptable known Claims have been recorded by the Attester.
エンティティ（通常は製造業者）が行う役割で、その参照値が検証者が証拠を評価し、証明者が記録した許容される既知の主張がされているかを判断するのに役立ちます。
Produces:
生産します。
Reference Values
参考値
Claim:
主張:
A piece of asserted information, often in the form of a name/ value pair. Claims make up the usual structure of Evidence and other RATS conceptual messages. Compare: claim [RFC7519].
主張された情報の一部であり、しばしば名前/値のペアの形で表されます。クレームは、証拠や他のRATS概念メッセージの通常の構造を構成します。比較：claim [RFC7519]。
Endorsement:
推薦:
A secure statement that an Endorser vouches for the integrity of an Attester's various capabilities, such as Claims collection and Evidence signing.
エンドーサーがアテスターのさまざまな能力、例えばクレーム収集や証拠の署名などの完全性を保証する安全な声明。
Consumed By:
消費されたもの：
Verifier
Verifier
Produced By:
制作：
Endorser
エンドーサー
Evidence:
証拠:
A set of Claims generated by an Attester to be appraised by a Verifier. Evidence may include configuration data, measurements, telemetry, or inferences.
アサーターによって生成されたクレームのセットを検証者が評価する。証拠には構成データ、計測データ、テレメトリー、または推論が含まれる場合があります。
Consumed By:
Consumed By: 消費された：
Verifier
Verifier
Produced By:
制作：
Attester
Attester
Attestation Result:
証明結果:
The output generated by a Verifier, typically including information about an Attester, where the Verifier vouches for the validity of the results.
検証者によって生成される出力は、通常、アテスターに関する情報を含み、検証者が結果の妥当性を保証します。
Consumed By:
消費されたもの：
Relying Party
信頼する側
Produced By:
制作：
Verifier
Verifier
Appraisal Policy for Evidence:
証拠の評価ポリシー:
A set of rules that a Verifier uses to evaluate the validity of information about an Attester. Compare: security policy [RFC4949].
VerifierがAttesterに関する情報の妥当性を評価するために使用するルールのセット。比較：セキュリティポリシー[RFC4949]。
Consumed By:
消費されたもの：
Verifier
Verifier
Produced By:
制作：
Verifier Owner
所有者を確認する
Appraisal Policy for Attestation Results:
証明結果の評価ポリシー:
A set of rules that direct how a Relying Party uses the Attestation Results regarding an Attester generated by the Verifiers. Compare: security policy [RFC4949].
Relying PartyがVerifierによって生成されたAttesterに関するAttestation Resultsをどのように使用するかを指示する一連のルール。比較：security policy [RFC4949]。
Consumed by:
Consumed by: 消費された
Relying Party
Relying Party はそのままの表記です。
Produced by:
制作：
Relying Party Owner
Relying Party Owner
Reference Values:
参考値:
A set of values against which values of Claims can be compared as part of applying an Appraisal Policy for Evidence. Reference Values are sometimes referred to in other documents as "known-good values", "golden measurements", or "nominal values". These terms typically assume comparison for equality, whereas here, Reference Values might be more general and be used in any sort of comparison.
クレームの値を比較するための基準値は、証拠の評価ポリシーの一部として適用されます。基準値は、他の文書では「既知の正常値」、「基準測定値」、「名目値」として言及されることがあります。これらの用語は通常、等しいかどうかの比較を前提としていますが、ここでは、基準値はより一般的で、あらゆる種類の比較に使用される可能性があります。
Consumed By:
消費されたもの：
Verifier
Verifier
Produced By:
制作：
Reference Value Provider
参照値プロバイダー
Figure 1 shows a data flow diagram for communication between an Attester, a Verifier, and a Relying Party. The Attester conveys its Evidence to the Verifier for appraisal and the Relying Party receives the Attestation Result from the Verifier. This section refines the data-flow diagram by describing two reference models, as well as one example composition thereof. The discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented models.
図1は、アテスター、検証者、および信頼する側との間の通信のデータフロー図を示しています。アテスターは、その証拠を検証者に伝え、信頼する側は検証者からアテステーション結果を受け取ります。このセクションでは、2つの参照モデルとその1つの例の構成について説明して、データフロー図を詳細にします。以下の議論は説明目的のみであり、RATSの役割間の相互作用を提示されたモデルに制約するものではありません。
The Passport Model is so named because of its resemblance to how nations issue passports to their citizens. The nature of the Evidence that an individual needs to provide to its local authority is specific to the country involved. The citizen retains control of the resulting passport document and presents it to other entities when it needs to assert a citizenship or identity Claim, such as at an airport immigration desk. The passport is considered sufficient because it vouches for the citizenship and identity Claims and it is issued by a trusted authority.
パスポートモデルは、国が市民にパスポートを発行する方法に似ているためこの名前が付けられています。個人が地元の権限に提供する必要がある証拠の性質は、関係する国に特有です。市民は、結果として得られるパスポート文書をコントロールし、空港の入国審査所などで市民権や身元の主張を行う必要があるときに他の機関に提示します。パスポートは、市民権と身元の主張を保証し、信頼できる機関によって発行されているため、十分であると見なされます。
Thus, in this immigration desk analogy, the citizen is the Attester, the passport-issuing agency is a Verifier, and the passport application and identifying information (e.g., birth certificate) is the Evidence. The passport is an Attestation Result and the immigration desk is a Relying Party.
したがって、この入国審査のアナロジーでは、市民はAttester、パスポート発行機関はVerifier、パスポート申請と識別情報（たとえば、出生証明書）はEvidenceです。パスポートはAttestation Resultであり、入国審査デスクはRelying Partyです。
In this model, an Attester conveys Evidence to a Verifier that compares the Evidence against its appraisal policy. The Verifier then gives back an Attestation Result that the Attester treats as opaque data.
このモデルでは、AttesterがEvidenceをVerifierに伝え、VerifierがそのEvidenceを評価ポリシーと比較します。その後、VerifierはAttesterが不透明なデータとして扱うAttestation Resultを返します。
The Attester does not consume the Attestation Result, but it might cache it. The Attester can then present the Attestation Result (and possibly additional Claims) to a Relying Party, which then compares this information against its own appraisal policy. The Attester may also present the same Attestation Result to other Relying Parties.
アテスターはアテステーション結果を消費しませんが、キャッシュすることがあります。その後、アテスターはアテステーション結果（および追加のクレーム）を信頼する側に提示し、その情報を独自の評価ポリシーと比較します。アテスターは同じアテステーション結果を他の信頼する側にも提示することができます。
There are three ways in which the process may fail:
プロセスが失敗する可能性がある3つの方法があります。
* First, the Verifier may not issue a positive Attestation Result due to the Evidence not passing the Appraisal Policy for Evidence.
* 最初に、エビデンスがエビデンスの評価ポリシーを通過しないため、検証者は肯定的な証明結果を発行することができません。
* The second way in which the process may fail is when the Attestation Result is examined by the Relying Party, and based upon the Appraisal Policy for Attestation Results, the result does not comply with the policy.
* プロセスが失敗する可能性の2番目の方法は、信頼する側がアテステーション結果を検討し、アテステーション結果の評価ポリシーに基づいて、その結果がポリシーに準拠していない場合です。
* The third way is when the Verifier is unreachable or unavailable.
* 第3の方法は、検証者が到達不能または利用できない場合です。
As with any other information needed by the Relying Party to make an authorization decision, an Attestation Result can be carried in a resource access protocol between the Attester and Relying Party. In this model, the details of the resource access protocol constrain the serialization format of the Attestation Result. On the other hand, the format of the Evidence is only constrained by the Attester-Verifier remote attestation protocol. This implies that interoperability and standardization is more relevant for Attestation Results than it is for Evidence.
Attestation Result（証明結果）は、認証決定を行うためにリリング パーティが必要とする他の情報と同様に、アテスターとリリング パーティの間のリソースアクセスプロトコルで運び出すことができます。このモデルでは、リソースアクセスプロトコルの詳細が証明結果の直列化形式を制約します。一方、エビデンスの形式は、アテスター-バリデーターのリモートアテステーションプロトコルによってのみ制約されます。これは、相互運用性と標準化がエビデンスよりも証明結果にとってより関連性があることを意味します。
.------------.
| | Compare Evidence
| Verifier | against appraisal policy
| |
'--------+---'
^ |
Evidence | | Attestation
| | Result
| v
.---+--------. .-------------.
| +------------->| | Compare Attestation
| Attester | Attestation | Relying | Result against
| | Result | Party | appraisal policy
'------------' '-------------'
Figure 5: Passport Model
図5：パスポートモデル
The Background-Check Model is so named because of the resemblance of how employers and volunteer organizations perform background checks. When a prospective employee provides Claims about education or previous experience, the employer will contact the respective institutions or former employers to validate the Claim. Volunteer organizations often perform police background checks on volunteers in order to determine the volunteer's trustworthiness. Thus, in this analogy, a prospective volunteer is an Attester, the organization is the Relying Party, and the organization that issues a report is a Verifier.
バックグラウンドチェックモデルは、雇用主やボランティア団体がバックグラウンドチェックを行う方法に類似しているため、その名前が付けられています。見込みの従業員が学歴や以前の経験に関する主張を提供すると、雇用主はそれを検証するために関連する機関や以前の雇用主に連絡します。ボランティア団体は、ボランティアの信頼性を判断するためにしばしばボランティアに対して警察のバックグラウンドチェックを行います。したがって、この比喩では、見込みのボランティアはAttester、組織はRelying Party、報告書を発行する組織はVerifierとなります。
In this model, an Attester conveys Evidence to a Relying Party, which treats it as opaque and simply forwards it on to a Verifier. The Verifier compares the Evidence against its appraisal policy and returns an Attestation Result to the Relying Party. The Relying Party then compares the Attestation Result against its own appraisal policy.
このモデルでは、Attester が Evidence を Relying Party に伝え、Relying Party はそれを不透明なものとして扱い、単純に Verifier に転送します。Verifier は Evidence を自身の評価ポリシーと比較し、Attestation Result を Relying Party に返します。その後、Relying Party は Attestation Result を自身の評価ポリシーと比較します。
The resource access protocol between the Attester and Relying Party includes Evidence rather than an Attestation Result, but that Evidence is not processed by the Relying Party.
アテスターと信頼する側の間のリソースアクセスプロトコルには、アテステーション結果ではなくエビデンスが含まれていますが、そのエビデンスは信頼する側によって処理されません。
Since the Evidence is merely forwarded on to a trusted Verifier, any serialization format can be used for Evidence because the Relying Party does not need a parser for it. The only requirement is that the Evidence can be _encapsulated_ in the format required by the resource access protocol between the Attester and Relying Party.
証拠は単に信頼できる検証者に転送されるだけなので、証拠にはどのようなシリアル化形式でも使用できます。なぜなら、リライアンス・パーティーはそれに対するパーサーが必要ないからです。唯一の要件は、証拠がアテスターとリライアンス・パーティーの間のリソースアクセスプロトコルで必要とされる形式で_カプセル化_できることです。
However, as seen in the Passport Model, an Attestation Result is still consumed by the Relying Party. Code footprint and attack surface area can be minimized by using a serialization format for which the Relying Party already needs a parser to support the protocol between the Attester and Relying Party, which may be an existing standard or widely deployed resource access protocol. Such minimization is especially important if the Relying Party is a constrained node.
ただし、パスポートモデルで見られるように、証明結果は依存する側によって引き続き消費されます。コードのフットプリントと攻撃面積は、アテスターと依存する側の間のプロトコルをサポートするために既にパーサーが必要なシリアライゼーション形式を使用することで最小限に抑えることができます。このような最小化は、依存する側が制約のあるノードである場合に特に重要です。
.-------------.
| | Compare Evidence
| Verifier | against appraisal
| | policy
'--------+----'
^ |
Evidence | | Attestation
| | Result
| v
.------------. .----|--------.
| +-------------->|---' | Compare Attestation
| Attester | Evidence | Relying | Result against
| | | Party | appraisal policy
'------------' '-------------'
Figure 6: Background-Check Model
図6：バックグラウンドチェックモデル
One variation of the Background-Check Model is where the Relying Party and the Verifier are on the same machine, performing both functions together. In this case, there is no need for a protocol between the two.
バックグラウンドチェックモデルの1つのバリエーションは、依頼先と検証者が同じマシン上にあり、両方の機能を一緒に実行する場合です。この場合、2つの間にプロトコルは必要ありません。
It is also worth pointing out that the choice of model depends on the use case and that different Relying Parties may use different topological patterns.
このモデルの選択はユースケースに依存し、異なる信頼する側が異なるトポロジーパターンを使用する可能性があることも指摘する価値があります。
The same device may need to create Evidence for different Relying Parties and/or different use cases. For instance, it would use one model to provide Evidence to a network infrastructure device to gain access to the network and the other model to provide Evidence to a server holding confidential data to gain access to that data. As such, both models may simultaneously be in use by the same device.
同じデバイスは、異なる信頼する当事者や/または異なるユースケースのために証拠を作成する必要があるかもしれません。例えば、ネットワークインフラデバイスにアクセスするために証拠を提供するために1つのモデルを使用し、機密データにアクセスするためにそのデータにアクセスするために証拠を提供するために他のモデルを使用するかもしれません。そのため、同じデバイスで両方のモデルが同時に使用される可能性があります。
Figure 7 shows another example of a combination where Relying Party 1 uses the Passport Model, whereas Relying Party 2 uses an extension of the Background-Check Model. Specifically, in addition to the basic functionality shown in Figure 6, Relying Party 2 actually provides the Attestation Result back to the Attester, allowing the Attester to use it with other Relying Parties. This is the model that the TAM plans to support in the TEEP architecture [TEEP-ARCH].
図7は、Relying Party 1がパスポートモデルを使用し、一方でRelying Party 2がバックグラウンドチェックモデルの拡張を使用する別の組み合わせの例を示しています。具体的には、図6に示されている基本機能に加えて、Relying Party 2は実際にアテスターにアテステーション結果を提供し、アテスターが他のRelying Partyと使用できるようにします。これは、TAMがTEEPアーキテクチャ[TEEP-ARCH]でサポートする予定のモデルです。
.-------------.
| | Compare Evidence
| Verifier | against appraisal policy
| |
'--------+----'
^ |
Evidence | | Attestation
| | Result
| v
.----+--------.
| | Compare
| Relying | Attestation Result
| Party 2 | against appraisal policy
'--------+----'
^ |
Evidence | | Attestation
| | Result
| v
.----+--------. .-------------.
| +-------------->| | Compare Attestation
| Attester | Attestation | Relying | Result against
| | Result | Party 1 | appraisal policy
'-------------' '-------------'
Figure 7: Example Combination
図7: 例の組み合わせ
An entity in the RATS architecture includes at least one of the roles defined in this document.
RATSアーキテクチャ内のエンティティには、少なくともこの文書で定義された役割の1つが含まれています。
An entity can aggregate more than one role into itself, such as being both a Verifier and a Relying Party or being both a Reference Value Provider and an Endorser. As such, any conceptual messages (see Section 8 for more discussion) originating from such roles might also be combined. For example, Reference Values might be conveyed as part of an appraisal policy if the Verifier Owner and Reference Value Provider roles are combined. Similarly, Reference Values might be conveyed as part of an Endorsement if the Endorser and Reference Value Provider roles are combined.
エンティティは、VerifierとRelying Partyの両方であるか、Reference Value ProviderとEndorserの両方であるなど、複数の役割を自身に集約することができます。そのため、そのような役割から発信される概念メッセージ（詳細についてはセクション8を参照）も組み合わされる可能性があります。例えば、Verifier OwnerとReference Value Providerの役割が組み合わされている場合、Reference Valuesは査定ポリシーの一部として伝達されるかもしれません。同様に、EndorserとReference Value Providerの役割が組み合わされている場合、Reference ValuesはEndorsementの一部として伝達されるかもしれません。
Interactions between roles aggregated into the same entity do not necessarily use the Internet Protocol. Such interactions might use a loopback device or other IP-based communication between separate environments, but they do not have to. Alternative channels to convey conceptual messages include function calls, sockets, General-Purpose Input/Output (GPIO) interfaces, local buses, or hypervisor calls. This type of conveyance is typically found in composite devices. Most importantly, these conveyance methods are out of scope of the RATS architecture, but they are presumed to exist in order to convey conceptual messages appropriately between roles.
同じエンティティに集約された役割間の相互作用は、必ずしもインターネットプロトコルを使用するわけではありません。このような相互作用は、ループバックデバイスや他のIPベースの通信を使用する場合もありますが、必ずしもそうである必要はありません。概念メッセージを伝達するための代替チャネルには、関数呼び出し、ソケット、汎用入出力（GPIO）インタフェース、ローカルバス、またはハイパーバイザー呼び出しが含まれます。この種の伝達は通常、複合デバイスで見られます。最も重要なことは、これらの伝達方法がRATSアーキテクチャの対象外であるということですが、適切に概念メッセージを役割間で伝達するために存在すると推定されています。
In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this document.
基本的に、1つ以上の役割を組み合わせたエンティティは、この文書で定義された対応する概念メッセージを作成し、消費します。
This document covers scenarios for which a Relying Party trusts a Verifier that can appraise the trustworthiness of information about an Attester. Such trust is expressed by storing one or more "trust anchors" in a secure location known as a "trust anchor store".
この文書は、信頼するRelying Partyがアテスターに関する情報の信頼性を評価できるVerifierを信頼するシナリオについてカバーしています。この信頼は、「信頼アンカー」と呼ばれる1つ以上の情報を安全な場所で保存することによって表現されます。
As defined in [RFC6024]:
[RFC6024] で定義されています。
A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative.
信頼アンカーは、公開鍵と関連データを介して権威あるエンティティを表します。公開鍵はデジタル署名を検証するために使用され、関連データは信頼アンカーが権威を持つ情報の種類を制限するために使用されます。
The trust anchor may be a certificate or it may be a raw public key along with additional data if necessary, such as its public key algorithm and parameters. In the context of this document, a trust anchor may also be a symmetric key, as in [TCG-DICE-SIBDA], or the symmetric mode described in [RATS-PSA-TOKEN].
信頼アンカーは証明書であるか、必要に応じて追加データと共に生の公開鍵である場合があります。この文書の文脈では、信頼アンカーは[TCG-DICE-SIBDA]で説明されているような対称鍵、または[RATS-PSA-TOKEN]で説明されている対称モードである場合もあります。
Thus, trusting a Verifier might be expressed by having the Relying Party store the Verifier's key or certificate in its trust anchor store. It might also be expressed by storing the public key or certificate of an entity (e.g., a Certificate Authority) that is in the Verifier's certificate path. For example, the Relying Party can verify that the Verifier is an expected one by out-of-band establishment of key material combined with a protocol like TLS to communicate. There is an assumption that the Verifier has not been compromised between the establishment of the trusted key material and the creation of the Evidence.
したがって、Verifierへの信頼は、Relying PartyがVerifierの鍵や証明書をその信頼アンカーストアに保存することで表現される可能性があります。また、Verifierの証明書パスに含まれるエンティティ（たとえば、証明書機関）の公開鍵や証明書を保存することで表現されるかもしれません。例えば、Relying Partyは、鍵素材の帰り道の確立とTLSのようなプロトコルを組み合わせて通信することによって、Verifierが予想されるものであることを検証できます。信頼された鍵素材の確立と証拠の作成の間にVerifierが侵害されていないという前提があります。
For a stronger level of security, the Relying Party might require that the Verifier first provide information about itself that the Relying Party can use to assess the trustworthiness of the Verifier before accepting its Attestation Results. Such a process would provide a stronger level of confidence in the correctness of the information provided, such as a belief that the authentic Verifier has not been compromised by malware.
より強固なセキュリティレベルを確保するために、信頼する側は、検証者が自身に関する情報を最初に提供することを要求するかもしれません。これにより、信頼する側が検証者の信頼性を評価してアテステーション結果を受け入れる前に、より強固な信頼レベルが提供されます。このようなプロセスは、提供された情報の正確性に対する信頼度を高めることができ、例えば、本物の検証者がマルウェアによって侵害されていないという信念を提供します。
For example, one explicit way for a Relying Party "A" to establish such confidence in the correctness of a Verifier "B" would be for B to first act as an Attester where A acts as a combined Verifier/ Relying Party. If A then accepts B as trustworthy, it can choose to accept B as a Verifier for other Attesters.
例えば、信頼する側である「A」が検証者「B」の正確性に対する信頼を確立するための明示的な方法の1つは、Bが最初にアテスターとして行動し、Aが結合された検証者/信頼する側として行動することです。その後、AがBを信頼できると判断すれば、他のアテスターの検証者としてBを受け入れることができます。
Similarly, the Relying Party also needs to trust the Relying Party Owner for providing its Appraisal Policy for Attestation Results, and, in some scenarios, the Relying Party might even require that the Relying Party Owner go through a remote attestation procedure with it before the Relying Party will accept an updated policy. This can be done in a manner similar to how a Relying Party could establish trust in a Verifier as discussed above, i.e., verifying credentials against a trust anchor store and optionally requiring Attestation Results from the Relying Party Owner.
同様に、Relying Party（依頼元）は、アテステーション結果の評価ポリシーを提供するためにRelying Party Owner（依頼元所有者）を信頼する必要があり、一部のシナリオでは、Relying Partyが更新されたポリシーを受け入れる前に、Relying Party Ownerがリモートアテステーション手順を実行することを要求する場合もあります。これは、上記で議論されたように、Relying PartyがVerifier（検証者）に信頼を確立する方法と同様に行うことができます。つまり、信頼アンカーストアに対して資格情報を検証し、必要に応じてRelying Party Ownerからアテステーション結果を要求することができます。
In some scenarios, Evidence might contain sensitive information, such as Personally Identifiable Information (PII) or system identifiable information. Thus, an Attester must trust the entities to which it conveys Evidence to not reveal sensitive data to unauthorized parties. The Verifier might share this information with other authorized parties according to a governing policy that addresses the handling of sensitive information (potentially included in Appraisal Policies for Evidence). In the Background-Check Model, this Evidence may also be revealed to Relying Parties.
いくつかのシナリオでは、証拠には個人を特定できる情報（PII）やシステムを特定できる情報など、機密情報が含まれる可能性があります。したがって、証拠を伝達するエンティティに対して、アテスターは権限のない第三者に機密データを漏洩しないよう信頼する必要があります。検証者は、機密情報の取り扱いに関する規定が含まれる適用ポリシーに従って、他の権限を持つ者とこの情報を共有するかもしれません（証拠の評価ポリシーに含まれる可能性があります）。バックグラウンドチェックモデルでは、この証拠はリライアンスパーティーにも開示される可能性があります。
When Evidence contains sensitive information, an Attester typically requires that a Verifier authenticates itself (e.g., at TLS session establishment) and might even request a remote attestation before the Attester sends the sensitive Evidence. This can be done by having the Attester first act as a Verifier/Relying Party and the Verifier act as its own Attester, as discussed above.
証拠に機密情報が含まれている場合、通常、証明者は、検証者が自身を認証することを要求し（たとえば、TLSセッションの確立時）、機密の証拠を送信する前に遠隔証明を要求することがあります。これは、最初に証明者が検証者/依存する側として行動し、検証者が自身の証明者として行動することによって行うことができます。
The Relying Party Owner might also require that the Relying Party first act as an Attester by providing Evidence that the Owner can appraise before the Owner would give the Relying Party an updated policy that might contain sensitive information. In such a case, authentication or attestation in both directions might be needed. Typically, one side's Evidence must be considered safe to share with an untrusted entity in order to bootstrap the sequence. See Section 11 for more discussion.
Relying Party Owner は、Relying Party に更新されたポリシーを提供する前に、最初に Relying Party が Attester として行動することを要求する場合があります。この際、Owner が評価できる Evidence を提供する必要があります。その際、両方向での認証または証明が必要になるかもしれません。通常、一方の Evidence は、シーケンスをブートストラップするために信頼できないエンティティと共有しても安全であると考えられる必要があります。詳細な議論については、セクション11を参照してください。
The Verifier trusts (or more specifically, the Verifier's security policy is written in a way that configures the Verifier to trust) a manufacturer or the manufacturer's hardware so as to be able to appraise the trustworthiness of that manufacturer's devices. Such trust is expressed by storing one or more trust anchors in the Verifier's trust anchor store.
検証者は、製造業者または製造業者のハードウェアを信頼しており、その製造業者のデバイスの信頼性を評価できるようになっています。このような信頼は、検証者の信頼アンカー・ストアに1つ以上の信頼アンカーを保存することで表現されます。
In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for the Attester's ability to securely generate Evidence through Endorsements (see Section 8.2). Endorsements might describe the ways in which the Attester resists attacks, protects secrets, and measures Target Environments. Consequently, the Endorser's key material is stored in the Verifier's trust anchor store so that Endorsements can be authenticated and used in the Verifier's appraisal process.
典型的なソリューションでは、検証者は、エンドーサー（例：製造業者など）がアテスターがエンドースメント（セクション8.2を参照）を通じて安全に証拠を生成する能力を保証することによって、アテスターを間接的に信頼するようになります。 エンドースメントには、アテスターが攻撃に耐え、秘密を保護し、ターゲット環境を測定する方法が記載される場合があります。したがって、エンドーサーの鍵素材は、エンドーサーの信頼アンカーストアに保存され、エンドーサメントを認証し、検証者の評価プロセスで使用できるようになります。
In some solutions, a Verifier might be configured to directly trust an Attester by having the Verifier possess the Attester's key material (rather than the Endorser's) in its trust anchor store.
いくつかのソリューションでは、検証者が、エンドーサーのではなくアテスターのキーマテリアルを直接信頼するように構成されることがあります。
Such direct trust must first be established at the time of trust anchor store configuration either by checking with an Endorser at that time or by conducting a security analysis of the specific device. Having the Attester directly in the trust anchor store narrows the Verifier's trust to only specific devices rather than all devices the Endorser might vouch for, such as all devices manufactured by the same manufacturer in the case that the Endorser is a manufacturer.
そのような直接的な信頼は、信頼アンカーストアの構成時に最初に確立されなければならず、その際にエンドーサーと確認するか、特定のデバイスのセキュリティ分析を実施することによって行われます。アテスターを信頼アンカーストアに直接配置することで、検証者の信頼は、エンドーサーが保証する可能性のあるすべてのデバイスではなく、特定のデバイスに限定されます。例えば、エンドーサーが製造業者である場合、同じ製造業者によって製造されたすべてのデバイスなどです。
Such narrowing is often important since physical possession of a device can also be used to conduct a number of attacks, and so a device in a physically secure environment (such as one's own premises) may be considered trusted, whereas devices owned by others would not be. This often results in a desire either to have the owner run their own Endorser that would only endorse devices one owns or to use Attesters directly in the trust anchor store. When there are many Attesters owned, the use of an Endorser enables better scalability.
そのような狭めることはしばしば重要です。物理的なデバイスの所有権は、攻撃を行うためにも使用されることがあるため、物理的に安全な環境（自分の敷地など）にあるデバイスは信頼されると考えられるかもしれませんが、他人が所有するデバイスはそうではありません。これは、所有者が自分の所有するデバイスのみを承認するエンドーサーを実行することを望むことがしばしばあり、または信頼アンカーストアでアテスターを直接使用することもあります。多くの所有者がいる場合、エンドーサーの使用はスケーラビリティを向上させることができます。
That is, a Verifier might appraise the trustworthiness of an application component, operating system component, or service under the assumption that information provided about it by the lower-layer firmware or software is true. A stronger level of assurance of security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to hardware tampering. In most cases, components that have to be vouched for via Endorsements (because no Evidence is generated about them) are referred to as "roots of trust".
それは、検証者が、下位のファームウェアやソフトウェアによって提供された情報が真実であるという前提のもとで、アプリケーションコンポーネント、オペレーティングシステムコンポーネント、またはサービスの信頼性を評価する可能性があります。情報がハードウェアまたはROMコードによって保証される場合、特にそのようなハードウェアが物理的にハードウェアの改ざんに耐性がある場合、セキュリティの強い保証レベルが得られます。ほとんどの場合、エビデンスが生成されないためにエンドースメントを介して保証される必要があるコンポーネントは、「信頼のルート」と呼ばれます。
The manufacturer having arranged for an Attesting Environment to be provisioned with key material with which to sign Evidence, the Verifier is then provided with some way of verifying the signature on the Evidence. This may be in the form of an appropriate trust anchor or the Verifier may be provided with a database of public keys (rather than certificates) or even carefully curated and secured lists of symmetric keys.
製造業者が証拠を署名するための鍵素材を提供するための証明環境を整えた後、検証者には証拠の署名を検証する方法が提供されます。これは適切な信頼アンカーの形であるか、検証者には公開鍵のデータベース（証明書ではなく）や、慎重に選別され保護された対称鍵のリストが提供されるかもしれません。
The nature of how the Verifier manages to validate the signatures produced by the Attester is critical to the secure operation of a remote attestation system but is not the subject of standardization within this architecture.
VerifierがAttesterによって生成された署名を検証する方法の性質は、リモートアテステーションシステムの安全な運用にとって重要ですが、このアーキテクチャ内では標準化の対象とはなっていません。
A conveyance protocol that provides authentication and integrity protection can be used to convey Evidence that is otherwise unprotected (e.g., not signed). Appropriate conveyance of unprotected Evidence (e.g., [RATS-UCCS]) relies on the following conveyance protocol's protection capabilities:
認証と整合性保護を提供する伝達プロトコルを使用して、それ以外に保護されていない（例：署名されていない）エビデンスを伝達することができます。保護されていないエビデンス（例：[RATS-UCCS]）の適切な伝達は、次の伝達プロトコルの保護機能に依存します。
1. The key material used to authenticate and integrity protect the conveyance channel is trusted by the Verifier to speak for the Attesting Environment(s) that collected Claims about the Target Environment(s).
1. Verifierが信頼する認証および整合性保護のために使用される鍵素材は、対象環境に関するクレームを収集したAttesting Environmentを代表するものとして機能します。
2. All unprotected Evidence that is conveyed is supplied exclusively by the Attesting Environment that has the key material that protects the conveyance channel.
2. 提供されるすべての保護されていない証拠は、伝達される環境によってのみ提供され、伝達チャネルを保護するキー素材を持っています。
3. A trusted environment protects the conveyance channel's key material, which may depend on other Attesting Environments with equivalent strength protections.
3. 信頼できる環境は、他の同等の強度の保護を持つAttesting Environmentsに依存する可能性がある伝達チャネルの鍵素材を保護します。
As illustrated in [RATS-UCCS], an entity that receives unprotected Evidence via a trusted conveyance channel always takes on the responsibility of vouching for the Evidence's authenticity and freshness. If protected Evidence is generated, the Attester's Attesting Environments take on that responsibility. In cases where unprotected Evidence is processed by a Verifier, Relying Parties have to trust that the Verifier is capable of handling Evidence in a manner that preserves the Evidence's authenticity and freshness. Generating and conveying unprotected Evidence always creates significant risk and the benefits of that approach have to be carefully weighed against potential drawbacks.
[RATS-UCCS] に示されているように、信頼できる伝達チャネルを介して保護されていないエビデンスを受け取るエンティティは、常にエビデンスの信頼性と新鮮さを保証する責任を負います。保護されたエビデンスが生成された場合、アテスターのアテスティング環境がその責任を負います。保護されていないエビデンスが検証者によって処理される場合、依存する側は、検証者がエビデンスの信頼性と新鮮さを保持する方法でエビデンスを処理できると信頼しなければなりません。保護されていないエビデンスを生成および伝達することは常に重大なリスクを伴い、そのアプローチの利点は潜在的な欠点と慎重に比較検討する必要があります。
See Section 12 for discussion on security strength.
セキュリティ強度に関する議論については、セクション12を参照してください。
In some scenarios, the Endorser, Reference Value Provider, and Verifier Owner may need to trust the Verifier before giving the Endorsement, Reference Values, or appraisal policy to it. This can be done in a similar manner to how a Relying Party might establish trust in a Verifier.
いくつかのシナリオでは、エンドーサー、リファレンス値提供者、および検証者所有者は、エンドースメント、リファレンス値、または査定ポリシーを与える前に、検証者を信頼する必要があるかもしれません。これは、信頼する側が検証者に信頼を築く方法と同様の方法で行うことができます。
As discussed in Section 7.3, authentication or attestation in both directions might be needed. Typically, one side's identity or Evidence in this case must be considered safe to share with an untrusted entity in order to bootstrap the sequence. See Section 11 for more discussion.
セクション7.3で議論されたように、両方向での認証または証明が必要になる場合があります。通常、この場合、一方の身元または証拠が安全であると見なされ、信頼できないエンティティと共有する必要があります。詳細についてはセクション11を参照してください。
Figure 1 illustrates the flow of conceptual messages between various roles. This section provides additional elaboration and implementation considerations. It is the responsibility of protocol specifications to define the actual data format and semantics of any relevant conceptual messages.
図1は、さまざまな役割間での概念メッセージの流れを示しています。このセクションでは、追加の詳細と実装上の考慮事項を提供します。関連する概念メッセージの実際のデータ形式と意味論を定義するのはプロトコル仕様の責任です。
Evidence is a set of Claims about the Target Environment that reveal operational status, health, configuration, or construction that have security relevance. Evidence is appraised by a Verifier to establish its relevance, compliance, and timeliness. Claims need to be collected in a manner that is reliable such that a Target Environment cannot lie to the Attesting Environment about its trustworthiness properties. Evidence needs to be securely associated with the Target Environment so that the Verifier cannot be tricked into accepting Claims originating from a different environment (that may be more trustworthy). Evidence also must be protected from an active on-path attacker who may observe, change, or misdirect Evidence as it travels from the Attester to the Verifier. The timeliness of Evidence can be captured using Claims that pinpoint the time or interval when changes in operational status, health, and so forth occur.
証拠は、セキュリティに関連する運用状況、健康状態、構成、または構築を明らかにする対象環境に関する主張のセットです。証拠は、その関連性、遵守、およびタイムリネスを確立するために検証者によって評価されます。主張は、対象環境が信頼性の特性について証明環境に嘘をつけないように信頼性のある方法で収集する必要があります。証拠は、検証者が異なる環境（より信頼性の高い可能性がある）から発信された主張を受け入れるようにだまされないように、対象環境と安全に関連付けられる必要があります。また、証拠は、証明者から検証者に移動する際に観察、変更、または誤誘導される可能性のあるアクティブな経路上の攻撃者から保護されなければなりません。証拠のタイムリネスは、運用状況、健康状態の変化などが発生する時間または間隔を特定する主張を使用して捉えることができます。
An Endorsement is a secure statement that some entity (e.g., a manufacturer) vouches for the integrity of the device's various capabilities, such as Claims collection, signing, launching code, transitioning to other environments, storing secrets, and more. For example, if the device's signing capability is in hardware, then an Endorsement might be a manufacturer certificate that signs a public key whose corresponding private key is only known inside the device's hardware. Thus, when Evidence and such an Endorsement are used together, an appraisal procedure can be conducted based on appraisal policies that may not be specific to the device instance but are merely specific to the manufacturer providing the Endorsement. For example, an appraisal policy might simply check that devices from a given manufacturer have information matching a set of Reference Values. An appraisal policy might also have a set of more complex logic on how to appraise the validity of information.
エンドースメントは、あるエンティティ（例：製造業者）が、デバイスのさまざまな機能（クレームの収集、署名、コードの起動、他の環境への移行、秘密の保存など）の信頼性を保証する安全な声明です。たとえば、デバイスの署名機能がハードウェアにある場合、エンドースメントは、デバイスのハードウェア内でのみ知られている対応する秘密鍵を持つ公開鍵に署名する製造業者証明書である可能性があります。したがって、エビデンスとそのようなエンドースメントを併用すると、デバイスのインスタンスに特有ではなく、単にエンドースメントを提供する製造業者に特有な評価ポリシーに基づいた査定手続きを行うことができます。たとえば、査定ポリシーは、特定の製造業者からのデバイスが一連の参照値に一致する情報を持っているかどうかを単にチェックする場合があります。査定ポリシーには、情報の有効性を査定する複雑なロジックのセットも含まれる場合があります。
However, while an appraisal policy that treats all devices from a given manufacturer the same may be appropriate for some use cases, it would be inappropriate to use such an appraisal policy as the sole means of authorization for use cases that wish to constrain _which_ compliant devices are considered authorized for some purpose. For example, an enterprise using remote attestation for Network Endpoint Assessment (NEA) [RFC5209] may not wish to let every healthy laptop from the same manufacturer onto the network. Instead, it may only want to let devices that it legally owns onto the network. Thus, an Endorsement may be helpful information in authenticating information about a device, but is not necessarily sufficient to authorize access to resources that may need device-specific information, such as a public key for the device or component or user on the device.
ただし、特定の製造業者からのすべてのデバイスを同じように扱う査定ポリシーは、一部のユースケースに適しているかもしれませんが、どの準拠デバイスがある目的のために認可されたと見なされるかを制限したいユースケースにおいて、そのような査定ポリシーを認可の唯一の手段として使用することは適切ではありません。たとえば、ネットワークエンドポイントアセスメント（NEA）[RFC5209]のリモートアテステーションを使用している企業は、同じ製造業者のすべての健全なノートパソコンをネットワークに接続させたくないかもしれません。代わりに、法的に所有しているデバイスのみをネットワークに接続させたいかもしれません。したがって、エンドースメントはデバイスに関する情報の認証に役立つ情報であるかもしれませんが、デバイス固有の情報が必要なリソースへのアクセスを認可するのに十分ではない場合があります。例えば、デバイスまたはコンポーネントの公開鍵、またはデバイス上のユーザーのようなデバイス固有の情報が必要なリソース。
Reference Values used in appraisal procedures come from a Reference Value Provider and are then used by the Verifier to compare to Evidence. Reference Values with matching Evidence produce acceptable Claims. Additionally, an appraisal policy may play a role in determining the acceptance of Claims.
鑑定手続きで使用される基準値は基準値プロバイダーから提供され、その後検証者が証拠と比較するために使用されます。一致する証拠を持つ基準値は許容可能な主張を生み出します。さらに、鑑定方針は主張の受け入れを決定する際に役割を果たす可能性があります。
Attestation Results are the input used by the Relying Party to decide the extent to which it will trust a particular Attester and allow it to access some data or perform some operation.
Attestation Resultsは、信頼する特定のAttesterとそのデータにアクセスしたり操作を行ったりする範囲を決定するためにリリングパーティが使用する入力です。
Attestation Results may carry a boolean value indicating compliance or non-compliance with a Verifier's appraisal policy or may carry a richer set of Claims about the Attester, against which the Relying Party applies its Appraisal Policy for Attestation Results.
アテステーション結果は、検証者の査定ポリシーに準拠しているかどうかを示す真偽値を持つことがあり、また、アテスターに関するより豊富なクレームを持つことがあります。これに対して、信頼する側はアテステーション結果に対して自身の査定ポリシーを適用します。
The quality of the Attestation Results depends upon the ability of the Verifier to evaluate the Attester. Different Attesters have a different _Strength of Function_ [strengthoffunction], which results in the Attestation Results being qualitatively different in strength.
Attestation Resultsの品質は、検証者がアテスターを評価する能力に依存します。異なるアテスターは異なる「機能の強さ」を持っており、これがAttestation Resultsの品質が異なる強度である理由です。
An Attestation Result that indicates non-compliance can be used by an Attester (in the Passport Model) or a Relying Party (in the Background-Check Model) to indicate that the Attester should not be treated as authorized and may be in need of remediation. In some cases, it may even indicate that the Evidence itself cannot be authenticated as being correct.
「遵守していないことを示す証明結果」は、パスポートモデルのアテスターまたはバックグラウンドチェックモデルの信頼する側が使用して、アテスターを権限を持つと見なすべきでないことを示し、改善が必要かもしれないことを示すことができます。場合によっては、証拠自体が正しいと認証されない可能性さえあります。
By default, the Relying Party does not believe the Attester to be compliant. Upon receipt of an authentic Attestation Result and given the Appraisal Policy for Attestation Results is satisfied, the Attester is allowed to perform the prescribed actions or access. The simplest such appraisal policy might authorize granting the Attester full access or control over the resources guarded by the Relying Party. A more complex appraisal policy might involve using the information provided in the Attestation Result to compare against expected values or to apply complex analysis of other information contained in the Attestation Result.
デフォルトでは、Relying Party（信頼側）はAttester（検証者）が適合しているとは信じていません。正当なAttestation Result（検証結果）を受け取り、Attestation ResultsのAppraisal Policy（査定方針）が満たされた場合、Attesterは指定されたアクションを実行したり、アクセスしたりすることが許可されます。最も単純な査定方針では、AttesterにRelying Partyが保護するリソースに対する完全なアクセス権限や制御権限を付与することを認可するかもしれません。より複雑な査定方針では、Attestation Resultで提供された情報を期待値と比較したり、Attestation Resultに含まれる他の情報を複雑な分析に適用したりすることが含まれるかもしれません。
Thus, Attestation Results can contain detailed information about an Attester, which can include privacy sensitive information as discussed in Section 11. Unlike Evidence, which is often very device- and vendor-specific, Attestation Results can be vendor-neutral, if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence. This allows a Relying Party's appraisal policy to be simpler, potentially based on standard ways of expressing the information, while still allowing interoperability with heterogeneous devices.
したがって、Attestation Resultsには、Attesterに関する詳細な情報が含まれることがあります。これには、第11節で議論されているプライバシーに関連する情報が含まれる場合があります。証拠とは異なり、通常はデバイスやベンダー固有の情報であるAttestation Resultsは、Evidenceのベンダー中立性を持つことができます。これは、VerifierがEvidenceのベンダー固有情報の評価に基づいてベンダーに中立的な情報を生成する方法を持っている場合です。これにより、Relying Partyの評価ポリシーをよりシンプルにすることができ、情報を表現する標準的な方法に基づいている可能性がありますが、異種のデバイスとの相互運用性を可能にすることができます。
Finally, whereas Evidence is signed by the device (or indirectly by a manufacturer if Endorsements are used), Attestation Results are signed by a Verifier, allowing a Relying Party to only need a trust relationship with one entity rather than a larger set of entities for purposes of its appraisal policy.
最終的に、証拠はデバイスによって署名されます（または承認が使用されている場合は製造業者によって間接的に署名されます）。一方、証明結果は検証者によって署名され、信頼する側は評価ポリシーの目的のために複数のエンティティとの信頼関係を必要とせず、1つのエンティティとの信頼関係だけで済むようになります。
The Verifier (when appraising Evidence) or the Relying Party (when appraising Attestation Results) checks the values of matched Claims against constraints specified in its appraisal policy. Examples of such constraints checking include the following:
検証者（証拠を査定する場合）または依頼元（アテステーション結果を査定する場合）は、その査定ポリシーで指定された制約に一致するクレームの値をチェックします。このような制約のチェックの例には、次のものがあります。
* Comparison for equality against a Reference Value.
* 参照値との等価性の比較。
* A check for being in a range bounded by Reference Values.
* 基準値によって制限された範囲内にあるかどうかのチェック。
* Membership in a set of Reference Values.
* 参照値のセットへのメンバーシップ。
* A check against values in other Claims.
* 他のクレームの値と照合する。
Upon completing all appraisal policy constraints, the remaining Claims are accepted as input toward determining Attestation Results (when appraising Evidence) or as input to a Relying Party (when appraising Attestation Results).
すべての査定方針の制約を完了した後、残りのクレームは、証拠を査定する際の証明結果を決定するための入力として受け入れられるか、証明結果を査定する際の依存する側の入力として受け入れられます。
Figure 8 illustrates a relationship to which remote attestation is desired to be added:
図8は、リモートアテステーションを追加したい関係を示しています。
.-------------. .------------. Evaluate
| +-------------->| | request
| Attester | Access some | Relying | against
| | resource | Party | security
'-------------' '------------' policy
Figure 8: Typical Resource Access
図8：典型的なリソースアクセス
In this diagram, the protocol between the Attester and a Relying Party can be any new or existing protocol (e.g., HTTP(S), CoAP(S), Resource-Oriented Lightweight Information Exchange (ROLIE) [RFC8322], 802.1x, OPC UA [OPCUA], etc.) depending on the use case.
この図では、AttesterとRelying Partyの間のプロトコルは、使用ケースに応じて任意の新しいまたは既存のプロトコル（例：HTTP(S)、CoAP(S)、Resource-Oriented Lightweight Information Exchange（ROLIE）[RFC8322]、802.1x、OPC UA [OPCUA]など）である可能性があります。
Typically, such protocols already have mechanisms for passing security information for authentication and authorization purposes. Common formats include JSON Web Tokens (JWTs) [RFC7519], CWTs [RFC8392], and X.509 certificates.
通常、そのようなプロトコルには、認証および認可の目的でセキュリティ情報を渡すためのメカニズムがすでに備わっています。一般的なフォーマットには、JSON Web Tokens（JWT）[RFC7519]、CWT（RFC8392）、およびX.509証明書が含まれます。
Retrofitting already-deployed protocols with remote attestation requires adding RATS conceptual messages to the existing data flows. This must be done in a way that does not degrade the security properties of the systems involved and should use extension mechanisms provided by the underlying protocol. For example, if a TLS handshake is to be extended with remote attestation capabilities, attestation Evidence may be embedded in an ad hoc X.509 certificate extension (e.g., [TCG-DICE]) or into a new TLS Certificate Type (e.g., [TLS-CWT]).
既に展開されているプロトコルにリモートアテステーションを追加するには、既存のデータフローに RATS コンセプチュアル メッセージを追加する必要があります。これは、関連するシステムのセキュリティ特性を低下させないように行われるべきであり、基礎となるプロトコルが提供する拡張メカニズムを使用する必要があります。たとえば、TLS ハンドシェイクにリモートアテステーション機能を追加する場合、アテステーションエビデンスは、アドホックな X.509 証明書拡張（例：[TCG-DICE]）または新しい TLS 証明書タイプ（例：[TLS-CWT]）に埋め込むことができます。
Especially for constrained nodes, there is a desire to minimize the amount of parsing code needed in a Relying Party in order to both minimize footprint and the attack surface. While it would be possible to embed a CWT inside a JWT, or a JWT inside an X.509 extension, etc., there is a desire to encode the information in a format that is already supported by the Relying Party.
特に制約のあるノードについては、リライアンスパーティーで必要な解析コードの量を最小限に抑えることが望まれています。これにより、フットプリントを最小限に抑え、攻撃面を減らすことができます。CWTをJWTの中に埋め込む、またはJWTをX.509拡張の中に埋め込むなどが可能であるかもしれませんが、既にリライアンスパーティーでサポートされている形式で情報をエンコードすることが望まれています。
This motivates having a common "information model" that describes the set of remote attestation related information in an encoding-agnostic way and allows multiple encoding formats (CWT, JWT, X.509, etc.) that encode the same information into the Claims format needed by the Relying Party.
これは、リモートアテステーションに関連する情報のセットをエンコーディングに依存しない方法で記述し、同じ情報をリレーパーティが必要とするクレーム形式にエンコードする複数のエンコーディング形式（CWT、JWT、X.509など）を許可する共通の「情報モデル」を持つことを促進します。
Figure 9 illustrates that Evidence and Attestation Results might be expressed via multiple potential encoding formats so that they can be conveyed by various existing protocols. It also motivates why the Verifier might also be responsible for accepting Evidence that encodes Claims in one format while issuing Attestation Results that encode Claims in a different format.
図9は、証拠と証明結果が複数の潜在的なエンコーディング形式を介して表現される可能性があるため、さまざまな既存のプロトコルで伝達されることができることを示しています。また、検証者が、クレームを1つの形式でエンコードする証拠を受け入れる責任がある一方で、証明結果を異なる形式でエンコードすることを発行する理由も示しています。
Evidence Attestation Results
.--------------. CWT CWT .-------------------.
| Attester-A +-----------. .---------->| Relying Party V |
'--------------' | | `-------------------'
v |
.--------------. JWT .---------+--. JWT .-------------------.
| Attester-B +-------->| +-------->| Relying Party W |
'--------------' | | `-------------------'
| |
.--------------. X.509 | | X.509 .-------------------.
| Attester-C +-------->| Verifier +-------->| Relying Party X |
'--------------' | | `-------------------'
| |
.--------------. TPM | | TPM .-------------------.
| Attester-D +-------->| +-------->| Relying Party Y |
'--------------' '---------+--' `-------------------'
^ |
.--------------. other | | other .-------------------.
| Attester-E +-----------' '---------->| Relying Party Z |
'--------------' `-------------------'
Figure 9: Multiple Attesters and Relying Parties with Different Formats
図9: 異なる形式の複数の証明者と依存する当事者
A Verifier or Relying Party might need to learn the point in time (i.e., the "epoch") an Evidence or Attestation Result has been produced. This is essential in deciding whether the included Claims can be considered fresh, meaning they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence, Endorsements, and Reference Values.
検証者または依頼先は、証拠または証明結果が生成された時点（つまり、「エポック」）を知る必要がある場合があります。これは、含まれているクレームが新鮮であると見なすことができるかどうかを決定する上で重要です。つまり、それらが依頼者の最新の状態をまだ反映していること、および証明結果が証拠、承認、および参照値の最新の評価ポリシーを使用して生成されたことを意味します。
This section provides a number of details. However, it does not define any protocol formats and the interactions shown are abstract. This section is intended for those creating protocols and solutions to understand the options available to ensure freshness. The way in which freshness is provisioned in a protocol is an architectural decision. Provisioning of freshness has an impact on the number of needed round trips in a protocol; therefore, it must be made very early in the design. Different decisions will have significant impacts on resulting interoperability, which is why this section goes into sufficient detail such that choices in freshness will be compatible across interacting protocols, such as depicted in Figure 9.
このセクションは多くの詳細を提供しています。ただし、プロトコル形式を定義しておらず、示されている相互作用は抽象的です。このセクションは、プロトコルとソリューションを作成する人が、新鮮さを確保するためのオプションを理解することを意図しています。プロトコルで新鮮さを提供する方法は、アーキテクチャ上の決定です。新鮮さの提供はプロトコル内で必要なラウンドトリップ数に影響を与えるため、設計段階で非常に早く行う必要があります。異なる決定は相互運用性に重大な影響を与えるため、このセクションでは、新鮮さの選択肢が図9に示されているように相互作用するプロトコル全体で互換性があるように十分な詳細を提供しています。
Freshness is assessed based on the Appraisal Policy for Evidence or Attestation Results that compares the estimated epoch against an "expiry" threshold defined locally to that policy. There is, however, always a race condition possible in that the state of the Attester and the appraisal policies might change immediately after the Evidence or Attestation Result was generated. The goal is merely to narrow their recentness to something the Verifier (for Evidence) or Relying Party (for Attestation Result) is willing to accept. Some flexibility on the freshness requirement is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices).
新鮮さは、推定されたエポックを「有効期限」として定義された閾値と比較する証拠または証明結果の評価ポリシーに基づいて評価されます。ただし、証拠または証明結果が生成された直後にアテスターの状態や評価ポリシーが変化する可能性が常にあります。目標は、証明書の検証者（証拠の場合）または依存する側（証明結果の場合）が受け入れる意志のあるものに最近のものを絞り込むことです。新鮮さの要件に対する柔軟性は、証拠と証明結果の両方のキャッシュ化と再利用を可能にするための重要な要素であり、特にその計算がリソース予算のかなりの部分（例：制約されたデバイスのエネルギー）を使用する場合に特に価値があります。
There are three common approaches for determining the epoch of Evidence or an Attestation Result.
証拠または証明結果のエポックを決定するための一般的なアプローチは3つあります。
The first approach is to rely on synchronized and trustworthy clocks and include a signed timestamp (see [RATS-TUDA]) along with the Claims in the Evidence or Attestation Result. Timestamps can also be added on a per-Claim basis to distinguish the time of generation of Evidence or Attestation Result from the time that a specific Claim was generated. The clock's trustworthiness can generally be established via Endorsements and typically requires additional Claims about the signer's time synchronization mechanism.
最初のアプローチは、同期された信頼性のあるクロックに依存し、証拠または証明結果のクレームと一緒に署名付きのタイムスタンプを含めることです。タイムスタンプは、証拠または証明結果の生成時刻と特定のクレームが生成された時刻を区別するために、クレームごとに追加することもできます。クロックの信頼性は一般的にエンドースメントを通じて確立され、通常、署名者の時刻同期メカニズムに関する追加のクレームが必要です。
However, a trustworthy clock might not be available in some use cases. For example, in many TEEs today, a clock is only available outside the TEE; thus, it cannot be trusted by the TEE.
ただし、信頼できるクロックは一部のユースケースで利用できない場合があります。例えば、現在の多くのTEEでは、クロックがTEEの外部でのみ利用可能であり、そのためTEEによって信頼されることはできません。
A second approach places the onus of timekeeping solely on the Verifier (for Evidence) or the Relying Party (for Attestation Results). For example, this approach might be suitable in case the Attester does not have a trustworthy clock or time synchronization is otherwise impaired. In this approach, an unpredictable nonce is sent by the appraising entity and the nonce is then signed and included along with the Claims in the Evidence or Attestation Result. After checking that the sent and received nonces are the same, the appraising entity knows that the Claims were signed after the nonce was generated. This allows associating a "rough" epoch to the Evidence or Attestation Result. In this case, the epoch is said to be rough because:
第2のアプローチでは、時間管理の責任を検証者（エビデンスの場合）または信頼する側（アテステーション結果の場合）に完全に置く方法があります。たとえば、このアプローチは、アテスターが信頼できる時計を持っていない場合や、時刻同期が妨げられている場合に適しているかもしれません。このアプローチでは、査定エンティティによって予測不可能なナンスが送信され、そのナンスが署名され、クレームと一緒にエビデンスまたはアテステーション結果に含まれます。送信されたナンスと受信されたナンスが同じであることを確認した後、査定エンティティは、クレームがナンス生成後に署名されたことを知ります。これにより、エビデンスまたはアテステーション結果に「おおまかな」エポックを関連付けることができます。この場合、エポックは「おおまか」と言われる理由は次の通りです：
* The epoch applies to the entire Claim set instead of a more granular association, and
* エポックは、より粒状な関連ではなく、全体のクレームセットに適用されます。
* The time between the creation of Claims and the collection of Claims is indistinguishable.
* 請求書の作成と請求書の収集の間の時間は区別できません。
A third approach relies on having epoch identifiers (IDs) periodically sent to both the sender and receiver of Evidence or Attestation Results by some "epoch ID distributor".
第3のアプローチは、いくつかの「エポックID配布者」によってEvidenceまたはAttestation Resultsの送信者と受信者の両方に定期的にエポック識別子（ID）が送信されることに依存しています。
Epoch IDs are different from nonces as they can be used more than once and can even be used by more than one entity at the same time. Epoch IDs are different from timestamps as they do not have to convey information about a point in time, i.e., they are not necessarily monotonically increasing integers.
エポックIDは、非スは異なります。それらは複数回使用することができ、さらに複数のエンティティによって同時に使用することもできます。エポックIDは、タイムスタンプとは異なり、時間の特定のポイントに関する情報を伝達する必要がないため、必ずしも単調に増加する整数ではありません。
Like the nonce approach, this allows associating a "rough" epoch without requiring a trustworthy clock or time synchronization in order to generate or appraise the freshness of Evidence or Attestation Results. Only the epoch ID distributor requires access to a clock so it can periodically send new epoch IDs.
このアプローチは、信頼できるクロックや時間同期を必要とせずに、証拠や証明結果の新鮮さを生成または評価するために「おおよその」エポックを関連付けることを可能にします。エポックIDディストリビューターだけがクロックにアクセスする必要があるため、定期的に新しいエポックIDを送信できます。
The most recent epoch ID is included in the produced Evidence or Attestation Results, and the appraising entity can compare the epoch ID in received Evidence or Attestation Results against the latest epoch ID it received from the epoch ID distributor to determine if it is within the current epoch. An actual solution also needs to take into account race conditions when transitioning to a new epoch, such as by using a counter signed by the epoch ID distributor as the epoch ID, by including both the current and previous epoch IDs in messages and/or checks by requiring retries in case of mismatching epoch IDs, or by buffering incoming messages that might be associated with an epoch ID that the receiver has not yet obtained.
最新のエポックIDは生成されたエビデンスまたは証明結果に含まれており、評価エンティティは受信したエビデンスまたは証明結果のエポックIDを、エポックIDディストリビューターから受け取った最新のエポックIDと比較して、現在のエポック内にあるかどうかを判断できます。新しいエポックに移行する際の競合状態も考慮する必要があります。これは、エポックIDディストリビューターによって署名されたカウンターをエポックIDとして使用すること、メッセージやチェックに現在のエポックIDと前のエポックIDの両方を含めること、エポックIDが一致しない場合に再試行を要求すること、または受信者がまだ取得していない可能性のあるエポックIDに関連付けられている着信メッセージをバッファリングすることなどが含まれます。
More generally, in order to prevent an appraising entity from generating false negatives (e.g., discarding Evidence that is deemed stale even if it is not), the appraising entity should keep an "epoch window" consisting of the most recently received epoch IDs. The depth of such epoch window is directly proportional to the maximum network propagation delay between the first to receive the epoch ID and the last to receive the epoch ID and it is inversely proportional to the epoch duration. The appraising entity shall compare the epoch ID carried in the received Evidence or Attestation Result with the epoch IDs in its epoch window to find a suitable match.
より一般的には、査定エンティティが偽の否定を生成するのを防ぐために（例：古くなったと見なされた証拠を破棄することがあっても）、査定エンティティは、最も最近受信したエポックIDから構成される「エポックウィンドウ」を保持すべきです。そのようなエポックウィンドウの深さは、最初にエポックIDを受信した者と最後にエポックIDを受信した者の間の最大ネットワーク伝播遅延に比例し、エポックの期間に反比例します。査定エンティティは、受信した証拠または証明結果に含まれるエポックIDを、エポックウィンドウ内のエポックIDと比較して適切な一致を見つけるべきです。
Whereas the nonce approach typically requires the appraising entity to keep state for each nonce generated, the epoch ID approach minimizes the state kept to be independent of the number of Attesters or Verifiers from which it expects to receive Evidence or Attestation Results as long as all use the same epoch ID distributor.
nonceアプローチでは、通常、各生成されたnonceごとに評価エンティティが状態を保持する必要がありますが、エポックIDアプローチは、同じエポックIDディストリビューターを使用する限り、EvidenceまたはAttestation Resultsを受信するAttestersまたはVerifiersの数に独立して保持される状態を最小限に抑えます。
Implicit and explicit timekeeping can be combined into hybrid mechanisms. For example, if clocks exist within the Attesting Environment and are considered trustworthy (tamper-proof) but are not synchronized, a nonce-based exchange may be used to determine the (relative) time offset between the involved peers followed by any number of timestamp based exchanges.
暗黙的および明示的な時間管理は、ハイブリッドメカニズムに組み合わせることができます。たとえば、アテスティング環境内に時計が存在し、信頼できる（改ざん防止）と見なされているが同期されていない場合、ノンスベースの交換を使用して関係するピア間の（相対的な）時間オフセットを決定し、その後、タイムスタンプベースの交換を任意の回数行うことができます。
It is important to note that the actual values in Claims might have been generated long before the Claims are signed. If so, it is the signer's responsibility to ensure that the values are still fresh when they are signed. For example, values generated at boot time might have been saved to secure storage until network connectivity is established to the remote Verifier and a nonce is obtained.
Claims内の実際の値は、Claimsが署名される前に生成されている可能性があることに注意することが重要です。その場合、値が署名されるときにまだ新鮮であることを保証するのは署名者の責任です。たとえば、ブート時に生成された値は、ネットワーク接続がリモートの検証者に確立され、ノンスが取得されるまで、安全なストレージに保存されている可能性があります。
A more detailed discussion with examples appears in Appendix A.
付録Aには、例を交えたより詳細な議論が記載されています。
For a discussion on the security of epoch IDs see Section 12.3.
エポックIDのセキュリティに関する議論については、セクション12.3を参照してください。
The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a device as well as potentially any users of the device.
証拠の伝達とその結果の証明結果は、デバイスの内部状態に関する多くの情報、およびデバイスの利用者に関する可能性があります。
In many cases, the whole point of attestation procedures is to provide reliable information about the type of the device and the firmware/software that the device is running.
多くの場合、証明手続きの目的は、デバイスの種類やデバイスが実行しているファームウェア/ソフトウェアの情報を信頼性のあるものとすることです。
This information might be particularly interesting to many attackers. For example, knowing that a device is running a weak version of firmware provides a way to aim attacks better.
この情報は多くの攻撃者にとって特に興味深いかもしれません。たとえば、デバイスが脆弱なファームウェアのバージョンを実行していることを知っていると、攻撃をより的確に狙う方法が提供されます。
In some circumstances, if an attacker can become aware of Endorsements, Reference Values, or appraisal policies, it could potentially provide an attacker with insight into defensive mitigations. It is recommended that attention be paid to confidentiality of such information.
攻撃者が承認、参照値、または査定ポリシーに気付くことができる場合、それは攻撃者に防御策に対する洞察を提供する可能性があります。そのような情報の機密性に注意を払うことが推奨されています。
Additionally, many Evidence, Attestation Results, and appraisal policies potentially contain Personally Identifying Information (PII) depending on the end-to-end use case of the remote attestation procedure. Remote attestation that includes containers and applications, e.g., a blood pressure monitor, may further reveal details about specific systems or users.
さらに、多くの証拠、証明結果、および査定ポリシーには、リモート査定手続きのエンドツーエンドの使用ケースに応じて、個人を特定する情報（PII）が含まれている可能性があります。コンテナやアプリケーションを含むリモート査定は、例えば血圧計など、特定のシステムやユーザーに関する詳細をさらに明らかにする可能性があります。
In some cases, an attacker may be able to make inferences about the contents of Evidence from the resulting effects or timing of the processing. For example, an attacker might be able to infer the value of specific Claims if it knew that only certain values were accepted by the Relying Party.
攻撃者は、処理の結果やタイミングから証拠の内容について推論することができる場合があります。例えば、攻撃者は、特定の値のみが信頼する側で受け入れられることを知っていれば、特定のクレームの値を推測することができるかもしれません。
Conceptual messages (see Section 8) carrying sensitive or confidential information are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption. If there isn't confidentiality protection of conceptual messages themselves, the underlying conveyance protocol should provide these protections.
概念メッセージ（セクション8を参照）には、機密情報を含むものがあります。これらは整合性保護されることが期待されます（つまり、署名または安全なチャネルを介して）。任意で暗号化による機密保護も行われるかもしれません。概念メッセージ自体に機密保護がない場合、基礎となる伝達プロトコルがこれらの保護を提供する必要があります。
As Evidence might contain sensitive or confidential information, Attesters are responsible for only sending such Evidence to trusted Verifiers. Some Attesters might want a stronger level of assurance of the trustworthiness of a Verifier before sending Evidence to it. In such cases, an Attester can first act as a Relying Party and ask for the Verifier's own Attestation Result. Appraising it just as a Relying Party would appraise an Attestation Result for any other purpose.
証拠には機密性の高い情報が含まれる可能性があるため、証明者は信頼できる検証者にのみそのような証拠を送る責任があります。一部の証明者は、証拠を送る前に検証者の信頼性についてより強い保証レベルを求めるかもしれません。そのような場合、証明者はまず信頼する当事者として行動し、検証者の独自の証明結果を求めることができます。これを、他の目的のために証明結果を評価するのと同様に、当事者として評価します。
Another approach to deal with Evidence is to remove PII from the Evidence while still being able to verify that the Attester is one of a large set. This approach is often called "Direct Anonymous Attestation". See Section 6.2 of [CCC-DeepDive] and [RATS-DAA] for more discussion.
証拠からPIIを削除しながら、アテスターが大規模なセットの1つであることを検証できる別のアプローチは、「Direct Anonymous Attestation」と呼ばれることがよくあります。詳細については、[CCC-DeepDive]のセクション6.2と[RATS-DAA]を参照してください。
This document provides an architecture for doing remote attestation. No specific wire protocol is documented here. Without a specific proposal to compare against, it is impossible to know if the security threats listed below have been mitigated well.
この文書はリモートアテステーションを行うためのアーキテクチャを提供しています。ここでは特定のワイヤープロトコルは文書化されていません。比較する具体的な提案がないため、以下にリストされたセキュリティ脅威が十分に軽減されているかどうかを知ることは不可能です。
The security considerations below should be read as being, essentially, requirements against realizations of the RATS architecture. Some threats apply to protocols and some are against implementations (code) and physical infrastructure (such as factories).
以下のセキュリティに関する考慮事項は、RATSアーキテクチャの実現に対する要件として読まれるべきです。一部の脅威はプロトコルに対して適用され、一部は実装（コード）や物理インフラ（工場など）に対してのものです。
The fundamental purpose of the RATS architecture is to allow a Relying Party to establish a basis for trusting the Attester.
RATSアーキテクチャの基本的な目的は、リライアンスパーティーがアテスターを信頼する基盤を確立することです。
Implementers need to pay close attention to the protection of the Attester and the manufacturing processes for provisioning attestation key material. If either of these are compromised, intended levels of assurance for remote attestation procedures are compromised because attackers can forge Evidence or manipulate the Attesting Environment. For example, a Target Environment should not be able to tamper with the Attesting Environment that measures it by isolating the two environments from each other in some way.
実装者は、アテスターの保護とアテステーションキー素材の供給の製造プロセスに注意を払う必要があります。これらのいずれかが危険にさらされると、リモートアテステーション手順の意図された保証レベルが危険にさらされます。なぜなら、攻撃者がエビデンスを偽造したり、アテスティング環境を操作したりできるからです。例えば、ターゲット環境は、それを測定するアテスティング環境を何らかの方法で互いに分離することによって、アテスティング環境を改ざんできないようにする必要があります。
Remote attestation applies to use cases with a range of security requirements. The protections discussed here range from low to high security: low security may be limited to application or process isolation by the device's operating system and high security may involve specialized hardware to defend against physical attacks on a chip.
リモートアテステーションは、さまざまなセキュリティ要件を持つユースケースに適用されます。ここで議論されている保護は、低いセキュリティから高いセキュリティまで幅広くあります。低いセキュリティは、デバイスのオペレーティングシステムによるアプリケーションやプロセスの分離に限定される場合があり、高いセキュリティは、チップへの物理攻撃に対抗するために専用のハードウェアを使用する場合があります。
It is assumed that an Attesting Environment is sufficiently isolated from the Target Environment it collects Claims about and that it signs the resulting Claims set with an attestation key so that the Target Environment cannot forge Evidence about itself. Such an isolated environment might be provided by a process, a dedicated chip, a TEE, a virtual machine, or another secure mode of operation. The Attesting Environment must be protected from unauthorized modification to ensure it behaves correctly. Confidentiality protection of the Attesting Environment's signing key is vital so it cannot be misused to forge Evidence.
アテスティング環境は、それが収集するクレームについてのターゲット環境から十分に隔離されていると仮定され、その結果のクレームセットにアテステーションキーで署名することで、ターゲット環境が自身に関するエビデンスを偽造できないようにします。このような隔離された環境は、プロセス、専用チップ、TEE、仮想マシン、または他の安全な動作モードによって提供される可能性があります。アテスティング環境は、正しく動作するようにするために、未承認の変更から保護されなければなりません。アテスティング環境の署名キーの機密保護は重要であり、それがエビデンスを偽造するために誤用されないようにする必要があります。
In many cases, the user or owner of a device that includes the role of Attester must not be able to modify or extract keys from the Attesting Environments to prevent creating forged Evidence. Some common examples include the user of a mobile phone or FIDO authenticator.
多くの場合、アテスターの役割を含むデバイスのユーザーまたは所有者は、偽のエビデンスを作成するのを防ぐために、アテスティング環境からキーを変更または抽出できないようにする必要があります。一般的な例には、携帯電話やFIDO認証器のユーザーが含まれます。
Measures for a minimally protected system might include process or application isolation provided by a high-level operating system and restricted access to root or system privileges. In contrast, for really simple single-use devices that don't use a protected mode operating system (like a Bluetooth speaker), the only factual isolation might be the sturdy housing of the device.
最小限の保護されたシステムのための対策には、高度なオペレーティングシステムによるプロセスやアプリケーションの分離、およびルートやシステム特権への制限されたアクセスが含まれるかもしれません。一方、Bluetoothスピーカーのように保護されたモードのオペレーティングシステムを使用していない本当にシンプルな単一利用デバイスの場合、唯一の実質的な分離はデバイスの頑丈な筐体かもしれません。
Measures for a moderately protected system could include a special restricted operating environment, such as a TEE. In this case, only security-oriented software has access to the Attester and key material.
中程度に保護されたシステムの対策には、TEEなどの特別な制限された運用環境が含まれる可能性があります。この場合、セキュリティ志向のソフトウェアのみがアテスターと鍵素材にアクセスできます。
Measures for a highly protected system could include specialized hardware that is used to provide protection against chip decapping attacks, power supply and clock glitching, faulting injection and RF, and power side channel attacks.
高度に保護されたシステムの対策には、チップのデキャップ攻撃、電源およびクロックのグリッチング、フォルティングインジェクションおよびRF、および電力側チャネル攻撃に対する保護を提供するために使用される専門のハードウェアが含まれる可能性があります。
Attestation key provisioning is the process that occurs in the factory or elsewhere to establish signing key material on the device and the validation key material off the device. Sometimes, this procedure is referred to as "personalization" or "customization".
アテステーションキープロビジョニングは、工場や他の場所で行われるプロセスで、デバイス上の署名キーマテリアルとデバイス外の検証キーマテリアルを確立するものです。この手順は、時々「個別化」や「カスタマイズ」とも呼ばれます。
When generating keys off-device in the factory or in the device, the use of a cryptographically strong sequence ([RFC4086], Section 6.2) needs consideration.
工場外またはデバイス内で鍵を生成する際には、暗号学的に強力なシーケンス（[RFC4086]、セクション6.2）の使用が考慮される必要があります。
One way to provision key material is to first generate it external to the device and then copy the key onto the device. In this case, confidentiality protection of the generator and the path over which the key is provisioned is necessary. The manufacturer needs to take care to protect corresponding key material with measures appropriate for its value.
キー素材を供給する1つの方法は、まずデバイス外部で生成し、その後キーをデバイスにコピーすることです。この場合、生成器とキーの供給経路の機密保護が必要です。製造業者は、その価値に適した対策で対応するキー素材を保護する必要があります。
The degree of protection afforded to this key material can vary by the intended function of the device and the specific practices of the device manufacturer or integrator. The confidentiality protection is fundamentally based upon some amount of physical protection. While encryption is often used to provide confidentiality when a key is conveyed across a factory where the attestation key is created or applied, it must be available in an unencrypted form. The physical protection can therefore vary from situations where the key is unencrypted only within carefully controlled secure enclaves within silicon to situations where an entire facility is considered secure by the simple means of locked doors and limited access.
この鍵素材に提供される保護の程度は、デバイスの意図された機能やデバイスメーカーまたは統合業者の具体的な慣行によって異なる場合があります。機密保護は基本的にある程度の物理的保護に基づいています。鍵がアテステーション鍵が作成または適用される工場を横断する際に機密性を提供するために暗号化がしばしば使用されますが、それは非暗号化形式で利用可能でなければなりません。したがって、物理的保護は、鍵がシリコン内の厳密に制御された安全なエンクロージャ内でのみ非暗号化されている状況から、施設全体が施錠されたドアと制限されたアクセスによって安全と見なされる状況までさまざまです。
The cryptography that is used to enable confidentiality protection of the attestation key comes with its own requirements to be secured. This results in recursive problems, as the key material used to provision attestation keys must again somehow have been provisioned securely beforehand (requiring an additional level of protection and so on).
使用される暗号化技術は、アテステーションキーの機密保護を可能にするために使用されますが、それ自体が保護される必要があります。これにより、再帰的な問題が発生します。アテステーションキーを提供するために使用されるキー素材は、以前にも何らかの方法で安全に提供されている必要があります（追加の保護レベルが必要となります）。
Commonly, a combination of some physical security measures and some cryptographic measures are used to establish confidentiality protection.
一般的に、いくつかの物理的なセキュリティ対策と暗号化対策の組み合わせが使用され、機密保護が確立されます。
When key material is generated within a device and the secret part of it never leaves the device, the problem may lessen. For public-key cryptography, it is not necessary to maintain confidentiality of the public key. However, integrity of the chain of custody of the public key is necessary in order to avoid attacks where an attacker is able to get a key endorsed that the attacker controls.
デバイス内で鍵素材が生成され、その秘密部分がデバイスから決して出ない場合、問題は軽減されるかもしれません。公開鍵暗号においては、公開鍵の機密性を維持する必要はありません。ただし、攻撃者がコントロールする鍵を取得できる攻撃を回避するために、公開鍵の保管の完全性が必要です。
To summarize, attestation key provisioning must ensure that only valid attestation key material is established in Attesters.
要約すると、アテステーションキーのプロビジョニングは、アテスターにおいて有効なアテステーションキーの材料のみが確立されることを保証しなければなりません。
Any solution that conveys information in any conceptual message (see Section 8) must support end-to-end integrity protection and replay attack prevention. It often also needs to support additional security properties, including:
任意の解決策が任意の概念メッセージで情報を伝達する場合（セクション8を参照）、エンドツーエンドの整合性保護とリプレイ攻撃の防止をサポートする必要があります。通常、追加のセキュリティプロパティもサポートする必要があります。
* end-to-end encryption,
* エンドツーエンドの暗号化
* denial-of-service protection,
* サービス拒否攻撃防御、
* authentication,
* 認証
* auditing,
* 監査、
* fine-grained access controls, and
* feine-grained access controls, and
* logging.
* ログ記録。
Section 10 discusses ways in which freshness can be used in this architecture to protect against replay attacks.
セクション10では、このアーキテクチャで新鮮さを利用してリプレイ攻撃に対抗する方法について説明しています。
To assess the security provided by a particular appraisal policy, it is important to understand the strength of the root of trust, e.g., whether it is mutable software or firmware that is read-only after boot or immutable hardware/ROM.
特定の査定ポリシーによって提供されるセキュリティを評価するには、信頼のルートの強さを理解することが重要です。たとえば、ブート後に読み取り専用となる変更可能なソフトウェアまたはファームウェアか、不変のハードウェア/ROMかを理解することが重要です。
It is also important that the appraisal policy was obtained securely itself. If an attacker can configure or modify appraisal policies and Endorsements or Reference Values for a Relying Party or a Verifier, then integrity of the process is compromised.
評価ポリシー自体が安全に取得されたことも重要です。攻撃者が信頼する側または検証者のための評価ポリシーや承認、または参照値を構成または変更できる場合、プロセスの整合性が損なわれます。
Security protections in the RATS architecture may be applied at different layers, whether by a conveyance protocol or an information encoding format. This architecture expects conceptual messages to be end-to-end protected based on the role interaction context. For example, if an Attester produces Evidence that is relayed through some other entity that doesn't implement the Attester or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence.
RATSアーキテクチャのセキュリティ保護は、輸送プロトコルまたは情報エンコーディング形式によって異なるレイヤーで適用される可能性があります。このアーキテクチャでは、概念メッセージが役割相互作用コンテキストに基づいてエンドツーエンドで保護されることが期待されています。たとえば、アテスターがエビデンスを生成し、それがアテスターまたは意図した検証者の役割を実装していない他のエンティティを介して中継される場合、中継エンティティはエビデンスにアクセスできることを期待すべきではありません。
The RATS architecture allows for an entity to function in multiple roles (Section 6) and for composite devices (Section 3.3). Implementers need to evaluate their designs to ensure that the assumed security properties of the individual components and roles still hold despite the lack of separation and that emergent risk is not introduced. The specifics of this evaluation will depend on the implementation and the use case; hence, they are out of scope for this document. Isolation mechanisms in software or hardware that separate Attesting Environments and Target Environments (Section 3.1) can support an implementer's evaluation and resulting design decisions.
RATSアーキテクチャは、エンティティが複数の役割で機能することを可能にし（セクション6）、合成デバイス（セクション3.3）にも対応しています。実装者は、個々のコンポーネントや役割の想定されるセキュリティプロパティが分離がないにもかかわらず依然として保持されていることを確認し、新たなリスクが導入されていないことを評価する必要があります。この評価の具体的な内容は、実装とユースケースに依存するため、この文書の範囲外です。アテスティング環境とターゲット環境を分離するソフトウェアまたはハードウェアの分離メカニズム（セクション3.1）は、実装者の評価と設計決定をサポートすることができます。
Epoch IDs, described in Section 10.3, can be tampered with, replayed, dropped, delayed, and reordered by an attacker.
エポックIDは、攻撃者によって改ざん、再生、削除、遅延、および並べ替えが可能です。
An attacker could either be external or belong to the distribution group (for example, if one of the Attester entities have been compromised).
攻撃者は外部の者であるか、もしくは配布グループに属している可能性があります（たとえば、Attesterエンティティの1つが侵害されている場合）。
An attacker who is able to tamper with epoch IDs can potentially lock all the participants in a certain epoch of choice forever, effectively freezing time. This is problematic since it destroys the ability to ascertain freshness of Evidence and Attestation Results.
エポックIDを改ざんできる攻撃者は、任意のエポックで全参加者を永遠にロックする可能性があり、時間を凍結することができます。これは、エビデンスやアテステーション結果の新鮮さを確認する能力を破壊するため、問題があります。
To mitigate this threat, the transport should be at least integrity protected and provide origin authentication.
この脅威を軽減するためには、輸送は少なくとも整合性保護され、起源認証が提供される必要があります。
Selective dropping of epoch IDs is equivalent to pinning the victim node to a past epoch. An attacker could drop epoch IDs to only some entities and not others, which will typically result in a denial of service due to the permanent staleness of the Attestation Result or Evidence.
エポックIDの選択的な削除は、被害者ノードを過去のエポックに固定することと同等です。攻撃者はエポックIDを一部のエンティティにのみ削除することができ、これにより通常はアテステーション結果やエビデンスの永続的な古さによるサービス拒否が発生する可能性があります。
Delaying or reordering epoch IDs is equivalent to manipulating the victim's timeline at will. This ability could be used by a malicious actor (e.g., a compromised router) to mount a confusion attack. For example, a Verifier can be tricked into accepting Evidence coming from a past epoch as fresh, while, in the meantime, the Attester has been compromised.
エポックIDの遅延や並べ替えは、被害者のタイムラインを自由に操作することと同等です。この能力は、悪意のある行為者（例：侵害されたルーター）が混乱攻撃を行うために使用される可能性があります。たとえば、検証者は、過去のエポックからの証拠を新鮮なものとして受け入れるようにだまされる可能性がありますが、その間にアテスターが侵害されているかもしれません。
Reordering and dropping attacks are mitigated if the transport provides the ability to detect reordering and drop. However, the delay attack described above can't be thwarted in this manner.
再配置やドロップ攻撃は、輸送が再配置やドロップを検出する機能を提供する場合に軽減されます。ただし、上記で説明した遅延攻撃はこの方法では阻止できません。
As noted in Section 7, Verifiers and Relying Parties have trust anchor stores that must be secured. [RFC6024] contains more discussion of trust anchor store requirements for protecting public keys. Section 6 of [NIST-800-57-p1] contains a comprehensive treatment of the topic, including the protection of symmetric key material. Specifically, a trust anchor store must resist modification against unauthorized insertion, deletion, and modification. Additionally, if the trust anchor is a symmetric key, the trust anchor store must not allow unauthorized read.
セクション7に記載されているように、検証者と依存するパーティーは信頼アンカーストアを確保する必要があります。[RFC6024]には、公開鍵を保護するための信頼アンカーストアの要件についてのさらなる議論が含まれています。[NIST-800-57-p1]のセクション6には、対称鍵素材の保護を含むトピックの包括的な取り扱いが含まれています。具体的には、信頼アンカーストアは、不正な挿入、削除、および変更に対して変更に耐えなければならず、信頼アンカーが対称鍵である場合、信頼アンカーストアは不正な読み取りを許可してはなりません。
If certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate path up to the trust anchor, which includes checking for certificate revocation. For an example of such a procedure, see Section 6 of [RFC5280].
証明書が信頼アンカーとして使用される場合、検証者と依存する当事者は、信頼アンカーまでの全体の証明書パスを検証する責任があります。これには証明書の失効の確認も含まれます。このような手順の例については、[RFC5280]のセクション6を参照してください。
This document has no IANA actions.
この文書にはIANAのアクションはありません。
[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>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[CCC-DeepDive]
Confidential Computing Consortium, "A Technical Analysis
of Confidential Computing", Version 1.3, November 2022,
<https://confidentialcomputing.io/white-papers-reports>.
[CTAP] FIDO Alliance, "Client to Authenticator Protocol (CTAP)",
February 2018, <https://fidoalliance.org/specs/fido-v2.0-
id-20180227/fido-client-to-authenticator-protocol-v2.0-id-
20180227.html>.
[NIST-800-57-p1]
Barker, E., "Recommendation for Key Management: Part 1 -
General", DOI 10.6028/NIST.SP.800-57pt1r5, May 2020,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-57pt1r5.pdf>.
[OPCUA] OPC Foundation, "OPC Unified Architecture Specification,
Part 2: Security Model, Release 1.03", OPC 10000-2 ,
November 2015, <https://opcfoundation.org/developer-tools/
specifications-unified-architecture/part-2-security-
model/>.
[RATS-DAA] Birkholz, H., Newton, C., Chen, L., and D. Thaler, "Direct
Anonymous Attestation for the Remote Attestation
Procedures Architecture", Work in Progress, Internet-
Draft, draft-ietf-rats-daa-02, 7 September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
daa-02>.
[RATS-PSA-TOKEN]
Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T.
Fossati, "Arm's Platform Security Architecture (PSA)
Attestation Token", Work in Progress, Internet-Draft,
draft-tschofenig-rats-psa-token-10, 6 September 2022,
<https://datatracker.ietf.org/doc/html/draft-tschofenig-
rats-psa-token-10>.
[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-UCCS]
Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
Bormann, "A CBOR Tag for Unprotected CWT Claims Sets",
Work in Progress, Internet-Draft, draft-ietf-rats-uccs-04,
11 January 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-uccs-04>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<https://www.rfc-editor.org/info/rfc5209>.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
Requirements", RFC 6024, DOI 10.17487/RFC6024, October
2010, <https://www.rfc-editor.org/info/rfc6024>.
[RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource-
Oriented Lightweight Information Exchange (ROLIE)",
RFC 8322, DOI 10.17487/RFC8322, February 2018,
<https://www.rfc-editor.org/info/rfc8322>.
[strengthoffunction]
NIST, "Strength of Function",
<https://csrc.nist.gov/glossary/term/
strength_of_function>.
[TCG-DICE] Trusted Computing Group, "DICE Attestation Architecture",
Version 1.00, Revision 0.23, March 2021,
<https://trustedcomputinggroup.org/wp-content/uploads/
DICE-Attestation-Architecture-r23-final.pdf>.
[TCG-DICE-SIBDA]
Trusted Computing Group, "Symmetric Identity Based Device
Attestation", Version 1.0, Revision 0.95, January 2020,
<https://trustedcomputinggroup.org/wp-content/uploads/
TCG_DICE_SymIDAttest_v1_r0p95_pub-1.pdf>.
[TCGarch] Trusted Computing Group, "Trusted Platform Module Library,
Part 1: Architecture", November 2019,
<https://trustedcomputinggroup.org/wp-content/uploads/
TCG_TPM2_r1p59_Part1_Architecture_pub.pdf>.
[TEEP-ARCH]
Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
"Trusted Execution Environment Provisioning (TEEP)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-teep-architecture-19, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-teep-
architecture-19>.
[TLS-CWT] Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens
(CWTs) in Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS)", Work in Progress,
Internet-Draft, draft-tschofenig-tls-cwt-02, 13 July 2020,
<https://datatracker.ietf.org/doc/html/draft-tschofenig-
tls-cwt-02>.
[WebAuthN] W3C, "Web Authentication: An API for accessing Public Key
Credentials Level 1", March 2019,
<https://www.w3.org/TR/webauthn-1/>.
Section 10 discussed various issues and requirements around freshness of Evidence and summarized three approaches that might be used by different solutions to address them. This appendix provides more details with examples to help illustrate potential approaches and inform those creating specific solutions.
セクション10では、証拠の新鮮さに関するさまざまな問題や要件について議論し、それらに対処するために異なるソリューションが使用するかもしれない3つのアプローチを要約しました。この付録では、潜在的なアプローチを説明するための詳細と例を提供し、特定のソリューションを作成する人々に情報を提供します。
The table below defines a number of relevant events with an ID that is used in subsequent diagrams. The times of said events might be defined in terms of an absolute clock time, such as the Coordinated Universal Time timescale, or might be defined relative to some other timestamp or timeticks counter, such as a clock resetting its epoch each time it is powered on.
以下の表は、後続の図で使用されるIDを持ついくつかの関連イベントを定義しています。これらのイベントの時刻は、協定世界時のような絶対時計時刻で定義される場合があります。また、他のタイムスタンプやタイムティックスカウンターに対して相対的に定義される場合もあります。例えば、時計が電源を入れるたびにエポックをリセットする場合などです。
+====+============+=================================================+
| ID | Event | Explanation of event |
+====+============+=================================================+
| VG | Value | A value to appear in a Claim was created. |
| | generated | In some cases, a value may have technically |
| | | existed before an Attester became aware of |
| | | it, but the Attester might have no idea how |
| | | long it has had that value. In such a |
| | | case, the value created time is the time at |
| | | which the Claim containing the copy of the |
| | | value was created. |
+----+------------+-------------------------------------------------+
| NS | Nonce sent | A nonce not predictable to an Attester |
| | | (recentness & uniqueness) is sent to an |
| | | Attester. |
+----+------------+-------------------------------------------------+
| NR | Nonce | A nonce is relayed to an Attester by |
| | relayed | another entity. |
+----+------------+-------------------------------------------------+
| IR | Epoch ID | An epoch ID is successfully received and |
| | received | processed by an entity. |
+----+------------+-------------------------------------------------+
| EG | Evidence | An Attester creates Evidence from collected |
| | generation | Claims. |
+----+------------+-------------------------------------------------+
| ER | Evidence | A Relying Party relays Evidence to a |
| | relayed | Verifier. |
+----+------------+-------------------------------------------------+
| RG | Result | A Verifier appraises Evidence and generates |
| | generation | an Attestation Result. |
+----+------------+-------------------------------------------------+
| RR | Result | A Relying Party relays an Attestation |
| | relayed | Result to a Relying Party. |
+----+------------+-------------------------------------------------+
| RA | Result | The Relying Party appraises Attestation |
| | appraised | Results. |
+----+------------+-------------------------------------------------+
| OP | Operation | The Relying Party performs some operation |
| | performed | requested by the Attester via a resource |
| | | access protocol as depicted in Figure 8, |
| | | e.g., across a session created earlier at |
| | | time(RA). |
+----+------------+-------------------------------------------------+
| RX | Result | An Attestation Result should no longer be |
| | expiry | accepted, according to the Verifier that |
| | | generated it. |
+----+------------+-------------------------------------------------+
Table 1: Relevant Events over Time
表1：時間経過に伴う関連イベント
Using the table above, a number of hypothetical examples of how a solution might be built are illustrated below. This list is not intended to be complete; it is just representative enough to highlight various timing considerations.
上記の表を使用して、解決策がどのように構築されるかの仮想的な例が以下に示されています。このリストは完全なものであることを意図しているわけではありません。さまざまなタイミングの考慮を強調するだけの代表的なものです。
All times are relative to the local clocks, indicated by an "_a" (Attester), "_v" (Verifier), or "_r" (Relying Party) suffix.
すべての時間は、"_a"（Attester）、"_v"（Verifier）、または"_r"（Relying Party）の接尾辞で示されるローカルの時計に対して相対的です。
Times with an appended Prime (') indicate a second instance of the same event.
Prime（'）が付いている時間は、同じイベントの2回目を示します。
How and if clocks are synchronized depends upon the model.
時計が同期される方法とその有無は、モデルによって異なります。
In the figures below, curly braces indicate containment. For example, the notation Evidence{foo} indicates that 'foo' is contained in the Evidence; thus, it is covered by its signature.
以下の図では、波括弧は含まれていることを示しています。例えば、記法Evidence{foo}は、'foo'がEvidenceに含まれていることを示しており、そのため署名でカバーされています。
Figure 10 illustrates a hypothetical Passport Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party, which depends on using a secure clock synchronization mechanism. As a result, the receiver of a conceptual message containing a timestamp can directly compare it to its own clock and timestamps.
図10は、タイムスタンプを使用し、Attester、Verifier、およびRelying Partyの間でおおよそ同期されたクロックを必要とする仮想のパスポートモデルソリューションを示しています。これには、安全なクロック同期メカニズムの使用が必要です。その結果、タイムスタンプを含む概念メッセージの受信者は、それを自分自身のクロックとタイムスタンプと直接比較できます。
.----------. .----------. .---------------.
| Attester | | Verifier | | Relying Party |
'----+-----' '-----+----' '-------+-------'
| | |
time(VG_a) | |
| | |
~ ~ ~
| | |
time(EG_a) | |
| | |
+------Evidence{time(EG_a)}------>| |
| | |
| time(RG_v) |
| | |
|<-----Attestation Result---------+ |
| {time(RG_v),time(RX_v)} | |
~ ~
| |
+--Attestation Result{time(RG_v),time(RX_v)}--> time(RA_r)
| |
~ ~
| |
| time(OP_r)
Figure 10: Timestamp-Based Passport Model
図10：タイムスタンプベースのパスポートモデル
The Verifier can check whether the Evidence is fresh when appraising it at time(RG_v) by checking time(RG_v) - time(EG_a) < Threshold, where the Verifier's threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester.
検証者は、証拠を評価する際に、time(RG_v) - time(EG_a) < Threshold をチェックすることで、証拠が新しいかどうかを確認できます。検証者のしきい値は、検証者と証明者の間で許容される最大クロックスキューを考慮に入れるために十分に大きく設定されています。
If time(VG_a) is included in the Evidence along with the Claim value generated at that time, and the Verifier decides that it can trust the time(VG_a) value, the Verifier can also determine whether the Claim value is recent by checking time(RG_v) - time(VG_a) < Threshold. The threshold is decided by the Appraisal Policy for Evidence and, again, needs to take into account the maximum permitted clock skew between the Verifier and the Attester.
もし、EvidenceにClaim値が生成された時刻であるtime(VG_a)が含まれており、Verifierがtime(VG_a)の値を信頼できると判断した場合、Verifierはtime(RG_v) - time(VG_a) < Threshold をチェックすることで、Claim値が最近のものかどうかも判断できます。ThresholdはEvidenceのAppraisal Policyによって決定され、再びVerifierとAttesterの間の最大許容クロックスキューを考慮する必要があります。
The Attester does not consume the Attestation Result but might cache it.
アテスターはアテステーション結果を消費しませんが、キャッシュする可能性があります。
The Relying Party can check whether the Attestation Result is fresh when appraising it at time(RA_r) by checking the time(RA_r) - time(RG_v) < Threshold, where the Relying Party's threshold is large enough to account for the maximum permitted clock skew between the Relying Party and the Verifier. The result might then be used for some time (e.g., throughout the lifetime of a connection established at time(RA_r)). However, the Relying Party must be careful not to allow continued use beyond the period for which it deems the Attestation Result to remain fresh enough. Thus, it might allow use (at time(OP_r)) as long as time(OP_r) - time(RG_v) < Threshold. However, if the Attestation Result contains an expiry time time(RX_v), then it could explicitly check time(OP_r) < time(RX_v).
Relying Partyは、Attestation Resultが新しいかどうかを確認することができます。これは、Relying Partyがそれを評価する際にtime(RA_r) - time(RG_v) < Thresholdをチェックすることで行います。ただし、Relying Partyのしきい値は、Relying PartyとVerifierの間で許容される最大のクロックスキューを考慮に入れるために十分に大きくする必要があります。その結果は、その後の一定期間（たとえば、time(RA_r)で確立された接続の寿命全体）に使用されるかもしれません。ただし、Relying Partyは、Attestation Resultが十分に新鮮であると見なす期間を超えて継続して使用されることを許可しないよう注意する必要があります。したがって、time(OP_r) - time(RG_v) < Thresholdである限り、使用を許可するかもしれません。ただし、Attestation Resultに有効期限時刻time(RX_v)が含まれている場合、明示的にtime(OP_r) < time(RX_v)をチェックすることができます。
Figure 11 illustrates a hypothetical Passport Model solution that uses nonces instead of timestamps. Compared to the timestamp-based example, it requires an extra round trip to retrieve a nonce and requires that the Verifier and Relying Party track state to remember the nonce for some period of time.
図11は、タイムスタンプの代わりにナンスを使用する架空のパスポートモデルソリューションを示しています。タイムスタンプベースの例と比較して、ナンスを取得するために追加のラウンドトリップが必要であり、VerifierとRelying Partyが状態を追跡して一定期間ナンスを覚えておく必要があります。
The advantage is that it does not require that any clocks are synchronized. As a result, the receiver of a conceptual message containing a timestamp cannot directly compare it to its own clock or timestamps. Thus, we use a suffix ("a" for Attester, "v" for Verifier, and "r" for Relying Party) on the IDs below indicating which clock generated them since times from different clocks cannot be compared. Only the delta between two events from the sender can be used by the receiver.
利点は、どの時計も同期されている必要がないことです。その結果、タイムスタンプを含む概念メッセージの受信者は、それを自分自身の時計やタイムスタンプと直接比較することはできません。したがって、以下のIDにはサフィックス（Attesterの場合は"a"、Verifierの場合は"v"、Relying Partyの場合は"r"）を使用して、異なる時計から生成されたことを示します。異なる時計からの時間を比較することはできないため、送信者からの2つのイベント間の差だけが受信者によって使用されます。
.----------. .----------. .---------------.
| Attester | | Verifier | | Relying Party |
'----+-----' '-----+----' '-------+-------'
| | |
time(VG_a) | |
| | |
~ ~ ~
| | |
|<--Nonce1---------------------time(NS_v) |
| | |
time(EG_a) | |
| | |
+---Evidence--------------------->| |
| {Nonce1, time(EG_a)-time(VG_a)} | |
| | |
| time(RG_v) |
| | |
|<--Attestation Result------------+ |
| {time(RX_v)-time(RG_v)} | |
~ ~
| |
|<--Nonce2-------------------------------------time(NS_r)
| |
time(RR_a) |
| |
+--[Attestation Result{time(RX_v)-time(RG_v)}, -->|time(RA_r)
| Nonce2, time(RR_a)-time(EG_a)] |
| |
~ ~
| |
| time(OP_r)
Figure 11: Nonce-Based Passport Model
図11: ノンスベースのパスポートモデル
In this example solution, the Verifier can check whether the Evidence is fresh at time(RG_v) by verifying that time(RG_v)-time(NS_v) < Threshold.
この例の解決策では、検証者は、time(RG_v) - time(NS_v) < 閾値 が成立しているかどうかを確認することで、証拠が新しいかどうかを確認できます。
However, the Verifier cannot simply rely on a Nonce to determine whether the value of a Claim is recent since the Claim value might have been generated long before the nonce was sent by the Verifier. Nevertheless, if the Verifier decides that the Attester can be trusted to correctly provide the delta time(EG_a)-time(VG_a), then it can determine recency by checking time(RG_v)-time(NS_v) + time(EG_a)- time(VG_a) < Threshold.
ただし、検証者は、クレームの値がNonceがVerifierによって送信される前に生成されている可能性があるため、単にNonceに頼ることはできません。それでも、Verifierがアテスターが正しくデルタ時間（EG_a）-時間（VG_a）を提供することを信頼できると判断した場合、time(RG_v)-time(NS_v) + time(EG_a)- time(VG_a) < Threshold によって最近のかどうかを判断できます。
Similarly if, based on an Attestation Result from a Verifier it trusts, the Relying Party decides that the Attester can be trusted to correctly provide time deltas, then it can determine whether the Attestation Result is fresh by checking time(OP_r)-time(NS_r) + time(RR_a)-time(EG_a) < Threshold. Although the Nonce2 and time(RR_a)-time(EG_a) values cannot be inside the Attestation Result, they might be signed by the Attester such that the Attestation Result vouches for the Attester's signing capability.
同様に、信頼できる検証者からの検証結果に基づいて、依頼元がアテスターが時間差を正しく提供できると判断した場合、依頼元は時間（OP_r）-時間（NS_r）+時間（RR_a）-時間（EG_a）< 閾値をチェックすることによって、検証結果が新鮮であるかどうかを判断できます。Nonce2および時間（RR_a）-時間（EG_a）の値は検証結果の中に含まれていないかもしれませんが、アテスターによって署名されている可能性があり、その結果、検証結果がアテスターの署名能力を保証しているかもしれません。
However, the Relying Party must still be careful not to allow continued use beyond the period for which it deems the Attestation Result to remain valid. Thus, if the Attestation Result sends a validity lifetime in terms of time(RX_v)-time(RG_v), then the Relying Party can check time(OP_r)-time(NS_r) < time(RX_v)-time(RG_v).
ただし、リレーリング・パーティーは、アテステーション・リザルトが有効であると判断される期間を超えての継続使用を許可しないよう注意する必要があります。したがって、アテステーション・リザルトが時間（RX_v）-時間（RG_v）で有効期間を送信する場合、リレーリング・パーティーは時間（OP_r）-時間（NS_r）< 時間（RX_v）-時間（RG_v）を確認できます。
The example in Figure 12 illustrates a hypothetical Passport Model solution that uses epoch IDs instead of nonces or timestamps.
図12の例は、ノンスやタイムスタンプの代わりにエポックIDを使用する架空のパスポートモデルソリューションを示しています。
The epoch ID distributor broadcasts epoch ID I, which starts a new epoch E for a protocol participant upon reception at time(IR).
エポックIDディストリビューターは、エポックID Iをブロードキャストし、プロトコル参加者に新しいエポックEを開始させます。時間(IR)に受信された場合。
The Attester generates Evidence incorporating epoch ID I and conveys it to the Verifier.
Attesterは、エポックID Iを組み込んだ証拠を生成し、Verifierに伝えます。
The Verifier appraises that the received epoch ID I is "fresh" according to the definition provided in Section 10.3 whereby retries are required in the case of mismatching epoch IDs; then the Verifier generates an Attestation Result. The Attestation Result is conveyed to the Attester.
Verifierは、受信したエポックID I が「新鮮」であると評価し、セクション10.3で提供された定義に従い、エポックIDが一致しない場合にはリトライが必要であると判断します。その後、Verifierはアテステーション結果を生成します。生成されたアテステーション結果はアテスターに伝えられます。
After the transmission of epoch ID I' a new epoch E' is established when I' is received by each protocol participant. The Attester relays the Attestation Result obtained during epoch E (associated with epoch ID I) to the Relying Party using the epoch ID for the current epoch I'. If the Relying Party had not yet received I', then the Attestation Result would be rejected. The Attestation Result is received in this example.
エポックID I' の送信後、各プロトコル参加者が I' を受信すると、新しいエポック E' が確立されます。アテスターは、エポック E（エポックID I に関連付けられた）で得られたアテステーション結果を、現在のエポックID I' に対してリライアンスパーティーに中継します。リライアンスパーティーがまだ I' を受信していない場合、アテステーション結果は拒否されます。この例では、アテステーション結果が受信されます。
In Figure 12, the epoch ID for relaying an Attestation Result to the Relying Party is current while a previous epoch ID was used to generate Verifier evaluated Evidence. This indicates that at least one epoch transition has occurred and the Attestation Results may only be as fresh as the previous epoch. If the Relying Party remembers the previous epoch ID I during an epoch window as discussed in Section 10.3, and the message is received during that window, the Attestation Result is accepted as fresh; otherwise, it is rejected as stale.
図12において、Attestation Resultを信頼するためのエポックIDは現在のものであり、以前のエポックIDはVerifierが評価したEvidenceを生成するために使用されました。これは少なくとも1つのエポック遷移が発生したことを示しており、Attestation Resultsは前のエポックと同じくらい新鮮である可能性があります。Relying Partyがセクション10.3で議論されているように、エポックウィンドウ中に前のエポックID Iを覚えている場合、メッセージがそのウィンドウ中に受信された場合、Attestation Resultは新鮮として受け入れられます。それ以外の場合は古いとして拒否されます。
.-------------.
.----------. | Epoch ID | .----------. .---------------.
| Attester | | Distributor | | Verifier | | Relying Party |
'----+-----' '------+------' '-----+----' '-------+-------'
| | | |
time(VG_a) | | |
| | | |
~ | ~ ~
| | | |
time(IR_a) <-----I--o--I------> time(IR_v) ---> time(IR_r)
| | | |
time(EG_a) | | |
| | | |
+---Evidence--------------------->| |
| {I,time(EG_a)-time(VG_a)} | |
| | | |
| | time(RG_v) |
| | | |
|<--Attestation Result------------+ |
| {I,time(RX_v)-time(RG_v)} | |
| | | |
time(IR'_a) <----I'-o--I' ----> time(IR'_v) --> time(IR'_r)
| | |
+---[Attestation Result--------------------> time(RA_r)
| {I,time(RX_v)-time(RG_v)},I'] | |
| | |
~ ~ ~
| | |
| | time(OP_r)
Figure 12: Epoch ID-Based Passport Model
図12：エポックIDベースのパスポートモデル
Figure 13 illustrates a hypothetical Background-Check Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party. The Attester conveys Evidence to the Relying Party, which treats it as opaque and simply forwards it on to the Verifier.
図13は、タイムスタンプを使用し、アテスター、検証者、および信頼する側の間でおおよそ同期されたクロックを必要とする仮想のバックグラウンドチェックモデルソリューションを示しています。アテスターはエビデンスを信頼する側に伝え、信頼する側はそれを不透明なものとして扱い、単純に検証者に転送します。
.----------. .---------------. .----------.
| Attester | | Relying Party | | Verifier |
'-------+--' '-------+-------' '----+-----'
| | |
time(VG_a) | |
| | |
~ ~ ~
| | |
time(EG_a) | |
| | |
+----Evidence------->| |
| {time(EG_a)} | |
| time(ER_r) ---Evidence{time(EG_a)}---->|
| | |
| | time(RG_v)
| | |
| time(RA_r) <---Attestation Result------+
| | {time(RX_v)} |
~ ~ ~
| | |
| time(OP_r) |
Figure 13: Timestamp-Based Background-Check Model
図13：タイムスタンプベースのバックグラウンドチェックモデル
The time considerations in this example are equivalent to those discussed under Example 1.
この例での時間的考慮事項は、例1で議論されたものと同等です。
Figure 14 illustrates a hypothetical Background-Check Model solution that uses nonces; thus, it does not require that any clocks be synchronized. In this example solution, a nonce is generated by a Verifier at the request of a Relying Party when the Relying Party needs to send one to an Attester.
図14は、ノンスを使用する架空のバックグラウンドチェックモデルソリューションを示しており、したがって、どの時計も同期される必要はありません。この例のソリューションでは、リライアンスパーティがアテスターに送信する必要がある場合に、リライアンスパーティがリクエストしたときに、検証者によってノンスが生成されます。
.----------. .---------------. .----------.
| Attester | | Relying Party | | Verifier |
'----+-----' '-------+-------' '----+-----'
| | |
time(VG_a) | |
| | |
~ ~ ~
| | |
| |<-------Nonce-----------time(NS_v)
| | |
|<---Nonce-----------time(NR_r) |
| | |
time(EG_a) | |
| | |
+----Evidence{Nonce}--->| |
| | |
| time(ER_r) ---Evidence{Nonce}--->|
| | |
| | time(RG_v)
| | |
| time(RA_r) <---Attestation Result--+
| | {time(RX_v)-time(RG_v)} |
~ ~ ~
| | |
| time(OP_r) |
Figure 14: Nonce-Based Background-Check Model
図14: ノンスベースのバックグラウンドチェックモデル
The Verifier can check whether the Evidence is fresh and a Claim value is recent, which is the same as Example 2.
検証者は、証拠が新しいかどうかやクレームの価値が最近のものかどうかを確認できます。これはExample 2と同じです。
However, unlike in Example 2, the Relying Party can use the Nonce to determine whether the Attestation Result is fresh by verifying that time(OP_r)-time(NR_r) < Threshold.
ただし、Example 2とは異なり、Relying PartyはNonceを使用して、time(OP_r) - time(NR_r) < Thresholdを検証することで、Attestation Resultが新しいかどうかを判断できます。
However, the Relying Party must still be careful not to allow continued use beyond the period for which it deems the Attestation Result to remain valid. Thus, if the Attestation Result sends a validity lifetime in terms of time(RX_v)-time(RG_v), then the Relying Party can check time(OP_r)-time(ER_r) < time(RX_v)-time(RG_v).
ただし、Relying Partyは、アテステーション結果が有効であると判断される期間を超えての継続使用を許可しないように注意する必要があります。したがって、アテステーション結果が時間（RX_v）-時間（RG_v）で有効期間を送信する場合、Relying Partyは時間（OP_r）-時間（ER_r）<時間（RX_v）-時間（RG_v）を確認できます。
The authors would like to thank the following people for their input:
著者は、次の人々に対して貢献を感謝したいと思います。
Joerg Borchert, Carsten Bormann, Nancy Cam-Winget, Guy Fedorkow, Jessica Fitzgerald-McKay, Thomas Fossati, Simon Frost, Andrew Guinn, Thomas Hardjano, Eliot Lear, Diego Lopez, Peter Loscocco, Laurence Lundblade, Giri Mandyam, Daniel Migault, Kathleen Moriarty, Paul Rowe, Hannes Tschofenig, Eric Voit, Monty Wiseman, David Wooten, and Liang Xia.
Joerg Borchert、Carsten Bormann、Nancy Cam-Winget、Guy Fedorkow、Jessica Fitzgerald-McKay、Thomas Fossati、Simon Frost、Andrew Guinn、Thomas Hardjano、Eliot Lear、Diego Lopez、Peter Loscocco、Laurence Lundblade、Giri Mandyam、Daniel Migault、Kathleen Moriarty、Paul Rowe、Hannes Tschofenig、Eric Voit、Monty Wiseman、David Wooten、およびLiang Xia。
Thomas Hardjono created initial versions of the terminology section in collaboration with Ned Smith. Eric Voit provided the conceptual separation between Attestation Provision Flows and Attestation Evidence Flows. Monty Wisemen was a key author of a document that was merged to create this document. Carsten Bormann provided many of the motivational building blocks with respect to the Internet Threat Model.
トーマス・ハルジョノは、ネッド・スミスと協力して用語セクションの初期バージョンを作成しました。エリック・ヴォイトは、証明提供フローと証明エビデンスフローの概念的な分離を提供しました。モンティ・ワイズマンは、この文書を作成するために統合された文書の主要な著者でした。カーステン・ボルマンは、インターネット脅威モデルに関する多くの動機付けの基盤を提供しました。
Peter Loscocco contributed critical review feedback as part of the weekly design team meetings that added precision and depth to several sections.
ピーター・ロスコッコは、週次のデザインチームミーティングの一環として、複数のセクションに精度と深さを加えるための重要なレビューフィードバックを提供しました。
Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@sit.fraunhofer.de
Dave Thaler
Microsoft
United States of America
Email: dthaler@microsoft.com
Michael Richardson
Sandelman Software Works
Canada
Email: mcr+ietf@sandelman.ca
Ned Smith
Intel Corporation
United States of America
Email: ned.smith@intel.com
Wei Pan
Huawei Technologies
Email: william.panwei@huawei.com