RFC4108 日本語訳
4108 Using Cryptographic Message Syntax (CMS) to Protect FirmwarePackages. R. Housley. August 2005. (Format: TXT=142060 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Housley Request for Comments: 4108 Vigil Security Category: Standards Track August 2005
Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4108年の不寝番セキュリティカテゴリ: 標準化過程2005年8月
Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages
ファームウェアパッケージを保護するのに、暗号のメッセージ構文(cm)を使用します。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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.
このドキュメントは、ファームウェアパッケージを保護するためにCryptographic Message Syntax(CMS)の使用について説明します。(パッケージは1つ以上のハードウェアモジュールの部品にオブジェクトコードを供給します)。 CMSはRFC3852で指定されます。 デジタル署名は、非検出された変更からファームウェアパッケージを保護して、データ発生源認証を提供するのに使用されます。 暗号化は公開からファームウェアパッケージを保護するのに任意に使用されます、そして、圧縮は、保護されたファームウェアパッケージのサイズを減少させるのに任意に使用されます。 ファームウェアパッケージのうまくいっているローディングを承諾するために任意にファームウェアパッケージローディング領収書を作ることができます。 同様に、ファームウェアパッケージをロードしないことを伝えるために任意にファームウェアパッケージ負荷エラー・レポートを作ることができます。
Housley Standards Track [Page 1] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[1ページ]RFC4108
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
1. 序論…3 1.1. 用語…5 1.2. 建築Elements…5 1.2.1. ハードウェアモジュール要件…7 1.2.2. ファームウェアパッケージ要件…8 1.2.3. 荷物を積む人要件を独力で進んでください…9 1.2.3.1. レガシーの聞き古したバージョン処理…11 1.2.3.2. 聞き古したバージョン処理を好みます…12 1.2.4. アンカーを信じてください…12 1.2.5. 暗号と圧縮アルゴリズム要件…13 1.3. ハードウェアモジュールセキュリティー体系…14 1.4. ASN.1コード化…14 1.5. ファームウェアパッケージ荷重を保護します…15 2. ファームウェアパッケージ保護…15 2.1. ファームウェアパッケージ保護cm content typeプロフィール…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. 属性であると署名されます…22 2.2.1. content type…23 2.2.2. メッセージダイジェスト…24 2.2.3. ファームウェアパッケージ識別子…24 2.2.4. ハードウェアモジュール識別子を狙ってください…25 2.2.5. 主要な識別子を解読してください…26 2.2.6. 暗号アルゴリズムであると実装されます…26 2.2.7. 圧縮アルゴリズムであると実装されます…27 2.2.8. 共同体識別子…27 2.2.9. ファームウェアパッケージ情報…29 2.2.10. ファームウェアパッケージメッセージダイジェスト…30 2.2.11. 署名時間…30 2.2.12. 内容は暗示します…31 2.2.13. 署名証明書…31 2.3. 未署名の属性…32 2.3.1. ファームウェア復号化キーを包装します…33 3. ファームウェアパッケージ負荷領収書…34 3.1. ファームウェアパッケージ負荷領収書cm content typeプロフィール…36 3.1.1. ContentInfo…36
Housley Standards Track [Page 2] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[2ページ]RFC4108
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
3.1.2. SignedData…36 3.1.2.1. SignerInfo…37 3.1.2.2. EncapsulatedContentInfo…38 3.1.3. FirmwarePackageLoadReceipt…38 3.2. 属性であると署名されます…40 3.2.1. content type…40 3.2.2. メッセージダイジェスト…40 3.2.3. 署名時間…40 4. ファームウェアパッケージ負荷誤り…41 4.1. ファームウェアパッケージ負荷誤りcm content typeプロフィール…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. 属性であると署名されます…49 4.2.1. content type…49 4.2.2. メッセージダイジェスト…49 4.2.3. 署名時間…50 5. ハードウェアモジュール名…50 6. セキュリティ問題…51 6.1. 暗号化キーとアルゴリズム…51 6.2. 乱数発生…51 6.3. ファームウェアパッケージバージョン番号は聞き古したになってください…52 6.4. 共同体識別子…53 7. 参照…54 7.1. 標準の参照…54 7.2. 有益な参照…54 付録A: ASN.1モジュール…56
1. Introduction
1. 序論
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.
このドキュメントは、ファームウェアパッケージを保護するためにCryptographic Message Syntax(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
ファームウェアパッケージはハードウェアモジュールを作る1つ以上のプログラマブルコンポーネントのためのオブジェクトコードを含んでいます。 ファームウェアパッケージ(不透明な2進のオブジェクトとして扱われる)はデジタルに署名されます。 また、任意の暗号化と圧縮はサポートされます。 すべての3が使用されていると、ファームウェアパッケージは、圧縮されて、次に、暗号化されて、署名されます。 圧縮、簡単
Housley Standards Track [Page 3] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[3ページ]RFC4108
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.
より効率的な処理とトランスミッションを許容して、ファームウェアパッケージのサイズを減少させます。 暗号化は公開からファームウェアパッケージを保護します。(それは、不安定なリンクの上に敏感なファームウェアパッケージのトランスミッションを許容します)。 また、非検出された変更からファームウェアパッケージを保護して、使われた暗号化アルゴリズムとモードは保全を提供するかもしれません。 暗号化は独占アルゴリズム、分類されたアルゴリズム、企業秘密、および実装のテクニックを保護します。 デジタル署名は、非検出された変更からファームウェアパッケージを保護して、データ発生源認証を提供します。 デジタル署名で、ハードウェアモジュールは、ファームウェアパッケージが許容できるソースから来ると確認できます。
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]にアクセスできないかもしれません。 したがって、ハードウェアモジュールが唯一信頼アンカー公開鍵でファームウェアパッケージ署名を有効にすることができないで、完全な証明経路合法化を実行できないなら、ハードウェアモジュールにパッケージをロードする前にファームウェア署名者証明経路を有効にするのは、実体がハードウェアモジュールにパッケージをロードする責任です。 この外部の証明書取消し状態の照合が実行される手段はこの仕様の範囲を超えています。
Housley Standards Track [Page 4] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[4ページ]RFC4108
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.
いくつかの場合、ハードウェアモジュールは、特定のファームウェアパッケージのローディングを承諾するために領収書を作ることができます。 どのハードウェアモジュールが、以前のファームウェアパッケージの中の欠点が発見されるときはいつも、アップデートされたファームウェアパッケージを受け取る必要であるかを決定するのにそのような領収書を使用できます。 また、ハードウェアモジュールは、失敗のファームウェアパッケージローディングを示すためにエラー・レポートを作ることができます。 領収書か誤りのどちらかがレポート作成であると実装するために、ハードウェアモジュールがユニークな永久的な通し番号を持つのに必要です。 領収書とエラー・レポートは、署名されるか、または未署名である場合があります。 デジタルに署名している領収書か誤りがレポートであると生成するために、それ自身の個人的な署名キーと対応する署名合法化公開鍵を含む証明書をハードウェアモジュールに支給しなければなりません。 ハードウェアモジュールでメモリを保存するために、ハードウェアモジュールは証明書自体の代わりに証明書指示子を保存するかもしれません。 個人的な署名キーは安全なストレージを必要とします。
1.1. Terminology
1.1. 用語
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]で説明されるようにNOT、REQUIRED、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
1.2. Architectural Elements
1.2. 建築Elements
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
アーキテクチャはハードウェアモジュール、ファームウェアパッケージ、およびブートストラップ・ローダを含んでいます。 ブートストラップ・ローダは、ファームウェアパッケージの上に署名を有効にするために信頼アンカーと呼ばれる1かさらに信じられた公開鍵に近づく手段を持たなければなりません。 署名しているファームウェアパッケージ負荷領収書かエラー・レポートがハードウェアモジュールを代表して作成されるなら、ブートストラップ・ローダは対応する署名合法化証明書かその指示子のための署名と署名者識別子を生成するために主要な個人的な署名に近づく手段を持たなければなりません。 署名合法化証明書は、署名合法化を支援するために含まれるかもしれません。 この任意の能力を実装するために、ハードウェアモジュールにはユニークな通し番号と個人的な署名キーがなければなりません。 また、ハードウェアモジュールはそれが含む証明書を含むかもしれません。
Housley Standards Track [Page 5] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[5ページ]RFC4108
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はこれらの建築要素を例証します。
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で指定されます。
Housley Standards Track [Page 6] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[6ページ]RFC4108
+------------------------------------------------------+
| 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 | |
| +------------------------------------+ |
| |
+------------------------------------------------------+
+------------------------------------------------------+ | ハードウェアモジュール| | | | +---------------+ +--------------------------+ | | | 独力で進んでください。| | ファームウェアパッケージ| | | | 荷物を積む人| | | | | +---------------+ | +------------------+ | | | | : ファームウェアパッケージ: | | | +---------------+ | : そして、識別子、: | | | | 信頼| | : バージョン番号: | | | | アンカー| | +------------------+ | | | +---------------+ | | | | | +-------------+ | | | +---------------+ | : アルゴリズム1: | | | | 連続のヌム。 | | +-+-----------+-+ | | | +---------------+ | : アルゴリズム2: | | | | +-+-----------+-+ | | | +---------------+ | : アルゴリズムn: | | | | ハードウェア| | +-------------+ | | | | モジュールタイプ| | | | | +---------------+ +--------------------------+ | | | | +------------------------------------+ | | | 任意の個人的な署名キー| | | | 署名合法化証明書| | | | または、証明書指示子| | | +------------------------------------+ | | | +------------------------------------------------------+
Figure 1. Architectural Elements
図1。 建築Elements
1.2.1. Hardware Module Requirements
1.2.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
ハードウェアモジュールファミリーSHOULDの中のそれぞれのハードウェアモジュールには、ユニークな永久的な通し番号があります。 しかしながら、任意の領収書か誤りレポート作成能力が実装されるなら、ハードウェアモジュールには、ユニークな永久的な通し番号がなければなりません。 任意の領収書かエラー・レポート署名能力が実装されるなら、ハードウェアモジュールには、対応する公共の署名合法化キーかその指示子を含む個人的な署名キーと証明書がなければなりません。 通し番号がプレゼント、ブートストラップ・ローダ用途であるなら
Housley Standards Track [Page 7] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[7ページ]RFC4108
it for authorization decisions (see Section 2.2.8), receipt generation (see Section 3), and error report generation (see Section 4).
それ、承認決定(セクション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つ以上のファームウェアプログラマブルのコンポーネントを含んでいると、ファームウェアパッケージが有効にされた後にブートストラップ・ローダはハードウェアモジュールの中で適切なコンポーネントにパッケージの部品を分配します。 セクション1.2.3で、より詳しくブートストラップ・ローダについて議論します。
1.2.2. Firmware Package Requirements
1.2.2. ファームウェアパッケージ要件
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ネットワーク・インターフェース・カードのためのファームウェアパッケージは異なったオブジェクト識別子を保証します。 同様に、ファームウェアが暗号アルゴリズムと運転モードの道具そんなに異なったスイートをパッケージするか、またはそれは(非プログラマブルの)異なった暗号装置証明書の異なったオブジェクト識別子を見習います。 バージョン番号はファームウェアパッケージの特定の体格かリリースを特定しなければなりません。 バージョン番号は単調に増加する非負の整数であるに違いありません。 一般に、以前のバージョンを後のものに取り替えます。 悲惨な欠点があるファームウェアパッケージがリリースされるなら、その後のファームウェアパッケージバージョンは、聞き古したバージョンより早く聞き古したバージョンかバージョンにその後のロールバックを防ぐために聞き古したバージョン番号を指定するかもしれません。
Housley Standards Track [Page 8] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[8ページ]RFC4108
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.
多くの場合、ファームウェアパッケージ署名は直接信頼アンカー公開鍵で有効にされるでしょう、証明経路を構成する必要性を避けて。 あるいはまた、信頼アンカーは証明経路を通してファームウェアパッケージ署名を別の公開鍵へ代表として派遣することができます。 後者の場合では、ファームウェアパッケージSHOULDは証明書が信頼アンカーによって発行されている状態で始まって、ファームウェアパッケージ署名者に証明書を発行している状態で終わる証明経路を構成するのが必要である証明書を含んでいます。
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.
ファームウェアパッケージは共同体識別子のリストを含むかもしれません。 これらの識別子はファームウェアパッケージをロードするのが認可されるモジュールとハードウェアを命名します。 ブートストラップ・ローダはファームウェアパッケージが共同体識別子のリストを含んでいて、ハードウェアモジュールが特定された共同体の1つのメンバーでないならファームウェアパッケージを拒絶しなければなりません。
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はコンポーネントのすべてのための実行コードを含んでいます。 ファームウェアパッケージの中の内部のタグ付けは、総合的なファームウェアパッケージのどの一部が各コンポーネントのために意図するかをブートストラップ・ローダに言わなければなりません。 しかしながら、具体的に言うと、このタグ付けはそれぞれのハードウェアモジュールに予想されます。 この仕様が不透明な2進のオブジェクトとしてファームウェアパッケージを扱うのが、この仕様の範囲を超えたファームウェアパッケージの形式の理由です。
1.2.3. Bootstrap Loader Requirements
1.2.3. ブートストラップ・ローダ要件
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
ファームウェアパッケージでブートストラップ・ローダを積み込むことができるなら、展開の前に初期のブートストラップ・ローダを非揮発性メモリーにインストールしなければなりません。 イニシャルを含むすべてのブートストラップ・ローダ
Housley Standards Track [Page 9] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[9ページ]RFC4108
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]のひとりに有効な証明経路の工事を必要とするかもしれない)を有効にすることができないなら、ブートストラップ・ローダはファームウェアパッケージを拒絶しなければなりません。 しかしながら、多くの場合、ファームウェアパッケージ署名は直接信頼アンカー公開鍵で有効にされるでしょう、証明経路を構成する必要性を避けて。
Housley Standards Track [Page 10] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[10ページ]RFC4108
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.
ファームウェアパッケージが共同体識別子のリストを含んでいるなら、ブートストラップ・ローダはファームウェアパッケージを拒絶しなければなりません、そして、ハードウェアモジュールは記載された共同体の1つのメンバーではありません。 共同体会員資格を決定する手段はこの仕様の範囲を超えています。
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がロードするのを防ぐ聞き古したバージョンと聞き古したバージョンより初期のバージョンのブートストラップ・ローダを指定します。
1.2.3.1. Legacy Stale Version Processing
1.2.3.1. レガシーの聞き古したバージョン処理
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.
悲惨な欠点があるファームウェアパッケージがリリースされるといけないので、形成というレガシーファームウェアパッケージ名を使うその後のファームウェアパッケージバージョンは聞き古したバージョンより早く聞き古したバージョンかバージョンにその後のロールバックを防ぐために聞き古したレガシーファームウェアパッケージ名を含むかもしれません。 このドキュメントのSecurity Considerations部で説明されるように、ファームウェアパッケージにおける聞き古したレガシーファームウェアパッケージ名の包含は完全に聞き古したファームウェアパッケージのその後の使用を防ぐことができるというわけではありません。 しかしながら、多くのハードウェアモジュールにはそれらのために書かれたほんのわずかなファームウェアパッケージがあると予想されます、重要な保護を提供する聞き古したファームウェアパッケージバージョン機能を許容して。
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
聞き古したバージョン番号のための非揮発性記憶装置が必要です。 保存できる聞き古したレガシーファームウェアパッケージ名の数は利用可能なストレージの量に依存します。 聞き古したレガシーファームウェアパッケージ名を含んでいて、次に、それはSHOULDです。リストの閉じ込められた非揮発性記憶装置に追加されてください。 その後のファームウェアであるときに、パッケージはロードされていて、レガシーファームウェアはパッケージです。
Housley Standards Track [Page 11] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[11ページ]RFC4108
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.
レガシーファームウェアパッケージ名と聞き古したレガシーファームウェアパッケージが名前であると保存するのに捧げられる必要がある非揮発性記憶装置の量はハードウェアモジュールのために開発されそうなファームウェアパッケージの数に依存します。
1.2.3.2. Preferred Stale Version Processing
1.2.3.2. 都合のよい聞き古したバージョン処理
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.
悲惨な欠点があるファームウェアパッケージがリリースされるなら、都合のよいファームウェアパッケージ名前フォームを使うその後のファームウェアパッケージバージョンは、聞き古したバージョンより早く聞き古したバージョンかバージョンにその後のロールバックを防ぐために聞き古したバージョン番号を含むかもしれません。 このドキュメントのSecurity Considerations部で説明されるように、ファームウェアパッケージにおける聞き古したバージョン番号の包含は完全に聞き古したファームウェアパッケージのその後の使用を防ぐことができるというわけではありません。 しかしながら、多くのハードウェアモジュールにはそれらのために書かれたほんのわずかなファームウェアパッケージがあると予想されます、重要な保護を提供する聞き古したファームウェアパッケージバージョン機能を許容して。
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.
ファームウェアパッケージ識別子と聞き古したバージョン番号を保存するのに捧げられる必要がある非揮発性記憶装置の量はハードウェアモジュールのために開発されそうなファームウェアパッケージの数に依存します。
1.2.4. Trust Anchors
1.2.4. 信頼アンカー
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.
信頼アンカーは公開鍵署名アルゴリズムと関連公開鍵から成らなければなりません。(任意に、それは、パラメタを含むかもしれません)。 また、信頼アンカーは公開鍵識別子を入れなければなりません。 また、信頼アンカーはX.500分類名を入れるかもしれません。
Housley Standards Track [Page 12] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[12ページ]RFC4108
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つの異なった方法で署名合法化アルゴリズムに関連して使用されます。 まず最初に、信頼アンカー公開鍵は、ファームウェアパッケージ署名を有効にするのに直接使用されます。 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.500分類名は、信頼アンカー公開鍵がX.509証明経路を有効にするのに使用されるために存在していなければなりません。 X.500分類名がなければ、証明経路工事は信頼アンカーを使用できません。
1.2.5. Cryptographic and Compression Algorithm Requirements
1.2.5. 暗号と圧縮アルゴリズム要件
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、また、暗号のモジュールを質問できて、各アルゴリズムに関連している属性を決定してください。 そのような属性は非対称のアルゴリズムのためのアルゴリズムタイプ(左右対称の暗号化、非対称の暗号化、主要な協定、一方向ハッシュ関数、デジタル署名など)かアルゴリズムブロック・サイズか係数サイズと、パラメタを含むかもしれません。この仕様はアルゴリズム識別子かアルゴリズム属性の検索のためにコンベンションを設立しません。
Housley Standards Track [Page 13] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[13ページ]RFC4108
1.3. Hardware Module Security Architecture
1.3. ハードウェアモジュールセキュリティー体系
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.
ほとんどのハードウェアモジュールデザインでは、ファームウェアパッケージ実行環境はただ一つのアドレス空間を提供します。 そうするなら、ファームウェアパッケージSHOULDはハードウェアモジュールのための完全なファームウェアパッケージ負荷を含んでいます。 この状況で、ファームウェアパッケージは部分的であるか増加の関数群を入れてあません。 完全なファームウェアパッケージ負荷は、複雑さを最小にして、潜在的警備上の問題を避けるでしょう。パッケージの増加のローディングで複雑さ見解から、各パッケージが必要であるいかなる他のパッケージ(依存)も特定するのが必要になります、そして、ブートストラップ・ローダは依存のすべてがファームウェアパッケージを実行するのを試みる前に満足していることを確かめる必要があります。 ハードウェアモジュールがメインプロセッサかディジタル信号プロセッサに基づいているとき、コードの独立している部分がお互いを妨げることができないのを保証するために参照モニターがない場合、任意のパッケージが同時にロードされるのを許容するのは危険です。 また、ソフトウェア・モジュール[SECREQMTS]の任意の組み合わせを評価するのも難しいです。 これらの理由で、完全なファームウェアパッケージ負荷はRECOMMENDEDです。 しかしながら、この仕様で、ファームウェア署名者は、すべての状況を扱うためにファームウェアパッケージの間の依存を特定できます。
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.
ファームウェアパッケージをロードすると、既にハードウェアモジュール構成の一部である他のファームウェアパッケージの依存の満足のいく解決に影響を与えることができます。 この理由で、結果として起こる構成における、どんなファームウェアパッケージの依存も満たされていなくなるなら、ブートストラップ・ローダはファームウェアパッケージのローディングを拒絶しなければなりません。
1.4. ASN.1 Encoding
1.4. ASN.1コード化
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
CMSは抽象的なSyntax Notation One(ASN.1)[X.208-88、X.209-88]を使用します。 ASN.1は実装によって使用されるプログラミング言語にかかわらずデータプロトコルについて説明するのに使用される正式な記法です。 符号化規則は値がどうコネを定義したかを説明します。
Housley Standards Track [Page 14] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[14ページ]RFC4108
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.
ASN.1はトランスミッションのために表されるでしょう。 Basic Encoding Rules(BER)は最も広く使われた規則セットですが、彼らはデータ構造を表す1つ以上の方法を提供します。 例えば、明確な長さのコード化していて無期の長さのコード化はサポートされます。 デジタル署名が使用されているとき、この柔軟性は望ましくはありません。 その結果、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を必要としませんが、明確な長さのコード化の使用が強く必要です。RECOMMENDED。 いつも明確な長さのコード化を使用することによって、ブートストラップ・ローダには、実装するより少ないオプションがあるでしょう。 明確な長さのコード化だけが使用されるという非常に高い信用がある状況で、無期長さの解読のサポートは省略されるかもしれません。
1.5. Protected Firmware Package Loading
1.5. 保護されたファームウェアパッケージ荷重
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.
このドキュメントは、ローディングファームウェアパッケージに必要な物理インターフェース、どんな関連するドライバソフトウェア、またはプロトコルも指定するのを試みません。 携帯用のメモリ素子、ファイル転送、およびウェブページを含んでいて、多くの異なった排紙機構が思い描かれます。 この仕様のセクション2は使用されたインタフェースにかかわらずハードウェアモジュールに提示しなければならない書式を定義します。 また、この仕様はハードウェアモジュールで生成されるかもしれない応答の形式を指定します。 この仕様のセクション3はファームウェアパッケージが首尾よくロードされるときハードウェアモジュールで返されるかもしれない書式を定義します。 この仕様のセクション4はファームウェアパッケージ負荷が失敗しているときハードウェアモジュールで返されるかもしれない書式を定義します。 ファームウェアパッケージ負荷領収書とファームウェアパッケージ負荷エラー・レポートは、署名されるか、または未署名である場合があります。
2. Firmware Package Protection
2. ファームウェアパッケージ保護
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
Cryptographic Message Syntax(CMS)は、ファームウェアパッケージを保護するのに使用されます。(パッケージは不透明な2進のオブジェクトとして扱われます)。 デジタル署名は、非検出された変更からファームウェアパッケージを保護して、データ発生源認証を提供するのに使用されます。 暗号化は公開からファームウェアパッケージを保護するのに任意に使用されます、そして、圧縮は、保護されたファームウェアパッケージのサイズを減少させるのに任意に使用されます。 CMS ContentInfo content typeはいつも存在していなければなりません、そして、それはCMS SignedData content typeをカプセル化しなければなりません。 ファームウェアパッケージが暗号化されているなら、CMS SignedData content typeはCMS EncryptedData content typeをカプセル化しなければなりません。 ファームウェアであるなら、パッケージは圧縮されて、次に、どちらかがCMS SignedDataです。
Housley Standards Track [Page 15] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[15ページ]RFC4108
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).
content type(暗号化が使用されていないとき)かCMS EncryptedData content type(暗号化が使用されているとき)がCMS CompressedData content typeをカプセル化しなければなりません。 (1) 最終的に、この仕様に基づき定義されたFirmwarePkgData content typeを使用して、CMS SignedData content type(暗号化も圧縮も使用されていないとき)、(2) CMS EncryptedData content type(暗号化が使用されていて、圧縮しかないということであるときに)、または(3) CMS CompressedData content type(圧縮が使用されているとき)が簡単なファームウェアパッケージをカプセル化しなければなりません(セクション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
}
ContentInfocontentTypeイド-signedData--、(1.2.840.113549.1.7.2)内容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
}
SignedDataバージョンCMSVersion--いつも署名者本命経路crls CertificateRevocationLists--任意のsignerInfos SET OF SignerInfo--1つだけを3digestAlgorithms DigestAlgorithmIdentifiers(1encapContentInfo EncapsulatedContentInfoだけ、証明書CertificateSet)に設定してください。
SignerInfo {
version CMSVersion, -- always set to 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Optional
}
SignerInfo{バージョンCMSVersion(いつも3sid SignerIdentifier、digestAlgorithm DigestAlgorithmIdentifier、signedAttrs SignedAttributesに設定される)はsignatureAlgorithm SignatureAlgorithmIdentifierを必要としました、署名SignatureValue、unsignedAttrs UnsignedAttributes--任意}です。
Housley Standards Track [Page 16] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[16ページ]RFC4108
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
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
}
EncryptedDataCMSVersion(いつも0encryptedContentInfo EncryptedContentInfo、unprotectedAttrs UnprotectedAttributesに設定される)が省略するバージョン
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
EncryptedContentInfo、contentType、イドct compressedData、--、(1.2、.840、.113549、.1、.9、.16、.1、.9(OR)、)イドct firmwarePackage、--、(1.2 .840 .113549 .1 .9 .16 .1 .16) contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier、encryptedContent八重奏ストリング、--CompressedData ORを含んでいます--、FirmwarePkgData
CompressedData {
version CMSVersion, -- Always set to 0
compressionAlgorithm CompressionAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo
}
CompressedDataバージョンCMSVersion--いつも0compressionAlgorithm CompressionAlgorithmIdentifier、encapContentInfo EncapsulatedContentInfoにセットしてください。
EncapsulatedContentInfo {
eContentType id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
eContent OCTET STRING -- Contains FirmwarePkgData
}
EncapsulatedContentInfoeContentType、イドct firmwarePackage、--、(1.2 .840 .113549 .1 .9 .16 .1 .16) eContent八重奏ストリング--、FirmwarePkgDataを含んでいます。
FirmwarePkgData OCTET STRING -- Contains firmware package
FirmwarePkgData OCTET STRING--、ファームウェアパッケージを含んでいます。
Housley Standards Track [Page 17] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[17ページ]RFC4108
2.1. Firmware Package Protection CMS Content Type Profile
2.1. ファームウェアパッケージ保護cm content typeプロフィール
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 content typeを使用するのにコンベンションを指定します。 また、それはFirmwarePkgData content typeを定義します。
2.1.1. ContentInfo
2.1.1. ContentInfo
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です。 イド-signedData、(1.2 .840 .113549 .1 .7 .2) オブジェクト識別子はこの分野に存在していなければなりません。
content holds the associated content, and in this case, the
content field MUST contain SignedData.
内容は関連内容を保持します、そして、この場合、満足している分野はSignedDataを含まなければなりません。
2.1.2. SignedData
2.1.2. 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 content type[CMS]は署名しているファームウェアパッケージ(署名の前に圧縮されるか、暗号化されるか、圧縮されて、または次に、暗号化されるかもしれない)、署名を有効にするのが必要である証明書、および1つのデジタル署名値を含んでいます。 SignedDataの分野は以下の通り使用されます:
version is the syntax version number, and in this case, it MUST be
set to 3.
バージョンは構文バージョン番号です、そして、この場合、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.
content type識別子と内容自体から成って、encapContentInfoは署名している内容を含んでいます。 セクション2.1.2で、より詳しく.2にEncapsulatedContentInfoタイプの使用について議論します。
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
証明書は証明書の任意の収集です。 アンカーは信頼であるなら直接ファームウェアパッケージに署名して、次に、証明書はSHOULDです。省略されます。 そうしなかったなら、証明書SHOULDはファームウェアパッケージ署名者のX.509証明書を含んでいます。 セット、証明書SHOULDでは、ブートストラップ・ローダが信頼アンカーからファームウェア署名者の証明書まで証明経路を構成するには、十分であってください。 PKCS#6通の拡張証明書
Housley Standards Track [Page 18] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[18ページ]RFC4108
[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は証明書失効リスト(CRLs)の任意の収集と、この場合、CRLs SHOULDです。ファームウェアパッケージ署名者で、含まれていません。 ハードウェアモジュールにダウンロードするために倉庫でファームウェアパッケージに生成して、署名して、利用可能にするかもしれないと予期されます。 そのような文脈では、ファームウェアパッケージ署名者がファームウェアパッケージにタイムリーなCRLsを含んでいるのは、難しいでしょう。 しかしながら、CRLsが署名でカバーされていないので、ファームウェアパッケージがハードウェアモジュールに提供される前に、タイムリーなCRLsはある他のパーティーによって挿入されるかもしれません。
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署名者あたりの情報の収集です、そして、この場合、収集はちょうど1SignerInfoを含まなければなりません。 セクション2.1.2で、より詳しく.1にSignerInfoタイプの使用について議論します。
2.1.2.1. SignerInfo
2.1.2.1. SignerInfo
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.
バージョンは構文バージョン番号です、そして、それは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は2つの選択肢をサポートします: issuerAndSerialNumberとsubjectKeyIdentifier。 しかしながら、ブートストラップ・ローダはsubjectKeyIdentifier代替手段をサポートしなければなりません。(それは、直接署名者の公開鍵を特定します)。 この公開鍵が証明書に含まれているとき、この識別子SHOULDはX.509 subjectKeyIdentifier拡張子に現れます。
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
signedAttrsは内容と共に署名される属性の任意の収集です。 signedAttrsはCMSで任意ですが、この仕様では、signedAttrsはファームウェアパッケージのためのREQUIREDです。 しかしながら、実装は認識されていない署名している属性を無視しなければなりません。 SET OF属性はDERであるに違いありません。
Housley Standards Track [Page 19] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[19ページ]RFC4108
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.
[X.509-88]をコード化しました。 このドキュメントのセクション2.2は収集に含まなければならない属性を記載します。 また、他の属性は含まれるかもしれません。
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.
署名はデジタル署名値です。
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で説明されるように、このセットは包装されたファームウェア復号化キー属性にもかかわらず、他のものがないただ一つのインスタンスを含むことができるだけです。
2.1.2.2. EncapsulatedContentInfo
2.1.2.2. EncapsulatedContentInfo
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 content typeはファームウェアパッケージをカプセル化します。(それは、署名の前に圧縮されるか、暗号化されるか、圧縮されて、または次に、暗号化されるかもしれません)。 これらの形式のいずれではも、ファームウェアパッケージは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が唯一content typeを指定するオブジェクト識別子であり、この場合値がイド-encryptedDataでなければならない、(1.2 .840 .113549 .1 .7 .6、)イドct compressedData、(1.2 .840 .113549 .1 .9 .16 .1 .9、)イドct firmwarePackage、(1.2 .840 .113549 .1 .9 .16 .1 .16)。 eContentTypeがイドencryptedDataを含むとき、ファームウェアパッケージは、署名の前に暗号化されて、また、暗号化の前に圧縮されたかもしれません。 それが含むいつ、イドct compressedData、ファームウェアパッケージは、署名の前に圧縮されましたが、暗号化されなかったか。 それが含むいつ、イド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である必要はありません。
2.1.3. EncryptedData
2.1.3. EncryptedData
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:
EncryptedData content type[CMS]は暗号化されたファームウェアパッケージ(暗号化の前に圧縮されるかもしれない)を含んでいます。 しかしながら、ファームウェアパッケージが暗号化されなかったなら、EncryptedData content typeは存在していません。 EncryptedDataの分野は以下の通り使用されます:
Housley Standards Track [Page 20] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[20ページ]RFC4108
version is the syntax version number, and in this case, version MUST
be 0.
バージョンは構文バージョン番号です、そして、この場合、バージョンは0であるに違いありません。
encryptedContentInfo is the encrypted content information. The use
of the EncryptedContentInfo type is discussed further in Section
2.1.3.1.
encryptedContentInfoは暗号化された満足している情報です。 セクション2.1.3で、より詳しく.1にEncryptedContentInfoタイプの使用について議論します。
unprotectedAttrs is an optional collection of unencrypted attributes,
and in this case, unprotectedAttrs MUST NOT be present.
unprotectedAttrsは非暗号化された属性の任意の収集です、そして、この場合、unprotectedAttrsは存在しているはずがありません。
2.1.3.1. EncryptedContentInfo
2.1.3.1. EncryptedContentInfo
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が内容のタイプを示して、この場合どちらかを含まなければならない、イドct compressedData、(1.2、.840、.113549、.1、.9、.16、.1、.9、)、イドct firmwarePackage、(1.2 .840 .113549 .1 .9 .16 .1 .16)。 それが含むいつ、イドct compressedData、そして、ファームウェアパッケージは暗号化の前に圧縮されたか。 -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はファームウェアパッケージを暗号化するという結果です。 分野は任意です。 しかしながら、この場合、それは存在していなければなりません。
2.1.4. CompressedData
2.1.4. CompressedData
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 content type[COMPRESS]は圧縮されたファームウェアパッケージを含んでいます。 ファームウェアパッケージが圧縮されなかったなら、CompressedData content typeは存在していません。 CompressedDataの分野は以下の通り使用されます:
version is the syntax version number; in this case, it MUST be 0.
バージョンは構文バージョン番号です。 この場合、それは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は圧縮された内容と、content type識別子から成って、内容自体です。 セクション2.1.4で、より詳しく.1にEncapsulatedContentInfoタイプの使用について議論します。
Housley Standards Track [Page 21] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[21ページ]RFC4108
2.1.4.1. EncapsulatedContentInfo
2.1.4.1. EncapsulatedContentInfo
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 content typeは圧縮されたファームウェアパッケージをカプセル化します、そして、それは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が唯一content typeを指定するオブジェクト識別子であり、この場合それがイド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である必要はありません。
2.1.5. FirmwarePkgData
2.1.5. FirmwarePkgData
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 content typeはファームウェアパッケージを含んでいます。 それは八重奏ストリングの簡単なカプセル化です、そして、コード化されたDERである必要はありません。
The FirmwarePkgData content type is identified by the id-ct- firmwarePackage object identifier:
FirmwarePkgData content typeが-イドによって特定されて、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 }
イドct firmwarePackage、オブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)ct(1)16をメンバーと同じくらい具体化させます。
The FirmwarePkgData content type is a simple octet string:
FirmwarePkgData content typeは簡単な八重奏ストリングです:
FirmwarePkgData ::= OCTET STRING
FirmwarePkgData:、:= 八重奏ストリング
2.2. Signed Attributes
2.2. 属性であると署名されます。
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 }
以下を結果と考えてください:= 系列attrTypeオブジェクト識別子、AttributeValueのattrValuesセット
AttributeValue ::= ANY
AttributeValue:、:= 少しも
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つのインスタンスがまさにあるに違いありません。
Housley Standards Track [Page 22] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[22ページ]RFC4108
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つの属性を含まなければなりません: content type、メッセージダイジェスト、ファームウェアパッケージ識別子、および目標ハードウェアモジュール識別子。
If the firmware package is encrypted, then the firmware package signer MUST also include the decrypt-key-identifier attribute.
また、ファームウェアパッケージが暗号化されているなら、ファームウェアパッケージ署名者は主要な識別子を解読している属性を含まなければなりません。
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.
また、ファームウェアパッケージが暗号アルゴリズムを実装するなら、ファームウェアパッケージ署名者は実装している暗号のアルゴリズムの属性を含むかもしれません。 また、同様に、ファームウェアパッケージが、圧縮がアルゴリズムであると実装するなら、ファームウェアパッケージ署名者は実装している湿布アルゴリズム属性を含むかもしれません。
If the firmware package is intended for use only by specific communities, then the firmware package signer MUST also include the community-identifiers attribute.
また、ファームウェアパッケージが使用のために単に特定の共同体によって意図されるなら、ファームウェアパッケージ署名者は共同体識別子属性を含まなければなりません。
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個以上のファームウェアパッケージの存在によるなら、ファームウェアパッケージ署名者SHOULDはファームウェアパッケージインフォメーション属性を含んでいます。 例えば、ファームウェアパッケージインフォメーション属性依存分野は、ファームウェアパッケージが特定のブートストラップ・ローダか分離カーネルに依存を含むのを示すかもしれません。
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.
また、ファームウェアパッケージ署名者SHOULDは3つの次の属性を含んでいます: ファームウェアパッケージメッセージダイジェスト、署名時間、および満足しているヒント。 また、さらに、ファームウェアパッケージ署名者に証明書(ファームウェアパッケージ署名者が信頼アンカーとしていつも構成されるというわけではないことを意味する)があるなら、ファームウェアパッケージ署名者SHOULDは署名証明書属性を含んでいます。
The firmware package signer MAY include any other attribute that it deems appropriate.
ファームウェアパッケージ署名者はそれが適切であると考えるいかなる他の属性も含むかもしれません。
2.2.1. Content Type
2.2.1. content type
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
または、ファームウェアパッケージ署名者がイド-encryptedDataの値があるcontent type属性を含まなければならない、(1.2、.840、.113549、.1、.7、.6、)イドct-compressedData、(1.2 .840 .113549 .1 .9 .16 .1 .9、)イドct firmwarePackage、(1.2 .840 .113549 .1 .9 .16 .1 .16)。 イド-encryptedDataを含むとき、ファームウェアパッケージは署名の前に暗号化されました。 それが含むいつ、イドct compressedData、ファームウェアパッケージは、署名の前に圧縮されましたが、暗号化されなかったか。 それが含むいつ
Housley Standards Track [Page 23] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[23ページ]RFC4108
id-ct-firmwarePackage, the firmware package was not compressed or encrypted prior to signing. Section 11.1 of [CMS] defines the content-type attribute.
イドct firmwarePackage、ファームウェアパッケージは、署名の前に圧縮もされませんでしたし、暗号化もされませんでした。 [CMS]のセクション11.1はcontent type属性を定義します。
2.2.2. Message Digest
2.2.2. メッセージダイジェスト
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.
ファームウェアパッケージ署名者はメッセージダイジェスト属性を含まなければなりません、値としてencapContentInfo eContent八重奏ストリングの上に計算されたメッセージダイジェストを持っていて、セクション2.1.2で.2に定義されるように この八重奏ストリングがファームウェアパッケージを含んでいて、それは、圧縮されるか、暗号化されるか、圧縮されて、または暗号化されるかもしれません。 [CMS]のセクション11.2はメッセージダイジェスト属性を定義します。
2.2.3. Firmware Package Identifier
2.2.3. ファームウェアパッケージ識別子
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.
ファームウェアパッケージ識別子属性は保護されたファームウェアパッケージを命名します。 ファームウェアパッケージを命名することへの2つのアプローチがサポートされます: レガシー..都合のよい これらの名前フォームの1つを使用して、ファームウェアパッケージ署名者はファームウェアパッケージ識別子属性を含まなければなりません。
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.
都合のよいファームウェアパッケージ名はオブジェクト識別子とバージョン番号の組み合わせです。 オブジェクト識別子はファームウェアパッケージによって実装された機能の収集を命名します、そして、バージョン番号はファームウェアパッケージの特定の体格かリリースを特定する非負の整数です。
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は聞き古したバージョンより早く聞き古したバージョンかバージョンにその後のロールバックを防ぎます。 形成というレガシーファームウェアパッケージ名が使用されているとき、聞き古したバージョンは聞き古したレガシーファームウェアパッケージ名によって示されます。(それは、八重奏ストリングです)。 私たちは、ファームウェアパッケージ署名者とブートストラップ・ローダが、与えられたレガシーファームウェアパッケージ名が聞き古したものより最近のバージョンを表すかどうか決定できると思います。 形成という都合のよいファームウェアパッケージ名が使用されているとき、聞き古したバージョンは聞き古したバージョン番号によって示されます。(それは、整数です)。
Housley Standards Track [Page 24] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[24ページ]RFC4108
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 }
イド-aa-firmwarePackageIDオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2)35をメンバーと同じくらい具体化させます。
The firmware-package-identifier attribute values have ASN.1 type FirmwarePackageIdentifier:
ファームウェアパッケージ識別子属性値で、ASN.1はFirmwarePackageIdentifierをタイプします:
FirmwarePackageIdentifier ::= SEQUENCE {
name PreferredOrLegacyPackageIdentifier,
stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
FirmwarePackageIdentifier:、:= 系列名前PreferredOrLegacyPackageIdentifier、聞き古したPreferredOrLegacyStalePackageIdentifier OPTIONAL
PreferredOrLegacyPackageIdentifier ::= CHOICE {
preferred PreferredPackageIdentifier,
legacy OCTET STRING }
PreferredOrLegacyPackageIdentifier:、:= 選択都合のよいPreferredPackageIdentifier、レガシーOCTET STRING
PreferredPackageIdentifier ::= SEQUENCE {
fwPkgID OBJECT IDENTIFIER,
verNum INTEGER (0..MAX) }
PreferredPackageIdentifier:、:= 系列fwPkgIDオブジェクト識別子、verNum整数(0..MAX)
PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
preferredStaleVerNum INTEGER (0..MAX),
legacyStaleVersion OCTET STRING }
PreferredOrLegacyStalePackageIdentifier:、:= 選択preferredStaleVerNum整数(0..MAX)、legacyStaleVersion八重奏ストリング
2.2.4. Target Hardware Module Identifiers
2.2.4. 目標ハードウェアモジュール識別子
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.
目標ハードウェアモジュール識別子属性はファームウェアパッケージがサポートするハードウェアモジュールのタイプを命名します。 ユニークなオブジェクト識別子はハードウェアモデルタイプと改正であるとサポートされたそれぞれを命名します。
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.
それ自身のハードウェアモジュールタイプ識別子が目標ハードウェアモジュール識別子属性でリストアップされないなら、ブートストラップ・ローダはファームウェアパッケージを拒絶しなければなりません。
The following object identifier identifies the target-hardware- module-identifiers attribute:
以下のオブジェクト識別子は目標ハードウェアを特定します。-モジュール識別子は以下を結果と考えます。
id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 36 }
イド-aa-targetHardwareIDsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2)36をメンバーと同じくらい具体化させます。
The target-hardware-module-identifiers attribute values have ASN.1 type TargetHardwareIdentifiers:
目標ハードウェアモジュール識別子属性値で、ASN.1はTargetHardwareIdentifiersをタイプします:
TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
TargetHardwareIdentifiers:、:= オブジェクト識別子の系列
Housley Standards Track [Page 25] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[25ページ]RFC4108
2.2.5. Decrypt Key Identifier
2.2.5. 主要な識別子を解読してください。
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.
主要な識別子を解読している属性はカプセル化されたファームウェアパッケージを解読するのに必要である対称鍵を命名します。 ファームウェアパッケージが暗号化されているとき、CMS EncryptedData content typeは使用されています。 主要な識別子を解読している署名している属性はEncryptedDataがcontent typeであるとカプセル化するSignedData content typeで運ばれます、ファームウェアパッケージを解読するのに必要である対称鍵を命名して。 どんな特定の構造も主要な識別子に課されません。 ファームウェア復号化キーがしっかりと関連ファームウェアパッケージを使用するのが認可されるすべてのモジュールに分配される手段はこの仕様の範囲を超えています。 しかしながら、しっかりとファームウェアパッケージによって主要なファームウェア復号化を分配するための任意のメカニズムはセクション2.3.1で指定されます。
The following object identifier identifies the decrypt-key-identifier attribute:
以下のオブジェクト識別子は主要な識別子を解読している属性を特定します:
id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 37 }
イド-aa-decryptKeyIDオブジェクト識別子:、:= iso(1)は(2) 私たち(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
DecryptKeyIdentifier:、:= 八重奏ストリング
2.2.6. Implemented Crypto Algorithms
2.2.6. 暗号アルゴリズムであると実装されます。
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.
実装している暗号アルゴリズム属性は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のオブジェクト識別子部分はアルゴリズムとその使用の方法を特定します。 どんなアルゴリズムパラメタも含まれていません。 暗号アルゴリズムインクルードトラフィック暗号化アルゴリズム、暗号化アルゴリズムを合わせてください、主要な輸送アルゴリズム、主要な協定アルゴリズム、一方向ハッシュアルゴリズム、そして、デジタル署名アルゴリズム暗号アルゴリズムは圧縮アルゴリズムを含んでいません。
Housley Standards Track [Page 26] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[26ページ]RFC4108
The following object identifier identifies the implemented-crypto- algorithms attribute:
以下のオブジェクト識別子は実装している暗号のアルゴリズムの属性を特定します:
id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 38 }
イド-aa-implCryptoAlgsオブジェクト識別子:、:= iso(1)は(2) 私たち(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
ImplementedCryptoAlgorithms:、:= オブジェクト識別子の系列
2.2.7. Implemented Compression Algorithms
2.2.7. 圧縮アルゴリズムであると実装されます。
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.
実装している湿布アルゴリズム属性は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:
以下のオブジェクト識別子は実装している湿布しているアルゴリズムの属性を特定します:
id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 43 }
イド-aa-implCompressAlgsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2)43をメンバーと同じくらい具体化させます。
The implemented-compress-algorithms attribute values have ASN.1 type ImplementedCompressAlgorithms:
実装している湿布アルゴリズム属性値で、ASN.1はImplementedCompressAlgorithmsをタイプします:
ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
ImplementedCompressAlgorithms:、:= オブジェクト識別子の系列
2.2.8. Community Identifiers
2.2.8. 共同体識別子
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に存在しているなら、共同体識別子属性はファームウェアパッケージを実行することが許可されている共同体を命名します。 ブートストラップ・ローダはハードウェアモジュールが特定された共同体の1つのメンバーでないならファームウェアパッケージを拒絶しなければなりません。 共同体会員資格を割り当てる手段はこの仕様の範囲を超えています。
Housley Standards Track [Page 27] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[27ページ]RFC4108
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.
共同体識別子属性は共同体オブジェクト識別子のリスト、特定のハードウェアモジュールのリスト、または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:
以下のオブジェクト識別子は共同体識別子属性を特定します:
id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 40 }
イド-aa-communityIdentifiersオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2)40をメンバーと同じくらい具体化させます。
The community-identifiers attribute values have ASN.1 type CommunityIdentifiers:
共同体識別子属性値で、ASN.1はCommunityIdentifiersをタイプします:
CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
CommunityIdentifiers:、:= CommunityIdentifierの系列
CommunityIdentifier ::= CHOICE {
communityOID OBJECT IDENTIFIER,
hwModuleList HardwareModules }
CommunityIdentifier:、:= 選択communityOIDオブジェクト識別子、hwModuleList HardwareModules
HardwareModules ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialEntries SEQUENCE OF HardwareSerialEntry }
HardwareModules:、:= 系列hwTypeオブジェクト識別子、HardwareSerialEntryのhwSerialEntries系列
HardwareSerialEntry ::= CHOICE {
all NULL,
single OCTET STRING,
block SEQUENCE {
low OCTET STRING,
high OCTET STRING } }
HardwareSerialEntry:、:= 選択すべてのNULL(独身のOCTET STRING)がSEQUENCEを妨げる、低いOCTET STRING、高いOCTET STRING
Housley Standards Track [Page 28] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[28ページ]RFC4108
2.2.9. Firmware Package Information
2.2.9. ファームウェアパッケージ情報
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.
ハードウェアモジュールが1つ以上のタイプのファームウェアパッケージを支えるなら、ファームウェアパッケージ署名者SHOULDは、ファームウェアパッケージ型式を特定するために居住されたfwPkgType分野があるファームウェアパッケージインフォメーション属性を含んでいます。 この値はハードウェアモジュールの中でファームウェアパッケージの正しいプレースメントでブートストラップ・ローダを支援できます。 ファームウェアパッケージ型式は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個のファームウェアパッケージが別のものによって提供されたルーチンを使用することを許可します。 また、ファームウェアパッケージが別のものに依存を含んでいるなら、ファームウェアパッケージ署名者SHOULDは居住された依存分野があるファームウェアパッケージインフォメーション属性を含んでいます。 ファームウェアパッケージがいかなる他のファームウェアパッケージにもよらないなら、ファームウェアパッケージ署名者は居住された依存分野があるファームウェアパッケージインフォメーション属性を含んではいけません。
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つのアプローチがサポートされます: レガシー..都合のよい 形成というレガシーファームウェアパッケージ名が使用されているとき、依存はレガシーファームウェアパッケージ名によって示されます。 私たちは、ファームウェアパッケージ署名者とブートストラップ・ローダが、与えられたレガシーファームウェアパッケージ名が許容できるより新しいバージョンの命名されたバージョンを表すかどうか決定できると思います。 形成という都合のよいファームウェアパッケージ名が使用されているとき、オブジェクト識別子と整数を提供します。 オブジェクト識別子はまさに既にロードされるファームウェアパッケージに関連している都合のよいファームウェアパッケージ名のオブジェクト識別子部分に合わなければなりません、そして、整数は同じファームウェアパッケージに関連している都合のよいファームウェアパッケージ名の整数より部分以下であるに違いありません。 すなわち、依存は許容できるバージョンの最小値を指定します。
Housley Standards Track [Page 29] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[29ページ]RFC4108
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 }
イド-aa-firmwarePackageInfoオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2)42をメンバーと同じくらい具体化させます。
The firmware-package-info attribute values have ASN.1 type FirmwarePackageInfo:
ファームウェアパッケージインフォメーション属性値で、ASN.1はFirmwarePackageInfoをタイプします:
FirmwarePackageInfo ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
dependencies SEQUENCE OF
PreferredOrLegacyPackageIdentifier OPTIONAL }
FirmwarePackageInfo:、:= 系列fwPkgType INTEGER OPTIONAL、依存SEQUENCE OF PreferredOrLegacyPackageIdentifier OPTIONAL
2.2.10. Firmware Package Message Digest
2.2.10. ファームウェアパッケージメッセージダイジェスト
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.
ファームウェアパッケージ署名者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 }
イド-aa-fwPkgMessageDigestオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2)41をメンバーと同じくらい具体化させます。
The firmware-package-message-digest attribute values have ASN.1 type FirmwarePackageMessageDigest:
ファームウェアパッケージメッセージダイジェスト属性値で、ASN.1はFirmwarePackageMessageDigestをタイプします:
FirmwarePackageMessageDigest ::= SEQUENCE {
algorithm AlgorithmIdentifier,
msgDigest OCTET STRING }
FirmwarePackageMessageDigest:、:= 系列アルゴリズムAlgorithmIdentifier、msgDigest OCTET STRING
2.2.11. Signing Time
2.2.11. 署名時間
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.
ファームウェアパッケージ署名者SHOULDは署名時間属性を含んでいます、署名がファームウェアパッケージに適用された時を指定して。 [CMS]のセクション11.3は署名時間属性を定義します。
Housley Standards Track [Page 30] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[30ページ]RFC4108
2.2.12. Content Hints
2.2.12. 内容は暗示します。
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.
ファームウェアパッケージ署名者SHOULDはファームウェアパッケージの簡潔なテキスト記述を含む満足しているヒント属性を含んでいます。 テキストはUTF-8でコード化されます。(UTF-8は世界の書記体系[UTF-8]の大部分をサポートします)。 [ESS]のセクション2.9は満足しているヒント属性を定義します。
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.
カプセル化の複数の層が採用しているとき、満足しているヒント属性は、最も奥深い内容の情報を提供するために一番はずれのSignedDataに含まれています。 1つ以上がこの場合利用可能であるときに、属性が人を助けることができるファームウェアパッケージの簡潔なテキスト記述を提供する内容ヒントは正しいファームウェアパッケージを選択します。
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.
都合のよいファームウェアパッケージ名前フォームが使用されているとき、満足しているヒント属性はレガシーファームウェアパッケージ名にリンケージを供給できます。 既存の構成管理システムが使用中であるときに、これは特に役立っていますが、都合のよいファームウェアパッケージ名に関連している特徴は役に立つと考えられます。 そのような構成管理システムに関連しているファームウェアパッケージ名は「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:
満足しているヒント属性は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が大部分のcontent typeをより多くのinのcontent typeに提供して、この場合、それがあるに違いない、イドct firmwarePackage、(1.2 .840 .113549 .1 .9 .16 .1 .16)。
2.2.13. Signing Certificate
2.2.13. 署名証明書
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は、使われた証明書を特定するために署名証明書属性を含んでいます。 しかしながら、ファームウェアパッケージ署名に証明書がないなら(署名が信頼アンカー公開鍵で有効にされるだけであることを意味して)、ファームウェアパッケージ署名者は署名証明書属性を含むことができません。 [ESS]のセクション5.4はこの属性を定義します。
Housley Standards Track [Page 31] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[31ページ]RFC4108
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:
署名証明書属性は2つの分野を含んでいます: 本命と方針。 本命分野は存在していなければなりません、そして、方針分野は存在しているかもしれません。 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.
本命は証明書識別子の系列を含みます。 この場合、証明書識別子の系列は単一のエントリーを含みます。 本命分野はファームウェアパッケージ署名について確かめるのに使用される公開鍵を含む証明書に関する証明書識別子だけを含まなければなりません。 本命分野は[ESS]のセクション5.4で指定されたESSCertID構文を使用します、そして、全体のASN.1のSHA-1ハッシュ[SHA1]から成って、DERが任意に証明書、証明書発行人、および証明書通し番号をコード化したということです。 SHA-1ハッシュ値は存在していなければなりません。 発行人と証明書通し番号SHOULDを証明してください。存在してください。
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つに合わなければなりません。 方針分野は.5PolicyInformation構文指定されたコネセクション4.2.1[PROFILE]を使用します、そして、それは証明書政策目的識別子と任意に証明書方針資格を与える人から成ります。 証明書政策目的識別子は存在していなければなりません。 方針資格を与える人SHOULD NOTを証明してください。存在してください。
2.3. Unsigned Attributes
2.3. 未署名の属性
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は未署名の属性のSETを含めさせます。 しかしながら、この仕様では、セットは、休むか、または包装されたファームウェア復号化キー属性のただ一つのインスタンスを含まなければなりません。 デジタル署名がこの属性をカバーしていないので、配送経路の任意な点でファームウェアパッケージ署名者からハードウェアモジュールまでそれを変更できます。 暗号化されて署名しているファームウェアパッケージと共に主要なファームウェア復号化を分配するのにこの特性を使うことができます、ファームウェア復号化キーが流通網における各リンクに、主要な異なった主要な暗号化で包装されるのを許容して。
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つのインスタンスがまさにあるに違いありません。
Housley Standards Track [Page 32] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[32ページ]RFC4108
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つのインスタンスだけも含まなければなりません。
2.3.1. Wrapped Firmware Decryption Key
2.3.1. 包装されたファームウェア復号化キー
The firmware package signer, or any other party in the distribution chain, MAY include a wrapped-firmware-decryption-key attribute.
ファームウェアパッケージ署名者、または流通網のいかなる他のパーティーも包装されたファームウェア復号化キー属性を入れるかもしれません。
The following object identifier identifies the wrapped-firmware- decryption-key attribute:
以下のオブジェクト識別子は包装されたファームウェア復号化主要な属性を特定します:
id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 39 }
イド-aa-wrappedFirmwareKeyオブジェクト識別子:、:= iso(1)は(2) 私たち(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.
包装されたファームウェア復号化キー属性値には、EnvelopedDataのASN.1タイプがあります。 [CMS]のセクション6はEnvelopedData content typeを定義します。(それは、属性の値を構成するのに使用されます)。 EnvelopedDataは、ファームウェア復号化キーが保護されるのを左右対称の、または、非対称のテクニックを使用することで可能にします。 EnvelopedDataは暗号化された内容を含んでいません。 むしろ、もう1つの位置に暗号化された内容を持つ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 content typeは包装されたファームウェア復号化主要な属性のために輪郭を描かれます。 EnvelopedData分野は[CMS]のセクション6で完全に説明されます。 EnvelopedDataが包装されたファームウェア復号化キー属性として使用されるとき、付則は適用されます。
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]がある証明書を含んではいけません。 任意のcrls分野は存在しているかもしれません。
- The optional unprotectedAttrs field MUST NOT be present.
- 任意のunprotectedAttrs分野は存在しているはずがありません。
Housley Standards Track [Page 33] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[33ページ]RFC4108
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分野で運ばれたcontent typeオブジェクト識別子に合わなければなりません。
- 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は任意です、そして、この場合、それは存在しているはずがありません。
3. Firmware Package Load Receipt
3. ファームウェアパッケージ負荷領収書
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.
Cryptographic Message Syntax(CMS)は、ファームウェアパッケージが首尾よくロードされたのを示すのに使用されます。 ファームウェアパッケージ負荷領収書のサポートはOPTIONALです。 しかしながら、そのような領収書を作るのを選ぶそれらのハードウェアモジュールはこのセクションで指定されたコンベンションに続かなければなりません。 すべてのハードウェアモジュールには個人的な署名キーがあるというわけではないので、ファームウェアパッケージ負荷領収書は、署名されるか、または未署名である場合があります。 署名しているファームウェアパッケージ負荷領収書の使用はRECOMMENDEDです。
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によって順番にカプセル化されます)。
Housley Standards Track [Page 34] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[34ページ]RFC4108
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
}
ContentInfocontentTypeイド-signedData--、(1.2、.840、.113549、.1、.7、.2(OR)、)イドct firmwareLoadReceipt、--、(1.2.840.113549.1.9.16.1.17)内容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
}
SignedDataバージョンCMSVersion--いつも任意のModule証明書crls CertificateRevocationLists--任意のsignerInfos SET OF SignerInfo--1つだけを3digestAlgorithms DigestAlgorithmIdentifiers(1encapContentInfo EncapsulatedContentInfoだけ、証明書CertificateSet)に設定してください。
SignerInfo {
version CMSVersion, -- either set to 1 or 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Omit
}
SignerInfoCMSVersion(1か3sid SignerIdentifier、digestAlgorithm DigestAlgorithmIdentifier、signedAttrs SignedAttributes--signatureAlgorithm SignatureAlgorithmIdentifier、署名SignatureValue、unsignedAttrs UnsignedAttributesを必要とするのに設定される)が省略するバージョン
EncapsulatedContentInfo {
eContentType id-ct-firmwareLoadReceipt,
-- (1.2.840.113549.1.9.16.1.17)
eContent OCTET STRING -- Contains receipt
}
EncapsulatedContentInfoeContentType、イドct firmwareLoadReceipt、--、(1.2 .840 .113549 .1 .9 .16 .1 .17)eContent OCTET STRING--、領収書を含んでいます。
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
}
FirmwarePackageLoadReceiptバージョンINTEGER--DEFAULTはいつも使用されたhwType OBJECT IDENTIFIERです--ハードウェア的なモジュールはhwSerialNum OCTET STRING--H/Wモジュール通し番号fwPkgName PreferredOrLegacyPackageIdentifier、trustAnchorKeyID OCTET STRING--任意のdecryptKeyID OCTET STRINGをタイプします--、任意
Housley Standards Track [Page 35] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[35ページ]RFC4108
3.1. Firmware Package Load Receipt CMS Content Type Profile
3.1. ファームウェアパッケージ負荷領収書cm content typeプロフィール
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 content typeを使用するのにコンベンションを指定します。 また、それはファームウェアパッケージ負荷領収書content typeを定義します。
3.1.1. ContentInfo
3.1.1. ContentInfo
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と、イド-signedDataであるに違いない、(1.2 .840 .113549 .1 .7 .2) オブジェクト識別子はこの分野に存在していなければなりません。 領収書が署名されないなら、密閉型がFirmwarePackageLoadReceiptと、イド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.
内容は関連内容を保持します。 ファームウェアパッケージ負荷領収書が署名されるなら、この分野はSignedDataを含まなければなりません。 領収書が署名されないなら、この分野はFirmwarePackageLoadReceiptを含まなければなりません。
3.1.2. SignedData
3.1.2. SignedData
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 content typeはファームウェアパッケージ負荷領収書と1つのデジタル署名を含んでいます。 ハードウェアモジュールが局所的に証明書を保存するなら、また、証明書を含むことができます。 SignedDataの分野は以下の通り使用されます:
version is the syntax version number, and in this case, it MUST be
set to 3.
バージョンは構文バージョン番号です、そして、この場合、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は署名している内容と、content type識別子から成って、内容自体です。 セクション3.1.2で、より詳しく.2にEncapsulatedContentInfoタイプの使用について議論します。
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
証明書は証明書の任意の収集です。 ハードウェアモジュールが局所的に証明書を保存するなら、含まれていて、X.509がハードウェアモジュールSHOULDについて証明するその時です。 the
Housley Standards Track [Page 36] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[36ページ]RFC4108
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.
ハードウェアモジュールは省略しないで、次に、証明書分野は省略されます。 証明書のセットにPKCS#6通の拡張証明書[PKCS#6]と属性証明書(バージョン1かバージョン2のどちらか)[X.509-97、X.509-00、ACPROFILE]を含んではいけません。
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は証明書失効リスト(CRLs)の任意の収集です。 CRLsは含まれるかもしれませんが、ハードウェアモジュールが一般に最新のCRLに近づく手段を持たないので、通常、彼らは省略されるでしょう。 領収書受取人SHOULDであると署名されて、任意のcrls分野の存在を扱うことができてください。
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署名者あたりの情報の収集です、そして、この場合、収集はちょうど1SignerInfoを含まなければなりません。 セクション3.1.2で、より詳しく.1にSignerInfoタイプの使用について議論します。
3.1.2.1. SignerInfo
3.1.2.1. SignerInfo
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.
それは、バージョンが構文バージョン番号であり、1か3であるに違いありません、ハードウェアモジュールの公開鍵を特定するのに使用されるメソッドによって。 subjectKeyIdentifierの使用はRECOMMENDEDです。(そのRECOMMENDEDはバージョン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は2つの選択肢をサポートします: issuerAndSerialNumberとsubjectKeyIdentifier。 ハードウェアモジュールは領収書世代のための代替手段の1か両方をサポートしなければなりません。 しかしながら、subjectKeyIdentifierのサポートはRECOMMENDEDです。 issuerAndSerialNumber代替手段は発行人の分類名と証明書通し番号でハードウェアモジュールの証明書を特定します。 特定された証明書は順番にハードウェアモジュールの公開鍵を含んでいます。 subjectKeyIdentifier代替手段は直接ハードウェアモジュールの公開鍵を特定します。 この公開鍵が証明書に含まれているとき、この識別子SHOULDはX.509 subjectKeyIdentifier拡張子に現れます。
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値で運ばれたので、このメッセージダイジェストアルゴリズム識別子が同じであるに違いないことに注意してください。)
Housley Standards Track [Page 37] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[37ページ]RFC4108
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はファームウェアパッケージ負荷領収書内容がある使用のためのREQUIREDです。 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.
署名はデジタル署名です。
unsignedAttrs is an optional collection of attributes that are not
signed, and in this case, there MUST NOT be any unsigned
attributes present.
unsignedAttrsは署名されない属性の任意の収集です、そして、この場合、どんな未署名の存在している属性もあるはずがありません。
3.1.2.2. EncapsulatedContentInfo
3.1.2.2. EncapsulatedContentInfo
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が唯一content typeを指定するオブジェクト識別子であり、この場合それがイド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である必要はありません。
3.1.3. FirmwarePackageLoadReceipt
3.1.3. FirmwarePackageLoadReceipt
The following object identifier identifies the firmware package load receipt content type:
以下のオブジェクト識別子はファームウェアパッケージ負荷領収書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 }
イドct firmwareLoadReceipt、オブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)ct(1)17をメンバーと同じくらい具体化させます。
Housley Standards Track [Page 38] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[38ページ]RFC4108
The firmware package load receipt content type has the ASN.1 type FirmwarePackageLoadReceipt:
ファームウェアパッケージ負荷領収書content typeで、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 }
FirmwarePackageLoadReceipt:、:= 系列バージョンFWReceiptVersion DEFAULT v1、hwType OBJECT IDENTIFIER、hwSerialNum OCTET STRING、fwPkgName PreferredOrLegacyPackageIdentifier、trustAnchorKeyID OCTET STRING OPTIONAL、decryptKeyID[1]OCTET STRING OPTIONAL
FWReceiptVersion ::= INTEGER { v1(1) }
FWReceiptVersion:、:= 整数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.
バージョンはこの仕様の今後の改正を互換性の構文バージョン番号に提供する整数です。 この仕様に従う実装はデフォルト値にバージョンを設定しなければなりません。(それは、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.
decryptKeyIDは任意です、そして、存在しているとき、それはファームウェアパッケージを解読するのに使用されたファームウェア復号化キーを特定します。
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
ファームウェアパッケージ負荷領収書はバージョン、hwType、hwSerialNum、fwPkgName分野、およびそれを含まなければなりません。SHOULDはtrustAnchorKeyID分野を含んでいます。 ファームウェアパッケージ負荷領収書はそうしてはいけません。
Housley Standards Track [Page 39] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[39ページ]RFC4108
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.
decryptKeyIDを含めてください、領収書に関連しているファームウェアパッケージが暗号化されていて、ファームウェア復号化キーがハードウェアモジュールに利用可能であり、ファームウェアパッケージが首尾よく解読されなかったなら。
3.2. Signed Attributes
3.2. 属性であると署名されます。
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 Attributesと定義されます。 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.
ハードウェアモジュールはcontent typeとメッセージダイジェスト属性を含まなければなりません。 また、ハードウェアモジュールがリアルタイム時計を含んでいるなら、ハードウェアモジュールSHOULDは署名時間属性を含んでいます。 ハードウェアモジュールはそれが適切であると考えるいかなる他の属性も含むかもしれません。
3.2.1. Content Type
3.2.1. content type
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.
ハードウェア的なモジュールが値があるcontent type属性を含まなければならない、イドct firmwareLoadReceipt、(1.2 .840 .113549 .1 .9 .16 .1 .17)。 [CMS]のセクション11.1はcontent type属性を定義します。
3.2.2. Message Digest
3.2.2. メッセージダイジェスト
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はメッセージダイジェスト属性を定義します。
3.2.3. Signing Time
3.2.3. 署名時間
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.
ハードウェアモジュールがリアルタイム時計を含んでいるなら、ハードウェアモジュールSHOULDは署名時間属性を含んでいます、領収書が作られた時を指定して。 [CMS]のセクション11.3は署名時間属性を定義します。
Housley Standards Track [Page 40] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[40ページ]RFC4108
4. Firmware Package Load Error
4. ファームウェアパッケージ負荷誤り
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.
Cryptographic Message Syntax(CMS)は、保護されたファームウェアパッケージをロードするのを試みている間誤りが発生しているのを示すのに使用されます。 ファームウェアパッケージ負荷エラー・レポートのサポートはOPTIONALです。 しかしながら、そのようなエラー・レポートを作るのを選ぶそれらのハードウェアモジュールはこのセクションで指定されたコンベンションに続かなければなりません。 すべてのハードウェアモジュールには、個人的な署名キーがあるというわけではありません。 したがって、ファームウェアパッケージ負荷エラー・レポートは、署名されるか、または未署名である場合があります。 署名しているファームウェアパッケージエラー・レポートの使用はRECOMMENDEDです。
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によってカプセル化されます。(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
}
ContentInfocontentTypeイド-signedData--、(1.2、.840、.113549、.1、.7、.2(OR)、)イドct firmwareLoadError、--、(1.2.840.113549.1.9.16.1.18)内容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
}
SignedDataバージョンCMSVersion--いつも任意のModule証明書crls CertificateRevocationLists--任意のsignerInfos SET OF SignerInfo--1つだけを3digestAlgorithms DigestAlgorithmIdentifiers(1encapContentInfo EncapsulatedContentInfoだけ、証明書CertificateSet)に設定してください。
Housley Standards Track [Page 41] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[41ページ]RFC4108
SignerInfo {
version CMSVersion, -- either set to 1 or 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Omit
}
SignerInfoCMSVersion(1か3sid SignerIdentifier、digestAlgorithm DigestAlgorithmIdentifier、signedAttrs SignedAttributes--signatureAlgorithm SignatureAlgorithmIdentifier、署名SignatureValue、unsignedAttrs UnsignedAttributesを必要とするのに設定される)が省略するバージョン
EncapsulatedContentInfo {
eContentType id-ct-firmwareLoadError,
-- (1.2.840.113549.1.9.16.1.18)
eContent OCTET STRING -- Contains error report
}
EncapsulatedContentInfoeContentType、イドct firmwareLoadError、--、(1.2 .840 .113549 .1 .9 .16 .1 .18)eContent OCTET STRING--、エラー・レポートを含んでいます。
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
}
FirmwarePackageLoadErrorバージョンINTEGER--DEFAULTはいつも使用されたhwType OBJECT IDENTIFIERです--ハードウェア的なモジュールはhwSerialNum OCTET STRING--H/Wモジュール通し番号errorCode FirmwarePackageLoadErrorCode--誤り識別子vendorErrorCode VendorErrorCode--任意のfwPkgName PreferredOrLegacyPackageIdentifier--任意のコンフィグSEQUENCE OF CurrentFWConfigをタイプします--、任意
CurrentFWConfig { -- Repeated for each package in configuration
fwPkgType INTEGER, -- Firmware package type; Optional
fwPkgName PreferredOrLegacyPackageIdentifier
}
CurrentFWConfig--構成fwPkgType INTEGER--ファームウェアパッケージ型式; 任意のfwPkgName PreferredOrLegacyPackageIdentifierでの各パッケージのために繰り返された
4.1. Firmware Package Load Error CMS Content Type Profile
4.1. ファームウェアパッケージ負荷誤りcm content typeプロフィール
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 content typeを使用するのにコンベンションを指定します。 また、それはファームウェアパッケージ負荷誤りcontent typeを定義します。
4.1.1. ContentInfo
4.1.1. ContentInfo
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
contentTypeは関連内容のタイプを示します。 ファームウェアパッケージ負荷エラー・レポートが署名されるなら、密閉型がSignedDataと、イド-signedDataであるに違いない、(1.2 .840 .113549 .1 .7 .2) オブジェクト識別子はこの分野に存在していなければなりません。 レポートが署名されないなら、カプセル化することはタイプされます。
Housley Standards Track [Page 42] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[42ページ]RFC4108
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.
そして、FirmwarePackageLoadErrorになってください、イド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.
内容は関連内容を保持します。 ファームウェアパッケージ負荷エラー・レポートが署名されるなら、この分野はSignedDataを含まなければなりません。 レポートが署名されないなら、この分野はFirmwarePackageLoadErrorを含まなければなりません。
4.1.2. SignedData
4.1.2. SignedData
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 content typeはファームウェアパッケージ負荷エラー・レポートと1つのデジタル署名を含んでいます。 ハードウェアモジュールが局所的に証明書を保存するなら、また、証明書を含むことができます。 SignedDataの分野はまさにセクション3.1.2で説明されるように使用されます。
4.1.2.1. SignerInfo
4.1.2.1. SignerInfo
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に説明されるように使用されます。
4.1.2.2. EncapsulatedContentInfo
4.1.2.2. EncapsulatedContentInfo
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が唯一content typeを指定するオブジェクト識別子であり、この場合それがイド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である必要はありません。
4.1.3. FirmwarePackageLoadError
4.1.3. FirmwarePackageLoadError
The following object identifier identifies the firmware package load error report content type:
以下のオブジェクト識別子はファームウェアパッケージ負荷エラー・レポート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 }
イドct firmwareLoadError、オブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)ct(1)18をメンバーと同じくらい具体化させます。
Housley Standards Track [Page 43] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[43ページ]RFC4108
The firmware package load error report content type has the ASN.1 type FirmwarePackageLoadError:
ファームウェアパッケージ負荷エラー・レポートcontent typeで、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 }
FirmwarePackageLoadError:、:= 系列バージョンFWErrorVersion DEFAULT v1、hwType OBJECT IDENTIFIER、hwSerialNum OCTET STRING、errorCode FirmwarePackageLoadErrorCode、vendorErrorCode VendorLoadErrorCode OPTIONAL、fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL、コンフィグ[1]SEQUENCE OF CurrentFWConfig OPTIONAL
FWErrorVersion ::= INTEGER { v1(1) }
FWErrorVersion:、:= 整数v1(1)
CurrentFWConfig ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier }
CurrentFWConfig:、:= 系列fwPkgType整数任意である、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),
FirmwarePackageLoadErrorCode:、:= 列挙、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)
Housley Standards Track [Page 44] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[44ページ]RFC4108
unsupportedPackageType (30),
missingDependency (31),
wrongDependencyVersion (32),
insufficientMemory (33),
badFirmware (34),
unsupportedParameters (35),
breaksDependency (36),
otherError (99) }
unsupportedPackageType(30)、missingDependency(31)、wrongDependencyVersion(32)、insufficientMemory(33)、badFirmware(34)、unsupportedParameters(35)、breaksDependency(36)、otherError(99)
VendorLoadErrorCode ::= INTEGER
VendorLoadErrorCode:、:= 整数
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.
バージョンは整数です、そして、それはこの仕様の今後の改正を互換性の構文バージョン番号に提供します。 この仕様に従う実装はデフォルト値にバージョンを設定しなければなりません。(それは、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.
コンフィグは現在のファームウェア構成を特定します。 分野はOPTIONALですが、この分野のサポートは1個以上のファームウェアパッケージのローディングを可能にするハードウェアモジュールのためのRECOMMENDEDです。 CurrentFWConfigの1つのインスタンスが、それぞれのファームウェアパッケージの情報をハードウェアモジュールに提供するのに使用されます。
Housley Standards Track [Page 45] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[45ページ]RFC4108
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構文、バージョンが、未知である、サポートされないです、または1つ以上のエントリーが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は包装されたファームウェア復号化キー属性以外の属性を含んでいます。それは、この仕様でサポートされた唯一の未署名の属性です。
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でなくなっています。(EncapsulatedContentInfoがこの仕様で必要です)。 SignedDataかCompressedDataに位置する問題のためこの誤りを生成することができます。
Housley Standards Track [Page 46] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[46ページ]RFC4108
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は署名している属性で運ばれたcontent typeに合っていません。
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を含んでいます。(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: 任意のencryptedContentはEncryptedContentInfoでなくなっています。(EncryptedContentInfoがこの仕様で必要です)。
Housley Standards Track [Page 47] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[47ページ]RFC4108
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.
decryptFailure: パッケージが適切に解読しなかったファームウェア。
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でなくなっています。(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.
insufficientMemory: ハードウェアモジュールには十分な記憶力がなかったので、ファームウェアパッケージをロードできませんでした。
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: ファームウェアパッケージにおける署名は有効にされましたが、許容形式にはファームウェアパッケージ自体がありませんでした。 詳細はそれぞれのハードウェアモジュールに特定になるでしょう。 例えば、複数のファームウェアプログラマブルのコンポーネントで構成されるハードウェアモジュールは、それぞれのコンポーネントに実行コードを分配するためにファームウェアパッケージの中に内部のタグ付けを見つけることができませんでした。
Housley Standards Track [Page 48] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[48ページ]RFC4108
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: 前のエラーコードのいずれにも合わない誤りは発生しました。
4.2. Signed Attributes
4.2. 属性であると署名されます。
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 Attributesと定義されます。 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.
ハードウェアモジュールはcontent typeとメッセージダイジェスト属性を含まなければなりません。 また、ハードウェアモジュールがリアルタイム時計を含んでいるなら、ハードウェアモジュールSHOULDは署名時間属性を含んでいます。 ハードウェアモジュールはそれが適切であると考えるいかなる他の属性も含むかもしれません。
4.2.1. Content Type
4.2.1. content type
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.
ハードウェア的なモジュールが値があるcontent type属性を含まなければならない、イドct firmwareLoadError、(1.2 .840 .113549 .1 .9 .16 .1 .18)。 [CMS]のセクション11.1はcontent type属性を定義します。
4.2.2. Message Digest
4.2.2. メッセージダイジェスト
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内容のメッセージダイジェストを持っていて、ハードウェアモジュールはメッセージダイジェスト属性を含まなければなりません。 [CMS]のセクション11.2はメッセージダイジェスト属性を定義します。
Housley Standards Track [Page 49] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[49ページ]RFC4108
4.2.3. Signing Time
4.2.3. 署名時間
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.
ハードウェアモジュールがリアルタイム時計を含んでいるなら、ハードウェアモジュールSHOULDは署名時間属性を含んでいます、ファームウェアパッケージ負荷エラー・レポートが作られた時を指定して。 [CMS]のセクション11.3は署名時間属性を定義します。
5. Hardware Module Name
5. ハードウェアモジュール名
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で議論するファームウェアパッケージ負荷領収書のサポートはOPTIONALです、そして、セクション4で議論するファームウェアパッケージ負荷エラー・レポートのサポートはOPTIONALです。 領収書か誤りがレポート作成であるとサポートするハードウェアモジュールはユニークな通し番号を持たなければなりません。 さらに、署名している領収書か誤りがレポート作成であるとサポートするハードウェアモジュールは個人的な署名キーと対応する署名合法化証明書[PROFILE]かそれらの指示子を持たなければなりません。 署名合法化証明書におけるハードウェアモジュール命名のためのコンベンションはこのセクションで指定されます。
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:
形成というハードウェアモジュール名はイドオンなhardwareModuleNameのオブジェクト識別子によって特定されます:
id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) on(8) 4 }
hardwareModuleNameの上のイドオブジェクト識別子:、:= (8)4のiso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
A HardwareModuleName is composed of an object identifier and an octet string:
HardwareModuleNameはオブジェクト識別子と八重奏ストリングで構成されます:
HardwareModuleName ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }
HardwareModuleName:、:= 系列hwTypeオブジェクト識別子、hwSerialNum八重奏ストリング
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はハードウェアモジュールのタイプを特定するオブジェクト識別子です。 ユニークなオブジェクト識別子はハードウェアモデルと改正を命名します。
Housley Standards Track [Page 50] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[50ページ]RFC4108
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の組み合わせは唯一ハードウェアモジュールを特定します。
6. Security Considerations
6. セキュリティ問題
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.
このドキュメントはファームウェアパッケージを保護するためにCryptographic Message Syntax(CMS)の使用について説明します。 したがって、[CMS]で議論したセキュリティ問題はまた、この仕様に適用されます。
The conventions specified in this document raise a few security considerations of their own.
本書では指定されたコンベンションはそれら自身のいくつかのセキュリティ問題を提起します。
6.1. Cryptographic Keys and Algorithms
6.1. 暗号化キーとアルゴリズム
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.
時間に従って、暗号アルゴリズムは、より弱くなります。 新しい暗号文解読術のテクニックが開発されていて、性能を計算するのが向上するのに従って、特定の暗号アルゴリズムを破るワーク・ファクタは減らされるでしょう。 ファームウェアパッケージを変える能力は暗号アルゴリズムをアップデートするか、または置き換える機会を提供します。この能力はそうですが、望ましくて、暗号のアルゴリズム交換は相互運用性失敗につながることができます。 したがって、新しい暗号アルゴリズムの初公開を管理しなければなりません。 一般に、暗号アルゴリズムの前の世代と彼らの交換は、同時に規則的な変遷を容易にするためにサポートされる必要があります。
6.2. Random Number Generation
6.2. 乱数発生
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
ファームウェアパッケージが暗号化されているとき、ファームウェアパッケージの源は手当たりしだいにファームウェア暗号化キーを生成しなければなりません。 また、公共の、または、私設の署名主要な組の世代は乱数を当てにします。 暗号化キーを生成する不十分な疑似乱数生成器(PRNGs)の使用はまずセキュリティをもたらすことができません。 攻撃者は、PRNGを再生させるのがはるかに簡単であることがわかるかもしれません。
Housley Standards Track [Page 51] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[51ページ]RFC4108
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.
全体の主要なスペースを捜すブルートフォースよりむしろ結果として起こる小さい可能性を捜して、キーを生産した環境。 上質の乱数の世代は難しいです。 RFC4086[RANDOM]はこの領域で重要な指導を提供します。
6.3. Stale Firmware Package Version Number
6.3. 聞き古したファームウェアパッケージバージョン番号
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年[DDJ]にネットスケープブラウザの乱数発生器でイアン・ゴールドバーグとデヴィッド・ワグナーによって見つけられた欠点を考えてください。 この欠点は、秘密性が保護であると完全に弱体化させます。 ファームウェア署名者は、アップグレードしたハードウェアモジュールが失敗するファームウェアの使用を再開しないのを保証するのに聞き古したバージョン番号を使用するかもしれません。 しかしながら、別のファームウェア署名者は、これが聞き古したバージョン番号を使うのが適切である状況であると考えないかもしれません、ハードウェアモジュールの操作の、より近くでこの決定をだれかへ代表として派遣するのを好んで。 そのような人は、より新しいファームウェアパッケージの中に導入された他のバグが失敗する乱数発生器によって引き起こされた機密保持の懸念より悪い操作上の関心を課すかどうか評価するさらに良い立場にいそうです。 例えば、失敗するネットスケープブラウザの暗号化機能を決して使用しないユーザは乱数欠点を考えないで使用する中で最も適切なバージョンかそのフィックスを決定するでしょう。
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
ファームウェアパッケージにおける聞き古したバージョン番号の形成という都合のよいファームウェアパッケージ名を使う使用は完全に聞き古したファームウェアパッケージのその後の使用を防ぐことができるというわけではありません。 この短所にもかかわらず、それがいくつかの重要な状況で役に立つので、特徴は含まれています。 異なったタイプのファームウェアパッケージをロードして、それぞれそれ自身の聞き古したファームウェアパッケージバージョン番号で、聞き古したバージョン番号のための内部記憶装置が超えられるまで、ユーザはメカニズムを回避できます。 ハードウェアモジュールを考えてください。
Housley Standards Track [Page 52] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[52ページ]RFC4108
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バージョン2が聞き古したである示して、FWPKG-Aバージョン3がロードされていると仮定してください。 ユーザは以下を連続してロードできます:
- 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.
ファームウェア署名者は、聞き古したバージョン番号が署名される異なったタイプのファームウェアパッケージの数を制限することによって光栄に思われるのを確実にすることができます。 ハードウェアモジュールのすべてがそれぞれの異なったタイプのファームウェアパッケージの聞き古したバージョン番号を保存できると、ハードウェアモジュールは必要な保護を提供できるでしょう。 これは、ファームウェア署名者にはファームウェアパッケージを受け取るかもしれないハードウェアモジュールのすべての深い理解があるのを必要とします。
6.4. Community Identifiers
6.4. 共同体識別子
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.
ファームウェアパッケージが共同体識別子を含んでいるとき、パッケージが意図している共同体によって使用されるだけであるという信用は共同体会員資格を構成するのに使用されるメカニズムによります。 このドキュメントはハードウェアモジュールへの共同体会員資格の課題にメカニズムを指定しません、そして、様々な代替手段には、異なったセキュリティの特性があります。 また、共同体識別子課題をハードウェアモジュールにする権威もファームウェアパッケージを生成する権威と異なっているかもしれません。
Housley Standards Track [Page 53] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[53ページ]RFC4108
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[COMPRESS] Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS)", RFC 3274, June
2002.
[圧縮します] ガットマン、P.、「暗号のメッセージ構文(cm)のための圧縮されたデータcontent type」、RFC3274、2002年6月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[cm] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[ESS]ホフマン、P.、「S/MIMEのための警備の強化サービス」、RFC2634、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.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[SHA1] National Institute of Standards and Technology. FIPS
Pub 180-1: Secure Hash Standard. 17 April 1995.
[SHA1]米国商務省標準技術局。 FIPSパブ180-1: ハッシュ規格を保証してください。 1995年4月17日。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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、ISO10646の変換形式」STD63、RFC3629、11月2003日
[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.
7.2. Informative References
7.2. 有益な参照
[ACPROFILE] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April
2002.
[ACPROFILE]ファレルとS.とR.Housley、「承認のためのインターネット属性証明書プロフィール」、RFC3281、2002年4月。
[AES] National Institute of Standards and Technology. FIPS
Pub 197: Advanced Encryption Standard (AES). 26
November 2001.
[AES]米国商務省標準技術局。 FIPSパブ197: エー・イー・エス(AES)。 2001年11月26日。
Housley Standards Track [Page 54] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[54ページ]RFC4108
[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] ピンカスとD.とR.Housley、「経路合法化を代表として派遣して、代表として派遣して、経路発見は要件について議定書の中で述べる」RFC3379、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.、Ankney、R.、Malpani、A.、ガリペリン、S.、およびC.アダムス、「X.509のインターネットの公開鍵暗号基盤のオンライン証明書状態は議定書を作ります--OCSP」、RFC2560、1999年6月。
[PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax
Standard, Version 1.5. November 1993.
[PKCS#6]RSA研究所。 PKCS#6: 拡張証明書構文規格、バージョン1.5。 1993年11月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」[無作為]のBCP106、2005年6月のRFC4086。
[SECREQMTS] National Institute of Standards and Technology. FIPS
Pub 140-2: Security Requirements for Cryptographic
Modules. 25 May 2001.
[SECREQMTS]米国商務省標準技術局。 FIPSパブ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.
Housley Standards Track [Page 55] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[55ページ]RFC4108
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) }
CMSFirmwareWrapperiso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cmファームウェア包装(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) };
IMPORTS EnvelopedData FROM CryptographicMessageSyntax--、[CMS]、iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm-2004(24)、。
-- Firmware Package Content Type and Object Identifier
-- ファームウェアパッケージcontent typeとオブジェクト識別子
id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 16 }
イドct firmwarePackage、オブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)ct(1)16をメンバーと同じくらい具体化させます。
FirmwarePkgData ::= OCTET STRING
FirmwarePkgData:、:= 八重奏ストリング
-- 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 }
イド-aa-firmwarePackageIDオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2)35をメンバーと同じくらい具体化させます。
FirmwarePackageIdentifier ::= SEQUENCE {
name PreferredOrLegacyPackageIdentifier,
stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
FirmwarePackageIdentifier:、:= 系列名前PreferredOrLegacyPackageIdentifier、聞き古したPreferredOrLegacyStalePackageIdentifier OPTIONAL
PreferredOrLegacyPackageIdentifier ::= CHOICE {
preferred PreferredPackageIdentifier,
legacy OCTET STRING }
PreferredOrLegacyPackageIdentifier:、:= 選択都合のよいPreferredPackageIdentifier、レガシーOCTET STRING
PreferredPackageIdentifier ::= SEQUENCE {
fwPkgID OBJECT IDENTIFIER,
verNum INTEGER (0..MAX) }
PreferredPackageIdentifier:、:= 系列fwPkgIDオブジェクト識別子、verNum整数(0..MAX)
Housley Standards Track [Page 56] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[56ページ]RFC4108
PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
preferredStaleVerNum INTEGER (0..MAX),
legacyStaleVersion OCTET STRING }
PreferredOrLegacyStalePackageIdentifier:、:= 選択preferredStaleVerNum整数(0..MAX)、legacyStaleVersion八重奏ストリング
id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 36 }
イド-aa-targetHardwareIDsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2)36をメンバーと同じくらい具体化させます。
TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
TargetHardwareIdentifiers:、:= オブジェクト識別子の系列
id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 37 }
イド-aa-decryptKeyIDオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2)37をメンバーと同じくらい具体化させます。
DecryptKeyIdentifier ::= OCTET STRING
DecryptKeyIdentifier:、:= 八重奏ストリング
id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 38 }
イド-aa-implCryptoAlgsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2)38をメンバーと同じくらい具体化させます。
ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
ImplementedCryptoAlgorithms:、:= オブジェクト識別子の系列
id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 43 }
イド-aa-implCompressAlgsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2)43をメンバーと同じくらい具体化させます。
ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
ImplementedCompressAlgorithms:、:= オブジェクト識別子の系列
id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 40 }
イド-aa-communityIdentifiersオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2)40をメンバーと同じくらい具体化させます。
CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
CommunityIdentifiers:、:= CommunityIdentifierの系列
CommunityIdentifier ::= CHOICE {
communityOID OBJECT IDENTIFIER,
hwModuleList HardwareModules }
CommunityIdentifier:、:= 選択communityOIDオブジェクト識別子、hwModuleList HardwareModules
HardwareModules ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialEntries SEQUENCE OF HardwareSerialEntry }
HardwareModules:、:= 系列hwTypeオブジェクト識別子、HardwareSerialEntryのhwSerialEntries系列
Housley Standards Track [Page 57] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[57ページ]RFC4108
HardwareSerialEntry ::= CHOICE {
all NULL,
single OCTET STRING,
block SEQUENCE {
low OCTET STRING,
high OCTET STRING } }
HardwareSerialEntry:、:= 選択すべてのNULL(独身のOCTET STRING)がSEQUENCEを妨げる、低いOCTET STRING、高い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 }
イド-aa-firmwarePackageInfoオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2)42をメンバーと同じくらい具体化させます。
FirmwarePackageInfo ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
dependencies SEQUENCE OF
PreferredOrLegacyPackageIdentifier OPTIONAL }
FirmwarePackageInfo:、:= 系列fwPkgType INTEGER OPTIONAL、依存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 }
イド-aa-wrappedFirmwareKeyオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2)39をメンバーと同じくらい具体化させます。
WrappedFirmwareKey ::= EnvelopedData
WrappedFirmwareKey:、:= EnvelopedData
-- Firmware Package Load Receipt Content Type and Object Identifier
-- ファームウェアパッケージ負荷領収書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 }
イドct firmwareLoadReceipt、オブジェクト識別子:、:= iso(1)は(2) 私たち(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 }
FirmwarePackageLoadReceipt:、:= 系列バージョンFWReceiptVersion DEFAULT v1、hwType OBJECT IDENTIFIER、hwSerialNum OCTET STRING、fwPkgName PreferredOrLegacyPackageIdentifier、trustAnchorKeyID OCTET STRING OPTIONAL、decryptKeyID[1]OCTET STRING OPTIONAL
FWReceiptVersion ::= INTEGER { v1(1) }
FWReceiptVersion:、:= 整数v1(1)
Housley Standards Track [Page 58] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[58ページ]RFC4108
-- Firmware Package Load Error Report Content Type -- and Object Identifier
-- ファームウェアパッケージ負荷エラー・レポート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 }
イドct firmwareLoadError、オブジェクト識別子:、:= iso(1)は(2) 私たち(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 }
FirmwarePackageLoadError:、:= 系列バージョンFWErrorVersion DEFAULT v1、hwType OBJECT IDENTIFIER、hwSerialNum OCTET STRING、errorCode FirmwarePackageLoadErrorCode、vendorErrorCode VendorLoadErrorCode OPTIONAL、fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL、コンフィグ[1]SEQUENCE OF CurrentFWConfig OPTIONAL
FWErrorVersion ::= INTEGER { v1(1) }
FWErrorVersion:、:= 整数v1(1)
CurrentFWConfig ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier }
CurrentFWConfig:、:= 系列fwPkgType整数任意である、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),
FirmwarePackageLoadErrorCode:、:= 列挙、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)
Housley Standards Track [Page 59] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[59ページ]RFC4108
decompressFailure (26),
wrongHardware (27),
stalePackage (28),
notInCommunity (29),
unsupportedPackageType (30),
missingDependency (31),
wrongDependencyVersion (32),
insufficientMemory (33),
badFirmware (34),
unsupportedParameters (35),
breaksDependency (36),
otherError (99) }
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
VendorLoadErrorCode:、:= 整数
-- Other Name syntax for Hardware Module Name
-- Hardware Module Nameのための他の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の上のイドオブジェクト識別子:、:= (8)4のiso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
HardwareModuleName ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }
HardwareModuleName:、:= 系列hwTypeオブジェクト識別子、hwSerialNum八重奏ストリング
END
終わり
Author's Address
作者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousley不寝番セキュリティ、スプリング小山Driveハーンドン、LLC918ヴァージニア20170米国
EMail: housley@vigilsec.com
メール: housley@vigilsec.com
Housley Standards Track [Page 60] RFC 4108 Using CMS to Protect Firmware Packages August 2005
2005年8月にファームウェアパッケージを保護するのにcmを使用するHousley標準化過程[60ページ]RFC4108
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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はこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Housley Standards Track [Page 61]
Housley標準化過程[61ページ]
一覧
スポンサーリンク
