Request for Comments: 4108 Vigil Security
Category: Standards Track August 2005
Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the use of the Cryptographic Message Syntax
(CMS) to protect firmware packages, which provide object code for one
or more hardware module components. CMS is specified in RFC 3852. A
digital signature is used to protect the firmware package from
undetected modification and to provide data origin authentication.
Encryption is optionally used to protect the firmware package from
disclosure, and compression is optionally used to reduce the size of
the protected firmware package. A firmware package loading receipt
can optionally be generated to acknowledge the successful loading of
a firmware package. Similarly, a firmware package load error report
can optionally be generated to convey the failure to load a firmware
package.
Table of Contents
1. Introduction ....................................................3
1.1. Terminology ................................................5
1.2. Architectural Elements .....................................5
1.2.1. Hardware Module Requirements ........................7
1.2.2. Firmware Package Requirements .......................8
1.2.3. Bootstrap Loader Requirements .......................9
1.2.3.1. Legacy Stale Version Processing ...........11
1.2.3.2. Preferred Stale Version Processing ........12
1.2.4. Trust Anchors ......................................12
1.2.5. Cryptographic and Compression Algorithm
Requirements .......................................13
1.3. Hardware Module Security Architecture .....................14
1.4. ASN.1 Encoding ............................................14
1.5. Protected Firmware Package Loading ........................15
2. Firmware Package Protection ....................................15
2.1. Firmware Package Protection CMS Content Type Profile ......18
2.1.1. ContentInfo ........................................18
2.1.2. SignedData .........................................18
2.1.2.1. SignerInfo ................................19
2.1.2.2. EncapsulatedContentInfo ...................20
2.1.3. EncryptedData ......................................20
2.1.3.1. EncryptedContentInfo ......................21
2.1.4. CompressedData .....................................21
2.1.4.1. EncapsulatedContentInfo ...................22
2.1.5. FirmwarePkgData ....................................22
2.2. Signed Attributes .........................................22
2.2.1. Content Type .......................................23
2.2.2. Message Digest .....................................24
2.2.3. Firmware Package Identifier ........................24
2.2.4. Target Hardware Module Identifiers .................25
2.2.5. Decrypt Key Identifier .............................26
2.2.6. Implemented Crypto Algorithms ......................26
2.2.7. Implemented Compression Algorithms .................27
2.2.8. Community Identifiers ..............................27
2.2.9. Firmware Package Information .......................29
2.2.10. Firmware Package Message Digest ...................30
2.2.11. Signing Time ......................................30
2.2.12. Content Hints .....................................31
2.2.13. Signing Certificate ...............................31
2.3. Unsigned Attributes .......................................32
2.3.1. Wrapped Firmware Decryption Key ....................33
3. Firmware Package Load Receipt ..................................34
3.1. Firmware Package Load Receipt CMS Content Type Profile ....36
3.1.1. ContentInfo ........................................36
3.1.2. SignedData .........................................36
3.1.2.1. SignerInfo ................................37
3.1.2.2. EncapsulatedContentInfo ...................38
3.1.3. FirmwarePackageLoadReceipt .........................38
3.2. Signed Attributes .........................................40
3.2.1. Content Type .......................................40
3.2.2. Message Digest .....................................40
3.2.3. Signing Time .......................................40
4. Firmware Package Load Error ....................................41
4.1. Firmware Package Load Error CMS Content Type Profile ......42
4.1.1. ContentInfo ........................................42
4.1.2. SignedData .........................................43
4.1.2.1. SignerInfo ................................43
4.1.2.2. EncapsulatedContentInfo ...................43
4.1.3. FirmwarePackageLoadError ...........................43
4.2. Signed Attributes .........................................49
4.2.1. Content Type .......................................49
4.2.2. Message Digest .....................................49
4.2.3. Signing Time .......................................50
5. Hardware Module Name ...........................................50
6. Security Considerations ........................................51
6.1. Cryptographic Keys and Algorithms .........................51
6.2. Random Number Generation ..................................51
6.3. Stale Firmware Package Version Number .....................52
6.4. Community Identifiers .....................................53
7. References .....................................................54
7.1. Normative References ......................................54
7.2. Informative References ....................................54
Appendix A: ASN.1 Module ..........................................56
1. Introduction
This document describes the use of the Cryptographic Message Syntax
(CMS) [CMS] to protect firmware packages. This document also
describes the use of CMS for receipts and error reports for firmware
package loading. The CMS is a data protection encapsulation syntax
that makes use of ASN.1 [X.208-88, X.209-88]. The protected firmware
package can be associated with any particular hardware module;
however, this specification was written with the requirements of
cryptographic hardware modules in mind, as these modules have strong
security requirements.
The firmware package contains object code for one or more
programmable components that make up the hardware module. The
firmware package, which is treated as an opaque binary object, is
digitally signed. Optional encryption and compression are also
supported. When all three are used, the firmware package is
compressed, then encrypted, and then signed. Compression simply
reduces the size of the firmware package, allowing more efficient
processing and transmission. Encryption protects the firmware
package from disclosure, which allows transmission of sensitive
firmware packages over insecure links. The encryption algorithm and
mode employed may also provide integrity, protecting the firmware
package from undetected modification. The encryption protects
proprietary algorithms, classified algorithms, trade secrets, and
implementation techniques. The digital signature protects the
firmware package from undetected modification and provides data
origin authentication. The digital signature allows the hardware
module to confirm that the firmware package comes from an acceptable
source.
If encryption is used, the firmware-decryption key must be made
available to the hardware module via a secure path. The key might be
delivered via physical media or via an independent electronic path.
One optional mechanism for distributing the firmware-decryption key
is specified in Section 2.3.1, but any secure key distribution
mechanism is acceptable.
The signature verification public key must be made available to the
hardware module in a manner that preserves its integrity and confirms
its source. CMS supports the transfer of certificates, and this
facility can be used to transfer a certificate that contains the
signature verification public key (a firmware-signing certificate).
However, use of this facility introduces a level of indirection.
Ultimately, a trust anchor public key must be made available to the
hardware module. Section 1.2 establishes a requirement that the
hardware module store one or more trust anchors.
Hardware modules may not be capable of accessing certificate
repositories or delegated path discovery (DPD) servers [DPD&DPV] to
acquire certificates needed to complete a certification path. Thus,
it is the responsibility of the firmware package signer to include
sufficient certificates to enable each module to validate the
firmware-signer certificate (see Section 2.1.2). Similarly, hardware
modules may not be capable of accessing a certificate revocation list
(CRL) repository, an OCSP responder [OCSP], or a delegated path
validation (DPV) server [DPD&DPV] to acquire revocation status
information. Thus, if the firmware package signature cannot be
validated solely with the trust anchor public key and the hardware
module is not capable of performing full certification path
validation, then it is the responsibility of the entity loading a
package into a hardware module to validate the firmware-signer
certification path prior to loading the package into a hardware
module. The means by which this external certificate revocation
status checking is performed is beyond the scope of this
specification.
Hardware modules will only accept firmware packages with a valid
digital signature. The signature is either validated directly using
the trust anchor public key or using a firmware-signer certification
path that is validated to the trust anchor public key. Thus, the
trust anchors define the set of entities that can create firmware
packages for the hardware module.
The disposition of a previously loaded firmware package after the
successful validation of another firmware package is beyond the scope
of this specification. The amount of memory available to the
hardware module will determine the range of alternatives.
In some cases, hardware modules can generate receipts to acknowledge
the loading of a particular firmware package. Such receipts can be
used to determine which hardware modules need to receive an updated
firmware package whenever a flaw in an earlier firmware package is
discovered. Hardware modules can also generate error reports to
indicate the unsuccessful firmware package loading. To implement
either receipt or error report generation, the hardware module is
required to have a unique permanent serial number. Receipts and
error reports can be either signed or unsigned. To generate
digitally signed receipts or error reports, a hardware module MUST be
issued its own private signature key and a certificate that contains
the corresponding signature validation public key. In order to save
memory with the hardware module, the hardware module might store a
certificate designator instead of the certificate itself. The
private signature key requires secure storage.
1.1. Terminology
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as
described in [STDWORDS].
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, to validate the
signature on the firmware package. If a signed firmware package load
receipt or error report is created on behalf of the hardware module,
then the bootstrap loader MUST have access to a private signature key
to generate the signature and the signer identifier for the
corresponding signature validation certificate or its designator. A
signature validation certificate MAY be included to aid signature
validation. To implement this optional capability, the hardware
module MUST have a unique serial number and a private signature key;
the hardware module MAY also include a certificate that contains the
corresponding signature validation public key. These items MUST be
installed in the hardware module before it is deployed. The private
key and certificate can be generated and installed as part of the
hardware module manufacture process. Figure 1 illustrates these
architectural elements.
ASN.1 object identifiers are the preferred means of naming the
architectural elements.
Details of managing the trust anchors are beyond the scope of this
specification. However, one or more trust anchors MUST be installed
in the hardware module using a secure process before it is deployed.
These trust anchors provide a means of controlling the acceptable
sources of firmware packages. The hardware module vendor can include
provisions for secure, remote management of trust anchors. One
approach is to include trust anchors in the firmware packages
themselves. This approach is analogous to the optional capability
described later for updating the bootstrap loader.
In a cryptographic hardware module, the firmware package might
implement many different cryptographic algorithms.
When the firmware package is encrypted, the firmware-decryption key
and the firmware package MUST both be provided to the hardware
module. The firmware-decryption key is necessary to use the
associated firmware package. Generally, separate distribution
mechanisms will be employed for the firmware-decryption key and the
firmware package. An optional mechanism for securely distributing
the firmware-decryption key with the firmware package is specified in
Section 2.3.1.
+------------------------------------------------------+
| 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
Many different vendors develop hardware modules, and each vendor
typically identifies its modules by product type (family) and
revision level. A unique object identifier MUST name each hardware
module type and revision.
Each hardware module within a hardware module family SHOULD have a
unique permanent serial number. However, if the optional receipt or
error report generation capability is implemented, then the hardware
module MUST have a unique permanent serial number. If the optional
receipt or error report signature capability is implemented, then the
hardware module MUST have a private signature key and a certificate
containing the corresponding public signature validation key or its
designator. If a serial number is present, the bootstrap loader uses
it for authorization decisions (see Section 2.2.8), receipt
generation (see Section 3), and error report generation (see
Section 4).
When the hardware module includes more than one firmware-programmable
component, the bootstrap loader distributes components of the package
to the appropriate components within the hardware module after the
firmware package is validated. The bootstrap loader is discussed
further in Section 1.2.3.
1.2.2. Firmware Package Requirements
Two approaches to naming firmware packages are supported: legacy and
preferred. Firmware package names are placed in a CMS signed
attribute, not in the firmware package itself.
Legacy firmware package names are simply octet strings, and no
structure is assumed. This firmware package name form is supported
in order to facilitate existing configuration management systems. We
assume that the firmware signer and the bootstrap loader will
understand any internal structure to the octet string. In
particular, given two legacy firmware package names, we assume that
the firmware signer and the bootstrap loader will be able to
determine which one represents the newer version of the firmware
package. This capability is necessary to implement the stale version
feature. If a firmware package with a disastrous flaw is released,
subsequent firmware package versions MAY designate a stale legacy
firmware package name in order to prevent subsequent rollback to the
stale version or versions earlier than the stale version.
Preferred firmware package names are a combination of the firmware
package object identifier and a version number. A unique object
identifier MUST identify the collection of features that characterize
the firmware package. For example, firmware packages for a cable
modem and a wireless LAN network interface card warrant distinct
object identifiers. Similarly, firmware packages that implement
distinct suites of cryptographic algorithms and modes of operation,
or that emulate different (non-programmable) cryptographic devices
warrant distinct object identifiers. The version number MUST
identify a particular build or release of the firmware package. The
version number MUST be a monotonically increasing non-negative
integer. Generally, an earlier version is replaced with a later one.
If a firmware package with a disastrous flaw is released, subsequent
firmware package versions MAY designate a stale version number to
prevent subsequent rollback to the stale version or versions earlier
than the stale version.
Firmware packages are developed to run on one or more hardware module
type. The firmware package digital signature MUST bind the list of
supported hardware module object identifiers to the firmware package.
In many cases, the firmware package signature will be validated
directly with the trust anchor public key, avoiding the need to
construct certification paths. Alternatively, the trust anchor can
delegate firmware package signing to another public key through a
certification path. In the latter case, the firmware package SHOULD
contain the certificates needed to construct the certification path
that begins with a certificate issued by the trust anchors and ends
with a certificate issued to the firmware package signer.
The firmware package MAY contain a list of community identifiers.
These identifiers name the hardware modules that are authorized to
load the firmware package. If the firmware package contains a list
of community identifiers, then the bootstrap loader MUST reject the
firmware package if the hardware module is not a member of one of the
identified communities.
When a hardware module includes multiple programmable components, the
firmware package SHOULD contain executable code for all of the
components. Internal tagging within the firmware package MUST tell
the bootstrap loader which portion of the overall firmware package is
intended for each component; however, this tagging is expected to be
specific to each hardware module. Because this specification treats
the firmware package as an opaque binary object, the format of the
firmware package is beyond the scope of this specification.
1.2.3. Bootstrap Loader Requirements
The bootstrap loader MUST have access to a physical interface and any
related driver or protocol software necessary to obtain a firmware
package. The same interface SHOULD be used to deliver receipts and
error reports. Details of the physical interface as well as the
driver or protocol software are beyond the scope of this
specification.
The bootstrap loader can be a permanent part of the hardware module,
or it can be replaced by loading a firmware package. In Figure 1,
the bootstrap loader is implemented as separate logic within the
hardware module. Not all hardware modules will include the ability
to replace or update the bootstrap loader, and this specification
does not mandate such support.
If the bootstrap loader can be loaded by a firmware package, an
initial bootstrap loader MUST be installed in non-volatile memory
prior to deployment. All bootstrap loaders, including an initial
bootstrap loader if one is employed, MUST meet the requirements in
this section. However, the firmware package containing the bootstrap
loader MAY also contain other routines.
The bootstrap loader requires access to cryptographic routines.
These routines can be implemented specifically for the bootstrap
loader, or they can be shared with other hardware module features.
The bootstrap loader MUST have access to a one-way hash function and
digital signature verification routines to validate the digital
signature on the firmware package and to validate the certification