Independent Submission H. Tschofenig
Request for Comments: 9783 H-BRS
Category: Informational S. Frost
ISSN: 2070-1721 M. Brossard
Arm Limited
A. Shaw
HP Labs
T. Fossati
Linaro
June 2025
Arm's Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, along with open-source reference implementations, aimed at helping device makers and chip manufacturers integrate best-practice security into their products. Devices that comply with PSA can generate attestation tokens as described in this document, which serve as the foundation for various protocols, including secure provisioning and network access control. This document specifies the structure and semantics of the PSA attestation token.
ARMのプラットフォームセキュリティアーキテクチャ（PSA）は、デバイスメーカーとチップメーカーがベストプラクティスセキュリティを製品に統合するのを支援することを目的としたオープンソースリファレンス実装とともに、ハードウェアおよびファームウェアセキュリティの仕様のファミリです。PSAに準拠するデバイスは、このドキュメントで説明されているように、安全なプロビジョニングやネットワークアクセス制御など、さまざまなプロトコルの基盤として機能するように、証明トークンを生成できます。このドキュメントは、PSA証明トークンの構造とセマンティクスを指定します。
The PSA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes the claims used in an attestation token generated by PSA-compliant systems, how these claims are serialized for transmission, and how they are cryptographically protected.
PSA証明トークンは、エンティティの証明トークン（EAT）のプロファイルです。この仕様では、PSA準拠システムによって生成された証明トークンで使用されるクレーム、これらのクレームが送信のためにどのようにシリアル化されているか、およびそれらが暗号化されている方法について説明します。
This Informational document is published as an Independent Submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF.
この情報文書は、ARMのアーキテクチャとの相互運用性を改善するための独立した提出物として公開されています。IETFの標準でも製品でもありません。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開されることが承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。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/rfc9783.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9783で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
2. Conventions and Definitions
3. PSA Attester Model
4. PSA Claims
4.1. Caller Claims
4.1.1. Nonce
4.1.2. Client ID
4.2. Target Identification Claims
4.2.1. Instance ID
4.2.2. Implementation ID
4.2.3. Certification Reference
4.3. Target State Claims
4.3.1. Security Lifecycle
4.3.2. Boot Seed
4.4. Software Inventory Claims
4.4.1. Software Components
4.5. Verification Claims
4.5.1. Verification Service Indicator
4.5.2. Profile Definition
4.6. Backwards Compatibility Considerations
5. Profiles
5.1. Baseline Profile
5.1.1. Token Encoding and Signing
5.1.2. Freshness Model
5.1.3. Synopsis
5.2. Profile TFM
6. Collated CDDL
7. Scalability Considerations
8. PSA Token Verification
8.1. AR4SI Trustworthiness Claims Mappings
8.2. Endorsements, Reference Values, and Verification Key
Material
9. Security and Privacy Considerations
10. IANA Considerations
10.1. CBOR Web Token Claims Registration
10.1.1. Client ID Claim
10.1.2. Security Lifecycle Claim
10.1.3. Implementation ID Claim
10.1.4. Certification Reference Claim
10.1.5. Software Components Claim
10.1.6. Verification Service Indicator Claim
10.2. Media Types
10.3. CoAP Content-Formats Registration
10.3.1. Registry Contents
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Examples
A.1. COSE Sign1 Token
A.2. COSE Mac0 Token
Acknowledgments
Contributors
Authors' Addresses
The Platform Security Architecture (PSA) [PSA] is a set of hardware and firmware specifications backed by reference implementations and a security certification program [PSACertified]. The security specifications have been published by Arm, while the certification program and reference implementations are the result of a collaborative effort by companies from multiple sectors, including evaluation laboratories, IP semiconductor vendors, and security consultancies. The main objective of the PSA initiative is to assist device manufacturers and chip makers in incorporating best-practice security measures into their products.
プラットフォームセキュリティアーキテクチャ（PSA）[PSA]は、参照実装とセキュリティ認証プログラム[PSACERTIFIED]に裏付けられたハードウェアおよびファームウェア仕様のセットです。セキュリティ仕様はARMによって公開されていますが、認定プログラムと参照実装は、評価研究所、IP半導体ベンダー、セキュリティコンサルタントなど、複数のセクターの企業による共同の取り組みの結果です。PSAイニシアチブの主な目的は、デバイスメーカーとチップメーカーがベストプラクティスセキュリティ対策を製品に組み込むのを支援することです。
Many devices now have Trusted Execution Environments (TEEs) that provide a safe space for security-sensitive code, such as cryptography, secure boot, secure storage, and other essential security functions. These security functions are typically exposed through a narrow and well-defined interface, and can be used by operating system libraries and applications.
現在、多くのデバイスには、暗号化、セキュアなブート、セキュアストレージ、その他の重要なセキュリティ関数など、セキュリティに敏感なコードの安全なスペースを提供する信頼できる実行環境（TEE）があります。これらのセキュリティ関数は通常、狭く明確に定義されたインターフェイスを介して公開され、オペレーティングシステムライブラリとアプリケーションで使用できます。
As outlined in the Remote ATtestation procedureS (RATS) Architecture [RFC9334], an Attester produces a signed collection of Claims that constitutes Evidence about its Target Environment. This document focuses on the output provided by PSA's Initial Attestation API [PSA-API]. This output corresponds to Evidence in [RFC9334] and, as a design decision, the PSA attestation token is a profile of the Entity Attestation Token (EAT) [EAT]. Note that there are other profiles of EAT available for use with different use cases and by different attestation technologies, such as [RATS-TDX] and [RATS-QWESTOKEN].
リモートの証明手順（RATS）アーキテクチャ[RFC9334]で概説されているように、Attesterは、ターゲット環境に関する証拠を構成する署名された主張のコレクションを作成します。このドキュメントは、PSAの最初の証明API [PSA-API]によって提供される出力に焦点を当てています。この出力は[RFC9334]の証拠に対応し、設計上の決定として、PSA証明トークンは、エンティティ証明トークン（EAT）[EAT]のプロファイルです。さまざまなユースケースで使用できる他のEATプロファイルがあり、[rats-tdx]や[rats-qwestoken]などのさまざまな証明技術によって使用できることに注意してください。
Since the PSA tokens are also consumed by services outside the device, there is an actual need to ensure interoperability. Interoperability needs are addressed here by describing the exact syntax and semantics of the attestation claims, and defining the way these claims are encoded and cryptographically protected.
PSAトークンはデバイス外のサービスによっても消費されるため、相互運用性を確保する必要があります。ここでは、相互運用性のニーズに対処し、証明の主張の正確な構文とセマンティクスを記述し、これらのクレームがエンコードされ、暗号化された方法を定義します。
Further details on concepts expressed below can be found in the PSA Security Model documentation [PSA-SM].
以下の概念の詳細については、PSAセキュリティモデルのドキュメント[PSA-SM]をご覧ください。
As mentioned in the abstract, this memo documents a vendor extension to the RATS architecture and is not a standard.
要約で述べたように、このメモはラットアーキテクチャのベンダー拡張機能を文書化しており、標準ではありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
The terms Attester, Relying Party, Verifier, Attestation Result, Target Environment, Attesting Environment, and Evidence are defined in [RFC9334]. We use the term "receiver" to refer to Relying Parties and Verifiers.
証明、依存者、検証者、証明の結果、ターゲット環境、環境の証明、および証拠という用語は、[RFC9334]で定義されています。「受信機」という用語を使用して、頼るパーティーと検証因子を指します。
We use the terms Evidence, "PSA attestation token", and "PSA token" interchangeably. The terms "sender" and Attester are used interchangeably. Likewise, we use the terms Verifier and "verification service" interchangeably.
証拠という用語「PSA Attestation Token」と「PSA Token」という用語を互換性があります。「Sender」とAttesterという用語は、交換可能に使用されます。同様に、Verifierと「検証サービス」という用語を交換可能に使用します。
Root of Trust (RoT):
ルートオブトラスト（腐敗）：
The minimal set of software, hardware, and data that has to be implicitly trusted in the platform; there is no software or hardware at a deeper level that can verify that the RoT is authentic and unmodified. An example of RoT is an initial bootloader in ROM, which contains cryptographic functions and credentials, running on a specific hardware platform.
プラットフォームで暗黙的に信頼する必要があるソフトウェア、ハードウェア、およびデータの最小限のセット。より深いレベルのソフトウェアやハードウェアはありません。これにより、腐敗が本物で変更されていないことを確認できます。腐敗の例は、特定のハードウェアプラットフォームで実行されている暗号化関数と資格情報を含むROMの初期ブートローダーです。
Secure Processing Environment (SPE):
セキュア処理環境（SPE）：
A platform's processing environment for software that provides confidentiality and integrity for its runtime state, from software and hardware, outside of the SPE. Contains trusted code and trusted hardware. (Equivalent to a TEE, "secure world", or "secure enclave".)
SPE以外のソフトウェアとハードウェアから、ランタイム状態に機密性と整合性を提供するソフトウェア用のプラットフォームの処理環境。信頼できるコードと信頼できるハードウェアが含まれています。（Tシャツ、「セキュアワールド」、または「セキュアエンクレーブ」に相当します。）
Non-Secure Processing Environment (NSPE):
非セキュア処理環境（NSPE）：
The security domain (Application domain) outside of the SPE that typically contains the application firmware, real-time operating systems, applications, and general hardware. (Equivalent to Rich Execution Environment (REE), or "normal world".)
通常、アプリケーションファームウェア、リアルタイムオペレーティングシステム、アプリケーション、および一般的なハードウェアを含むSPEの外側のセキュリティドメイン（アプリケーションドメイン）。（豊富な実行環境（REE）、または「通常の世界」に相当します。）
In this document, the structure of data is specified in Concise Data Definition Language (CDDL) [RFC8610].
このドキュメントでは、データの構造は簡潔なデータ定義言語（CDDL）[RFC8610]で指定されています。
Figure 1 outlines the structure of the PSA Attester according to the conceptual model described in Section 3.1 of [RFC9334].
図1は、[RFC9334]のセクション3.1で説明されている概念モデルに従って、PSA攻撃の構造の概要を示しています。
.----------.
| Verifier |
'----------'
^
|
PSA Token |
|
.--------------------------------------------------------|----------.
| .------------------------------------------------------|--------. |
| | Attesting Environment | | |
| | .------------. .-----. .------+------. | |
| | | Main | | Main | | Initial | | |
| | | Bootloader +--->| Boot |<---+ Attestation | | |
| | | | W | State | R | Service | | |
| | '-----+------' '-----' '-------------' | |
| '----------------------|----------------------------------------' |
| .------------+--------------+---------------. |
| .--------|-------------|--------------|----------------|--------. |
| | | | | | | |
| | .------o-----. .-----o-------. .----o--------. .-----o------. | |
| | | Updateable | | Application | | Application | | PSA RoT | | |
| | | PSA RoT | | RoT | | Loader | | Parameters | | |
| | '------------' '-------------' '-------------' '------------' | |
| | Target Environment | |
| '---------------------------------------------------------------' |
'-------------------------------------------------------------------'
Legend:
---> read ---> write ---o measure
R W
Figure 1: PSA Attester
図1：PSA Attester
The PSA Attester is a relatively straightforward embodiment of the RATS Attester with exactly one Attesting Environment and one or more Target Environments.
PSA Attesterは、1つの証明環境と1つ以上のターゲット環境を備えたラットの攻撃の比較的単純な具体化です。
The Attesting Environment is responsible for collecting the information to be represented in PSA claims and to assemble them into Evidence. The Attesting Environment is made of two cooperating components:
証明環境は、PSAクレームで表される情報を収集し、それらを証拠に組み立てる責任があります。証明環境は、2つの協力的なコンポーネントで構成されています。
* Executing at boot-time, the Main Bootloader measures the Target Environments (i.e., loaded software components and all the relevant PSA RoT parameters) and stores the recorded information in secure memory (Main Boot State). See Figure 2.
* ブートタイムで実行するメインブートローダーは、ターゲット環境（つまり、ロードされたソフトウェアコンポーネントと関連するすべてのPSA ROTパラメーター）を測定し、記録された情報を安全なメモリ（メインブートステート）に保存します。図2を参照してください。
i-th Target Main Boot Main Boot
Environment Loader State
| | |
.--------|-------------|-------------|----.
| loop i | | | |
| | measure | | |
| |o------------+ | |
| | | write | |
| | | measurement | |
| | +------------>| |
'--------|-------------|-------------|----'
| | |
Figure 2: PSA Attester Boot Phase
図2：PSA Attesterブートフェーズ
* The Initial Attestation Service (executing at run-time in SPE) answers requests coming from NSPE via the PSA attestation API [PSA-API], collects and formats the claims from Main Boot State, and uses the Initial Attestation Key (IAK) to sign them and produce Evidence. See Figure 3.
* 最初の証明サービス（SPEの実行時に実行）は、PSA Atestation API [PSA-API]を介してNSPEからのリクエストを回答し、メインブート状態からクレームを収集およびフォーマットし、最初の証明キー（IAK）を使用して署名して証拠を作成します。図3を参照してください。
The word "Initial" in "Initial Attestation Service" refers to a limited set of Target Environments, namely those representing the first foundational stages establishing the chain of trust of a PSA device. Collecting measurements from Target Environments after this initial phase is outside the scope of this specification. Extensions of this specification could collect up-to-date measurements from additional Target Environments and define additional claims for use within those environments, but these are, by definition, custom.
「初期証明サービス」の「初期」という言葉は、ターゲット環境の限られたセット、つまりPSAデバイスの信頼のチェーンを確立する最初の基礎段階を表すものを指します。ターゲット環境から測定を収集したこの初期段階は、この仕様の範囲外です。この仕様の拡張は、追加のターゲット環境から最新の測定値を収集し、それらの環境内で使用する追加のクレームを定義することができますが、これらは定義上、カスタムです。
Initial
Main Boot Attestation
State Service Verifier
| | |
.--------|----------------|-----------|----.
| loop i | read | | |
| | measurement of | | |
| | i-th Target | | |
| | Environment | | |
| |<---------------+ | |
'--------|----------------|-----------|----'
| .---+ |
| sign | | |
| '-->| |
| | PSA Token |
| +---------->|
| | |
Figure 3: PSA Attester Run-Time Phase
図3：PSA Attesterランタイムフェーズ
The Target Environments can be of four types, some of which may or may not be present depending on the device architecture:
ターゲット環境には4つのタイプがありますが、そのうちのいくつかはデバイスアーキテクチャに応じて存在する場合と存在する場合があります。
* (A subset of) the PSA RoT parameters, including Instance and Implementation IDs.
* （のサブセット）インスタンスと実装IDを含むPSA ROTパラメーター。
* The updateable PSA RoT, including the Secure Partition Manager and all PSA RoT services.
* 安全なパーティションマネージャーとすべてのPSA ROTサービスを含む、更新可能なPSA ROT。
* The (optional) Application RoT, that is any application-defined security service possibly making use of the PSA RoT services.
* （オプションの）アプリケーションの腐敗は、PSA ROTサービスを利用する可能性のあるアプリケーション定義のセキュリティサービスです。
* The loader of the application software running in NSPE.
* NSPEで実行されているアプリケーションソフトウェアのローダー。
A reference implementation of the PSA Attester is provided by [TF-M].
PSA Attesterの参照実装は[TF-M]によって提供されます。
This section describes the claims to be used in a PSA attestation token. A more comprehensive treatment of the EAT profiles defined by PSA is found in Section 5.
このセクションでは、PSA証明トークンで使用されるクレームについて説明します。PSAで定義されたEATプロファイルのより包括的な処理は、セクション5にあります。
CDDL [RFC8610] along with text descriptions is used to define each claim independent of encoding. The following CDDL types are reused by different claims:
CDDL [RFC8610]とテキストの説明とともに、エンコードとは無関係に各クレームを定義するために使用されます。次のCDDLタイプは、さまざまなクレームによって再利用されます。
psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64
Two conventions are used to encode the Right-Hand-Side (RHS) of a claim. The postfix -label is used for EAT-defined claims and the postfix -key is used for PSA-originated claims.
2つの規則が使用され、クレームの右側（RHS）をエンコードします。Postfix -LabelはEAT定義されたクレームに使用され、Postfix -KeyはPSA誘発請求に使用されます。
The EAT [EAT] "nonce" (claim key 10) is used to carry the challenge provided by the caller to demonstrate freshness of the generated token.
Eat [Eat] "Nonce"（クレームキー10）は、発信者が提供するチャレンジを運ぶために使用され、生成されたトークンの新鮮さを実証します。
Since the EAT nonce claim offers flexibility for different attestation technologies, this specification applies the following constraints to the nonce-type:
EAT NonCeクレームはさまざまなAttestation Technologiesに柔軟性を提供するため、この仕様はNonCeタイプに次の制約を適用します。
* The length MUST be either 32, 48, or 64 bytes.
* 長さは32、48、または64バイトのいずれかでなければなりません。
* Only a single nonce value is conveyed. The array notation MUST NOT be used for encoding the nonce value.
* 単一のNonCe値のみが伝えられます。Array表記は、NonCe値をエンコードするために使用してはなりません。
This claim MUST be present in a PSA attestation token.
この主張は、PSA証明トークンに存在する必要があります。
psa-nonce = (
nonce-label => psa-hash-type
)
The Client ID claim represents the security domain of the caller.
クライアントIDクレームは、発信者のセキュリティドメインを表します。
In PSA, a security domain is represented by a signed integer whereby negative values represent callers from the NSPE and where positive IDs represent callers from the SPE. The value 0 is not permitted.
PSAでは、セキュリティドメインは署名された整数によって表されます。これにより、負の値はNSPEからの発信者を表し、正のIDがSPEからの発信者を表します。値0は許可されていません。
For an example definition of client IDs, see the PSA Firmware Framework [PSA-FF].
クライアントIDの定義の例については、PSAファームウェアフレームワーク[PSA-FF]を参照してください。
It is essential that this claim is checked in the verification process to ensure that a security domain, i.e., an attestation endpoint, cannot spoof a report from another security domain.
このクレームが検証プロセスでチェックされ、セキュリティドメイン、つまり証明のエンドポイントが別のセキュリティドメインからのレポートを押し付けることができないことを確認することが不可欠です。
This claim MUST be present in a PSA attestation token.
この主張は、PSA証明トークンに存在する必要があります。
psa-client-id-nspe-type = -2147483648...0
psa-client-id-spe-type = 1..2147483647
psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type
psa-client-id = (
psa-client-id-key => psa-client-id-type
)
The Instance ID claim represents the unique identifier of the IAK. The full definition is in [PSA-SM].
インスタンスIDクレームは、IAKの一意の識別子を表します。完全な定義は[PSA-SM]にあります。
The EAT ueid (claim key 256) of type RAND is used. The following constraints apply to the ueid-type:
タイプRANDのEAT UEID（クレームキー256）が使用されます。UEIDタイプには、次の制約が適用されます。
* The length MUST be 33 bytes.
* 長さは33バイトでなければなりません。
* The first byte MUST be 0x01 (RAND) followed by the 32-byte unique identifier of the IAK. [PSA-API] provides implementation options for deriving the IAK unique identifier from the IAK itself.
* 最初のバイトは0x01（rand）で、次にiakの32バイトの一意の識別子でなければなりません。[PSA-API]は、IAK自体からIAK一意の識別子を導出するための実装オプションを提供します。
This claim MUST be present in a PSA attestation token.
この主張は、PSA証明トークンに存在する必要があります。
psa-instance-id-type = bytes .size 33
psa-instance-id = (
ueid-label => psa-instance-id-type
)
The Implementation ID claim uniquely identifies the hardware assembly of the immutable PSA RoT. A verification service uses this claim to locate the details of the PSA RoT implementation from an Endorser or manufacturer. Such details are used by a verification service to determine the security properties or certification status of the PSA RoT implementation.
実装IDは、不変のPSA ROTのハードウェアアセンブリを一意に識別すると主張しています。検証サービスは、この主張を使用して、承認者またはメーカーからのPSA ROT実装の詳細を見つけます。このような詳細は、PSA ROT実装のセキュリティプロパティまたは認証ステータスを決定するために検証サービスによって使用されます。
The value and format of the ID is decided by the manufacturer or a particular certification scheme. For example, the ID could take the form of a product serial number, database ID, or other appropriate identifier.
IDの値と形式は、メーカーまたは特定の認証スキームによって決定されます。たとえば、IDは、製品のシリアル番号、データベースID、またはその他の適切な識別子の形式を取得できます。
This claim MUST be present in a PSA attestation token.
この主張は、PSA証明トークンに存在する必要があります。
Note that this identifies the PSA RoT implementation, not a particular instance. To uniquely identify an instance, see the Instance ID claim Section 4.2.1.
これは、特定のインスタンスではなく、PSA ROT実装を識別することに注意してください。インスタンスを一意に識別するには、インスタンスIDクレームセクション4.2.1を参照してください。
psa-implementation-id-type = bytes .size 32
psa-implementation-id = (
psa-implementation-id-key => psa-implementation-id-type
)
The Certification Reference claim is used to link the class of chip and PSA RoT of the attesting device to an associated entry in the PSA Certification database. The Certification Reference claim MUST be represented as a string made of nineteen numeric characters: a thirteen-digit EAN-13 [EAN-13] followed by a dash "-" and the five-digit versioning information described in [PSA-Cert-Guide].
認証リファレンスクレームは、AttestingデバイスのChIPおよびPSA ROTのクラスをPSA認定データベースの関連するエントリにリンクするために使用されます。認証参照請求は、19の数値文字で作られた文字列として表す必要があります：13桁のEAN-13 [EAN-13]に続いて、[PSA-Cert-Guide]で説明されている5桁のバージョン情報が続きます。
Linking to the PSA Certification entry can still be achieved if this claim is not present in the token by making an association at a Verifier between the reference value and other token claim values, for example, the Implementation ID.
PSA認証エントリへのリンクは、この請求がトークンに存在しない場合でも、参照値と他のトークンクレーム値、たとえば実装IDの間の評価を行うことにより、トークンに存在しない場合でも達成できます。
This claim MAY be present in a PSA attestation token.
この主張は、PSA証明トークンに存在する場合があります。
psa-certification-reference-type = text .regexp "[0-9]{13}-[0-9]{5}"
psa-certification-reference = (
? psa-certification-reference-key =>
psa-certification-reference-type
)
The Security Lifecycle claim represents the current lifecycle state of the PSA RoT. The state is represented by an integer that is divided to convey a major state and a minor state. A major state is mandatory and defined by [PSA-SM]. A minor state is optional and 'IMPLEMENTATION DEFINED'. The PSA security lifecycle state and implementation state are encoded as follows:
セキュリティライフサイクルの主張は、PSA腐敗の現在のライフサイクル状態を表しています。状態は、主要な状態と小国家を伝えるために分割された整数によって表されます。主要な状態は必須であり、[PSA-SM]によって定義されています。マイナー状態はオプションであり、「実装が定義されている」。PSAセキュリティライフサイクルの状態と実装状態は、次のようにエンコードされています。
* major[15:8] - PSA security lifecycle state, and
* メジャー[15：8] -PSAセキュリティライフサイクル状態、および
* minor[7:0] - IMPLEMENTATION DEFINED state.
* マイナー[7：0] - 実装定義状態。
The PSA lifecycle states are illustrated in Figure 4. For PSA, a Verifier can only trust reports from the PSA RoT when it is in SECURED or NON_PSA_ROT_DEBUG major states.
PSAライフサイクルの状態を図4に示します。PSAの場合、検証者はPSA ROTからのレポートのみをセキュリティで保護している場合、またはnon_psa_rot_debugの主要状態です。
This claim MUST be present in a PSA attestation token.
この主張は、PSA証明トークンに存在する必要があります。
.-------------------------.
| Device Assembly and Test |
'------------+------------'
| Device
| Lockdown
v
.----------------------.
| PSA RoT Provisioning |
'-----------+----------'
|
Provisioning | .------------------.
Lockdown | | |
v v |
.----------------. |
.-------------+ Secured +-------. |
| '-+--------------' | |
| | ^ Debug |
| Debug | | |
| | Recoverable | Recoverable
| v | v |
| .----------------+--. .----------+----.
| | (Non-Recoverable) | | Recoverable |
| | Non-PSA RoT Debug | | PSA RoT Debug |
| '---------+---------' '------+--------'
| | |
Terminate Non-Recoverable PSA RoT Compromised
| | |
| v |
| .----------------. |
'------------>| Decommissioned |<--------'
'----------------'
Figure 4: PSA Lifecycle States
図4：PSAライフサイクルの状態
The CDDL representation is shown below. Table 1 provides the mappings between Figure 4 and the data model.
CDDL表現を以下に示します。表1に、図4とデータモデルの間のマッピングを示します。
psa-lifecycle-unknown-type = 0x0000..0x00ff
psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff
psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff
psa-lifecycle-secured-type = 0x3000..0x30ff
psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff
psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff
psa-lifecycle-decommissioned-type = 0x6000..0x60ff
psa-lifecycle-type =
psa-lifecycle-unknown-type /
psa-lifecycle-assembly-and-test-type /
psa-lifecycle-psa-rot-provisioning-type /
psa-lifecycle-secured-type /
psa-lifecycle-non-psa-rot-debug-type /
psa-lifecycle-recoverable-psa-rot-debug-type /
psa-lifecycle-decommissioned-type
psa-lifecycle = (
psa-lifecycle-key => psa-lifecycle-type
)
psa-lifecycle-unknown-type is not shown in Figure 4; it represents an invalid state that must not occur in a system.
PSA-Lifecycle-Unknown-Typeは図4には示されていません。これは、システムで発生してはならない無効な状態を表しています。
+==============================================+===================+
| CDDL | Lifecycle States |
+==============================================+===================+
| psa-lifecycle-unknown-type | |
+----------------------------------------------+-------------------+
| psa-lifecycle-assembly-and-test-type | Assembly and Test |
+----------------------------------------------+-------------------+
| psa-lifecycle-psa-rot-provisioning-type | PSA RoT |
| | Provisioning |
+----------------------------------------------+-------------------+
| psa-lifecycle-secured-type | Secured |
+----------------------------------------------+-------------------+
| psa-lifecycle-non-psa-rot-debug-type | Non-Recoverable |
| | PSA RoT Debug |
+----------------------------------------------+-------------------+
| psa-lifecycle-recoverable-psa-rot-debug-type | Recoverable PSA |
| | RoT Debug |
+----------------------------------------------+-------------------+
| psa-lifecycle-decommissioned-type | Decommissioned |
+----------------------------------------------+-------------------+
Table 1: Lifecycle States Mappings
表1：ライフサイクル状態のマッピング
The "bootseed" claim contains a value created at system boot time that allows differentiation of attestation reports from different boot sessions of a particular entity (i.e., a certain Instance ID).
「ブートシード」クレームには、特定のエンティティ（つまり、特定のインスタンスID）のさまざまなブートセッションからの証明レポートの区別を可能にするシステムブート時間に作成された値が含まれています。
The EAT "bootseed" (claim key 268) is used. The following constraints apply to the binary-data type:
EAT「ブートシード」（クレームキー268）が使用されます。次の制約は、バイナリデータタイプに適用されます。
* The length MUST be between 8 and 32 bytes.
* 長さは8〜32バイトでなければなりません。
This claim MAY be present in a PSA attestation token.
この主張は、PSA証明トークンに存在する場合があります。
psa-boot-seed-type = bytes .size (8..32)
psa-boot-seed = (
boot-seed-label => psa-boot-seed-type
)
The Software Components claim is a list of software components that includes all the software (both code and configuration) loaded by the PSA RoT. This claim MUST be included in attestation tokens produced by an implementation conformant with [PSA-SM].
ソフトウェアコンポーネントのクレームは、PSA ROTによってロードされたすべてのソフトウェア（コードと構成の両方）を含むソフトウェアコンポーネントのリストです。このクレームは、[PSA-SM]に適合した実装によって生成される証明トークンに含める必要があります。
Each entry in the Software Components list describes one software component using the attributes described in the following subsections. Unless explicitly stated, the presence of an attribute is OPTIONAL.
ソフトウェアコンポーネントリストの各エントリは、次のサブセクションで説明されている属性を使用して1つのソフトウェアコンポーネントを記述します。明示的に述べられない限り、属性の存在はオプションです。
Note that a Relying Party will typically see the result of the appraisal process from the Verifier in form of an Attestation Result rather than the PSA token from the attesting endpoint as described in [RFC9334]. Therefore, a Relying Party is not expected to understand the Software Components claim. Instead, it is for the Verifier to check this claim against the available Reference Values and provide an answer in form of a "high-level" Attestation Result, which may or may not include the original Software Components claim.
頼る当事者は通常、[RFC9334]に記載されているように、証明エンドポイントからのPSAトークンではなく、検証者からの評価プロセスの結果を認証結果の形で見ることに注意してください。したがって、頼る当事者は、ソフトウェアコンポーネントの主張を理解することは期待されていません。代わりに、検証者が利用可能な参照値に対してこのクレームを確認し、「高レベルの」証明結果の形での回答を提供することです。
psa-software-component = {
? &(measurement-type: 1) => text
&(measurement-value: 2) => psa-hash-type
? &(version: 4) => text
&(signer-id: 5) => psa-hash-type
? &(measurement-desc: 6) => text
}
psa-software-components = (
psa-software-components-key => [ + psa-software-component ]
)
The Measurement Type attribute (key=1) is a short string representing the role of this software component.
測定型属性（key = 1）は、このソフトウェアコンポーネントの役割を表す短い文字列です。
The following measurement types MAY be used for code measurements:
次の測定タイプは、コード測定に使用できます。
"BL":
「BL」：
a Boot Loader
ブートローダー
"PRoT":
「Prot」：
a component of the PSA Root of Trust
信頼のPSAルートのコンポーネント
"ARoT":
「アロ」：
a component of the Application Root of Trust
信頼のアプリケーションルートのコンポーネント
"App":
"アプリ"：
a component of the NSPE application
NSPEアプリケーションのコンポーネント
"TS":
「TS」：
a component of a Trusted Subsystem
信頼できるサブシステムのコンポーネント
The same labels with a "_CONFIG" postfix (e.g., "PRoT_CONFIG") MAY be used for configuration measurements.
「_config」ポストフィックス（「prot_config」など）を備えた同じラベルを構成測定に使用できます。
This attribute SHOULD be present in a PSA software component unless there is a very good reason to leave it out, for example, in networks with severely constrained bandwidth where sparing a few bytes really makes a difference.
この属性は、たとえば、数枚のバイトを節約する帯域幅の厳しい帯域幅を持つネットワークでそれを除外する非常に正当な理由がない限り、PSAソフトウェアコンポーネントに存在する必要があります。
The Measurement Value attribute (key=2) represents a hash of the invariant software component in memory at startup time. The value MUST be a cryptographic hash of 256 bits or stronger.
測定値属性（key = 2）は、起動時にメモリ内の不変ソフトウェアコンポーネントのハッシュを表します。値は、256ビット以下の暗号化ハッシュでなければなりません。
This attribute MUST be present in a PSA software component.
この属性は、PSAソフトウェアコンポーネントに存在する必要があります。
The Version attribute (key=4) is the issued software version in the form of a text string. The value of this attribute will correspond to the entry in the original signed manifest of the component.
バージョン属性（key = 4）は、テキスト文字列の形式で発行されたソフトウェアバージョンです。この属性の値は、コンポーネントの元の署名されたマニフェストのエントリに対応します。
The Signer ID attribute (key=5) uniquely identifies the signer of the software component. The identification is typically accomplished by hashing the signer's public key. The value of this attribute will correspond to the entry in the original manifest for the component. This can be used by a Verifier to ensure the components were signed by an expected trusted source.
署名者ID属性（key = 5）は、ソフトウェアコンポーネントの署名者を一意に識別します。識別は通常、署名者の公開鍵をハッシュすることによって達成されます。この属性の値は、コンポーネントの元のマニフェストのエントリに対応します。これは、検証剤が使用して、予想される信頼できるソースによってコンポーネントが署名されたことを確認できます。
This attribute MUST be present in a PSA software component to be compliant with [PSA-SM].
この属性は、[PSA-SM]に準拠するには、PSAソフトウェアコンポーネントに存在する必要があります。
The Measurement Description attribute (key=6) contains a string identifying the hash algorithm used to compute the corresponding Measurement Value. The string SHOULD be encoded according to "Hash Name String" in the "Named Information Hash Algorithm Registry" [NAMED-INFO].
測定説明属性（key = 6）には、対応する測定値を計算するために使用されるハッシュアルゴリズムを識別する文字列が含まれています。文字列は、「名前付き情報ハッシュアルゴリズムレジストリ」の「ハッシュ名文字列」に従ってエンコードする必要があります。
The following claims, although part of Evidence, do not reflect the internal state of the Attester. Instead, they aim to help receivers, including Relying Parties, in processing the received attestation Evidence.
以下の主張は、証拠の一部ではあるが、アテスターの内部状態を反映していない。代わりに、彼らは、依存する当事者を含む、受け取った証明の証拠を処理する際に、受信者を支援することを目指しています。
The Verification Service Indicator claim is a hint used by a Relying Party to locate a verification service for the token. The value is a text string that can be used to locate the service (typically, a URL specifying the address of the verification service API). A Relying Party may choose to ignore this claim in favor of other information.
検証サービスインジケーターのクレームは、頼りになる当事者がトークンの検証サービスを見つけるために使用されるヒントです。値は、サービスを見つけるために使用できるテキスト文字列です（通常、検証サービスAPIのアドレスを指定するURL）。頼る当事者は、他の情報を支持してこの主張を無視することを選択する場合があります。
psa-verification-service-indicator-type = text
psa-verification-service-indicator = (
? psa-verification-service-indicator-key =>
psa-verification-service-indicator-type
)
It is assumed that the Relying Party is pre-configured with a list of trusted verification services and that the contents of this hint can be used to look up the correct one. Under no circumstances must the Relying Party be tricked into contacting an unknown and untrusted verification service since the returned Attestation Result cannot be relied on.
頼りになる当事者は、信頼できる検証サービスのリストで事前に構成されており、このヒントの内容を使用して正しいものを調べることができると想定されています。返された証明の結果に依存することができないため、頼る当事者は未知で信頼されていない検証サービスに連絡するようにだまされてはなりません。
Note: This hint requires the Relying Party to parse the content of the PSA token. Since the Relying Party may not be in possession of a trust anchor to verify the digital signature, it uses the hint in the same way as it would treat any other information provided by an external party, which includes attacker-provided data.
注：このヒントでは、PSAトークンのコンテンツを解析するために頼る当事者が必要です。依存者は、デジタル署名を検証するために信託アンカーを所有していない可能性があるため、攻撃者が提供するデータを含む外部当事者が提供する他の情報を扱うのと同じ方法でヒントを使用します。
The Profile Definition claim encodes the unique identifier that corresponds to the EAT profile described by this document. This allows a receiver to assign the intended semantics to the rest of the claims found in the token.
プロファイル定義クレームは、このドキュメントで説明されているEATプロファイルに対応する一意の識別子をエンコードします。これにより、受信者はトークンで見つかった残りのクレームに意図したセマンティクスを割り当てることができます。
The EAT eat_profile (claim key 265) is used.
Eat Eat_Profile（クレームキー265）が使用されます。
The URI encoding MUST be used.
URIエンコードを使用する必要があります。
The value MUST be tag:psacertified.org,2023:psa#tfm for the profile defined in Section 5.2.
値は、セクション5.2で定義されているプロファイルのpsacertified.org、2023：psa＃tfmである必要があります。
Future profiles derived from the baseline PSA profile SHALL create their unique value as described in Section 4.5.2.1.
ベースラインPSAプロファイルから派生した将来のプロファイルは、セクション4.5.2.1で説明されているように、一意の値を作成するものとします。
This claim MUST be present in a PSA attestation token.
この主張は、PSA証明トークンに存在する必要があります。
See Section 4.6 for considerations about backwards compatibility with previous versions of the PSA attestation token format.
PSA証明トークン形式の以前のバージョンとの逆方向の互換性に関する考慮事項については、セクション4.6を参照してください。
psa-profile-type = "tag:psacertified.org,2023:psa#tfm"
psa-profile = (
profile-label => psa-profile-type
)
A new profile is associated with a unique string.
新しいプロファイルは、一意の文字列に関連付けられています。
The string MUST use the URI fragment syntax defined in Section 3.5 of [RFC3986].
文字列は、[RFC3986]のセクション3.5で定義されているURIフラグメント構文を使用する必要があります。
The string SHOULD be short to avoid unnecessary overhead.
ひもは不必要なオーバーヘッドを避けるために短い必要があります。
To avoid collisions, profile authors SHOULD communicate their intent upfront to use a certain string that uses the inquiry form on the website [PSACertified].
衝突を避けるために、プロファイルの著者は、Webサイト[Psacertified]で照会フォームを使用する特定の文字列を使用するために、意図を前もって伝える必要があります。
To derive the value to be used for the eat_profile claim, the string is added as a fragment to the tag:psacertified.org,2023:psa tag URI [RFC4151].
EAT_Profileクレームに使用する値を導出するために、文字列はタグのフラグメントとして追加されます：psacertified.org、2023：psa tag uri [rfc4151]。
For example, a hypothetical profile using only COSE_Mac0 with the AES Message Authentication Code (AES-MAC) may decide to use the string "aes-mac". The eat_profile value would then be tag:psacertified.org,2023:psa#aes-mac.
たとえば、AESメッセージ認証コード（AES-MAC）を使用してCOSE_MAC0のみを使用した仮想プロファイルは、文字列「AES-MAC」を使用することを決定する場合があります。EAT_PROFILE値は、TAG：psacertified.org、2023：psa＃aes-macになります。
An earlier draft of this document [PSA-OLD] identified by the PSA_IOT_PROFILE_1 profile, used claim key values from the "private use range" of the CWT Claims registry. These claim keys have now been deprecated.
PSA_iot_Profile_1プロファイルによって識別されたこのドキュメントの以前のドラフト[PSA-Old]は、CWTクレームレジストリの「プライベート使用範囲」からキー値を使用しました。これらのクレームキーは現在廃止されています。
Table 2 provides the mappings between the deprecated and new claim keys.
表2に、非推奨キーと新しいクレームキーの間のマッピングを示します。
+==============+=================+=================================+
| |PSA_IOT_PROFILE_1|tag:psacertified.org,2023:psa#tfm|
+==============+=================+=================================+
|Nonce |-75008 |10 (EAT nonce) |
+--------------+-----------------+---------------------------------+
|Instance ID |-75009 |256 (EAT euid) |
+--------------+-----------------+---------------------------------+
|Profile |-75000 |265 (EAT eat_profile) |
|Definition | | |
+--------------+-----------------+---------------------------------+
|Client ID |-75001 |2394 |
+--------------+-----------------+---------------------------------+
|Security |-75002 |2395 |
|Lifecycle | | |
+--------------+-----------------+---------------------------------+
|Implementation|-75003 |2396 |
|ID | | |
+--------------+-----------------+---------------------------------+
|Boot Seed |-75004 |268 (EAT bootseed) |
+--------------+-----------------+---------------------------------+
|Certification |-75005 |2398 |
|Reference | | |
+--------------+-----------------+---------------------------------+
|Software |-75006 |2399 |
|Components | | |
+--------------+-----------------+---------------------------------+
|Verification |-75010 |2400 |
|Service | | |
|Indicator | | |
+--------------+-----------------+---------------------------------+
Table 2: Claim Key Mappings
表2：キーマッピングを主張します
The new profile introduces three further changes:
新しいプロファイルは、さらに3つの変更を導入します。
* The "bootseed" claim is now optional and of variable length (see Section 4.3.2).
* 「ブートシード」クレームは現在、オプションであり、長さはさまざまです（セクション4.3.2を参照）。
* The "No Software Measurements" claim has been retired.
* 「ソフトウェア測定なし」の主張は廃止されました。
* The "Certification Reference" claim syntax changed from EAN-13 to EAN-13+5 (see Section 4.2.3).
* 「認証リファレンス」クレーム構文は、EAN-13からEAN-13+5に変更されました（セクション4.2.3を参照）。
To simplify the transition to the token format described in this document, it is RECOMMENDED that Verifiers accept tokens encoded according to the old profile (PSA_IOT_PROFILE_1) as well as to the profile defined in this document (tag:psacertified.org,2023:psa#tfm), at least for the time needed to their devices to upgrade.
このドキュメントで説明されているトークン形式への移行を簡素化するには、Verifiersが古いプロファイル（psa_iot_profile_1）に従ってエンコードされたトークンを受け入れることをお勧めします。
This document defines a baseline with common requirements that all PSA profiles must satisfy. (Note that this does not apply to [PSA-OLD].)
このドキュメントでは、すべてのPSAプロファイルが満たさなければならない一般的な要件を持つベースラインを定義します。（これは[PSA-old]には適用されないことに注意してください。）
This document also defines a "TFM" profile (Section 5.2) that builds on the baseline while constraining the use of COSE algorithms to improve interoperability between Attesters and Verifiers.
このドキュメントでは、ベースラインに基づいて構築されながら、COSEアルゴリズムの使用を制約して、アテッターと検証剤間の相互運用性を改善する「TFM」プロファイル（セクション5.2）を定義します。
Baseline and TFM are what the EAT calls a "partial" and "full" profile, respectively. See Section 6.2 of [EAT] for further details regarding profiles.
ベースラインとTFMは、Eatがそれぞれ「部分的な」プロファイルと呼ぶものです。プロファイルに関する詳細については、[EAT]のセクション6.2を参照してください。
The PSA attestation token is encoded in CBOR [STD94] format. The CBOR representation of a PSA token MUST be "valid" according to the definition in Section 1.2 of RFC 8949 [STD94]. Besides, only definite-length string, arrays, and maps are allowed. Given that a PSA Attester is typically found in a constrained device, it MAY NOT emit CBOR preferred serializations (Section 4.1 of RFC 8949 [STD94]). Therefore, the Verifier MUST be a variation-tolerant CBOR decoder.
PSA証明トークンは、CBOR [STD94]形式でエンコードされています。PSAトークンのCBOR表現は、RFC 8949 [STD94]のセクション1.2の定義に従って「有効」でなければなりません。また、明確な長さの文字列、配列、マップのみが許可されます。PSAの攻撃は通常、制約付きのデバイスに見られることを考えると、CBORの優先シリアル化を放出しない可能性があります（RFC 8949 [STD94]のセクション4.1）。したがって、検証者はバリエーション耐性CBORデコーダーでなければなりません。
Cryptographic protection is obtained by wrapping the psa-token claims set in a COSE Web Token (CWT) [RFC8392]. For asymmetric key algorithms, the signature structure MUST be a tagged (18) COSE_Sign1. For symmetric key algorithms, the signature structure MUST be a tagged (17) COSE_Mac0.
暗号化の保護は、COSE Webトークン（CWT）[RFC8392]に設定されたPSAトークンクレームをラッピングすることにより得られます。非対称キーアルゴリズムの場合、署名構造はタグ付き（18）cose_sign1でなければなりません。対称キーアルゴリズムの場合、署名構造はタグ付き（17）cose_mac0でなければなりません。
Acknowledging the variety of markets, regulations, and use cases in which the PSA attestation token can be used, the baseline profile does not impose any strong requirement on the cryptographic algorithms that need to be supported by Attesters and Verifiers. The flexibility provided by the COSE format should be sufficient to deal with the level of cryptographic agility needed to adapt to specific use cases. It is RECOMMENDED that commonly adopted algorithms are used, such as those discussed in [COSE-ALGS]. It is expected that receivers will accept a wider range of algorithms while Attesters would produce PSA tokens using only one such algorithm.
PSA証明トークンを使用できる市場、規制、およびユースケースのさまざまなことを認識して、ベースラインプロファイルは、アッターと検証者によってサポートされる必要がある暗号化アルゴリズムに強力な要件を課しません。COSE形式で提供される柔軟性は、特定のユースケースに適応するために必要な暗号造影の俊敏性のレベルに対処するのに十分でなければなりません。[Cose-algs]で説明されているアルゴリズムなど、一般的に採用されたアルゴリズムを使用することをお勧めします。受信機はより広い範囲のアルゴリズムを受け入れることが期待され、アテナツはそのようなアルゴリズムを1つだけ使用してPSAトークンを生成します。
The CWT CBOR tag (61) is not used. An application that needs to exchange PSA attestation tokens can wrap the serialized COSE_Sign1 or COSE_Mac0 in the media type defined in Section 10.2 or the CoAP Content-Format defined in Section 10.3.
CWT CBORタグ（61）は使用されていません。PSAの証明トークンを交換する必要があるアプリケーションは、セクション10.2で定義されているメディアタイプまたはセクション10.3で定義されているCOAPコンテンツフォーマットで、シリアル化されたCOSE_SIGN1またはCOSE_MAC0をラップできます。
A PSA token is always directly signed by the PSA RoT. Therefore, a PSA-token claims set (Section 4) is never carried in a Detached EAT bundle (Section 5 of [EAT]).
PSAトークンは、常にPSA ROTによって直接署名されます。したがって、PSAトークンクレームセット（セクション4）は、戸建ての食事バンドル（[EAT]のセクション5）には決して運ばれません。
The PSA token supports the freshness models for attestation Evidence based on nonces and epoch handles (Section 10.2 and Section 10.3 of [RFC9334]) using the "nonce" claim to convey the nonce or epoch handle supplied by the Verifier. No further assumption on the specific remote attestation protocol is made.
PSAトークンは、「ノンセ」クレームを使用して、検証者が提供するノンセまたはエポックハンドルを伝える「ノンセ10.2および[RFC9334]のセクション10.2およびセクション10.3）に基づく認証証拠のために、新鮮さモデルをサポートしています。特定のリモート認証プロトコルに関するさらなる仮定は行われません。
Note that use of epoch handles is constrained by the type restrictions imposed by the eat_nonce syntax. For use in PSA tokens, it must be possible to encode the epoch handle as an opaque binary string between 8 and 64 octets.
エポックハンドルの使用は、EAT_NONCE構文によって課されるタイプの制限によって制約されることに注意してください。PSAトークンで使用するには、8〜64オクテットの間の不透明なバイナリ文字列としてエポックハンドルをエンコードすることが可能である必要があります。
Table 3 presents a concise view of the requirements described in the preceding sections.
表3は、前のセクションで説明した要件の簡潔なビューを示しています。
+==================+=============================================+
| Issue | Profile Definition |
+==================+=============================================+
| CBOR/JSON | CBOR MUST be used. |
+------------------+---------------------------------------------+
| CBOR Encoding | Definite length maps and arrays MUST be |
| | used. |
+------------------+---------------------------------------------+
| CBOR Encoding | Definite length strings MUST be used. |
+------------------+---------------------------------------------+
| CBOR | Variant serialization MAY be used. |
| Serialization | |
+------------------+---------------------------------------------+
| COSE Protection | COSE_Sign1 and/or COSE_Mac0 MUST be used. |
+------------------+---------------------------------------------+
| Algorithms | [COSE-ALGS] SHOULD be used. |
+------------------+---------------------------------------------+
| Detached EAT | Detached EAT bundles MUST NOT be sent. |
| Bundle Usage | |
+------------------+---------------------------------------------+
| Verification Key | Any identification method listed in |
| Identification | Appendix F.1 of [EAT]. |
+------------------+---------------------------------------------+
| Endorsements | See Section 8.2. |
+------------------+---------------------------------------------+
| Freshness | Nonce or epoch ID-based. |
+------------------+---------------------------------------------+
| Claims | Those defined in Section 4. As per general |
| | EAT rules, the receiver MUST NOT error out |
| | on claims it does not understand. |
+------------------+---------------------------------------------+
Table 3: Baseline Profile
表3：ベースラインプロファイル
The TFM profile is appropriate for the code base implemented in [TF-M] and should apply for most derivative implementations. If an implementation changes the requirements described below, then a different profile value should be used (Section 4.5.2.1) to ensure interoperability. This includes a restriction of the profile to a subset of the COSE Protection scheme requirements.
TFMプロファイルは、[TF-M]に実装されているコードベースに適しており、ほとんどのデリバティブ実装に適用する必要があります。実装が以下で説明する要件を変更する場合、相互運用性を確保するために、異なるプロファイル値を使用して（セクション4.5.2.1）する必要があります。これには、COSE保護スキーム要件のサブセットに対するプロファイルの制限が含まれます。
Table 4 presents a concise view of the requirements.
表4は、要件の簡潔なビューを示しています。
The value of the eat_profile MUST be tag:psacertified.org,2023:psa#tfm.
eat_profileの値はタグでなければなりません：psacertified.org、2023：psa＃tfm。
+================+==============================================+
| Issue | Profile Definition |
+================+==============================================+
| CBOR/JSON | See Section 5.1. |
+----------------+----------------------------------------------+
| CBOR Encoding | See Section 5.1. |
+----------------+----------------------------------------------+
| CBOR Encoding | See Section 5.1. |
+----------------+----------------------------------------------+
| CBOR | See Section 5.1. |
| Serialization | |
+----------------+----------------------------------------------+
| COSE | COSE_Sign1 or COSE_Mac0 MUST be used. |
| Protection | |
+----------------+----------------------------------------------+
| Algorithms | The receiver MUST accept ES256, ES384, and |
| | ES512 with COSE_Sign1 and HMAC256/256, |
| | HMAC384/384, and HMAC512/512 with COSE_Mac0; |
| | the sender MUST send one of these. |
+----------------+----------------------------------------------+
| Detached EAT | See Section 5.1. |
| Bundle Usage | |
+----------------+----------------------------------------------+
| Verification | Claim-Based Key Identification |
| Key | (Appendix F.1.4 of [EAT]) using Instance ID. |
| Identification | |
+----------------+----------------------------------------------+
| Endorsements | See Section 8.2. |
+----------------+----------------------------------------------+
| Freshness | See Section 5.1. |
+----------------+----------------------------------------------+
| Claims | See Section 5.1. |
+----------------+----------------------------------------------+
Table 4: TF-M Profile
表4：TF-Mプロファイル
psa-token = {
psa-nonce
psa-instance-id
psa-verification-service-indicator
psa-profile
psa-implementation-id
psa-client-id
psa-lifecycle
psa-certification-reference
? psa-boot-seed
psa-software-components
}
psa-client-id-key = 2394
psa-lifecycle-key = 2395
psa-implementation-id-key = 2396
psa-certification-reference-key = 2398
psa-software-components-key = 2399
psa-verification-service-indicator-key = 2400
nonce-label = 10
ueid-label = 256
boot-seed-label = 268
profile-label = 265
psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64
psa-boot-seed-type = bytes .size (8..32)
psa-boot-seed = (
boot-seed-label => psa-boot-seed-type
)
psa-client-id-nspe-type = -2147483648...0
psa-client-id-spe-type = 1..2147483647
psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type
psa-client-id = (
psa-client-id-key => psa-client-id-type
)
psa-certification-reference-type = text .regexp "[0-9]{13}-[0-9]{5}"
psa-certification-reference = (
? psa-certification-reference-key =>
psa-certification-reference-type
)
psa-implementation-id-type = bytes .size 32
psa-implementation-id = (
psa-implementation-id-key => psa-implementation-id-type
)
psa-instance-id-type = bytes .size 33
psa-instance-id = (
ueid-label => psa-instance-id-type
)
psa-nonce = (
nonce-label => psa-hash-type
)
psa-profile-type = "tag:psacertified.org,2023:psa#tfm"
psa-profile = (
profile-label => psa-profile-type
)
psa-lifecycle-unknown-type = 0x0000..0x00ff
psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff
psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff
psa-lifecycle-secured-type = 0x3000..0x30ff
psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff
psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff
psa-lifecycle-decommissioned-type = 0x6000..0x60ff
psa-lifecycle-type =
psa-lifecycle-unknown-type /
psa-lifecycle-assembly-and-test-type /
psa-lifecycle-psa-rot-provisioning-type /
psa-lifecycle-secured-type /
psa-lifecycle-non-psa-rot-debug-type /
psa-lifecycle-recoverable-psa-rot-debug-type /
psa-lifecycle-decommissioned-type
psa-lifecycle = (
psa-lifecycle-key => psa-lifecycle-type
)
psa-software-component = {
? &(measurement-type: 1) => text
&(measurement-value: 2) => psa-hash-type
? &(version: 4) => text
&(signer-id: 5) => psa-hash-type
? &(measurement-desc: 6) => text
}
psa-software-components = (
psa-software-components-key => [ + psa-software-component ]
)
psa-verification-service-indicator-type = text
psa-verification-service-indicator = (
? psa-verification-service-indicator-key =>
psa-verification-service-indicator-type
)
IAKs (see Section 3) can be either raw public keys or certified public keys.
IAKS（セクション3を参照）は、生の公開鍵または認定公開キーのいずれかです。
Certified public keys require the manufacturer to run the certification authority (CA) that issues X.509 certificates for the IAKs. (Note that operating a CA is a complex and expensive task that may be unaffordable to certain manufacturers.)
認定公開鍵では、製造業者がIAKSのX.509証明書を発行する認定機関（CA）を運営する必要があります。（CAを運営することは、特定のメーカーにとって手に負えない複雑で高価なタスクであることに注意してください。）
Using certified public keys offers better scalability properties when compared to using raw public keys, namely:
認定されたパブリックキーを使用すると、生のパブリックキーを使用するのと比較すると、より良いスケーラビリティプロパティが提供されます。
* Storage requirements for the Verifier are minimized; the same manufacturer's trust anchor is used for any number of devices.
* 検証剤のストレージ要件が最小化されます。同じメーカーの信頼アンカーは、任意の数のデバイスに使用されます。
* The provisioning model is simpler and more robust since there is no need to notify the Verifier about each newly manufactured device.
* プロビジョニングモデルは、新しく製造された各デバイスについて検証者に通知する必要がないため、よりシンプルで堅牢です。
Furthermore, existing and well-understood revocation mechanisms can be readily used.
さらに、既存の、よく理解されている取り消しメカニズムを容易に使用できます。
The IAK's X.509 certificates can be inlined in the PSA token using the x5chain COSE header parameter [COSE-X509] at the cost of an increase in the PSA token size. Section 4.4 of [TLS12-IoT] and Section 15 of [TLS13-IoT] provide guidance for profiling X.509 certificates used in IoT deployments. Note that the exact split between pre-provisioned and inlined certificates may vary depending on the specific deployment. In that respect, x5chain is quite flexible. It can contain the end entity (EE) certification only, the EE and a partial chain, or the EE and the full chain up to the trust anchor (see Section 2 of [COSE-X509] for the details). Constraints around network bandwidth and computing resources available to endpoints, such as network buffers, may dictate a reasonable split point.
IAKのX.509証明書は、PSAトークンサイズの増加を犠牲にして、X5Chain COSEヘッダーパラメーター[COSE-X509]を使用してPSAトークンにインランスできます。[TLS12-OIT]のセクション4.4および[TLS13-OIT]のセクション15は、IoT展開で使用されるX.509証明書をプロファイリングするためのガイダンスを提供します。事前に生成された証明書とインラインされた証明書の正確な分割は、特定の展開によって異なる場合があることに注意してください。その点で、x5chainは非常に柔軟です。END ENTITY（EE）認証のみ、EEと部分チェーン、またはEEと完全なチェーンを信頼アンカーに上げることができます（詳細については[COSE-X509]のセクション2を参照）。ネットワークバッファーなどのエンドポイントで利用可能なネットワーク帯域幅とコンピューティングリソースをめぐる制約は、合理的な分割点を指示する可能性があります。
To verify the token, the primary need is to check correct encoding and signing as detailed in Section 5.1.1. The key used for verification is either supplied to the Verifier by an authorized Endorser along with the corresponding Attester's Instance ID or inlined in the token using the x5chain header parameter as described in Section 7. If the IAK is a raw public key and the Instance ID claim is used to assist in locating the key used to verify the signature covering the CWT token. If the IAK is a certified public key, X.509 path construction and validation (Section 6 of [X509]) up to a trusted CA MUST be successful before the key is used to verify the token signature. This also includes revocation checking.
トークンを検証するために、主な必要性は、セクション5.1.1で詳述されているように、正しいエンコードと署名を確認することです。検証に使用されるキーは、セクション7で説明されているようにX5チェーンヘッダーパラメーターを使用して、対応するAttesterのインスタンスIDとともに、対応するAttesterのインスタンスIDとトークンにインラインされた認定証書によって検証剤に提供されるかのいずれかです。IAKが生の鍵であり、インスタンスIDのクレームは、CWTをカバーする兆候を検証する鍵を見つけるために使用される場合に使用されます。IAKが認定された公開キーである場合、X.509パスの構築と検証（[X509]のセクション6）までのCAまでのCAまでは、キーを使用してトークンの署名を確認する前に成功する必要があります。これには、取り消しチェックも含まれます。
The Verifier typically has a policy where it compares some claims in this profile to reference values registered with it for a given deployment. This verification process serves to confirm that the device is endorsed by the manufacturer supply chain. The policy may require that the relevant claims must have a match to a registered reference value. All claims may be worthy of additional appraisal. It is likely that most deployments would include a policy with appraisal for the following claims:
Verifierには通常、このプロファイルの一部のクレームを、特定の展開に登録された参照値と比較するポリシーがあります。この検証プロセスは、デバイスがメーカーのサプライチェーンによって承認されていることを確認するのに役立ちます。ポリシーは、関連する請求が登録された参照値に一致する必要があることを要求する場合があります。すべての請求は、追加の評価に値する場合があります。ほとんどの展開には、以下の請求のための評価のあるポリシーが含まれる可能性があります。
* Implementation ID: The value of the Implementation ID can be used to identify the verification requirements of the deployment.
* 実装ID：実装IDの値を使用して、展開の検証要件を特定できます。
* Software Component, Measurement Value: This value can uniquely identify a firmware release from the supply chain. In some cases, a Verifier may maintain a record for a series of firmware releases being patches to an original baseline release. A verification policy may then allow this value to match any point on that release sequence or expect some minimum level of maturity related to the sequence.
* ソフトウェアコンポーネント、測定値：この値は、サプライチェーンからのファームウェアリリースを一意に識別できます。場合によっては、検証剤は、一連のファームウェアリリースのレコードを、元のベースラインリリースまでのパッチであることを維持する場合があります。検証ポリシーにより、この値がそのリリースシーケンスの任意のポイントに一致するか、シーケンスに関連する最小レベルの成熟度を期待する場合があります。
* Software Component, Signer ID: Where present in a deployment, this could allow a Verifier to operate a more general policy than that for Measurement Value as above by allowing a token to contain any firmware entries signed by a known Signer ID without checking for a uniquely registered version.
* ソフトウェアコンポーネント、署名者ID：展開に存在する場合、これにより、検証者は、一意に登録されたバージョンをチェックせずにトークンが既知の署名者IDが署名したファームウェアエントリを含めることにより、上記のように測定値の場合よりも一般的なポリシーを操作できるようになります。
* Certification Reference: If present, this value could be used as a hint to locate security certification information associated with the attesting device. An example could be a reference to a [PSACertified] certificate.
* 認定リファレンス：存在する場合、この値は、証明デバイスに関連するセキュリティ認証情報を見つけるためのヒントとして使用できます。例は、[Psacertified]証明書への参照です。
[RATS-AR4SI] defines an information model that Verifiers can employ to produce Attestation Results. AR4SI provides a set of standardized appraisal categories and tiers that greatly simplifies the task of writing Relying Party policies in Multi-Attester environments.
[RATS-AR4SI]は、検証者が証明の結果を生成するために使用できる情報モデルを定義します。AR4SIは、マルチアテスター環境で当事者ポリシーに依存するタスクを大幅に簡素化する標準化された評価カテゴリとティアのセットを提供します。
The contents of Table 5 are intended as guidance for implementing a PSA Verifier that computes its results using AR4SI. The table describes which PSA Evidence claims (if any) are related to which AR4SI trustworthiness claim, and therefore what the Verifier must consider when deciding if and how to appraise a certain feature associated with the PSA Attester.
表5の内容は、AR4SIを使用して結果を計算するPSA検証剤を実装するためのガイダンスとして意図されています。表には、どのPSAの証拠がAR4SIの信頼性の主張に関連しているか（もしあれば）が主張するか、したがって、PSA Attesterに関連する特定の機能を評価するかどうか、どのように評価するかを検証者が考慮しなければならないことを説明しています。
+=====================+===========================================+
| Trustworthiness | Related PSA claims |
| Vector claims | |
+=====================+===========================================+
| "configuration" | Software Components (Section 4.4.1) |
+---------------------+-------------------------------------------+
| "executables" | ditto |
+---------------------+-------------------------------------------+
| "file-system" | N/A |
+---------------------+-------------------------------------------+
| "hardware" | Implementation ID (Section 4.2.2) |
+---------------------+-------------------------------------------+
| "instance-identity" | Instance ID (Section 4.2.1). The |
| | Security Lifecycle (Section 4.3.1) can |
| | also impact the derived identity. |
+---------------------+-------------------------------------------+
| "runtime-opaque" | Indirectly derived from "executables", |
| | "hardware", and "instance-identity". The |
| | Security Lifecycle (Section 4.3.1) can |
| | also be relevant, e.g., any debug state |
| | will expose otherwise protected memory. |
+---------------------+-------------------------------------------+
| "sourced-data" | N/A |
+---------------------+-------------------------------------------+
| "storage-opaque" | Indirectly derived from "executables", |
| | "hardware", and "instance-identity". |
+---------------------+-------------------------------------------+
Table 5: AR4SI Claims mappings
表5：AR4SIはマッピングを主張しています
This document does not prescribe what value must be chosen based on each possible situation. When assigning specific Trustworthiness Claim values, an implementation is expected to follow the algorithm described in Section 2.3.3 of [RATS-AR4SI].
このドキュメントでは、可能な各状況に基づいて選択しなければならない価値を規定していません。特定の信頼性の請求値を割り当てる場合、実装は[rats-ar4si]のセクション2.3.3で説明されているアルゴリズムに従うことが期待されます。
[PSA-Endorsements] defines a protocol based on the [RATS-CoRIM] data model that can be used to convey PSA Endorsements, Reference Values, and verification key material to the Verifier.
[PSA-Endorsements]は、PSAの承認、参照値、および検証キー資料を検証者に伝達するために使用できる[RATS-CORIM]データモデルに基づくプロトコルを定義します。
This specification reuses the EAT specification and therefore the CWT specification. Hence, the security and privacy considerations of those specifications apply here as well.
この仕様では、EAT仕様、したがってCWT仕様を再利用します。したがって、これらの仕様のセキュリティとプライバシーの考慮事項もここにも適用されます。
Since CWTs offer different ways to protect the token, this specification profiles those options and allows signatures using public key cryptography as well as message authentication codes (MACs). COSE_Sign1 is used for digital signatures and COSE_Mac0 for MACs as defined in the COSE specification [STD96]. Note, however, that the use of MAC authentication is NOT RECOMMENDED due to the associated infrastructure costs for key management and protocol complexities.
CWTSはトークンを保護するさまざまな方法を提供するため、この仕様はこれらのオプションをプロファイルし、公開キーの暗号化とメッセージ認証コード（MACS）を使用して署名を許可します。COSE_SIGN1は、COSE仕様[STD96]で定義されているように、デジタル署名とMacのCOSE_MAC0に使用されます。ただし、主要な管理とプロトコルの複雑さに関連するインフラストラクチャコストのため、Mac認証の使用は推奨されないことに注意してください。
A PSA Attester MUST NOT provide Evidence to an untrusted challenger, as it may allow attackers to interpose and trick the Verifier into believing the attacker is a legitimate Attester. This is especially relevant to protocols that use PSA attestation tokens to authenticate the attester to a Relying Party.
PSAの攻撃者は、攻撃者が干渉し、検証者をだまして攻撃者が正当な攻撃であると信じることを可能にする可能性があるため、信頼できない挑戦者に証拠を提供してはなりません。これは、PSAの証明トークンを使用して依存者にアテスターを認証するプロトコルに特に関連しています。
Attestation tokens contain information that may be unique to a device. Therefore, they may allow to single out an individual device for tracking purposes. Deployments that have privacy requirements must take appropriate measures to ensure that the token is only used to provision anonymous/pseudonym keys.
証明トークンには、デバイスに固有の情報が含まれています。したがって、追跡目的で個々のデバイスを選出することを許可する場合があります。プライバシー要件を持つ展開は、トークンが匿名/仮名キーの提供にのみ使用されることを保証するために適切な対策を講じる必要があります。
IANA has registered the following claims in the "CBOR Web Token (CWT) Claims" registry [CWT].
IANAは、「Cbor Web Token（CWT）クレーム」レジストリ[CWT]に次の請求を登録しています。
Claim Name:
クレーム名：
psa-client-id
psa-client-id
Claim Description:
クレームの説明：
PSA Client ID
PSAクライアントID
JWT Claim Name:
JWTクレーム名：
N/A
n/a
Claim Key:
主張キー：
2394
2394
Claim Value Type(s):
請求値タイプ：
signed integer
署名された整数
Change Controller:
Change Controller：
Hannes Tschofenig
Hannes Tschofenig
Specification Document(s):
仕様文書：
Section 4.1.2 of RFC 9783
RFC 9783のセクション4.1.2
Claim Name:
クレーム名：
psa-security-lifecycle
PSA-Security-Lifecycle
Claim Description:
クレームの説明：
PSA Security Lifecycle
PSAセキュリティライフサイクル
JWT Claim Name:
JWTクレーム名：
N/A
n/a
Claim Key:
主張キー：
2395
2395
Claim Value Type(s):
請求値タイプ：
unsigned integer
署名されていない整数
Change Controller:
Change Controller：
Hannes Tschofenig
Hannes Tschofenig
Specification Document(s):
仕様文書：
Section 4.3.1 of RFC 9783
RFC 9783のセクション4.3.1
Claim Name:
クレーム名：
psa-implementation-id
PSA-Implementation-ID
Claim Description:
クレームの説明：
PSA Implementation ID
PSA実装ID
JWT Claim Name:
JWTクレーム名：
N/A
n/a
Claim Key:
主張キー：
2396
2396
Claim Value Type(s):
請求値タイプ：
byte string
バイト文字列
Change Controller:
Change Controller：
Hannes Tschofenig
Hannes Tschofenig
Specification Document(s):
仕様文書：
Section 4.2.2 of RFC 9783
RFC 9783のセクション4.2.2
Claim Name:
クレーム名：
psa-certification-reference
PSA認定参照
Claim Description:
クレームの説明：
PSA Certification Reference
PSA認定リファレンス
JWT Claim Name:
JWTクレーム名：
N/A
n/a
Claim Key:
主張キー：
2398
2398
Claim Value Type(s):
請求値タイプ：
text string
テキスト文字列
Change Controller:
Change Controller：
Hannes Tschofenig
Hannes Tschofenig
Specification Document(s):
仕様文書：
Section 4.2.3 of RFC 9783
RFC 9783のセクション4.2.3
Claim Name:
クレーム名：
psa-software-components
PSAソフトウェアコンポーネント
Claim Description:
クレームの説明：
PSA Software Components
PSAソフトウェアコンポーネント
JWT Claim Name:
JWTクレーム名：
N/A
n/a
Claim Key:
主張キー：
2399
2399
Claim Value Type(s):
請求値タイプ：
array
配列
Change Controller:
Change Controller：
Hannes Tschofenig
Hannes Tschofenig
Specification Document(s):
仕様文書：
Section 4.4.1 of RFC 9783
RFC 9783のセクション4.4.1
Claim Name:
クレーム名：
psa-verification-service-indicator
psa-verification-service-indicator
Claim Description:
クレームの説明：
PSA Verification Service Indicator
PSA検証サービスインジケーター
JWT Claim Name:
JWTクレーム名：
N/A
n/a
Claim Key:
主張キー：
2400
2400
Claim Value Type(s):
請求値タイプ：
text string
テキスト文字列
Change Controller:
Change Controller：
Hannes Tschofenig
Hannes Tschofenig
Specification Document(s):
仕様文書：
Section 4.5.1 of RFC 9783
RFC 9783のセクション4.5.1
This document does not register any new media types. To indicate that the transmitted content is a PSA attestation token, applications can use the application/eat+cwt media type defined in [EAT-MEDIATYPES] with the eat_profile parameter set to tag:psacertified.org,2023:psa#tfm (or tag:psacertified.org,2019:psa#legacy if the token is encoded according to the old profile; see Section 4.6).
このドキュメントは、新しいメディアタイプを登録しません。送信されたコンテンツがPSA証明トークンであることを示すために、アプリケーションは[Eat_Profileパラメーターをタグ付け]で設定された[Eat-Mediatypes]で[Eat-Mediatypes]で定義されたアプリケーション/EAT+CWTメディアタイプを使用できます。
IANA has registered two CoAP Content-Format IDs in the First Come First Served range of the "CoAP Content-Formats" registry [Content-Formats]:
IANAは、「Coap Content-Formats」レジストリ[コンテンツフォーマット]の最初の提供範囲で最初のCOAPコンテンツフォーマットIDを登録しました。
* One for the application/eat+cwt media type with the eat_profile parameter equal to tag:psacertified.org,2023:psa#tfm.
* 1つは、eat_profileパラメーターを使用してアプリケーション/eat+cwtメディアタイプに等しいタグ：psacertified.org、2023：psa＃tfmに等しくなります。
* Another for the application/eat+cwt media type with the eat_profile parameter equal to tag:psacertified.org,2019:psa#legacy.
* 別のアプリケーション/EAT+CWTメディアタイプを使用して、eat_profileパラメーターがタグに等しい：psacertified.org、2019：psa＃legacy。
Media Type:
メディアタイプ：
application/eat+cwt; eat_profile="tag:psacertified.org,2023:psa#tfm"
アプリケーション/EAT+CWT;eat_profile = "tag：psacertified.org、2023：psa＃tfm"
Encoding:
エンコーディング：
-
-
ID:
ID:
10003
10003
Reference:
参照：
RFC 9783
RFC 9783
Media Type:
メディアタイプ：
application/eat+cwt; eat_profile="tag:psacertified.org,2019:psa#legacy"
アプリケーション/EAT+CWT;eat_profile = "tag：psacertified.org、2019：psa＃legacy"
Encoding:
エンコーディング：
-
-
ID:
ID:
10004
10004
Reference:
参照：
RFC 9783
RFC 9783
[COSE-ALGS]
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/info/rfc9053>.
[CWT] IANA, "CBOR Web Token (CWT) Claims",
<https://www.iana.org/assignments/cwt>.
[EAN-13] GS1, "EAN/UPC barcodes",
<https://www.gs1.org/standards/barcodes/ean-upc>.
[EAT] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/info/rfc9711>.
[EAT-MEDIATYPES]
Lundblade, L., Birkholz, H., and T. Fossati, "Entity
Attestation Token (EAT) Media Types", RFC 9782,
DOI 10.17487/RFC9782, May 2025,
<https://www.rfc-editor.org/info/rfc9782>.
[NAMED-INFO]
IANA, "Named Information Hash Algorithm Registry",
<https://www.iana.org/assignments/named-information>.
[PSA-Cert-Guide]
PSA Certified, "PSA Certified Level 2 Step by Step Guide
Version 1.1", April 2020,
<https://www.psacertified.org/app/uploads/2020/07/
JSADEN011-PSA_Certified_Level_2_Step-by-Step-
1.1-20200403.pdf>.
[PSA-FF] Arm, "Arm PSA Firmware Framework 1.0",
<https://developer.arm.com/documentation/den0063/a>.
[PSA-SM] Arm, "Platform Security Model 1.1", December 2021,
<https://www.psacertified.org/app/uploads/2021/12/
JSADEN014_PSA_Certified_SM_V1.1_BET0.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme",
RFC 4151, DOI 10.17487/RFC4151, October 2005,
<https://www.rfc-editor.org/info/rfc4151>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[STD94] Internet Standard 94,
<https://www.rfc-editor.org/info/std94>.
At the time of writing, this STD comprises the following:
Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[STD96] Internet Standard 96,
<https://www.rfc-editor.org/info/std96>.
At the time of writing, this STD comprises the following:
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Countersignatures", STD 96, RFC 9338,
DOI 10.17487/RFC9338, December 2022,
<https://www.rfc-editor.org/info/rfc9338>.
[X509] 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>.
[Content-Formats]
IANA, "CoAP Content-Formats",
<https://www.iana.org/assignments/core-parameters>.
[COSE-X509]
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header Parameters for Carrying and Referencing X.509
Certificates", RFC 9360, DOI 10.17487/RFC9360, February
2023, <https://www.rfc-editor.org/info/rfc9360>.
[IAT-VERIFIER]
Trusted Firmware, "iat-verifier", commit:
0b49b00195b7733d6fe74e8f42ed4d7b81242801, 18 August 2023,
<https://git.trustedfirmware.org/plugins/gitiles/TF-M/tf-
m-tools/+/refs/heads/main/iat-verifier/>.
[PSA] Arm, "Security - Platform Security Architecture",
<https://developer.arm.com/documentation/101892/0100/
Security---Platform-Security-Architecture?lang=en>.
[PSA-API] Arm, "PSA Certified Attestation API 1.0", October 2022,
<https://arm-software.github.io/psa-api/attestation/1.0/
IHI0085-PSA_Certified_Attestation_API-1.0.3.pdf>.
[PSA-Endorsements]
Fossati, T., Deshpande, Y., and H. Birkholz, "A CoRIM
Profile for Arm's Platform Security Architecture (PSA)",
Work in Progress, Internet-Draft, draft-fdb-rats-psa-
endorsements-06, 3 March 2025,
<https://datatracker.ietf.org/doc/html/draft-fdb-rats-psa-
endorsements-06>.
[PSA-OLD] Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L., and
T. Fossati, "Arm's Platform Security Architecture (PSA)
Attestation Token", Work in Progress, Internet-Draft,
draft-tschofenig-rats-psa-token-07, 1 February 2021,
<https://datatracker.ietf.org/doc/html/draft-tschofenig-
rats-psa-token-07>.
[PSACertified]
PSA Certified, "PSA Certified: IoT Security Framework and
Certification", <https://psacertified.org>.
[RATS-AR4SI]
Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
Scarlata, "Attestation Results for Secure Interactions",
Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-
08, 6 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
ar4si-08>.
[RATS-CoRIM]
Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and
W. Pan, "Concise Reference Integrity Manifest", Work in
Progress, Internet-Draft, draft-ietf-rats-corim-07, 3
March 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-rats-corim-07>.
[RATS-QWESTOKEN]
Mandyam, G., Sekhar, V., and S. Mohammed, "The Qualcomm
Wireless Edge Services (QWES) Attestation Token", Work in
Progress, Internet-Draft, draft-mandyam-rats-qwestoken-00,
1 November 2019, <https://datatracker.ietf.org/doc/html/
draft-mandyam-rats-qwestoken-00>.
[RATS-TDX] Kostal, G., Dittakavi, S., Yeluri, R., Xia, H., and J. Yu,
"EAT profile for Intel(r) Trust Domain Extensions (TDX)
attestation result", Work in Progress, Internet-Draft,
draft-kdyxy-rats-tdx-eat-profile-02, 13 December 2024,
<https://datatracker.ietf.org/doc/html/draft-kdyxy-rats-
tdx-eat-profile-02>.
[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>.
[TF-M] Trusted Firmware, "Trusted Firmware-M",
<https://www.trustedfirmware.org/projects/tf-m/>.
[TLS12-IoT]
Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016,
<https://www.rfc-editor.org/info/rfc7925>.
[TLS13-IoT]
Tschofenig, H., Fossati, T., and M. Richardson, "TLS/DTLS
1.3 Profiles for the Internet of Things", Work in
Progress, Internet-Draft, draft-ietf-uta-tls13-iot-
profile-14, 5 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-uta-
tls13-iot-profile-14>.
The following examples show PSA attestation tokens for a hypothetical system comprising a single measured software component. The attesting device is in a lifecycle state (Section 4.3.1) of SECURED. The attestation has been requested from a client residing in the SPE.
次の例は、単一の測定ソフトウェアコンポーネントを含む仮想システムのPSA証明トークンを示しています。証明デバイスは、保護されたライフサイクル状態（セクション4.3.1）にあります。証明は、SPEに居住するクライアントから要求されています。
The example in Appendix A.1 illustrates the case where the IAK is an asymmetric key. A COSE Sign1 envelope is used to wrap the PSA-token claims set.
付録A.1の例は、IAKが非対称キーである場合を示しています。COSE Sign1エンベロープは、PSAトークンクレームセットをラップするために使用されます。
Appendix A.2 illustrates the case where the IAK is a symmetric key and a COSE Mac0 envelope is used instead.
付録A.2は、IAKが対称キーであり、代わりにCOSE Mac0エンベロープが使用される場合を示しています。
The claims sets are identical, except for the Instance ID which is synthesized from the key material.
主要な資料から合成されるインスタンスIDを除き、クレームセットは同一です。
The examples have been created using the iat-verifier tool [IAT-VERIFIER].
例は、IAT-Verifierツール[IAT-Verifier]を使用して作成されています。
{
/ ueid / 256: h'01020202020202020202020202
0202020202020202020202020202020202020202',
/ psa-implementation-id / 2396: h'00000000000000000000000000
00000000000000000000000000000000000000',
/ eat_nonce / 10: h'01010101010101010101010101
01010101010101010101010101010101010101',
/ psa-client-id / 2394: 2147483647,
/ psa-security-lifecycle / 2395: 12288,
/ eat_profile / 265: "tag:psacertified.org,2023:psa#tfm",
/ bootseed / 268: h'0000000000000000',
/ psa-software-components / 2399: [
{
/ signer ID / 5: h'0404040404040404040404040404040
404040404040404040404040404040404',
/ measurement value / 2: h'0303030303030303030303030303030
303030303030303030303030303030303',
/ measurement type / 1: "PRoT"
}
]
}
The JWK representation of the IAK used for creating the COSE Sign1 signature over the PSA token is:
PSAトークンを介してCOSE Sign1署名を作成するために使用されるIAKのJWK表現は次のとおりです。
{
"kty": "EC",
"crv": "P-256",
"alg": "ES256",
"x": "Tl4iCZ47zrRbRG0TVf0dw7VFlHtv18HInYhnmMNybo8",
"y": "gNcLhAslaqw0pi7eEEM2TwRAlfADR0uR4Bggkq-xPy4",
"d": "Q__-y5X4CFp8QOHT6nkL7063jN131YUDpkwWAPkbM-c"
}
The resulting COSE object is:
結果のCOSEオブジェクトは次のとおりです。
18([
h'A10126',
{},
h'A81901005821010202020202020202020202020202020202020202020202
02020202020202020219095C5820000000000000000000000000000000000000
00000000000000000000000000000A5820010101010101010101010101010101
010101010101010101010101010101010119095A1A7FFFFFFF19095B19300019
010978217461673A7073616365727469666965642E6F72672C323032333A7073
612374666D19010C48000000000000000019095F81A305582004040404040404
0404040404040404040404040404040404040404040404040402582003030303
0303030303030303030303030303030303030303030303030303030301645052
6F54',
h'786E937A4C42667AF3847399319CA95C7E7DBABDC9B50FDB8DE3F6BFF4AB
82FF80C42140E2A488000219E3E10663193DA69C75F52B798EA10B2F7041A90E
8E5A'
])
which has the following base16 encoding:
次のbase16エンコードがあります：
d28443a10126a0590100a819010058210102020202020202020202020202
0202020202020202020202020202020202020219095c5820000000000000
00000000000000000000000000000000000000000000000000000a582001
010101010101010101010101010101010101010101010101010101010101
0119095a1a7fffffff19095b19300019010978217461673a707361636572
7469666965642e6f72672c323032333a7073612374666d19010c48000000
000000000019095f81a30558200404040404040404040404040404040404
040404040404040404040404040404025820030303030303030303030303
0303030303030303030303030303030303030303016450526f545840786e
937a4c42667af3847399319ca95c7e7dbabdc9b50fdb8de3f6bff4ab82ff
80c42140e2a488000219e3e10663193da69c75f52b798ea10b2f7041a90e
8e5a
{
/ ueid / 256: h'01C557BD4FADC83F756FCA2CD5
EA2DCC8B82159BB4E7453D6A744D4EECD6D0AC60',
/ psa-implementation-id / 2396: h'00000000000000000000000000
00000000000000000000000000000000000000',
/ eat_nonce / 10: h'01010101010101010101010101
01010101010101010101010101010101010101',
/ psa-client-id / 2394: 2147483647,
/ psa-security-lifecycle / 2395: 12288,
/ eat_profile / 265: "tag:psacertified.org,2023:psa#tfm",
/ psa-boot-seed / 268: h'0000000000000000',
/ psa-software-components / 2399: [
{
/ signer ID / 5: h'0404040404040404040404040404040
404040404040404040404040404040404',
/ measurement value / 2: h'0303030303030303030303030303030
303030303030303030303030303030303',
/ measurement type / 1: "PRoT"
}
]
}
The JWK representation of the IAK used for creating the COSE Mac0 signature over the PSA token is:
PSAトークンを介したコードMAC0署名の作成に使用されるオークのJWK表現は次のとおりです。
========== NOTE: '\\' line wrapping per RFC 8792 ==========
{
"kty": "oct",
"alg": "HS256",
"k": "3gOLNKyhJXaMXjNXq40Gs2e5qw1-i-Ek7cpH_gM6W7epPTB_8imqNv8k\
\bBKVlk-s9xq3qm7E_WECt7OYMlWtkg"
}
The resulting COSE object is:
結果のCOSEオブジェクトは次のとおりです。
17([
h'A10105',
{},
h'A8190100582101C557BD4FADC83F756FCA2CD5EA2DCC8B82159BB4E7453D
6A744D4EECD6D0AC6019095C5820000000000000000000000000000000000000
00000000000000000000000000000A5820010101010101010101010101010101
010101010101010101010101010101010119095A1A7FFFFFFF19095B19300019
010978217461673A7073616365727469666965642E6F72672C323032333A7073
612374666D19010C48000000000000000019095F81A305582004040404040404
0404040404040404040404040404040404040404040404040402582003030303
0303030303030303030303030303030303030303030303030303030301645052
6F54',
h'CF88D330E7A5366A95CF744A4DBF0D50304D405EDD8B2530E243EDDBD317
7820'
])
which has the following base16 encoding:
次のbase16エンコードがあります：
d18443a10105a0590100a8190100582101c557bd4fadc83f756fca2cd5ea
2dcc8b82159bb4e7453d6a744d4eecd6d0ac6019095c5820000000000000
00000000000000000000000000000000000000000000000000000a582001
010101010101010101010101010101010101010101010101010101010101
0119095a1a7fffffff19095b19300019010978217461673a707361636572
7469666965642e6f72672c323032333a7073612374666d19010c48000000
000000000019095f81a30558200404040404040404040404040404040404
040404040404040404040404040404025820030303030303030303030303
0303030303030303030303030303030303030303016450526f545820cf88
d330e7a5366a95cf744a4dbf0d50304d405edd8b2530e243eddbd3177820
Thank you Carsten Bormann for help with the CDDL. Thanks to Nicholas Wood, Eliot Lear, Yaron Sheffer, Kathleen Moriarty, and Ned Smith for ideas, comments, and suggestions.
CDDLの支援をありがとうCarsten Bormannに感謝します。ニコラス・ウッド、エリオット・リア、ヤロン・シェファー、キャスリーン・モリアーティ、ネッド・スミスに感謝します。
Laurence Lundblade
Security Theory LLC
Email: lgl@securitytheory.com
Tamas Ban
Arm Limited
Email: Tamas.Ban@arm.com
Sergei Trofimov
Arm Limited
Email: Sergei.Trofimov@arm.com
Hannes Tschofenig
University of Applied Sciences Bonn-Rhein-Sieg
Germany
Email: Hannes.Tschofenig@gmx.net
Simon Frost
Arm Limited
Email: Simon.Frost@arm.com
Mathias Brossard
Arm Limited
Email: Mathias.Brossard@arm.com
Adrian Shaw
HP Labs
Email: adrianlshaw@acm.org
Thomas Fossati
Linaro
Email: thomas.fossati@linaro.org