Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages
Extracted elements (29)
A complete firmware package load is RECOMMENDED over incremental loading because incremental loading requires dependency tracking, a reference monitor to isolate independent code segments, and makes security evaluation of arbitrary software combinations extremely difficult.
CRLs are excluded from firmware packages by the signer because packages may be pre-signed and stored in repositories, making timely CRL inclusion impractical. A third party MAY insert CRLs before delivery since they are not covered by the signature.
The firmware-decryption key is carried as an unsigned attribute (not a signed one) so that intermediaries in the distribution chain can re-wrap it with different key-encryption keys for each delivery link without invalidating the firmware package signature.
When all three protections are applied, the firmware package is compressed first, then encrypted, then signed. Signing the encrypted (outer) form allows signature verification without decryption, and compressing before encryption yields better compression ratios on unencrypted data.
The bootstrap loader MUST support the subjectKeyIdentifier alternative in SignerInfo.sid to identify the signer's public key directly, enabling trust anchor validation without certificate path construction on memory-constrained hardware modules.
Two firmware package naming forms are supported for backward compatibility: a legacy octet-string form with no imposed structure (to accommodate existing configuration management systems) and a preferred OID-plus-integer form with richer rollback semantics. Bootstrap loaders must support both.
A preferred firmware package version number MUST be a monotonically increasing non-negative integer, and a unique OID MUST identify each distinct collection of features characterizing a firmware package. Each hardware module type and revision MUST be named by a unique OID.
Digitally signed structures MUST be encoded with Distinguished Encoding Rules (DER). Other structures do not require DER, but use of definite length encoding is strongly RECOMMENDED to minimize bootstrap loader implementation complexity.
Hardware modules that support receipt or error report generation MUST have a unique permanent serial number. Those that support signed receipts or error reports MUST also have a private signature key and the corresponding certificate or its designator, installed before deployment.
One or more trust anchors MUST be installed in non-volatile memory prior to deployment using a secure process. Each trust anchor MUST consist of a public key signature algorithm, an associated public key, and a public key identifier.
The bootstrap loader MUST reject a firmware package load if it contains a dependency on a firmware package that is not already loaded, and MUST also reject if the load would leave any existing firmware package's dependencies unsatisfied.
The CMS ContentInfo MUST always be present and MUST encapsulate SignedData (id-signedData, OID 1.2.840.113549.1.7.2). SignedData version MUST be set to 3 and MUST contain exactly one SignerInfo.
The firmware package signer MUST include four signed attributes: content-type, message-digest, firmware-package-identifier, and target-hardware-module-identifiers. If the firmware package is encrypted, the decrypt-key-identifier attribute MUST also be included.
FirmwarePackageLoadError (id-ct-firmwareLoadError, OID 1.2.840.113549.1.9.16.1.18) conveys failure information including hwType, hwSerialNum, fwPkgName, and a structured errorCode field enumerating specific failure reasons such as decodeFailure, badSignature, or communityMismatch.
FirmwarePackageLoadReceipt (id-ct-firmwareLoadReceipt, OID 1.2.840.113549.1.9.16.1.17) contains hwType, hwSerialNum, fwPkgName, and optionally trustAnchorKeyID and decryptKeyID. It may be unsigned (bare ContentInfo) or digitally signed (wrapped in SignedData).
FirmwarePkgData (id-ct-firmwarePackage, OID 1.2.840.113549.1.9.16.1.16) is a simple OCTET STRING that encapsulates the raw firmware package as an opaque binary object, carried at the innermost layer of the CMS encapsulation.
The community-identifiers signed attribute (id-aa-communityIdentifiers, OID …aa.40) restricts loading to authorized communities, expressed as a list of community OIDs or explicit hardware module serial numbers including contiguous block ranges (low/high OCTET STRING pairs).
The firmware-package-identifier signed attribute (id-aa-firmwarePackageID, OID …aa.35) names the firmware package using either a legacy octet-string or a preferred SEQUENCE{OID, INTEGER verNum}, with an optional stale version designator to prevent rollback to flawed versions.
The firmware-package-info signed attribute (id-aa-firmwarePackageInfo, OID …aa.42) carries an optional fwPkgType INTEGER identifying the firmware type (e.g., bootstrap loader vs. application) and an optional sequence of PreferredOrLegacyPackageIdentifier entries specifying inter-package dependencies.
The firmware-package-message-digest attribute (id-aa-fwPkgMessageDigest, OID …aa.41) provides a SEQUENCE{AlgorithmIdentifier, msgDigest OCTET STRING} computed over the raw firmware package before any compression, encryption, or signing, allowing post-load integrity verification.
The wrapped-firmware-decryption-key unsigned attribute (id-aa-wrappedFirmwareKey, OID …aa.39) carries a CMS EnvelopedData wrapping the firmware-decryption key, enabling intermediaries to re-wrap the key with different key-encryption keys at each distribution chain link.
This document registers S/MIME content types id-ct-firmwarePackage (ct.16), id-ct-firmwareLoadReceipt (ct.17), and id-ct-firmwareLoadError (ct.18), and S/MIME signed attribute OIDs id-aa-firmwarePackageID (aa.35) through id-aa-implCompressAlgs (aa.43), all under the S/MIME arc 1.2.840.113549.1.9.16.
Community identifiers provide access control, but are only as strong as the integrity of community membership records. If the bootstrap loader cannot determine community membership, it MUST treat the hardware module as excluded, erring on the side of rejection.
Cryptographic algorithm selection and key lengths must be sufficient to protect the firmware package for its intended lifetime. The algorithms and parameters should be reviewed periodically as cryptanalytic advances occur.
Stale version rollback protection is inherently limited: the inclusion of a stale version designator in a firmware package cannot completely prevent subsequent use of the stale firmware package if the hardware module loads the stale package before ever loading a package with the stale designator.
The bootstrap loader requires access to a high-quality random number generator for signature key operations. Weak or predictable random number generation undermines the security of all cryptographic operations in the firmware loading process.
CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier, each a CHOICE between communityOID (OBJECT IDENTIFIER) or HardwareModules SEQUENCE{hwType OID, hwSerialEntries SEQUENCE OF HardwareSerialEntry}, where HardwareSerialEntry is NULL (all), single OCTET STRING, or block SEQUENCE{low, high OCTET STRING}.
FirmwarePackageIdentifier ::= SEQUENCE { name PreferredOrLegacyPackageIdentifier, stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }, where the preferred form is SEQUENCE{OID fwPkgID, INTEGER verNum} and the legacy form is OCTET STRING.
The CMS encapsulation nesting order when all layers are present is: ContentInfo > SignedData > EncryptedData > CompressedData > FirmwarePkgData. Each layer's contentType OID must consistently identify the next inner layer's type.