RFC 4108
Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages
RFC 4108: Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages 🎀
Okay bestie, let's start with the basics. This is RFC 4108 from the Network Working Group, written by R. Housley of Vigil Security. It's on the Standards Track and it's dated August 2005 📅. The header doesn't list anything it obsoletes or updates, so it's a standalone doc. 💅
The whole point is protecting firmware packages, which are the object code that runs on one or more hardware module components 🔥 It uses the Cryptographic Message Syntax (CMS), which is specified in RFC 3852, to do the heavy lifting.
Status of This Memo ✨
This document is an Internet standards track protocol for the Internet community, and it's literally asking for your thoughts and suggestions for improvements 🫶 If you want the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Also, distribution of this memo is unlimited, so share it with everyone 🌈
Copyright Notice 📜
Copyright (C) The Internet Society (2005).
Abstract 🦋
Okay so the big idea is this: CMS gets used to lock down firmware packages, which are basically the code that makes hardware modules work 💖 A digital signature protects the package from being modified without anyone noticing, and it also proves where the data came from (that's the data origin authentication part 👑). Encryption is totally optional if you want to keep the package secret, and compression is optional too if you want it smaller 🍓
There are also two optional reports 🙈 A firmware package loading receipt can be generated to say "yep, it loaded successfully ✅", and a firmware package load error report can be generated to say "uh oh, it didn't load" 💀
Table of Contents 🧚
Network Working Group R. Housley
Request for Comments: 4108 Vigil Security
Category: Standards Track August 2005 1. Introduction ....................................................3
1.1. Terminology ................................................5
1.2. Architectural Elements .....................................5
1.2.1. Hardware Module Requirements ........................7
1.2.2. Firmware Package Requirements .......................8
1.2.3. Bootstrap Loader Requirements .......................9
1.2.3.1. Legacy Stale Version Processing ...........11
1.2.3.2. Preferred Stale Version Processing ........12
1.2.4. Trust Anchors ......................................12
1.2.5. Cryptographic and Compression Algorithm
Requirements .......................................13
1.3. Hardware Module Security Architecture .....................14
1.4. ASN.1 Encoding ............................................14
1.5. Protected Firmware Package Loading ........................15
2. Firmware Package Protection ....................................15
2.1. Firmware Package Protection CMS Content Type Profile ......18
2.1.1. ContentInfo ........................................18
2.1.2. SignedData .........................................18
2.1.2.1. SignerInfo ................................19
2.1.2.2. EncapsulatedContentInfo ...................20
2.1.3. EncryptedData ......................................20
2.1.3.1. EncryptedContentInfo ......................21
2.1.4. CompressedData .....................................21
2.1.4.1. EncapsulatedContentInfo ...................22
2.1.5. FirmwarePkgData ....................................22
2.2. Signed Attributes .........................................22
2.2.1. Content Type .......................................23
2.2.2. Message Digest .....................................24
2.2.3. Firmware Package Identifier ........................24
2.2.4. Target Hardware Module Identifiers .................25
2.2.5. Decrypt Key Identifier .............................26
2.2.6. Implemented Crypto Algorithms ......................26
2.2.7. Implemented Compression Algorithms .................27
2.2.8. Community Identifiers ..............................27
2.2.9. Firmware Package Information .......................29
2.2.10. Firmware Package Message Digest ...................30
2.2.11. Signing Time ......................................30
2.2.12. Content Hints .....................................31
2.2.13. Signing Certificate ...............................31
2.3. Unsigned Attributes .......................................32
2.3.1. Wrapped Firmware Decryption Key ....................33
3. Firmware Package Load Receipt ..................................34
3.1. Firmware Package Load Receipt CMS Content Type Profile ....36
3.1.1. ContentInfo ........................................36
3.1.2. SignedData .........................................36
3.1.2.1. SignerInfo ................................37
3.1.2.2. EncapsulatedContentInfo ...................38
3.1.3. FirmwarePackageLoadReceipt .........................38
3.2. Signed Attributes .........................................40
3.2.1. Content Type .......................................40
3.2.2. Message Digest .....................................40
3.2.3. Signing Time .......................................40
4. Firmware Package Load Error ....................................41
4.1. Firmware Package Load Error CMS Content Type Profile ......42
4.1.1. ContentInfo ........................................42
4.1.2. SignedData .........................................43
4.1.2.1. SignerInfo ................................43
4.1.2.2. EncapsulatedContentInfo ...................43
4.1.3. FirmwarePackageLoadError ...........................43
4.2. Signed Attributes .........................................49
4.2.1. Content Type .......................................49
4.2.2. Message Digest .....................................49
4.2.3. Signing Time .......................................50
5. Hardware Module Name ...........................................50
6. Security Considerations ........................................51
6.1. Cryptographic Keys and Algorithms .........................51
6.2. Random Number Generation ..................................51
6.3. Stale Firmware Package Version Number .....................52
6.4. Community Identifiers .....................................53
7. References .....................................................54
7.1. Normative References ......................................54
7.2. Informative References ....................................54
Appendix A: ASN.1 Module ..........................................561. Introduction ✨
okay bestie, this doc is all about using the Cryptographic Message Syntax (CMS) [CMS] to protect firmware packages 🔐 It also covers using CMS for receipts and error reports when a firmware package gets loaded 📨 CMS is a data protection encapsulation syntax that runs on ASN.1 [X.208-88, X.209-88] 🧠 A protected firmware package can be tied to any hardware module, but this spec was written with cryptographic hardware modules in mind, because those have seriously strong security requirements 💪🔥
so a firmware package holds object code for one or more programmable components inside the hardware module 🧩 The package is treated as an opaque binary object and it gets digitally signed ✍️ Encryption and compression are optional, but they're supported 💅 When all three are used, the order is: compress, then encrypt, then sign 🎀 Compression just shrinks the package so processing and transmission are more efficient 🦋 Encryption keeps the package from being disclosed, which means you can send sensitive packages over insecure links 🙈 The encryption algorithm and mode might also give you integrity, so the package is protected from undetected modification 🛡️ Encryption also protects proprietary algorithms, classified algorithms, trade secrets, and implementation techniques 🤫 The digital signature protects the package from undetected modification and gives you data origin authentication 💖 It lets the hardware module confirm the 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 🔑 It might get delivered on physical media or over an independent electronic path 📦 One optional mechanism for distributing the decryption key is in Section 2.3.1, but honestly any secure key distribution mechanism is fine 🌸
the signature verification public key also has to reach the hardware module in a way that keeps its integrity and confirms where it came from 🫶 CMS can transfer certificates, so you can use that to send a certificate holding the signature verification public key (a firmware-signing certificate) 📜 BUT, and this is a big but 😭, using that facility adds a layer of indirection. At the end of the day, a trust anchor public key must be made available to the hardware module 👑 Section 1.2 sets the requirement that the hardware module stores one or more trust anchors 💜
hardware modules might not be able to reach certificate repositories or delegated path discovery (DPD) servers [DPD&DPV] to grab the certificates they need for a certification path 💀 So the firmware package signer has to include enough certificates so each module can validate the firmware-signer certificate (see Section 2.1.2) 🧚 Same deal for revocation info: modules might not be able to access a certificate revocation list (CRL) repository, an OCSP responder [OCSP], or a delegated path validation (DPV) server [DPD&DPV] to get revocation status 😵 So if the firmware package signature can't be validated with just the trust anchor public key, and the module can't do full certification path validation, then the entity loading the package into the hardware module is responsible for validating the firmware-signer certification path BEFORE loading 🙏 How that external revocation status checking gets done is out of scope for this spec 🚫
hardware modules will only accept firmware packages with a valid digital signature 🔥 The signature gets validated either directly with the trust anchor public key, or through a firmware-signer certification path that's validated back to the trust anchor public key 🎯 So, the trust anchors basically decide which entities can create firmware packages for the module 👑✨
what happens to a previously loaded firmware package after another one validates successfully is out of scope too 🤷♀️ How much memory the hardware module has will decide what options it gets 🧠
in some cases, hardware modules can generate receipts to acknowledge that a particular firmware package was loaded 📬 Receipts are super useful for figuring out which modules need an updated package whenever someone finds a flaw in an earlier one 🕵️♀️ Modules can also generate error reports to flag a firmware package load that didn't work 🚨 To do either one, the hardware module is required to have a unique permanent serial number 🔢 Receipts and error reports can be signed or unsigned 🎀 If you want digitally signed receipts or error reports, a hardware module MUST be issued its own private signature key and a certificate with the matching signature validation public key 💅 To save memory, the module might store a certificate designator instead of the whole certificate 🧚 The private signature key needs secure storage 🔐
1.1. Terminology
in this doc, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL get interpreted as described in [STDWORDS] 📖✨
1.2. Architectural 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, so it can validate the signature on the firmware package 🔑 If a signed firmware package load receipt or error report gets created on behalf of the hardware module, then the bootstrap loader MUST have access to a private signature key so it can generate the signature, plus the signer identifier for the matching signature validation certificate or its designator ✍️ A signature validation certificate MAY be included to help with signature validation 💖 To make this optional capability work, the hardware module MUST have a unique serial number and a private signature key 🔢 The hardware module MAY also include a certificate with the matching signature validation public key 📜 These items MUST be installed in the hardware module before it gets deployed 🚀 The private key and certificate can be generated and installed as part of the manufacturing process 🏭 Figure 1 shows all of this visually 👀
ASN.1 object identifiers are the preferred way to name the architectural elements 🧾
okay so managing the trust anchors is out of scope 🙈 BUT one or more trust anchors MUST be installed in the hardware module using a secure process before it's deployed 🔐 These trust anchors are how you control which sources of firmware packages are acceptable 🚧 The hardware module vendor can include provisions for secure, remote management of trust anchors 🌐 One approach is to put trust anchors inside the firmware packages themselves 🎁 That approach is kind of like the optional capability described later for updating the bootstrap loader 🧚
in a cryptographic hardware module, the firmware package might implement lots of 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 decryption key is needed to actually use the firmware package 🗝️ Usually, separate distribution mechanisms are used for the decryption key and the firmware package 🛤️ An optional mechanism for securely distributing the decryption key along with the firmware package is in Section 2.3.1 🎀
+------------------------------------------------------+
| Hardware Module |
| |
| +---------------+ +--------------------------+ |
| | Bootstrap | | Firmware Package | |
| | Loader | | | |
| +---------------+ | +------------------+ | |
| | : Firmware Package : | |
| +---------------+ | : Identifier and : | |
| | Trust | | : Version Number : | |
| | Anchor(s) | | +------------------+ | |
| +---------------+ | | |
| | +-------------+ | |
| +---------------+ | : Algorithm 1 : | |
| | Serial Num. | | +-+-----------+-+ | |
| +---------------+ | : Algorithm 2 : | |
| | +-+-----------+-+ | |
| +---------------+ | : Algorithm n : | |
| | Hardware | | +-------------+ | |
| | Module Type | | | |
| +---------------+ +--------------------------+ |
| |
| +------------------------------------+ |
| | Optional Private Signature Key & | |
| | Signature Validation Certificate | |
| | or the Certificate Designator | |
| +------------------------------------+ |
| |
+------------------------------------------------------+Figure 1. Architectural Elements 🖼️✨
1.2.1. Hardware Module Requirements
okay so, many different vendors make hardware modules, and each vendor usually identifies its modules by product type (family) and revision level 🏭 A unique object identifier MUST name each hardware module type and revision 🧾💅
each hardware module within a hardware module family SHOULD have a unique permanent serial number 🔢 HOWEVER, if the optional receipt or error report generation capability is implemented, then the hardware module MUST have a unique permanent serial number 🎯 If the optional receipt or error report signature capability is implemented, then the hardware module MUST have a private signature key and a certificate containing the corresponding public signature validation key or its designator 🔐 If a serial number is present, the bootstrap loader uses it for authorization decisions (see Section 2.2.8), receipt generation (see Section 3), and error report generation (see Section 4) 📋✨
when the hardware module has more than one firmware-programmable component, the bootstrap loader distributes the components of the package to the right components inside the hardware module after the firmware package is validated 🧩 The bootstrap loader gets more detail in Section 1.2.3 🫶
1.2.2. Firmware Package Requirements ✨
okay so there are two ways to name firmware packages 🎀: legacy and preferred. The name goes in a CMS signed attribute, not inside the firmware package itself 📦
Legacy names are just octet strings with no structure assumed 🫶. This form is only supported so existing configuration management systems can keep vibing. We assume the firmware signer and the bootstrap loader will understand whatever internal structure the octet string has. Like, given two legacy names, we assume they can tell which one is the newer version. This is literally needed for the stale version feature 💀. If a firmware package with a disastrous flaw gets released, later firmware package versions MAY designate a stale legacy firmware package name so nobody can roll back to that stale version or anything older than it 🙅♀️.
Preferred names are a combo 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. Like, firmware for a cable modem and firmware for a wireless LAN network interface card are giving distinct object identifiers 🦋. Same energy for firmware that implements distinct suites of cryptographic algorithms and modes of operation, or that emulates different (non-programmable) cryptographic devices. Distinct OIDs, periodt 💅. The version number MUST identify a particular build or release of the firmware package. It MUST be a monotonically increasing non-negative integer 📈. Usually an earlier version gets replaced by a later one 🌸. If a disastrous-flaw package drops, later versions MAY designate a stale version number so rollback to that version (or anything earlier) is blocked 🧚.
Firmware packages are developed to run on one or more hardware module types. The firmware package digital signature MUST bind the list of supported hardware module object identifiers to the firmware package 🔐.
In lots of cases, the signature gets validated directly with the trust anchor public key, so there's no need to build certification paths 🙈. Or, the trust anchor can delegate firmware package signing to another public key through a certification path. In that case, the firmware package SHOULD contain the certificates needed to build the certification path that begins with a certificate issued by the trust anchors and ends with a certificate issued to the firmware package signer 🎀.
The firmware package MAY contain a list of community identifiers. These name the hardware modules that are authorized to load the firmware package 🫧. If the firmware package has a list of community identifiers, then the bootstrap loader MUST reject the firmware package if the hardware module is not a member of one of the identified communities.
When a hardware module has 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 meant 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 🙃.
1.2.3. Bootstrap Loader Requirements 🥾
The bootstrap loader MUST have access to a physical interface and any related driver or protocol software needed to obtain a firmware package 🔌. The same interface SHOULD be used to deliver receipts and error reports. Details of the physical interface and the driver or protocol software are beyond the scope of this specification.
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 that support 🤷♀️.
If the bootstrap loader can be loaded by a firmware package, an initial bootstrap loader MUST be installed in non-volatile memory prior to deployment. All bootstrap loaders, including an initial bootstrap loader if one is used, MUST meet the requirements in this section. The firmware package containing the bootstrap loader MAY also contain other routines 🧰.
The bootstrap loader needs 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, so it can validate the digital signature on the firmware package and 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 don't need to be capable of generating firmware packages. Because some symmetric encryption algorithm implementations (such as AES [AES]) use separate logic for encryption and decryption, there might be some hardware module savings 💸.
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, for the same reason: hardware modules don't need to 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 needs 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. That MAY require building a valid certification path from the firmware-signing certificate to one of the trust anchors [PROFILE]. However, in lots of cases, the firmware package signature will be validated directly with the trust anchor public key, so there's no need to build certification paths 🙌.
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. How community membership gets determined is beyond the scope of this specification 🫧.
The bootstrap loader MUST reject a firmware package if it cannot successfully decrypt the firmware package using the firmware-decryption key available to the hardware module. The firmware package contains an identifier of the firmware-decryption key needed for decryption 🔑.
When an earlier version of a firmware package is replacing a later one, the bootstrap loader SHOULD generate a warning ⚠️. How that warning gets generated is highly dependent on the hardware module and the environment it's used in. 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 🛑.
1.2.3.1. Legacy Stale Version Processing 🕰️
In case a firmware package with a disastrous flaw is released, subsequent firmware package versions that use the legacy firmware package name form MAY include a stale legacy firmware package name, so rollback to the stale version or versions earlier than it gets blocked. As described in the Security Considerations section of this document, including a stale legacy firmware package name in a firmware package cannot completely prevent subsequent use of the stale firmware package. But many hardware modules are expected to have very few firmware packages written for them, which lets the stale firmware package version feature provide important protections 🛡️.
Non-volatile storage for stale version numbers is needed 💾. The number of stale legacy firmware package names that can be stored depends on how much storage is available. When a firmware package is loaded and it contains a stale legacy firmware package name, then that name SHOULD be added to a list kept in non-volatile storage. When subsequent firmware packages are loaded, the legacy firmware package name of the new package is compared to the list in non-volatile storage. If the legacy firmware package name represents the same version or an older version of a member of the list, then the new firmware package SHOULD be rejected 🚫.
The amount of non-volatile storage that needs to be set aside for saving legacy firmware package names and stale legacy firmware package 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 🎀
okay so, if a firmware package with a disastrous flaw gets released 😭, the later firmware package versions that use the preferred firmware package name form MAY include a stale version number 🦋. That way nobody can roll back to the stale version or anything older than it 🙅♀️. Bestie, heads up: like the Security Considerations section of this document explains, putting a stale version number in a firmware package can't completely stop someone from using the stale firmware package later 🥺. BUT many hardware modules are only ever gonna get a handful of firmware packages written for them, so the stale firmware package version feature can still give some seriously important protections 💜✨
Non-volatile storage for stale version numbers is needed 💾. How many stale version numbers you can store depends on how much storage is available. When a firmware package gets loaded and it contains a stale version number, the object identifier of that firmware package and the stale version number SHOULD be added to a list kept in non-volatile storage 📝. When later firmware packages get loaded, their object identifier and version number get compared to that list. 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 🚫.
The amount of non-volatile storage that needs to be set aside for saving firmware package identifiers and stale version numbers depends on how many firmware packages are likely to be developed for the hardware module 🧮.
1.2.4. Trust Anchors 🌸
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. It's giving identity 🪪✨
The trust anchor public key gets used 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 that certification path is used to validate the firmware package signature. Two routes, one destination, periodt 🛣️💅
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's 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 it's 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 🙈.
1.2.5. Cryptographic and Compression Algorithm Requirements 🔐
A firmware package for a cryptographic hardware module includes cryptographic algorithm implementations 🧰. A firmware package for a non-cryptographic hardware module will likely include cryptographic algorithm implementations too, so it can support the bootstrap loader in validating 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 🆔. These identifiers can be used to figure out whether a particular firmware package satisfies the needs of a particular application 🔍. To make it easier to build algorithm-agile applications, the cryptographic module interface SHOULD allow applications to query the cryptographic module for the object identifiers associated with each cryptographic algorithm in the currently loaded firmware package 🦋. Applications SHOULD also be able to query the cryptographic module to find out attributes associated with each algorithm. Those 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 retrieving algorithm identifiers or algorithm attributes 🤷♀️.
1.3. Hardware Module Security Architecture 🏰
The bootstrap loader MAY be permanently stored in read-only memory, or it can be 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 that situation the firmware package doesn't contain a partial or incremental set of functions. A complete firmware package load minimizes complexity and avoids potential security problems ✅. From a complexity perspective, loading packages incrementally means each package has to identify any other packages it requires (its dependencies), and the bootstrap loader needs to verify that all of those dependencies are satisfied before it tries to execute the firmware package 🧩. When a hardware module is based on a general purpose processor or a digital signal processor, it's dangerous to let arbitrary packages get loaded at the same time unless there's a reference monitor making sure independent portions of the code can't interfere with each other 😬. It's also hard to evaluate arbitrary combinations of software modules [SECREQMTS] 🙃. For these reasons, a complete firmware package load is RECOMMENDED 💖; however, this specification lets the firmware signer identify dependencies between firmware packages so every situation can be handled 🫶.
The firmware packages MAY have dependencies on routines provided by other firmware packages 🔗. To keep the security evaluation complexity of a hardware module with that kind of design as low as possible, 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 it depends on 📋. The bootstrap loader MUST reject a firmware package load if it contains a dependency on a firmware package that isn't available 🚫.
Loading a firmware package can affect whether the dependencies of other firmware packages already part of the hardware module configuration get satisfied 🌀. For this reason, the bootstrap loader MUST reject the loading of a firmware package if the dependencies of any firmware package in the resulting configuration will be unsatisfied 🛑.
1.4. ASN.1 Encoding 🧾
The CMS uses Abstract Syntax Notation One (ASN.1) [X.208-88, X.209-88] 🔤. ASN.1 is a formal notation for describing data protocols, no matter what programming language the implementation uses 💻. Encoding rules describe how the values defined in ASN.1 get represented for transmission 📦. The Basic Encoding Rules (BER) are the most widely used rule set, but they offer more than one way to represent data structures 😵💫. For example, both definite length encoding and indefinite length encoding are supported. This flexibility is not desirable when digital signatures are used 🙅♀️. So the Distinguished Encoding Rules (DER) [X.509-88] were created 🎉. DER is a subset of BER that makes sure there's a single way to represent a given value. For example, DER always uses definite length encoding 💜.
In this specification, digitally signed structures MUST be encoded with DER 🔏. Other structures don't require DER, but the use of definite length encoding is strongly RECOMMENDED 🌈. By always using definite length encoding, the bootstrap loader has fewer options to implement 🧘♀️. In situations where there's very high confidence that only definite length encoding will be used, support for indefinite length decoding MAY be omitted 🙌.
1.5. Protected Firmware Package Loading 📦
This document doesn't try to specify a physical interface, any related driver software, or a protocol needed for loading firmware packages 🙅♀️. Lots of 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, no matter which interface 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. Firmware Package Protection ✨
okay bestie, so the firmware package gets wrapped up in CMS (Cryptographic Message Syntax) and treated as one opaque binary blob 📦. No peeking inside 👀. A digital signature guards it against undetected modification and handles data origin authentication 🔐. Encryption is optional for keeping it secret 🤫, and compression is optional for making it smaller 🎀. The CMS ContentInfo content type MUST always be present, and it MUST encapsulate the CMS SignedData content type 💖. If the package is encrypted, SignedData MUST encapsulate EncryptedData 🔒. If it's compressed, then SignedData (when there's no encryption) or EncryptedData (when there is) MUST encapsulate CompressedData 🗜️. And last but not least, (1) SignedData when there's no encryption or compression, (2) EncryptedData when it's encrypted but not compressed, or (3) CompressedData when it's compressed, MUST encapsulate the simple firmware package using the FirmwarePkgData content type defined in this specification (see Section 2.1.5) 👑.
The firmware package protection is summarized as follows (see [CMS] for the full syntax) 🧚:
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData
}
SignedData {
version CMSVersion, -- always set to 3
digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Signer cert. path
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one
}
SignerInfo {
version CMSVersion, -- always set to 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Optional
}
EncapsulatedContentInfo {
eContentType id-encryptedData, -- (1.2.840.113549.1.7.6)
-- OR --
id-ct-compressedData,
-- (1.2.840.113549.1.9.16.1.9)
-- OR --
id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
eContent OCTET STRING
} -- Contains EncryptedData OR
-- CompressedData OR
-- FirmwarePkgData
EncryptedData {
version CMSVersion, -- Always set to 0
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs UnprotectedAttributes -- Omit
}
EncryptedContentInfo {
contentType id-ct-compressedData,
-- (1.2.840.113549.1.9.16.1.9)
-- OR --
id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent OCTET STRING
} -- Contains CompressedData OR
-- FirmwarePkgData
CompressedData {
version CMSVersion, -- Always set to 0
compressionAlgorithm CompressionAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo
}
EncapsulatedContentInfo {
eContentType id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
eContent OCTET STRING -- Contains FirmwarePkgData
}
FirmwarePkgData OCTET STRING -- Contains firmware package2.1. Firmware Package Protection CMS Content Type Profile 🎀
this section is where we lay down the rules for using the CMS ContentInfo, SignedData, EncryptedData, and CompressedData content types 💅. It also defines the FirmwarePkgData content type, which is the new kid on the block 🌸.
2.1.1. ContentInfo 🌷
CMS requires that the outermost encapsulation be ContentInfo [CMS] 🎁. Here's how its fields work:
contentType tells you what kind of content is inside, 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 💖.
content holds the actual content, and in this case it MUST contain SignedData 🫶.
2.1.2. SignedData 🔏
The SignedData content type [CMS] holds the signed firmware package (which might be compressed, encrypted, or compressed and then encrypted before it gets signed), the certificates needed to validate the signature, and one digital signature value 💜. Here's how its fields are used:
version is the syntax version number, and in this case it MUST be set to 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 used by the firmware package signer MUST be present 🔥.
encapContentInfo contains the signed content, which is a content type identifier plus the content itself. More on how this type works in Section 2.1.2.2 🧚.
certificates is an optional collection of certificates. If the trust anchor signed the firmware package directly, then certificates SHOULD be omitted. If it didn't, then certificates SHOULD include the X.509 certificate of the firmware package signer. The set of certificates SHOULD be enough for the bootstrap loader to build a certification path from the trust anchor to the firmware signer's certificate 🛤️. 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 🙅♀️.
crls is an optional collection of certificate revocation lists (CRLs). In this case, CRLs SHOULD NOT be included by the firmware package signer. The reason is that firmware packages may be generated, signed, and posted in repositories for downloading into hardware modules, and it would be tough for the signer to include timely CRLs in the package. Because the CRLs aren't covered by the signature, timely CRLs MAY be inserted by some other party before the firmware package gets delivered to the hardware module 🦋.
signerInfos is a collection of per-signer information, and in this case the collection MUST contain exactly one SignerInfo. More on the SignerInfo type in Section 2.1.2.1 💅.
2.1.2.1. SignerInfo 🩷
The firmware package signer is represented by the SignerInfo type. Here's how its fields are used:
version is the syntax version number, and it MUST be 3 ✨.
sid identifies the signer's public key. CMS supports two options: issuerAndSerialNumber and subjectKeyIdentifier. However, the bootstrap loader MUST support the subjectKeyIdentifier option, which identifies the signer's public key directly. When this public key lives in a certificate, this identifier SHOULD appear in the X.509 subjectKeyIdentifier extension 🔑.
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. (Heads up: this message digest algorithm identifier MUST be the same as the one carried in the digestAlgorithms value in SignedData 👀.)
signedAttrs is an optional collection of attributes that get signed along with the content. Attributes are optional in CMS, but in this spec signedAttrs are REQUIRED for the firmware package. Implementations MUST ignore unrecognized signed attributes though, which is very chill of them 🫶. The SET OF attributes MUST be DER encoded [X.509-88]. Section 2.2 of this document lists the attributes that MUST be included in the collection, and other attributes MAY be included as well 🌈.
signatureAlgorithm identifies the signature algorithm, and any associated parameters, that the firmware package signer used to generate the digital signature 🖊️.
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 🔐.
2.1.2.2. EncapsulatedContentInfo 🧁
The EncapsulatedContentInfo content type wraps the firmware package, which might be compressed, encrypted, or compressed and then encrypted before it gets signed. The firmware package, in any of these formats, rides inside the EncapsulatedContentInfo type 🚀. Here's how its fields are used:
eContentType is an object identifier that uniquely specifies the content type. 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 holds id-encryptedData, the firmware package was encrypted before signing, and it may also have been compressed before encryption. When it holds id-ct-compressedData, the firmware package was compressed before signing but not encrypted. When it holds id-ct-firmwarePackage, the firmware package was neither compressed nor encrypted before signing 🧠.
eContent contains the signed firmware package, which might also be encrypted, compressed, or compressed and then encrypted before signing. The content is encoded as an octet string. The eContent octet string need not be DER encoded 🦢.
2.1.3. EncryptedData 🔒
The EncryptedData content type [CMS] holds the encrypted firmware package (which might be compressed before encryption). However, if the firmware package wasn't encrypted, the EncryptedData content type is not present at all 🙈. Here's how its fields are used:
version is the syntax version number, and in this case version MUST be 0 💖.
encryptedContentInfo is the encrypted content information. More on the EncryptedContentInfo type in Section 2.1.3.1 🎀.
unprotectedAttrs is an optional collection of unencrypted attributes, and in this case unprotectedAttrs MUST NOT be present 🙅♀️.
2.1.3.1. EncryptedContentInfo ✨
Okay bestie, so the encrypted firmware package gets tucked inside the EncryptedContentInfo type 🎀. It might have been compressed before encryption, and these are the fields and how they work 💅
contentTypetells you what kind of content you're dealing with 🔥. It MUST contain eitherid-ct-compressedData(1.2.840.113549.1.9.16.1.9) orid-ct-firmwarePackage(1.2.840.113549.1.9.16.1.16). If it'sid-ct-compressedData, the firmware package got compressed before it was encrypted. If it'sid-ct-firmwarePackage, it didn't get compressed first 🦋contentEncryptionAlgorithmnames the firmware-encryption algorithm, plus any parameters, that was used to encrypt the firmware package 🔐encryptedContentis the actual result of encrypting the firmware package 💖. This field is optional, but if you're in this case, it MUST be present 🫶
2.1.4. CompressedData 🗜️
The CompressedData content type [COMPRESS] holds the compressed firmware package 🌸. If the firmware package was NOT compressed, then the CompressedData content type just isn't there at all, no drama 🙈 Here's how its fields are used:
versionis the syntax version number. In this case it MUST be 0 💜compressionAlgorithmnames the compression algorithm, plus any parameters, that was used to compress the firmware package ✨encapContentInfois the compressed content itself, made of a content type identifier and the content 🧚 The EncapsulatedContentInfo type gets more detail in Section 2.1.4.1 👑
2.1.4.1. EncapsulatedContentInfo 🍓
The CompressedData content type wraps up the compressed firmware package, and it lives inside the EncapsulatedContentInfo type 🎀 Fields:
eContentTypeis an object identifier that uniquely specifies the content type. In this case it MUST be the value ofid-ct-firmwarePackage(1.2.840.113549.1.9.16.1.16) 🌈eContentis the compressed firmware package, encoded as an octet string. The eContent octet string need not be DER encoded 🫧
2.1.5. FirmwarePkgData 📦
The FirmwarePkgData content type contains the firmware package 💅 It's basically a straight wrap in an octet string, and it need not be DER encoded 💖
The FirmwarePkgData content type is identified by the id-ct-firmwarePackage object identifier 🔥
id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 16 }The FirmwarePkgData content type is a simple octet string 🦋
FirmwarePkgData ::= OCTET STRING2.2. Signed Attributes 💎
The firmware package signer MUST digitally sign a collection of attributes along with the firmware package 🔐 Every attribute in that collection MUST be DER encoded [X.509-88]. The syntax for attributes is defined in [CMS], but it's repeated here so you don't have to go hunting 🧚
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANYEvery attribute used with this profile has a single attribute value, even though the syntax says SET OF AttributeValue 🙈 There MUST be exactly one instance of AttributeValue present 🎀
The SignedAttributes syntax within signerInfo is defined as a SET OF Attribute 💜 The SignedAttributes MUST include only one instance of any particular attribute 🍓
The firmware package signer MUST include these four attributes: content-type, message-digest, firmware-package-identifier, and target-hardware-module-identifiers 👑
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 🌸 Same deal for compression: if the firmware package implements compression algorithms, the firmware package signer MAY also include the implemented-compress-algorithms attribute ✨
If the firmware package is meant for use only by specific communities, then the firmware package signer MUST also include the community-identifiers attribute 🫶
If the firmware package depends on one or more other firmware packages being present 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 say the firmware package depends on a particular bootstrap loader or separation kernel 🦋
The firmware package signer SHOULD also include these three attributes: firmware-package-message-digest, signing-time, and content-hints 🌈 And if the firmware package signer has a certificate (meaning the signer isn't always configured as a trust anchor), then the firmware package signer SHOULD also include the signing-certificate attribute 💖
The firmware package signer MAY include any other attribute that it deems appropriate 🧚
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) 🔥 If it's id-encryptedData, the firmware package was encrypted before it got signed. If it's id-ct-compressedData, the firmware package was compressed before signing but NOT encrypted 🦋 If it's id-ct-firmwarePackage, the firmware package was neither compressed nor encrypted before signing 🫧 Section 11.1 of [CMS] defines the content-type attribute 📚
2.2.2. Message Digest 💜
The firmware package signer MUST include a message-digest attribute, whose value is the message digest computed over the encapContentInfo eContent octet string, as defined in Section 2.1.2.2 🍓 This octet string holds the firmware package, and it MAY be compressed, encrypted, or both compressed and encrypted 🌸 Section 11.2 of [CMS] defines the message-digest attribute ✨
2.2.3. Firmware Package Identifier 🌈
The firmware-package-identifier attribute names the protected firmware package 🎀 There are two supported approaches to naming firmware packages: legacy and preferred 💅 The firmware package signer MUST include a firmware-package-identifier attribute using one of these name forms 👑
A legacy firmware package name is an octet string, and no structure inside it is assumed 🧚
A preferred firmware package name is a combo of an object identifier and a version number 💖 The object identifier names a collection of functions the firmware package implements, and the version number is a non-negative integer that identifies a particular build or release 🦋
If a firmware package with a disastrous flaw gets released, the firmware package that repairs the flaw MAY designate a stale firmware package version so the flawed version can't be reloaded 🔥 The hardware module bootstrap loader SHOULD prevent subsequent rollback to the stale version, or to versions earlier than the stale version 🛡️ When the legacy 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 more recent than the stale one 🙈 When the preferred form is used, the stale version is indicated by a stale version number, which is an integer 🌸
The following object identifier identifies the firmware-package-identifier attribute:
id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 35 }The firmware-package-identifier attribute values have ASN.1 type FirmwarePackageIdentifier:
FirmwarePackageIdentifier ::= SEQUENCE {
name PreferredOrLegacyPackageIdentifier,
stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
PreferredOrLegacyPackageIdentifier ::= CHOICE {
preferred PreferredPackageIdentifier,
legacy OCTET STRING }
PreferredPackageIdentifier ::= SEQUENCE {
fwPkgID OBJECT IDENTIFIER,
verNum INTEGER (0..MAX) }
PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
preferredStaleVerNum INTEGER (0..MAX),
legacyStaleVersion OCTET STRING }2.2.4. Target Hardware Module Identifiers 🎯
The target-hardware-module-identifiers attribute names the types of hardware modules the firmware package supports 🧚 Each supported hardware model type and revision gets its own unique object identifier 💅
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 }The target-hardware-module-identifiers attribute values have ASN.1 type TargetHardwareIdentifiers:
TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER2.2.5. Decrypt Key Identifier 🔑
The decrypt-key-identifier attribute names the symmetric key needed to decrypt the encapsulated firmware package 💖 The CMS EncryptedData content type is used when the firmware package is encrypted. The decrypt-key-identifier signed attribute gets carried in the SignedData content type that wraps the EncryptedData content type, naming the symmetric key needed to decrypt the firmware package 🦋 No particular structure is imposed on the key identifier 🌈 How the firmware-decryption key is securely distributed to every module authorized to use the firmware package is beyond the scope of this specification 🙈 There is an optional mechanism for securely distributing the firmware-decryption key along with the firmware package, though, and it's specified in Section 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 }The decrypt-key-identifier attribute values have ASN.1 type DecryptKeyIdentifier:
DecryptKeyIdentifier ::= OCTET STRING2.2.6. Implemented Crypto Algorithms ✨
okay so the implemented-crypto-algorithms attribute MAY be in the SignedAttributes 💖 and it lists the crypto algorithms the firmware package implements AND makes available to applications 🔥. only the algorithms exposed at the cryptographic module's interface get listed 🎀. if an algorithm is used internally and you can't reach it through the module's interface, it MUST NOT be listed 🙈. like, say the firmware package does decryption for future firmware installs but nobody else can use that decryption, then the firmware-decryption algorithm would not be listed. no cap, it's only the stuff you can actually touch 💅
the OID part of AlgorithmIdentifier names an algorithm AND its mode of use, and no algorithm parameters are included ✨. crypto algorithms cover traffic-encryption, key-encryption, key transport, key agreement, one-way hash, and digital signature algorithms 🔐. compression algorithms are NOT part of this list, bestie 🙅♀️
the OID that identifies this attribute is:
id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 38 }and the attribute values have the ASN.1 type ImplementedCryptoAlgorithms:
ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER2.2.7. Implemented Compression Algorithms 🗜️💜
the implemented-compress-algorithms attribute MAY be in the SignedAttributes, and it names the compression algorithms the firmware package implements and makes available to applications 🌸. only algorithms made available at the hardware module's interface get listed ✨. any compression algorithm used internally that isn't reachable through the hardware module interface MUST NOT be listed 💀. for example, if the firmware package has a decompression algorithm for future installs that nobody else can access, then the firmware-decompression algorithm would not be listed. iconic restraint 👑
the OID portion of AlgorithmIdentifier identifies a compression algorithm, and again, no algorithm parameters are included 🧚
the OID for this attribute is:
id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 43 }and the values are ASN.1 type ImplementedCompressAlgorithms:
ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER2.2.8. Community Identifiers 🏘️🫶
okay this one is giving gatekeeping, but in a responsible way 💅. if the community-identifiers attribute is in the SignedAttributes, it names the communities that are allowed to run the firmware package. the bootstrap loader MUST reject the firmware package if the hardware module is not a member of at least one of the identified communities 🚫. how community membership gets assigned is beyond the scope of this spec, so that's a whole other story 📖
the attribute can name authorized communities using a list of community object identifiers, a list of specific hardware modules, or a mix of both 🎀. a specific hardware module is identified by the hardware module identifier (as defined in Section 2.2.4) plus a serial number 🔢. to keep serial numbers compact, you can specify a contiguous block using the lowest authorized serial number and the highest authorized serial number 🧩. or, if you want every serial number tied to a hardware module family identifier, you can use the NULL value 🌈
now the important safety net: if the bootstrap loader has no way to get the list of community OIDs the hardware module belongs to, the bootstrap loader MUST behave as though that list is empty 🙈. and if it can't access the hardware module serial number, the bootstrap loader MUST behave as though the hardware module is not on the list of authorized hardware modules 🔒. defensive and iconic 👑
the OID for this attribute is:
id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 40 }the community-identifiers values have ASN.1 type CommunityIdentifiers:
CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
CommunityIdentifier ::= CHOICE {
communityOID OBJECT IDENTIFIER,
hwModuleList HardwareModules }
HardwareModules ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialEntries SEQUENCE OF HardwareSerialEntry }
HardwareSerialEntry ::= CHOICE {
all NULL,
single OCTET STRING,
block SEQUENCE {
low OCTET STRING,
high OCTET STRING } }2.2.9. Firmware Package Information 🧸📦
so if a hardware module supports more than one type of firmware package, the firmware package signer SHOULD include the firmware-package-info attribute with a populated fwPkgType field to say which type it is 🎀. this helps the bootstrap loader put the package in the right spot inside the hardware module 🗺️. the type is an INTEGER, and what the number means is specific to each hardware module. like, one module could use 1 for a bootstrap loader, 2 for a separation kernel, and 3 for an application 🔢✨
some hardware architectures let one firmware package use routines from another 🫂. if your package depends on another one, the firmware package signer SHOULD ALSO include the firmware-package-info attribute, this time with a populated dependencies field 🔗. BUT if the package doesn't depend on any other firmware packages, the firmware package signer MUST NOT include the firmware-package-info attribute with a populated dependencies field 🙅♀️
dependencies get identified either by the firmware package identifier or by information inside the package itself, and either way the bootstrap loader makes sure they're met 🛡️. the bootstrap loader MUST reject a firmware package load if it names a dependency on a package that isn't already loaded 🚫. and the bootstrap loader MUST reject a firmware package load if that action would leave an already loaded package's dependencies unsatisfied 💔. it's a whole web of trust, periodt 🕸️
here's the naming situation, and it's a lot 😭. as described in Section 2.2.3, two approaches to naming firmware packages are supported: legacy and preferred. with the legacy form, the dependency is indicated by a legacy firmware package name, and we assume the signer and the bootstrap loader can figure out whether a given legacy name represents the named version of an acceptable newer version 🧐. with the preferred form, you provide an object identifier and an integer. the object identifier MUST exactly match the object identifier portion of a preferred firmware package name associated with a package that's already loaded 🎯. and the integer MUST be less than or equal to the integer portion of that same preferred name 🔢. so basically the dependency sets the minimum acceptable version 💜
the OID for this attribute is:
id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 42 }and the values are ASN.1 type FirmwarePackageInfo:
FirmwarePackageInfo ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
dependencies SEQUENCE OF
PreferredOrLegacyPackageIdentifier OPTIONAL }2.2.10. Firmware Package Message Digest 🔍🌷
the firmware package signer SHOULD include a firmware-package-message-digest attribute 💌. it gives the message digest algorithm and the message digest value computed over the firmware package. the digest gets computed BEFORE any compression, encryption, or signature processing happens 🧁. then the bootstrap loader MAY use that digest to double-check that the intended firmware package came back out after all the layers of encapsulation got peeled off 🧅✨. the receipts, the proof, so iconic 📜
the OID for this attribute is:
id-aa-fwPkgMessageDigest OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 41 }and the values are ASN.1 type FirmwarePackageMessageDigest:
FirmwarePackageMessageDigest ::= SEQUENCE {
algorithm AlgorithmIdentifier,
msgDigest OCTET STRING }2.2.11. Signing Time ⏰💫
the firmware package signer SHOULD include a signing-time attribute, which records when the signature was applied to the firmware package 🕰️. for the details, Section 11.3 of [CMS] is where the signing-time attribute is defined, so go check it out if you're curious 📚🦋
2.2.12. Content Hints 💬🎀
the firmware package signer SHOULD include a content-hints attribute, which holds 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, so that's your reference 🧾
when there are multiple layers of encapsulation, the content-hints attribute goes in the outermost SignedData, and it gives info about the innermost content 🪆. here the description is a brief text note about the firmware package, which can help a person pick the correct package when more than one is available 🙋♀️✨
when the preferred firmware package name forms are used, the content-hints attribute can link to a legacy firmware package name 🔗. this is super helpful when an existing configuration management system is still in use but the features tied to the preferred name are still wanted 🥹. a name from that kind of system might look like "R1234.C0(AJ11).D62.A02.11(b)." ✨. putting those names in the text description can help developers see a clear link between the two name forms 🧠💜
the content-hints attribute has two fields, and in this case BOTH fields MUST be present 🫶. here's how they work:
contentDescription gives a brief text description of the firmware package 📣.
contentType gives the content type of the innermost content, and in this case it MUST be id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16) 🌈👑
2.2.13. Signing Certificate 🎀
okay so when the firmware-signer's public key lives inside a certificate, the firmware package signer SHOULD include a signing-certificate attribute to say exactly which certificate got used 💅 BUT if the firmware package signature doesn't have a certificate (so it only gets checked against the trust anchor public key), the signer can't include a signing-certificate attribute 😭 Section 5.4 of [ESS] defines this attribute.
the signing-certificate attribute has two fields, certs and policies 🦋 the certs field MUST be present, and the policies field MAY be present. here's how the fields of SigningCertificate work:
certsholds a sequence of certificate identifiers. in this case, the sequence has a single entry. thecertsfield MUST contain only the certificate identifier of the certificate that holds the public key used to verify the firmware package signature. it uses the ESSCertID syntax from Section 5.4 of [ESS], and it's made 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, and the certificate issuer and the certificate serial number SHOULD be present. 🔥policiesis optional. when it's there, it holds a sequence of policy information. if it's present, it MUST contain only one entry, and that entry MUST match one of the certificate policies in the certificate policies extension of the certificate that holds the public key used to verify the firmware package signature. it uses the PolicyInformation syntax from Section 4.2.1.5 of [PROFILE], and it's made of the certificate policy object identifier and, optionally, certificate policy qualifiers. the certificate policy object identifier MUST be present, and the certificate policy qualifiers SHOULD NOT be present. 👑
2.3. Unsigned Attributes 🫶
okay this one's giving main character energy 🌸 CMS lets you include a SET of unsigned attributes, but in this spec the set MUST be absent or include a single instance of the wrapped-firmware-decryption-key attribute. the digital signature doesn't cover this attribute, so it can get changed at any point in the delivery path from the firmware package signer to the hardware module 🙈 that's literally the point, because it lets you ship the firmware-decryption key along with an encrypted and signed firmware package, and wrap the key with a different key-encryption key for each link in the distribution chain. iconic 💜
the syntax for attributes is defined in [CMS], and it's repeated at the start of Section 2.2 of this document for convenience. every attribute used with this profile has a single attribute value, even though the syntax says SET OF AttributeValue. there MUST be exactly one instance of AttributeValue present. 🧚
the UnsignedAttributes syntax inside signerInfo is a SET OF Attribute. the UnsignedAttributes MUST include only one instance of any particular attribute. 🍓
2.3.1. Wrapped Firmware Decryption Key 🔐
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 }the wrapped-firmware-decryption-key attribute values have the ASN.1 type EnvelopedData. Section 6 of [CMS] defines the EnvelopedData content type, which is used to build the value of the attribute. EnvelopedData lets the firmware-decryption key be protected with symmetric or asymmetric techniques 🦋 the EnvelopedData does NOT include an encrypted content, though. instead it uses the feature where the encrypted content lives somewhere else. the encrypted content is found in the eContent field of the EncryptedData structure, and the firmware-decryption key is in the recipientInfos field. Section 6 of [CMS] calls this key the content-encryption key. 🎀
the EnvelopedData syntax supports lots of different key management algorithms. four general techniques are supported: key transport, key agreement, symmetric key-encryption keys, and passwords. 💅
the EnvelopedData content type is profiled for the wrapped-firmware-decryption-key attribute. the EnvelopedData fields are described fully in Section 6 of [CMS], and additional rules apply when EnvelopedData is used as a wrapped-firmware-decryption-key attribute. 🌈
within the EnvelopedData structure, the following apply:
- 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
crlsfield MAY be present. 🙅♀️ - the optional
unprotectedAttrsfield MUST NOT be present. 💀
within the EncryptedContentInfo structure, the following apply:
contentTypeMUST match the content type object identifier carried in thecontentTypefield within the EncryptedContentInfo structure of EncryptedData, as described in Section 2.1.3.1. 🫶contentEncryptionAlgorithmidentifies the firmware-encryption algorithm, and any associated parameters, used to encrypt the firmware package carried in theencryptedContentfield of the EncryptedContentInfo structure of EncryptedData. so it MUST exactly match the value of the EncryptedContentInfo structure of EncryptedData, as described in Section 2.1.3.1. 🔥encryptedContentis optional, and in this case, it MUST NOT be present. ✨
3. Firmware Package Load Receipt 🧾
the Cryptographic Message Syntax (CMS) is used to show that a firmware package loaded successfully 🥰 support for firmware package load receipts is OPTIONAL. however, hardware modules that choose to generate these receipts MUST follow the conventions in this section. not every hardware module will have private signature keys, so the receipt can be either signed or unsigned. using the signed receipt is 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, plus the matching signature validation certificate or its designator. the designator is either the certificate issuer name and the certificate serial number, or the public key identifier. memory-constrained hardware modules will usually store the public key identifier, since it takes up 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 then encapsulated by ContentInfo. 🦋
the firmware package load receipt is summarized as follows (see [CMS] for the full syntax):
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
-- OR --
id-ct-firmwareLoadReceipt,
-- (1.2.840.113549.1.9.16.1.17)
content SignedData
-- OR --
FirmwarePackageLoadReceipt
}
SignedData {
version CMSVersion, -- always set to 3
digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Optional Module certificate
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one
}
SignerInfo {
version CMSVersion, -- either set to 1 or 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Omit
}
EncapsulatedContentInfo {
eContentType id-ct-firmwareLoadReceipt,
-- (1.2.840.113549.1.9.16.1.17)
eContent OCTET STRING -- Contains receipt
}
FirmwarePackageLoadReceipt {
version INTEGER, -- The DEFAULT is always used
hwType OBJECT IDENTIFIER, -- Hardware module type
hwSerialNum OCTET STRING, -- H/W module serial number
fwPkgName PreferredOrLegacyPackageIdentifier,
trustAnchorKeyID OCTET STRING, -- Optional
decryptKeyID OCTET STRING -- Optional
}3.1. Firmware Package Load Receipt CMS Content Type Profile 🌸
this section lays out 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. ✨
3.1.1. ContentInfo 🎀
the CMS requires that the outermost encapsulation be ContentInfo [CMS]. the fields of ContentInfo work like this:
contentTypeindicates the type of the associated content. if the firmware package load receipt is signed, the encapsulated type MUST be SignedData, and theid-signedData(1.2.840.113549.1.7.2) object identifier MUST be present in this field. if the receipt is not signed, the encapsulated type MUST be FirmwarePackageLoadReceipt, and theid-ct-firmwareLoadReceipt(1.2.840.113549.1.9.16.1.17) object identifier MUST be present in this field. 🔥contentholds the associated content. if the firmware package load receipt is signed, this field MUST contain the SignedData. if the receipt is not signed, this field MUST contain the FirmwarePackageLoadReceipt. 🫶
3.1.2. SignedData
okay so SignedData is the wrapper 🎀 that holds the firmware package load receipt plus one digital signature. If the hardware module stores its own certificate locally, that cert can tag along too ✨ Here's how each field works:
versionis the syntax version number, and in this case, it MUST be set to 3 💖digestAlgorithmsis a collection of message digest algorithm identifiers, and in this case, it MUST contain a single message digest algorithm identifier. The message digest algorithms the hardware module uses MUST be present 🦋encapContentInfois the signed content, made up of a content type identifier and the content itself. We go deeper into the EncapsulatedContentInfo type in Section 3.1.2.2 🌸certificatesis an optional collection of certificates. If the hardware module stores its certificate locally, the X.509 certificate of the hardware module SHOULD be included. If it doesn't, the certificates field gets 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 🚫✨crlsis an optional collection of certificate revocation lists (CRLs). CRLs MAY be included, but they'll usually get left out, since hardware modules generally can't reach the most recent CRL 🙈 Signed receipt recipients SHOULD be able to handle the presence of the optional crls field 💅signerInfosis a collection of per-signer information, and in this case, the collection MUST contain exactly one SignerInfo. We cover the SignerInfo type in Section 3.1.2.1 👑
3.1.2.1. SignerInfo
this is where the hardware module actually gets represented 🧚 Here's the rundown:
versionis the syntax version number, and it MUST be either 1 or 3, depending on how the hardware module's public key gets identified. Using the subjectKeyIdentifier is RECOMMENDED, which means you end up on version 3 🌈sidspecifies the hardware module's certificate (and therefore the hardware module's public key). CMS gives you two options: issuerAndSerialNumber and subjectKeyIdentifier. The hardware module MUST support one or both of these alternatives for receipt generation, but supporting subjectKeyIdentifier is RECOMMENDED 💜 issuerAndSerialNumber finds the certificate using the issuer's distinguished name plus the certificate serial number, and that certificate holds the public key. subjectKeyIdentifier points straight at the public key. When that public key lives inside a certificate, this identifier SHOULD show up in the X.509 subjectKeyIdentifier extension 🔑digestAlgorithmidentifies the message digest algorithm, along with any associated parameters, that the hardware module uses. It MUST contain the message digest algorithms used to sign the receipt. (Heads up: this message digest algorithm identifier MUST be the same one carried in the digestAlgorithms value in SignedData 🫶)signedAttrsis an optional collection of attributes that get signed along with the content. Attributes are optional in CMS, but for this spec, 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 🙃signatureAlgorithmidentifies the signature algorithm, along with any associated parameters, used to sign the receipt ✍️signatureis the digital signature itself 💖unsignedAttrsis an optional collection of attributes that are not signed. In this case, there MUST NOT be any unsigned attributes present 🚫💅
3.1.2.2. EncapsulatedContentInfo
the FirmwarePackageLoadReceipt gets wrapped in an OCTET STRING, and that wrapper rides inside the EncapsulatedContentInfo type 🎁 Here's how its fields work:
eContentTypeis an object identifier that uniquely specifies the content type. In this case, it MUST be the value of id-ct-firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17) 🦋eContentis the firmware package load receipt, encapsulated in an OCTET STRING. The eContent octet string need not be DER encoded 🌸
3.1.3. FirmwarePackageLoadReceipt
here's the object identifier that names the firmware package load receipt content type 🆔✨
id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 17 }and the firmware package load receipt content type has the ASN.1 type FirmwarePackageLoadReceipt 🧁
FirmwarePackageLoadReceipt ::= SEQUENCE {
version FWReceiptVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
fwPkgName PreferredOrLegacyPackageIdentifier,
trustAnchorKeyID OCTET STRING OPTIONAL,
decryptKeyID [1] OCTET STRING OPTIONAL }
FWReceiptVersion ::= INTEGER { v1(1) }the fields of FirmwarePackageLoadReceipt mean the following 💜
versionis an integer that gives the syntax version number, so future revisions of this spec stay compatible. Implementations that conform to this specification MUST set the version to the default value, which is v1 👑hwTypeis an object identifier that identifies the type of hardware module the firmware package was loaded onto 🔧hwSerialNumis the serial number of the hardware module the firmware package was loaded onto. No particular structure is imposed on the serial number, so it doesn't have to be an integer. However, the combination of hwType and hwSerialNum uniquely identifies the hardware module 🪪fwPkgNameidentifies 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 📦trustAnchorKeyIDis optional. When it's present, it identifies the trust anchor that was used to validate the firmware package signature 🌈decryptKeyIDis optional. When it's present, it identifies the firmware-decryption key that was used to decrypt the firmware package 🗝️
the firmware package load receipt MUST include the version, hwType, hwSerialNum, and fwPkgName fields, and it SHOULD include the trustAnchorKeyID field 💅 The firmware package load receipt MUST NOT include the decryptKeyID, unless the firmware package tied to the receipt is encrypted, the firmware-decryption key is available to the hardware module, and the firmware package was successfully decrypted. no shortcuts, bestie 😤
3.2. Signed Attributes
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 🎀
each attribute 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 💖
inside signerInfo, SignedAttributes is defined as a SET OF Attributes. The SignedAttributes MUST include only one instance of any particular attribute 🔁
the hardware module MUST include the content-type and message-digest attributes 🫶 If the hardware module has a real-time clock, it SHOULD also include the signing-time attribute ⏰ The hardware module MAY include any other attribute it deems appropriate 🌸
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 📖
3.2.2. Message Digest
the hardware module MUST include a message-digest attribute, and its value is the message digest of the FirmwarePackageLoadReceipt content 🧾 Section 11.2 of [CMS] defines the message-digest attribute 💜
3.2.3. Signing Time
if the hardware module has a real-time clock, it SHOULD include a signing-time attribute that specifies when the receipt was generated ⏰✨ Section 11.3 of [CMS] defines the signing-time attribute 🌈
4. Firmware Package Load Error 💖
Okay bestie, so the Cryptographic Message Syntax (CMS) is what gets used to say an error happened while a hardware module was trying to load a protected firmware package 😭🎀 Support for firmware package load error reports is OPTIONAL 🌸 but if a hardware module does make them, it MUST follow the conventions in this section ✨
Not every hardware module has private signature keys 🔑 so the error report can be signed or unsigned 💅 Signed reports are RECOMMENDED tho 👑
Hardware modules that can generate error reports MUST have a unique serial number 🦋 And if they can make signed ones, they MUST also have a private signature key to sign the report, plus the matching signature validation certificate or its designator 🧚 The designator is either the certificate issuer name plus the certificate serial number, or the public key identifier. Memory-constrained modules usually store the public key identifier because it takes up less storage ✨
The unsigned report gets wrapped in ContentInfo. The signed one gets wrapped in SignedData, and that SignedData is then wrapped in ContentInfo 🎁
Here's the quick summary of the firmware package load error report (see [CMS] for the full syntax, obviously 💀):
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
-- OR --
id-ct-firmwareLoadError,
-- (1.2.840.113549.1.9.16.1.18)
content SignedData
-- OR --
FirmwarePackageLoadError
}
SignedData {
version CMSVersion, -- Always set to 3
digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Optional Module certificate
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one
}
SignerInfo {
version CMSVersion, -- either set to 1 or 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Omit
}
EncapsulatedContentInfo {
eContentType id-ct-firmwareLoadError,
-- (1.2.840.113549.1.9.16.1.18)
eContent OCTET STRING -- Contains error report
}
FirmwarePackageLoadError {
version INTEGER, -- The DEFAULT is always used
hwType OBJECT IDENTIFIER, -- Hardware module type
hwSerialNum OCTET STRING, -- H/W module serial number
errorCode FirmwarePackageLoadErrorCode -- Error identifier
vendorErrorCode VendorErrorCode, -- Optional
fwPkgName PreferredOrLegacyPackageIdentifier, -- Optional
config SEQUENCE OF CurrentFWConfig, -- Optional
}
CurrentFWConfig { -- Repeated for each package in configuration
fwPkgType INTEGER, -- Firmware package type; Optional
fwPkgName PreferredOrLegacyPackageIdentifier
}4.1. Firmware Package Load Error CMS Content Type Profile 🌈
This section is where we lay out the rules 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, so that's a whole vibe too 🧚
4.1.1. ContentInfo 🎀
CMS says the outermost wrapper has to be ContentInfo [CMS] 💅 Here's how its fields get used:
contentTypetells you what kind of content is inside. If the firmware package load error report is signed, the encapsulated type MUST be SignedData, and theid-signedData(1.2.840.113549.1.7.2)object identifier MUST be present in this field. If the report is not signed, the encapsulated type MUST be FirmwarePackageLoadError, and theid-ct-firmwareLoadError(1.2.840.113549.1.9.16.1.18)object identifier MUST be present in this field 🦋contentholds the actual stuff. If the report is signed, this field MUST contain the SignedData. If the report is not signed, this field MUST contain the FirmwarePackageLoadError 🔥
4.1.2. SignedData 🌸
The SignedData content type carries the firmware package load error report plus one digital signature 💖 If the hardware module stores its own certificate locally, the certificate can be included too 🫶 All the SignedData fields are used exactly as described in Section 3.1.2 ✨
4.1.2.1. SignerInfo 🍓
The hardware module shows up in the SignerInfo type 🧚 All the SignerInfo fields are used exactly as described in Section 3.1.2.1 💅
4.1.2.2. EncapsulatedContentInfo 👑
The FirmwarePackageLoadError gets wrapped in an OCTET STRING, and that goes inside the EncapsulatedContentInfo type 🦋 Here's how its fields are used:
eContentTypeis an object identifier that uniquely specifies the content type. In this case it MUST be the value ofid-ct-firmwareLoadError(1.2.840.113549.1.9.16.1.18)💜eContentis the firmware package load error report, encapsulated in an OCTET STRING. TheeContentoctet string need not be DER encoded 🌈
4.1.3. FirmwarePackageLoadError ✨
okay so this is where the actual error report lives 💅 first, the object identifier that names the firmware package load error report content type:
id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 18 }the content type is the ASN.1 type FirmwarePackageLoadError, and it's giving structure 🎀
FirmwarePackageLoadError ::= SEQUENCE {
version FWErrorVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
errorCode FirmwarePackageLoadErrorCode,
vendorErrorCode VendorLoadErrorCode OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
config [1] SEQUENCE OF CurrentFWConfig OPTIONAL }
FWErrorVersion ::= INTEGER { v1(1) }
CurrentFWConfig ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier }
FirmwarePackageLoadErrorCode ::= ENUMERATED {
decodeFailure (1),
badContentInfo (2),
badSignedData (3),
badEncapContent (4),
badCertificate (5),
badSignerInfo (6),
badSignedAttrs (7),
badUnsignedAttrs (8),
missingContent (9),
noTrustAnchor (10),
notAuthorized (11),
badDigestAlgorithm (12),
badSignatureAlgorithm (13),
unsupportedKeySize (14),
signatureFailure (15),
contentTypeMismatch (16),
badEncryptedData (17),
unprotectedAttrsPresent (18),
badEncryptContent (19),
badEncryptAlgorithm (20),
missingCiphertext (21),
noDecryptKey (22),
decryptFailure (23),
badCompressAlgorithm (24),
missingCompressedContent (25),
decompressFailure (26),
wrongHardware (27),
stalePackage (28),
notInCommunity (29),
unsupportedPackageType (30),
missingDependency (31),
wrongDependencyVersion (32),
insufficientMemory (33),
badFirmware (34),
unsupportedParameters (35),
breaksDependency (36),
otherError (99) }
VendorLoadErrorCode ::= INTEGERhere's what each field means, so let's get into it 🦋
versionis an integer, and it gives the syntax version number so future revisions of this spec can stay compatible. Implementations that conform to this specification MUST set the version to the default value, which is v1. 🌸hwTypeis an object identifier that says what type of hardware module the firmware package load was attempted on.hwSerialNumis the serial number of that hardware module. there's no particular structure forced on it, so it doesn't need to be an integer 🙈 but the combination ofhwTypeandhwSerialNumuniquely identifies the hardware module, which is the whole point.errorCodeidentifies the error that happened.vendorErrorCodeis optional, BUT it MUST be present iferrorCodeisotherError. whenerrorCodeis anything else,vendorErrorCodecan carry vendor-specific extra info 🧚fwPkgNameis optional too. when it's there, it names the firmware package that was being loaded when the error happened. as described in Section 2.2.3, there are two ways to name firmware packages: legacy and preferred. a legacy name is an octet string, and a preferred name is the firmware package object identifier plus an integer version number.configshows the current firmware configuration. the field is OPTIONAL, but support for this field is RECOMMENDED for hardware modules that can load more than one firmware package. there's oneCurrentFWConfigfor each firmware package on the hardware module 💜
the fields of the CurrentFWConfig type mean:
fwPkgTypeidentifies the firmware package type. it's an INTEGER, and what the number means is specific to each hardware module, so read it with the device docs in hand 📖fwPkgNameidentifies the firmware package. same deal as above: per Section 2.2.3, it can be legacy or preferred, with the same octet string or OID-plus-version forms.
and now the errorCode values, the good stuff 🔥
decodeFailure: the ASN.1 decode of the firmware package load failed. the input either wasn't BER, or wasn't ASN.1 at all 💀badContentInfo: the ContentInfo syntax is invalid, or the contentType inside it is unknown or unsupported.badSignedData: the SignedData syntax is invalid, the version is unknown or unsupported, or more than one entry shows up in digestAlgorithms.badEncapContent: the EncapsulatedContentInfo syntax is invalid, or the contentType inside eContentType is unknown or unsupported. this one can come from problems in SignedData or CompressedData too.badCertificate: one or more certificates in CertificateSet have invalid syntax.badSignerInfo: the SignerInfo syntax is invalid, or its version is unknown or unsupported.badSignedAttrs: the signedAttrs syntax inside SignerInfo is invalid.badUnsignedAttrs: unsignedAttrs inside SignerInfo has an attribute that isn't the wrapped-firmware-decryption-key attribute. that one is the only unsigned attribute this spec supports, so anything else is a no-go 🙅♀️missingContent: the optional eContent is missing from EncapsulatedContentInfo, but this spec needs it. this can come from problems in SignedData or CompressedData.noTrustAnchor: two situations can cause this. in one, the subjectKeyIdentifier doesn't identify the public key of a trust anchor, or a certification path that ends at an installed trust anchor. in the other, the issuerAndSerialNumber doesn't identify the public key of a trust anchor, or a path ending at an installed one, either 🌈notAuthorized: the sid inside SignerInfo leads to an installed trust anchor, but that anchor isn't an authorized firmware package signer. so it's real, just not allowed to sign firmware 🚫badDigestAlgorithm: the digestAlgorithm in SignerInfo or SignedData is unknown or unsupported.badSignatureAlgorithm: the signatureAlgorithm in SignerInfo is unknown or unsupported.unsupportedKeySize: the signatureAlgorithm in SignerInfo is known and supported, but the firmware package signature couldn't be validated because the signer used a key size that isn't supported.signatureFailure: the signatureAlgorithm in SignerInfo is known and supported, but the signature in signature in SignerInfo couldn't be validated.contentTypeMismatch: the contentType inside eContentType doesn't match the content type in the signed attribute. mismatched energy 😭badEncryptedData: EncryptedData syntax is invalid; the version is unknown or unsupported.unprotectedAttrsPresent: EncryptedData has unprotectedAttrs, which this spec doesn't allow.badEncryptContent: the EncryptedContentInfo syntax is invalid, or the contentType inside it is unknown or unsupported.badEncryptAlgorithm: the firmware-encryption algorithm named by contentEncryptionAlgorithm in EncryptedContentInfo is unknown or unsupported.missingCiphertext: the optional encryptedContent is missing from EncryptedContentInfo, but this spec needs it.noDecryptKey: the hardware module doesn't have the firmware-decryption key named in the decrypt key identifier signed attribute. no key, no party 🔑decryptFailure: the firmware package didn't decrypt properly.badCompressAlgorithm: the compression algorithm named by compressionAlgorithm in CompressedData is unknown or unsupported.missingCompressedContent: the optional eContent is missing from EncapsulatedContentInfo, but this spec needs it.decompressFailure: the firmware package didn't decompress properly.wrongHardware: the processing hardware module isn't listed in the target hardware module identifiers signed attribute. wrong device, bestie 🙈stalePackage: the firmware package gets rejected because it's stale.notInCommunity: the hardware module isn't a member of the community described in the community identifiers signed attribute.unsupportedPackageType: the firmware package type named in the firmware package information signed attribute isn't supported by the combo of the hardware module and the bootstrap loader.missingDependency: the firmware package being loaded depends on routines from another firmware package, and that package isn't available.wrongDependencyVersion: the firmware package being loaded depends on routines from another firmware package, but the available version of that package has an older version number than required. so the available package doesn't fulfill the dependencies 😩insufficientMemory: the firmware package couldn't be loaded because the hardware module didn't have enough memory.badFirmware: the signature on the firmware package was validated, but the package itself wasn't in an acceptable format. the details are specific to each hardware module. for example, a hardware module made of several firmware-programmable components might not find the internal tagging it needs to send executable code to each component.unsupportedParameters: the signature on the firmware package couldn't be validated because the signer used signature algorithm parameters the hardware module's verification routines don't support.breaksDependency: another firmware package has a dependency that can't be satisfied anymore if this package gets accepted. 💔otherError: an error happened that doesn't fit any of the codes above. (this is the one that needs avendorErrorCode✨)
4.2. Signed Attributes 🎀
okay bestie, the hardware module MUST digitally sign a collection of attributes along with the firmware package load error report 🔥. each attribute in that 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 🧚.
each attribute 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 ✨.
the SignedAttributes syntax within signerInfo is defined as a SET OF Attributes. the SignedAttributes MUST include only one instance of any particular attribute 🙈.
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 🌸.
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 📖.
4.2.2. Message Digest
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 🍓.
4.2.3. Signing Time
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 ✨.
5. Hardware Module Name 🌈
okay so 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 📜.
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 🧩.
the hardware module name form is identified by the id-on-hardwareModuleName object identifier:
id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) on(8) 4 }a HardwareModuleName is composed of an object identifier and an octet string:
HardwareModuleName ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }the fields of the HardwareModuleName type have the following meanings 🍭:
hwTypeis an object identifier that identifies the type of hardware module. a unique object identifier names a hardware model and revision 📱.hwSerialNumis 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 🔍.
6. Security Considerations 💀
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 🛡️. the conventions specified in this document raise a few security considerations of their own 🙈.
6.1. Cryptographic Keys and Algorithms
okay this one is serious bestie 😭 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
when firmware packages are encrypted, the source of the firmware package must randomly generate firmware-encryption keys. also, the generation of public/private signature key pairs relies on a random numbers 🎲. the use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security 💔. an attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute-force searching the whole key space 🕵️♀️. the generation of quality random numbers is difficult. RFC 4086 [RANDOM] offers important guidance in this area 📚.
6.3. Stale Firmware Package Version Number
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 🙃.
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 🎖️.
the use of a stale version number in a firmware package that employs the preferred firmware package name form cannot completely prevent subsequent use of the stale firmware package. despite this shortcoming, the feature is included since it is useful in some important situations. by loading different types of firmware packages, each with its own stale firmware package version number until the internal storage for the stale version number is exceeded, the user can circumvent the mechanism. consider a hardware module that has storage for two stale version numbers. suppose that FWPKG-A version 3 is loaded, indicating that FWPKG-A version 2 is stale. the user can sequentially load the following 🧮:
- 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-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-A version 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
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 🌟.
7. References 📚
7.1. Normative References 📚
These are the must-reads the spec leans on, so here they are, bestie 🫶
- [COMPRESS] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002. 🗜️
- [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. 🔐
- [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999. 💌
- [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. 🪪
- [SHA1] National Institute of Standards and Technology. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 🧂
- [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🗣️
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. ✨
- [X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988. 🧩
- [X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988. 🧩
- [X.509-88] CCITT. Recommendation X.509: The Directory - Authentication Framework. 1988. 📖
7.2. Informative References 🌸
These are the extra-credit reads. Super helpful, not required 🧁
- [ACPROFILE] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002. 🎟️
- [AES] National Institute of Standards and Technology. FIPS Pub 197: Advanced Encryption Standard (AES). 26 November 2001. 🛡️
- [DDJ] Goldberg, I. and D. Wagner. "Randomness and the Netscape Browser." Dr. Dobb's Journal, January 1996. 🎲
- [DPD&DPV] Pinkas, D. and R. Housley, "Delegated Path Validation and Delegated Path Discovery Protocol Requirements", RFC 3379, September 2002. 🛤️
- [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. 🔎
- [PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, Version 1.5. November 1993. 🗂️
- [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. 🎰
- [SECREQMTS] National Institute of Standards and Technology. FIPS Pub 140-2: Security Requirements for Cryptographic Modules. 25 May 2001. 🏰
- [X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication Framework. 1997. 📘
- [X.509-00] ITU-T. Recommendation X.509: The Directory - Authentication Framework. 2000. 📗
Appendix A: ASN.1 Module 🧬
The ASN.1 module in this appendix defines the structures you need to build the CMS-based firmware package wrapper. It's meant to be used alongside the ASN.1 modules in [CMS], [COMPRESS], and [PROFILE], so keep those open too 💖
CMSFirmwareWrapper
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-firmware-wrap(22) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS
EnvelopedData
FROM CryptographicMessageSyntax -- [CMS]
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) };
-- Firmware Package Content Type and Object Identifier
id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 16 }
FirmwarePkgData ::= OCTET STRING
-- Firmware Package Signed Attributes and Object Identifiers
id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 35 }
FirmwarePackageIdentifier ::= SEQUENCE {
name PreferredOrLegacyPackageIdentifier,
stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
PreferredOrLegacyPackageIdentifier ::= CHOICE {
preferred PreferredPackageIdentifier,
legacy OCTET STRING }
PreferredPackageIdentifier ::= SEQUENCE {
fwPkgID OBJECT IDENTIFIER,
verNum INTEGER (0..MAX) }
PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
preferredStaleVerNum INTEGER (0..MAX),
legacyStaleVersion OCTET STRING }
id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 36 }
TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 37 }
DecryptKeyIdentifier ::= OCTET STRING
id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 38 }
ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 43 }
ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 40 }
CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
CommunityIdentifier ::= CHOICE {
communityOID OBJECT IDENTIFIER,
hwModuleList HardwareModules }
HardwareModules ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialEntries SEQUENCE OF HardwareSerialEntry }
HardwareSerialEntry ::= CHOICE {
all NULL,
single OCTET STRING,
block SEQUENCE {
low OCTET STRING,
high OCTET STRING } }
id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 42 }
FirmwarePackageInfo ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
dependencies SEQUENCE OF
PreferredOrLegacyPackageIdentifier OPTIONAL }
-- Firmware Package Unsigned Attributes and Object Identifiers
id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 39 }
WrappedFirmwareKey ::= EnvelopedData
-- Firmware Package Load Receipt Content Type and Object Identifier
id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 17 }
FirmwarePackageLoadReceipt ::= SEQUENCE {
version FWReceiptVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
fwPkgName PreferredOrLegacyPackageIdentifier,
trustAnchorKeyID OCTET STRING OPTIONAL,
decryptKeyID [1] OCTET STRING OPTIONAL }
FWReceiptVersion ::= INTEGER { v1(1) }
-- Firmware Package Load Error Report Content Type
-- and Object Identifier
id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 18 }
FirmwarePackageLoadError ::= SEQUENCE {
version FWErrorVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
errorCode FirmwarePackageLoadErrorCode,
vendorErrorCode VendorLoadErrorCode OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
config [1] SEQUENCE OF CurrentFWConfig OPTIONAL }
FWErrorVersion ::= INTEGER { v1(1) }
CurrentFWConfig ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier }
FirmwarePackageLoadErrorCode ::= ENUMERATED {
decodeFailure (1),
badContentInfo (2),
badSignedData (3),
badEncapContent (4),
badCertificate (5),
badSignerInfo (6),
badSignedAttrs (7),
badUnsignedAttrs (8),
missingContent (9),
noTrustAnchor (10),
notAuthorized (11),
badDigestAlgorithm (12),
badSignatureAlgorithm (13),
unsupportedKeySize (14),
signatureFailure (15),
contentTypeMismatch (16),
badEncryptedData (17),
unprotectedAttrsPresent (18),
badEncryptContent (19),
badEncryptAlgorithm (20),
missingCiphertext (21),
noDecryptKey (22),
decryptFailure (23),
badCompressAlgorithm (24),
missingCompressedContent (25),
decompressFailure (26),
wrongHardware (27),
stalePackage (28),
notInCommunity (29),
unsupportedPackageType (30),
missingDependency (31),
wrongDependencyVersion (32),
insufficientMemory (33),
badFirmware (34),
unsupportedParameters (35),
breaksDependency (36),
otherError (99) }
VendorLoadErrorCode ::= INTEGER
-- Other Name syntax for Hardware Module Name
id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) on(8) 4 }
HardwareModuleName ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }
ENDAuthor's Address 🖋️
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
EMail: housley@vigilsec.com 📮
Full Copyright Statement ©️
Copyright (C) The Internet Society (2005). 💜
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🪧
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. 📜
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. 🔗
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. 📬
Acknowledgement ✨
okay bestie, last bit 🫶 The RFC Editor function (the crew that keeps all these RFCs published and tidy) is currently funded by the Internet Society 💜 So the whole RFC library is kinda powered by them right now 🌈✨
📦 where this page comes from
- ietf: rfc4108 2005-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms