[要約] 要約：RFC 4108は、ファームウェアパッケージを保護するために暗号化メッセージ構文（CMS）を使用する方法について説明しています。 目的：このRFCの目的は、ファームウェアパッケージのセキュリティを向上させるために、CMSを使用する方法を提案することです。
Network Working Group R. Housley
Request for Comments: 4108 Vigil Security
Category: Standards Track August 2005
Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages
暗号化メッセージ構文（CMS）を使用したファームウェアパッケージの保護
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（2005）。
Abstract
概要
This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package.
このドキュメントでは、1つ以上のハードウェアモジュールコンポーネントにオブジェクトコードを提供するファームウェアパッケージを保護するための暗号メッセージ構文（CMS）の使用について説明します。 CMSはRFC 3852で指定されています。デジタル署名は、ファームウェアパッケージを未検出の変更から保護し、データ発信元認証を提供するために使用されます。暗号化は、ファームウェアパッケージを開示から保護するためにオプションで使用され、圧縮は、保護されたファームウェアパッケージのサイズを縮小するためにオプションで使用されます。ファームウェアパッケージの読み込みが正常に行われたことを確認するために、ファームウェアパッケージ読み込みレシートをオプションで生成できます。同様に、ファームウェアパッケージのロードエラーレポートをオプションで生成して、ファームウェアパッケージのロードの失敗を伝えることができます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................5
1.2. Architectural Elements .....................................5
1.2.1. Hardware Module Requirements ........................7
1.2.2. Firmware Package Requirements .......................8
1.2.3. Bootstrap Loader Requirements .......................9
1.2.3.1. Legacy Stale Version Processing ...........11
1.2.3.2. Preferred Stale Version Processing ........12
1.2.4. Trust Anchors ......................................12
1.2.5. Cryptographic and Compression Algorithm
Requirements .......................................13
1.3. Hardware Module Security Architecture .....................14
1.4. ASN.1 Encoding ............................................14
1.5. Protected Firmware Package Loading ........................15
2. Firmware Package Protection ....................................15
2.1. Firmware Package Protection CMS Content Type Profile ......18
2.1.1. ContentInfo ........................................18
2.1.2. SignedData .........................................18
2.1.2.1. SignerInfo ................................19
2.1.2.2. EncapsulatedContentInfo ...................20
2.1.3. EncryptedData ......................................20
2.1.3.1. EncryptedContentInfo ......................21
2.1.4. CompressedData .....................................21
2.1.4.1. EncapsulatedContentInfo ...................22
2.1.5. FirmwarePkgData ....................................22
2.2. Signed Attributes .........................................22
2.2.1. Content Type .......................................23
2.2.2. Message Digest .....................................24
2.2.3. Firmware Package Identifier ........................24
2.2.4. Target Hardware Module Identifiers .................25
2.2.5. Decrypt Key Identifier .............................26
2.2.6. Implemented Crypto Algorithms ......................26
2.2.7. Implemented Compression Algorithms .................27
2.2.8. Community Identifiers ..............................27
2.2.9. Firmware Package Information .......................29
2.2.10. Firmware Package Message Digest ...................30
2.2.11. Signing Time ......................................30
2.2.12. Content Hints .....................................31
2.2.13. Signing Certificate ...............................31
2.3. Unsigned Attributes .......................................32
2.3.1. Wrapped Firmware Decryption Key ....................33
3. Firmware Package Load Receipt ..................................34
3.1. Firmware Package Load Receipt CMS Content Type Profile ....36
3.1.1. ContentInfo ........................................36
3.1.2. SignedData .........................................36
3.1.2.1. SignerInfo ................................37
3.1.2.2. EncapsulatedContentInfo ...................38
3.1.3. FirmwarePackageLoadReceipt .........................38
3.2. Signed Attributes .........................................40
3.2.1. Content Type .......................................40
3.2.2. Message Digest .....................................40
3.2.3. Signing Time .......................................40
4. Firmware Package Load Error ....................................41
4.1. Firmware Package Load Error CMS Content Type Profile ......42
4.1.1. ContentInfo ........................................42
4.1.2. SignedData .........................................43
4.1.2.1. SignerInfo ................................43
4.1.2.2. EncapsulatedContentInfo ...................43
4.1.3. FirmwarePackageLoadError ...........................43
4.2. Signed Attributes .........................................49
4.2.1. Content Type .......................................49
4.2.2. Message Digest .....................................49
4.2.3. Signing Time .......................................50
5. Hardware Module Name ...........................................50
6. Security Considerations ........................................51
6.1. Cryptographic Keys and Algorithms .........................51
6.2. Random Number Generation ..................................51
6.3. Stale Firmware Package Version Number .....................52
6.4. Community Identifiers .....................................53
7. References .....................................................54
7.1. Normative References ......................................54
7.2. Informative References ....................................54
Appendix A: ASN.1 Module ..........................................56
This document describes the use of the Cryptographic Message Syntax (CMS) [CMS] to protect firmware packages. This document also describes the use of CMS for receipts and error reports for firmware package loading. The CMS is a data protection encapsulation syntax that makes use of ASN.1 [X.208-88, X.209-88]. The protected firmware package can be associated with any particular hardware module; however, this specification was written with the requirements of cryptographic hardware modules in mind, as these modules have strong security requirements.
このドキュメントでは、ファームウェアパッケージを保護するための暗号化メッセージ構文（CMS）[CMS]の使用について説明します。このドキュメントでは、ファームウェアパッケージの読み込みに関するレシートおよびエラーレポートでのCMSの使用についても説明しています。 CMSは、ASN.1 [X.208-88、X.209-88]を利用するデータ保護カプセル化構文です。保護されたファームウェアパッケージは、特定のハードウェアモジュールに関連付けることができます。ただし、これらのモジュールには強力なセキュリティ要件があるため、この仕様は暗号化ハードウェアモジュールの要件を念頭に置いて作成されました。
The firmware package contains object code for one or more programmable components that make up the hardware module. The firmware package, which is treated as an opaque binary object, is digitally signed. Optional encryption and compression are also supported. When all three are used, the firmware package is compressed, then encrypted, and then signed. Compression simply reduces the size of the firmware package, allowing more efficient processing and transmission. Encryption protects the firmware package from disclosure, which allows transmission of sensitive firmware packages over insecure links. The encryption algorithm and mode employed may also provide integrity, protecting the firmware package from undetected modification. The encryption protects proprietary algorithms, classified algorithms, trade secrets, and implementation techniques. The digital signature protects the firmware package from undetected modification and provides data origin authentication. The digital signature allows the hardware module to confirm that the firmware package comes from an acceptable source.
ファームウェアパッケージには、ハードウェアモジュールを構成する1つまたは複数のプログラム可能なコンポーネントのオブジェクトコードが含まれています。不透明なバイナリオブジェクトとして扱われるファームウェアパッケージは、デジタル署名されています。オプションの暗号化と圧縮もサポートされています。 3つすべてを使用する場合、ファームウェアパッケージは圧縮され、暗号化され、署名されます。圧縮は単にファームウェアパッケージのサイズを縮小し、より効率的な処理と送信を可能にします。暗号化は、ファームウェアパッケージを開示から保護します。これにより、機密性の高いファームウェアパッケージを安全でないリンクを介して送信できます。使用される暗号化アルゴリズムとモードは、完全性を提供し、ファームウェアパッケージを未検出の変更から保護することもできます。暗号化は、独自のアルゴリズム、分類されたアルゴリズム、企業秘密、および実装技術を保護します。デジタル署名は、ファームウェアパッケージを未検出の変更から保護し、データ発信元認証を提供します。デジタル署名により、ハードウェアモジュールは、ファームウェアパッケージが適切なソースからのものであることを確認できます。
If encryption is used, the firmware-decryption key must be made available to the hardware module via a secure path. The key might be delivered via physical media or via an independent electronic path. One optional mechanism for distributing the firmware-decryption key is specified in Section 2.3.1, but any secure key distribution mechanism is acceptable.
暗号化を使用する場合、ファームウェア復号化キーは、安全なパスを介してハードウェアモジュールで使用できるようにする必要があります。キーは、物理メディアまたは独立した電子パスを介して配信される場合があります。ファームウェア復号化キーを配布するためのオプションのメカニズムの1つは、セクション2.3.1で指定されていますが、安全なキー配布メカニズムはすべて受け入れられます。
The signature verification public key must be made available to the hardware module in a manner that preserves its integrity and confirms its source. CMS supports the transfer of certificates, and this facility can be used to transfer a certificate that contains the signature verification public key (a firmware-signing certificate). However, use of this facility introduces a level of indirection. Ultimately, a trust anchor public key must be made available to the hardware module. Section 1.2 establishes a requirement that the hardware module store one or more trust anchors.
署名検証公開鍵は、その完全性を維持し、そのソースを確認する方法でハードウェアモジュールで利用できるようにする必要があります。 CMSは証明書の転送をサポートしており、この機能を使用して、署名検証公開鍵を含む証明書（ファームウェア署名証明書）を転送できます。ただし、この機能を使用すると、ある程度の間接参照が発生します。最終的に、ハードウェアモジュールでトラストアンカー公開鍵を使用できるようにする必要があります。セクション1.2は、ハードウェアモジュールが1つ以上のトラストアンカーを格納するという要件を確立します。
Hardware modules may not be capable of accessing certificate repositories or delegated path discovery (DPD) servers [DPD&DPV] to acquire certificates needed to complete a certification path. Thus, it is the responsibility of the firmware package signer to include sufficient certificates to enable each module to validate the firmware-signer certificate (see Section 2.1.2). Similarly, hardware modules may not be capable of accessing a certificate revocation list (CRL) repository, an OCSP responder [OCSP], or a delegated path validation (DPV) server [DPD&DPV] to acquire revocation status information. Thus, if the firmware package signature cannot be validated solely with the trust anchor public key and the hardware module is not capable of performing full certification path validation, then it is the responsibility of the entity loading a package into a hardware module to validate the firmware-signer certification path prior to loading the package into a hardware module. The means by which this external certificate revocation status checking is performed is beyond the scope of this specification.
ハードウェアモジュールは、証明書リポジトリまたは委任パス探索（DPD）サーバー[DPD＆DPV]にアクセスして、証明書パスを完了するために必要な証明書を取得できない場合があります。したがって、各モジュールがファームウェア署名者証明書を検証できるようにするために十分な証明書を含めるのは、ファームウェアパッケージ署名者の責任です（セクション2.1.2を参照）。同様に、ハードウェアモジュールは、証明書失効リスト（CRL）リポジトリ、OCSPレスポンダ[OCSP]、または委任パス検証（DPV）サーバー[DPD＆DPV]にアクセスして失効ステータス情報を取得できない場合があります。したがって、ファームウェアパッケージの署名をトラストアンカー公開鍵だけで検証できず、ハードウェアモジュールが完全な証明書パス検証を実行できない場合、ファームウェアを検証するのはエンティティがパッケージをハードウェアモジュールにロードする責任があります。パッケージをハードウェアモジュールにロードする前の署名者認証パス。この外部証明書失効ステータスチェックを実行する方法は、この仕様の範囲を超えています。
Hardware modules will only accept firmware packages with a valid digital signature. The signature is either validated directly using the trust anchor public key or using a firmware-signer certification path that is validated to the trust anchor public key. Thus, the trust anchors define the set of entities that can create firmware packages for the hardware module.
ハードウェアモジュールは、有効なデジタル署名のあるファームウェアパッケージのみを受け入れます。署名は、トラストアンカー公開鍵を使用して直接検証されるか、トラストアンカー公開鍵に対して検証されるファームウェア署名者証明書パスを使用して検証されます。したがって、トラストアンカーは、ハードウェアモジュールのファームウェアパッケージを作成できるエンティティのセットを定義します。
The disposition of a previously loaded firmware package after the successful validation of another firmware package is beyond the scope of this specification. The amount of memory available to the hardware module will determine the range of alternatives.
別のファームウェアパッケージの検証が成功した後の、以前にロードされたファームウェアパッケージの処理は、この仕様の範囲外です。ハードウェアモジュールが使用できるメモリの量によって、代替の範囲が決まります。
In some cases, hardware modules can generate receipts to acknowledge the loading of a particular firmware package. Such receipts can be used to determine which hardware modules need to receive an updated firmware package whenever a flaw in an earlier firmware package is discovered. Hardware modules can also generate error reports to indicate the unsuccessful firmware package loading. To implement either receipt or error report generation, the hardware module is required to have a unique permanent serial number. Receipts and error reports can be either signed or unsigned. To generate digitally signed receipts or error reports, a hardware module MUST be issued its own private signature key and a certificate that contains the corresponding signature validation public key. In order to save memory with the hardware module, the hardware module might store a certificate designator instead of the certificate itself. The private signature key requires secure storage.
場合によっては、ハードウェアモジュールが領収書を生成して、特定のファームウェアパッケージのロードを確認できます。このような領収書は、以前のファームウェアパッケージの欠陥が発見されたときに、更新されたファームウェアパッケージを受け取る必要のあるハードウェアモジュールを決定するために使用できます。ハードウェアモジュールは、エラーパッケージを生成して、ファームウェアパッケージのロードが失敗したことを示すこともできます。受信レポートまたはエラーレポートの生成を実装するには、ハードウェアモジュールに一意の永続的なシリアル番号が必要です。領収書とエラーレポートは、署名されている場合と、署名されていない場合があります。デジタル署名されたレシートまたはエラーレポートを生成するには、ハードウェアモジュールに独自の秘密署名キーと、対応する署名検証公開キーを含む証明書を発行する必要があります。ハードウェアモジュールでメモリを節約するために、ハードウェアモジュールは、証明書自体ではなく証明書指定子を保存する場合があります。秘密署名キーには安全なストレージが必要です。
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [STDWORDS].
このドキュメントでは、キーワード「必須」、「必須」、「必須」、「必須」、「必須」、「推奨」、「必須」、および「オプション」は、[STDWORDS]で説明されているように解釈されます。
The architecture includes the hardware module, the firmware package, and a bootstrap loader. The bootstrap loader MUST have access to one or more trusted public keys, called trust anchors, to validate the signature on the firmware package. If a signed firmware package load receipt or error report is created on behalf of the hardware module, then the bootstrap loader MUST have access to a private signature key to generate the signature and the signer identifier for the corresponding signature validation certificate or its designator. A signature validation certificate MAY be included to aid signature validation. To implement this optional capability, the hardware module MUST have a unique serial number and a private signature key; the hardware module MAY also include a certificate that contains the corresponding signature validation public key. These items MUST be installed in the hardware module before it is deployed. The private key and certificate can be generated and installed as part of the hardware module manufacture process. Figure 1 illustrates these architectural elements.
アーキテクチャには、ハードウェアモジュール、ファームウェアパッケージ、およびブートストラップローダーが含まれます。ブートストラップローダーは、ファームウェアパッケージの署名を検証するために、トラストアンカーと呼ばれる1つ以上の信頼された公開鍵にアクセスできる必要があります。ハードウェアモジュールに代わって署名されたファームウェアパッケージのロードレシートまたはエラーレポートが作成された場合、ブートストラップローダーは秘密署名キーにアクセスして、対応する署名検証証明書またはその指定子の署名と署名者識別子を生成する必要があります。署名検証を支援するために、署名検証証明書が含まれる場合があります。このオプション機能を実装するには、ハードウェアモジュールに一意のシリアル番号と秘密署名キーが必要です。ハードウェアモジュールには、対応する署名検証公開鍵を含む証明書も含まれる場合があります。これらのアイテムは、展開する前にハードウェアモジュールにインストールする必要があります。秘密鍵と証明書は、ハードウェアモジュールの製造プロセスの一部として生成およびインストールできます。図1は、これらのアーキテクチャ要素を示しています。
ASN.1 object identifiers are the preferred means of naming the architectural elements.
ASN.1オブジェクト識別子は、アーキテクチャ要素に名前を付けるための推奨される方法です。
Details of managing the trust anchors are beyond the scope of this specification. However, one or more trust anchors MUST be installed in the hardware module using a secure process before it is deployed. These trust anchors provide a means of controlling the acceptable sources of firmware packages. The hardware module vendor can include provisions for secure, remote management of trust anchors. One approach is to include trust anchors in the firmware packages themselves. This approach is analogous to the optional capability described later for updating the bootstrap loader.
トラストアンカーの管理の詳細は、この仕様の範囲外です。ただし、1つ以上のトラストアンカーは、展開する前に安全なプロセスを使用してハードウェアモジュールにインストールする必要があります。これらのトラストアンカーは、ファームウェアパッケージの受け入れ可能なソースを制御する手段を提供します。ハードウェアモジュールベンダーは、トラストアンカーの安全なリモート管理のための規定を含めることができます。 1つのアプローチは、ファームウェアパッケージ自体にトラストアンカーを含めることです。このアプローチは、ブートストラップローダーを更新するための、後で説明するオプション機能に似ています。
In a cryptographic hardware module, the firmware package might implement many different cryptographic algorithms.
暗号化ハードウェアモジュールでは、ファームウェアパッケージは多くの異なる暗号化アルゴリズムを実装する場合があります。
When the firmware package is encrypted, the firmware-decryption key and the firmware package MUST both be provided to the hardware module. The firmware-decryption key is necessary to use the associated firmware package. Generally, separate distribution mechanisms will be employed for the firmware-decryption key and the firmware package. An optional mechanism for securely distributing the firmware-decryption key with the firmware package is specified in Section 2.3.1.
ファームウェアパッケージが暗号化されている場合、ファームウェア復号化キーとファームウェアパッケージの両方をハードウェアモジュールに提供する必要があります。ファームウェア復号化キーは、関連するファームウェアパッケージを使用するために必要です。一般に、ファームウェア復号化キーとファームウェアパッケージには、個別の配布メカニズムが採用されます。ファームウェア復号キーをファームウェアパッケージとともに安全に配布するためのオプションのメカニズムは、セクション2.3.1で指定されています。
+------------------------------------------------------+
| Hardware Module |
| |
| +---------------+ +--------------------------+ |
| | Bootstrap | | Firmware Package | |
| | Loader | | | |
| +---------------+ | +------------------+ | |
| | : Firmware Package : | |
| +---------------+ | : Identifier and : | |
| | Trust | | : Version Number : | |
| | Anchor(s) | | +------------------+ | |
| +---------------+ | | |
| | +-------------+ | |
| +---------------+ | : Algorithm 1 : | |
| | Serial Num. | | +-+-----------+-+ | |
| +---------------+ | : Algorithm 2 : | |
| | +-+-----------+-+ | |
| +---------------+ | : Algorithm n : | |
| | Hardware | | +-------------+ | |
| | Module Type | | | |
| +---------------+ +--------------------------+ |
| |
| +------------------------------------+ |
| | Optional Private Signature Key & | |
| | Signature Validation Certificate | |
| | or the Certificate Designator | |
| +------------------------------------+ |
| |
+------------------------------------------------------+
Figure 1. Architectural Elements
図1.アーキテクチャ要素
Many different vendors develop hardware modules, and each vendor typically identifies its modules by product type (family) and revision level. A unique object identifier MUST name each hardware module type and revision.
多くの異なるベンダーがハードウェアモジュールを開発しており、各ベンダーは通常、モジュールを製品タイプ（ファミリ）とリビジョンレベルで識別しています。一意のオブジェクト識別子は、各ハードウェアモジュールのタイプとリビジョンを指定する必要があります。
Each hardware module within a hardware module family SHOULD have a unique permanent serial number. However, if the optional receipt or error report generation capability is implemented, then the hardware module MUST have a unique permanent serial number. If the optional receipt or error report signature capability is implemented, then the hardware module MUST have a private signature key and a certificate containing the corresponding public signature validation key or its designator. If a serial number is present, the bootstrap loader uses it for authorization decisions (see Section 2.2.8), receipt generation (see Section 3), and error report generation (see Section 4).
ハードウェアモジュールファミリ内の各ハードウェアモジュールには、一意の永続的なシリアル番号が必要です（SHOULD）。ただし、オプションの受信またはエラーレポート生成機能が実装されている場合、ハードウェアモジュールには一意の永続的なシリアル番号が必要です。オプションの受信またはエラーレポートの署名機能が実装されている場合、ハードウェアモジュールには、秘密署名キーと、対応する公開署名検証キーまたはその指定子を含む証明書が必要です。シリアル番号が存在する場合、ブートストラップローダーは、それを承認決定（セクション2.2.8を参照）、レシートの生成（セクション3を参照）、およびエラーレポートの生成（セクション4を参照）に使用します。
When the hardware module includes more than one firmware-programmable component, the bootstrap loader distributes components of the package to the appropriate components within the hardware module after the firmware package is validated. The bootstrap loader is discussed further in Section 1.2.3.
ハードウェアモジュールに複数のファームウェアプログラマブルコンポーネントが含まれている場合、ファームウェアパッケージが検証された後、ブートストラップローダーはパッケージのコンポーネントをハードウェアモジュール内の適切なコンポーネントに配布します。ブートストラップローダーについては、セクション1.2.3で詳しく説明します。
Two approaches to naming firmware packages are supported: legacy and preferred. Firmware package names are placed in a CMS signed attribute, not in the firmware package itself.
ファームウェアパッケージの命名には、レガシーと優先の2つのアプローチがサポートされています。ファームウェアパッケージ名は、ファームウェアパッケージ自体ではなく、CMS署名属性に配置されます。
Legacy firmware package names are simply octet strings, and no structure is assumed. This firmware package name form is supported in order to facilitate existing configuration management systems. We assume that the firmware signer and the bootstrap loader will understand any internal structure to the octet string. In particular, given two legacy firmware package names, we assume that the firmware signer and the bootstrap loader will be able to determine which one represents the newer version of the firmware package. This capability is necessary to implement the stale version feature. If a firmware package with a disastrous flaw is released, subsequent firmware package versions MAY designate a stale legacy firmware package name in order to prevent subsequent rollback to the stale version or versions earlier than the stale version.
レガシーファームウェアパッケージ名は単にオクテット文字列であり、構造は想定されていません。このファームウェアパッケージ名の形式は、既存の構成管理システムを容易にするためにサポートされています。ファームウェアの署名者とブートストラップローダーは、オクテット文字列の内部構造を理解すると想定しています。特に、2つのレガシーファームウェアパッケージ名が与えられた場合、ファームウェア署名者とブートストラップローダーがどちらがファームウェアパッケージの新しいバージョンを表すかを判別できると想定します。この機能は、古いバージョンの機能を実装するために必要です。悲惨な欠陥のあるファームウェアパッケージがリリースされた場合、古いバージョンまたは古いバージョンよりも前のバージョンへの後続のロールバックを防ぐために、後続のファームウェアパッケージバージョンは古いレガシーファームウェアパッケージ名を指定する場合があります。
Preferred firmware package names are a combination of the firmware package object identifier and a version number. A unique object identifier MUST identify the collection of features that characterize the firmware package. For example, firmware packages for a cable modem and a wireless LAN network interface card warrant distinct object identifiers. Similarly, firmware packages that implement distinct suites of cryptographic algorithms and modes of operation, or that emulate different (non-programmable) cryptographic devices warrant distinct object identifiers. The version number MUST identify a particular build or release of the firmware package. The version number MUST be a monotonically increasing non-negative integer. Generally, an earlier version is replaced with a later one. If a firmware package with a disastrous flaw is released, subsequent firmware package versions MAY designate a stale version number to prevent subsequent rollback to the stale version or versions earlier than the stale version.
優先ファームウェアパッケージ名は、ファームウェアパッケージオブジェクト識別子とバージョン番号の組み合わせです。一意のオブジェクト識別子は、ファームウェアパッケージを特徴付ける機能のコレクションを識別する必要があります。たとえば、ケーブルモデムと無線LANネットワークインターフェイスカードのファームウェアパッケージは、個別のオブジェクト識別子を保証します。同様に、暗号化アルゴリズムと動作モードの個別のスイートを実装する、または異なる（プログラム不可能な）暗号化デバイスをエミュレートするファームウェアパッケージは、個別のオブジェクト識別子を保証します。バージョン番号は、ファームウェアパッケージの特定のビルドまたはリリースを識別する必要があります。バージョン番号は単調に増加する非負の整数でなければなりません。通常、以前のバージョンは新しいバージョンに置き換えられます。悲惨な欠陥のあるファームウェアパッケージがリリースされた場合、後続のファームウェアパッケージバージョンは、古いバージョン番号を指定して、古いバージョンまたは古いバージョンより前のバージョンへの後続のロールバックを防ぐことができます。
Firmware packages are developed to run on one or more hardware module type. The firmware package digital signature MUST bind the list of supported hardware module object identifiers to the firmware package.
ファームウェアパッケージは、1つ以上のハードウェアモジュールタイプで実行するように開発されています。ファームウェアパッケージのデジタル署名は、サポートされているハードウェアモジュールオブジェクト識別子のリストをファームウェアパッケージにバインドする必要があります。
In many cases, the firmware package signature will be validated directly with the trust anchor public key, avoiding the need to construct certification paths. Alternatively, the trust anchor can delegate firmware package signing to another public key through a certification path. In the latter case, the firmware package SHOULD contain the certificates needed to construct the certification path that begins with a certificate issued by the trust anchors and ends with a certificate issued to the firmware package signer.
多くの場合、ファームウェアパッケージの署名は、トラストアンカー公開鍵を使用して直接検証されるため、証明書パスを構築する必要がありません。または、トラストアンカーは、証明書パスを介して、ファームウェアパッケージの署名を別の公開鍵に委任できます。後者の場合、ファームウェアパッケージには、トラストアンカーによって発行された証明書で始まり、ファームウェアパッケージの署名者に発行された証明書で終わる証明書パスを構築するために必要な証明書が含まれている必要があります。
The firmware package MAY contain a list of community identifiers. These identifiers name the hardware modules that are authorized to load the firmware package. If the firmware package contains a list of community identifiers, then the bootstrap loader MUST reject the firmware package if the hardware module is not a member of one of the identified communities.
ファームウェアパッケージには、コミュニティ識別子のリストが含まれる場合があります。これらの識別子は、ファームウェアパッケージのロードを許可されているハードウェアモジュールの名前です。ファームウェアパッケージにコミュニティ識別子のリストが含まれている場合、ハードウェアモジュールが識別されたコミュニティのいずれかのメンバーでない場合、ブートストラップローダーはファームウェアパッケージを拒否する必要があります。
When a hardware module includes multiple programmable components, the firmware package SHOULD contain executable code for all of the components. Internal tagging within the firmware package MUST tell the bootstrap loader which portion of the overall firmware package is intended for each component; however, this tagging is expected to be specific to each hardware module. Because this specification treats the firmware package as an opaque binary object, the format of the firmware package is beyond the scope of this specification.
ハードウェアモジュールに複数のプログラム可能なコンポーネントが含まれている場合、ファームウェアパッケージには、すべてのコンポーネントの実行可能コードが含まれている必要があります（SHOULD）。ファームウェアパッケージ内の内部タグ付けは、ファームウェアパッケージ全体のどの部分が各コンポーネントを対象としているのかをブートストラップローダーに通知する必要があります。ただし、このタグ付けは各ハードウェアモジュールに固有であると予想されます。この仕様はファームウェアパッケージを不透明なバイナリオブジェクトとして扱うため、ファームウェアパッケージの形式はこの仕様の範囲を超えています。
The bootstrap loader MUST have access to a physical interface and any related driver or protocol software necessary to obtain a firmware package. The same interface SHOULD be used to deliver receipts and error reports. Details of the physical interface as well as the driver or protocol software are beyond the scope of this specification.
ブートストラップローダーは、ファームウェアパッケージを取得するために必要な物理インターフェイスと関連するドライバーまたはプロトコルソフトウェアにアクセスできる必要があります。同じインターフェースを使用して、レシートとエラーレポートを配信する必要があります（SHOULD）。物理インターフェイスの詳細と、ドライバーまたはプロトコルソフトウェアは、この仕様の範囲を超えています。
The bootstrap loader can be a permanent part of the hardware module, or it can be replaced by loading a firmware package. In Figure 1, the bootstrap loader is implemented as separate logic within the hardware module. Not all hardware modules will include the ability to replace or update the bootstrap loader, and this specification does not mandate such support.
ブートストラップローダーは、ハードウェアモジュールの永続的な部分にすることも、ファームウェアパッケージをロードして置き換えることもできます。図1では、ブートストラップローダーは、ハードウェアモジュール内の個別のロジックとして実装されています。すべてのハードウェアモジュールにブートストラップローダーの置き換えまたは更新機能が含まれるわけではありません。この仕様では、そのようなサポートは必須ではありません。
If the bootstrap loader can be loaded by a firmware package, an initial bootstrap loader MUST be installed in non-volatile memory prior to deployment. All bootstrap loaders, including an initial bootstrap loader if one is employed, MUST meet the requirements in this section. However, the firmware package containing the bootstrap loader MAY also contain other routines.
ブートストラップローダーをファームウェアパッケージでロードできる場合、展開前に初期ブートストラップローダーを不揮発性メモリにインストールする必要があります。すべてのブートストラップローダー（採用されている場合は初期ブートストラップローダーを含む）は、このセクションの要件を満たしている必要があります。ただし、ブートストラップローダーを含むファームウェアパッケージには、他のルーチンも含まれている場合があります。
The bootstrap loader requires access to cryptographic routines. These routines can be implemented specifically for the bootstrap loader, or they can be shared with other hardware module features. The bootstrap loader MUST have access to a one-way hash function and digital signature verification routines to validate the digital signature on the firmware package and to validate the certification path for the firmware-signing certificate.
ブートストラップローダーは暗号化ルーチンへのアクセスを必要とします。これらのルーチンは、ブートストラップローダー専用に実装することも、他のハードウェアモジュール機能と共有することもできます。ブートストラップローダーは、一方向ハッシュ関数とデジタル署名検証ルーチンにアクセスして、ファームウェアパッケージのデジタル署名を検証し、ファームウェア署名証明書の証明書パスを検証する必要があります。
If firmware packages are encrypted, the bootstrap loader MUST have access to a decryption routine. Access to a corresponding encryption function is not required, since hardware modules need not be capable of generating firmware packages. Because some symmetric encryption algorithm implementations (such as AES [AES]) employ separate logic for encryption and decryption, some hardware module savings might result.
ファームウェアパッケージが暗号化されている場合、ブートストラップローダーは復号化ルーチンにアクセスできる必要があります。ハードウェアモジュールはファームウェアパッケージを生成する必要がないため、対応する暗号化機能にアクセスする必要はありません。一部の対称暗号化アルゴリズムの実装（AES [AES]など）は、暗号化と復号化に別々のロジックを採用しているため、一部のハードウェアモジュールが節約される可能性があります。
If firmware packages are compressed, the bootstrap loader MUST also have access to a decompression function. This function can be implemented specifically for the bootstrap loader, or it can be shared with other hardware module features. Access to a corresponding compression function is not required, since hardware modules need not be capable of generating firmware packages.
ファームウェアパッケージが圧縮されている場合、ブートストラップローダーも解凍機能にアクセスできる必要があります。この機能は、ブートストラップローダー専用に実装することも、他のハードウェアモジュール機能と共有することもできます。ハードウェアモジュールはファームウェアパッケージを生成する必要がないため、対応する圧縮機能にアクセスする必要はありません。
If the optional receipt generation or error report capability is supported, the bootstrap loader MUST have access to the hardware module serial number and the object identifier for the hardware module type. If the optional signed receipt generation or signed error report capability is supported, the bootstrap loader MUST also have access to a one-way hash function and digital signature routines, the hardware module private signing key, and the corresponding signature validation certificate or its designator.
オプションのレシート生成またはエラーレポート機能がサポートされている場合、ブートストラップローダーは、ハードウェアモジュールのシリアル番号とハードウェアモジュールタイプのオブジェクト識別子にアクセスできる必要があります。オプションの署名済みレシート生成または署名済みエラーレポート機能がサポートされている場合、ブートストラップローダーは、一方向ハッシュ関数とデジタル署名ルーチン、ハードウェアモジュールの秘密署名キー、および対応する署名検証証明書またはその指定子にもアクセスできる必要があります。
The bootstrap loader requires access to one or more trusted public keys, called trust anchors, to validate the firmware package digital signature. One or more trust anchors MUST be installed in non-volatile memory prior to deployment. The bootstrap loader MUST reject a firmware package if it cannot validate the signature, which MAY require the construction of a valid certification path from the firmware-signing certificate to one of the trust anchors [PROFILE]. However, in many cases, the firmware package signature will be validated directly with the trust anchor public key, avoiding the need to construct certification paths.
ブートストラップローダーは、ファームウェアパッケージのデジタル署名を検証するために、トラストアンカーと呼ばれる1つ以上の信頼できる公開鍵にアクセスする必要があります。展開する前に、1つ以上のトラストアンカーを不揮発性メモリにインストールする必要があります。ブートストラップローダーは、署名を検証できない場合、ファームウェアパッケージを拒否する必要があります。ファームウェア署名証明書からトラストアンカーのいずれかへの有効な証明書パスの構築が必要になる場合があります[PROFILE]。ただし、多くの場合、ファームウェアパッケージの署名は、トラストアンカーの公開キーを使用して直接検証されるため、証明書パスを構築する必要がありません。
The bootstrap loader MUST reject a firmware package if the list of supported hardware module type identifiers within the firmware package does not include the object identifier of the hardware module.
ファームウェアパッケージ内のサポートされているハードウェアモジュールタイプ識別子のリストにハードウェアモジュールのオブジェクト識別子が含まれていない場合、ブートストラップローダーはファームウェアパッケージを拒否する必要があります。
The bootstrap loader MUST reject a firmware package if the firmware package includes a list of community identifiers and the hardware module is not a member of one of the listed communities. The means of determining community membership is beyond the scope of this specification.
ファームウェアパッケージにコミュニティ識別子のリストが含まれ、ハードウェアモジュールがリストされているコミュニティのいずれのメンバーでもない場合、ブートストラップローダーはファームウェアパッケージを拒否する必要があります。コミュニティのメンバーシップを決定する方法は、この仕様の範囲を超えています。
The bootstrap loader MUST reject a firmware package if it cannot successfully decrypt the firmware package using the firmware-decryption key available to the hardware module. The firmware package contains an identifier of the firmware-decryption key needed for decryption.
ブートストラップローダーは、ハードウェアモジュールで利用可能なファームウェア復号化キーを使用してファームウェアパッケージを正常に復号化できない場合、ファームウェアパッケージを拒否する必要があります。ファームウェアパッケージには、復号化に必要なファームウェア復号化キーの識別子が含まれています。
When an earlier version of a firmware package is replacing a later one, the bootstrap loader SHOULD generate a warning. The manner in which a warning is generated is highly dependent on the hardware module and the environment in which it is being used. If a firmware package with a disastrous flaw is released and subsequent firmware package versions designate a stale version, the bootstrap loader SHOULD prevent loading of the stale version and versions earlier than the stale version.
ファームウェアパッケージの以前のバージョンが新しいバージョンを置き換える場合、ブートストラップローダーは警告を生成する必要があります（SHOULD）。警告が生成される方法は、ハードウェアモジュールとそれが使用されている環境に大きく依存します。悲惨な欠陥のあるファームウェアパッケージがリリースされ、後続のファームウェアパッケージバージョンが古いバージョンを指定している場合、ブートストラップローダーは、古いバージョンと古いバージョンより前のバージョンのロードを防止する必要があります（SHOULD）。
In case a firmware package with a disastrous flaw is released, subsequent firmware package versions that employ the legacy firmware package name form MAY include a stale legacy firmware package name to prevent subsequent rollback to the stale version or versions earlier than the stale version. As described in the Security Considerations section of this document, the inclusion of a stale legacy firmware package name in a firmware package cannot completely prevent subsequent use of the stale firmware package. However, many hardware modules are expected to have very few firmware packages written for them, allowing the stale firmware package version feature to provide important protections.
悲惨な欠陥のあるファームウェアパッケージがリリースされた場合、古いファームウェアパッケージ名の形式を使用する後続のファームウェアパッケージバージョンに古い古いファームウェアパッケージ名を含めて、古いバージョンまたは古いバージョンより前のバージョンへの後続のロールバックを防ぐことができます。このドキュメントの「セキュリティに関する考慮事項」セクションで説明されているように、古いレガシーファームウェアパッケージ名をファームウェアパッケージに含めても、古いファームウェアパッケージのその後の使用を完全に防ぐことはできません。ただし、多くのハードウェアモジュールにはファームウェアパッケージがほとんど書き込まれていないことが予想され、古いファームウェアパッケージバージョン機能が重要な保護を提供できるようにします。
Non-volatile storage for stale version numbers is needed. The number of stale legacy firmware package names that can be stored depends on the amount of storage that is available. When a firmware package is loaded and it contains a stale legacy firmware package name, then it SHOULD be added to a list kept in non-volatile storage. When subsequent firmware packages are loaded, the legacy firmware package name of the new package is compared to the list in non-volatile storage. If the legacy firmware package name represents the same version or an older version of a member of the list, then the new firmware packages SHOULD be rejected.
古いバージョン番号の不揮発性ストレージが必要です。保存できる古いレガシーファームウェアパッケージ名の数は、利用可能なストレージの量によって異なります。ファームウェアパッケージが読み込まれ、古いレガシーファームウェアパッケージ名が含まれている場合は、不揮発性ストレージに保持されているリストに追加する必要があります（SHOULD）。後続のファームウェアパッケージがロードされると、新しいパッケージのレガシーファームウェアパッケージ名が、不揮発性ストレージのリストと比較されます。レガシーファームウェアパッケージ名がリストのメンバーの同じバージョンまたは古いバージョンを表す場合、新しいファームウェアパッケージは拒否されるべきです。
The amount of non-volatile storage that needs to be dedicated to saving legacy firmware package names and stale legacy firmware packages names depends on the number of firmware packages that are likely to be developed for the hardware module.
レガシーファームウェアパッケージ名と古いレガシーファームウェアパッケージ名を保存するために専用に必要な不揮発性ストレージの量は、ハードウェアモジュール用に開発される可能性が高いファームウェアパッケージの数によって異なります。
If a firmware package with a disastrous flaw is released, subsequent firmware package versions that employ preferred firmware package name form MAY include a stale version number to prevent subsequent rollback to the stale version or versions earlier than the stale version. As described in the Security Considerations section of this document, the inclusion of a stale version number in a firmware package cannot completely prevent subsequent use of the stale firmware package. However, many hardware modules are expected to have very few firmware packages written for them, allowing the stale firmware package version feature to provide important protections.
悲惨な欠陥のあるファームウェアパッケージがリリースされた場合、優先ファームウェアパッケージ名形式を使用する後続のファームウェアパッケージバージョンには、古いバージョン番号を含めて、古いバージョンまたは古いバージョンより前のバージョンへの後続のロールバックを防ぐことができます。このドキュメントの「セキュリティに関する考慮事項」セクションで説明されているように、古いバージョン番号をファームウェアパッケージに含めても、古いファームウェアパッケージのその後の使用を完全に防ぐことはできません。ただし、多くのハードウェアモジュールにはファームウェアパッケージがほとんど書き込まれていないことが予想され、古いファームウェアパッケージバージョン機能が重要な保護を提供できるようにします。
Non-volatile storage for stale version numbers is needed. The number of stale version numbers that can be stored depends on the amount of storage that is available. When a firmware package is loaded and it contains a stale version number, then the object identifier of the firmware package and the stale version number SHOULD be added to a list that is kept in non-volatile storage. When subsequent firmware packages are loaded, the object identifier and version number of the new package are compared to the list in non-volatile storage. If the object identifier matches and the version number is less than or equal to the stale version number, then the new firmware packages SHOULD be rejected.
古いバージョン番号の不揮発性ストレージが必要です。保管できる古いバージョン番号の数は、使用可能なストレージの量によって異なります。ファームウェアパッケージが読み込まれ、古いバージョン番号が含まれている場合、ファームウェアパッケージのオブジェクト識別子と古いバージョン番号を、不揮発性ストレージに保持されているリストに追加する必要があります（SHOULD）。後続のファームウェアパッケージがロードされると、新しいパッケージのオブジェクト識別子とバージョン番号が、不揮発性ストレージのリストと比較されます。オブジェクト識別子が一致し、バージョン番号が古いバージョン番号以下の場合、新しいファームウェアパッケージは拒否されるべきです（SHOULD）。
The amount of non-volatile storage that needs to be dedicated to saving firmware package identifiers and stale version numbers depends on the number of firmware packages that are likely to be developed for the hardware module.
ファームウェアパッケージ識別子と古いバージョン番号を保存するために専用に必要な不揮発性ストレージの量は、ハードウェアモジュール用に開発される可能性が高いファームウェアパッケージの数によって異なります。
A trust anchor MUST consist of a public key signature algorithm and an associated public key, which MAY optionally include parameters. A trust anchor MUST also include a public key identifier. A trust anchor MAY also include an X.500 distinguished name.
トラストアンカーは、公開鍵署名アルゴリズムと関連する公開鍵で構成されている必要があり、オプションでパラメーターを含めることができます（MAY）。トラストアンカーには、公開キー識別子も含める必要があります。トラストアンカーには、X.500識別名も含まれる場合があります。
The trust anchor public key is used in conjunction with the signature validation algorithm in two different ways. First, the trust anchor public key is used directly to validate the firmware package signature. Second, the trust anchor public key is used to validate an X.509 certification path, and then the subject public key in the final certificate in the certification path is used to validate the firmware package signature.
トラストアンカー公開鍵は、署名検証アルゴリズムと2つの異なる方法で使用されます。まず、トラストアンカーの公開キーを直接使用して、ファームウェアパッケージの署名を検証します。次に、トラストアンカー公開鍵を使用してX.509証明書パスを検証し、次に証明書パスの最終証明書のサブジェクト公開鍵を使用してファームウェアパッケージの署名を検証します。
The public key names the trust anchor, and each public key has a public key identifier. The public key identifier identifies the trust anchor as the signer when it is used directly to validate firmware package signatures. This key identifier can be stored with the trust anchor, or it can be computed from the public key whenever needed.
公開鍵はトラストアンカーに名前を付け、各公開鍵には公開鍵識別子があります。公開鍵識別子は、ファームウェアパッケージの署名を検証するために直接使用される場合、トラストアンカーを署名者として識別します。このキー識別子は、トラストアンカーと共に保存するか、必要に応じて公開キーから計算できます。
The optional trusted X.500 distinguished name MUST be present in order for the trust anchor public key to be used to validate an X.509 certification path. Without an X.500 distinguished name, certification path construction cannot use the trust anchor.
トラストアンカーの公開キーを使用してX.509証明書のパスを検証するには、オプションの信頼できるX.500識別名が存在する必要があります。 X.500識別名がないと、証明書パスの構築でトラストアンカーを使用できません。
A firmware package for a cryptographic hardware module includes cryptographic algorithm implementations. In addition, a firmware package for a non-cryptographic hardware module will likely include cryptographic algorithm implementations to support the bootstrap loader in the validation of firmware packages.
暗号化ハードウェアモジュールのファームウェアパッケージには、暗号化アルゴリズムの実装が含まれています。さらに、非暗号化ハードウェアモジュールのファームウェアパッケージには、ファームウェアパッケージの検証でブートストラップローダーをサポートする暗号化アルゴリズムの実装が含まれている可能性があります。
A unique algorithm object identifier MUST be assigned for each cryptographic algorithm and mode implemented by a firmware package. A unique algorithm object identifier MUST also be assigned for each compression algorithm implemented by a firmware package. The algorithm object identifiers can be used to determine whether a particular firmware package satisfies the needs of a particular application. To facilitate the development of algorithm-agile applications, the cryptographic module interface SHOULD allow applications to query the cryptographic module for the object identifiers associated with each cryptographic algorithm contained in the currently loaded firmware package. Applications SHOULD also be able to query the cryptographic module to determine attributes associated with each algorithm. Such attributes might include the algorithm type (symmetric encryption, asymmetric encryption, key agreement, one-way hash function, digital signature, and so on), the algorithm block size or modulus size, and parameters for asymmetric algorithms. This specification does not establish the conventions for the retrieval of algorithm identifiers or algorithm attributes.
一意のアルゴリズムオブジェクト識別子は、ファームウェアパッケージによって実装される暗号化アルゴリズムおよびモードごとに割り当てられる必要があります。一意のアルゴリズムオブジェクト識別子も、ファームウェアパッケージによって実装された各圧縮アルゴリズムに割り当てる必要があります。アルゴリズムオブジェクト識別子を使用して、特定のファームウェアパッケージが特定のアプリケーションのニーズを満たすかどうかを判断できます。アルゴリズムアジャイルアプリケーションの開発を容易にするために、暗号化モジュールインターフェイスは、アプリケーションが現在読み込まれているファームウェアパッケージに含まれている各暗号化アルゴリズムに関連付けられているオブジェクト識別子を暗号化モジュールに照会できるようにする必要があります（SHOULD）。アプリケーションは、暗号化モジュールにクエリを実行して、各アルゴリズムに関連付けられている属性を判断することもできます（SHOULD）。このような属性には、アルゴリズムのタイプ（対称暗号化、非対称暗号化、鍵合意、一方向ハッシュ関数、デジタル署名など）、アルゴリズムブロックサイズまたは係数サイズ、および非対称アルゴリズムのパラメーターが含まれる場合があります。この仕様は、アルゴリズム識別子またはアルゴリズム属性の取得に関する規則を確立していません。
The bootstrap loader MAY be permanently stored in read-only memory or separately loaded into non-volatile memory as discussed above.
ブートストラップローダーは、読み取り専用メモリに永続的に保存するか、前述のように個別に不揮発性メモリにロードすることができます。
In most hardware module designs, the firmware package execution environment offers a single address space. If it does, the firmware package SHOULD contain a complete firmware package load for the hardware module. In this situation, the firmware package does not contain a partial or incremental set of functions. A complete firmware package load will minimize complexity and avoid potential security problems. From a complexity perspective, the incremental loading of packages makes it necessary for each package to identify any other packages that are required (its dependencies), and the bootstrap loader needs to verify that all of the dependencies are satisfied before attempting to execute the firmware package. When a hardware module is based on a general purpose processor or a digital signal processor, it is dangerous to allow arbitrary packages to be loaded simultaneously unless there is a reference monitor to ensure that independent portions of the code cannot interfere with one another. Also, it is difficult to evaluate arbitrary combinations of software modules [SECREQMTS]. For these reasons, a complete firmware package load is RECOMMENDED; however, this specification allows the firmware signer to identify dependencies between firmware packages in order to handle all situations.
ほとんどのハードウェアモジュール設計では、ファームウェアパッケージ実行環境は単一のアドレス空間を提供します。含まれている場合、ファームウェアパッケージには、ハードウェアモジュールの完全なファームウェアパッケージロードが含まれている必要があります。この状況では、ファームウェアパッケージには、機能の一部または増分セットが含まれていません。完全なファームウェアパッケージのロードにより、複雑さが最小限に抑えられ、潜在的なセキュリティの問題が回避されます。複雑さの観点から、パッケージのインクリメンタルロードにより、各パッケージは必要な他のパッケージ（依存関係）を特定する必要があり、ブートストラップローダーはファームウェアパッケージを実行する前にすべての依存関係が満たされていることを確認する必要があります。ハードウェアモジュールが汎用プロセッサまたはデジタルシグナルプロセッサに基づいている場合、コードの独立した部分が互いに干渉できないことを保証するリファレンスモニターがない限り、任意のパッケージを同時にロードすることは危険です。また、ソフトウェアモジュールの任意の組み合わせを評価することは困難です[SECREQMTS]。これらの理由により、完全なファームウェアパッケージのロードが推奨されます。ただし、この仕様では、すべての状況を処理するために、ファームウェア署名者がファームウェアパッケージ間の依存関係を識別できます。
The firmware packages MAY have dependencies on routines provided by other firmware packages. To minimize the security evaluation complexity of a hardware module employing such a design, the firmware package MUST identify the package identifiers (and the minimum version numbers when the preferred firmware package name form is used) of the packages upon which it depends. The bootstrap loader MUST reject a firmware package load if it contains a dependency on a firmware package that is not available.
ファームウェアパッケージは、他のファームウェアパッケージによって提供されるルーチンに依存する場合があります。このような設計を採用するハードウェアモジュールのセキュリティ評価の複雑さを最小限に抑えるために、ファームウェアパッケージは、依存するパッケージのパッケージ識別子（および優先ファームウェアパッケージ名の形式が使用される場合の最小バージョン番号）を識別しなければなりません。ブートストラップローダーは、利用できないファームウェアパッケージへの依存関係が含まれている場合、ファームウェアパッケージのロードを拒否する必要があります。
Loading a firmware package can impact the satisfactory resolution of dependencies of other firmware packages that are already part of the hardware module configuration. For this reason, the bootstrap loader MUST reject the loading of a firmware package if the dependencies of any firmware package in the resulting configurations will be unsatisfied.
ファームウェアパッケージをロードすると、すでにハードウェアモジュール構成に含まれている他のファームウェアパッケージの依存関係の十分な解決に影響を与える可能性があります。このため、結果の構成内のファームウェアパッケージの依存関係が満たされない場合、ブートストラップローダーはファームウェアパッケージのロードを拒否する必要があります。
The CMS uses Abstract Syntax Notation One (ASN.1) [X.208-88, X.209-88]. ASN.1 is a formal notation used for describing data protocols, regardless of the programming language used by the implementation. Encoding rules describe how the values defined in ASN.1 will be represented for transmission. The Basic Encoding Rules (BER) are the most widely employed rule set, but they offer more than one way to represent data structures. For example, definite length encoding and indefinite length encoding are supported. This flexibility is not desirable when digital signatures are used. As a result, the Distinguished Encoding Rules (DER) [X.509-88] were invented. DER is a subset of BER that ensures a single way to represent a given value. For example, DER always employs definite length encoding.
CMSは、抽象構文記法1（ASN.1）[X.208-88、X.209-88]を使用します。 ASN.1は、実装で使用されているプログラミング言語に関係なく、データプロトコルの記述に使用される正式な表記法です。エンコーディングルールは、ASN.1で定義された値が送信のためにどのように表されるかを記述します。 Basic Encoding Rules（BER）は最も広く採用されているルールセットですが、データ構造を表現する方法が複数あります。たとえば、定長エンコーディングと不定長エンコーディングがサポートされています。デジタル署名を使用する場合、この柔軟性は望ましくありません。その結果、Distinguished Encoding Rules（DER）[X.509-88]が発明されました。 DERはBERのサブセットであり、特定の値を表す単一の方法を保証します。たとえば、DERは常に固定長エンコーディングを使用します。
In this specification, digitally signed structures MUST be encoded with DER. Other structures do not require DER, but the use of definite length encoding is strongly RECOMMENDED. By always using definite length encoding, the bootstrap loader will have fewer options to implement. In situations where there is very high confidence that only definite length encoding will be used, support for indefinite length decoding MAY be omitted.
この仕様では、デジタル署名された構造をDERでエンコードする必要があります。他の構造ではDERは必要ありませんが、明確な長さのエンコーディングを使用することを強くお勧めします。常に一定の長さのエンコーディングを使用することにより、ブートストラップローダーは実装するオプションが少なくなります。明確な長さのエンコードのみが使用されるという非常に高い信頼性がある状況では、不明確な長さのデコードのサポートは省略される場合があります。
This document does not attempt to specify a physical interface, any related driver software, or a protocol necessary for loading firmware packages. Many different delivery mechanisms are envisioned, including portable memory devices, file transfer, and web pages. Section 2 of this specification defines the format that MUST be presented to the hardware module regardless of the interface that is used. This specification also specifies the format of the response that MAY be generated by the hardware module. Section 3 of this specification defines the format that MAY be returned by the hardware module when a firmware package loads successfully. Section 4 of this specification defines the format that MAY be returned by the hardware module when a firmware package load is unsuccessful. The firmware package load receipts and firmware package load error reports can be either signed or unsigned.
このドキュメントでは、ファームウェアパッケージのロードに必要な物理インターフェイス、関連するドライバソフトウェア、またはプロトコルを指定することを試みていません。ポータブルメモリデバイス、ファイル転送、Webページなど、さまざまな配信メカニズムが想定されています。この仕様のセクション2は、使用するインターフェイスに関係なく、ハードウェアモジュールに提示する必要がある形式を定義しています。この仕様は、ハードウェアモジュールによって生成される可能性がある応答の形式も指定します。この仕様のセクション3は、ファームウェアパッケージが正常にロードされたときにハードウェアモジュールによって返される可能性があるフォーマットを定義しています。この仕様のセクション4は、ファームウェアパッケージのロードに失敗したときにハードウェアモジュールによって返される可能性があるフォーマットを定義しています。ファームウェアパッケージロードの領収書とファームウェアパッケージロードのエラーレポートは、署名されている場合と、署名されていない場合があります。
The Cryptographic Message Syntax (CMS) is used to protect a firmware package, which is treated as an opaque binary object. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. The CMS ContentInfo content type MUST always be present, and it MUST encapsulate the CMS SignedData content type. If the firmware package is encrypted, then the CMS SignedData content type MUST encapsulate the CMS EncryptedData content type. If the firmware package is compressed, then either the CMS SignedData content type (when encryption is not used) or the CMS EncryptedData content type (when encryption is used) MUST encapsulate the CMS CompressedData content type. Finally, (1) the CMS SignedData content type (when neither encryption nor compression is used), (2) the CMS EncryptedData content type (when encryption is used, but compression is not), or (3) the CMS CompressedData content type (when compression is used) MUST encapsulate the simple firmware package using the FirmwarePkgData content type defined in this specification (see Section 2.1.5).
暗号メッセージ構文（CMS）は、不透明なバイナリオブジェクトとして扱われるファームウェアパッケージを保護するために使用されます。デジタル署名は、ファームウェアパッケージを検出されない変更から保護し、データ発信元認証を提供するために使用されます。暗号化は、ファームウェアパッケージを開示から保護するためにオプションで使用され、圧縮は、保護されたファームウェアパッケージのサイズを縮小するためにオプションで使用されます。 CMS ContentInfoコンテンツタイプは常に存在する必要があり、CMS SignedDataコンテンツタイプをカプセル化する必要があります。ファームウェアパッケージが暗号化されている場合、CMS SignedDataコンテンツタイプはCMS EncryptedDataコンテンツタイプをカプセル化する必要があります。ファームウェアパッケージが圧縮されている場合、CMS SignedDataコンテンツタイプ（暗号化が使用されていない場合）またはCMS EncryptedDataコンテンツタイプ（暗号化が使用されている場合）は、CMS CompressedDataコンテンツタイプをカプセル化する必要があります。最後に、（1）CMS SignedDataコンテンツタイプ（暗号化も圧縮も使用されていない場合）、（2）CMS EncryptedDataコンテンツタイプ（暗号化が使用されているが圧縮は使用されていない場合）、または（3）CMS CompressedDataコンテンツタイプ（圧縮を使用する場合）この仕様で定義されているFirmwarePkgDataコンテンツタイプを使用して単純なファームウェアパッケージをカプセル化する必要があります（セクション2.1.5を参照）。
The firmware package protection is summarized as follows (see [CMS] for the full syntax):
ファームウェアパッケージ保護は、次のように要約されます（完全な構文については、[CMS]を参照してください）。
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData
}
SignedData {
version CMSVersion, -- always set to 3
digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Signer cert. path
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one
}
SignerInfo {
version CMSVersion, -- always set to 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Optional
}
EncapsulatedContentInfo {
eContentType id-encryptedData, -- (1.2.840.113549.1.7.6)
-- OR --
id-ct-compressedData,
-- (1.2.840.113549.1.9.16.1.9)
-- OR --
id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
eContent OCTET STRING
} -- Contains EncryptedData OR
-- CompressedData OR
-- FirmwarePkgData
EncryptedData {
version CMSVersion, -- Always set to 0
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs UnprotectedAttributes -- Omit
}
EncryptedContentInfo {
contentType id-ct-compressedData,
-- (1.2.840.113549.1.9.16.1.9)
-- OR --
id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent OCTET STRING
} -- Contains CompressedData OR
-- FirmwarePkgData
CompressedData {
version CMSVersion, -- Always set to 0
compressionAlgorithm CompressionAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo
}
EncapsulatedContentInfo {
eContentType id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
eContent OCTET STRING -- Contains FirmwarePkgData
}
FirmwarePkgData OCTET STRING -- Contains firmware package
FirmwarePkgData OCTET STRING-ファームウェアパッケージが含まれています
This section specifies the conventions for using the CMS ContentInfo, SignedData, EncryptedData, and CompressedData content types. It also defines the FirmwarePkgData content type.
このセクションでは、CMS ContentInfo、SignedData、EncryptedData、およびCompressedDataコンテンツタイプを使用するための規則を指定します。 FirmwarePkgDataコンテンツタイプも定義します。
The CMS requires that the outermost encapsulation be ContentInfo [CMS]. The fields of ContentInfo are used as follows:
CMSでは、最も外側のカプセル化がContentInfo [CMS]である必要があります。 ContentInfoのフィールドは次のように使用されます。
contentType indicates the type of the associated content, and in this case, the encapsulated type is always SignedData. The id-signedData (1.2.840.113549.1.7.2) object identifier MUST be present in this field.
contentTypeは関連するコンテンツのタイプを示し、この場合、カプセル化されたタイプは常にSignedDataです。 id-signedData（1.2.840.113549.1.7.2）オブジェクト識別子は、このフィールドに存在する必要があります。
content holds the associated content, and in this case, the content field MUST contain SignedData.
contentは関連付けられたコンテンツを保持します。この場合、contentフィールドにはSignedDataが含まれている必要があります。
The SignedData content type [CMS] contains the signed firmware package (which might be compressed, encrypted, or compressed and then encrypted prior to signature), the certificates needed to validate the signature, and one digital signature value. The fields of SignedData are used as follows:
SignedDataコンテンツタイプ[CMS]には、署名済みファームウェアパッケージ（圧縮、暗号化、または圧縮してから暗号化してから署名する）、署名の検証に必要な証明書、および1つのデジタル署名値が含まれます。 SignedDataのフィールドは次のように使用されます。
version is the syntax version number, and in this case, it MUST be set to 3.
versionは構文のバージョン番号で、この場合は3に設定する必要があります。
digestAlgorithms is a collection of message digest algorithm identifiers, and in this case, it MUST contain a single message digest algorithm identifier. The message digest algorithm employed by the firmware package signer MUST be present.
digestAlgorithmsは、メッセージダイジェストアルゴリズム識別子のコレクションであり、この場合、単一のメッセージダイジェストアルゴリズム識別子を含んでいる必要があります。ファームウェアパッケージの署名者が使用するメッセージダイジェストアルゴリズムが存在する必要があります。
encapContentInfo contains the signed content, consisting of a content type identifier and the content itself. The use of the EncapsulatedContentInfo type is discussed further in Section 2.1.2.2.
encapContentInfoには、コンテンツタイプ識別子とコンテンツ自体で構成される署名付きコンテンツが含まれています。 EncapsulatedContentInfoタイプの使用については、セクション2.1.2.2で詳しく説明します。
certificates is an optional collection of certificates. If the trust anchor signed the firmware package directly, then certificates SHOULD be omitted. If it did not, then certificates SHOULD include the X.509 certificate of the firmware package signer. The set of certificates SHOULD be sufficient for the bootstrap loader to construct a certification path from the trust anchor to the firmware-signer's certificate. PKCS#6 extended certificates
証明書は、オプションの証明書のコレクションです。トラストアンカーがファームウェアパッケージに直接署名した場合、証明書は省略してください。含まれていない場合は、証明書にファームウェアパッケージ署名者のX.509証明書を含める必要があります。証明書のセットは、ブートストラップローダーがトラストアンカーからファームウェア署名者の証明書への証明書パスを構築するのに十分である必要があります（SHOULD）。 PKCS＃6拡張証明書
[PKCS#6] and attribute certificates (either version 1 or version 2) [X.509-97, X.509-00, ACPROFILE] MUST NOT be included in the set of certificates.
[PKCS＃6]および属性証明書（バージョン1またはバージョン2のいずれか）[X.509-97、X.509-00、ACPROFILE]は、証明書のセットに含めることはできません。
crls is an optional collection of certificate revocation lists (CRLs), and in this case, CRLs SHOULD NOT be included by the firmware package signer. It is anticipated that firmware packages may be generated, signed, and made available in repositories for downloading into hardware modules. In such contexts, it would be difficult for the firmware package signer to include timely CRLs in the firmware package. However, because the CRLs are not covered by the signature, timely CRLs MAY be inserted by some other party before the firmware package is delivered to the hardware module.
crlsは証明書失効リスト（CRL）のオプションのコレクションであり、この場合、CRLはファームウェアパッケージの署名者によって含まれるべきではありません（SHOULD NOT）。ファームウェアパッケージが生成され、署名され、ハードウェアモジュールにダウンロードするためにリポジトリで利用可能になることが予想されます。このような状況では、ファームウェアパッケージの署名者がファームウェアパッケージにタイムリーなCRLを含めることは困難です。ただし、CRLは署名によってカバーされていないため、ファームウェアパッケージがハードウェアモジュールに配信される前に、タイムリーなCRLが他のパーティによって挿入される場合があります。
signerInfos is a collection of per-signer information, and in this case, the collection MUST contain exactly one SignerInfo. The use of the SignerInfo type is discussed further in Section 2.1.2.1.
signerInfosは署名者ごとの情報のコレクションであり、この場合、コレクションには1つのSignerInfoが含まれている必要があります。 SignerInfoタイプの使用については、2.1.2.1項で詳しく説明します。
The firmware package signer is represented in the SignerInfo type. The fields of SignerInfo are used as follows:
ファームウェアパッケージの署名者は、SignerInfoタイプで表されます。 SignerInfoのフィールドは次のように使用されます。
version is the syntax version number, and it MUST be 3.
versionは構文バージョン番号であり、3でなければなりません。
sid identifies the signer's public key. CMS supports two alternatives: issuerAndSerialNumber and subjectKeyIdentifier. However, the bootstrap loader MUST support the subjectKeyIdentifier alternative, which identifies the signer's public key directly. When this public key is contained in a certificate, this identifier SHOULD appear in the X.509 subjectKeyIdentifier extension.
sidは、署名者の公開鍵を識別します。 CMSは、issuerAndSerialNumberとsubjectKeyIdentifierの2つの選択肢をサポートしています。ただし、ブートストラップローダーは、署名者の公開鍵を直接識別するsubjectKeyIdentifier代替をサポートする必要があります。この公開鍵が証明書に含まれている場合、この識別子はX.509 subjectKeyIdentifier拡張に現れる必要があります（SHOULD）。
digestAlgorithm identifies the message digest algorithm, and any associated parameters, used by the firmware package signer. It MUST contain the message digest algorithms employed by the firmware package signer. (Note that this message digest algorithm identifier MUST be the same as the one carried in the digestAlgorithms value in SignedData.)
digestAlgorithmは、ファームウェアパッケージの署名者が使用するメッセージダイジェストアルゴリズムおよび関連するパラメーターを識別します。ファームウェアパッケージの署名者が使用するメッセージダイジェストアルゴリズムを含める必要があります。 （このメッセージダイジェストアルゴリズムの識別子は、SignedDataのdigestAlgorithms値で運ばれるものと同じでなければならないことに注意してください。）
signedAttrs is an optional collection of attributes that are signed along with the content. The signedAttrs are optional in the CMS, but in this specification, signedAttrs are REQUIRED for the firmware package; however, implementations MUST ignore unrecognized signed attributes. The SET OF attributes MUST be DER encoded [X.509-88]. Section 2.2 of this document lists the attributes that MUST be included in the collection; other attributes MAY be included as well.
signedAttrsは、コンテンツとともに署名されるオプションの属性のコレクションです。 signedAttrsはCMSではオプションですが、この仕様では、ファームウェアパッケージにはsignedAttrsが必要です。ただし、実装では、認識されない署名付き属性を無視する必要があります。 SET OF属性は、DERエンコードされている必要があります[X.509-88]。このドキュメントのセクション2.2には、コレクションに含める必要がある属性がリストされています。他の属性も含めることができます（MAY）。
signatureAlgorithm identifies the signature algorithm, and any associated parameters, used by the firmware package signer to generate the digital signature.
signatureAlgorithmは、デジタル署名を生成するためにファームウェアパッケージの署名者が使用する署名アルゴリズムと関連パラメータを識別します。
signature is the digital signature value.
signatureはデジタル署名の値です。
unsignedAttrs is an optional SET of attributes that are not signed. As described in Section 2.3, this set can only contain a single instance of the wrapped-firmware-decryption-key attribute and no others.
unsignedAttrsは、署名されていない属性のオプションのSETです。セクション2.3で説明したように、このセットに含めることができるのは、wrapped-firmware-decryption-key属性の単一のインスタンスのみで、他のインスタンスは含まれません。
The EncapsulatedContentInfo content type encapsulates the firmware package, which might be compressed, encrypted, or compressed and then encrypted prior to signature. The firmware package, in any of these formats, is carried within the EncapsulatedContentInfo type. The fields of EncapsulatedContentInfo are used as follows:
EncapsulatedContentInfoコンテンツタイプは、ファームウェアパッケージをカプセル化します。これは、圧縮、暗号化、または圧縮してから署名前に暗号化することができます。これらのいずれかの形式のファームウェアパッケージは、EncapsulatedContentInfoタイプ内で伝送されます。 EncapsulatedContentInfoのフィールドは次のように使用されます。
eContentType is an object identifier that uniquely specifies the content type, and in this case, the value MUST be id-encryptedData (1.2.840.113549.1.7.6), id-ct-compressedData (1.2.840.113549.1.9.16.1.9), or id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16). When eContentType contains id-encryptedData, the firmware package was encrypted prior to signing, and may also have been compressed prior to encryption. When it contains id-ct-compressedData, the firmware package was compressed prior to signing, but was not encrypted. When it contains id-ct-firmwarePackage, the firmware package was not compressed or encrypted prior to signing.
eContentTypeは、コンテンツタイプを一意に指定するオブジェクト識別子であり、この場合、値はid-encryptedData（1.2.840.113549.1.7.6）、id-ct-compressedData（1.2.840.113549.1.9.16.1.9）でなければなりません。 、またはid-ct-firmwarePackage（1.2.840.113549.1.9.16.1.16）。 eContentTypeにid-encryptedDataが含まれている場合、ファームウェアパッケージは署名前に暗号化されており、暗号化前に圧縮されている場合もあります。 id-ct-compressedDataが含まれている場合、ファームウェアパッケージは署名前に圧縮されていましたが、暗号化されていませんでした。 id-ct-firmwarePackageが含まれている場合、ファームウェアパッケージは署名前に圧縮も暗号化もされていません。
eContent contains the signed firmware package, which might also be encrypted, compressed, or compressed and then encrypted, prior to signing. The content is encoded as an octet string. The eContent octet string need not be DER encoded.
eContentには、署名済みのファームウェアパッケージが含まれています。これは、署名する前に、暗号化、圧縮、または圧縮してから暗号化することもできます。コンテンツはオクテット文字列としてエンコードされます。 eContentオクテット文字列は、DERエンコードする必要はありません。
The EncryptedData content type [CMS] contains the encrypted firmware package (which might be compressed prior to encryption). However, if the firmware package was not encrypted, the EncryptedData content type is not present. The fields of EncryptedData are used as follows: version is the syntax version number, and in this case, version MUST be 0.
EncryptedDataコンテンツタイプ[CMS]には、暗号化されたファームウェアパッケージが含まれています（暗号化前に圧縮されている場合があります）。ただし、ファームウェアパッケージが暗号化されていない場合、EncryptedDataコンテンツタイプは存在しません。 EncryptedDataのフィールドは次のように使用されます。versionは構文のバージョン番号であり、この場合、versionは0でなければなりません。
encryptedContentInfo is the encrypted content information. The use of the EncryptedContentInfo type is discussed further in Section 2.1.3.1.
encryptedContentInfoは、暗号化されたコンテンツ情報です。 EncryptedContentInfoタイプの使用については、2.1.3.1項で詳しく説明します。
unprotectedAttrs is an optional collection of unencrypted attributes, and in this case, unprotectedAttrs MUST NOT be present.
unprotectedAttrsは、暗号化されていない属性のオプションのコレクションであり、この場合、unprotectedAttrsは存在してはなりません（MUST NOT）。
The encrypted firmware package, which might be compressed prior to encryption, is encapsulated in the EncryptedContentInfo type. The fields of EncryptedContentInfo are used as follows:
暗号化前に圧縮されている可能性がある暗号化されたファームウェアパッケージは、EncryptedContentInfoタイプにカプセル化されます。 EncryptedContentInfoのフィールドは次のように使用されます。
contentType indicates the type of content, and in this case, it MUST contain either id-ct-compressedData (1.2.840.113549.1.9.16.1.9) or id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16). When it contains id-ct-compressedData, then the firmware package was compressed prior to encryption. When it contains id-ct-firmwarePackage, then the firmware package was not compressed prior to encryption.
contentTypeはコンテンツのタイプを示し、この場合、id-ct-compressedData（1.2.840.113549.1.9.16.1.9）またはid-ct-firmwarePackage（1.2.840.113549.1.9.16.1.16）のいずれかを含む必要があります。 id-ct-compressedDataが含まれている場合、ファームウェアパッケージは暗号化の前に圧縮されています。 id-ct-firmwarePackageが含まれている場合、ファームウェアパッケージは暗号化前に圧縮されていません。
contentEncryptionAlgorithm identifies the firmware-encryption algorithm, and any associated parameters, used to encrypt the firmware package.
contentEncryptionAlgorithmは、ファームウェア暗号化アルゴリズム、およびファームウェアパッケージの暗号化に使用される関連パラメータを識別します。
encryptedContent is the result of encrypting the firmware package. The field is optional; however, in this case, it MUST be present.
encryptedContentは、ファームウェアパッケージを暗号化した結果です。このフィールドはオプションです。ただし、この場合は存在する必要があります。
The CompressedData content type [COMPRESS] contains the compressed firmware package. If the firmware package was not compressed, then the CompressedData content type is not present. The fields of CompressedData are used as follows:
CompressedDataコンテンツタイプ[COMPRESS]には、圧縮されたファームウェアパッケージが含まれています。ファームウェアパッケージが圧縮されていない場合、CompressedDataコンテンツタイプは存在しません。 CompressedDataのフィールドは次のように使用されます。
version is the syntax version number; in this case, it MUST be 0.
versionは構文のバージョン番号です。この場合、0でなければなりません。
compressionAlgorithm identifies the compression algorithm, and any associated parameters, used to compress the firmware package.
compressionAlgorithmは、ファームウェアパッケージの圧縮に使用される圧縮アルゴリズムおよび関連するパラメーターを識別します。
encapContentInfo is the compressed content, consisting of a content type identifier and the content itself. The use of the EncapsulatedContentInfo type is discussed further in Section 2.1.4.1.
encapContentInfoは、コンテンツタイプ識別子とコンテンツ自体で構成される圧縮コンテンツです。 EncapsulatedContentInfoタイプの使用については、セクション2.1.4.1で詳しく説明します。
The CompressedData content type encapsulates the compressed firmware package, and it is carried within the EncapsulatedContentInfo type. The fields of EncapsulatedContentInfo are used as follows:
CompressedDataコンテンツタイプは、圧縮されたファームウェアパッケージをカプセル化し、EncapsulatedContentInfoタイプ内で伝送されます。 EncapsulatedContentInfoのフィールドは次のように使用されます。
eContentType is an object identifier that uniquely specifies the content type, and in this case, it MUST be the value of id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16).
eContentTypeは、コンテンツタイプを一意に指定するオブジェクト識別子であり、この場合、id-ct-firmwarePackage（1.2.840.113549.1.9.16.1.16）の値である必要があります。
eContent is the compressed firmware package, encoded as an octet string. The eContent octet string need not be DER encoded.
eContentは、オクテット文字列としてエンコードされた圧縮ファームウェアパッケージです。 eContentオクテット文字列は、DERエンコードする必要はありません。
The FirmwarePkgData content type contains the firmware package. It is a straightforward encapsulation in an octet string, and it need not be DER encoded.
FirmwarePkgDataコンテンツタイプには、ファームウェアパッケージが含まれています。これはオクテット文字列での単純なカプセル化であり、DERエンコードする必要はありません。
The FirmwarePkgData content type is identified by the id-ct-firmwarePackage object identifier:
FirmwarePkgDataコンテンツタイプは、id-ct-firmwarePackageオブジェクト識別子によって識別されます。
id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 16 }
The FirmwarePkgData content type is a simple octet string:
FirmwarePkgDataコンテンツタイプは、単純なオクテット文字列です。
FirmwarePkgData ::= OCTET STRING
The firmware package signer MUST digitally sign a collection of attributes along with the firmware package. Each attribute in the collection MUST be DER encoded [X.509-88]. The syntax for attributes is defined in [CMS], but it is repeated here for convenience:
ファームウェアパッケージの署名者は、ファームウェアパッケージとともに属性のコレクションにデジタル署名する必要があります。コレクションの各属性は、DERエンコードされている必要があります[X.509-88]。属性の構文は[CMS]で定義されていますが、便宜上ここで繰り返します。
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANY
Each of the attributes used with this profile has a single attribute value, even though the syntax is defined as a SET OF AttributeValue. There MUST be exactly one instance of AttributeValue present.
構文がSET OF AttributeValueとして定義されている場合でも、このプロファイルで使用される各属性には単一の属性値があります。 AttributeValueのインスタンスが1つだけ存在している必要があります。
The SignedAttributes syntax within signerInfo is defined as a SET OF Attribute. The SignedAttributes MUST include only one instance of any particular attribute.
signerInfo内のSignedAttributes構文は、SET OF Attributeとして定義されています。 SignedAttributesには、特定の属性のインスタンスを1つだけ含める必要があります。
The firmware package signer MUST include the following four attributes: content-type, message-digest, firmware-package-identifier, and target-hardware-module-identifiers.
ファームウェアパッケージの署名者は、コンテンツタイプ、メッセージダイジェスト、ファームウェアパッケージ識別子、ターゲットハードウェアモジュール識別子の4つの属性を含める必要があります。
If the firmware package is encrypted, then the firmware package signer MUST also include the decrypt-key-identifier attribute.
ファームウェアパッケージが暗号化されている場合、ファームウェアパッケージの署名者は、decrypt-key-identifier属性も含める必要があります。
If the firmware package implements cryptographic algorithms, then the firmware package signer MAY also include the implemented-crypto-algorithms attribute. Similarly, if the firmware package implements compression algorithms, then the firmware package signer MAY also include the implemented-compress-algorithms attribute.
ファームウェアパッケージが暗号化アルゴリズムを実装している場合、ファームウェアパッケージの署名者は、implemented-crypto-algorithms属性も含めることができます（MAY）。同様に、ファームウェアパッケージが圧縮アルゴリズムを実装している場合、ファームウェアパッケージの署名者は、implemented-compress-algorithms属性も含めることができます（MAY）。
If the firmware package is intended for use only by specific communities, then the firmware package signer MUST also include the community-identifiers attribute.
ファームウェアパッケージが特定のコミュニティのみでの使用を目的としている場合、ファームウェアパッケージの署名者はcommunity-identifiers属性も含める必要があります。
If the firmware package depends on the presence of one or more other firmware packages to operate properly, then the firmware package signer SHOULD also include the firmware-package-info attribute. For example, the firmware-package-info attribute dependencies field might indicate that the firmware package contains a dependency on a particular bootstrap loader or separation kernel.
ファームウェアパッケージが適切に動作するために1つ以上の他のファームウェアパッケージの存在に依存している場合、ファームウェアパッケージの署名者はfirmware-package-info属性も含める必要があります（SHOULD）。たとえば、firmware-package-info属性の依存関係フィールドは、ファームウェアパッケージに特定のブートストラップローダーまたは分離カーネルへの依存関係が含まれていることを示す場合があります。
The firmware package signer SHOULD also include the three following attributes: firmware-package-message-digest, signing-time, and content-hints. Additionally, if the firmware package signer has a certificate (meaning that the firmware package signer is not always configured as a trust anchor), then the firmware package signer SHOULD also include the signing-certificate attribute.
ファームウェアパッケージの署名者には、ファームウェアパッケージメッセージダイジェスト、署名時間、コンテンツヒントの3つの属性も含める必要があります（SHOULD）。さらに、ファームウェアパッケージの署名者が証明書を持っている場合（つまり、ファームウェアパッケージの署名者が常にトラストアンカーとして構成されているわけではない）、ファームウェアパッケージの署名者には、signing-certificate属性も含める必要があります（SHOULD）。
The firmware package signer MAY include any other attribute that it deems appropriate.
ファームウェアパッケージの署名者には、適切と見なされるその他の属性を含めることができます。
The firmware package signer MUST include a content-type attribute with the value of id-encryptedData (1.2.840.113549.1.7.6), id-ct-compressedData (1.2.840.113549.1.9.16.1.9), or id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16). When it contains id-encryptedData, the firmware package was encrypted prior to signing. When it contains id-ct-compressedData, the firmware package was compressed prior to signing, but was not encrypted. When it contains id-ct-firmwarePackage, the firmware package was not compressed or encrypted prior to signing. Section 11.1 of [CMS] defines the content-type attribute.
ファームウェアパッケージの署名者は、id-encryptedData（1.2.840.113549.1.7.6）、id-ct-compressedData（1.2.840.113549.1.9.16.1.9）、またはid-ct-の値を持つcontent-type属性を含める必要があります。 firmwarePackage（1.2.840.113549.1.9.16.1.16）。 id-encryptedDataが含まれている場合、ファームウェアパッケージは署名前に暗号化されています。 id-ct-compressedDataが含まれている場合、ファームウェアパッケージは署名前に圧縮されていましたが、暗号化されていませんでした。 id-ct-firmwarePackageが含まれている場合、ファームウェアパッケージは署名前に圧縮も暗号化もされていません。 [CMS]のセクション11.1はcontent-type属性を定義しています。
The firmware package signer MUST include a message-digest attribute, having as its value the message digest computed on the encapContentInfo eContent octet string, as defined in Section 2.1.2.2. This octet string contains the firmware package, and it MAY be compressed, encrypted, or both compressed and encrypted. Section 11.2 of [CMS] defines the message-digest attribute.
ファームウェアパッケージの署名者は、2.1.2.2項で定義されているように、encapContentInfo eContentオクテット文字列で計算されたメッセージダイジェストを値として持つメッセージダイジェスト属性を含める必要があります。このオクテット文字列にはファームウェアパッケージが含まれており、圧縮、暗号化、または圧縮と暗号化の両方が行われる場合があります。 [CMS]のセクション11.2は、メッセージダイジェスト属性を定義しています。
The firmware-package-identifier attribute names the protected firmware package. Two approaches to naming firmware packages are supported: legacy and preferred. The firmware package signer MUST include a firmware-package-identifier attribute using one of these name forms.
firmware-package-identifier属性は、保護されたファームウェアパッケージを指定します。ファームウェアパッケージの命名には、レガシーと優先の2つのアプローチがサポートされています。ファームウェアパッケージの署名者は、これらの名前形式のいずれかを使用して、ファームウェアパッケージ識別子の属性を含める必要があります。
A legacy firmware package name is an octet string, and no structure within the octet string is assumed.
従来のファームウェアパッケージ名はオクテット文字列であり、オクテット文字列内の構造は想定されていません。
A preferred firmware package name is a combination of an object identifier and a version number. The object identifier names a collection of functions implemented by the firmware package, and the version number is a non-negative integer that identifies a particular build or release of the firmware package.
推奨されるファームウェアパッケージ名は、オブジェクト識別子とバージョン番号の組み合わせです。オブジェクトIDは、ファームウェアパッケージによって実装される機能のコレクションを示し、バージョン番号は、ファームウェアパッケージの特定のビルドまたはリリースを識別する負でない整数です。
If a firmware package with a disastrous flaw is released, the firmware package that repairs the previously distributed flaw MAY designate a stale firmware package version to prevent the reloading of the flawed version. The hardware module bootstrap loader SHOULD prevent subsequent rollback to the stale version or versions earlier than the stale version. When the legacy firmware package name form is used, the stale version is indicated by a stale legacy firmware package name, which is an octet string. We assume that the firmware package signer and the bootstrap loader can determine whether a given legacy firmware package name represents a version that is more recent than the stale one. When the preferred firmware package name form is used, the stale version is indicated by a stale version number, which is an integer.
悲惨な欠陥のあるファームウェアパッケージがリリースされた場合、以前に配布された欠陥を修復するファームウェアパッケージは、欠陥のあるバージョンのリロードを防ぐために古いファームウェアパッケージバージョンを指定する場合があります。ハードウェアモジュールのブートストラップローダーは、古いバージョンまたは古いバージョンより前のバージョンへの後続のロールバックを防止する必要があります（SHOULD）。レガシーファームウェアパッケージ名の形式が使用されている場合、古いバージョンはオクテット文字列である古いレガシーファームウェアパッケージ名で示されます。ファームウェアパッケージの署名者とブートストラップローダーは、特定のレガシーファームウェアパッケージ名が古いものよりも新しいバージョンを表しているかどうかを判別できると想定しています。優先ファームウェアパッケージ名の形式を使用すると、古いバージョンは古いバージョン番号で示されます。これは整数です。
The following object identifier identifies the firmware-package-identifier attribute:
次のオブジェクト識別子は、ファームウェアパッケージ識別子の属性を識別します。
id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 35 }
The firmware-package-identifier attribute values have ASN.1 type FirmwarePackageIdentifier:
firmware-package-identifier属性値には、ASN.1タイプFirmwarePackageIdentifierがあります。
FirmwarePackageIdentifier ::= SEQUENCE {
name PreferredOrLegacyPackageIdentifier,
stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
PreferredOrLegacyPackageIdentifier ::= CHOICE {
preferred PreferredPackageIdentifier,
legacy OCTET STRING }
PreferredPackageIdentifier ::= SEQUENCE {
fwPkgID OBJECT IDENTIFIER,
verNum INTEGER (0..MAX) }
PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
preferredStaleVerNum INTEGER (0..MAX),
legacyStaleVersion OCTET STRING }
The target-hardware-module-identifiers attribute names the types of hardware modules that the firmware package supports. A unique object identifier names each supported hardware model type and revision.
target-hardware-module-identifiers属性は、ファームウェアパッケージがサポートするハードウェアモジュールのタイプを指定します。一意のオブジェクト識別子は、サポートされている各ハードウェアモデルのタイプとリビジョンを示します。
The bootstrap loader MUST reject the firmware package if its own hardware module type identifier is not listed in the target-hardware-module-identifiers attribute.
独自のハードウェアモジュールタイプ識別子がtarget-hardware-module-identifiers属性にリストされていない場合、ブートストラップローダーはファームウェアパッケージを拒否する必要があります。
The following object identifier identifies the target-hardware-module-identifiers attribute:
次のオブジェクト識別子は、target-hardware-module-identifiers属性を識別します。
id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 36 }
The target-hardware-module-identifiers attribute values have ASN.1 type TargetHardwareIdentifiers:
target-hardware-module-identifiers属性値には、ASN.1タイプのTargetHardwareIdentifiersがあります。
TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
The decrypt-key-identifier attribute names the symmetric key needed to decrypt the encapsulated firmware package. The CMS EncryptedData content type is used when the firmware package is encrypted. The decrypt-key-identifier signed attribute is carried in the SignedData content type that encapsulates EncryptedData content type, naming the symmetric key needed to decrypt the firmware package. No particular structure is imposed on the key identifier. The means by which the firmware-decryption key is securely distributed to all modules that are authorized to use the associated firmware package is beyond the scope of this specification; however, an optional mechanism for securely distributing the firmware-decryption key with the firmware package is specified in Section 2.3.1.
decode-key-identifier属性は、カプセル化されたファームウェアパッケージを復号化するために必要な対称鍵を指定します。 CMS EncryptedDataコンテンツタイプは、ファームウェアパッケージが暗号化されるときに使用されます。復号化キー識別子の署名された属性は、EncryptedDataコンテンツタイプをカプセル化するSignedDataコンテンツタイプで運ばれ、ファームウェアパッケージの復号化に必要な対称キーに名前を付けます。キー識別子には特定の構造は課されません。ファームウェア復号化キーを、関連するファームウェアパッケージの使用が許可されているすべてのモジュールに安全に配布する方法は、この仕様の範囲外です。ただし、ファームウェア復号化キーをファームウェアパッケージとともに安全に配布するためのオプションのメカニズムは、セクション2.3.1で指定されています。
The following object identifier identifies the decrypt-key-identifier attribute:
次のオブジェクト識別子は、decrypt-key-identifier属性を識別します。
id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 37 }
The decrypt-key-identifier attribute values have ASN.1 type DecryptKeyIdentifier:
復号化キー識別子の属性値には、ASN.1タイプのDecryptKeyIdentifierがあります。
DecryptKeyIdentifier ::= OCTET STRING
The implemented-crypto-algorithms attribute MAY be present in the SignedAttributes, and it names the cryptographic algorithms that are implemented by the firmware package and available to applications. Only those algorithms that are made available at the interface of the cryptographic module are listed. Any cryptographic algorithm that is used internally and is not accessible via the cryptographic module interface MUST NOT be listed. For example, if the firmware package implements the decryption algorithm for future firmware package installations and this algorithm is not made available for other uses, then the firmware-decryption algorithm would not be listed.
implementation-crypto-algorithms属性はSignedAttributesに存在する場合があり、ファームウェアパッケージによって実装され、アプリケーションで利用可能な暗号アルゴリズムを指定します。暗号化モジュールのインターフェースで利用可能になるアルゴリズムのみがリストされています。内部で使用され、暗号化モジュールインターフェイスからアクセスできない暗号化アルゴリズムは、リストに記載してはなりません。たとえば、ファームウェアパッケージが将来のファームウェアパッケージのインストールのための復号化アルゴリズムを実装し、このアルゴリズムが他の用途で利用可能にならない場合、ファームウェア復号化アルゴリズムはリストされません。
The object identifier portion of AlgorithmIdentifier identifies an algorithm and its mode of use. No algorithm parameters are included. Cryptographic algorithms include traffic-encryption algorithms, key-encryption algorithms, key transport algorithms, key agreement algorithms, one-way hash algorithms, and digital signature algorithms. Cryptographic algorithms do not include compression algorithms.
AlgorithmIdentifierのオブジェクト識別子部分は、アルゴリズムとその使用モードを識別します。アルゴリズムパラメータは含まれていません。暗号化アルゴリズムには、トラフィック暗号化アルゴリズム、キー暗号化アルゴリズム、キー転送アルゴリズム、キー合意アルゴリズム、一方向ハッシュアルゴリズム、およびデジタル署名アルゴリズムが含まれます。暗号化アルゴリズムには、圧縮アルゴリズムは含まれていません。
The following object identifier identifies the implemented-crypto-algorithms attribute:
次のオブジェクト識別子は、implemented-crypto-algorithms属性を識別します。
id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 38 }
The implemented-crypto-algorithms attribute values have ASN.1 type ImplementedCryptoAlgorithms:
実装された暗号アルゴリズムの属性値には、ASN.1タイプのImplementedCryptoAlgorithmsがあります。
ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
The implemented-compress-algorithms attribute MAY be present in the SignedAttributes, and it names the compression algorithms that are implemented by the firmware package and available to applications. Only those algorithms that are made available at the interface of the hardware module are listed. Any compression algorithm that is used internally and is not accessible via the hardware module interface MUST NOT be listed. For example, if the firmware package implements a decompression algorithm for future firmware package installations and this algorithm is not made available for other uses, then the firmware-decompression algorithm would not be listed.
implementation-compress-algorithms属性はSignedAttributesに存在する場合があり、ファームウェアパッケージによって実装され、アプリケーションで利用可能な圧縮アルゴリズムを指定します。ハードウェアモジュールのインターフェイスで使用できるようになっているアルゴリズムのみがリストされます。内部で使用され、ハードウェアモジュールインターフェイスからアクセスできない圧縮アルゴリズムは、リストに含めてはなりません。たとえば、ファームウェアパッケージが将来のファームウェアパッケージのインストール用に解凍アルゴリズムを実装し、このアルゴリズムが他の用途で利用できない場合、ファームウェア解凍アルゴリズムはリストされません。
The object identifier portion of AlgorithmIdentifier identifies a compression algorithm. No algorithm parameters are included.
AlgorithmIdentifierのオブジェクト識別子部分は、圧縮アルゴリズムを識別します。アルゴリズムパラメータは含まれていません。
The following object identifier identifies the implemented-compress-algorithms attribute:
次のオブジェクト識別子は、implemented-compress-algorithms属性を識別します。
id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 43 }
The implemented-compress-algorithms attribute values have ASN.1 type ImplementedCompressAlgorithms:
implements-compress-algorithms属性値には、ASN.1タイプのImplementedCompressAlgorithmsがあります。
ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
If present in the SignedAttributes, the community-identifiers attribute names the communities that are permitted to execute the firmware package. The bootstrap loader MUST reject the firmware package if the hardware module is not a member of one of the identified communities. The means of assigning community membership is beyond the scope of this specification.
SignedAttributesに存在する場合、community-identifiers属性は、ファームウェアパッケージの実行を許可されるコミュニティを指定します。ハードウェアモジュールが識別されたコミュニティの1つのメンバーでない場合、ブートストラップローダーはファームウェアパッケージを拒否する必要があります。コミュニティメンバーシップを割り当てる方法は、この仕様の範囲を超えています。
The community-identifiers attributes names the authorized communities by a list of community object identifiers, by a list of specific hardware modules, or by a combination of the two lists. A specific hardware module is specified by the combination of the hardware module identifier (as defined in Section 2.2.4) and a serial number. To facilitate compact representation of serial numbers, a contiguous block can be specified by the lowest authorized serial number and the highest authorized serial number. Alternatively, all of the serial numbers associated with a hardware module family identifier can be specified with the NULL value.
community-identifiers属性は、コミュニティオブジェクト識別子のリスト、特定のハードウェアモジュールのリスト、または2つのリストの組み合わせによって、許可されたコミュニティに名前を付けます。特定のハードウェアモジュールは、ハードウェアモジュール識別子（セクション2.2.4で定義）とシリアル番号の組み合わせによって指定されます。シリアル番号のコンパクトな表現を容易にするために、連続するブロックを、最小の承認済みシリアル番号と最大の承認済みシリアル番号で指定できます。または、ハードウェアモジュールファミリ識別子に関連付けられているすべてのシリアル番号をNULL値で指定できます。
If the bootstrap loader does not have a mechanism for obtaining a list of object identifiers that identify the communities to which the hardware module is a member, then the bootstrap loader MUST behave as though the list is empty. Similarly, if the bootstrap loader does not have access to the hardware module serial number, then the bootstrap loader MUST behave as though the hardware module is not included on the list of authorized hardware modules.
ブートストラップローダーに、ハードウェアモジュールがメンバーとなっているコミュニティを識別するオブジェクト識別子のリストを取得するメカニズムがない場合、ブートストラップローダーは、リストが空であるかのように動作する必要があります。同様に、ブートストラップローダーがハードウェアモジュールのシリアル番号にアクセスできない場合、ブートストラップローダーは、ハードウェアモジュールが承認済みハードウェアモジュールのリストに含まれていないかのように動作する必要があります。
The following object identifier identifies the community-identifiers attribute:
次のオブジェクト識別子は、community-identifiers属性を識別します。
id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 40 }
The community-identifiers attribute values have ASN.1 type CommunityIdentifiers:
community-identifiers属性値には、ASN.1タイプのCommunityIdentifiersがあります。
CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
CommunityIdentifier ::= CHOICE {
communityOID OBJECT IDENTIFIER,
hwModuleList HardwareModules }
HardwareModules ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialEntries SEQUENCE OF HardwareSerialEntry }
HardwareSerialEntry ::= CHOICE {
all NULL,
single OCTET STRING,
block SEQUENCE {
low OCTET STRING,
high OCTET STRING } }
If a hardware module supports more than one type of firmware package, then the firmware package signer SHOULD include the firmware-package-info attribute with a populated fwPkgType field to identify the firmware package type. This value can aid the bootstrap loader in the correct placement of the firmware package within the hardware module. The firmware package type is an INTEGER, and the meaning of the integer value is specific to each hardware module. For example, a hardware module could assign different integer values for a bootstrap loader, a separation kernel, and an application.
ハードウェアモジュールが複数のタイプのファームウェアパッケージをサポートしている場合、ファームウェアパッケージの署名者は、ファームウェアパッケージタイプを識別するためにfwPkgTypeフィールドに値が入力されたfirmware-package-info属性を含める必要があります（SHOULD）。この値は、ブートストラップローダーがハードウェアモジュール内のファームウェアパッケージを正しく配置するのに役立ちます。ファームウェアパッケージタイプはINTEGERであり、整数値の意味は各ハードウェアモジュールに固有です。たとえば、ハードウェアモジュールは、ブートストラップローダー、分離カーネル、およびアプリケーションに異なる整数値を割り当てることができます。
Some hardware module architectures permit one firmware package to use routines provided by another. If the firmware package contains a dependency on another, then the firmware package signer SHOULD also include the firmware-package-info attribute with a populated dependencies field. If the firmware package does not depend on any other firmware packages, then the firmware package signer MUST NOT include the firmware-package-info attribute with a populated dependencies field.
一部のハードウェアモジュールアーキテクチャでは、1つのファームウェアパッケージで別のファームウェアパッケージが使用できるルーチンを使用できます。ファームウェアパッケージに別の依存関係が含まれている場合、ファームウェアパッケージ署名者は、入力された依存関係フィールドを持つfirmware-package-info属性も含める必要があります（SHOULD）。ファームウェアパッケージが他のファームウェアパッケージに依存していない場合、ファームウェアパッケージの署名者は、入力された依存関係フィールドを持つfirmware-package-info属性を含めてはなりません（MUST NOT）。
Firmware package dependencies are identified by the firmware package identifier or by information contained in the firmware package itself, and in either case the bootstrap loader ensures that the dependencies are met. The bootstrap loader MUST reject a firmware package load if it identifies a dependency on a firmware package that is not already loaded. Also, the bootstrap loader MUST reject a firmware package load if the action will result in a configuration where the dependencies of an already loaded firmware package will no longer be satisfied. As described in Section 2.2.3, two approaches to naming firmware packages are supported: legacy and preferred. When the legacy firmware package name form is used, the dependency is indicated by a legacy firmware package name. We assume that the firmware package signer and the bootstrap loader can determine whether a given legacy firmware package name represents the named version of an acceptable newer version. When the preferred firmware package name form is used, an object identifier and an integer are provided. The object identifier MUST exactly match the object identifier portion of a preferred firmware package name associated with a firmware package that is already loaded, and the integer MUST be less than or equal to the integer portion of the preferred firmware package name associated with the same firmware package. That is, the dependency specifies the minimum value of the version that is acceptable.
ファームウェアパッケージの依存関係は、ファームウェアパッケージ識別子またはファームウェアパッケージ自体に含まれる情報によって識別されます。どちらの場合も、ブートストラップローダーは依存関係が確実に満たされるようにします。ブートストラップローダーは、まだロードされていないファームウェアパッケージへの依存関係を識別する場合、ファームウェアパッケージのロードを拒否する必要があります。また、ブートストラップローダーは、アクションが既にロードされたファームウェアパッケージの依存関係が満たされない構成になる場合、ファームウェアパッケージのロードを拒否する必要があります。セクション2.2.3で説明されているように、ファームウェアパッケージの命名には、レガシーと優先の2つのアプローチがサポートされています。レガシーファームウェアパッケージ名の形式が使用されている場合、依存関係はレガシーファームウェアパッケージ名で示されます。ファームウェアパッケージの署名者とブートストラップローダーは、特定のレガシーファームウェアパッケージ名が、受け入れ可能な新しいバージョンの名前付きバージョンを表すかどうかを判断できると想定しています。優先ファームウェアパッケージ名の形式を使用すると、オブジェクト識別子と整数が提供されます。オブジェクト識別子は、すでにロードされているファームウェアパッケージに関連付けられている優先ファームウェアパッケージ名のオブジェクト識別子部分と正確に一致する必要があり、整数は、同じファームウェアに関連付けられている優先ファームウェアパッケージ名の整数部分以下である必要がありますパッケージ。つまり、依存関係は、許容されるバージョンの最小値を指定します。
The following object identifier identifies the firmware-package-info attribute:
次のオブジェクト識別子は、ファームウェアパッケージ情報属性を識別します。
id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 42 }
The firmware-package-info attribute values have ASN.1 type FirmwarePackageInfo:
firmware-package-info属性値には、ASN.1タイプFirmwarePackageInfoがあります。
FirmwarePackageInfo ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
dependencies SEQUENCE OF
PreferredOrLegacyPackageIdentifier OPTIONAL }
The firmware package signer SHOULD include a firmware-package-message-digest attribute, which provides the message digest algorithm and the message digest value computed on the firmware package. The message digest is computed on the firmware package prior to any compression, encryption, or signature processing. The bootstrap loader MAY use this message digest to confirm that the intended firmware package has been recovered after all of the layers of encapsulation are removed.
ファームウェアパッケージの署名者は、ファームウェアパッケージで計算されたメッセージダイジェストアルゴリズムとメッセージダイジェスト値を提供するfirmware-package-message-digest属性を含める必要があります（SHOULD）。メッセージダイジェストは、圧縮、暗号化、または署名処理の前にファームウェアパッケージで計算されます。ブートストラップローダーは、このメッセージダイジェストを使用して、カプセル化のすべての層が削除された後、目的のファームウェアパッケージが復元されたことを確認できます。
The following object identifier identifies the firmware-package-message-digest attribute:
次のオブジェクト識別子は、ファームウェアパッケージメッセージダイジェスト属性を識別します。
id-aa-fwPkgMessageDigest OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 41 }
The firmware-package-message-digest attribute values have ASN.1 type FirmwarePackageMessageDigest:
firmware-package-message-digest属性値には、ASN.1タイプFirmwarePackageMessageDigestがあります。
FirmwarePackageMessageDigest ::= SEQUENCE {
algorithm AlgorithmIdentifier,
msgDigest OCTET STRING }
The firmware package signer SHOULD include a signing-time attribute, specifying the time at which the signature was applied to the firmware package. Section 11.3 of [CMS] defines the signing-time attribute.
ファームウェアパッケージの署名者は、署名がファームウェアパッケージに適用された時刻を指定する、signing-time属性を含める必要があります（SHOULD）。 [CMS]のセクション11.3は、署名時間属性を定義しています。
The firmware package signer SHOULD include a content-hints attribute, including a brief text description of the firmware package. The text is encoded in UTF-8, which supports most of the world's writing systems [UTF-8]. Section 2.9 of [ESS] defines the content-hints attribute.
ファームウェアパッケージの署名者は、ファームウェアパッケージの簡単な説明を含むcontent-hints属性を含める必要があります（SHOULD）。テキストはUTF-8でエンコードされており、世界のほとんどの書記体系[UTF-8]をサポートしています。 [ESS]のセクション2.9はcontent-hints属性を定義しています。
When multiple layers of encapsulation are employed, the content-hints attribute is included in the outermost SignedData to provide information about the innermost content. In this case, the content-hints attribute provides a brief text description of the firmware package, which can help a person select the correct firmware package when more than one is available.
カプセル化の複数の層が採用されている場合、最も内側のコンテンツに関する情報を提供するために、content-hints属性が最も外側のSignedDataに含まれています。この場合、content-hints属性は、ファームウェアパッケージの簡単なテキスト説明を提供します。これは、複数のパッケージが利用可能な場合に、正しいファームウェアパッケージを選択するのに役立ちます。
When the preferred firmware package name forms are used, the content-hints attribute can provide a linkage to a legacy firmware package name. This is especially helpful when an existing configuration management system is in use, but the features associated with the preferred firmware package name are deemed useful. A firmware package name associated with such a configuration management system might look something like "R1234.C0(AJ11).D62.A02.11(b)." Including these firmware package names in the text description may be helpful to developers by providing a clear linkage between the two name forms.
優先ファームウェアパッケージ名の形式が使用される場合、content-hints属性は、レガシーファームウェアパッケージ名へのリンクを提供できます。これは、既存の構成管理システムが使用されている場合に特に役立ちますが、優先ファームウェアパッケージ名に関連付けられている機能が役立つと見なされます。このような構成管理システムに関連付けられたファームウェアパッケージ名は、「R1234.C0（AJ11）.D62.A02.11（b）」のようになります。これらのファームウェアパッケージ名をテキストの説明に含めると、2つの名前形式を明確にリンクできるため、開発者にとって役立つ場合があります。
The content-hints attribute contains two fields, and in this case, both fields MUST be present. The fields of ContentHints are used as follows:
content-hints属性には2つのフィールドが含まれ、この場合、両方のフィールドが存在する必要があります。 ContentHintsのフィールドは次のように使用されます。
contentDescription provides a brief text description of the firmware package.
contentDescriptionは、ファームウェアパッケージの簡単なテキストの説明を提供します。
contentType provides the content type of the inner most content type, and in this case, it MUST be id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16).
contentTypeは、最も内側のコンテンツタイプのコンテンツタイプを提供します。この場合、id-ct-firmwarePackage（1.2.840.113549.1.9.16.1.16）でなければなりません。
When the firmware-signer's public key is contained in a certificate, the firmware package signer SHOULD include a signing-certificate attribute to identify the certificate that was employed. However, if the firmware package signature does not have a certificate (meaning that the signature will only be validated with the trust anchor public key), then the firmware package signer is unable to include a signing-certificate attribute. Section 5.4 of [ESS] defines this attribute.
ファームウェア署名者の公開鍵が証明書に含まれている場合、ファームウェアパッケージ署名者は、使用された証明書を識別するための署名証明書属性を含める必要があります（SHOULD）。ただし、ファームウェアパッケージの署名に証明書がない場合（つまり、署名はトラストアンカーの公開鍵でのみ検証される）、ファームウェアパッケージの署名者は、signing-certificate属性を含めることができません。 [ESS]のセクション5.4はこの属性を定義しています。
The signing-certificate attribute contains two fields: certs and policies. The certs field MUST be present, and the policies field MAY be present. The fields of SigningCertificate are used as follows:
signing-certificate属性には、証明書とポリシーの2つのフィールドが含まれています。証明書フィールドが存在しなければならず（MUST）、ポリシーフィールドが存在してもよい（MAY）。 SigningCertificateのフィールドは次のように使用されます。
certs contains a sequence of certificate identifiers. In this case, sequence of certificate identifiers contains a single entry. The certs field MUST contain only the certificate identifier of the certificate that contains the public key used to verify the firmware package signature. The certs field uses the ESSCertID syntax specified in Section 5.4 of [ESS], and it is comprised of the SHA-1 hash [SHA1] of the entire ASN.1 DER encoded certificate and, optionally, the certificate issuer and the certificate serial number. The SHA-1 hash value MUST be present. The certificate issuer and the certificate serial number SHOULD be present.
certsには、一連の証明書識別子が含まれています。この場合、証明書識別子のシーケンスには1つのエントリが含まれます。 certsフィールドには、ファームウェアパッケージの署名を検証するために使用される公開鍵を含む証明書の証明書識別子のみを含める必要があります。 certsフィールドは、[ESS]のセクション5.4で指定されたESSCertID構文を使用し、ASN.1 DERエンコードされた証明書全体のSHA-1ハッシュ[SHA1]と、オプションで証明書発行者と証明書シリアル番号で構成されます。 SHA-1ハッシュ値が存在する必要があります。証明書の発行者と証明書のシリアル番号が存在する必要があります。
policies is optional; when it is present, it contains a sequence of policy information. The policies field, when present, MUST contain only one entry, and that entry MUST match one of the certificate policies in the certificate policies extension of the certificate that contains the public key used to verify the firmware package signature. The policies field uses the PolicyInformation syntax specified in Section 4.2.1.5 of [PROFILE], and it is comprised of the certificate policy object identifier and, optionally, certificate policy qualifiers. The certificate policy object identifier MUST be present. The certificate policy qualifiers SHOULD NOT be present.
ポリシーはオプションです。存在する場合は、一連のポリシー情報が含まれます。ポリシーフィールドは、存在する場合、1つのエントリのみを含む必要があり、そのエントリは、ファームウェアパッケージの署名の検証に使用される公開鍵を含む証明書の証明書ポリシー拡張の証明書ポリシーの1つと一致する必要があります。ポリシーフィールドは、[PROFILE]のセクション4.2.1.5で指定されたPolicyInformation構文を使用し、証明書ポリシーオブジェクト識別子と、オプションで証明書ポリシー修飾子で構成されます。証明書ポリシーオブジェクト識別子が存在する必要があります。証明書ポリシー修飾子は存在すべきではありません。
CMS allows a SET of unsigned attributes to be included; however, in this specification, the set MUST be absent or include a single instance of the wrapped-firmware-decryption-key attribute. Because the digital signature does not cover this attribute, it can be altered at any point in the delivery path from the firmware package signer to the hardware module. This property can be employed to distribute the firmware-decryption key along with an encrypted and signed firmware package, allowing the firmware-decryption key to be wrapped with a different key-encryption key for each link in the distribution chain.
CMSでは、署名されていない属性のセットを含めることができます。ただし、この仕様では、セットは存在しないか、wrapped-firmware-decryption-key属性の単一のインスタンスを含む必要があります。デジタル署名はこの属性に対応していないため、ファームウェアパッケージの署名者からハードウェアモジュールへの配信パスのどの時点でも変更できます。このプロパティを使用して、暗号化および署名されたファームウェアパッケージと共にファームウェア復号化キーを配布できます。これにより、ファームウェア復号化キーを、配布チェーンの各リンクの異なるキー暗号化キーでラップできます。
The syntax for attributes is defined in [CMS], and it is repeated at the beginning of Section 2.2 of this document for convenience. Each of the attributes used with this profile has a single attribute value, even though the syntax is defined as a SET OF AttributeValue. There MUST be exactly one instance of AttributeValue present.
属性の構文は[CMS]で定義されており、便宜上、このドキュメントのセクション2.2の冒頭で繰り返されています。構文がSET OF AttributeValueとして定義されている場合でも、このプロファイルで使用される各属性には単一の属性値があります。 AttributeValueのインスタンスが1つだけ存在している必要があります。
The UnsignedAttributes syntax within signerInfo is defined as a SET OF Attribute. The UnsignedAttributes MUST include only one instance of any particular attribute.
signerInfo内のUnsignedAttributes構文は、SET OF Attributeとして定義されています。 UnsignedAttributesには、特定の属性のインスタンスを1つだけ含める必要があります。
The firmware package signer, or any other party in the distribution chain, MAY include a wrapped-firmware-decryption-key attribute.
ファームウェアパッケージの署名者、または配布チェーンの他のパーティには、wrapped-firmware-decryption-key属性を含めることができます（MAY）。
The following object identifier identifies the wrapped-firmware-decryption-key attribute:
次のオブジェクト識別子は、wrapped-firmware-decryption-key属性を識別します。
id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 39 }
The wrapped-firmware-decryption-key attribute values have ASN.1 type of EnvelopedData. Section 6 of [CMS] defines the EnvelopedData content type, which is used to construct the value of the attribute. EnvelopedData permits the firmware-decryption key to be protected using symmetric or asymmetric techniques. The EnvelopedData does not include an encrypted content; rather, the EnvelopedData feature of having the encrypted content in another location is employed. The encrypted content is found in the eContent field of the EncryptedData structure. The firmware-decryption key is contained in the recipientInfos field. Section 6 of [CMS] refers to this key as the content-encryption key.
wrapped-firmware-decryption-key属性値には、EnvelopedDataのASN.1タイプがあります。 [CMS]のセクション6は、EnvelopedDataコンテンツタイプを定義します。これは、属性の値を構築するために使用されます。 EnvelopedDataでは、ファームウェア復号鍵を対称または非対称の手法を使用して保護できます。 EnvelopedDataには暗号化されたコンテンツは含まれません。むしろ、暗号化されたコンテンツを別の場所に置くEnvelopedData機能が採用されています。暗号化されたコンテンツは、EncryptedData構造のeContentフィールドにあります。ファームウェア復号化キーは、recipientInfosフィールドに含まれています。 [CMS]のセクション6では、このキーをコンテンツ暗号化キーと呼びます。
The EnvelopedData syntax supports many different key management algorithms. Four general techniques are supported: key transport, key agreement, symmetric key-encryption keys, and passwords.
EnvelopedData構文は、さまざまなキー管理アルゴリズムをサポートしています。鍵の転送、鍵の合意、対称鍵暗号鍵、およびパスワードの4つの一般的な手法がサポートされています。
The EnvelopedData content type is profiled for the wrapped-firmware-decryption-key attribute. The EnvelopedData fields are described fully in Section 6 of [CMS]. Additional rules apply when EnvelopedData is used as a wrapped-firmware-decryption-key attribute.
EnvelopedDataコンテンツタイプは、wrapped-firmware-decryption-key属性に対してプロファイルされます。 EnvelopedDataフィールドについては、[CMS]のセクション6で詳しく説明しています。 EnvelopedDataがwrapped-firmware-decryption-key属性として使用される場合、追加のルールが適用されます。
Within the EnvelopedData structure, the following apply:
EnvelopedData構造内では、以下が適用されます。
- The set of certificates included in OriginatorInfo MUST NOT include certificates with a type of extendedCertificate, v1AttrCert, or v2AttrCert [X.509-97, X.509-00, ACPROFILE]. The optional crls field MAY be present.
- OriginatorInfoに含まれる証明書のセットには、extendedCertificate、v1AttrCert、またはv2AttrCert [X.509-97、X.509-00、ACPROFILE]のタイプの証明書を含めてはなりません（MUST NOT）。オプションのcrlsフィールドが存在してもかまいません。
- The optional unprotectedAttrs field MUST NOT be present.
- オプションのunprotectedAttrsフィールドは存在してはなりません（MUST NOT）。
Within the EncryptedContentInfo structure, the following apply:
EncryptedContentInfo構造内では、以下が適用されます。
- contentType MUST match the content type object identifier carried in the contentType field within the EncryptedContentInfo structure of EncryptedData as described in Section 2.1.3.1.
- contentTypeは、セクション2.1.3.1で説明されているように、EncryptedDataのEncryptedContentInfo構造内のcontentTypeフィールドに含まれるコンテンツタイプオブジェクト識別子と一致する必要があります。
- contentEncryptionAlgorithm identifies the firmware-encryption algorithm, and any associated parameters, used to encrypt the firmware package carried in the encryptedContent field of the EncryptedContentInfo structure of EncryptedData. Therefore, it MUST exactly match the value of the EncryptedContentInfo structure of EncryptedData as described in Section 2.1.3.1.
- contentEncryptionAlgorithmは、ファームウェア暗号化アルゴリズムと、EncryptedDataのEncryptedContentInfo構造体のencryptedContentフィールドに含まれるファームウェアパッケージを暗号化するために使用される関連パラメータを識別します。したがって、セクション2.1.3.1で説明されているように、EncryptedDataのEncryptedContentInfo構造の値と正確に一致する必要があります。
- encryptedContent is optional, and in this case, it MUST NOT be present.
- encryptedContentはオプションであり、この場合は存在させてはなりません。
The Cryptographic Message Syntax (CMS) is used to indicate that a firmware package loaded successfully. Support for firmware package load receipts is OPTIONAL. However, those hardware modules that choose to generate such receipts MUST follow the conventions specified in this section. Because not all hardware modules will have private signature keys, the firmware package load receipt can be either signed or unsigned. Use of the signed firmware package load receipt is RECOMMENDED.
暗号化メッセージ構文（CMS）は、ファームウェアパッケージが正常にロードされたことを示すために使用されます。ファームウェアパッケージロードレシートのサポートはオプションです。ただし、そのような領収書を生成することを選択したハードウェアモジュールは、このセクションで指定された規則に従う必要があります。すべてのハードウェアモジュールに秘密の署名キーがあるとは限らないため、ファームウェアパッケージのロードレシートは署名されている場合と署名されていない場合があります。署名されたファームウェアパッケージロードレシートの使用をお勧めします。
Hardware modules that support receipt generation MUST have a unique serial number. Hardware modules that support signed receipt generation MUST have a private signature key to sign the receipt and the corresponding signature validation certificate or its designator. The designator is the certificate issuer name and the certificate serial number, or it is the public key identifier. Memory-constrained hardware modules will generally store the public key identifier since it requires less storage.
レシートの生成をサポートするハードウェアモジュールには、一意のシリアル番号が必要です。署名済みレシートの生成をサポートするハードウェアモジュールには、レシートに署名するための秘密署名キーと、対応する署名検証証明書またはその指定子が必要です。指定子は、証明書の発行者名と証明書のシリアル番号、または公開鍵の識別子です。メモリに制約のあるハードウェアモジュールは、必要なストレージが少ないため、一般に公開キー識別子を格納します。
The unsigned firmware package load receipt is encapsulated by ContentInfo. Alternatively, the signed firmware package load receipt is encapsulated by SignedData, which is in turn encapsulated by ContentInfo.
署名されていないファームウェアパッケージのロードレシートは、ContentInfoによってカプセル化されます。または、署名されたファームウェアパッケージロードレシートは、SignedDataによってカプセル化されます。SignedDataは、ContentInfoによってカプセル化されます。
The firmware package load receipt is summarized as follows (see [CMS] for the full syntax):
ファームウェアパッケージのロードレシートは、次のように要約されます（完全な構文については、[CMS]を参照してください）。
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
-- OR --
id-ct-firmwareLoadReceipt,
-- (1.2.840.113549.1.9.16.1.17)
content SignedData
-- OR --
FirmwarePackageLoadReceipt
}
SignedData {
version CMSVersion, -- always set to 3
digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Optional Module certificate
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one
}
SignerInfo {
version CMSVersion, -- either set to 1 or 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Omit
}
EncapsulatedContentInfo {
eContentType id-ct-firmwareLoadReceipt,
-- (1.2.840.113549.1.9.16.1.17)
eContent OCTET STRING -- Contains receipt
}
FirmwarePackageLoadReceipt {
version INTEGER, -- The DEFAULT is always used
hwType OBJECT IDENTIFIER, -- Hardware module type
hwSerialNum OCTET STRING, -- H/W module serial number
fwPkgName PreferredOrLegacyPackageIdentifier,
trustAnchorKeyID OCTET STRING, -- Optional
decryptKeyID OCTET STRING -- Optional
}
This section specifies the conventions for using the CMS ContentInfo and SignedData content types for firmware package load receipts. It also defines the firmware package load receipt content type.
このセクションでは、ファームウェアパッケージのロードの受信にCMS ContentInfoおよびSignedDataコンテンツタイプを使用するための規則を指定します。また、ファームウェアパッケージロードレシートのコンテンツタイプも定義します。
The CMS requires that the outermost encapsulation be ContentInfo [CMS]. The fields of ContentInfo are used as follows:
CMSでは、最も外側のカプセル化がContentInfo [CMS]である必要があります。 ContentInfoのフィールドは次のように使用されます。
contentType indicates the type of the associated content. If the firmware package load receipt is signed, then the encapsulated type MUST be SignedData, and the id-signedData (1.2.840.113549.1.7.2) object identifier MUST be present in this field. If the receipt is not signed, then the encapsulated type MUST be FirmwarePackageLoadReceipt, and the id-ct-firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17) object identifier MUST be present in this field.
contentTypeは、関連付けられたコンテンツのタイプを示します。ファームウェアパッケージロードレシートが署名されている場合、カプセル化されたタイプはSignedDataである必要があり、id-signedData（1.2.840.113549.1.7.2）オブジェクト識別子がこのフィールドに存在する必要があります。領収書が署名されていない場合、カプセル化されたタイプはFirmwarePackageLoadReceiptでなければならず、id-ct-firmwareLoadReceipt（1.2.840.113549.1.9.16.1.17）オブジェクト識別子がこのフィールドに存在する必要があります。
content holds the associated content. If the firmware package load receipt is signed, then this field MUST contain the SignedData. If the receipt is not signed, then this field MUST contain the FirmwarePackageLoadReceipt.
contentは関連するコンテンツを保持します。ファームウェアパッケージロードレシートが署名されている場合、このフィールドにはSignedDataが含まれている必要があります。領収書が署名されていない場合、このフィールドにはFirmwarePackageLoadReceiptが含まれている必要があります。
The SignedData content type contains the firmware package load receipt and one digital signature. If the hardware module locally stores its certificate, then the certificate can be included as well. The fields of SignedData are used as follows:
SignedDataコンテンツタイプには、ファームウェアパッケージのロードレシートと1つのデジタル署名が含まれています。ハードウェアモジュールがローカルに証明書を格納している場合は、証明書も含めることができます。 SignedDataのフィールドは次のように使用されます。
version is the syntax version number, and in this case, it MUST be set to 3.
versionは構文のバージョン番号で、この場合は3に設定する必要があります。
digestAlgorithms is a collection of message digest algorithm identifiers, and in this case, it MUST contain a single message digest algorithm identifier. The message digest algorithms employed by the hardware module MUST be present.
digestAlgorithmsは、メッセージダイジェストアルゴリズム識別子のコレクションであり、この場合、単一のメッセージダイジェストアルゴリズム識別子を含んでいる必要があります。ハードウェアモジュールで採用されているメッセージダイジェストアルゴリズムが存在する必要があります。
encapContentInfo is the signed content, consisting of a content type identifier and the content itself. The use of the EncapsulatedContentInfo type is discussed further in Section 3.1.2.2.
encapContentInfoは、コンテンツタイプ識別子とコンテンツ自体で構成される署名付きコンテンツです。 EncapsulatedContentInfoタイプの使用については、セクション3.1.2.2で詳しく説明します。
certificates is an optional collection of certificates. If the hardware module locally stores its certificate, then the X.509 certificate of the hardware module SHOULD be included. If the hardware module does not, then the certificates field is omitted. PKCS#6 extended certificates [PKCS#6] and attribute certificates (either version 1 or version 2) [X.509-97, X.509-00, ACPROFILE] MUST NOT be included in the set of certificates.
証明書は、オプションの証明書のコレクションです。ハードウェアモジュールがローカルに証明書を格納する場合、ハードウェアモジュールのX.509証明書を含める必要があります（SHOULD）。ハードウェアモジュールがサポートしていない場合、証明書フィールドは省略されます。 PKCS＃6拡張証明書[PKCS＃6]および属性証明書（バージョン1またはバージョン2）[X.509-97、X.509-00、ACPROFILE]は、証明書のセットに含まれていてはなりません（MUST NOT）。
crls is an optional collection of certificate revocation lists (CRLs). CRLs MAY be included, but they will normally be omitted since hardware modules will not generally have access to the most recent CRL. Signed receipt recipients SHOULD be able to handle the presence of the optional crls field.
crlsは、証明書失効リスト（CRL）のオプションのコレクションです。 CRLを含めることができますが、ハードウェアモジュールは通常、最新のCRLにアクセスできないため、通常は省略されます。署名済みの受信者は、オプションのcrlsフィールドの存在を処理できる必要があります（SHOULD）。
signerInfos is a collection of per-signer information, and in this case, the collection MUST contain exactly one SignerInfo. The use of the SignerInfo type is discussed further in Section 3.1.2.1.
signerInfosは署名者ごとの情報のコレクションであり、この場合、コレクションには1つのSignerInfoが含まれている必要があります。 SignerInfoタイプの使用については、セクション3.1.2.1で詳しく説明します。
The hardware module is represented in the SignerInfo type. The fields of SignerInfo are used as follows:
ハードウェアモジュールは、SignerInfoタイプで表されます。 SignerInfoのフィールドは次のように使用されます。
version is the syntax version number, and it MUST be either 1 or 3, depending on the method used to identify the hardware module's public key. The use of the subjectKeyIdentifier is RECOMMENDED, which results in the use of version 3.
versionは構文のバージョン番号であり、ハードウェアモジュールの公開鍵を識別するために使用される方法に応じて、1または3でなければなりません。 subjectKeyIdentifierの使用は推奨されており、バージョン3が使用されます。
sid specifies the hardware module's certificate (and thereby the hardware module's public key). CMS supports two alternatives: issuerAndSerialNumber and subjectKeyIdentifier. The hardware module MUST support one or both of the alternatives for receipt generation; however, the support of subjectKeyIdentifier is RECOMMENDED. The issuerAndSerialNumber alternative identifies the hardware module's certificate by the issuer's distinguished name and the certificate serial number. The identified certificate, in turn, contains the hardware module's public key. The subjectKeyIdentifier alternative identifies the hardware module's public key directly. When this public key is contained in a certificate, this identifier SHOULD appear in the X.509 subjectKeyIdentifier extension.
sidは、ハードウェアモジュールの証明書（およびハードウェアモジュールの公開鍵）を指定します。 CMSは、issuerAndSerialNumberとsubjectKeyIdentifierの2つの選択肢をサポートしています。ハードウェアモジュールは、レシート生成の代替手段の1つまたは両方をサポートする必要があります。ただし、subjectKeyIdentifierのサポートは推奨されています。 issuerAndSerialNumber代替は、発行者の識別名と証明書のシリアル番号によってハードウェアモジュールの証明書を識別します。識別された証明書には、ハードウェアモジュールの公開鍵が含まれています。 subjectKeyIdentifier代替は、ハードウェアモジュールの公開鍵を直接識別します。この公開鍵が証明書に含まれている場合、この識別子はX.509 subjectKeyIdentifier拡張に現れる必要があります（SHOULD）。
digestAlgorithm identifies the message digest algorithm, and any associated parameters, used by the hardware module. It MUST contain the message digest algorithms employed to sign the receipt. (Note that this message digest algorithm identifier MUST be the same as the one carried in the digestAlgorithms value in SignedData.)
digestAlgorithmは、ハードウェアモジュールによって使用されるメッセージダイジェストアルゴリズムと関連するパラメータを識別します。領収書への署名に使用されるメッセージダイジェストアルゴリズムが含まれている必要があります。 （このメッセージダイジェストアルゴリズムの識別子は、SignedDataのdigestAlgorithms値で運ばれるものと同じでなければならないことに注意してください。）
signedAttrs is an optional collection of attributes that are signed along with the content. The signedAttrs are optional in the CMS, but in this specification, signedAttrs are REQUIRED for use with the firmware package load receipt content. The SET OF attributes MUST be DER encoded [X.509-88]. Section 3.2 of this document lists the attributes that MUST be included in the collection. Other attributes MAY be included, but the recipient will ignore any unrecognized signed attributes.
signedAttrsは、コンテンツとともに署名されるオプションの属性のコレクションです。 signedAttrsはCMSではオプションですが、この仕様では、signedAttrsはファームウェアパッケージロードレシートのコンテンツで使用する必要があります。 SET OF属性は、DERエンコードされている必要があります[X.509-88]。このドキュメントのセクション3.2には、コレクションに含める必要がある属性がリストされています。他の属性を含めることができますが、受信者は、認識されていない署名付き属性を無視します。
signatureAlgorithm identifies the signature algorithm, and any associated parameters, used to sign the receipt.
signatureAlgorithmは、レシートへの署名に使用される署名アルゴリズムおよび関連するパラメーターを識別します。
signature is the digital signature.
signatureはデジタル署名です。
unsignedAttrs is an optional collection of attributes that are not signed, and in this case, there MUST NOT be any unsigned attributes present.
unsignedAttrsは、署名されていない属性のオプションのコレクションです。この場合、署名されていない属性があってはなりません。
The FirmwarePackageLoadReceipt is encapsulated in an OCTET STRING, and it is carried within the EncapsulatedContentInfo type. The fields of EncapsulatedContentInfo are used as follows:
FirmwarePackageLoadReceiptはOCTET STRINGにカプセル化され、EncapsulatedContentInfoタイプ内で伝達されます。 EncapsulatedContentInfoのフィールドは次のように使用されます。
eContentType is an object identifier that uniquely specifies the content type, and in this case, it MUST be the value of id-ct-firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17).
eContentTypeは、コンテンツタイプを一意に指定するオブジェクト識別子であり、この場合、id-ct-firmwareLoadReceipt（1.2.840.113549.1.9.16.1.17）の値である必要があります。
eContent is the firmware package load receipt, encapsulated in an OCTET STRING. The eContent octet string need not be DER encoded.
eContentは、OCTET STRINGにカプセル化されたファームウェアパッケージロードレシートです。 eContentオクテット文字列は、DERエンコードする必要はありません。
The following object identifier identifies the firmware package load receipt content type:
次のオブジェクト識別子は、ファームウェアパッケージロードの受信コンテンツタイプを識別します。
id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 17 }
The firmware package load receipt content type has the ASN.1 type FirmwarePackageLoadReceipt:
ファームウェアパッケージロード受信コンテンツタイプには、ASN.1タイプFirmwarePackageLoadReceiptがあります。
FirmwarePackageLoadReceipt ::= SEQUENCE {
version FWReceiptVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
fwPkgName PreferredOrLegacyPackageIdentifier,
trustAnchorKeyID OCTET STRING OPTIONAL,
decryptKeyID [1] OCTET STRING OPTIONAL }
FWReceiptVersion ::= INTEGER { v1(1) }
The fields of the FirmwarePackageLoadReceipt type have the following meanings:
FirmwarePackageLoadReceiptタイプのフィールドには、次の意味があります。
version is an integer that provides the syntax version number for compatibility with future revisions of this specification. Implementations that conform to this specification MUST set the version to the default value, which is v1.
versionは、この仕様の将来のリビジョンとの互換性のために構文バージョン番号を提供する整数です。この仕様に準拠する実装では、バージョンをデフォルト値（v1）に設定する必要があります。
hwType is an object identifier that identifies the type of hardware module on which the firmware package was loaded.
hwTypeは、ファームウェアパッケージがロードされたハードウェアモジュールのタイプを識別するオブジェクト識別子です。
hwSerialNum is the serial number of the hardware module on which the firmware package was loaded. No particular structure is imposed on the serial number; it need not be an integer. However, the combination of the hwType and hwSerialNum uniquely identifies the hardware module.
hwSerialNumは、ファームウェアパッケージがロードされたハードウェアモジュールのシリアル番号です。シリアル番号には特別な構造はありません。整数である必要はありません。ただし、hwTypeとhwSerialNumの組み合わせは、ハードウェアモジュールを一意に識別します。
fwPkgName identifies the firmware package that was loaded. As described in Section 2.2.3, two approaches to naming firmware packages are supported: legacy and preferred. A legacy firmware package name is an octet string. A preferred firmware package name is a combination of the firmware package object identifier and an integer version number.
fwPkgNameは、ロードされたファームウェアパッケージを識別します。セクション2.2.3で説明されているように、ファームウェアパッケージの命名には、レガシーと優先の2つのアプローチがサポートされています。従来のファームウェアパッケージ名はオクテット文字列です。推奨されるファームウェアパッケージ名は、ファームウェアパッケージオブジェクト識別子と整数バージョン番号の組み合わせです。
trustAnchorKeyID is optional, and when it is present, it identifies the trust anchor that was used to validate the firmware package signature.
trustAnchorKeyIDはオプションであり、存在する場合、ファームウェアパッケージの署名の検証に使用されたトラストアンカーを識別します。
decryptKeyID is optional, and when it is present, it identifies the firmware-decryption key that was used to decrypt the firmware package.
decodeKeyIDはオプションであり、存在する場合は、ファームウェアパッケージの復号化に使用されたファームウェア復号化キーを識別します。
The firmware package load receipt MUST include the version, hwType, hwSerialNum, and fwPkgName fields, and it SHOULD include the trustAnchorKeyID field. The firmware package load receipt MUST NOT include the decryptKeyID, unless the firmware package associated with the receipt is encrypted, the firmware-decryption key is available to the hardware module, and the firmware package was successfully decrypted.
ファームウェアパッケージロードレシートには、バージョン、hwType、hwSerialNum、およびfwPkgNameフィールドを含める必要があり、trustAnchorKeyIDフィールドを含める必要があります（SHOULD）。ファームウェアパッケージロードレシートには、decryptKeyIDを含めてはなりません。ただし、レシートに関連付けられたファームウェアパッケージが暗号化され、ファームウェア復号化キーがハードウェアモジュールで利用可能で、ファームウェアパッケージが正常に復号化された場合を除きます。
The hardware module MUST digitally sign a collection of attributes along with the firmware package load receipt. Each attribute in the collection MUST be DER encoded [X.509-88]. The syntax for attributes is defined in [CMS], and it was repeated in Section 2.2 for convenience.
ハードウェアモジュールは、ファームウェアパッケージロードレシートとともに属性のコレクションにデジタル署名する必要があります。コレクションの各属性は、DERエンコードされている必要があります[X.509-88]。属性の構文は[CMS]で定義されており、2.2節で便宜上繰り返されています。
Each of the attributes used with this profile has a single attribute value, even though the syntax is defined as a SET OF AttributeValue. There MUST be exactly one instance of AttributeValue present.
構文がSET OF AttributeValueとして定義されている場合でも、このプロファイルで使用される各属性には単一の属性値があります。 AttributeValueのインスタンスが1つだけ存在している必要があります。
The SignedAttributes syntax within signerInfo is defined as a SET OF Attributes. The SignedAttributes MUST include only one instance of any particular attribute.
signerInfo内のSignedAttributes構文は、SET OF属性として定義されます。 SignedAttributesには、特定の属性のインスタンスを1つだけ含める必要があります。
The hardware module MUST include the content-type and message-digest attributes. If the hardware module includes a real-time clock, then the hardware module SHOULD also include the signing-time attribute. The hardware module MAY include any other attribute that it deems appropriate.
ハードウェアモジュールには、コンテンツタイプとメッセージダイジェストの属性を含める必要があります。ハードウェアモジュールにリアルタイムクロックが含まれている場合、ハードウェアモジュールには、署名時間属性も含める必要があります（SHOULD）。ハードウェアモジュールには、適切と見なされるその他の属性を含めることができます。
The hardware module MUST include a content-type attribute with the value of id-ct-firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17). Section 11.1 of [CMS] defines the content-type attribute.
ハードウェアモジュールには、id-ct-firmwareLoadReceipt（1.2.840.113549.1.9.16.1.17）の値を持つcontent-type属性を含める必要があります。 [CMS]のセクション11.1はcontent-type属性を定義しています。
The hardware module MUST include a message-digest attribute, having as its value the message digest of the FirmwarePackageLoadReceipt content. Section 11.2 of [CMS] defines the message-digest attribute.
ハードウェアモジュールは、値としてFirmwarePackageLoadReceiptコンテンツのメッセージダイジェストを持つメッセージダイジェスト属性を含める必要があります。 [CMS]のセクション11.2は、メッセージダイジェスト属性を定義しています。
If the hardware module includes a real-time clock, then the hardware module SHOULD include a signing-time attribute, specifying the time at which the receipt was generated. Section 11.3 of [CMS] defines the signing-time attribute.
ハードウェアモジュールにリアルタイムクロックが含まれている場合、ハードウェアモジュールには、レシートが生成された時刻を指定するsigning-time属性を含める必要があります（SHOULD）。 [CMS]のセクション11.3は、署名時間属性を定義しています。
The Cryptographic Message Syntax (CMS) is used to indicate that an error has occurred while attempting to load a protected firmware package. Support for firmware package load error reports is OPTIONAL. However, those hardware modules that choose to generate such error reports MUST follow the conventions specified in this section. Not all hardware modules have private signature keys; therefore the firmware package load error report can be either signed or unsigned. Use of the signed firmware package error report is RECOMMENDED.
暗号化メッセージ構文（CMS）は、保護されたファームウェアパッケージをロードしようとしたときにエラーが発生したことを示すために使用されます。ファームウェアパッケージロードエラーレポートのサポートはオプションです。ただし、このようなエラーレポートを生成することを選択したハードウェアモジュールは、このセクションで指定された規則に従う必要があります。すべてのハードウェアモジュールに秘密の署名キーがあるわけではありません。したがって、ファームウェアパッケージロードエラーレポートは、署名されている場合と、署名されていない場合があります。署名されたファームウェアパッケージエラーレポートの使用をお勧めします。
Hardware modules that support error report generation MUST have a unique serial number. Hardware modules that support signed error report generation MUST also have a private signature key to sign the error report and the corresponding signature validation certificate or its designator. The designator is the certificate issuer name and the certificate serial number, or it is the public key identifier. Memory-constrained hardware modules will generally store the public key identifier since it requires less storage.
エラーレポートの生成をサポートするハードウェアモジュールには、一意のシリアル番号が必要です。署名付きエラーレポートの生成をサポートするハードウェアモジュールには、エラーレポートに署名するための秘密署名キーと、対応する署名検証証明書またはその指定子も必要です。指定子は、証明書の発行者名と証明書のシリアル番号、または公開鍵の識別子です。メモリに制約のあるハードウェアモジュールは、必要なストレージが少ないため、一般に公開キー識別子を格納します。
The unsigned firmware package load error report is encapsulated by ContentInfo. Alternatively, the signed firmware package load error report is encapsulated by SignedData, which is in turn encapsulated by ContentInfo.
署名されていないファームウェアパッケージのロードエラーレポートは、ContentInfoによってカプセル化されます。または、署名されたファームウェアパッケージのロードエラーレポートは、SignedDataによってカプセル化され、ContentInfoによってカプセル化されます。
The firmware package load error report is summarized as follows (see [CMS] for the full syntax):
ファームウェアパッケージのロードエラーレポートは、次のように要約されます（完全な構文については、[CMS]を参照してください）。
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
-- OR --
id-ct-firmwareLoadError,
-- (1.2.840.113549.1.9.16.1.18)
content SignedData
-- OR --
FirmwarePackageLoadError
}
SignedData {
version CMSVersion, -- Always set to 3
digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Optional Module certificate
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one
}
SignerInfo {
version CMSVersion, -- either set to 1 or 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Omit
}
EncapsulatedContentInfo {
eContentType id-ct-firmwareLoadError,
-- (1.2.840.113549.1.9.16.1.18)
eContent OCTET STRING -- Contains error report
}
FirmwarePackageLoadError {
version INTEGER, -- The DEFAULT is always used
hwType OBJECT IDENTIFIER, -- Hardware module type
hwSerialNum OCTET STRING, -- H/W module serial number
errorCode FirmwarePackageLoadErrorCode -- Error identifier
vendorErrorCode VendorErrorCode, -- Optional
fwPkgName PreferredOrLegacyPackageIdentifier, -- Optional
config SEQUENCE OF CurrentFWConfig, -- Optional
}
CurrentFWConfig { -- Repeated for each package in configuration fwPkgType INTEGER, -- Firmware package type; Optional fwPkgName PreferredOrLegacyPackageIdentifier }
CurrentFWConfig {-構成fwPkgType INTEGERの各パッケージに対して繰り返されます、-ファームウェアパッケージタイプ。オプションのfwPkgName PreferredOrLegacyPackageIdentifier}
This section specifies the conventions for using the CMS ContentInfo and SignedData content types for firmware package load error reports. It also defines the firmware package load error content type.
このセクションでは、ファームウェアパッケージロードエラーレポートにCMS ContentInfoおよびSignedDataコンテンツタイプを使用するための規則を指定します。また、ファームウェアパッケージのロードエラーのコンテンツタイプも定義します。
The CMS requires that the outermost encapsulation be ContentInfo [CMS]. The fields of ContentInfo are used as follows:
CMSでは、最も外側のカプセル化がContentInfo [CMS]である必要があります。 ContentInfoのフィールドは次のように使用されます。
contentType indicates the type of the associated content. If the firmware package load error report is signed, then the encapsulated type MUST be SignedData, and the id-signedData (1.2.840.113549.1.7.2) object identifier MUST be present in this field. If the report is not signed, then the encapsulated type MUST be FirmwarePackageLoadError, and the id-ct-firmwareLoadError (1.2.840.113549.1.9.16.1.18) object identifier MUST be present in this field.
contentTypeは、関連付けられたコンテンツのタイプを示します。ファームウェアパッケージロードエラーレポートが署名されている場合、カプセル化されたタイプはSignedDataである必要があり、id-signedData（1.2.840.113549.1.7.2）オブジェクト識別子がこのフィールドに存在する必要があります。レポートが署名されていない場合、カプセル化されたタイプはFirmwarePackageLoadErrorでなければならず、id-ct-firmwareLoadError（1.2.840.113549.1.9.16.1.18）オブジェクト識別子がこのフィールドに存在する必要があります。
content holds the associated content. If the firmware package load error report is signed, then this field MUST contain the SignedData. If the report is not signed, then this field MUST contain the FirmwarePackageLoadError.
contentは関連するコンテンツを保持します。ファームウェアパッケージロードエラーレポートが署名されている場合、このフィールドにはSignedDataが含まれている必要があります。レポートが署名されていない場合、このフィールドにはFirmwarePackageLoadErrorが含まれている必要があります。
The SignedData content type contains the firmware package load error report and one digital signature. If the hardware module locally stores its certificate, then the certificate can be included as well. The fields of SignedData are used exactly as described in Section 3.1.2.
SignedDataコンテンツタイプには、ファームウェアパッケージのロードエラーレポートと1つのデジタル署名が含まれています。ハードウェアモジュールがローカルに証明書を格納している場合は、証明書も含めることができます。 SignedDataのフィールドは、セクション3.1.2で説明されているとおりに使用されます。
The hardware module is represented in the SignerInfo type. The fields of SignerInfo are used exactly as described in Section 3.1.2.1.
ハードウェアモジュールは、SignerInfoタイプで表されます。 SignerInfoのフィールドは、セクション3.1.2.1で説明されているとおりに使用されます。
The FirmwarePackageLoadError is encapsulated in an OCTET STRING, and it is carried within the EncapsulatedContentInfo type. The fields of EncapsulatedContentInfo are used as follows:
FirmwarePackageLoadErrorはOCTET STRINGにカプセル化され、EncapsulatedContentInfoタイプ内で伝達されます。 EncapsulatedContentInfoのフィールドは次のように使用されます。
eContentType is an object identifier that uniquely specifies the content type, and in this case, it MUST be the value of id-ct-firmwareLoadError (1.2.840.113549.1.9.16.1.18).
eContentTypeは、コンテンツタイプを一意に指定するオブジェクト識別子であり、この場合、id-ct-firmwareLoadError（1.2.840.113549.1.9.16.1.18）の値である必要があります。
eContent is the firmware package load error report, encapsulated in an OCTET STRING. The eContent octet string need not be DER encoded.
eContentは、ファームウェアパッケージのロードエラーレポートで、OCTET STRINGにカプセル化されています。 eContentオクテット文字列は、DERエンコードする必要はありません。
The following object identifier identifies the firmware package load error report content type:
次のオブジェクト識別子は、ファームウェアパッケージのロードエラーレポートのコンテンツタイプを識別します。
id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 18 }
The firmware package load error report content type has the ASN.1 type FirmwarePackageLoadError:
ファームウェアパッケージロードエラーレポートのコンテンツタイプには、ASN.1タイプFirmwarePackageLoadErrorがあります。
FirmwarePackageLoadError ::= SEQUENCE {
version FWErrorVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
errorCode FirmwarePackageLoadErrorCode,
vendorErrorCode VendorLoadErrorCode OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
config [1] SEQUENCE OF CurrentFWConfig OPTIONAL }
FWErrorVersion ::= INTEGER { v1(1) }
CurrentFWConfig ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier }
FirmwarePackageLoadErrorCode ::= ENUMERATED {
decodeFailure (1),
badContentInfo (2),
badSignedData (3),
badEncapContent (4),
badCertificate (5),
badSignerInfo (6),
badSignedAttrs (7),
badUnsignedAttrs (8),
missingContent (9),
noTrustAnchor (10),
notAuthorized (11),
badDigestAlgorithm (12),
badSignatureAlgorithm (13),
unsupportedKeySize (14),
signatureFailure (15),
contentTypeMismatch (16),
badEncryptedData (17),
unprotectedAttrsPresent (18),
badEncryptContent (19),
badEncryptAlgorithm (20),
missingCiphertext (21),
noDecryptKey (22),
decryptFailure (23),
badCompressAlgorithm (24),
missingCompressedContent (25),
decompressFailure (26),
wrongHardware (27),
stalePackage (28),
notInCommunity (29),
unsupportedPackageType (30),
missingDependency (31),
wrongDependencyVersion (32),
insufficientMemory (33),
badFirmware (34),
unsupportedParameters (35),
breaksDependency (36),
otherError (99) }
VendorLoadErrorCode ::= INTEGER
The fields of the FirmwarePackageLoadError type have the following meanings:
FirmwarePackageLoadErrorタイプのフィールドには、次の意味があります。
version is an integer, and it provides the syntax version number for compatibility with future revisions of this specification. Implementations that conform to this specification MUST set the version to the default value, which is v1.
versionは整数であり、この仕様の将来のリビジョンとの互換性のために構文バージョン番号を提供します。この仕様に準拠する実装では、バージョンをデフォルト値（v1）に設定する必要があります。
hwType is an object identifier that identifies the type of hardware module on which the firmware package load was attempted.
hwTypeは、ファームウェアパッケージのロードが試行されたハードウェアモジュールのタイプを識別するオブジェクト識別子です。
hwSerialNum is the serial number of the hardware module on which the firmware package load was attempted. No particular structure is imposed on the serial number; it need not be an integer. However, the combination of the hwType and hwSerialNum uniquely identifies the hardware module.
hwSerialNumは、ファームウェアパッケージのロードが試行されたハードウェアモジュールのシリアル番号です。シリアル番号には特別な構造はありません。整数である必要はありません。ただし、hwTypeとhwSerialNumの組み合わせは、ハードウェアモジュールを一意に識別します。
errorCode identifies the error that occurred.
errorCodeは、発生したエラーを識別します。
vendorErrorCode is optional; however, it MUST be present if the errorCode contains a value of otherError. When errorCode contains a value other than otherError, the vendorErrorCode can provide vendor-specific supplemental information.
vendorErrorCodeはオプションです。ただし、errorCodeにotherErrorの値が含まれている場合は、存在する必要があります。 errorCodeにotherError以外の値が含まれている場合、vendorErrorCodeはベンダー固有の補足情報を提供できます。
fwPkgName is optional. When it is present, it identifies the firmware package that was being loaded when the error occurred. As described in Section 2.2.3, two approaches to naming firmware packages are supported: legacy and preferred. A legacy firmware package name is an octet string. A preferred firmware package name is a combination of the firmware package object identifier and an integer version number.
fwPkgNameはオプションです。存在する場合は、エラーが発生したときにロードされていたファームウェアパッケージを識別します。セクション2.2.3で説明されているように、ファームウェアパッケージの命名には、レガシーと優先の2つのアプローチがサポートされています。従来のファームウェアパッケージ名はオクテット文字列です。推奨されるファームウェアパッケージ名は、ファームウェアパッケージオブジェクト識別子と整数バージョン番号の組み合わせです。
config identifies the current firmware configuration. The field is OPTIONAL, but support for this field is RECOMMENDED for hardware modules that permit the loading of more than one firmware package. One instance of CurrentFWConfig is used to provide information about each firmware package in hardware module.
configは、現在のファームウェア構成を識別します。このフィールドはオプションですが、このフィールドのサポートは、複数のファームウェアパッケージのロードを許可するハードウェアモジュールに対して推奨されます。 CurrentFWConfigの1つのインスタンスは、ハードウェアモジュールの各ファームウェアパッケージに関する情報を提供するために使用されます。
The fields of the CurrentFWConfig type have the following meanings:
CurrentFWConfigタイプのフィールドには、次の意味があります。
fwPkgType identifies the firmware package type. The firmware package type is an INTEGER, and the meaning of the integer value is specific to each hardware module.
fwPkgTypeは、ファームウェアパッケージタイプを識別します。ファームウェアパッケージタイプはINTEGERであり、整数値の意味は各ハードウェアモジュールに固有です。
fwPkgName identifies the firmware package. As described in Section 2.2.3, two approaches to naming firmware packages are supported: legacy and preferred. A legacy firmware package name is an octet string. A preferred firmware package name is a combination of the firmware package object identifier and an integer version number.
fwPkgNameはファームウェアパッケージを識別します。セクション2.2.3で説明されているように、ファームウェアパッケージの命名には、レガシーと優先の2つのアプローチがサポートされています。従来のファームウェアパッケージ名はオクテット文字列です。推奨されるファームウェアパッケージ名は、ファームウェアパッケージオブジェクト識別子と整数バージョン番号の組み合わせです。
The errorCode values have the following meanings:
errorCode値には次の意味があります。
decodeFailure: The ASN.1 decode of the firmware package load failed. The provided input did not conform to BER, or it was not ASN.1 at all.
decodeFailure：ファームウェアパッケージのロードのASN.1デコードが失敗しました。提供された入力はBERに準拠していなかったか、まったくASN.1ではありませんでした。
badContentInfo: Invalid ContentInfo syntax, or the contentType carried within the ContentInfo is unknown or unsupported.
badContentInfo：無効なContentInfo構文、またはContentInfo内で運ばれるcontentTypeが不明またはサポートされていません。
badSignedData: Invalid SignedData syntax, the version is unknown or unsupported, or more than one entry is present in digestAlgorithms.
badSignedData：無効なSignedData構文、バージョンが不明またはサポートされていない、またはdigestAlgorithmsに複数のエントリが存在する。
badEncapContent: Invalid EncapsulatedContentInfo syntax, or the contentType carried within the eContentType is unknown or unsupported. This error can be generated due to problems located in SignedData or CompressedData.
badEncapContent：無効なEncapsulatedContentInfo構文、またはeContentType内で運ばれるcontentTypeが不明またはサポートされていません。このエラーは、SignedDataまたはCompressedDataにある問題が原因で発生する可能性があります。
badCertificate: Invalid syntax for one or more certificates in CertificateSet.
badCertificate：CertificateSetの1つ以上の証明書の無効な構文。
badSignerInfo: Invalid SignerInfo syntax, or the version is unknown or unsupported.
badSignerInfo：無効なSignerInfo構文、またはバージョンが不明またはサポートされていません。
badSignedAttrs: Invalid signedAttrs syntax within SignerInfo.
badSignedAttrs：SignerInfo内の無効なsignedAttrs構文。
badUnsignedAttrs: The unsignedAttrs within SignerInfo contains an attribute other than the wrapped-firmware-decryption-key attribute, which is the only unsigned attribute supported by this specification.
badUnsignedAttrs：SignerInfo内のunsignedAttrsには、wrapped-firmware-decryption-key属性以外の属性が含まれています。これは、この仕様でサポートされている唯一の署名されていない属性です。
missingContent: The optional eContent is missing in EncapsulatedContentInfo, which is required in this specification. This error can be generated due to problems located in SignedData or CompressedData.
missingContent：オプションのeContentがこの仕様で必要なEncapsulatedContentInfoにありません。このエラーは、SignedDataまたはCompressedDataにある問題が原因で発生する可能性があります。
noTrustAnchor: Two situations can lead to this error. In one case, the subjectKeyIdentifier does not identify the public key of a trust anchor or a certification path that terminates with an installed trust anchor. In the other case, the issuerAndSerialNumber does not identify the public key of a trust anchor or a certification path that terminates with an installed trust anchor.
noTrustAnchor：2つの状況がこのエラーにつながる可能性があります。ある場合では、subjectKeyIdentifierは、トラストアンカーの公開鍵、またはインストールされているトラストアンカーで終了する証明書パスを識別しません。その他の場合、issuerAndSerialNumberは、トラストアンカーの公開鍵、またはインストールされているトラストアンカーで終了する証明書パスを識別しません。
notAuthorized: The sid within SignerInfo leads to an installed trust anchor, but that trust anchor is not an authorized firmware package signer.
notAuthorized：SignerInfo内のsidはインストールされたトラストアンカーにつながりますが、そのトラストアンカーは承認されたファームウェアパッケージの署名者ではありません。
badDigestAlgorithm: The digestAlgorithm in either SignerInfo or SignedData is unknown or unsupported.
badDigestAlgorithm：SignerInfoまたはSignedDataのいずれかのdigestAlgorithmが不明またはサポートされていません。
badSignatureAlgorithm: The signatureAlgorithm in SignerInfo is unknown or unsupported.
badSignatureAlgorithm：SignerInfoのsignatureAlgorithmが不明またはサポートされていません。
unsupportedKeySize: The signatureAlgorithm in SignerInfo is known and supported, but the firmware package signature could not be validated because an unsupported key size was employed by the signer.
unsupportedKeySize：SignerInfoのsignatureAlgorithmは既知でありサポートされていますが、サポートされていないキーサイズが署名者によって使用されたため、ファームウェアパッケージの署名を検証できませんでした。
signatureFailure: The signatureAlgorithm in SignerInfo is known and supported, but the signature in signature in SignerInfo could not be validated.
signatureFailure：SignerInfoのsignatureAlgorithmは既知であり、サポートされていますが、SignerInfoの署名の署名を検証できませんでした。
contentTypeMismatch: The contentType carried within the eContentType does not match the content type carried in the signed attribute.
contentTypeMismatch：eContentType内で伝達されるcontentTypeは、signed属性で伝達されるコンテンツタイプと一致しません。
badEncryptedData: Invalid EncryptedData syntax; the version is unknown or unsupported.
badEncryptedData：無効なEncryptedData構文。バージョンが不明またはサポートされていません。
unprotectedAttrsPresent: EncryptedData contains unprotectedAttrs, which are not permitted in this specification.
unprotectedAttrsPresent：EncryptedDataにはunprotectedAttrsが含まれていますが、この仕様では許可されていません。
badEncryptContent: Invalid EncryptedContentInfo syntax, or the contentType carried within the contentType is unknown or unsupported.
badEncryptContent：無効なEncryptedContentInfo構文、またはcontentType内に含まれるcontentTypeが不明またはサポートされていません。
badEncryptAlgorithm: The firmware-encryption algorithm identified by contentEncryptionAlgorithm in EncryptedContentInfo is unknown or unsupported.
badEncryptAlgorithm：EncryptedContentInfoのcontentEncryptionAlgorithmによって識別されるファームウェア暗号化アルゴリズムが不明であるか、サポートされていません。
missingCiphertext: The optional encryptedContent is missing in EncryptedContentInfo, which is required in this specification.
missingCiphertext：この仕様で必要なEncryptedContentInfoにオプションのencryptedContentがありません。
noDecryptKey: The hardware module does not have the firmware-decryption key named in the decrypt key identifier signed attribute.
noDecryptKey：ハードウェアモジュールには、復号化キー識別子の署名済み属性で指定されたファームウェア復号化キーがありません。
decryptFailure: The firmware package did not decrypt properly.
decodeFailure：ファームウェアパッケージが正しく復号化されませんでした。
badCompressAlgorithm: The compression algorithm identified by compressionAlgorithm in CompressedData is unknown or unsupported.
badCompressAlgorithm：CompressedDataのcompressionAlgorithmによって識別される圧縮アルゴリズムが不明であるか、サポートされていません。
missingCompressedContent: The optional eContent is missing in EncapsulatedContentInfo, which is required in this specification.
missingCompressedContent：オプションのeContentがこの仕様で必要なEncapsulatedContentInfoにありません。
decompressFailure: The firmware package did not decompress properly.
decompressFailure：ファームウェアパッケージが適切に解凍されませんでした。
wrongHardware: The processing hardware module is not listed in the target hardware module identifiers signed attribute.
wrongHardware：処理ハードウェアモジュールは、ターゲットハードウェアモジュール識別子の署名済み属性にリストされていません。
stalePackage: The firmware package is rejected because it is stale.
stalePackage：ファームウェアパッケージは古くなっているため拒否されます。
notInCommunity: The hardware module is not a member of the community described in the community identifiers signed attribute.
notInCommunity：ハードウェアモジュールは、コミュニティ識別子の署名済み属性で説明されているコミュニティのメンバーではありません。
unsupportedPackageType: The firmware package type identified in the firmware package information signed attribute is not supported by the combination of the hardware module and the bootstrap loader.
unsupportedPackageType：ファームウェアパッケージ情報の署名済み属性で識別されたファームウェアパッケージタイプは、ハードウェアモジュールとブートストラップローダーの組み合わせではサポートされていません。
missingDependency: The firmware package being loaded depends on routines that are part of another firmware package, but that firmware package is not available.
missingDependency：ロードされているファームウェアパッケージは、別のファームウェアパッケージの一部であるルーチンに依存していますが、そのファームウェアパッケージは利用できません。
wrongDependencyVersion: The firmware package being loaded depends on routines that are part of the another firmware package, and the available version of that package has an older version number than is required. The available firmware package does not fulfill the dependencies.
wrongDependencyVersion：ロードされるファームウェアパッケージは、別のファームウェアパッケージの一部であるルーチンに依存しており、そのパッケージの使用可能なバージョンには、必要なバージョン番号より古いバージョン番号が付いています。利用可能なファームウェアパッケージは依存関係を満たしていません。
insufficientMemory: The firmware package could not be loaded because the hardware module did not have sufficient memory.
不十分なメモリ：ハードウェアモジュールに十分なメモリがないため、ファームウェアパッケージをロードできませんでした。
badFirmware: The signature on the firmware package was validated, but the firmware package itself was not in an acceptable format. The details will be specific to each hardware module. For example, a hardware module that is composed of multiple firmware-programmable components could not find the internal tagging within the firmware package to distribute executable code to each of the components.
badFirmware：ファームウェアパッケージの署名は検証されましたが、ファームウェアパッケージ自体は許容可能な形式ではありませんでした。詳細は、各ハードウェアモジュールに固有です。たとえば、複数のファームウェアプログラマブルコンポーネントで構成されるハードウェアモジュールは、実行可能コードを各コンポーネントに配布するファームウェアパッケージ内の内部タグ付けを見つけることができませんでした。
unsupportedParameters: The signature on the firmware package could not be validated because the signer used signature algorithm parameters that are not supported by the hardware module signature verification routines.
unsupportedParameters：署名者がハードウェアモジュールの署名検証ルーチンでサポートされていない署名アルゴリズムパラメーターを使用したため、ファームウェアパッケージの署名を検証できませんでした。
breaksDependency: Another firmware package has a dependency that can no longer be satisfied if the firmware package being loaded is accepted.
breaksDependency：別のファームウェアパッケージには依存関係があり、ロードされているファームウェアパッケージが受け入れられた場合は、それ以上満たすことができません。
otherError: An error occurred that does not fit any of the previous error codes.
otherError：以前のエラーコードのいずれにも当てはまらないエラーが発生しました。
The hardware module MUST digitally sign a collection of attributes along with the firmware package load error report. Each attribute in the collection MUST be DER encoded [X.509-88]. The syntax for attributes is defined in [CMS], and it was repeated in Section 2.2 for convenience.
ハードウェアモジュールは、ファームウェアパッケージロードエラーレポートとともに属性のコレクションにデジタル署名する必要があります。コレクションの各属性は、DERエンコードされている必要があります[X.509-88]。属性の構文は[CMS]で定義されており、2.2節で便宜上繰り返されています。
Each of the attributes used with this profile has a single attribute value, even though the syntax is defined as a SET OF AttributeValue. There MUST be exactly one instance of AttributeValue present.
構文がSET OF AttributeValueとして定義されている場合でも、このプロファイルで使用される各属性には単一の属性値があります。 AttributeValueのインスタンスが1つだけ存在している必要があります。
The SignedAttributes syntax within signerInfo is defined as a SET OF Attributes. The SignedAttributes MUST include only one instance of any particular attribute.
signerInfo内のSignedAttributes構文は、SET OF属性として定義されます。 SignedAttributesには、特定の属性のインスタンスを1つだけ含める必要があります。
The hardware module MUST include the content-type and message-digest attributes. If the hardware module includes a real-time clock, then the hardware module SHOULD also include the signing-time attribute. The hardware module MAY include any other attribute that it deems appropriate.
ハードウェアモジュールには、コンテンツタイプとメッセージダイジェストの属性を含める必要があります。ハードウェアモジュールにリアルタイムクロックが含まれている場合、ハードウェアモジュールには、署名時間属性も含める必要があります（SHOULD）。ハードウェアモジュールには、適切と見なされるその他の属性を含めることができます。
The hardware module MUST include a content-type attribute with the value of id-ct-firmwareLoadError (1.2.840.113549.1.9.16.1.18). Section 11.1 of [CMS] defines the content-type attribute.
ハードウェアモジュールには、id-ct-firmwareLoadError（1.2.840.113549.1.9.16.1.18）の値を持つcontent-type属性を含める必要があります。 [CMS]のセクション11.1はcontent-type属性を定義しています。
The hardware module MUST include a message-digest attribute, having as its value the message digest of the FirmwarePackageLoadError content. Section 11.2 of [CMS] defines the message-digest attribute.
ハードウェアモジュールは、値としてFirmwarePackageLoadErrorコンテンツのメッセージダイジェストを持つメッセージダイジェスト属性を含まなければなりません（MUST）。 [CMS]のセクション11.2は、メッセージダイジェスト属性を定義しています。
If the hardware module includes a real-time clock, then hardware module SHOULD include a signing-time attribute, specifying the time at which the firmware package load error report was generated. Section 11.3 of [CMS] defines the signing-time attribute.
ハードウェアモジュールにリアルタイムクロックが含まれている場合、ハードウェアモジュールには、ファームウェアパッケージロードエラーレポートが生成された時刻を指定するsigning-time属性を含める必要があります（SHOULD）。 [CMS]のセクション11.3は、署名時間属性を定義しています。
Support for firmware package load receipts, as discussed in Section 3, is OPTIONAL, and support for the firmware package load error reports, as discussed in Section 4, is OPTIONAL. Hardware modules that support receipt or error report generation MUST have unique serial numbers. Further, hardware modules that support signed receipt or error report generation MUST have private signature keys and corresponding signature validation certificates [PROFILE] or their designators. The conventions for hardware module naming in the signature validation certificates are specified in this section.
セクション3で説明されているファームウェアパッケージロード受信のサポートはオプションであり、セクション4で説明されているファームウェアパッケージロードエラーレポートのサポートはオプションです。受信またはエラーレポートの生成をサポートするハードウェアモジュールには、一意のシリアル番号が必要です。さらに、署名された受信またはエラーレポートの生成をサポートするハードウェアモジュールには、秘密の署名キーと対応する署名検証証明書[プロファイル]またはその指定子が必要です。このセクションでは、署名検証証明書でのハードウェアモジュールの命名規則について説明します。
The hardware module vendor or a trusted third party MUST issue the signature validation certificate prior to deployment of the hardware module. The certificate is likely to be issued at the time of manufacture. The subject alternative name in this certificate identifies the hardware module. The subject distinguished name is empty, but a critical subject alternative name extension contains the hardware module name, using the otherName choice within the GeneralName structure.
ハードウェアモジュールベンダーまたは信頼できるサードパーティは、ハードウェアモジュールの展開前に署名検証証明書を発行する必要があります。証明書は製造時に発行される可能性があります。この証明書のサブジェクトの別名は、ハードウェアモジュールを識別します。サブジェクトの識別名は空ですが、クリティカルサブジェクトの別名拡張には、GeneralName構造内のotherName選択を使用したハードウェアモジュール名が含まれています。
The hardware module name form is identified by the id-on-hardwareModuleName object identifier:
ハードウェアモジュール名の形式は、id-on-hardwareModuleNameオブジェクト識別子で識別されます。
id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) on(8) 4 }
A HardwareModuleName is composed of an object identifier and an octet string:
HardwareModuleNameは、オブジェクト識別子とオクテット文字列で構成されています。
HardwareModuleName ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }
The fields of the HardwareModuleName type have the following meanings:
HardwareModuleNameタイプのフィールドには、次の意味があります。
hwType is an object identifier that identifies the type of hardware module. A unique object identifier names a hardware model and revision.
hwTypeは、ハードウェアモジュールのタイプを識別するオブジェクト識別子です。一意のオブジェクト識別子は、ハードウェアモデルとリビジョンを指定します。
hwSerialNum is the serial number of the hardware module. No particular structure is imposed on the serial number; it need not be an integer. However, the combination of the hwType and hwSerialNum uniquely identifies the hardware module.
hwSerialNumは、ハードウェアモジュールのシリアル番号です。シリアル番号には特別な構造はありません。整数である必要はありません。ただし、hwTypeとhwSerialNumの組み合わせは、ハードウェアモジュールを一意に識別します。
This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages; therefore, the security considerations discussed in [CMS] apply to this specification as well.
このドキュメントでは、暗号化メッセージ構文（CMS）を使用してファームウェアパッケージを保護する方法について説明します。したがって、[CMS]で説明されているセキュリティの考慮事項は、この仕様にも適用されます。
The conventions specified in this document raise a few security considerations of their own.
このドキュメントで指定されている規則は、独自のセキュリティ上の考慮事項をいくつか提起しています。
Private signature keys must be protected. Compromise of the private key used to sign firmware packages permits unauthorized parties to generate firmware packages that are acceptable to hardware modules. Compromise of the hardware module private key allows unauthorized parties to generate signed firmware package load receipts and error reports.
秘密署名鍵は保護する必要があります。ファームウェアパッケージに署名するために使用される秘密鍵の侵害により、権限のない者がハードウェアモジュールに受け入れ可能なファームウェアパッケージを生成することができます。ハードウェアモジュールの秘密鍵の侵害により、未承認の当事者が署名されたファームウェアパッケージのロードの領収書とエラーレポートを生成できます。
The firmware-decryption key must be protected. Compromise of the key may result in the disclosure of the firmware package to unauthorized parties.
ファームウェア復号化キーは保護する必要があります。キーが侵害されると、ファームウェアパッケージが不正な関係者に開示される可能性があります。
Cryptographic algorithms become weaker with time. As new cryptanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will be reduced. The ability to change the firmware package provides an opportunity to update or replace cryptographic algorithms. Although this capability is desirable, cryptographic algorithm replacement can lead to interoperability failures. Therefore, the rollout of new cryptographic algorithms must be managed. Generally, the previous generation of cryptographic algorithms and their replacements need to be supported at the same time in order to facilitate an orderly transition.
暗号化アルゴリズムは時間とともに弱くなります。新しい暗号解読技術が開発され、コンピューティングパフォーマンスが向上すると、特定の暗号アルゴリズムを解読するための作業要素が減少します。ファームウェアパッケージを変更する機能は、暗号化アルゴリズムを更新または置き換える機会を提供します。この機能は望ましいですが、暗号化アルゴリズムを置き換えると、相互運用性の障害が発生する可能性があります。したがって、新しい暗号化アルゴリズムのロールアウトを管理する必要があります。一般に、前の世代の暗号化アルゴリズムとそれらの置き換えは、正常な移行を容易にするために同時にサポートする必要があります。
When firmware packages are encrypted, the source of the firmware package must randomly generate firmware-encryption keys. Also, the generation of public/private signature key pairs relies on a random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute-force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RANDOM] offers important guidance in this area.
ファームウェアパッケージが暗号化されている場合、ファームウェアパッケージのソースはファームウェア暗号化キーをランダムに生成する必要があります。また、公開/秘密署名鍵ペアの生成は、乱数に依存します。不十分な疑似乱数ジェネレーター（PRNG）を使用して暗号化キーを生成すると、セキュリティがほとんどまたはまったくなくなる可能性があります。攻撃者は、キースペース全体をブルートフォースで検索するよりも、キーを生成したPRNG環境を再現し、結果として生じる可能性の小さなセットを検索する方がはるかに簡単であることに気付く場合があります。高品質の乱数の生成は困難です。 RFC 4086 [ランダム]は、この分野で重要なガイダンスを提供しています。
The firmware signer determines whether a stale version number is included. The policy of the firmware signer needs to consider many factors. Consider the flaw found by Ian Goldberg and David Wagner in the random number generator of the Netscape browser in 1996 [DDJ]. This flaw completely undermines confidentiality protection. A firmware signer might use the stale version number to ensure that upgraded hardware modules do not resume use of the flawed firmware. However, another firmware signer may not consider this an appropriate situation to employ the stale version number, preferring to delegate this decision to someone closer to the operation of the hardware module. Such a person is likely to be in a better position to evaluate whether other bugs introduced in the newer firmware package impose worse operational concerns than the confidentiality concern caused by the flawed random number generator. For example, a user who never uses the encryption feature of the flawed Netscape browser will determine the most appropriate version to use without considering the random number flaw or its fix.
ファームウェアの署名者は、古いバージョン番号が含まれているかどうかを判断します。ファームウェア署名者のポリシーは、多くの要因を考慮する必要があります。 1996年にNetscapeブラウザの乱数ジェネレータでIan GoldbergとDavid Wagnerが発見した欠陥を考えてみてください[DDJ]。この欠陥により、機密保護が完全に損なわれます。ファームウェアの署名者は古いバージョン番号を使用して、アップグレードされたハードウェアモジュールが欠陥のあるファームウェアの使用を再開しないようにします。ただし、別のファームウェア署名者は、古いバージョン番号を採用するのにこれを適切な状況とは見なさず、この決定をハードウェアモジュールの操作に近い誰かに委任することを好む場合があります。そのような人物は、新しいファームウェアパッケージで導入された他のバグが、欠陥のある乱数ジェネレーターによって引き起こされる機密性の懸念よりも運用上の懸念を引き起こすかどうかを評価するより良い立場にある可能性があります。たとえば、欠陥のあるNetscapeブラウザの暗号化機能を決して使用しないユーザーは、乱数の欠陥やその修正を考慮せずに、使用するのに最適なバージョンを決定します。
The stale version number is especially useful when the security interests of the person choosing which firmware package version to load into a particular hardware module do not align with the security interests of the firmware package signer. For example, stale version numbers may be useful in hardware modules that provide digital rights management (DRM). Also, stale version numbers will be useful when the deployment organization (as opposed to the firmware package vendor) is the firmware signer. Further, stale version numbers will be useful for firmware packages that need to be trusted to implement organizational (as opposed to the deployment organization) security policy, regardless of whether the firmware signer is the deployment organization or the vendor. For example, hardware devices employed by the military will probably make use of stale version numbers.
古いバージョン番号は、特定のハードウェアモジュールにロードするファームウェアパッケージのバージョンを選択する人のセキュリティ上の関心が、ファームウェアパッケージの署名者のセキュリティ上の関心と一致しない場合に特に役立ちます。たとえば、古いバージョン番号は、デジタル著作権管理（DRM）を提供するハードウェアモジュールで役立ちます。また、（ファームウェアパッケージベンダーではなく）展開組織がファームウェア署名者である場合は、古いバージョン番号が役立ちます。さらに、古いバージョン番号は、ファームウェアの署名者が展開組織であるかベンダーであるかに関係なく、組織（展開組織ではなく）のセキュリティポリシーを実装するために信頼する必要があるファームウェアパッケージに役立ちます。たとえば、軍隊で採用されているハードウェアデバイスでは、古いバージョン番号が使用される可能性があります。
The use of a stale version number in a firmware package that employs the preferred firmware package name form cannot completely prevent subsequent use of the stale firmware package. Despite this shortcoming, the feature is included since it is useful in some important situations. By loading different types of firmware packages, each with its own stale firmware package version number until the internal storage for the stale version number is exceeded, the user can circumvent the mechanism. Consider a hardware module that has storage for two stale version numbers. Suppose that FWPKG-A version 3 is loaded, indicating that FWPKG-A version 2 is stale. The user can sequentially load the following:
優先ファームウェアパッケージ名の形式を採用しているファームウェアパッケージで古いバージョン番号を使用しても、古いファームウェアパッケージのその後の使用を完全に防ぐことはできません。この欠点にもかかわらず、いくつかの重要な状況で役立つため、機能が含まれています。古いバージョン番号の内部ストレージを超えるまで、独自の古いファームウェアパッケージのバージョン番号を持つ異なるタイプのファームウェアパッケージをロードすることにより、ユーザーはメカニズムを回避できます。 2つの古いバージョン番号用のストレージを持つハードウェアモジュールについて考えてみます。 FWPKG-Aバージョン3がロードされていて、FWPKG-Aバージョン2が古いことを示しているとします。ユーザーは次のものを順次ロードできます。
- FWPKG-B version 8, indicating that FWPKG-B version 4 is stale. (Note: The internal storage indicates that FWPKG-A version 2 and FWPKG-B version 4 are stale.)
- FWPKG-Bバージョン8は、FWPKG-Bバージョン4が古いことを示します。 （注：内部ストレージは、FWPKG-Aバージョン2およびFWPKG-Bバージョン4が古いことを示しています。）
- FWPKG-C version 5, indicating that FWPKG-C version 3 is stale. (Note: The internal storage indicates that FWPKG-B version 4 and FWPKG-C version 3 are stale.)
- FWPKG-Cバージョン5は、FWPKG-Cバージョン3が古いことを示します。 （注：内部ストレージは、FWPKG-Bバージョン4およびFWPKG-Cバージョン3が古いことを示しています。）
- FWPKG-A version 2.
- FWPKG-Aバージョン2。
Because many hardware modules are expected to have very few firmware packages written for them, the stale firmware package version feature provides important protections. The amount of non-volatile storage that needs to be dedicated to saving firmware package identifiers and version numbers depends on the number of firmware packages that are likely to be developed for the hardware module.
多くのハードウェアモジュールにはファームウェアパッケージがほとんど書き込まれていないことが予想されるため、古いファームウェアパッケージバージョン機能は重要な保護を提供します。ファームウェアパッケージ識別子とバージョン番号を保存するために専用に必要な不揮発性ストレージの量は、ハードウェアモジュール用に開発される可能性が高いファームウェアパッケージの数によって異なります。
The use of legacy firmware package name form does not improve this situation. In fact, the legacy firmware package names are usually larger than an object identifier. Thus, comparable stale version protection requires more memory.
レガシーファームウェアパッケージ名の形式を使用しても、この状況は改善されません。実際、従来のファームウェアパッケージ名は通常、オブジェクト識別子よりも大きくなっています。したがって、同等の古いバージョンの保護には、より多くのメモリが必要です。
A firmware signer can ensure that stale version numbers are honored by limiting the number of different types of firmware packages that are signed. If all of the hardware modules are able to store a stale version number for each of the different types of firmware package, then the hardware module will be able to provide the desired protection. This requires the firmware signer to have a deep understanding of all of the hardware modules that might accept the firmware package.
ファームウェアの署名者は、署名されている異なるタイプのファームウェアパッケージの数を制限することにより、古いバージョン番号が守られるようにすることができます。すべてのハードウェアモジュールが異なるタイプのファームウェアパッケージごとに古いバージョン番号を保存できる場合、ハードウェアモジュールは必要な保護を提供できます。これには、ファームウェア署名者が、ファームウェアパッケージを受け入れるすべてのハードウェアモジュールを深く理解している必要があります。
When a firmware package includes a community identifier, the confidence that the package is only used by the intended community depends on the mechanism used to configure community membership. This document does not specify a mechanism for the assignment of community membership to hardware modules, and the various alternatives have different security properties. Also, the authority that makes community identifier assignments to hardware modules might be different than the authority that generates firmware packages.
ファームウェアパッケージにコミュニティ識別子が含まれている場合、そのパッケージが目的のコミュニティでのみ使用されるという信頼性は、コミュニティメンバーシップの構成に使用されるメカニズムに依存します。このドキュメントでは、ハードウェアモジュールへのコミュニティメンバーシップの割り当てのメカニズムを指定していません。また、さまざまな選択肢には異なるセキュリティプロパティがあります。また、コミュニティIDをハードウェアモジュールに割り当てる権限は、ファームウェアパッケージを生成する権限とは異なる場合があります。
[COMPRESS] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[COMPRESS] Gutmann、P。、「暗号化メッセージ構文（CMS）の圧縮データコンテンツタイプ」、RFC 3274、2002年6月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、RFC 3852、2004年7月。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS] Hoffman、P。、「Enhanced Security Services for S / MIME」、RFC 2634、1999年6月。
[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[プロファイル] Housley、R.、Polk、W.、Ford、W。、およびD. Solo、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[SHA1] National Institute of Standards and Technology. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995.
[SHA1]国立標準技術研究所。 FIPS Pub 180-1：Secure Hash Standard。 1995年4月17日。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
[X.208-88] CCITT。勧告X.208：抽象構文記法1（ASN.1）の仕様。 1988。
[X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
[X.209-88] CCITT。推奨事項X.209：抽象構文記法1（ASN.1）の基本的なエンコーディングルールの仕様。 1988。
[X.509-88] CCITT. Recommendation X.509: The Directory - Authentication Framework. 1988.
[X.509-88] CCITT。推奨事項X.509：ディレクトリ-認証フレームワーク。 1988。
[ACPROFILE] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[ACPROFILE] Farrell、S。およびR. Housley、「承認のためのインターネット属性証明書プロファイル」、RFC 3281、2002年4月。
[AES] National Institute of Standards and Technology. FIPS Pub 197: Advanced Encryption Standard (AES). 26 November 2001.
[AES]国立標準技術研究所。 FIPS Pub 197：Advanced Encryption Standard（AES）。 2001年11月26日。
[DDJ] Goldberg, I. and D. Wagner. "Randomness and the Netscape Browser." Dr. Dobb's Journal, January 1996.
[DDJ]ゴールドバーグ、I。およびD.ワーグナー。 「ランダムネスとネットスケープブラウザ。」ドブ博士のジャーナル、1996年1月。
[DPD&DPV] Pinkas, D. and R. Housley, "Delegated Path Validation and Delegated Path Discovery Protocol Requirements", RFC 3379, September 2002.
[DPD＆DPV] Pinkas、D。およびR. Housley、「Delegated Path Validation and Delegated Path Discovery Protocol Requirements」、RFC 3379、2002年9月。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[OCSP]マイヤーズ、M。、アンクニー、R。、マルパニ、A。、ガルペリン、S。、およびC.アダムス、「X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル-OCSP」、RFC 2560、1999年6月。
[PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, Version 1.5. November 1993.
[PKCS＃6] RSA Laboratories。 PKCS＃6：Extended-Certificate Syntax Standard、バージョン1.5。 1993年11月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[SECREQMTS] National Institute of Standards and Technology. FIPS Pub 140-2: Security Requirements for Cryptographic Modules. 25 May 2001.
[SECREQMTS]国立標準技術研究所。 FIPS Pub 140-2：暗号化モジュールのセキュリティ要件。 2001年5月25日。
[X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication Framework. 1997.
[X.509-97] ITU-T。推奨事項X.509：ディレクトリ-認証フレームワーク。 1997年
[X.509-00] ITU-T. Recommendation X.509: The Directory - Authentication Framework. 2000.
[X.509-00] ITU-T。推奨事項X.509：ディレクトリ-認証フレームワーク。 2000年
Appendix A: ASN.1 Module
付録A：ASN.1モジュール
The ASN.1 module contained in this appendix defines the structures that are needed to implement the CMS-based firmware package wrapper. It is expected to be used in conjunction with the ASN.1 modules in [CMS], [COMPRESS], and [PROFILE].
この付録に含まれるASN.1モジュールは、CMSベースのファームウェアパッケージラッパーを実装するために必要な構造を定義します。 [CMS]、[COMPRESS]、および[PROFILE]のASN.1モジュールと組み合わせて使用することが期待されています。
CMSFirmwareWrapper
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-firmware-wrap(22) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS
EnvelopedData
FROM CryptographicMessageSyntax -- [CMS]
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) };
-- Firmware Package Content Type and Object Identifier
-ファームウェアパッケージのコンテンツタイプとオブジェクト識別子
id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 16 }
FirmwarePkgData ::= OCTET STRING
-- Firmware Package Signed Attributes and Object Identifiers
-ファームウェアパッケージの署名済み属性とオブジェクト識別子
id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 35 }
FirmwarePackageIdentifier ::= SEQUENCE {
name PreferredOrLegacyPackageIdentifier,
stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
PreferredOrLegacyPackageIdentifier ::= CHOICE {
preferred PreferredPackageIdentifier,
legacy OCTET STRING }
PreferredPackageIdentifier ::= SEQUENCE {
fwPkgID OBJECT IDENTIFIER,
verNum INTEGER (0..MAX) }
PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
preferredStaleVerNum INTEGER (0..MAX),
legacyStaleVersion OCTET STRING }
id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 36 }
TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 37 }
DecryptKeyIdentifier ::= OCTET STRING
id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 38 }
ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 43 }
ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 40 }
CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
CommunityIdentifier ::= CHOICE {
communityOID OBJECT IDENTIFIER,
hwModuleList HardwareModules }
HardwareModules ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialEntries SEQUENCE OF HardwareSerialEntry }
HardwareSerialEntry ::= CHOICE {
all NULL,
single OCTET STRING,
block SEQUENCE {
low OCTET STRING,
high OCTET STRING } }
id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 42 }
FirmwarePackageInfo ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
dependencies SEQUENCE OF
PreferredOrLegacyPackageIdentifier OPTIONAL }
-- Firmware Package Unsigned Attributes and Object Identifiers
-ファームウェアパッケージの署名されていない属性とオブジェクト識別子
id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 39 }
WrappedFirmwareKey ::= EnvelopedData
-- Firmware Package Load Receipt Content Type and Object Identifier
-ファームウェアパッケージロードの受信コンテンツタイプとオブジェクト識別子
id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 17 }
FirmwarePackageLoadReceipt ::= SEQUENCE {
version FWReceiptVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
fwPkgName PreferredOrLegacyPackageIdentifier,
trustAnchorKeyID OCTET STRING OPTIONAL,
decryptKeyID [1] OCTET STRING OPTIONAL }
FWReceiptVersion ::= INTEGER { v1(1) }
-- Firmware Package Load Error Report Content Type
-- and Object Identifier
id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 18 }
FirmwarePackageLoadError ::= SEQUENCE {
version FWErrorVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
errorCode FirmwarePackageLoadErrorCode,
vendorErrorCode VendorLoadErrorCode OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
config [1] SEQUENCE OF CurrentFWConfig OPTIONAL }
FWErrorVersion ::= INTEGER { v1(1) }
CurrentFWConfig ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier }
FirmwarePackageLoadErrorCode ::= ENUMERATED {
decodeFailure (1),
badContentInfo (2),
badSignedData (3),
badEncapContent (4),
badCertificate (5),
badSignerInfo (6),
badSignedAttrs (7),
badUnsignedAttrs (8),
missingContent (9),
noTrustAnchor (10),
notAuthorized (11),
badDigestAlgorithm (12),
badSignatureAlgorithm (13),
unsupportedKeySize (14),
signatureFailure (15),
contentTypeMismatch (16),
badEncryptedData (17),
unprotectedAttrsPresent (18),
badEncryptContent (19),
badEncryptAlgorithm (20),
missingCiphertext (21),
noDecryptKey (22),
decryptFailure (23),
badCompressAlgorithm (24),
missingCompressedContent (25),
decompressFailure (26),
wrongHardware (27),
stalePackage (28),
notInCommunity (29),
unsupportedPackageType (30),
missingDependency (31),
wrongDependencyVersion (32),
insufficientMemory (33),
badFirmware (34),
unsupportedParameters (35),
breaksDependency (36),
otherError (99) }
VendorLoadErrorCode ::= INTEGER
-- Other Name syntax for Hardware Module Name
-ハードウェアモジュール名のその他の名前構文
id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) on(8) 4 }
HardwareModuleName ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }
END
終わり
Author's Address
著者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170アメリカ
EMail: housley@vigilsec.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。