[要約] RFC 9397は、信頼できる実行環境（TEE）のプロビジョニングに関するアーキテクチャを定義します。その目的は、安全な方法でTEEアプリケーションを管理・配布するためのフレームワークを提供することです。このアーキテクチャは、スマートフォンや組み込みデバイスなど、セキュリティが重要な環境での利用が想定されています。
Internet Engineering Task Force (IETF) M. Pei
Request for Comments: 9397 Broadcom
Category: Informational H. Tschofenig
ISSN: 2070-1721
D. Thaler
Microsoft
D. Wheeler
Amazon
July 2023
A Trusted Execution Environment (TEE) is an environment that enforces the following: any code within the environment cannot be tampered with, and any data used by such code cannot be read or tampered with by any code outside the environment. This architecture document discusses the motivation for designing and standardizing a protocol for managing the lifecycle of Trusted Applications running inside such a TEE.
信頼された実行環境（TEE）は、次のことを強制する環境です：環境内のコードは改ざんできず、そのようなコードで使用されるデータは環境外のコードによって読まれたり改ざんされたりすることはありません。このアーキテクチャ文書では、そのようなTEE内で実行される信頼されたアプリケーションのライフサイクルを管理するためのプロトコルを設計および標準化する動機について議論しています。
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/rfc9397.
このドキュメントの現在の状況、誤り、およびフィードバックの方法に関する情報は、https://www.rfc-editor.org/info/rfc9397 で入手できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）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. Terminology
3. Use Cases
3.1. Payment
3.2. Authentication
3.3. Internet of Things
3.4. Confidential Cloud Computing
4. Architecture
4.1. System Components
4.2. Multiple TEEs in a Device
4.3. Multiple TAMs and Relationship to TAs
4.4. Untrusted Apps, Trusted Apps, and Personalization Data
4.4.1. Example: Application Delivery Mechanisms in Intel SGX
4.4.2. Example: Application Delivery Mechanisms in Arm
TrustZone
4.5. Entity Relations
5. Keys and Certificate Types
5.1. Trust Anchors in a TEEP Agent
5.2. Trust Anchors in a TEE
5.3. Trust Anchors in a TAM
5.4. Scalability
5.5. Message Security
6. TEEP Broker
6.1. Role of the TEEP Broker
6.2. TEEP Broker Implementation Consideration
6.2.1. TEEP Broker APIs
6.2.2. TEEP Broker Distribution
7. Attestation
8. Algorithm and Attestation Agility
9. Security Considerations
9.1. Broker Trust Model
9.2. Data Protection
9.3. Compromised REE
9.4. CA Compromise or Expiry of CA Certificate
9.5. Compromised TAM
9.6. Malicious TA Removal
9.7. TEE Certificate Expiry and Renewal
9.8. Keeping Secrets from the TAM
9.9. REE Privacy
10. IANA Considerations
11. Informative References
Acknowledgments
Contributors
Authors' Addresses
Applications executing in a device are exposed to many different attacks intended to compromise the execution of the application or reveal the data upon which those applications are operating. These attacks increase with the number of other applications on the device, with such other applications coming from potentially untrustworthy sources. The potential for attacks further increases with the complexity of features and applications on devices and the unintended interactions among those features and applications. The risk of attacks on a system increases as the sensitivity of the applications or data on the device increases. As an example, exposure of emails from a mail client is likely to be of concern to its owner, but a compromise of a banking application raises even greater concerns.
デバイスで実行されているアプリケーションは、アプリケーションの実行を妨害したり、アプリケーションが操作しているデータを明らかにすることを意図したさまざまな攻撃にさらされています。これらの攻撃は、デバイス上の他のアプリケーションの数が増えるにつれて増加し、その他のアプリケーションが潜在的に信頼できないソースから提供される場合があります。攻撃の可能性は、デバイス上の機能やアプリケーションの複雑さ、およびそれらの機能やアプリケーション間の意図しない相互作用が増加するにつれてさらに高まります。システムへの攻撃リスクは、デバイス上のアプリケーションやデータの感度が高まるにつれて増加します。たとえば、メールクライアントからのメールの露出は、所有者にとって懸念される可能性が高いですが、銀行アプリケーションの妥協はさらに大きな懸念を引き起こします。
The Trusted Execution Environment (TEE) concept is designed to let applications execute in a protected environment that enforces that any code within that environment cannot be tampered with and that any data used by such code cannot be read or tampered with by any code outside that environment, including by a commodity operating system (if present). In a system with multiple TEEs, this also means that code in one TEE cannot be read or tampered with by code in another TEE.
信頼された実行環境（TEE）のコンセプトは、アプリケーションが保護された環境で実行されるように設計されており、その環境内のコードが改ざんされないように強制し、そのコードで使用されるデータがその環境外のコードによって読まれたり改ざんされたりすることができないようにします。複数のTEEを持つシステムでは、これはまた、1つのTEE内のコードが他のTEE内のコードによって読まれたり改ざんされたりすることができないことを意味します。
This separation reduces the possibility of a successful attack on application components and the data contained inside the TEE. Typically, application components are chosen to execute inside a TEE because those application components perform security-sensitive operations or operate on sensitive data. An application component running inside a TEE is commonly referred to (e.g., in [GPTEE] and [OP-TEE]) as a Trusted Application (TA), while an application running outside any TEE, i.e., in the Rich Execution Environment (REE), is referred to as an Untrusted Application (UA). In the example of a banking application, code that relates to the authentication protocol could reside in a TA while the application logic including HTTP protocol parsing could be contained in the Untrusted Application. In addition, processing of credit card numbers or account balances could be done in a TA as it is sensitive data. The precise code split is ultimately a decision of the developer based on the assets the person wants to protect according to the threat model.
この分離により、アプリケーションコンポーネントやTEE内に含まれるデータへの攻撃の可能性が低減されます。通常、アプリケーションコンポーネントは、セキュリティに敏感な操作を実行するか、機密データを扱うためにTEE内で実行されるよう選択されます。TEE内で実行されるアプリケーションコンポーネントは、一般的に[GPTEE]や[OP-TEE]などで「信頼されたアプリケーション（TA）」と呼ばれ、TEE外で実行されるアプリケーション（リッチ実行環境（REE）内）は「信頼されていないアプリケーション（UA）」と呼ばれます。銀行アプリケーションの例では、認証プロトコルに関連するコードはTAに存在し、HTTPプロトコルの解析を含むアプリケーションロジックは信頼されていないアプリケーションに含まれる可能性があります。さらに、クレジットカード番号や口座残高の処理は、それが機密データであるため、TAで行われる可能性があります。正確なコードの分割は、最終的には開発者が脅威モデルに基づいて保護したい資産に応じて行う決定です。
TEEs are typically used in cases where software or data assets need to be protected from unauthorized access where threat actors may have physical or administrative access to a device. This situation arises, for example, in gaming consoles where anti-cheat protection is a concern, devices such as ATMs or IoT devices placed in locations where attackers might have physical access, cell phones or other devices used for mobile payments, and hosted cloud environments. Such environments can be thought of as hybrid devices where one user or administrator controls the REE and a different (remote) user or administrator controls a TEE in the same physical device. In some constrained devices, it may also be the case that there is no REE (only a TEE) and no local "user" per se, but only a remote TEE administrator. For further discussion of such confidential computing use cases and threat model, see [CC-Overview] and [CC-Technical-Analysis].
TEEs は、ソフトウェアやデータ資産を不正アクセスから保護する必要がある場合に通常使用されます。脅威行為者がデバイスに物理的または管理的アクセスを持っている可能性がある場合です。このような状況は、たとえば、ゲーム機でアンチチート保護が懸念される場合、ATMや攻撃者が物理的アクセスを持つ可能性のある場所に配置されたIoTデバイス、モバイル決済に使用される携帯電話や他のデバイス、ホストされたクラウド環境などで発生します。このような環境は、1つのユーザーまたは管理者がREEを制御し、異なる（リモート）ユーザーまたは管理者が同じ物理デバイス内のTEEを制御するハイブリッドデバイスと考えることができます。制約のあるデバイスでは、REE（TEEのみ）がない場合や、ローカルの「ユーザー」そのものがなく、リモートTEE管理者のみが存在する場合もあります。このような機密コンピューティングの使用事例や脅威モデルについてのさらなる議論については、[CC-Overview] および [CC-Technical-Analysis] を参照してください。
TEEs use hardware enforcement combined with software protection to secure TAs and their data. TEEs typically offer a more limited set of services to TAs than what is normally available to Untrusted Applications.
TEEsは、TAとそのデータを保護するためにハードウェア強制とソフトウェア保護を組み合わせて使用します。 TEEsは通常、Untrusted Applicationsに通常利用可能なサービスよりも、TAに対してより限られたサービスを提供します。
However, not all TEEs are the same. Different vendors may have different implementations of TEEs with different security properties, features, and control mechanisms to operate on TAs. Some vendors may market multiple different TEEs themselves, with different properties attuned to different markets. A device vendor may integrate one or more TEEs into their devices depending on market needs.
ただし、すべてのTEEが同じというわけではありません。異なるベンダーは、異なるセキュリティプロパティ、機能、およびTAで動作するための制御メカニズムを持つTEEの異なる実装を持っているかもしれません。一部のベンダーは、異なる市場に合わせた異なるプロパティを持つ複数のTEEを自社で販売するかもしれません。デバイスベンダーは、市場のニーズに応じて1つ以上のTEEをデバイスに統合することがあります。
To simplify the life of TA developers interacting with TAs in a TEE, an interoperable protocol for managing TAs running in different TEEs of various devices is needed. This software update protocol needs to make sure that compatible trusted and Untrusted Components (if any) of an application are installed on the correct device. In this TEE ecosystem, the need often arises for an external trusted party to verify the identity, claims, and permissions of TA developers, devices, and their TEEs. This external trusted party is the Trusted Application Manager (TAM).
TA 開発者が TEE で TA とやり取りする際に生活を簡素化するために、さまざまなデバイスの異なる TEE で実行されている TA を管理するための相互運用可能なプロトコルが必要です。このソフトウェア更新プロトコルは、アプリケーションの互換性のある信頼できるコンポーネントと非信頼できるコンポーネント（ある場合）が正しいデバイスにインストールされていることを確認する必要があります。この TEE エコシステムでは、TA 開発者、デバイス、およびそれらの TEE のアイデンティティ、クレーム、および権限を外部の信頼できる第三者が検証する必要がしばしば生じます。この外部の信頼できる第三者は、Trusted Application Manager（TAM）です。
The Trusted Execution Environment Provisioning (TEEP) protocol addresses the following problems:
信頼された実行環境プロビジョニング（TEEP）プロトコルは、以下の問題に対処します。
* An installer of an Untrusted Application that depends on a given TA wants to request installation of that TA in the device's TEE so that the installation of the Untrusted Application can complete, but the TEE needs to verify whether such a TA is actually authorized to run in the TEE and consume potentially scarce TEE resources.
* 信頼できないアプリケーションのインストーラーは、指定されたTAに依存するアプリケーションのインストールをリクエストしたいと考えています。そのために、信頼できないアプリケーションのインストールを完了させるために、TEE内にそのTAをインストールするようにリクエストします。しかし、TEEはそのようなTAが実際にTEE内で実行されることが許可されているかどうかを検証し、潜在的に限られたTEEリソースを消費するかどうかを確認する必要があります。
* A TA developer providing a TA whose code itself is considered confidential wants to determine security-relevant information of a device before allowing their TA to be provisioned to the TEE within the device. An example is the verification of the type of TEE included in a device and its capability of providing the security protections required.
* TAの開発者は、コード自体が機密情報と見なされるTAを提供しており、そのTAをデバイス内のTEEにプロビジョニングする前に、デバイスのセキュリティに関連する情報を特定したいと考えています。デバイスに含まれるTEEの種類や、必要なセキュリティ保護を提供できる能力の検証がその例です。
* A TEE in a device needs to determine whether an entity that wants to manage a TA in the device is authorized to manage TAs in the TEE and what TAs the entity is permitted to manage.
* デバイス内のTEEにあるTEEが、デバイス内のTAを管理したいエンティティが、TEE内のTAを管理する権限があるかどうか、およびエンティティが管理を許可されているTAを決定する必要があります。
* A Device Administrator wants to determine if a TA exists on a device (i.e., is installed in the TEE) and, if not, install the TA in the TEE.
* デバイス管理者は、デバイスにTAが存在するかどうかを判断し（つまり、TEEにインストールされているかどうかを判断し）、存在しない場合はTEEにTAをインストールします。
* A Device Administrator wants to check whether a TA in a device's TEE is the most up-to-date version, and if not, update the TA in the TEE.
* デバイス管理者は、デバイスのTEE内のTAが最新バージョンかどうかを確認し、最新でない場合はTEE内のTAを更新したいと考えています。
* A Device Administrator wants to remove a TA from a device's TEE if the TA developer is no longer maintaining that TA, when the TA has been revoked, or if the TA is not used for other reasons (e.g., due to an expired subscription).
* デバイス管理者は、TAの開発者がそのTAを保守していない場合、TAが取り消された場合、またはTAが他の理由（たとえば、有効期限が切れたため）で使用されていない場合に、デバイスのTEEからTAを削除したいと考えています。
For TEEs that simply verify and load signed TAs from an untrusted filesystem, classic application distribution protocols can be used without modification. On the other hand, the problems listed in the bullets above require a new protocol -- the TEEP protocol. The TEEP protocol is a solution for TEEs that can install and enumerate TAs in a TEE-secured location where another domain-specific protocol standard (e.g., [GSMA] and [OTRP]) that meets the needs is not already in use.
TEEが単に署名されたTAを検証して読み込む場合、信頼できないファイルシステムから、従来のアプリケーション配布プロトコルを変更せずに使用できます。一方、上記の箇条書きにリストされた問題は、新しいプロトコルであるTEEPプロトコルが必要です。TEEPプロトコルは、他のドメイン固有のプロトコル標準（例：[GSMA]および[OTRP]）が既に使用されていないTEEで、TAをインストールおよび列挙できるようにするためのソリューションです。
The following terms are used:
次の用語が使用されています。
App Store:
App Store: アプリストア
An online location from which Untrusted Applications can be downloaded.
信頼できないアプリケーションをダウンロードできるオンラインの場所。
Device:
デバイス:
A physical piece of hardware that hosts one or more TEEs, often along with an REE.
1つ以上のTEEをホストする物理的なハードウェア、通常はREEと一緒に。
Device Administrator:
デバイス管理者:
An entity that is responsible for administration of a device, which could be the Device Owner. A Device Administrator has privileges on the device to install and remove Untrusted Applications and TAs, approve or reject Trust Anchors, and approve or reject TA developers, among other possible privileges on the device. A Device Administrator can manage the list of allowed TAMs by modifying the list of Trust Anchors on the device. Although a Device Administrator may have privileges and device-specific controls to locally administer a device, the Device Administrator may choose to remotely administer a device through a TAM.
デバイスの管理を担当するエンティティであり、デバイス所有者である可能性があります。デバイス管理者は、信頼できないアプリケーションやTAをインストールおよび削除し、信頼アンカーを承認または拒否し、TA開発者を承認または拒否する権限を持っています。デバイス管理者は、デバイス上の信頼アンカーのリストを変更することで、許可されたTAMのリストを管理できます。デバイス管理者は、デバイスをローカルで管理するための権限やデバイス固有のコントロールを持っている場合がありますが、TAMを介してデバイスをリモートで管理することも選択できます。
Device Owner:
デバイス所有者:
A device is always owned by someone. In some cases, it is common for the (primary) device user to also own the device, making the device user/owner also the Device Administrator. In enterprise environments, it is more common for the enterprise to own the device and for any device user to have no or limited administration rights. In this case, the enterprise appoints a Device Administrator that is not the Device Owner.
デバイスは常に誰かに所有されています。場合によっては、（主要な）デバイスのユーザーがデバイスを所有していることが一般的であり、デバイスのユーザー/所有者がデバイス管理者でもあります。企業環境では、企業がデバイスを所有し、デバイスのユーザーが管理権限を持たないか、または制限されていることが一般的です。この場合、企業はデバイス所有者ではないデバイス管理者を任命します。
Device User:
デバイスユーザー:
A human being that uses a device. Many devices have a single device user. Some devices have a primary device user with other human beings as secondary device users (e.g., a parent allowing children to use their tablet or laptop). Other devices are not used by a human being; hence, they have no device user.
デバイスを使用する人間。多くのデバイスは1人のデバイスユーザーを持っています。一部のデバイスは、他の人間が副次的なデバイスユーザーとして主要なデバイスユーザーを持っています（例：親が子供にタブレットやノートパソコンを使用させる）。他のデバイスは人間によって使用されず、したがってデバイスユーザーはいません。
Personalization Data:
個人情報:
A set of configuration data that is specific to the device or user. The Personalization Data may depend on the type of TEE, a particular TEE instance, the TA, and even the user of the device. An example of Personalization Data might be a secret symmetric key used by a TA to communicate with some service.
デバイスやユーザーに固有の構成データのセット。パーソナライゼーションデータは、TEEのタイプ、特定のTEEインスタンス、TA、さらにはデバイスのユーザーに依存する場合があります。パーソナライゼーションデータの例としては、TAがあるサービスと通信するために使用する秘密の対称鍵が挙げられます。
Raw Public Key:
生の公開鍵:
A raw public key consists of only the algorithm identifier (type) of the key and the cryptographic public key material, such as the SubjectPublicKeyInfo structure of a PKIX certificate [RFC5280]. Other serialization formats that do not rely on ASN.1 may also be used.
生の公開鍵は、鍵のアルゴリズム識別子（タイプ）と暗号化された公開鍵素材のみで構成されており、PKIX証明書のSubjectPublicKeyInfo構造[RFC5280]などが含まれます。ASN.1に依存しない他のシリアル化形式も使用できます。
Rich Execution Environment (REE):
リッチ実行環境（REE）:
An environment that is provided and governed by a typical OS (e.g., Linux, Windows, Android, iOS), potentially in conjunction with other supporting operating systems and hypervisors; it is outside of the TEE(s) managed by the TEEP protocol. This environment and applications running on it are considered untrusted (or more precisely, less trusted than a TEE).
提供され、典型的なOS（例：Linux、Windows、Android、iOS）によって管理される環境。他のサポートOSやハイパーバイザーと連携する可能性があり、TEEPプロトコルによって管理されるTEEの外に位置します。この環境とその上で実行されるアプリケーションは信頼されていないと見なされます（正確には、TEEよりも信頼性が低いとされます）。
Trust Anchor:
信頼アンカー:
As defined in [RFC6024] and [RFC9019], 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, a raw public key, or other structure, as appropriate. It can be a non-root certificate when it is a certificate.
[RFC6024]および[RFC9019]で定義されているように、Trust Anchorは「公開鍵と関連データを介して権威あるエンティティを表します。公開鍵はデジタル署名を検証するために使用され、関連データはTrust Anchorが権威を持つ情報の種類を制限するために使用されます。」Trust Anchorは、証明書、生の公開鍵、または適切な場合には他の構造物であることがあります。証明書である場合、ルート証明書でないことがあります。
Trust Anchor Store:
信頼アンカーストア:
As defined in [RFC6024], a "trust anchor store is a set of one or more trust anchors stored in a device... A device may have more than one trust anchor store, each of which may be used by one or more applications." As noted in [RFC9019], "a trust anchor store must resist modification against unauthorized insertion, deletion, and modification."
[RFC6024] で定義されているように、"信頼アンカーストアは、デバイスに格納されている1つ以上の信頼アンカーのセットです... デバイスには1つ以上の信頼アンカーストアがある場合があり、それぞれが1つ以上のアプリケーションによって使用される可能性があります。" [RFC9019] で指摘されているように、"信頼アンカーストアは、不正な挿入、削除、および変更に対して変更に耐える必要があります。"
Trusted Application (TA):
信頼されたアプリケーション（TA）:
An application (or, in some implementations, an application component) that runs in a TEE.
TEE で実行されるアプリケーション（または、一部の実装では、アプリケーションコンポーネント）。
Trusted Application Manager (TAM):
信頼されるアプリケーションマネージャ（TAM）:
An entity that manages Trusted Applications and other Trusted Components running in TEEs of various devices.
さまざまなデバイスのTEEで実行されている信頼されたアプリケーションや他の信頼されたコンポーネントを管理するエンティティ。
Trusted Component:
信頼できるコンポーネント:
A set of code and/or data in a TEE managed as a unit by a Trusted Application Manager. Trusted Applications and Personalization Data are thus managed by being included in Trusted Components. Trusted OS code or trusted firmware can also be expressed as Trusted Components that a Trusted Component depends on.
信頼されたアプリケーションマネージャによって単位として管理されるTEE内のコードおよび/またはデータのセット。信頼されたアプリケーションと個人化データは、信頼されたコンポーネントに含まれることで管理されます。信頼されたOSコードや信頼されたファームウェアも、信頼されたコンポーネントが依存する信頼されたコンポーネントとして表現できます。
Trusted Component Developer:
信頼できるコンポーネント開発者:
An entity that develops one or more Trusted Components.
1つ以上の信頼できるコンポーネントを開発するエンティティ。
Trusted Component Signer:
信頼されるコンポーネント署名者:
An entity that signs a Trusted Component with a key that a TEE will trust. The signer might or might not be the same entity as the Trusted Component Developer. For example, a Trusted Component might be signed (or re-signed) by a Device Administrator if the TEE will only trust the Device Administrator. A Trusted Component might also be encrypted if the code is considered confidential, for example, when a developer wants to provide a TA without revealing its code to others.
信頼されたコンポーネントに署名するエンティティは、TEEが信頼するキーを使用します。署名者は、信頼されたコンポーネントの開発者と同じエンティティであるかもしれませんし、そうでないかもしれません。例えば、TEEがデバイス管理者のみを信頼する場合、信頼されたコンポーネントはデバイス管理者によって署名（または再署名）されるかもしれません。コードが機密と見なされる場合、例えば、開発者が他者にコードを公開せずにTAを提供したい場合、信頼されたコンポーネントは暗号化されるかもしれません。
Trusted Execution Environment (TEE):
信頼された実行環境（TEE）:
An execution environment that enforces that only authorized code can execute within the TEE and data used by that code cannot be read or tampered with by code outside the TEE. A TEE also generally has a unique device credential that cannot be cloned. There are multiple technologies that can be used to implement a TEE, and the level of security achieved varies accordingly. In addition, TEEs typically use an isolation mechanism between Trusted Applications to ensure that one TA cannot read, modify, or delete the data and code of another TA.
実行環境は、TEE内でのみ認可されたコードが実行され、そのコードによって使用されるデータがTEE外のコードによって読み取られたり改ざんされたりすることができないように強制する。TEEには一般的にクローンできない固有のデバイス認証情報もある。TEEを実装するために使用できる複数の技術があり、達成されるセキュリティレベルはそれに応じて異なる。さらに、TEEは通常、信頼されたアプリケーション間に隔離メカニズムを使用して、1つのTAが他のTAのデータやコードを読み取ったり変更したり削除したりすることを防ぐ。
Untrusted Application (UA):
信頼されていないアプリケーション（UA）:
An application running in an REE. An Untrusted Application might depend on one or more TAs.
REEで実行されているアプリケーション。信頼されていないアプリケーションは、1つ以上のTAに依存する可能性があります。
A payment application in a mobile device requires high security and trust in the hosting device. Payments initiated from a mobile device can use a Trusted Application to provide strong identification and proof of transaction.
モバイルデバイス上の支払いアプリケーションは、ホスティングデバイスに対する高いセキュリティと信頼が必要です。モバイルデバイスから開始される支払いは、信頼できるアプリケーションを使用して、強力な識別と取引の証拠を提供できます。
For a mobile payment application, some biometric identification information could also be stored in a TEE. The mobile payment application can use such information for unlocking the device and local identification of the user.
モバイル支払いアプリケーションでは、生体認証情報がTEEにも保存されることがあります。モバイル支払いアプリケーションは、そのような情報をデバイスのロック解除やユーザーのローカル識別に使用できます。
A trusted user interface (UI) may be used in a mobile device or point-of-sale device to prevent malicious software from stealing sensitive user input data. Such an implementation often relies on a TEE for providing access to peripherals, such as PIN input or a trusted display, so that the REE cannot observe or tamper with the user input or output.
信頼できるユーザーインターフェース（UI）は、悪意のあるソフトウェアが機密性の高いユーザー入力データを盗むのを防ぐために、モバイルデバイスやPOSデバイスで使用されることがあります。このような実装は、通常、TEEを利用して、PIN入力や信頼できるディスプレイなどの周辺機器へのアクセスを提供するため、REEがユーザーの入力や出力を観察したり改ざんしたりできないようにします。
For better security of authentication, a device may store its keys and cryptographic libraries inside a TEE, limiting access to cryptographic functions via a well-defined interface and thereby reducing access to keying material.
認証のセキュリティを向上させるために、デバイスはそのキーと暗号ライブラリを TEE 内に保存することがあります。これにより、暗号機能へのアクセスを厳密に定義されたインターフェースを介して制限し、鍵素材へのアクセスを減らすことができます。
Weak security in Internet of Things (IoT) devices has been posing threats to critical infrastructure, i.e., assets that are essential for the functioning of a society and economy. It is desirable that IoT devices can prevent malware from manipulating actuators (e.g., unlocking a door) or stealing or modifying sensitive data, such as authentication credentials in the device. A TEE can be one of the best ways to implement such IoT security functions. For example, [GPTEE] uses the term "trusted peripheral" to refer to such things being accessible only from the TEE, and this concept is used in some GlobalPlatform-compliant devices today.
インターネット・オブ・シングス（IoT）デバイスのセキュリティが弱いことは、社会や経済の機能に不可欠な資産である重要インフラに脅威をもたらしています。 IoTデバイスがマルウェアによるアクチュエーター（例：ドアの開錠）の操作や、認証情報などの機密データの盗難や改ざんを防ぐことが望ましいです。 TEEは、そのようなIoTセキュリティ機能を実装するための最良の方法の1つとなり得ます。 たとえば、[GPTEE]は、「信頼できるペリフェラル」という用語を使用して、TEEからのみアクセス可能なものを指し、このコンセプトは一部のGlobalPlatform準拠デバイスで今日使用されています。
A tenant can store sensitive data, such as customer details or credit card numbers, in a TEE in a cloud computing server such that only the tenant can access the data, which prevents the cloud hosting provider from accessing the data. A tenant can run TAs inside a server TEE for secure operation and enhanced data security. This provides benefits not only to tenants with better data security but also to cloud hosting providers for reduced liability and increased cloud adoption.
テナントは、顧客の詳細やクレジットカード番号などの機密データを、クラウドコンピューティングサーバー内のTEEに保存することができます。これにより、テナントだけがデータにアクセスできるため、クラウドホスティングプロバイダーがデータにアクセスすることを防ぐことができます。テナントは、サーバーTEE内でTAを実行することで、安全な運用とデータセキュリティを強化することができます。これにより、テナントだけでなく、クラウドホスティングプロバイダーも責任の軽減とクラウドの採用拡大にメリットがあります。
Figure 1 shows the main components in a typical device with an REE and a TEE. Full descriptions of components not previously defined are provided below. Interactions of all components are further explained in the following paragraphs.
図1は、典型的なデバイスに含まれる主要な部品を示しています。以前に定義されていない部品の詳細な説明は以下に提供されています。すべての部品の相互作用は、以下の段落でさらに説明されています。
+---------------------------------------------+
| Device | Trusted Component
| +--------+ | Signer
| +---------------+ | |--------------+ |
| | TEE-1 | | TEEP |-----------+ | |
| | +--------+ | +--| Broker | | | | +-------+ |
| | | TEEP | | | | |<-----+ | | +-->| |<-+
| | | Agent |<------+ | | | | | +-| TAM-1 |
| | +--------+ | | |<---+ | | +--->| | |<-+
| | | +--------+ | | | | +-------+ |
| | +----+ +----+ | | | | | TAM-2 | |
| +-->|TA-1| |TA-2| | +-------+ | | | +-------+ |
| | | | | | |<---------| UA-2 |--+ | | |
| | | +----+ +----+ | +-------+ | | | Device
| | +---------------+ | UA-1 | | | | Administrator
| | | | | | |
| +--------------------| |-----+ | |
| | |----------+ |
| +-------+ |
+---------------------------------------------+
Figure 1: Notional Architecture of TEEP
図1：TEEPの概念アーキテクチャ
Trusted Component Signer and Device Administrator:
信頼されたコンポーネント署名者およびデバイス管理者:
Trusted Component Signers and Device Administrators utilize the services of a TAM to manage TAs on devices. Trusted Component Signers do not directly interact with devices. Device Administrators may elect to use a TAM for remote administration of TAs instead of managing each device directly.
信頼できるコンポーネント署名者とデバイス管理者は、TAMを利用してデバイス上のTAを管理します。信頼できるコンポーネント署名者はデバイスと直接やり取りしません。デバイス管理者は、各デバイスを直接管理する代わりに、TAMを使用してTAをリモートで管理することを選択することができます。
Trusted Application Manager (TAM):
信頼されるアプリケーションマネージャ（TAM）:
A TAM is responsible for performing lifecycle management activity on Trusted Components on behalf of Trusted Component Signers and Device Administrators. This includes installation and deletion of Trusted Components and may include, for example, over-the-air updates to keep Trusted Components up-to-date and clean up when Trusted Components should be removed. TAMs may provide services that make it easier for Trusted Component Signers or Device Administrators to use the TAM's service to manage multiple devices, although that is not required of a TAM.
TAMは、信頼できるコンポーネントのライフサイクル管理活動を、信頼できるコンポーネントの署名者やデバイス管理者の代わりに行う責任があります。これには、信頼できるコンポーネントのインストールや削除が含まれ、例えば、信頼できるコンポーネントを最新の状態に保つためのオーバーザエアのアップデートや、信頼できるコンポーネントを削除すべき時にクリーンアップすることが含まれる場合があります。TAMは、信頼できるコンポーネントの署名者やデバイス管理者が複数のデバイスを管理するためにTAMのサービスを利用しやすくするサービスを提供することがありますが、TAMにはそのような義務はありません。
The TAM performs its management of Trusted Components on the device through interactions with a device's TEEP Broker, which relays messages between a TAM and a TEEP Agent running inside the TEE. TEEP authentication is performed between a TAM and a TEEP Agent.
TAMは、デバイス上の信頼できるコンポーネントの管理を、デバイスのTEEPブローカーとのやり取りを通じて行います。TEEPブローカーは、TAMとTEE内で実行されているTEEPエージェントとの間でメッセージを中継します。TEEP認証は、TAMとTEEPエージェントの間で行われます。
When the TEEP Agent runs in a user or enterprise device, network and application firewalls normally protect user and enterprise devices from arbitrary connections from external network entities. In such a deployment, a TAM outside that network might not be able to directly contact a TEEP Agent but needs to wait for the TEEP Broker to contact it. The architecture in Figure 1 accommodates this case as well as other less restrictive cases by leaving such details to an appropriate TEEP transport protocol (e.g., [TEEP-HTTP], though other transport protocols can be defined under the TEEP protocol for other cases).
TEEP エージェントがユーザーまたはエンタープライズデバイスで実行される場合、通常、ネットワークおよびアプリケーションファイアウォールは外部ネットワークエンティティからの任意の接続からユーザーおよびエンタープライズデバイスを保護します。このような展開では、そのネットワーク外の TAM は TEEP エージェントに直接連絡することができないかもしれませんが、TEEP ブローカーがそれに連絡するのを待つ必要があります。図1のアーキテクチャは、このケースだけでなく、他のより制限の少ないケースも適切な TEEP トランスポートプロトコル（たとえば、[TEEP-HTTP]、他のケースには TEEP プロトコルの下で他のトランスポートプロトコルを定義できます）にその詳細を残すことで対応しています。
A TAM may be publicly available for use by many Trusted Component Signers, or a TAM may be private and accessible by only one or a limited number of Trusted Component Signers. It is expected that many enterprises, manufacturers, and network carriers will run their own private TAM.
TAMは多くの信頼できるコンポーネント署名者によって使用可能な場合もありますし、TAMは1人または限られた数の信頼できるコンポーネント署名者にのみアクセス可能なプライベートな場合もあります。多くの企業、製造業者、およびネットワークキャリアが独自のプライベートTAMを運用することが期待されています。
A Trusted Component Signer or Device Administrator chooses a particular TAM based on whether the TAM is trusted by a device or set of devices. The TAM is trusted by a device if the TAM's public key is, or chains up to, an authorized Trust Anchor in the device and conforms with all constraints defined in the Trust Anchor. A Trusted Component Signer or Device Administrator may run their own TAM, but the devices they wish to manage must include this TAM's public key or certificate, or a certificate it chains up to, in the Trust Anchor Store.
信頼できるコンポーネント署名者またはデバイス管理者は、特定のTAMを選択します。その選択は、そのTAMがデバイスまたはデバイスセットによって信頼されているかどうかに基づいています。デバイスがTAMを信頼している場合、そのTAMの公開鍵が、またはその公開鍵がデバイス内の認可された信頼アンカーに連なっている場合、および信頼アンカーで定義されたすべての制約に準拠している場合です。信頼できるコンポーネント署名者またはデバイス管理者は、独自のTAMを実行することができますが、管理したいデバイスには、そのTAMの公開鍵または証明書、またはそれに連なる証明書が信頼アンカーストアに含まれている必要があります。
A Trusted Component Signer or Device Administrator is free to utilize multiple TAMs. This may be required for managing Trusted Components on multiple different types of devices from different manufacturers or mobile devices on different network carriers, since the Trust Anchor Store on these different devices may contain keys for different TAMs. To overcome this limitation, Device Administrator may be able to add their own TAM's public key or certificate, or a certificate it chains up to, to the Trust Anchor Store on all their devices.
信頼できるコンポーネント署名者またはデバイス管理者は、複数のTAMを利用することができます。これは、異なる製造元の異なる種類のデバイスや異なるネットワークキャリアのモバイルデバイス上で信頼できるコンポーネントを管理するために必要とされる場合があります。なぜなら、これらの異なるデバイスのTrust Anchor Storeには異なるTAMのキーが含まれている可能性があるからです。この制限を克服するために、デバイス管理者は、自分自身のTAMの公開鍵や証明書、またはそれに連なる証明書を、すべてのデバイスのTrust Anchor Storeに追加することができるかもしれません。
Any entity is free to operate a TAM. For a TAM to be successful, it must have its public key or certificate installed in a device's Trust Anchor Store. A TAM may set up a relationship with device manufacturers or network carriers to have them install the TAM's keys in their device's Trust Anchor Store. Alternatively, a TAM may publish its certificate and allow Device Administrators to install the TAM's certificate in their devices as an aftermarket action.
どんなエンティティもTAMを運営する自由があります。TAMが成功するためには、その公開鍵や証明書がデバイスの信頼アンカーストアにインストールされている必要があります。TAMは、デバイスメーカーやネットワークキャリアと関係を構築して、彼らにTAMの鍵をデバイスの信頼アンカーストアにインストールさせることができます。また、TAMは自身の証明書を公開し、デバイス管理者がその証明書をデバイスにアフターマーケットのアクションとしてインストールすることもできます。
TEEP Broker:
TEEPブローカー
A TEEP Broker is an application component running in a Rich Execution Environment (REE) that enables the message protocol exchange between a TAM and a TEE in a device. A TEEP Broker does not process messages on behalf of a TEE but is merely responsible for relaying messages from the TAM to the TEE and for returning the TEE's responses to the TAM. In devices with no REE (e.g., a microcontroller where all code runs in an environment that meets the definition of a Trusted Execution Environment in Section 2), the TEEP Broker would be absent, and the TEEP protocol transport would be implemented inside the TEE itself.
TEEPブローカーは、デバイス内のTAMとTEEの間でメッセージプロトコルの交換を可能にする、リッチ実行環境（REE）で実行されるアプリケーションコンポーネントです。TEEPブローカーはTEEの代わりにメッセージを処理することはありませんが、TAMからTEEへのメッセージの中継およびTEEの応答をTAMに返す責任があります。REEがないデバイス（例：すべてのコードが信頼実行環境の定義を満たす環境で実行されるマイクロコントローラなど）では、TEEPブローカーは存在せず、TEEPプロトコルトランスポートはTEE自体内で実装されます。
TEEP Agent:
TEEP エージェント
The TEEP Agent is a processing module running inside a TEE that receives TAM requests (typically relayed via a TEEP Broker that runs in an REE). A TEEP Agent in the TEE may parse or forward requests to other processing modules in a TEE, which is up to a TEE provider's implementation. A response message corresponding to a TAM request is sent back to the TAM, again typically relayed via a TEEP Broker.
TEEPエージェントは、通常はREEで実行されるTEEPブローカーを介して中継されるTAMリクエストを受信するTEE内で実行される処理モジュールです。 TEE内のTEEPエージェントは、TEE内の他の処理モジュールにリクエストを解析または転送することができますが、これはTEEプロバイダーの実装によります。 TAMリクエストに対応する応答メッセージは、通常は再びTEEPブローカーを介してTAMに送信されます。
Certification Authority (CA):
認証機関（CA）
A CA is an entity that issues digital certificates (especially X.509 certificates) and vouches for the binding between the data items in a certificate [RFC4949]. Certificates are then used for authenticating a device, a TAM, or a Trusted Component Signer, as discussed in Section 5. The CAs do not need to be the same; different CAs can be chosen by each TAM, and different device CAs can be used by different device manufacturers.
CAは、デジタル証明書（特にX.509証明書）を発行し、証明書内のデータ項目間のバインディングを保証するエンティティです[RFC4949]。その後、証明書は、デバイス、TAM、または信頼できるコンポーネントサイナーの認証に使用されます（セクション5で説明）。CAは同じである必要はありません。各TAMは異なるCAを選択でき、異なるデバイスメーカーは異なるデバイスCAを使用できます。
Some devices might implement multiple TEEs. In these cases, there might be one shared TEEP Broker that interacts with all the TEEs in the device. However, some TEEs (for example, SGX [SGX]) present themselves as separate containers within memory without a controlling manager within the TEE. As such, there might be multiple TEEP Brokers in the REE, where each TEEP Broker communicates with one or more TEEs associated with it.
いくつかのデバイスは複数のTEEを実装する場合があります。これらの場合、デバイス内のすべてのTEEとやり取りする1つの共有TEEPブローカーが存在するかもしれません。ただし、一部のTEE（たとえば、SGX [SGX]）は、TEE内に制御マネージャーなしでメモリ内の別々のコンテナとして表現されます。そのため、REEには複数のTEEPブローカーが存在し、各TEEPブローカーがそれに関連する1つ以上のTEEと通信する可能性があります。
It is up to the REE and the Untrusted Applications how they select the correct TEEP Broker. Verification that the correct TA has been reached then becomes a matter of properly verifying TA attestations, which are unforgeable.
REEと信頼できないアプリケーションが正しいTEEPブローカーを選択する方法は、それぞれに委ねられています。正しいTAに到達したことを確認するためには、TAの証明書を適切に検証する必要があります。これらの証明書は偽造不可能です。
The multiple TEEP Broker approach is shown in the diagram below. For brevity, TEEP Broker 2 is shown interacting with only one TAM, Untrusted Application, and TEE, but no such limitations are intended to be implied in the architecture.
以下の図には、複数のTEEPブローカーアプローチが示されています。簡潔にするため、TEEPブローカー2は1つのTAM、信頼できないアプリケーション、およびTEEとのやり取りが示されていますが、このアーキテクチャにはそのような制限が意図されているわけではありません。
+-------------------------------------------+
| Device | Trusted Component
| | Signer
| +---------------+ | |
| | TEE-1 | | |
| | +-------+ | +--------+ | +--------+ |
| | | TEEP | | | TEEP |------------->| |<-+
| | | Agent |<----------| Broker | | | | TA
| | | 1 | | | 1 |---------+ | |
| | +-------+ | | | | | | |
| | | | |<---+ | | | |
| | +----+ +----+ | | | | | | +-| TAM-1 | Policy
| | |TA-1| |TA-2| | | |<-+ | | +->| | |<-+
| +-->| | | |<---+ +--------+ | | | | +--------+ |
| | | +----+ +----+ | | | | | | TAM-2 | |
| | | | | +-------+ | | | +--------+ |
| | +---------------+ +---| UA-2 |--+ | | ^ |
| | +-------+ | | | | Device
| +--------------------| UA-1 | | | | | Administrator
| +------| | | | | |
| +-----------|---+ | |---+ | | |
| | TEE-2 | | | |--------+ | |
| | +------+ | | | |-------+ | |
| | | TEEP | | | +-------+ | | |
| | | Agent|<-------+ | | |
| | | 2 | | | | | | |
| | +------+ | | | | | |
| | | | | | | |
| | +----+ | | | | | |
| | |TA-3|<---+ | | +---------+ | | |
| | | | | | | TEEP |<-+ | |
| | +----+ | +---| Broker | | |
| | | | 2 |--------------+
| +---------------+ +---------+ |
| |
+-------------------------------------------+
Figure 2: Notional Architecture of TEEP with multiple TEEs
図2：複数のTEEを備えたTEEPの概念アーキテクチャ
In the diagram above, TEEP Broker 1 controls interactions with the TAs in TEE-1, and TEEP Broker 2 controls interactions with the TAs in TEE-2. This presents some challenges for a TAM in completely managing the device, since a TAM may not interact with all the TEEP Brokers on a particular platform. In addition, since TEEs may be physically separated, with wholly different resources, there may be no need for TEEP Brokers to share information on installed Trusted Components or resource usage.
上記の図では、TEEPブローカー1がTEE-1内のTAとのやり取りを制御し、TEEPブローカー2がTEE-2内のTAとのやり取りを制御しています。これは、特定のプラットフォーム上のすべてのTEEPブローカーとやり取りすることができないため、TAMがデバイスを完全に管理する際にいくつかの課題が生じます。さらに、TEEsが物理的に分離されている可能性があり、完全に異なるリソースを持っているため、TEEPブローカーがインストールされた信頼できるコンポーネントやリソースの使用状況について情報を共有する必要がない場合があります。
As shown in Figure 2, a TEEP Broker provides communication between one or more TEEP Agents and one or more TAMs. The selection of which TAM to interact with might be made with or without input from an Untrusted Application but is ultimately the decision of a TEEP Agent.
図2に示すように、TEEPブローカーは1つ以上のTEEPエージェントと1つ以上のTAMとの間の通信を提供します。どのTAMとやり取りするかの選択は、信頼できないアプリケーションからの入力を伴う場合も伴わない場合もありますが、最終的にはTEEPエージェントの決定です。
For any given Trusted Component, a TEEP Agent is assumed to be able to determine whether that Trusted Component is installed (or minimally, is running) in a TEE with which the TEEP Agent is associated.
TEEPエージェントは、関連付けられているTEE内でその信頼されたコンポーネントがインストールされているか（または最小限で実行されているか）を判断できると仮定されます。
Each Trusted Component is digitally signed, protecting its integrity and linking the Trusted Component back to the Trusted Component Signer. The Trusted Component Signer is often the Trusted Component Developer but, in some cases, might be another party such as a Device Administrator or other party to whom the code has been licensed (in which case, the same code might be signed by multiple licensees and distributed as if it were different TAs).
各信頼されたコンポーネントはデジタル署名されており、その完全性が保護され、信頼されたコンポーネントを信頼されたコンポーネントの署名者にリンクします。信頼されたコンポーネントの署名者は通常、信頼されたコンポーネントの開発者ですが、場合によっては、デバイス管理者やコードがライセンスされた他の当事者など、別の当事者であることがあります（その場合、同じコードが複数のライセンス保持者によって署名され、異なるTAであるかのように配布される可能性があります）。
A Trusted Component Signer selects one or more TAMs and communicates the Trusted Component(s) to the TAM. For example, the Trusted Component Signer might choose TAMs based upon the markets into which the TAM can provide access. There may be TAMs that provide services to specific types of devices, device operating systems, specific geographical regions, or network carriers. A Trusted Component Signer may be motivated to utilize multiple TAMs in order to maximize market penetration and availability on multiple types of devices. This means that the same Trusted Component will often be available through multiple TAMs.
信頼できるコンポーネント署名者は、1つ以上のTAMを選択し、信頼できるコンポーネントをTAMに通知します。たとえば、信頼できるコンポーネント署名者は、TAMがアクセスを提供できる市場に基づいてTAMを選択するかもしれません。特定の種類のデバイス、デバイスのオペレーティングシステム、特定の地理的地域、またはネットワークキャリアにサービスを提供するTAMがあるかもしれません。信頼できるコンポーネント署名者は、市場浸透と複数の種類のデバイスでの利用可能性を最大化するために複数のTAMを利用する動機があるかもしれません。これは、同じ信頼できるコンポーネントがしばしば複数のTAMを通じて利用可能であることを意味します。
When the developer of an Untrusted Application that depends on a Trusted Component publishes the Untrusted Application to an app store or other app repository, the developer optionally binds the Untrusted Application with a manifest that identifies what TAMs can be contacted for the Trusted Component. In some situations, a Trusted Component may only be available via a single TAM; this is likely the case for enterprise applications or Trusted Component Signers serving a closed community. For broad public apps, there will likely be multiple TAMs in the Untrusted Application's manifest, one servicing one brand of mobile device and another servicing a different manufacturer, etc. Because different devices and manufacturers trust different TAMs, the manifest can include multiple TAMs that support the required Trusted Component.
信頼できるコンポーネントに依存する信頼できないアプリケーションの開発者が、信頼できるコンポーネントに依存する信頼できないアプリケーションをアプリストアやその他のアプリリポジトリに公開する際、開発者はオプションで、信頼できるコンポーネントに連絡するためのTAM（信頼されるアプリケーションモジュール）を特定するマニフェストと結びつけることができます。いくつかの状況では、信頼できるコンポーネントは単一のTAMを介してのみ利用可能である場合があります。これは、企業向けアプリケーションや閉鎖的なコミュニティを対象とする信頼できるコンポーネントの署名者の場合に起こり得ます。一般向けのアプリケーションの場合、信頼できないアプリケーションのマニフェストには、おそらく複数のTAMが含まれるでしょう。1つは特定のモバイルデバイスのブランドをサポートし、もう1つは異なるメーカーをサポートするなど、異なるデバイスやメーカーが異なるTAMを信頼しているため、必要な信頼できるコンポーネントをサポートする複数のTAMがマニフェストに含まれる可能性があります。
When a TEEP Broker receives a request (see the RequestTA API in Section 6.2.1) from an Untrusted Application to install a Trusted Component, a list of TAM URIs may be provided for that Trusted Component, and the request is passed to the TEEP Agent. If the TEEP Agent decides that the Trusted Component needs to be installed, the TEEP Agent selects a single TAM URI that is consistent with the list of trusted TAMs provisioned in the TEEP Agent, invokes the HTTP transport for TEEP to connect to the TAM URI, and begins a TEEP protocol exchange. When the TEEP Agent subsequently receives the Trusted Component to install and the Trusted Component's manifest indicates dependencies on any other Trusted Components, each dependency can include a list of TAM URIs for the relevant dependency. If such dependencies exist that are prerequisites to install the Trusted Component, then the TEEP Agent recursively follows the same procedure for each dependency that needs to be installed or updated, including selecting a TAM URI that is consistent with the list of trusted TAMs provisioned on the device and beginning a TEEP exchange. If multiple TAM URIs are considered trusted, only one needs to be contacted, and they can be attempted in some order until one responds.
TEEPブローカーが信頼できないアプリケーションから信頼できるコンポーネントをインストールするリクエスト（セクション6.2.1のRequestTA APIを参照）を受け取った場合、その信頼できるコンポーネントのためにTAM URIのリストが提供されることがあり、そのリクエストはTEEPエージェントに渡されます。TEEPエージェントが信頼できるコンポーネントをインストールする必要があると判断した場合、TEEPエージェントはTEEPエージェントにプロビジョニングされた信頼できるTAMのリストと一致する単一のTAM URIを選択し、TEEPがTAM URIに接続するためのHTTPトランスポートを呼び出し、TEEPプロトコルの交換を開始します。その後、TEEPエージェントがインストールする信頼できるコンポーネントとそのマニフェストが他の信頼できるコンポーネントに依存していることを示す場合、各依存関係には関連する依存関係のためのTAM URIのリストが含まれることがあります。信頼できるコンポーネントをインストールするための前提条件となる依存関係が存在する場合、TEEPエージェントは、インストールまたは更新する必要がある各依存関係に対して同じ手順を再帰的に実行し、デバイスにプロビジョニングされた信頼できるTAMのリストと一致するTAM URIを選択し、TEEP交換を開始します。複数のTAM URIが信頼されると考えられる場合、1つだけ連絡する必要があり、1つが応答するまでいくつかの順序で試行できます。
Separate from the Untrusted Application's manifest, this framework relies on the use of the manifest format in [SUIT-MANIFEST] for expressing how to install a Trusted Component, as well as any dependencies on other TEE components and versions. That is, dependencies from Trusted Components on other Trusted Components can be expressed in a Software Update for the Internet of Things (SUIT) manifest, including dependencies on any other TAs, trusted OS code (if any), or trusted firmware. Installation steps can also be expressed in a SUIT manifest.
このフレームワークは、信頼できないアプリケーションのマニフェストとは別に、信頼できるコンポーネントのインストール方法や他のTEEコンポーネントやバージョンへの依存関係を表現するために、[SUIT-MANIFEST]のマニフェスト形式を使用しています。つまり、信頼できるコンポーネントが他の信頼できるコンポーネントに依存する場合、その依存関係は、インターネット・オブ・シングス（IoT）のためのソフトウェア・アップデート（SUIT）マニフェストで表現することができます。また、インストール手順もSUITマニフェストで表現することができます。
For example, TEEs compliant with GlobalPlatform [GPTEE] may have a notion of a "security domain" (which is a grouping of one or more TAs installed on a device that can share information within such a group) that must be created and into which one or more TAs can then be installed. It is thus up to the SUIT manifest to express a dependency on having such a security domain existing or being created first, as appropriate.
例えば、GlobalPlatform [GPTEE]に準拠したTEEは、「セキュリティドメイン」という概念を持つ場合があります（これはデバイスにインストールされた1つ以上のTAをグループ化し、そのグループ内で情報を共有できるものです）。そのため、SUITマニフェストが、そのようなセキュリティドメインが既存しているか、適切に作成されているかに依存することを表現することができます。
Updating a Trusted Component may cause compatibility issues with any Untrusted Applications or other components that depend on the updated Trusted Component, just like updating the OS or a shared library could impact an Untrusted Application. Thus, an implementation needs to take such issues into account.
信頼されたコンポーネントを更新すると、更新された信頼されたコンポーネントに依存する信頼されていないアプリケーションや他のコンポーネントとの互換性の問題が発生する可能性があります。これは、OSや共有ライブラリを更新することが信頼されていないアプリケーションに影響を与える可能性があるのと同様です。したがって、実装する際にはこのような問題を考慮する必要があります。
In TEEP, there is an explicit relationship and dependence between an Untrusted Application in an REE and one or more TAs in a TEE, as shown in Figure 2. For most purposes, an Untrusted Application that uses one or more TAs in a TEE appears no different from any other Untrusted Application in the REE. However, the way the Untrusted Application and its corresponding TAs are packaged, delivered, and installed on the device can vary. The variations depend on whether the Untrusted Application and TA are bundled together or provided separately, and this has implications to the management of the TAs in a TEE. In addition to the Untrusted Application and TA(s), the TA(s) and/or TEE may also require additional data to personalize the TA to the device or a user. Implementations of the TEEP protocol must support encryption to preserve the confidentiality of such Personalization Data, which may potentially contain sensitive data. The encryption is used to ensure that no personalization data is sent in the clear. Implementations must also support mechanisms for integrity protection of such Personalization Data. Other than the requirement to support confidentiality and integrity protection, the TEEP architecture places no limitations or requirements on the Personalization Data.
TEEPでは、REE内の信頼できないアプリケーションとTEE内の1つ以上のTAとの明示的な関係と依存関係があります。図2に示されているように、TEE内の1つ以上のTAを使用する信頼できないアプリケーションは、ほとんどの目的において、REE内の他の信頼できないアプリケーションとは異ならないように見えます。ただし、信頼できないアプリケーションと対応するTAがパッケージ化、配信、およびデバイスにインストールされる方法は異なる場合があります。変化は、信頼できないアプリケーションとTAが一緒にバンドルされるか、別々に提供されるかに依存し、これはTEE内のTAの管理に影響を与えます。信頼できないアプリケーションとTA（たち）に加えて、TA（たち）やTEEには、デバイスやユーザーにTAを個別化するための追加データが必要な場合があります。 TEEPプロトコルの実装は、機密性を保持するために暗号化をサポートする必要があります。これには機密データが含まれる可能性がある個別化データが含まれます。暗号化は、個別化データが平文で送信されないようにするために使用されます。実装はまた、このような個別化データの整合性保護のメカニズムをサポートする必要があります。機密性と整合性保護をサポートする必要がある以外に、TEEPアーキテクチャは個別化データに対して制限や要件を課しません。
There are multiple possible cases for bundling of an Untrusted Application, TA(s), and Personalization Data. Such cases include (possibly among others):
信頼できないアプリケーション、TA（複数）、および個人化データのバンドル化には複数の可能なケースがあります。これらのケースには、（おそらく他にも）次のようなものが含まれます：
1. The Untrusted Application, TA(s), and Personalization Data are all bundled together in a single package by a Trusted Component Signer and either provided to the TEEP Broker through the TAM or provided separately (with encrypted Personalization Data), with key material needed to decrypt and install the Personalization Data and TA provided by a TAM.
1. 信頼されたコンポーネント署名者によって、信頼されていないアプリケーション（TA）、および個人化データはすべて1つのパッケージにまとめられ、TAMを介してTEEPブローカーに提供されるか、別途提供されます（暗号化された個人化データを含む）、TAMによって提供される個人化データとTAを解読およびインストールするために必要なキーマテリアル。
2. The Untrusted Application and the TA(s) are bundled together in a single package, which a TAM or a publicly accessible app store maintains, and the Personalization Data is separately provided by the Personalization Data provider's TAM.
2. 信頼されていないアプリケーションとTA（たち）は、TAMまたは一般にアクセス可能なアプリストアが管理し、パーソナライゼーションデータはパーソナライゼーションデータプロバイダーのTAMによって別々に提供されます。
3. All components are independent packages. The Untrusted Application is installed through some independent or device-specific mechanism, and one or more TAMs provide (directly or indirectly by reference) the TA(s) and Personalization Data.
3. すべてのコンポーネントは独立したパッケージです。信頼できないアプリケーションは、いくつかの独立したまたはデバイス固有のメカニズムを介してインストールされ、1つ以上のTAMがTA（または参照によって間接的に）と個人化データを提供します。
4. The TA(s) and Personalization Data are bundled together into a package provided by a TAM, while the Untrusted Application is installed through some independent or device-specific mechanism, such as an app store.
4. TA（たち）と個人化データは、TAMによって提供されるパッケージにまとめられますが、信頼できないアプリケーションは、独立したまたはデバイス固有のメカニズム、例えばアプリストアを介してインストールされます。
5. Encrypted Personalization Data is bundled into a package distributed with the Untrusted Application, while the TA(s) and key material needed to decrypt and install the Personalization Data are in a separate package provided by a TAM. Personalization Data is encrypted with a key unique to that specific TEE, as discussed in Section 5.
5. 暗号化された個人化データは、信頼できないアプリケーションと一緒に配布されるパッケージにバンドルされます。一方、個人化データを復号化してインストールするために必要なTA(s)およびキーマテリアルは、TAMによって提供される別のパッケージに含まれています。個人化データは、セクション5で議論されている特定のTEEに固有のキーで暗号化されています。
The TEEP protocol can treat each TA, any dependencies the TA has, and Personalization Data as separate Trusted Components with separate installation steps that are expressed in SUIT manifests, and a SUIT manifest might contain or reference multiple binaries (see [SUIT-MANIFEST] for more details). The TEEP Agent is responsible for handling any installation steps that need to be performed inside the TEE, such as decryption of private TA binaries or Personalization Data.
TEEPプロトコルは、各TA、TAが持つ依存関係、および個人化データを、SUITマニフェストで表現される別々のインストール手順を持つ別々の信頼されたコンポーネントとして扱うことができます。SUITマニフェストには、複数のバイナリが含まれるか、または参照される可能性があります（詳細については[SUIT-MANIFEST]を参照してください）。TEEPエージェントは、TEE内で実行する必要があるインストール手順を処理する責任があります。例えば、プライベートTAバイナリや個人化データの復号化などが該当します。
In order to better understand these cases, it is helpful to review actual implementations of TEEs and their application delivery mechanisms.
これらのケースをよりよく理解するためには、TEEの実際の実装とそのアプリケーション配信メカニズムを見直すことが役立ちます。
In Intel Software Guard Extensions (SGX), the Untrusted Application and TA are typically bundled into the same package (Case 2). The TA exists in the package as a shared library (.so or .dll). The Untrusted Application loads the TA into an SGX enclave when the Untrusted Application needs the TA. This organization makes it easy to maintain compatibility between the Untrusted Application and the TA, since they are updated together. It is entirely possible to create an Untrusted Application that loads an external TA into an SGX enclave and use that TA (Cases 3-5). In this case, the Untrusted Application would require a reference to an external file or download such a file dynamically, place the contents of the file into memory, and load that as a TA. Obviously, such file or downloaded content must be properly formatted and signed for it to be accepted by the SGX TEE.
Intel Software Guard Extensions（SGX）では、信頼されていないアプリケーションとTAは通常、同じパッケージにバンドルされます（ケース2）。 TAは、共有ライブラリ（.soまたは.dll）としてパッケージ内に存在します。 信頼されていないアプリケーションは、TAが必要になったときにTAをSGXエンクレーブにロードします。 この構成により、信頼されていないアプリケーションとTAの互換性を維持しやすくなります。なぜなら、それらは一緒に更新されるからです。 外部TAをSGXエンクレーブにロードし、そのTAを使用する信頼されていないアプリケーションを作成することは完全に可能です（ケース3-5）。 この場合、信頼されていないアプリケーションは、外部ファイルへの参照が必要であり、そのようなファイルを動的にダウンロードして、ファイルの内容をメモリに配置し、TAとしてロードする必要があります。 明らかに、そのようなファイルまたはダウンロードされたコンテンツは、SGX TEEによって受け入れられるために適切にフォーマットされ、署名されている必要があります。
In SGX, any Personalization Data is normally loaded into the SGX enclave (the TA) after the TA has started. Although it is possible with SGX to include the Untrusted Application in an encrypted package along with Personalization Data (Cases 1 and 5), there are currently no known instances of this in use, since such a construction would require a special installation program and SGX TA (which might or might not be the TEEP Agent itself based on the implementation) to receive the encrypted package, decrypt it, separate it into the different elements, and then install each one. This installation is complex because the Untrusted Application decrypted inside the TEE must be passed out of the TEE to an installer in the REE that would install the Untrusted Application. Finally, the Personalization Data would need to be sent out of the TEE (encrypted in an SGX enclave-to-enclave manner) to the REE's installation app, which would pass this data to the installed Untrusted Application, which would in turn send this data to the SGX enclave (TA). This complexity is due to the fact that each SGX enclave is separate and does not have direct communication to other SGX enclaves.
SGXでは、通常、TAが開始した後に個人化データがSGXエンクレーブ（TA）にロードされます。SGXでは、暗号化されたパッケージに信頼できないアプリケーションと個人化データを含めることが可能ですが（ケース1および5）、現時点ではそのような使用例は知られていません。なぜなら、そのような構成には特別なインストールプログラムとSGX TA（実装に基づいてTEEPエージェント自体であるかもしれない）が必要であり、暗号化されたパッケージを受け取り、復号化し、異なる要素に分割し、それぞれをインストールする必要があるからです。このインストールは複雑であり、TEE内で復号化された信頼できないアプリケーションは、TEEから外部のREEに渡され、REE内のインストーラーが信頼できないアプリケーションをインストールする必要があります。最後に、個人化データはTEEから外部に送信される必要があります（SGXエンクレーブ間で暗号化された方法で）、REEのインストールアプリケーションがこのデータをインストールされた信頼できないアプリケーションに渡し、そのデータをSGXエンクレーブ（TA）に送信します。この複雑さは、各SGXエンクレーブが分離されており、他のSGXエンクレーブと直接通信できないという事実に起因しています。
As long as signed files (TAs and/or Personalization Data) are installed into an untrusted filesystem and trust is verified by the TEE at load time, classic distribution mechanisms can be used. However, some uses of SGX allow a model where a TA can be dynamically installed into an SGX enclave that provides a runtime platform. The TEEP protocol can be used in such cases, where the runtime platform could include a TEEP Agent.
署名済みファイル（TAsおよび/またはパーソナライゼーションデータ）が信頼できないファイルシステムにインストールされ、信頼がロード時にTEEによって検証される限り、従来の配布メカニズムを使用できます。ただし、SGXの一部の使用法では、TAがランタイムプラットフォームを提供するSGXエンクレーブに動的にインストールされるモデルが可能です。このような場合には、TEEPプロトコルが使用でき、ランタイムプラットフォームにはTEEPエージェントが含まれる可能性があります。
In Arm TrustZone [TrustZone] for A-class devices, the Untrusted Application and TA may or may not be bundled together. This differs from SGX since in TrustZone, the TA lifetime is not inherently tied to a specific Untrusted Application process lifetime as occurs in SGX. A TA is loaded by a trusted OS running in the TEE, such as a TEE compliant with GlobalPlatform [GPTEE], where the trusted OS is separate from the OS in the REE. Thus, Cases 2-4 are equally applicable. In addition, it is possible for TAs to communicate with each other without involving any Untrusted Application; thus, the complexity of Cases 1 and 5 are lower than in the SGX example, though still more complex than Cases 2-4.
Arm TrustZone [TrustZone] for A-class devicesでは、Untrusted ApplicationとTAが一緒にバンドルされている場合とされていない場合があります。これはSGXと異なり、TrustZoneでは、TAの寿命はSGXで発生するように特定のUntrusted Applicationプロセスの寿命に固有に結びついていません。TAは、GPTEEに準拠したTEE内で実行される信頼できるOSによってロードされます。この信頼できるOSは、REE内のOSとは別個に存在します。そのため、Cases 2-4は同様に適用可能です。さらに、Untrusted Applicationを介さずにTA同士が通信することも可能です。そのため、Cases 1および5の複雑さはSGXの例よりも低くなりますが、Cases 2-4よりは複雑です。
A trusted OS running in the TEE (e.g., OP-TEE [OP-TEE]) that supports loading and verifying signed TAs from an untrusted filesystem can, like SGX, use classic file distribution mechanisms. If secure TA storage is used (e.g., a Replay-Protected Memory Block device) on the other hand, the TEEP protocol can be used to manage such storage.
信頼できるOSがTEEで実行され、署名付きTAを信頼できないファイルシステムから読み込んで検証することができる場合、SGXのように、古典的なファイル配布メカニズムを使用することができます。一方、安全なTAストレージ（たとえば、再生防止メモリブロックデバイス）が使用されている場合、TEEPプロトコルを使用してそのようなストレージを管理することができます。
This architecture leverages asymmetric cryptography to authenticate a device to a TAM. Additionally, a TEEP Agent in a device authenticates a TAM. The provisioning of Trust Anchors to a device may be different from one use case to the other. A Device Administrator may want to have the capability to control what TAs are allowed. A device manufacturer enables verification by one or more TAMs and by Trusted Component Signers; it may embed a list of default Trust Anchors into the TEEP Agent and TEE for TAM trust verification and TA signature verification.
このアーキテクチャは、非対称暗号を利用してデバイスをTAMに認証します。さらに、デバイス内のTEEPエージェントがTAMを認証します。デバイスへの信頼アンカーのプロビジョニングは、ユースケースによって異なる場合があります。デバイス管理者は、どのTAが許可されているかを制御する機能を持ちたい場合があります。デバイスメーカーは、1つ以上のTAMおよび信頼されたコンポーネントサイナーによる検証を可能にし、デフォルトの信頼アンカーのリストをTEEPエージェントとTEEに埋め込むことがあります。これにより、TAMの信頼検証とTAの署名検証が行われます。
(App Developers) (App Store) (TAM) (Device with TEE) (CAs)
| | | | |
| | | (Embedded TEE cert) <--|
| | | | |
| <--- Get an app cert -----------------------------------|
| | | | |
| | | <-- Get a TAM cert ---------|
| | | | |
1. Build two apps: | | | |
| | | |
(a) Untrusted | | | |
App - 2a. Supply --> | | | |
| | | |
(b) TA -- 2b. Supply ----------> | | |
| | | |
| --- 3. Install ------> | |
| | | |
| | 4. Messaging-->| |
Figure 3: Example Developer Experience
図3: 開発者体験の例
Figure 3 shows an example where the same developer builds and signs two applications: (a) an Untrusted Application and (b) a TA that provides some security functions to be run inside a TEE. This example assumes that the developer, the TEE, and the TAM have previously been provisioned with certificates.
図3は、同じ開発者が2つのアプリケーションをビルドして署名する例を示しています：(a) 信頼されていないアプリケーションと(b) TEE内で実行されるいくつかのセキュリティ機能を提供するTA。この例では、開発者、TEE、およびTAMが以前に証明書でプロビジョニングされていることを前提としています。
At step 1, the developer authors the two applications.
ステップ1では、開発者が2つのアプリケーションを作成します。
At step 2, the developer uploads the Untrusted Application (2a) to an Application Store. In this example, the developer is also the Trusted Component Signer and thus generates a signed TA. The developer can then either bundle the signed TA with the Untrusted Application or provide a signed Trusted Component containing the TA to a TAM that will be managing the TA in various devices.
ステップ2では、開発者が信頼できないアプリケーション（2a）をアプリケーションストアにアップロードします。この例では、開発者は信頼できるコンポーネントの署名者でもあり、署名付きのTAを生成します。開発者は、署名付きのTAを信頼できないアプリケーションとバンドルするか、TAを管理するTAMに提供するためにTAを含む署名済みの信頼できるコンポーネントを提供することができます。
At step 3, a user will go to an Application Store to download the Untrusted Application (where the arrow indicates the direction of data transfer).
ステップ3では、ユーザーはアプリケーションストアに移動して、信頼されていないアプリケーションをダウンロードします（矢印がデータ転送の方向を示しています）。
At step 4, since the Untrusted Application depends on the TA, installing the Untrusted Application will trigger TA installation via communication with a TAM. The TEEP Agent will interact with the TAM via a TEEP Broker that facilitates communications between the TAM and the TEEP Agent.
ステップ4では、Untrusted Application が TA に依存しているため、Untrusted Application のインストールは TAM との通信を介して TA のインストールをトリガーします。TEEP エージェントは、TAM とのやり取りを促進する TEEP ブローカーを介して TAM と通信します。
Some implementations that install Trusted Components might ask for a user's consent. In other implementations, a Device Administrator might choose the Untrusted Applications and related Trusted Components to be installed. A user consent flow is out of scope of the TEEP architecture.
信頼されたコンポーネントをインストールする一部の実装では、ユーザーの同意を求める場合があります。他の実装では、デバイス管理者がインストールされる信頼されていないアプリケーションと関連する信頼されたコンポーネントを選択することができます。ユーザーの同意フローは、TEEPアーキテクチャの範囲外です。
The main components of the TEEP protocol consist of a set of standard messages created by a TAM to deliver Trusted Component management commands to a device and device attestation and response messages created by a TEE that responds to a TAM's message.
TEEPプロトコルの主要なコンポーネントは、TAMによって作成された一連の標準メッセージで構成され、これらはデバイスに信頼されたコンポーネント管理コマンドを送信するためのものです。また、TEEによって作成されたデバイスの証明および応答メッセージも含まれており、これらはTAMのメッセージに応答するために使用されます。
It should be noted that network communication capability is generally not available in TAs in today's TEE-powered devices. Consequently, Trusted Applications generally rely on a Broker in the REE to provide access to network functionality in the REE. A Broker does not need to know the actual content of messages to facilitate such access.
現在のTEE搭載デバイスのTAには通常、ネットワーク通信機能が利用できないことに注意する必要があります。そのため、信頼されたアプリケーションは一般的に、REE内のブローカーに依存してREE内でのネットワーク機能へのアクセスを提供します。ブローカーは、そのようなアクセスを容易にするためにメッセージの実際の内容を知る必要はありません。
Similarly, since the TEEP Agent runs inside a TEE, the TEEP Agent generally relies on a TEEP Broker in the REE to provide network access, relay TAM requests to the TEEP Agent, and relay the responses back to the TAM.
同様に、TEEPエージェントはTEE内で実行されるため、通常、TEEPエージェントはREE内のTEEPブローカーにネットワークアクセスを提供し、TAMリクエストをTEEPエージェントに中継し、応答をTAMに中継することに依存しています。
This architecture leverages the following credentials, which allow achieving end-to-end security between a TAM and a TEEP Agent.
このアーキテクチャは、TAMとTEEPエージェントの間でエンドツーエンドのセキュリティを実現するために以下の資格情報を活用しています。
Table 1 summarizes the relationships between various keys and where they are stored. Each public/private key identifies a Trusted Component Signer, TAM, or TEE and gets a certificate that chains up to some Trust Anchor. A list of trusted certificates is used to check a presented certificate against.
Table 1は、さまざまなキーとそれらが保存されている場所との関係を要約しています。各公開/秘密キーは、信頼されたコンポーネントサイナー、TAM、またはTEEを識別し、いくつかの信頼アンカーにチェーンアップされた証明書を取得します。信頼された証明書のリストは、提示された証明書をチェックするために使用されます。
Different CAs can be used for different types of certificates. TEEP messages are always signed, where the signer key is the message originator's private key, such as that of a TAM or a TEE. In addition to the keys shown in Table 1, there may be additional keys used for attestation or encryption. Refer to the RATS Architecture [RFC9334] for more discussion.
異なるCAは異なる種類の証明書に使用できます。 TEEPメッセージは常に署名されており、署名者キーはメッセージの発信者の秘密キー、たとえばTAMやTEEのものです。表1に示されているキーに加えて、アテステーションや暗号化に使用される追加のキーがあるかもしれません。詳細については、RATSアーキテクチャ[RFC9334]を参照してください。
+================+===============+===========+==============+
| Purpose | Cardinality & | Private | Location of |
| | Location of | Key Signs | Trust Anchor |
| | Private Key | | Store |
+================+===============+===========+==============+
| Authenticating | 1 per TEE | TEEP | TAM |
| TEEP Agent | | responses | |
+----------------+---------------+-----------+--------------+
| Authenticating | 1 per TAM | TEEP | TEEP Agent |
| TAM | | requests | |
+----------------+---------------+-----------+--------------+
| Code Signing | 1 per Trusted | TA binary | TEE |
| | Component | | |
| | Signer | | |
+----------------+---------------+-----------+--------------+
Table 1: Signature Keys
表1：署名キー
Note that Personalization Data is not included in the table above. The use of Personalization Data is dependent on how TAs are used and what their security requirements are.
上記の表には個人情報データは含まれていません。個人情報データの使用は、TAがどのように使用され、そのセキュリティ要件がどのようなものかに依存します。
TEEP requests from a TAM to a TEEP Agent are signed with the TAM private key (for authentication and integrity protection). Personalization Data and TA binaries can be encrypted with a key unique to that specific TEE. Conversely, TEEP responses from a TEEP Agent to a TAM can be signed with the TEE private key.
TEEPリクエストは、TAMからTEEPエージェントにTAMの秘密鍵で署名されます（認証および整合性保護のため）。個別のTEEに固有のキーでPersonalization DataとTAバイナリを暗号化することができます。逆に、TEEPエージェントからTAMへのTEEPレスポンスは、TEEの秘密鍵で署名されることがあります。
The TEE key pair and certificate are thus used for authenticating the TEE to a remote TAM and for sending private data to the TEE. Often, the key pair is burned into the TEE by the TEE manufacturer, and the key pair and its certificate are valid for the expected lifetime of the TEE. A TAM provider is responsible for configuring the TAM's Trust Anchor Store with the manufacturer certificates or CAs that are used to sign TEE keys. This is discussed further in Section 5.3. Typically, the same TEE key pair is used for both signing and encryption, though separate key pairs might also be used in the future, as the joint security of encryption and signature with a single key remains, to some extent, an open question in academic cryptography.
TEEキーペアと証明書は、TEEをリモートTAMに認証するために使用され、TEEにプライベートデータを送信するために使用されます。多くの場合、キーペアはTEEメーカーによってTEEに焼き込まれ、そのキーペアと証明書はTEEの予想される寿命の間有効です。TAMプロバイダーは、TEEキーに署名するために使用されるメーカー証明書またはCAをTAMの信頼アンカーストアに構成する責任があります。これについては、5.3節でさらに詳しく説明されています。通常、同じTEEキーペアが署名と暗号化の両方に使用されますが、将来は別々のキーペアが使用されるかもしれません。暗号化と署名の共同セキュリティについては、一つのキーでの暗号化と署名のセキュリティが、ある程度、学術的な暗号化において未解決の問題であると言えます。
The TAM key pair and certificate are used for authenticating a TAM to a remote TEE and for sending private data to the TAM (separate key pairs for authentication vs. encryption could also be used in the future). A TAM provider is responsible for acquiring a certificate from a CA that is trusted by the TEEs it manages. This is discussed further in Section 5.1.
TAMキーペアと証明書は、TAMをリモートTEEに認証し、TAMにプライベートデータを送信するために使用されます（将来的には認証用と暗号化用の別々のキーペアも使用できます）。TAMプロバイダーは、TEEが信頼するCAから証明書を取得する責任があります。これについては、セクション5.1でさらに詳しく説明されています。
The Trusted Component Signer key pair and certificate are used to sign Trusted Components that the TEE will consider authorized to execute. TEEs must be configured with the certificates or keys that it considers authorized to sign TAs that it will execute. This is discussed further in Section 5.2.
信頼されたコンポーネント署名者のキーペアと証明書は、TEEが実行を許可すると見なす信頼されたコンポーネントに署名するために使用されます。 TEEは、実行するTAに署名することを許可する証明書またはキーで構成する必要があります。これについては、セクション5.2でさらに詳しく説明されています。
A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors, which are typically CA certificates that sign various TAM certificates. The list is usually preloaded at manufacturing time and can be updated using the TEEP protocol if the TEE has some form of "Trust Anchor Manager TA" that has Trust Anchors in its configuration data. Thus, Trust Anchors can be updated similarly to the Personalization Data for any other TA.
TEEPエージェントの信頼アンカーストアには、通常、さまざまなTAM証明書に署名するCA証明書である信頼アンカーのリストが含まれています。このリストは通常、製造時にプリロードされ、TEEに「信頼アンカーマネージャーTA」が構成データに信頼アンカーを持っている場合、TEEPプロトコルを使用して更新することができます。したがって、信頼アンカーは、他のTAのパーソナライゼーションデータと同様に更新できます。
When a Trust Anchor update is carried out, it is imperative that any update must maintain integrity where only an authentic Trust Anchor list from a device manufacturer or a Device Administrator is accepted. Details are out of scope of this architecture document and can be addressed in a protocol document.
信頼アンカーの更新が行われる際には、更新が整合性を保持することが不可欠であり、デバイスメーカーまたはデバイス管理者からの正規の信頼アンカーリストのみが受け入れられます。このアーキテクチャ文書の範囲外の詳細は、プロトコル文書で取り扱うことができます。
Before a TAM can begin operation in the marketplace to support a device with a particular TEE, it must be able to get its raw public key, its certificate, or a certificate it chains up to listed in the Trust Anchor Store of the TEEP Agent.
特定のTEEをサポートするためにマーケットプレースでTAMが動作を開始する前に、その生の公開鍵、証明書、またはそれにチェーンアップされた証明書をTEEPエージェントのTrust Anchor Storeにリストアップする必要があります。
The Trust Anchor Store in a TEE contains a list of Trust Anchors (raw public keys or certificates) that are used to determine whether TA binaries are allowed to execute by checking if their signatures can be verified. The list is typically preloaded at manufacturing time and can be updated using the TEEP protocol if the TEE has some form of "Trust Anchor Manager TA" that has Trust Anchors in its configuration data. Thus, Trust Anchors can be updated similarly to the Personalization Data for any other TA, as discussed in Section 5.1.
TEE内のTrust Anchor Storeには、TAバイナリが実行を許可されるかどうかを決定するために使用されるTrust Anchors（生の公開鍵または証明書）のリストが含まれています。このリストは通常、製造時にプリロードされ、TEEに「Trust Anchor Manager TA」が構成データにTrust Anchorsを持っている場合、TEEPプロトコルを使用して更新することができます。したがって、Trust Anchorsは、セクション5.1で議論されている他のTAのパーソナライゼーションデータと同様に更新することができます。
The Trust Anchor Store in a TAM consists of a list of Trust Anchors, which are certificates that sign various device TEE certificates. A TAM will accept a device for Trusted Component management if the TEE in the device uses a TEE certificate that is chained to a certificate or raw public key that the TAM trusts, is contained in an allow list, is not found on a block list, and/or fulfills any other policy criteria.
TAM（Trusted Application Manager）内のTrust Anchor Storeには、さまざまなデバイスTEE証明書に署名するTrust Anchorsのリストが含まれています。デバイスが信頼されたコンポーネント管理のために受け入れられるのは、そのデバイスのTEEが、TAMが信頼する証明書または生の公開鍵にチェーンされたTEE証明書を使用している場合、許可リストに含まれている場合、ブロックリストに含まれていない場合、および/または他のポリシー基準を満たしている場合です。
This architecture uses a PKI (including self-signed certificates). Trust Anchors exist on the devices to enable the TEEP Agent to authenticate TAMs and the TEE to authenticate Trusted Component Signers, and TAMs use Trust Anchors to authenticate TEEP Agents. When a PKI is used, many intermediate CA certificates can chain to a root certificate, each of which can issue many certificates. This makes the protocol highly scalable. New factories that produce TEEs can join the ecosystem. In this case, such a factory can get an intermediate CA certificate from one of the existing roots without requiring that TAMs are updated with information about the new device factory. Likewise, new TAMs can join the ecosystem, providing they are issued a TAM certificate that chains to an existing root whereby existing TAs in the TEE will be allowed to be personalized by the TAM without requiring changes to the TEE itself. This enables the ecosystem to scale and avoids the need for centralized databases of all TEEs produced, all TAMs that exist, or all Trusted Component Signers that exist.
このアーキテクチャはPKI（自己署名証明書を含む）を使用しています。信頼アンカーは、TEEPエージェントがTAMを認証し、TEEが信頼されたコンポーネント署名者を認証するためのデバイスに存在し、TAMはTEEPエージェントを認証するために信頼アンカーを使用します。PKIを使用すると、多くの中間CA証明書がルート証明書にチェーンでき、それぞれが多くの証明書を発行できます。これにより、プロトコルは非常にスケーラブルになります。新しいTEEを生産する工場はエコシステムに参加できます。この場合、そのような工場は、TAMが新しいデバイス工場の情報を更新する必要がないように、既存のルートの1つから中間CA証明書を取得できます。同様に、新しいTAMは、既存のTAがTEEを変更することなくTAMによって個人化されることを許可する既存のルートにチェーンされたTAM証明書が発行されている限り、エコシステムに参加できます。これにより、エコシステムを拡大し、生産されたすべてのTEE、存在するすべてのTAM、または存在するすべての信頼されたコンポーネント署名者の中央集権化されたデータベースの必要性を回避できます。
Messages created by a TAM are used to deliver Trusted Component management commands to a device, and device attestation and messages are created by the device TEE to respond to TAM messages.
TAM によって作成されたメッセージは、信頼されたコンポーネントの管理コマンドをデバイスに送信するために使用され、デバイスの TEE によってデバイスの証明とメッセージが TAM メッセージに応答するために作成されます。
These messages are signed end-to-end between a TEEP Agent and a TAM. Confidentiality is provided by encrypting sensitive payloads (such as Personalization Data and attestation evidence), rather than encrypting the messages themselves. Using encrypted payloads is important to ensure that only the targeted device TEE or TAM is able to decrypt and view the actual content.
これらのメッセージは、TEEPエージェントとTAMの間でエンドツーエンドで署名されます。機密性は、メッセージ自体を暗号化するのではなく、機密ペイロード（個人化データや証明書の証拠など）を暗号化することによって提供されます。暗号化されたペイロードを使用することは重要であり、対象のデバイスTEEまたはTAMだけが実際のコンテンツを復号化して表示できるようにするためです。
A TEE and TAs often do not have the capability to directly communicate outside of the hosting device. For example, GlobalPlatform [GPTEE] specifies one such architecture. This calls for a software module in the REE world to handle network communication with a TAM.
TEEとTAsは、ホスティングデバイスの外部で直接通信する能力を持っていないことがよくあります。たとえば、GlobalPlatform [GPTEE]はそのようなアーキテクチャを指定しています。これにより、REEワールドのソフトウェアモジュールがTAMとのネットワーク通信を処理する必要があります。
A TEEP Broker is an application component running in the REE of the device or an SDK that facilitates communication between a TAM and a TEE. It also provides interfaces for Untrusted Applications to query and trigger installation of Trusted Components that the application needs to use.
TEEPブローカーは、デバイスのREEで実行されるアプリケーションコンポーネントまたはTAMとTEEの間の通信を容易にするSDKです。また、信頼できないアプリケーションが必要とする信頼できるコンポーネントのインストールをクエリおよびトリガーするためのインターフェースも提供します。
An Untrusted Application might communicate with a TEEP Broker at runtime to trigger Trusted Component installation itself. Alternatively, an Untrusted Application might simply have a metadata file that describes the Trusted Components it depends on and the associated TAM(s) for each Trusted Component. An REE Application Installer can inspect this application metadata file and invoke the TEEP Broker to trigger Trusted Component installation on behalf of the Untrusted Application without requiring the Untrusted Application to run first.
信頼されていないアプリケーションは、実行時に TEEP ブローカーと通信して、信頼されたコンポーネントのインストールをトリガーすることがあります。 また、信頼されていないアプリケーションは、単に依存する信頼されたコンポーネントと各信頼されたコンポーネントに関連する TAM を記述したメタデータファイルを持っているかもしれません。 REE アプリケーションインストーラーは、このアプリケーションのメタデータファイルを検査し、信頼されていないアプリケーションが最初に実行する必要なく、信頼されていないアプリケーションの代わりに TEEP ブローカーを起動して信頼されたコンポーネントのインストールをトリガーすることができます。
A TEEP Broker interacts with a TEEP Agent inside a TEE, relaying messages between the TEEP Agent and the TAM, and may also interact with one or more Untrusted Applications (see Section 6.2.1). The Broker cannot parse encrypted TEEP messages exchanged between a TAM and a TEEP Agent but merely relays them.
TEEPブローカーは、TEE内のTEEPエージェントとTAMの間でメッセージを中継し、また1つ以上の信頼できないアプリケーションともやり取りすることがあります（セクション6.2.1を参照）。ブローカーは、TAMとTEEPエージェントの間で交換される暗号化されたTEEPメッセージを解析することはできませんが、単に中継します。
When a device has more than one TEE, one TEEP Broker per TEE could be present in the REE, or a common TEEP Broker could be used by multiple TEEs where the transport protocol (e.g., [TEEP-HTTP]) allows the TEEP Broker to distinguish which TEE is relevant for each message from a TAM.
デバイスに複数のTEEがある場合、1つのTEEごとに1つのTEEPブローカーがREEに存在するか、複数のTEEが共通のTEEPブローカーを使用することができます。ここで、輸送プロトコル（例：[TEEP-HTTP]）がTEEPブローカーに、TAMからの各メッセージに対してどのTEEが関連しているかを区別することを許可している場合があります。
The Broker only needs to return an error message to the TAM if the TEE is not reachable for some reason. Other errors are represented as TEEP response messages returned from the TEE, which will then be passed to the TAM.
ブローカーは、TEEが何らかの理由で到達できない場合にのみ、TAMにエラーメッセージを返す必要があります。その他のエラーは、TEEから返されるTEEP応答メッセージとして表され、それらはその後TAMに渡されます。
As depicted in Figure 4, there are multiple ways in which a TEEP Broker can be implemented with more or fewer layers being inside the TEE. For example, in model A (the model with the smallest TEE footprint), only the TEEP implementation is inside the TEE, whereas the TEEP/HTTP implementation is in the TEEP Broker outside the TEE.
図4に示されているように、TEEPブローカーを実装する際には、TEEP内により多くまたはより少ないレイヤーが含まれる複数の方法があります。たとえば、モデルA（TEEのフットプリントが最小のモデル）では、TEEP実装のみがTEE内にあり、一方、TEEP/HTTP実装はTEEの外にあるTEEPブローカーにあります。
Model: A B C
TEE TEE TEE
+----------------+ | | |
| TEEP | Agent | | | Agent
| implementation | | | |
+----------------+ v | |
| | |
+----------------+ ^ | |
| TEEP/HTTP | Broker | | |
| implementation | | | |
+----------------+ | v |
| | |
+----------------+ | ^ |
| HTTP(S) | | | |
| implementation | | | |
+----------------+ | | v
| | |
+----------------+ | | ^
| TCP or QUIC | | | | Broker
| implementation | | | |
+----------------+ | | |
REE REE REE
Figure 4: TEEP Broker Models
図4：TEEPブローカーモデル
In other models, additional layers are moved into the TEE, increasing the TEE footprint, with the Broker either containing or calling the topmost protocol layer outside of the TEE. An implementation is free to choose any of these models.
他のモデルでは、追加のレイヤーがTEEに移動され、TEEのフットプリントが増加します。Brokerは、TEEの外側にある最上位のプロトコルレイヤーを含むか、それを呼び出します。実装はこれらのモデルのいずれかを選択することができます。
TEEP Broker implementers should consider methods of distribution, scope, and concurrency on devices and runtime options.
TEEPブローカーの実装者は、デバイスやランタイムオプションにおける配布方法、範囲、および同時性を考慮する必要があります。
The following conceptual APIs exist from a TEEP Broker to a TEEP Agent:
次の概念的なAPIは、TEEPブローカーからTEEPエージェントへ存在しています。
1. RequestTA: A notification from an REE application (e.g., an installer or an Untrusted Application) that the application depends on a given Trusted Component, which may or may not already be installed in the TEE.
1. RequestTA: アプリケーションが特定の信頼されたコンポーネントに依存していることを通知するREEアプリケーション（例：インストーラーまたは信頼されていないアプリケーション）からの通知。この信頼されたコンポーネントは、TEEにすでにインストールされているかどうかは不明です。
2. UnrequestTA: A notification from an REE application (e.g., an installer or an Untrusted Application) that the application no longer depends on a given Trusted Component, which may or may not already be installed in the TEE. For example, if the Untrusted Application is uninstalled, the uninstaller might invoke this conceptual API.
2. UnrequestTA: アプリケーションが特定の信頼されたコンポーネントに依存しなくなったことを通知するREEアプリケーション（例：インストーラーまたは信頼されていないアプリケーション）からの通知。たとえば、信頼されていないアプリケーションがアンインストールされると、アンインストーラーがこの概念的なAPIを呼び出すかもしれません。
3. ProcessTeepMessage: A message arriving from the network, to be delivered to the TEEP Agent for processing.
3. ProcessTeepMessage: ネットワークから到着したメッセージは、処理のためにTEEPエージェントに配信されます。
4. RequestPolicyCheck: A hint (e.g., based on a timer) that the TEEP Agent may wish to contact the TAM for any changes without the device itself needing any particular change.
4. RequestPolicyCheck: TEEPエージェントが、デバイス自体に特定の変更が必要なく、任意の変更がある場合にTAMに連絡することを希望するヒント（たとえば、タイマーに基づく）
5. ProcessError: A notification that the TEEP Broker could not deliver an outbound TEEP message to a TAM.
5. TEEPブローカーがTAMに出力TEEPメッセージを配信できなかったことを通知するエラー。
For comparison, similar APIs may exist on the TAM side, where a Broker may or may not exist, depending on whether the TAM uses a TEE or not:
比較のために、TAM側には同様のAPIが存在する可能性があります。TAMがTEEを使用しているかどうかによって、ブローカーが存在するかどうかが異なります。
1. ProcessConnect: A notification that a new TEEP session is being requested by a TEEP Agent.
1. ProcessConnect: TEEPエージェントによって新しいTEEPセッションがリクエストされていることを通知します。
2. ProcessTeepMessage: A message arriving at an existing TEEP session, to be delivered to the TAM for processing.
2. ProcessTeepMessage: 既存のTEEPセッションに到着したメッセージは、処理のためにTAMに配信されます。
For further discussion on these APIs, see [TEEP-HTTP].
これらのAPIに関するさらなる議論については、[TEEP-HTTP]を参照してください。
The Broker installation is commonly carried out at device manufacturing time. A user may also dynamically download and install a Broker on demand.
ブローカーのインストールは通常、デバイスの製造時に行われます。ユーザーは必要に応じてブローカーをダイナミックにダウンロードしてインストールすることもできます。
Attestation is the process through which one entity (an Attester) presents "evidence" in the form of a series of claims to another entity (a Verifier) and provides sufficient proof that the claims are true. Different Verifiers may require different degrees of confidence in attestation proofs, and not all attestations are acceptable to every Verifier. A third entity (a Relying Party) can then use "attestation results" in the form of another series of claims from a Verifier to make authorization decisions. (See [RFC9334] for more discussion.)
アテステーションは、1つのエンティティ（アテスター）が別のエンティティ（検証者）に対して「証拠」として一連の主張を提示し、その主張が真実であることを十分に証明するプロセスです。異なる検証者は、アテステーションの証拠に対して異なる信頼度を要求する場合があり、すべてのアテステーションがすべての検証者に受け入れられるわけではありません。第三のエンティティ（信頼する側）は、その後、「アテステーションの結果」として、検証者からの別の一連の主張を使用して、認可の決定を行うことができます。（詳細については[RFC9334]を参照してください。）
In TEEP, as depicted in Figure 5, the primary purpose of an attestation is to allow a device (the Attester) to prove to a TAM (the Relying Party) that a TEE in the device has particular properties, was built by a particular manufacturer, and/or is executing a particular TA. Other claims are possible; TEEP does not limit the claims that may appear in evidence or attestation results, but it defines a minimal set of attestation result claims required for TEEP to operate properly. Extensions to these claims are possible. Other standards or groups may define the format and semantics of extended claims.
TEEPでは、図5に示されているように、証明書の主な目的は、デバイス（Attester）がデバイス内のTEEが特定の特性を持ち、特定の製造業者によって構築され、または特定のTAを実行していることをTAM（Relying Party）に証明することです。他の主張も可能です。TEEPは、証拠や証明結果に表示される可能性のある主張を制限しませんが、TEEPが適切に動作するために必要な最小限の証明結果主張のセットを定義しています。これらの主張の拡張も可能です。他の標準やグループが拡張された主張の形式と意味を定義することがあります。
+----------------+
| Device | +----------+
| +------------+ | Evidence | TAM | Evidence +----------+
| | TEE |------------->| (Relying |-------------->| Verifier |
| | (Attester) | | | Party) |<--------------| |
| +------------+ | +----------+ Attestation +----------+
+----------------+ Result
Figure 5: TEEP Attestation Roles
図5：TEEP認証ロール
At the time of writing this specification, device and TEE attestations have not been standardized across the market. Different devices, manufacturers, and TEEs support different attestation protocols. In order for TEEP to be inclusive, it is agnostic to the format of evidence, allowing proprietary or standardized formats to be used between a TEE and a Verifier (which may or may not be colocated in the TAM), as long as the format supports encryption of any information that is considered sensitive.
この仕様書を書いている時点では、デバイスとTEEのアテステーションは市場全体で標準化されていません。異なるデバイス、製造業者、およびTEEは異なるアテステーションプロトコルをサポートしています。TEEPが包括的であるためには、証拠の形式に中立的であることが重要であり、TEEと検証者（TAM内にあるかどうかは問わない）の間でプロプライエタリまたは標準化された形式が使用されることができます。ただし、その形式が機密情報を暗号化することをサポートしている限りです。
However, it should be recognized that not all Verifiers may be able to process all proprietary forms of attestation evidence. Similarly, the TEEP protocol is agnostic as to the format of attestation results and the protocol (if any) used between the TAM and a Verifier, as long as they convey at least the required set of claims in some format. Note that the respective attestation algorithms are not defined in the TEEP protocol itself; see [RFC9334] and [TEEP] for more discussion.
ただし、すべての検証者がすべての独自の証明形式を処理できるとは限らないことを認識する必要があります。同様に、TEEPプロトコルは、検証結果の形式やTAMと検証者の間で使用されるプロトコル（あれば）については中立的です。少なくとも必要な一連のクレームをいくつかの形式で伝達すればよいです。なお、それぞれの証明アルゴリズムは、TEEPプロトコル自体で定義されていません。詳細については[RFC9334]および[TEEP]を参照してください。
Considerations when appraising evidence provided by a TEE include the following:
TEEによって提供される証拠を評価する際の考慮事項は次の通りです。
* What security measures a manufacturer takes when provisioning keys into devices/TEEs;
* メーカーがデバイス/TEEに鍵を供給する際に取るセキュリティ対策は何ですか。
* What hardware and software components have access to the attestation keys of the TEE;
* TEEのアテステーションキーにアクセスできるハードウェアおよびソフトウェアコンポーネントは何ですか。
* The source or local verification of claims within an attestation prior to a TEE signing a set of claims;
* 信頼環境（TEE）が一連のクレームに署名する前に、アテステーション内のクレームをソースまたはローカルで検証すること。
* The level of protection afforded to attestation keys against exfiltration, modification, and side channel attacks;
* 認証キーを外部流出、改ざん、およびサイドチャネル攻撃から保護するレベル；
* The limitations of use applied to TEE attestation keys;
* TEEアテステーションキーに適用される使用制限；
* The processes in place to discover or detect TEE breaches; and
* TEE違反を発見または検出するためのプロセス；および
* The revocation and recovery process of TEE attestation keys.
* TEE認証キーの取り消しと回復プロセス。
Some TAMs may require additional claims in order to properly authorize a device or TEE. The specific format for these additional claims are outside the scope of this specification, but the TEEP protocol allows these additional claims to be included in the attestation messages.
一部のTAMは、デバイスやTEEを適切に認証するために追加のクレームが必要になる場合があります。これらの追加のクレームの具体的な形式は、この仕様の範囲外ですが、TEEPプロトコルではこれらの追加のクレームをアテステーションメッセージに含めることができます。
For more discussion of the attestation and appraisal process, see the RATS Architecture [RFC9334].
RATSアーキテクチャ[RFC9334]における承認および評価プロセスのさらなる議論については、詳細をご覧ください。
The following information is required for TEEP attestation:
次の情報は、TEEPの証明に必要です。
* Device Identifying Information: Attestation information may need to uniquely identify a device to the TAM. Unique device identification allows the TAM to provide services to the device, such as managing installed TAs, providing subscriptions to services, and locating device-specific keying material to communicate with or authenticate the device. In some use cases, it may be sufficient to identify only the model or class of the device, for example, a DAA Issuer's group public key ID when the attestation uses DAA; see [RATS-DAA]. Another example of models is the hwmodel (Hardware Model) as defined in [EAT]. The security and privacy requirements regarding device identification will vary with the type of TA provisioned to the TEE.
* デバイス識別情報：アテステーション情報は、デバイスをTAMに一意に識別する必要がある場合があります。ユニークなデバイス識別は、TAMがデバイスにサービスを提供できるようにし、インストールされたTAを管理し、サービスに加入し、デバイスと通信したり認証するためのデバイス固有の鍵材料を特定することができます。一部の使用ケースでは、デバイスのモデルまたはクラスのみを識別することが十分である場合があります。たとえば、アテステーションがDAAを使用する場合のDAA発行者のグループ公開鍵IDを参照してください[RATS-DAA]。モデルの別の例は、[EAT]で定義されているhwmodel（ハードウェアモデル）です。デバイス識別に関するセキュリティおよびプライバシー要件は、TEEに提供されるTAの種類によって異なります。
* TEE Identifying Information: The type of TEE that generated this attestation must be identified. This includes version identification information for hardware, firmware, and software version of the TEE, as applicable by the TEE type. TEE manufacturer information for the TEE is required in order to disambiguate the same TEE type created by different manufacturers and address considerations around manufacturer provisioning, keying, and support for the TEE.
* TEE識別情報：この証明書を生成したTEEのタイプを特定する必要があります。これには、TEEのハードウェア、ファームウェア、およびソフトウェアバージョンのバージョン識別情報が含まれます。TEEの製造元情報が必要です。これにより、異なる製造元によって作成された同じTEEタイプを明確にし、製造元のプロビジョニング、キー付け、およびTEEのサポートに関する考慮事項を解決できます。
* Freshness Proof: A claim that includes freshness information must be included, such as a nonce or timestamp.
* 新鮮さの証明：新鮮さ情報を含む主張には、ナンスまたはタイムスタンプなどが含まれている必要があります。
[RFC7696] outlines the requirements to migrate from one mandatory-to-implement cryptographic algorithm suite to another over time. This feature is also known as "crypto agility". Protocol evolution is greatly simplified when crypto agility is considered during the design of the protocol. In the case of the TEEP protocol, the diverse range of use cases (from trusted app updates for smartphones and tablets to updates of code on higher-end IoT devices) creates the need for different mandatory-to-implement algorithms from the start.
[RFC7696]は、時間の経過とともに実装が必須とされる暗号アルゴリズムスイートから別のものに移行するための要件を概説しています。この機能は「暗号アジリティ」としても知られています。プロトコルの設計時に暗号アジリティが考慮されると、プロトコルの進化が大幅に簡素化されます。TEEPプロトコルの場合、さまざまな使用ケース（スマートフォンやタブレット向けの信頼できるアプリの更新から、高度なIoTデバイス上のコードの更新まで）があり、最初から異なる実装が必須とされるアルゴリズムが必要とされます。
Crypto agility in TEEP concerns the use of symmetric as well as asymmetric algorithms. In the context of TEEP, symmetric algorithms are used for encryption and integrity protection of TA binaries and Personalization Data, whereas the asymmetric algorithms are used for signing messages and managing symmetric keys.
TEEPにおける暗号アジリティは、対称アルゴリズムと非対称アルゴリズムの使用に関わります。TEEPの文脈では、対称アルゴリズムはTAバイナリおよび個人データの暗号化と整合性保護に使用され、非対称アルゴリズムはメッセージの署名と対称キーの管理に使用されます。
In addition to the use of cryptographic algorithms in TEEP, there is also the need to make use of different attestation technologies. A device must provide techniques to inform a TAM about the attestation technology it supports. For many deployment cases, it is more likely for the TAM to support one or more attestation techniques, whereas the device may only support one.
TEEPでの暗号アルゴリズムの使用に加えて、異なる証明技術を利用する必要もあります。デバイスは、TAMにサポートされている証明技術について通知する技術を提供する必要があります。多くの展開ケースでは、TAMが1つ以上の証明技術をサポートする可能性が高い一方、デバイスは1つしかサポートしていないことがあります。
The architecture enables the TAM to communicate, via a TEEP Broker, with the device's TEE to manage Trusted Components. However, since the TEEP Broker runs in a potentially vulnerable REE, the TEEP Broker could be malware or be infected by malware. As such, all TAM messages are signed and sensitive data is encrypted such that the TEEP Broker cannot modify or capture sensitive data, but the TEEP Broker can still conduct DoS attacks as discussed in Section 9.3.
アーキテクチャは、TAMがTEE Brokerを介してデバイスのTEEと通信し、信頼されたコンポーネントを管理できるようにします。ただし、TEEP Brokerは潜在的に脆弱なREEで実行されているため、TEEP Brokerはマルウェアである可能性があり、またはマルウェアに感染している可能性があります。そのため、すべてのTAMメッセージは署名され、機密データは暗号化されており、TEEP Brokerは機密データを変更またはキャプチャすることはできませんが、TEEP Brokerは9.3節で議論されているようにDoS攻撃を実行することができます。
A TEEP Agent in a TEE is responsible for protecting against potential attacks from a compromised TEEP Broker or rogue malware in the REE. A rogue TEEP Broker might send corrupted data to the TEEP Agent, launch a DoS attack by sending a flood of TEEP protocol requests, or simply drop or delay notifications to a TEE. The TEEP Agent validates the signature of each TEEP protocol request and checks the signing certificate against its Trust Anchors. To mitigate DoS attacks, it might also add some protection scheme such as a threshold on repeated requests or the number of TAs that can be installed.
TEEPエージェントは、TEE内で、危険にさらされたTEEPブローカーやREE内のローグマルウェアからの潜在的な攻撃から保護する責任があります。ローグTEEPブローカーは、TEEPエージェントに破損したデータを送信したり、TEEPプロトコルリクエストの洪水を送信してDoS攻撃を行ったり、TEEに通知をドロップしたり遅延させたりする可能性があります。TEEPエージェントは、各TEEPプロトコルリクエストの署名を検証し、署名証明書を信頼アンカーと照合します。DoS攻撃を緩和するために、繰り返しリクエストやインストールできるTAの数にしきい値などの保護スキームを追加することもあります。
Due to the lack of any available alternative, some implementations might rely on the use of an untrusted timer or other event to call the RequestPolicyCheck API (Section 6.2.1), which means that a compromised REE can cause a TEE to not receive policy changes and thus be out of date with respect to policy. The same can potentially be done by any other manipulator-in-the-middle simply by blocking communication with a TAM. Ultimately, such outdated compliance could be addressed by using attestation in secure communication, where the attestation evidence reveals what state the TEE is in, so that communication (other than remediation such as via TEEP) from an out-of-compliance TEE can be rejected.
利用可能な代替手段がないため、一部の実装では信頼できないタイマーやその他のイベントを使用してRequestPolicyCheck API（セクション6.2.1）を呼び出すことがあります。これは、侵害されたリモート実行環境（REE）がトラステッド実行環境（TEE）がポリシーの変更を受け取らず、その結果ポリシーに関して時代遅れになる可能性があることを意味します。同様のことは、他の中間者がTAMとの通信をブロックすることで簡単に行うことができます。最終的に、そのような時代遅れのコンプライアンスは、TEEの状態を示すアテステーション証拠を使用してセキュアな通信で対処できる可能性があります。これにより、コンプライアンスに違反しているTEEからの通信（TEEPなどを介したリメディエーションを除く）を拒否することができます。
Similarly, in most implementations, the REE is involved in the mechanics of installing new TAs. However, the authority for what TAs are running in a given TEE is between the TEEP Agent and the TAM. While a TEEP Broker can, in effect, make suggestions as discussed in Section 6.2.1, it cannot decide or enforce what runs where. The TEEP Broker can also control which TEE a given installation request is directed at, but a TEEP Agent will only accept TAs that are actually applicable to it and where installation instructions are received by a TAM that it trusts.
同様に、ほとんどの実装では、REEは新しいTAをインストールするメカニクスに関与しています。ただし、特定のTEEで実行されているTAはTEEPエージェントとTAMの間で権限があります。TEEPブローカーは、セクション6.2.1で議論されているように提案を行うことができますが、実際にどこで実行されるかを決定したり強制したりすることはできません。TEEPブローカーは、特定のインストールリクエストがどのTEEに向けられるかを制御することもできますが、TEEPエージェントは、実際に適用可能であり、信頼できるTAMから受け取ったインストール指示があるTAのみを受け入れます。
The authorization model for the UnrequestTA operation is, however, weaker in that it expresses the removal of a dependency from an application that was untrusted to begin with. This means that a compromised REE could remove a valid dependency from an Untrusted Application on a TA. Normal REE security mechanisms should be used to protect the REE and Untrusted Applications.
UnrequestTA操作の認可モデルは、ただし、アプリケーションから依存関係を削除することを表現する点で弱いです。これは、信頼されていないアプリケーションから始まった依存関係を削除することを意味します。これは、侵害されたREEがTA上の信頼されていないアプリケーションから有効な依存関係を削除できる可能性があることを意味します。通常のREEセキュリティメカニズムを使用して、REEと信頼されていないアプリケーションを保護する必要があります。
It is the responsibility of the TAM to protect data on its servers. Similarly, it is the responsibility of the TEE implementation to provide protection of data against integrity and confidentiality attacks from outside the TEE. TEEs that provide isolation among TAs within the TEE are likewise responsible for protecting TA data against the REE and other TAs. For example, this can be used to protect the data of one user or tenant from compromise by another user or tenant, even if the attacker has TAs.
TAMはサーバー上のデータを保護する責任があります。同様に、TEEの実装は、TEE外部からの整合性および機密性攻撃に対するデータの保護を提供する責任があります。TEE内のTA間で隔離を提供するTEEは、REEおよび他のTAからのTAデータの保護も同様に責任を負います。例えば、これは、攻撃者がTAを持っていても、1人のユーザーやテナントのデータを他のユーザーやテナントによる侵害から保護するために使用できます。
The protocol between TEEP Agents and TAMs is similarly responsible for securely providing integrity and confidentiality protection against adversaries between them. The layers at which to best provide protection against network adversaries is a design choice. As discussed in Section 6, the transport protocol and any security mechanism associated with it (e.g., the Transport Layer Security protocol) under the TEEP protocol may terminate outside a TEE. If it does, the TEEP protocol itself must provide integrity and confidentiality protection to secure data end-to-end. For example, confidentiality protection for payloads may be provided by utilizing encrypted TA binaries and encrypted attestation information. See [TEEP] for how a specific solution addresses the design question of how to provide integrity and confidentiality protection.
TEEPエージェントとTAM間のプロトコルは、彼らの間の敵対者に対して整合性と機密性の保護を安全に提供する責任が同様にあります。ネットワークの敵対者に対して最良の保護を提供するためのレイヤーは、設計の選択肢です。セクション6で議論されているように、TEEPプロトコルの下での輸送プロトコルとそれに関連するセキュリティメカニズム（例：Transport Layer Securityプロトコル）は、TEEの外で終了する場合があります。その場合、TEEPプロトコル自体がデータのエンドツーエンドの整合性と機密性の保護を提供する必要があります。たとえば、ペイロードの機密性保護は、暗号化されたTAバイナリと暗号化されたアテステーション情報を利用して提供される場合があります。整合性と機密性の保護をどのように提供するかという設計上の問題に特定の解決策がどのように対処しているかについては、[TEEP]を参照してください。
It is possible that the REE of a device is compromised. We have already seen examples of attacks on the public Internet with a large number of compromised devices being used to mount DDoS attacks. A compromised REE can be used for such an attack, but it cannot tamper with the TEE's code or data in doing so. A compromised REE can, however, launch DoS attacks against the TEE.
デバイスのREEが危険にさらされている可能性があります。公共インターネット上で、多数の危険にさらされたデバイスが使用されてDDoS攻撃を行う例がすでに見られています。危険にさらされたREEはそのような攻撃に使用される可能性がありますが、その際にTEEのコードやデータを改ざんすることはできません。ただし、危険にさらされたREEはTEEに対してDoS攻撃を行うことができます。
The compromised REE may terminate the TEEP Broker such that TEEP transactions cannot reach the TEE or might drop, replay, or delay messages between a TAM and a TEEP Agent. However, while a DoS attack cannot be prevented, the REE cannot access anything in the TEE if the TEE is implemented correctly. Some TEEs may have some watchdog scheme to observe REE state and mitigate DoS attacks against it, but most TEEs don't have such a capability.
REEが侵害されると、TEEPブローカーが終了され、TEEPトランザクションがTEEに到達できなくなる可能性があり、TAMとTEEPエージェントの間のメッセージがドロップ、リプレイ、または遅延する可能性があります。ただし、DoS攻撃は防ぐことができませんが、TEEが正しく実装されている場合、REEはTEE内の何もアクセスできません。一部のTEEには、REEの状態を監視し、それに対するDoS攻撃を緩和するための監視スキームがある場合がありますが、ほとんどのTEEにはそのような機能がありません。
In some other scenarios, the compromised REE may ask a TEEP Broker to make repeated requests to a TEEP Agent in a TEE to install or uninstall a Trusted Component. An installation or uninstallation request constructed by the TEEP Broker or REE will be rejected by the TEEP Agent because the request won't have the correct signature from a TAM to pass the request signature validation.
別のシナリオでは、侵害されたREEが、信頼されたコンポーネントをインストールまたはアンインストールするためにTEE内のTEEPエージェントに繰り返しリクエストを行うようTEEPブローカーに要求することがあります。TEEPブローカーまたはREEによって構築されたインストールまたはアンインストールのリクエストは、TAMからの正しい署名を持たないため、TEEPエージェントによって拒否されます。
This can become a DoS attack by exhausting resources in a TEE with repeated requests. In general, a DoS attack threat exists when the REE is compromised and a DoS attack can happen to other resources. The TEEP architecture doesn't change this.
これは、繰り返しのリクエストによって TEE のリソースを枯渇させることで DoS 攻撃になり得ます。一般的に、REE が危険にさらされているときに DoS 攻撃の脅威が存在し、他のリソースにも DoS 攻撃が発生する可能性があります。TEEP アーキテクチャはこれを変えません。
A compromised REE might also request initiating the full flow of installation of Trusted Components that are not necessary. It may also repeat a prior legitimate Trusted Component installation request. A TEEP Agent implementation is responsible for ensuring that it can recognize and decline such repeated requests. It is also responsible for protecting the resource usage allocated for Trusted Component management.
REが妥協されると、不要な信頼されたコンポーネントの完全なインストールフローの開始を要求する可能性があります。また、以前の正当な信頼されたコンポーネントのインストール要求を繰り返すことがあります。TEEPエージェントの実装は、このような繰り返し要求を認識して拒否できるようにする責任があります。また、信頼されたコンポーネント管理に割り当てられたリソース使用量を保護する責任もあります。
A root CA for TAM certificates might get compromised, its certificate might expire, or a Trust Anchor other than a root CA certificate may also expire or be compromised. TEEs are responsible for validating the entire TAM certification path, including the TAM certificate and any intermediate certificates up to the root certificate. See Section 6 of [RFC5280] for details. Such validation generally includes checking for certificate revocation, but certificate status check protocols may not scale down to constrained devices that use TEEP.
TAM証明書のルートCAが危険にさらされる可能性があり、その証明書が期限切れになる可能性があります。また、ルートCA証明書以外の信頼アンカーも期限切れになるか、危険にさらされる可能性があります。 TEEは、TAM証明書およびルート証明書までの中間証明書を含むTAM認証パス全体を検証する責任があります。詳細については、[RFC5280]のセクション6を参照してください。 このような検証には、通常、証明書の取り消しをチェックすることが含まれますが、証明書ステータスチェックプロトコルは、TEEPを使用する制約のあるデバイスにスケーリングダウンできない場合があります。
To address the above issues, a certification path update mechanism is expected from TAM operators, so that the TAM can get a new certification path that can be validated by a TEEP Agent. In addition, the Trust Anchor in the TEEP Agent's Trust Anchor Store may need to be updated. To address this, a TEE Trust Anchor update mechanism is expected from device equipment manufacturers (OEMs), such as using the TEEP protocol to distribute new Trust Anchors.
上記の問題に対処するために、TAMオペレーターから認証パスの更新メカニズムが期待されています。これにより、TAMはTEEPエージェントによって検証できる新しい認証パスを取得できます。さらに、TEEPエージェントのTrust Anchor Store内の信頼アンカーを更新する必要があるかもしれません。これに対処するために、デバイス機器メーカー（OEM）からTEE Trust Anchorの更新メカニズムが期待されています。これは、新しいTrust Anchorを配布するためにTEEPプロトコルを使用するなどの方法が考えられます。
Similarly, a root CA for TEE certificates might get compromised, its certificate might expire, or a Trust Anchor other than a root CA certificate may also expire or be compromised. TAMs are responsible for validating the entire TEE certification path, including the TEE certificate and any intermediate certificates up to the root certificate. Such validation includes checking for certificate revocation.
同様に、TEE証明書のルートCAが侵害される可能性があり、その証明書が期限切れになる可能性があります。また、ルートCA証明書以外の信頼アンカーも期限切れになるか、侵害される可能性があります。TAMは、TEE証明書およびルート証明書までの中間証明書を含むTEE認証パス全体を検証する責任があります。このような検証には、証明書の取り消しをチェックすることも含まれます。
If a TEE certification path validation fails, the TEE might be rejected by a TAM, subject to the TAM's policy. To address this, a certification path update mechanism is expected from device OEMs, so that the TEE can get a new certification path that can be validated by a TAM. In addition, the Trust Anchor in the TAM's Trust Anchor Store may need to be updated.
TEE 認証パスの検証に失敗した場合、TAM によって TEE が拒否される可能性があり、その際は TAM のポリシーに従います。これを解決するために、デバイス OEM から認証パスの更新メカニズムが期待されており、これにより TEE が TAM によって検証される新しい認証パスを取得できるようになります。さらに、TAM の Trust Anchor Store 内の Trust Anchor を更新する必要があるかもしれません。
Device TEEs are responsible for validating the supplied TAM certificates. A compromised TAM may bring multiple threats and damage to user devices that it can manage and thus to the Device Owners. Information on devices that the TAM manages may be leaked to a bad actor. A compromised TAM can also install many TAs to launch a DoS attack on devices, for example, by filling up a device's TEE resources reserved for TAs such that other TAs may not get resources to be installed or properly function. It may also install malicious TAs to potentially many devices under the condition that it also has a Trusted Component signer key that is trusted by the TEEs. This makes TAMs high-value targets. A TAM could be compromised without impacting its certificate or raising concern from the TAM's operator.
デバイスTEEは提供されたTAM証明書の検証を担当しています。侵害されたTAMは、管理できるユーザーデバイスに複数の脅威や損害をもたらす可能性があり、それによってデバイス所有者にも損害が及ぶ可能性があります。 TAMが管理するデバイスの情報が悪意のある者に漏洩する可能性があります。侵害されたTAMは、例えば、デバイスのTEEリソースをTAのために予約されているリソースで埋めることにより、他のTAがリソースを取得してインストールされたり正常に機能することができないようにするなど、多くのTAをインストールしてデバイスにDoS攻撃を仕掛けることもできます。また、信頼されているTEEによって信頼されている信頼されたコンポーネント署名者キーを持っている場合、悪意のあるTAを多くのデバイスにインストールすることもできます。これにより、TAMは高い価値の標的となります。 TAMは、その証明書に影響を与えることなく侵害される可能性があり、TAMの運用者からの懸念を引き起こす可能性があります。
To mitigate this threat, TEEP Agents and Device Owners have several options for detecting and mitigating a compromised TAM, including but potentially not limited to the following:
この脅威を緩和するために、TEEPエージェントとデバイス所有者は、侵害されたTAMを検出および緩和するためのいくつかのオプションを持っています。これには、以下のものに限定されないが、以下のものが含まれる可能性があります。
1. Apply an ACL to the TAM key, limiting which Trusted Components the TAM is permitted to install or update.
1. TAMキーにACLを適用し、TAMが許可されているTrusted Componentsのインストールまたは更新を制限します。
2. Use a transparency log to expose a TAM compromise. TAMs publish an out-of-band record of Trusted Component releases, allowing a TEE to cross-check the Trusted Components delivered against the Trusted Components installed in order to detect a TAM compromise.
2. 透過性ログを使用してTAMの妥協を暴露します。TAMは、信頼されるコンポーネントのリリースの帯域外レコードを公開し、TEEがTAMの妥協を検出するために提供された信頼されるコンポーネントとインストールされた信頼されるコンポーネントを相互に照合できるようにします。
3. Use remote attestation of the TAM to prove trustworthiness.
3. TAMのリモートアテステーションを使用して信頼性を証明してください。
It is possible that a rogue developer distributes a malicious Untrusted Application and intends to have a malicious TA installed. Such a TA might be able to escape from malware detection by the REE or access trusted resources within the TEE (but could not access other TEEs or other TAs if the TEE provides isolation between TAs).
悪意のある開発者が悪意のあるUntrusted Applicationを配布し、悪意のあるTAをインストールする意図がある可能性があります。そのようなTAは、REEによるマルウェア検出を回避したり、TEE内の信頼されたリソースにアクセスしたりすることができるかもしれません（ただし、TEEがTA間の隔離を提供している場合、他のTEEや他のTAにはアクセスできません）。
It is the responsibility of the TAM to not install malicious TAs in the first place. The TEEP architecture allows a TEEP Agent to decide which TAMs it trusts via Trust Anchors and delegate the TA authenticity check to the TAMs it trusts.
TAMの責任は、最初から悪意のあるTAをインストールしないことです。TEEPアーキテクチャでは、TEEPエージェントが信頼するTAMを信頼アンカーを介して決定し、信頼するTAMにTAの信頼性チェックを委任することができます。
A TA that was previously considered trustworthy may later be found to be buggy or compromised. In this case, the TAM can initiate the removal of the TA by notifying devices to remove the TA (and potentially notify the REE or Device Owner to remove any Untrusted Application that depend on the TA). If the TAM does not currently have a connection to the TEEP Agent on a device, such a notification would occur the next time connectivity does exist. That is, to recover, the TEEP Agent must be able to reach out to the TAM, for example, whenever the RequestPolicyCheck API (Section 6.2.1) is invoked by a timer or other event.
以前信頼されていたTAが後にバグがあるか、侵害されていることが判明することがあります。この場合、TAMは、TAを削除するようデバイスに通知してTAを削除するように指示することができます（おそらく、TAに依存する信頼できないアプリケーションを削除するようREEまたはデバイス所有者に通知することもできます）。TAMが現在デバイス上のTEEPエージェントに接続していない場合、そのような通知は次回の接続時に行われます。つまり、回復するためには、TEEPエージェントが、たとえば、タイマーまたは他のイベントによってRequestPolicyCheck API（セクション6.2.1）が呼び出されたときにTAMにアクセスできる必要があります。
Furthermore, the policy in the Verifier in an attestation process can be updated so that any evidence that includes the malicious TA would result in an attestation failure. There is, however, a time window during which a malicious TA might be able to operate successfully, which is the validity time of the previous attestation result. For example, if the Verifier in Figure 5 is updated to treat a previously valid TA as no longer trustworthy, any attestation result it previously generated saying that the TA is valid will continue to be used until the attestation result expires. As such, the TAM's Verifier should take into account the acceptable time window when generating attestation results. See [RFC9334] for further discussion.
さらに、アテステーションプロセスにおける検証者のポリシーは更新され、悪意のあるTAを含む証拠がある場合はアテステーションの失敗となります。ただし、悪意のあるTAが成功裏に操作できる可能性がある時間枠があります。それは前回のアテステーション結果の有効期間です。たとえば、図5の検証者が以前に有効だったTAを信頼できないと見なすように更新された場合、TAが有効であるという以前に生成されたアテステーション結果は、アテステーション結果の有効期限が切れるまで引き続き使用されます。そのため、TAMの検証者は、アテステーション結果を生成する際に許容される時間枠を考慮すべきです。詳細については[RFC9334]を参照してください。
TEE device certificates are expected to be long-lived, longer than the lifetime of a device. A TAM certificate usually has a moderate lifetime of 1 to 5 years. A TAM should get renewed or rekeyed certificates. The root CA certificates for a TAM, which are embedded into the Trust Anchor Store in a device, should have long lifetimes that don't require device Trust Anchor updates. On the other hand, it is imperative that OEMs or device providers plan for support of a Trust Anchor update in their shipped devices.
TEE デバイスの証明書は、デバイスの寿命よりも長期間有効であることが期待されています。TAM 証明書は通常、1年から5年の中程度の寿命があります。TAM は証明書の更新または再鍵交換を行う必要があります。デバイスに埋め込まれた Trust Anchor Store に組み込まれる TAM のルート CA 証明書は、デバイスの Trust Anchor の更新を必要としない長期間有効であるべきです。一方、OEM またはデバイスプロバイダーは、出荷されたデバイスの Trust Anchor の更新をサポートする計画を立てることが重要です。
For those cases where TEE devices are given certificates for which no good expiration date can be assigned, the recommendations in Section 4.1.2.5 of [RFC5280] are applicable.
TEEデバイスに有効期限の設定ができない証明書が与えられる場合には、[RFC5280]のセクション4.1.2.5の推奨事項が適用されます。
In some scenarios, it is desirable to protect the TA binary or Personalization Data from being disclosed to the TAM that distributes them. In such a scenario, the files can be encrypted end-to-end between a Trusted Component Signer and a TEE. However, there must be some means of provisioning the decryption key into the TEE and/or some means of the Trusted Component Signer securely learning a public key of the TEE that it can use to encrypt. The Trusted Component Signer cannot necessarily even trust the TAM to report the correct public key of a TEE for use with encryption, since the TAM might instead provide the public key of a TEE that it controls.
いくつかのシナリオでは、TAバイナリや個人化データを配布するTAMから漏洩されるのを防ぐことが望ましい場合があります。そのようなシナリオでは、信頼できるコンポーネントサイナーとTEEの間でファイルをエンドツーエンドで暗号化することができます。ただし、TEEに復号キーをプロビジョニングする手段や、信頼できるコンポーネントサイナーがTEEの公開鍵を安全に学習し、それを使用して暗号化する手段が必要です。信頼できるコンポーネントサイナーは、暗号化に使用するTEEの正しい公開鍵を報告するためにTAMを信頼する必要はなく、TAMは代わりに自分が制御するTEEの公開鍵を提供する可能性があるためです。
One way to solve this is for the Trusted Component Signer to run its own TAM that is only used to distribute the decryption key via the TEEP protocol and the key file can be a dependency in the manifest of the encrypted TA. Thus, the TEEP Agent would look at the Trusted Component manifest to determine if there is a dependency with a TAM URI of the Trusted Component Signer's TAM. The Agent would then install the dependency and continue with the Trusted Component installation steps, including decrypting the TA binary with the relevant key.
これを解決する方法の1つは、Trusted Component Signerが独自のTAMを実行し、TEEPプロトコルを介して復号キーを配布するためだけに使用されるようにすることです。そして、キーファイルは暗号化されたTAのマニフェストの依存関係として指定できます。したがって、TEEPエージェントは、信頼されたコンポーネントのマニフェストを参照して、依存関係にTrusted Component SignerのTAM URIがあるかどうかを確認します。エージェントはその後、依存関係をインストールし、TAのバイナリを関連するキーで復号化するなど、信頼されたコンポーネントのインストール手順を続行します。
The TEEP architecture is applicable to cases where devices have a TEE that protects data and code from the REE administrator. In such cases, the TAM administrator, not the REE administrator, controls the TEE in the devices. Examples include:
TEEPアーキテクチャは、デバイスにTEE（Trusted Execution Environment）があり、そのTEEがデータやコードをREE（Rich Execution Environment）の管理者から保護する場合に適用されます。このような場合、デバイス内のTEEはREEの管理者ではなく、TAM（TEE Administration Mode）の管理者が制御します。例としては、以下が挙げられます：
* A cloud hoster may be the REE administrator where a customer administrator controls the TEE hosted in the cloud.
* クラウドホスターは、顧客管理者がクラウドにホストされたTEEを制御するREE管理者である場合があります。
* A device manufacturer might control the TEE in a device purchased by a customer.
* デバイス製造業者は、顧客が購入したデバイス内のTEEを制御するかもしれません。
The privacy risk is that data in the REE might be susceptible to disclosure to the TEE administrator. This risk is not introduced by the TEEP architecture, but it is inherent in most uses of TEEs. This risk can be mitigated by making sure the REE administrator explicitly chooses to have a TEE that is managed by another party. In the cloud hoster example, this choice is made by explicitly offering a service to customers to provide TEEs for them to administer. In the device manufacturer example, this choice is made by the customer choosing to buy a device made by a given manufacturer.
プライバシーのリスクは、REE内のデータがTEE管理者に開示される可能性があることです。このリスクはTEEPアーキテクチャによって導入されるものではありませんが、ほとんどのTEEの使用には固有のものです。このリスクは、REE管理者が別のパーティに管理されるTEEを選択することを明示的に選択することで軽減することができます。クラウドホスターの例では、この選択は、顧客にTEEを提供して管理するサービスを明示的に提供することによって行われます。デバイスメーカーの例では、この選択は、顧客が特定のメーカーが製造したデバイスを購入することを選択することによって行われます。
This document has no IANA actions.
この文書にはIANAのアクションはありません。
[CC-Overview]
Confidential Computing Consortium, "Confidential
Computing: Hardware-Based Trusted Execution for
Applications and Data", November 2022,
<https://confidentialcomputing.io/wp-
content/uploads/sites/85/2021/03/
confidentialcomputing_outreach_whitepaper-8-5x11-1.pdf>.
[CC-Technical-Analysis]
Confidential Computing Consortium, "A Technical Analysis
of Confidential Computing", v1.3, November 2022,
<https://confidentialcomputing.io/wp-
content/uploads/sites/10/2023/03/CCC-A-Technical-Analysis-
of-Confidential-Computing-v1.3_unlocked.pdf>.
[EAT] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", Work in
Progress, Internet-Draft, draft-ietf-rats-eat-21, 30 June
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
rats-eat-21>.
[GPTEE] GlobalPlatform, "TEE System Architecture v1.3",
GlobalPlatform GPD_SPE_009, May 2022,
<https://globalplatform.org/specs-library/tee-system-
architecture/>.
[GSMA] GSM Association, "SGP.22 RSP Technical Specification",
Version 2.2.2, June 2020, <https://www.gsma.com/esim/wp-
content/uploads/2020/06/SGP.22-v2.2.2.pdf>.
[OP-TEE] TrustedFirmware.org, "OP-TEE Documentation",
<https://optee.readthedocs.io/en/latest/>.
[OTRP] GlobalPlatform, "TEE Management Framework: Open Trust
Protocol (OTrP) Profile v1.1", GlobalPlatform GPD_SPE_123,
July 2020, <https://globalplatform.org/specs-library/tee-
management-framework-open-trust-protocol/>.
[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-03, 10 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
daa-03>.
[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>.
[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>.
[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>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>.
[RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
Firmware Update Architecture for Internet of Things",
RFC 9019, DOI 10.17487/RFC9019, April 2021,
<https://www.rfc-editor.org/info/rfc9019>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[SGX] Intel, "Intel(R) Software Guard Extensions (Intel (R)
SGX)", <https://www.intel.com/content/www/us/en/
architecture-and-technology/software-guard-
extensions.html>.
[SUIT-MANIFEST]
Moran, B., Tschofenig, H., Birkholz, H., Zandberg, K., and
O. Rønningstad, "A Concise Binary Object Representation
(CBOR)-based Serialization Format for the Software Updates
for Internet of Things (SUIT) Manifest", Work in Progress,
Internet-Draft, draft-ietf-suit-manifest-22, 27 February
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
suit-manifest-22>.
[TEEP] Tschofenig, H., Pei, M., Wheeler, D. M., Thaler, D., and
A. Tsukamoto, "Trusted Execution Environment Provisioning
(TEEP) Protocol", Work in Progress, Internet-Draft, draft-
ietf-teep-protocol-15, 3 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teep-
protocol-15>.
[TEEP-HTTP]
Thaler, D., "HTTP Transport for Trusted Execution
Environment Provisioning: Agent Initiated Communication",
Work in Progress, Internet-Draft, draft-ietf-teep-otrp-
over-http-15, 27 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teep-
otrp-over-http-15>.
[TrustZone]
Arm, "TrustZone for Cortex-A",
<https://www.arm.com/technologies/trustzone-for-cortex-a>.
We would like to thank Nick Cook, Minho Yoo, Brian Witten, Tyler Kim, Alin Mutu, Juergen Schoenwaelder, Nicolae Paladi, Sorin Faibish, Ned Smith, Russ Housley, Jeremy O'Donoghue, Anders Rundgren, and Brendan Moran for their feedback.
私たちは、Nick Cook、Minho Yoo、Brian Witten、Tyler Kim、Alin Mutu、Juergen Schoenwaelder、Nicolae Paladi、Sorin Faibish、Ned Smith、Russ Housley、Jeremy O'Donoghue、Anders Rundgren、およびBrendan Moranに対してフィードバックをいただきたいと思います。
Andrew Atyeo
Intercede
Email: andrew.atyeo@intercede.com
Liu Dapeng
Alibaba Group
Email: maxpassion@gmail.com
Mingliang Pei
Broadcom
Email: mingliang.pei@broadcom.com
Hannes Tschofenig
Email: hannes.tschofenig@gmx.net
Dave Thaler
Microsoft
Email: dthaler@microsoft.com
David Wheeler
Amazon
Email: davewhee@amazon.com