Network Working Group R. Housley
Internet Draft Vigil Security
expires in six months September 2003
Using CMS to Protect Firmware Packages
<draft-housley-cms-fw-wrap-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This document describes the use of the Cryptographic Message Syntax
(CMS) to protect firmware packages. A digital signature is used to
protect the firmware package from undetected modification and provide
data origin authentication. Encryption is optionally used to protect
the firmware from disclosure, and compression is optionally used to
reduce the size of the protected firmware package. A firmware
package loading signed receipt can optionally be generated to
acknowledge the successful loading of a firmware package.
Housley [Page 1]
INTERNET DRAFT September 2003
Table of Contents
Status of this Memo ................................................ 1
Abstract ........................................................... 1
Table of Contents .................................................. 2
1 Introduction ................................................... 4
1.1 Terminology .............................................. 5
1.2 Architectural Elements ................................... 5
1.2.1 Hardware Module Requirements ..................... 7
1.2.2 Firmware Package Requirements .................... 7
1.2.3 Bootstrap Loader Requirements .................... 8
1.2.3.1 Stale Version Processing ............... 10
1.2.4 Trust Anchors .................................... 11
1.2.5 Cryptographic Algorithm Requirements ............. 11
1.3 Hardware Module Security Architecture .................... 12
1.4 ASN.1 Encoding ........................................... 13
1.5 Protected Firmware Package Loading ....................... 13
2 Firmware Package Protection .................................... 14
2.1 Firmware Package Protection CMS Content Type Profile ..... 16
2.1.1 ContentInfo ...................................... 16
2.1.2 SignedData ....................................... 16
2.1.2.1 SignerInfo ............................. 17
2.1.2.2 EncapsulatedContentInfo ................ 18
2.1.3 EncryptedData .................................... 18
2.1.3.1 EncryptedContentInfo ................... 19
2.1.4 CompressedData ................................... 19
2.1.4.1 EncapsulatedContentInfo ................ 20
2.1.5 FirmwarePkgData .................................. 20
2.2 Signed Attributes ........................................ 20
2.2.1 Content Type ..................................... 21
2.2.2 Message Digest ................................... 22
2.2.3 Firmware Package Identifier ...................... 22
2.2.4 Target Hardware Module Identifiers ............... 22
2.2.5 Decrypt Key Identifier ........................... 23
2.2.6 Implemented Crypto Algorithms .................... 23
2.2.7 Community Identifiers ............................ 24
2.2.8 Firmware Package Information ..................... 25
2.2.9 Firmware Package Message Digest .................. 26
2.2.10 Signing Time ..................................... 27
2.2.11 Content Hints .................................... 27
2.2.12 Signing Certificate .............................. 27
2.3 Unsigned Attributes ...................................... 28
2.3.1 Wrapped Firmware-Decryption Key .................. 29
Housley [Page 2]
INTERNET DRAFT September 2003
3 Firmware Package Load Receipt .................................. 29
3.1 Firmware Package Load Receipt CMS Content Type Profile ... 31
3.1.1 ContentInfo ...................................... 31
3.1.2 SignedData ....................................... 32
3.1.2.1 SignerInfo ............................. 33
3.1.2.2 EncapsulatedContentInfo ................ 34
3.1.3 FirmwarePackageLoadReceipt ....................... 34
3.2 Signed Attributes ........................................ 35
3.2.1 Content Type ..................................... 35
3.2.2 Message Digest ................................... 36
3.2.3 Signing Time ..................................... 36
4 Firmware Package Load Error .................................... 36
4.1 Firmware Package Load Error CMS Content Type Profile ..... 37
4.1.1 ContentInfo ....................................... 37
4.1.2 SignedData ....................................... 38
4.1.2.1 SignerInfo ............................. 38
4.1.2.2 EncapsulatedContentInfo ................ 38
4.1.3 FirmwarePackageLoadError .......................... 38
4.2 Signed Attributes ........................................ 43
4.2.1 Content Type ..................................... 43
4.2.2 Message Digest ................................... 44
4.2.3 Signing Time ..................................... 44
5 Hardware Module Name ........................................... 44
6 References ..................................................... 45
6.1 Normative References ..................................... 45
6.2 Informative References ................................... 46
7 Security Considerations ........................................ 46
8 Author Address ................................................. 48
Appendix A: ASN.1 Module .......................................... 49
Full Copyright Statement ........................................... 53
Housley [Page 3]
INTERNET DRAFT September 2003
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 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 can be associated
with any particular hardware module; however, this specification was
written with the requirements of cryptographic hardware modules in
mind, since such modules have strong security requirements.
The firmware package contains object code for one or more processors
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, and then encrypted, and
then signed. Compression simply reduces the size of the firmware
package, allowing more efficient processing and transmission.
Encryption protects the firmware 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 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. This out-of-band
key delivery is beyond the scope of this specification. The key
might be delivered via physical media or delivered via an independent
electronic path.
The signature verification public key must be made available to the
module in a secure fashion. CMS provides for 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
Housley [Page 4]
INTERNET DRAFT September 2003
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 CRL repository, an OCSP
responder [OCSP], or 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, 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 digitally signed
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. To generate digitally signed
receipts, a hardware module is required to have a unique serial
number, its own private signature key to sign the receipt, and a
certificate that contains the corresponding signature validation
public key. 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 firmware 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 firmware
loading receipt is generated, the bootstrap loader uses the private
Housley [Page 5]
INTERNET DRAFT September 2003
signature key to sign the receipt and includes the signature
validation certificate to aid receipt validation. To implement this
optional capability, the hardware module MUST have a unique serial
number, and the private signature key to sign the receipt and the
certificate containing the corresponding signature validation public
key 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 used to name the architectural elements.
+------------------------------------------------------+
| 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 | |
| +------------------------------------+ |
| |
+------------------------------------------------------+
Figure 1. Architectural Elements
Housley [Page 6]
INTERNET DRAFT September 2003
Details of managing the trust anchors are outside 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 authorization to use the
associated firmware package. Generally, separate distribution
mechanisms will be employed for the firmware-decryption key and the
firmware package.
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 family of hardware modules SHOULD have
a unique permanent serial number. However, if the optional receipt
generation capability is implemented, then the hardware module MUST
have a unique permanent serial number, a private signature key, and a
certificate containing the corresponding public signature validation
key. If a serial number is present, the bootstrap loader uses it for
authorization decisions (see section 2.2.7) and receipt generation
(see section 3).
When the hardware module includes more than one processor, the
bootstrap loader distributes components of the package to the
appropriate processors 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
Firmware packages are named by a combination of the firmware package
object identifier and a version number. The firmware package object
identifier and version number are placed in CMS signed attributes,
not in the firmware package itself. A unique object identifier MUST
Housley [Page 7]
INTERNET DRAFT September 2003
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 which
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. In case
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 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 processors, the firmware
package MUST contain object code for all of the processors. Internal
tagging within the firmware package MUST tell the bootstrap loader
which portion of the overall firmware package is intended for each
processor; however, this tagging is expected to be specific to each
hardware module. Since 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 can be a permanent part of the hardware module,
or it can be replaced by loading a firmware package. In Figure 1,
Housley [Page 8]
INTERNET DRAFT September 2003
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 is can be loaded by a firmware package, an
initial bootstrap loader MUST be installed in non-volatile memory
prior to deployment. The firmware package containing the bootstrap
loader MAY also contain other routines.
Regardless of how the bootstrap loader is implemented, the trust
anchors MUST be installed in non-volatile memory prior to deployment.
The bootstrap loader requires access to cryptographic routines.
These routines can be implemented specifically for the bootstrap
loader, or they can be shared with other hardware module features.
The bootstrap loader MUST have access to a one-way hash function and
digital signature verification routines to validate the digital
signature on the firmware package and to validate the certification
path for the firmware-signing certificate.
If firmware packages are encrypted, the bootstrap loader MUST have
access to a decryption routine. Access to a corresponding encryption
function is not required, since hardware modules need not be capable
of generating firmware packages. Since some symmetric encryption
algorithm implementations (such as AES [AES]), employ separate logic
for encryption and decryption, some hardware module savings might
result.
If firmware packages are compressed, the bootstrap loader MUST also
have access to decompression function. The decompression function
can be implemented specifically for the bootstrap loader, or they can
be shared with other hardware module features. Access to a
corresponding compression function is not required, since hardware
modules need not be capable of generating firmware packages.
The bootstrap loader requires access to one or more trusted public
keys, called trust anchors, to validate the firmware package digital
signature. The bootstrap loader MUST reject a firmware package if it
cannot validate the signature, which MAY require the construction of
a valid certification path from the firmware-signing certificate to
one of the trust anchors [PROFILE]. However, in many cases, the
firmware package signature will be validated directly with the trust
anchor public key, avoiding the need to construct certification
paths.
The bootstrap loader MUST reject a firmware package if the list of
supported hardware modules within the firmware package does not
Housley [Page 9]
INTERNET DRAFT September 2003
include the object identifier of the hardware module.
The bootstrap loader MUST reject a firmware package if the firmware
package includes a list of community identifiers and the hardware
module is not a member of one of the listed communities. The means
of determining community membership is beyond the scope of this
specification.
The bootstrap loader MUST reject a firmware package if it cannot
successfully decrypt the firmware package using the firmware-
decryption key available to the hardware module. The firmware
package contains an identifier of the firmware-decryption key needed
for decryption.
When an earlier version of a firmware package is replacing a later
one, the bootstrap loader SHOULD generate a warning. In case a
firmware package with a disastrous flaw is released and subsequent
firmware package versions designate a stale version number, the
bootstrap loader SHOULD prevent loading of the stale version and
versions earlier than the stale version.
1.2.3.1 Stale Version Processing
In case a firmware package with a disastrous flaw is released,
subsequent firmware package versions MAY include a stale version
number to prevent subsequent rollback to the stale version or
versions earlier than the stale version. As described in the
Security Considerations section of this document, the inclusion of a
stale version number in a firmware package cannot completely prevent
subsequent use of the stale firmware package. However, many hardware
modules are expected to have very few firmware packages written for
them, allowing the stale firmware version feature provide important
protections.
Non-volatile storage for stale version number is needed. The number
of stale version numbers that can be stored depends on the amount of
storage that is available. When a firmware package is loaded and it
contains a stale version number, then the object identifier of the
firmware package and the stale version number SHOULD be added to a
list that is kept in non-volatile storage. When subsequent firmware
packages are loaded, the object identifier and version number of the
new package is are compared to the list in non-volatile storage. If
there is a match, then the new firmware packages SHOULD be rejected.
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.
Housley [Page 10]
INTERNET DRAFT September 2003
1.2.4 Trust Anchors
A trust anchor MUST consist of a public key signature algorithm and
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 issuer name.
The trust anchor public key is used in conjunction with the signature
validation algorithm in two different ways. First, the trust anchor
public key is used directly to validate the firmware package
signature. Second, the trust anchor public key is used to validate
an X.509 certification path, and then the subject public key in the
final certificate in the certification path is used to validate the
firmware package signature.
The public key identifier names the trust anchor, and it is used when
the trust anchor is used directly to validate firmware package
signatures. This key identifier can be stored with the trust anchor,
or if the recommended method of computing the key identifier is
followed, it can be computed from the public key whenever needed.
The key identifier is RECOMMENDED to be the 160-bit SHA-1 hash [SHA1]
of the public key. X.509 certificates encode public keys as a BIT
STRING [PROFILE]. The public key is encoded in this format, and then
the SHA-1 hash is computed on the BIT STRING value, excluding the
tag, length, and number of unused bits.
The optional trusted issuer name can be used when the trust anchor
public key is used to validate an X.509 certification path.
1.2.5 Cryptographic Algorithm Requirements
Firmware for cryptographic hardware modules includes cryptographic
algorithm implementations. In addition, firmware for non-
cryptographic hardware modules will likely include cryptographic
algorithm implementations to support the Bootstrap Loader in the
validation of firmware packages.
A unique algorithm object identifier MUST be assigned for each
algorithm and mode implemented by a firmware package. The algorithm
object identifiers can be used to determine whether a particular
firmware package satisfies the needs of a particular application. To
facilitate the development of algorithm agile applications, the
cryptographic module interface SHOULD allow applications to query the
cryptographic module for the object identifiers associated with each
cryptographic algorithm contained in the currently loaded firmware
package. Applications SHOULD also be able to query the cryptographic
module to determine attributes associated with each algorithm. Such
Housley [Page 11]
INTERNET DRAFT September 2003
attributes might include the algorithm type (symmetric encryption,
asymmetric encryption, key agreement, one-way hash function, digital
signature, and so on), the algorithm block size or modulus size, and
parameters for asymmetric algorithms. This specification does not
establish the conventions for the retrieval of algorithm identifiers
or algorithm attributes.
1.3 Hardware Module Security Architecture
In most hardware module designs, the firmware execution environment
offers a single address space. When a single address space is
offered, the firmware package MUST contain a complete firmware load
for hardware module. That is, the firmware package cannot be a
partial or incremental set of functions. This requirement is
motivated by a desire to minimize complexity and avoid potential
security problems. From a complexity perspective, if the incremental
loading of packages were permitted, it would be necessary for each
package to identify any other packages that are required (its
dependencies), and the bootstrap loader would have to verify that all
of the dependencies were satisfied before attempting to execute the
firmware. Two security-relevant observations motivate this
requirement. First, if the hardware module were based on a general
purpose processor or a digital signal processor, it would be
dangerous to allow such packages to be loaded simultaneously unless
there is a reference monitor to ensure that independent portions of
the code cannot interfere with one another. Second, it is difficult
evaluate arbitrary combinations of software modules [SECREQMTS].
Even when a single address space is offered by the execution
environment, the hardware module MAY accommodate separate loading of
the bootstrap loader and the firmware package. In this hardware
module design, the bootstrap loader and the rest of the firmware are
stored in separate portions of non-volatile memory. The firmware
package MAY depend on routines that are part of the bootstrap loader
such as a memory manager, heap manager, one-way hash function, or
digital signature processing. To minimize the security evaluation
complexity of this hardware module employing such a design, the
firmware package MUST identify the package identifier and minimum
version number of the bootstrap loader. The bootstrap loader MUST
reject a firmware package load if it contains a bootstrap loader
identifier other than the one that is executing or the identified
bootstrap loader version is greater than the one that is executing.
A few hardware module architectures employ a separation kernel to
provide more than one space for firmware execution. In this
architecture, the bootstrap loader is used to separately load the
separation kernel and firmware packages. The bootstrap loader MAY be
permanently stored in read-only memory or separately loaded into non-
Housley [Page 12]
INTERNET DRAFT September 2003
volatile memory as discussed above. The separation kernel and the
other firmware packages are each stored in separate portions of non-
volatile memory. The firmware packages MAY have dependencies on
routines provided by the separation kernel or the bootstrap loader.
To minimize the security evaluation complexity of this hardware
module employing such a design, the firmware package must identify
the package identifiers and minimum version numbers of the separation
kernel and bootstrap loader. The bootstrap loader MUST reject a
firmware package load if it contains a separation kernel identifier
other than the one that is already loaded or the identified
separation kernel version is greater than the one that is already
loaded. Likewise, the bootstrap loader MUST reject a firmware
package load if it contains a bootstrap loader identifier other than
the one that is executing or the identified bootstrap loader version
is greater than the one that is executing.
1.4 ASN.1 Encoding
The CMS makes use of Abstract Syntax Notation One (ASN.1) [X.208-88,
X.209-88]. ASN.1 is a formal notation used for describing data
protocols, regardless of programming language used by the
implementation. Encoding rules describe how the values defined in
ASN.1 will be represented for transmission. The Basic Encoding Rules
(BER) are the most widely employed rule set, but they offer more than
one way to represent data structures. For example, definite length
encoding and indefinite length encoding are supported. This
flexibility is not desirable when digital signatures are use in a
system. As a result, the Distinguished Encoding Rules (DER)
[X.509-88] were invented. DER is a subset of BER which ensures a
single way to represent a given value. For example, DER always
employs definite length encoding.
In this specification, digitally signed structures MUST be encoded
with DER. Other structures do not require DER, but the use of
definite length encoding is strongly RECOMMENDED. By always using
definite length encoding, the bootstrap loader will have fewer
options to implement.
1.5 Protected Firmware Package Loading
This document does not attempt to specify a protocol for loading
firmware packages. Many different delivery mechanisms are
envisioned, including portable memory devices, file transfer, and web
pages. Section 2 of this specification defines the format that MUST
be presented to the hardware module regardless of the interface that
is used. This specification also specifies the format of the
response that MAY be generated by the hardware module. Section 3 of
this specification defines the format that MAY be returned by the
Housley [Page 13]
INTERNET DRAFT September 2003
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
The Cryptographic Message Syntax (CMS) is used to protect firmware,
which is treated as an opaque binary object. A digital signature is
used to protect the firmware package from undetected modification and
provide data origin authentication. Encryption is optionally used to
protect the firmware from disclosure, and compression is optionally
used to reduce the size of the protected firmware package. The CMS
ContentInfo content type MUST always be present, and it MUST
encapsulate the CMS SignedData content type. If the firmware package
is encrypted, then the CMS SignedData content type MUST encapsulate
the CMS EncryptedData content type. If the firmware package is
compressed, then either the CMS SignedData content type (when
encryption is not used) or the CMS EncryptedData content type (when
encryption is used) MUST encapsulate the CMS CompressedData content
type. Finally, either the CMS SignedData content type (when neither
encryption nor compression is used) or the CMS EncryptedData content
type (when encryption is used, but compression is not used) or CMS
CompressedData content type (when compression is used) MUST
encapsulate the simple firmware package using the FirmwarePkgData
content type defined in this specification (see section 2.1.5).
The firmware protection is summarized by (see [CMS] for the full
syntax):
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData
}
SignedData {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Signer certification path
crls CertificateRevocationLists, -- Omit
signerInfos SET OF SignerInfo -- Only one
}
Housley [Page 14]
INTERNET DRAFT September 2003
SignerInfo {
version CMSVersion,
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,
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,
compressionAlgorithm CompressionAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo
}
Housley [Page 15]
INTERNET DRAFT September 2003
EncapsulatedContentInfo {
eContentType id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
eContent OCTET STRING -- Contains FirmwarePkgData
}
FirmwarePkgData OCTET STRING -- Contains the firmware
2.1 Firmware Package Protection CMS Content Type Profile
This section specifies the conventions for using the CMS ContentInfo,
SignedData, EncryptedData, and CompressedData content types. It also
defines the FirmwarePkgData content type.
2.1.1 ContentInfo
The CMS requires the outer most encapsulation to be ContentInfo
[CMS]. The fields of ContentInfo are used as follows:
contentType indicates the type of the associated content, and in
this case, the encapsulated type is always SignedData. The id-
signedData (1.2.840.113549.1.7.2) object identifier MUST be
present in this field.
content holds the associated content, and in this case, the
encapsulated SignedData MUST be present in this field.
2.1.2 SignedData
The SignedData content type [CMS] contains the signed firmware
package (which might be compressed, encrypted, or compressed and then
encrypted prior to signature), the certificates needed to validate
the signature, and one digital signature value. The fields of
SignedData are used as follows:
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
employed by the firmware signer MUST be present.
encapContentInfo is the signed content, consisting of a content
type identifier and the content itself. The use of the
EncapsulatedContentInfo type is discussed further in section
2.1.2.2.
Housley [Page 16]
INTERNET DRAFT September 2003
certificates is an optional collection of certificates. If the
trust anchor directly signed the firmware package, then
certificates SHOULD be omitted. If the trust anchor signed a
certificate, then certificates MUST include the X.509 certificate
of the firmware signer. The set of certificates MAY be sufficient
for the bootstrap loader to construct a certification path from
the trust anchor to the firmware signer's certificate. PKCS#6
extended certificates [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), and in this case, CRLs MUST NOT be included. It is
anticipated that firmware packages may be generated, signed, and
made available in repositories for downloading into hardware
modules. In such contexts, it would be difficult to include
timely CRLs in the firmware package.
signerInfos is a collection of per-signer information, and in this
case, the collection MUST contain exactly one SignerInfo. The use
of the SignerInfo type is discussed further in section 2.1.2.1.
2.1.2.1 SignerInfo
The firmware signer is represented in the SignerInfo type. The
fields of SignerInfo are used as follows:
version is the syntax version number, and it MUST be 3.
sid identifies the signer's public key. CMS supports two
alternatives: issuerAndSerialNumber and subjectKeyIdentifier.
However, the bootstrap loader MUST support the
subjectKeyIdentifier alternative. The subjectKeyIdentifier
alternative identifies the signer's public key directly. When
this public key is contained in a certificate, this identifier
appears in the X.509 subjectKeyIdentifier extension. Public key
identifiers SHOULD be assigned using one of the methods specified
in section 4.2.1.2 of RFC 3280 [PROFILE].
digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the firmware signer. It MUST
contain the message digest algorithms employed by the signer of
the encrypted firmware package. (Note that 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 are
signed along with the content. The signedAttrs are optional in
Housley [Page 17]
INTERNET DRAFT September 2003
the CMS, but in this specification, signedAttrs are REQUIRED for
the firmware package. However, implementations MAY ignore
unrecognized signed attributes. The SET OF attributes MUST be DER
encoded [X.509-88]. Section 2.2 of this document lists the
attributes that MUST be included in the collection; other
attributes MAY be included as well.
signatureAlgorithm identifies the signature algorithm, and any
associated parameters, used by the firmware signer 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 encapsulates the firmware
package, which might be compressed, encrypted, or compressed and then
encrypted prior to signature. The firmware package, in any of these
formats, is carried within the EncapsulatedContentInfo type. The
fields of EncapsulatedContentInfo are used as follows:
eContentType is an object identifier that uniquely specifies the
content type, and in this case, the value MUST be either id-
encryptedData (1.2.840.113549.1.7.6), id-ct-compressedData
(1.2.840.113549.1.9.16.1.9), or id-ct-firmwarePackage
(1.2.840.113549.1.9.16.1.16). When it contains id-encryptedData,
then the firmware packages was encrypted prior to signing, and the
firmware package may also have been compressed prior to
encryption. When it contains id-ct-compressedData, then the
firmware package was compressed prior to signing, but the firmware
package was not encrypted. When it contains id-ct-
firmwarePackage, then the firmware package was not compressed or
encrypted prior to signing.
eContent is the encrypted firmware, encoded as an octet string.
The eContent octet string need not be DER encoded.
2.1.3 EncryptedData
The EncryptedData content type [CMS] contains the encrypted firmware
package (which might be compressed prior to encryption). However, if
the firmware package was not encrypted, the EncryptedData content
type is not present. The fields of EncryptedData are used as
Housley [Page 18]
INTERNET DRAFT September 2003
follows:
version is the syntax version number, and in this case, version
MUST be 0.
encryptedContentInfo is the encrypted content information. The
use of the EncryptedContentInfo type is discussed further 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
The encrypted firmware package is encapsulated in the
EncryptedContentInfo type. The fields of EncryptedContentInfo are
used as follows:
contentType indicates the type of content, and in this case, it
MUST contain either id-ct-compressedData
(1.2.840.113549.1.9.16.1.9) or id-ct-firmwarePackage
(1.2.840.113549.1.9.16.1.16). When it contains id-ct-
compressedData, then the firmware package was compressed prior to
encryption. When it contains id-ct-firmwarePackage, then the
firmware package was not compressed prior to encryption.
contentEncryptionAlgorithm identifies the firmware-encryption
algorithm, and any associated parameters, used to encrypt the
firmware package.
encryptedContent is the result of encrypting the firmware package.
The field is optional; however, in this case, it MUST be present.
2.1.4 CompressedData
The CompressedData content type [COMPRESS] contains the compressed
firmware package. If the firmware package was not compressed, then
the CompressedData content type is not present. The fields of
CompressedData are used as follows:
version is the syntax version number; in this case, it MUST be 0.
compressionAlgorithm identifies the compression algorithm, and any
associated parameters, used to compress the firmware package.
encapContentInfo is the compressed content, consisting of a
content type identifier and the content itself. The use of the
Housley [Page 19]
INTERNET DRAFT September 2003
EncapsulatedContentInfo type is discussed further in section
2.1.4.1.
2.1.4.1 EncapsulatedContentInfo
The CompressedData content type encapsulates the compressed firmware
package, and it carried within the EncapsulatedContentInfo type. The
fields of EncapsulatedContentInfo are used as follows:
eContentType is an object identifier that uniquely specifies the
content type, and in this case, it MUST be the value of id-ct-
firmwarePackage (1.2.840.113549.1.9.16.1.16).
eContent is the compressed firmware, 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
is a straightforward encapsulation 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 STRING
2.2 Signed Attributes
The firmware signer MUST digitally sign a collection of attributes
along with the firmware package. Each attribute in the collection
MUST be DER encoded [X.509-88]. The syntax for attributes is defined
in [CMS], but it is repeated here for convenience:
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANY
Each of the attributes used with this profile has a single attribute
value, even though the syntax is defined as a SET OF AttributeValue.
Housley [Page 20]
INTERNET DRAFT September 2003
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 firmware signer MUST include the following four attributes:
content-type, message-digest, firmware-package-identifier, and
target-hardware-module-identifiers.
If the firmware package is encrypted, then the firmware signer MUST
also include the decrypt-key-identifier attribute.
If the firmware package implements cryptographic algorithms, then the
firmware signer MUST also include the implemented-crypto-algorithms
attribute.
If the firmware package is intended for use only by specific
communities, then the firmware signer MUST also include the
community-identifiers attribute.
If the firmware package contains a bootstrap loader or a separation
kernel, then the firmware signer MUST also include the firmware-
package-info attribute. Also, if the firmware package contains a
dependency on a particular bootstrap loader or separation kernel,
then the firmware signer MUST also include the firmware-package-info
attribute.
The firmware signer SHOULD also include the three following
attributes: firmware-package-message-digest, signing-time, and
content-hints. Additionally, if the firmware signer has a
certificate (meaning that the firmware signer in not always
configured as a trust anchor), then the firmware signer SHOULD also
include signing-certificate attribute.
The firmware signer MAY include any other attribute that it deems
appropriate.
2.2.1 Content Type
The firmware signer MUST include a content-type attribute with the
value of id-encryptedData (1.2.840.113549.1.7.6), id-ct-
compressedData (1.2.840.113549.1.9.16.1.9), or id-ct-firmwarePackage
(1.2.840.113549.1.9.16.1.16). When it contains id-encryptedData,
then the firmware packages was encrypted prior to signing. When it
contains id-ct-compressedData, then the firmware package was
compressed prior to signing, but the firmware package was not
encrypted. When it contains id-ct-firmwarePackage, then the firmware
Housley [Page 21]
INTERNET DRAFT September 2003
package was not compressed or encrypted prior to signing. Section
11.1 of [CMS] defines the content-type attribute.
2.2.2 Message Digest
The firmware signer MUST include a message-digest attribute, having
as its value the message digest computed on the encapContentInfo
eContent octet string. This octet string contains the firmware
package, and it MAY be compressed, encrypted, or both compressed and
encrypted. Section 11.2 of [CMS] defines the message-digest
attribute.
2.2.3 Firmware Package Identifier
The firmware-package-identifier attribute type names the protected
firmware package with an object identifier and a version number. The
object identifier names a collection of functions implemented by the
firmware package, and the version number is a non-negative integer
that identifies a particular build or release of the firmware
package.
In case a firmware package with a disastrous flaw is released, the
firmware package that repairs the previously distributed flaw MAY
designate a stale version number to prevent the reloading of the
flawed version. The hardware module bootstrap loader SHOULD prevent
subsequent rollback to the stale version or versions earlier than the
stale version.
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 {
fwPkgID OBJECT IDENTIFIER,
verNum INTEGER (0..MAX),
staleVerNum INTEGER (0..MAX) OPTIONAL }
2.2.4 Target Hardware Module Identifiers
The target-hardware-module-identifiers attribute type names the types
of hardware modules that the firmware package supports. A unique
object identifier names each supported hardware model and revision.
Housley [Page 22]
INTERNET DRAFT September 2003
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 IDENTIFIER
2.2.5 Decrypt Key Identifier
The decrypt-key-identifier attribute type names the symmetric key
needed to decrypt the encapsulated firmware package. No particular
structure is imposed on the key identifier. The means by which the
firmware-decryption key is securely distributed to all modules that
are authorized to use the associated firmware package is beyond the
scope of this specification.
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 STRING
2.2.6 Implemented Crypto Algorithms
The implemented-crypto-algorithms attribute type names the
cryptographic algorithms that are implemented by the firmware package
and available to applications. Only those algorithms that are made
available at the interface of the cryptographic module are to be
listed. Any cryptographic algorithm that is used internally and not
accessible via the cryptographic module interface MUST NOT be listed.
For example, if the firmware package implements the decryption
algorithm for future firmware installations and this algorithm is not
made available outside the cryptographic module, then the firmware-
decryption algorithm would not be listed.
The object identifier portion of its AlgorithmIdentifier identifies
Housley [Page 23]
INTERNET DRAFT September 2003
each algorithm.
The following object identifier identifies the implemented-crypto-
algorithms attribute:
id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 38 }
The implemented-crypto-algorithms attribute values have ASN.1 type
ImplementedCryptoAlgorithms:
ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
2.2.7 Community Identifiers
The community-identifiers attribute type names the communities that
are permitted to execute the firmware package. The bootstrap loader
MUST reject the firmware package if the hardware module is not a
member of one of the identified communities. The means of assigning
community membership is beyond the scope of this specification.
The community-identifiers attribute type names the authorized
communities by a list of community object identifiers, by a list of
hardware module identifiers, or by a combination of the two lists. A
hardware module identifier is an object identifier that names the
hardware module type and a serial number. To facilitate compact
representation of serial numbers, a contiguous block can be specified
by the lowest authorized serial number and the highest authorized
serial number.
If the bootstrap loader does not have a mechanism for obtaining a
list of object identifiers that identify the communities to which the
hardware module is a member, then the bootstrap loader MUST behave as
though the list is empty. Similarly, if the bootstrap loader does
not have access to the hardware module serial number, then the
bootstrap loader MUST behave as though the hardware module is not
included on the list of authorized hardware modules.
The following object identifier identifies the community-identifiers
attribute:
id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 40 }
Housley [Page 24]
INTERNET DRAFT September 2003
The community-identifiers attribute 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 {
single OCTET STRING,
block SEQUENCE {
low OCTET STRING,
high OCTET STRING } }
2.2.8 Firmware Package Information
If the firmware package contains a bootstrap loader or a separation
kernel, then the firmware signer MUST also include the firmware-
package-info attribute to identify the firmware package type. Also,
if the firmware package contains a dependency on another formware
package, then the firmware signer MUST also include the firmware-
package-info attribute to explicitly identify the dependencies.
The firmware-package-info attribute identifies the firmware package
type as a bootstrap loader, a separation kernel, or an application.
The firmware-package-info attribute optionally identifies
dependencies. Bootstrap loader packages MUST NOT contain any
dependencies. Separation kernel packages SHOULD only contain
dependencies on the bootstrap loader. Application packages SHOULD
only contain dependencies on the bootstrap loader and the separation
kernel. Dependencies are identified by the firmware package
identifier, which is an object identifier, and the minimum version of
that firmware package, which is an integer.
The bootstrap loader MUST reject a firmware package load if it
identifies a dependency on a bootstrap loader identifier other than
the one that is executing or the identified bootstrap loader version
is greater than the one that is executing.
The bootstrap loader MUST reject a firmware package load if it
identifies a dependency on a separation kernel identifier other than
the one that is already loaded or the identified separation kernel
Housley [Page 25]
INTERNET DRAFT September 2003
version is greater than the one that is already loaded.
The following object identifier identifies the firmware-package-info
attribute:
id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 42 }
The firmware-package-info attribute values have ASN.1 type
FirmwarePackageInfo:
FirmwarePackageInfo ::= SEQUENCE {
fwPkgType FWPackageType DEFAULT firmwarePackage,
dependencies SEQUENCE OF FWPackageRef OPTIONAL }
FWPackageType ::= ENUMERATED {
bootstrapLoader (1),
separationKernel (2),
application (3) }
FWPackageRef ::= SEQUENCE {
fwPkgID OBJECT IDENTIFIER,
minVerNum INTEGER }
2.2.9 Firmware Package Message Digest
The firmware signer SHOULD include a firmware-package-message-digest
attribute, which provides the message digest algorithm and the
message digest value computed on the firmware package. The message
digest is computed on the firmware package prior to any compression,
encryption, or signature processing. The bootstrap loader MAY use
this message digest to confirm that the intended firmware package has
been recovered after all of the layers of encapsulation are removed.
The following object identifier identifies the firmware-package-
message-digest attribute:
id-aa-fwPkgMessageDigest OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 41 }
The firmware-package-message-digest attribute values have ASN.1 type
FirmwarePackageMessageDigest:
FirmwarePackageMessageDigest ::= SEQUENCE {
algorithm AlgorithmIdentifier,
Housley [Page 26]
INTERNET DRAFT September 2003
msgDigest OCTET STRING }
2.2.10 Signing Time
The firmware signer SHOULD include a signing-time attribute,
specifying the time at which the signature was applied to the
encrypted firmware. Section 11.3 of [CMS] defines the signing-time
attribute.
2.2.11 Content Hints
The firmware signer SHOULD include a content-hints attribute,
including a brief text description of the firmware package. The text
is encoded in UTF-8, which supports most of the world's writing
systems [UTF-8]. Section 2.9 of [ESS] defines the content-hints
attribute.
The configuration management systems employed by firmware package
developers will probably not align with the firmware package naming
convention required by this specification. A firmware package name
associated with such a configuration management system might look
something like "R1234.C0(AJ11).D62.A02.11(b)" and these strings are
only meaningful to the developers. Including these firmware package
names in the text description may be helpful to developers by
providing a clear linkage between the two kinds of names.
The content-hints attribute contains two fields, and in this case,
both fields MUST be present. The fields of ContentHints are used as
follows:
contentDescription provides a brief text description of the
firmware package.
contentType provides the content type of the inner most content
type, and in this case, it MUST be id-ct-firmwarePackage
(1.2.840.113549.1.9.16.1.16).
2.2.12 Signing Certificate
When this firmware signer's public key is contained in a certificate,
firmware signer SHOULD include a signing-certificate attribute to
identify the certificate that was employed. However, if the firmware
package signature does not have a certificate (meaning that the
signature will only be validated with the trust anchor public key),
then the firmware signer is unable to include a signing-certificate
attribute. Section 5.4 of [ESS] defines the signing-certificate
attribute.
Housley [Page 27]
INTERNET DRAFT September 2003
The signing-certificate attribute contains two fields: certs and
policies. The certs field MUST be present, and the policies field
MAY be present. The fields of SigningCertificate are used as
follows:
certs contains a sequence of certificate identifiers. In this
case, sequence of certificate identifiers contains a single entry.
The certs field MUST contain only the certificate identifier of
the certificate that contains the public key used to verify the
firmware signature. The certs field uses the ESSCertID syntax
specified in section 5.4 of [ESS], and it is comprised of the
SHA-1 hash [SHA1] of the entire ASN.1 DER encoded certificate and,
optionally, the certificate issuer and the certificate serial
number. The SHA-1 hash value MUST be present. The certificate
issuer and the certificate serial number SHOULD be present.
policies is optional, and when it is present, it contains a
sequence of policy information. In this case, the sequence of
policy information contains a single entry. The policies field,
when present, MUST contain only one entry, and that entry MUST
match one of the certificate policies in the certificate policies
extension of the certificate that contains the public key used to
verify the firmware signature. The policies field uses the
PolicyInformation syntax specified in section 4.2.1.5 of
[PROFILE], and it is comprised of the certificate policy object
identifier and, optionally, certificate policy qualifiers. The
certificate policy object identifier MUST be present. The
certificate policy qualifiers SHOULD NOT be present.
2.3 Unsigned Attributes
CMS allows a SET of unsigned attributes to be included; however, in
this specification, the set MUST be absent or include a single
instance of the wrapped-firmware-decryption-key attribute. Since the
digital signature does not cover this attribute, it can be altered at
any point in the delivery path from the firmware signer to the
hardware module. This property can be employed to distribute the
firmware-decryption key along with an encrypted and signed firmware
package, allowing the firmware-decryption key to be wrapped with a
different key-encryption key for each link in the distribution chain.
The syntax for attributes is defined in [CMS], and it is repeated at
the beginning of section 2.2 of this document for convenience. Each
of the attributes used with this profile has a single attribute
value, even though the syntax is defined as a SET OF AttributeValue.
There MUST be exactly one instance of AttributeValue present.
The UnsignedAttributes syntax within signerInfo is defined as a SET
Housley [Page 28]
INTERNET DRAFT September 2003
OF Attributes. The UnsignedAttributes MUST include only one instance
of any particular attribute.
2.3.1 Wrapped Firmware Decryption Key
The firmware 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 ASN.1 type
of EnvelopedData. Section 6 of [CMS] defines the EnvelopedData
content type, which is used to construct the value of the attribute.
EnvelopedData permits the firmware-decryption key to be protected
using symmetric or asymmetric techniques. The EnvelopedData does not
include an encrypted content, as the key normally used to decrypt the
encapsulated content is the firmware-decryption key. Section 6 of
[CMS] refers to this key as the content-encryption key.
The EnvelopedData syntax support many 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]. Additional rules apply when
EnvelopedData is used as a wrapped-firmware-decryption-key attribute.
Within the EnvelopedData structure:
- The set of certificates included in OriginatorInfo MUST NOT
include certificates with a type of extendedCertificate or
v1AttrCert.
- The optional unprotectedAttrs field MUST NOT be present.
Housley [Page 29]
INTERNET DRAFT September 2003
Within the EncryptedContentInfo structure:
- contentType MUST contain id-data (1.2.840.113549.1.7.1).
- contentEncryptionAlgorithm identifies the firmware-encryption
algorithm, and any associated parameters, used to encrypt the
firmware package.
- encryptedContent is optional, and in this case, it MUST NOT
be present.
3 Firmware Package Load Receipt
The Cryptographic Message Syntax (CMS) is used to indicate that a
firmware package loaded successfully. Support for firmware package
load receipts is OPTIONAL. However, those hardware modules that
choose to generate such receipts MUST follow the conventions
specified in this section. Since not all hardware modules will have
private signature keys, the firmware package load receipt can either
be signed or unsigned. Use of the signed firmware package load
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, and
a corresponding signature validation certificate to include in the
receipt to aid validation.
The unsigned firmware package load receipt is encapsulated by
ContentInfo. Alternatively, the signed firmware package load error
report is encapsulated by SignedData, which is in turn encapsulated
by ContentInfo.
The firmware package load receipt protection is summarized by (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 --
OCTET STRING -- which encapsulates
-- FirmwarePackageLoadReceipt
}
Housley [Page 30]
INTERNET DRAFT September 2003
SignedData {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Module certificate
crls CertificateRevocationLists, -- Omit
signerInfos SET OF SignerInfo -- Only one
}
SignerInfo {
version CMSVersion,
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 {
hwType OBJECT IDENTIFIER, -- Hardware module type
hwSerialNum OCTET STRING, -- H/W module serial number
fwPkgID OBJECT IDENTIFIER, -- Package identifier
verNum INTEGER, -- Release or build number
trustAnchorKeyID OCTET STRING, -- Optional
decryptKeyID OCTET STRING -- Optional
}
3.1 Firmware Package Load Receipt CMS Content Type Profile
This section specifies the conventions for using the CMS ContentInfo
and SignedData content types for firmware package load receipts. It
also defines the firmware package load receipt content type.
3.1.1 ContentInfo
The CMS requires the outer most encapsulation to be ContentInfo
[CMS]. The fields of ContentInfo are used as follows:
contentType indicates the type of the associated content. If the
firmware load receipt is signed, then the encapsulated type MUST
be SignedData, and the id-signedData (1.2.840.113549.1.7.2) object
Housley [Page 31]
INTERNET DRAFT September 2003
identifier MUST be present in this field. If the firmware load
receipt is not signed, then the encapsulated type MUST be
FirmwarePackageLoadReceipt, and the id-ct-firmwareLoadReceipt
(1.2.840.113549.1.9.16.1.17) object identifier MUST be present in
this field.
content holds the associated content. If the firmware load
receipt is signed, then the encapsulated SignedData MUST be
present in this field. If the firmware load error report is not
signed, then this field MUT contain an OCTET STRING, and that
OCTET STRING MUST encapsulate the FirmwarePackageLoadReceipt.
3.1.2 SignedData
The SignedData content type consists the firmware package load
receipt, the hardware module certificate, and one digital signature.
The fields of SignedData are used as follows:
version is the syntax version number, and in this case, is 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 algorithms
employed by the hardware module MUST be present.
encapContentInfo is the signed content, consisting of a content
type identifier and the content itself. The use of the
EncapsulatedContentInfo type is discussed further in section
3.1.2.2.
certificates is an optional collection of certificates, and in
this case, it MUST include the X.509 certificate of the hardware
module. 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), and in this case, CRLs MUST NOT be included. (Hardware
modules will probably not have the ability to obtain the most
recent CRLs for inclusion.)
signerInfos is a collection of per-signer information, and in this
case, the collection MUST contain exactly one SignerInfo. The use
of the SignerInfo type is discussed further in section 3.1.2.1.
Housley [Page 32]
INTERNET DRAFT September 2003
3.1.2.1 SignerInfo
The hardware module is represented in the SignerInfo type. The
fields of SignerInfo are used as follows:
version is the syntax version number, and it MUST be either 1 or
3, depending on the method used to identify the hardware module's
public key. The use of the subjectKeyIdentifier is RECOMMENDED,
which results in the use of version 3.
sid specifies the hardware module's certificate (and thereby the
hardware module's public key). CMS supports two alternatives:
issuerAndSerialNumber and subjectKeyIdentifier. However, the
hardware module MUST support only one of the alternatives. The
issuerAndSerialNumber alternative identifies the hardware module's
certificate by the issuer's distinguished name and the certificate
serial number. The identified certificate, in turn, contains the
hardware module's public key. The subjectKeyIdentifier
alternative identifies the hardware module's public key directly.
When this public key is contained in a certificate, this
identifier appears in the X.509 subjectKeyIdentifier extension.
Public key identifiers SHOULD be assigned using one of the methods
specified in section 4.2.1.2 of RFC 3280 [PROFILE]. The use of
the subjectKeyIdentifier by hardware modules is RECOMMENDED.
digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the hardware module. It MUST
contain the message digest algorithms employed to sign the
receipt. (Note that this message digest algorithm identifier MUST
be the same as the one carried in the digestAlgorithms value in
SignedData.)
signedAttrs is an optional collection of attributes that are
signed along with the content. The signedAttrs are optional in
the CMS, but in this specification, signedAttrs are REQUIRED for
use with the firmware package load receipt content. The SET OF
attributes MUST be DER encoded [X.509-88]. Section 3.2 of this
document lists the attributes that MUST be included in the
collection.
signatureAlgorithm identifies the signature algorithm, and any
associated parameters, used by to sign the receipt.
signature is the digital signature.
unsignedAttrs is an optional collection of attributes that are not
signed, and in this case, there MUST NOT be any unsigned
attributes present.
Housley [Page 33]
INTERNET DRAFT September 2003
3.1.2.2 EncapsulatedContentInfo
The FirmwarePackageLoadReceipt is encapsulated in an OCTET STRING,
and it is carried within the EncapsulatedContentInfo type. The
fields of EncapsulatedContentInfo are used as follows:
eContentType is an object identifier that uniquely specifies the
content type, and in this case, it MUST be the value of id-ct-
firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17).
eContent is the firmware package load receipt, encapsulated in an
OCTET STRING. The eContent octet string need not be DER encoded.
3.1.3 FirmwarePackageLoadReceipt
The following object identifier identifies the firmware package load
receipt content type:
id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 17 }
The firmware package load receipt content type has the ASN.1 type
FirmwarePackageLoadReceipt:
FirmwarePackageLoadReceipt ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
fwPkgID OBJECT IDENTIFIER,
verNum INTEGER (0..MAX),
trustAnchorKeyID [1] OCTET STRING OPTIONAL,
decryptKeyID [2] OCTET STRING OPTIONAL }
The fields of the FirmwarePackageLoadReceipt type have the following
meanings:
hwType is an object identifier that identifies the type of
hardware module on which the firmware package was loaded.
hwSerialNum is the serial number of the hardware module on which
the firmware package was loaded. No particular structure is
imposed on the serial number; it need not be an integer. However,
the combination of the hwType and hwSerialNum uniquely identifies
the hardware module.
fwPkgID identifies the type of firmware package that was loaded.
verNum identifies the version of firmware package that was loaded.
Housley [Page 34]
INTERNET DRAFT September 2003
The combination of the fwPkgID and verNum specify a particular
firmware package. The version number is a non-negative integer
that identifies a particular build or release of the firmware
package.
trustAnchorKeyID identifies the trust anchor that was used to
validate the firmware package signature.
decryptKeyID is optional, and when it is present it identifies the
firmware-decryption key that was used to decrypt the firmware
package.
The Firmware Package Load Receipt MUST include the hwType,
hwSerialNum, fwPkgID, and verNum fields, and it SHOULD include the
trustAnchorKeyID field. The Firmware Package Load Receipt MUST
include the decryptKeyID only if the firmware package associated with
the receipt is encrypted, the firmware-decryption key is available,
and the firmware package was successfully decrypted.
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 in 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 of the attributes used with this profile has a single attribute
value, even though the syntax is defined as a SET OF AttributeValue.
There MUST be exactly one instance of AttributeValue present.
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.
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.
Housley [Page 35]
INTERNET DRAFT September 2003
3.2.2 Message Digest
The hardware module MUST include a message-digest attribute, having
as its value the message digest of the FirmwarePackageLoadReceipt
content. Section 11.2 of [CMS] defines the message-digest attribute.
3.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 receipt was generated. Section 11.3 of [CMS] defines
the signing-time attribute.
4 Firmware Package Load Error
The Cryptographic Message Syntax (CMS) is used to indicate that an
error has occurred while attempted to load a protected firmware
package. Support for firmware package load error reports is
OPTIONAL. However, those hardware modules that choose to generate
such error reports MUST follow the conventions specified in this
section.
Hardware modules that support error report generation MUST have a
unique serial number. Hardware modules that support signed error
report generation MUST also have a private signature key to sign the
error report, and a corresponding signature validation certificate to
include in the error report to aid validation.
The unsigned firmware package load error report is encapsulated by
ContentInfo. Alternatively, the signed firmware package load error
report is encapsulated by SignedData, which is in turn encapsulated
by ContentInfo.
The firmware package load receipt protection is summarized by (see
[CMS] for the full syntax):
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 --
OCTET STRING -- which encapsulates
-- FirmwarePackageLoadError
}
Housley [Page 36]
INTERNET DRAFT September 2003
SignedData {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Module certificate
crls CertificateRevocationLists, -- Omit
signerInfos SET OF SignerInfo -- Only one
}
SignerInfo {
version CMSVersion,
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 {
hwType OBJECT IDENTIFIER, -- Hardware module type
hwSerialNum OCTET STRING, -- H/W module serial number
fwPkgID OBJECT IDENTIFIER, -- Package identifier
verNum INTEGER, -- Release or build number
errorCode INTEGER -- Identifies the error
}
4.1 Firmware Package Load Error CMS Content Type Profile
This section specifies the conventions for using the CMS ContentInfo
and SignedData content types for firmware package load error reports.
It also defines the firmware package load error content type.
4.1.1 ContentInfo
The CMS requires the outer most encapsulation to be ContentInfo
[CMS]. The fields of ContentInfo are used as follows:
contentType indicates the type of the associated content. If the
firmware load error report is signed, then the encapsulated type
MUST be SignedData, and the id-signedData (1.2.840.113549.1.7.2)
Housley [Page 37]
INTERNET DRAFT September 2003
object identifier MUST be present in this field. If the firmware
load error report is not signed, then the encapsulated type MUST
be FirmwarePackageLoadError, and the id-ct-firmwareLoadError
(1.2.840.113549.1.9.16.1.18) object identifier MUST be present in
this field.
content holds the associated content. If the firmware load error
report is signed, then the encapsulated SignedData MUST be present
in this field. If the firmware load error report is not signed,
then this field MUT contain an OCTET STRING, and that OCTET STRING
MUST encapsulate the FirmwarePackageLoadError.
4.1.2 SignedData
The SignedData content type consists the firmware package load error
report, the hardware module certificate, and one digital signature.
The fields of SignedData are used exactly as described in section
3.1.2.
4.1.2.1 SignerInfo
The hardware module is represented in the SignerInfo type. The
fields of SignerInfo are used exactly as described in section
3.1.2.1.
4.1.2.2 EncapsulatedContentInfo
The FirmwarePackageLoadError is encapsulated in an OCTET STRING, and
it is carried within the EncapsulatedContentInfo type. The fields of
EncapsulatedContentInfo are used as follows:
eContentType is an object identifier that uniquely specifies the
content type, and in this case, it MUST be the value of id-ct-
firmwareLoadError (1.2.840.113549.1.9.16.1.18).
eContent is the firmware package load error report, encapsulated
in an OCTET STRING. The eContent octet string need not be DER
encoded.
4.1.3 FirmwarePackageLoadError
The following object identifier identifies the firmware package load
error report content type:
id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 18 }
Housley [Page 38]
INTERNET DRAFT September 2003
The firmware package load error report content type has the ASN.1
type FirmwarePackageLoadError:
FirmwarePackageLoadError ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
fwPkgID OBJECT IDENTIFIER OPTIONAL,
verNum INTEGER (0..MAX) OPTIONAL,
errorCode FirmwarePackageLoadErrorCode }
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),
wrongBootstrapLoader (31),
wrongSeparationKernel (32),
insufficientMemory (33),
badFirmware (34),
other (99) }
Housley [Page 39]
INTERNET DRAFT September 2003
The fields of the FirmwarePackageLoadError type have the following
meanings:
hwType is an object identifier that identifies the type of
hardware module on which the firmware package load was attempted.
hwSerialNum is the serial number of the hardware module on which
the firmware package load was attempted. No particular structure
is imposed on the serial number; it need not be an integer.
However, the combination of the hwType and hwSerialNum uniquely
identifies the hardware module.
fwPkgID identifies the type of firmware package that was trying to
be loaded. The field is OPTIONAL so that it can be omitted when
an error is detected parsing the firmware package.
verNum identifies the version of firmware package that was trying
to be loaded. The field is OPTIONAL so that it can be omitted
when an error is detected parsing the firmware package. The
combination of the fwPkgID and verNum specify a particular
firmware package. The version number is a non-negative integer
that identifies a particular build or release of the firmware
package.
errorCode identifies the error that occurred.
The errorCode values have the following meanings:
decodeFailure: The ASN.1 decode of the firmware load package
failed. The provided input did not conform to BER, or it was not
ASN.1 at all.
badContentInfo: Invalid ContentInfo syntax, or the contentType
carried within the ContentInfo is unknown or unsupported.
badSignedData: Invalid SignedData syntax, the version is unknown
or unsupported, or more than one entry is present in
digestAlgorithms.
badEncapContent: Invalid EncapsulatedContentInfo syntax, or the
contentType carried within the eContentType is unknown or
unsupported. This error can be generated due to problems located
in SignedData or CompressedData.
badCertificate: Invalid syntax for one or more certificates in
CertificateSet.
Housley [Page 40]
INTERNET DRAFT September 2003
badSignerInfo: Invalid SignerInfo syntax, or the version is
unknown or unsupported.
badSignedAttrs: Invalid signedAttrs syntax within SignerInfo, or
an unknown or unsupported signed attribute is present.
badUnsignedAttrs: The unsignedAttrs within SignerInfo contains an
attribute other than the wrapped-firmware-decryption-key
attribute, which is the only unsigned attribute supported by this
specification.
missingContent: The optional eContent is missing in
EncapsulatedContentInfo, which is required in this specification.
This error can be generated due to problems located in SignedData
or CompressedData.
noTrustAnchor: The sid within SignerInfo does not match to a
trust anchor associated with firmware package signing. Two
situations can lead to this error. In one case, the
subjectKeyIdentifier does not identify the public key of a trust
anchor or a certification path that terminates with an installed
trust anchor. In the other case, the issuerAndSerialNumber and
subjectKeyIdentifier does not identify the public key of a trust
anchor or a certification path that terminates with an installed
trust anchor.
notAuthorized: The sid within SignerInfo leads to an installed
trust anchor, but that trust anchor is not an authorized firmware
package signer.
badDigestAlgorithm: The digestAlgorithm in either 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 could not be
validated because an unsupported key size was employed by the
signer.
signatureFailure: The signatureAlgorithm in SignerInfo is known
and supported, but the signature in signature in SignerInfo could
not be validated.
contentTypeMismatch: The contentType carried within the
eContentType does not match the content type carried in the signed
attribute.
Housley [Page 41]
INTERNET DRAFT September 2003
badEncryptedData: Invalid EncryptedData syntax, the version is
unknown or unsupported, or more than one entry is present in
digestAlgorithms.
unprotectedAttrsPresent: EncryptedData contains unprotectedAttrs,
which are not permitted in this specification.
badEncryptContent: Invalid EncryptedContentInfo syntax, or the
contentType carried within the contentType is unknown or
unsupported.
badEncryptAlgorithm: The firmware-encryption algorithm identified
by contentEncryptionAlgorithm in EncryptedContentInfo is unknown
or unsupported.
missingCiphertext: The optional encryptedContent is missing in
EncryptedContentInfo, which is required in this specification.
noDecryptKey: The hardware module does not have the firmware-
decryption key named in the decrypt key identifier assigned
attribute.
decryptFailure: The firmware package did not decrypt properly.
badCompressAlgorithm: The compression algorithm identified by
compressionAlgorithm in CompressedData is unknown or unsupported.
missingCompressedContent: The optional eContent is missing in
EncapsulatedContentInfo, which is required in this specification.
decompressFailure: The firmware package did not decompress
properly.
wrongHardware: The processing hardware module is not listed in
the target hardware module identifiers signed attribute.
stalePackage: The firmware package is rejected because it is
stale.
notInCommunity: The hardware module is not a member of the
community described in the community identifiers signed attribute.
unsupportedPackageType: The firmware package type identified in
the firmware package information signed attribute is not supported
by the combination of the hardware module and the bootstrap
loader.
Housley [Page 42]
INTERNET DRAFT September 2003
wrongBootstrapLoader: The firmware package depends on routines
that are part of the bootstrap loader, and the current bootstrap
loader does not fulfill the dependencies.
wrongSeparationKernel: The firmware package depends on routines
that are part of the separation kernel, and the current separation
kernel does not fulfill the dependencies.
insufficientMemory: The firmware package could not be loaded
because the hardware module did not have sufficient memory.
badFirmware: The signature on the firmware package was validated,
but the firmware package itself was not in an acceptable format.
The details will be specific to each hardware module. For
example, a hardware module that is composed of multiple processors
could not find the internal tagging within the firmware package to
distribute object code to each of the processors.
other: An error occurred that does not fit any of the previous
error codes.
4.2 Signed Attributes
The hardware module MUST digitally sign a collection of attributes
along with the firmware package load error report. Each attribute in
the collection in 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 of the attributes used with this profile has a single attribute
value, even though the syntax is defined as a SET OF AttributeValue.
There MUST be exactly one instance of AttributeValue present.
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.
Housley [Page 43]
INTERNET DRAFT September 2003
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
Support for firmware package load receipts, as discussed in section
3, is OPTIONAL. Hardware modules that support receipt generation
MUST have a unique serial number, a private signature key to sign the
receipt, and a corresponding signature validation certificate
[PROFILE] to include in the receipt to aid validation. 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. The otherName choice within the GeneralName
structure is used.
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 }
Housley [Page 44]
INTERNET DRAFT September 2003
The fields of the HardwareModuleName type have the following
meanings:
hwType is an object identifier that identifies the type of
hardware module. A unique object identifier names a hardware
model and revision.
hwSerialNum is the serial number of the hardware module. No
particular structure is imposed on the serial number; it need not
be an integer. However, the combination of the hwType and
hwSerialNum uniquely identifies the hardware module.
6 References
This section provides normative and informative references.
6.1 Normative References
COMPRESS Gutmann, P. Compressed Data Content Type for
Cryptographic Message Syntax (CMS). RFC 3274.
June 2002.
CMS Housley, R. Cryptographic Message Syntax.
RFC 3369. August 2002.
ESS Hoffman, P. Enhanced Security Services for S/MIME.
RFC 2634. June 1999.
PROFILE Housley, R., W. Polk, W. Ford, 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. RFC 2119. March 1997.
UTF-8 Yergeau, F. UTF-8, a transformation format of ISO 10646.
RFC 2279. January 1998.
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.
Housley [Page 45]
INTERNET DRAFT September 2003
X.509-88 CCITT. Recommendation X.509: The Directory - Authentication
Framework. 1988.
6.2 Informative References
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.
DPD&DPV Pinkas, D., and R. Housley. Delegated Path Validation
and Delegated Path Discovery Protocol Requirements.
RFC 3379. September 2002.
DSS National Institute of Standards and Technology.
FIPS Pub 186: Digital Signature Standard. 19 May 1994.
OCSP Myers, M., R. Ankney, A. Malpani, S. Galperin, 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., S. Crocker, and J. Schiller. Randomness
Recommendations for Security. RFC 1750. December 1994.
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.
7 Security Considerations
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 permits unauthorized
parties to generate firmware package load receipts.
Housley [Page 46]
INTERNET DRAFT September 2003
The firmware-decryption key must be protected. Compromise of the key
may result in the disclosure of the firmware 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. While this capability is desirable, cryptographic
algorithm replacement can lead to interoperability failures.
Therefore, the roll out of new cryptographic algorithms must be
managed. Generally, the previous generation of cryptographic
algorithms needs to be supported at the same time as their
replacements to facilitate an orderly transition.
The use of a stale version number in a firmware package 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 their own stale firmware 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.
Since many hardware modules are expected to have very few firmware
packages written for them, the stale firmware 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.
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
Housley [Page 47]
INTERNET DRAFT September 2003
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.
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
1750 [RANDOM] offers important guidance in this area, and Appendix 3
of FIPS Pub 186 [DSS] provides one quality PRNG technique.
8 Author Address
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
housley@vigilsec.com
Housley [Page 48]
INTERNET DRAFT September 2003
Appendix A: ASN.1 Module
The ASN.1 module contained in this appendix defines the structures
that are needed to implement the CMS-based firmware package wrapper.
It is expected to be used in conjunction with the ASN.1 modules in
[CMS], [COMPRESS], and [PROFILE].
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, id-data
FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };
-- 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 {
fwPkgID OBJECT IDENTIFIER,
verNum INTEGER (0..MAX),
staleVerNum INTEGER (0..MAX) OPTIONAL }
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
Housley [Page 49]
INTERNET DRAFT September 2003
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-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 {
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 FWPackageType DEFAULT application,
dependencies SEQUENCE OF FWPackageRef OPTIONAL }
Housley [Page 50]
INTERNET DRAFT September 2003
FWPackageType ::= ENUMERATED {
bootstrapLoader (1),
separationKernel (2),
application (3) }
FWPackageRef ::= SEQUENCE {
fwPkgID OBJECT IDENTIFIER,
minVerNum INTEGER }
-- 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 {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
fwPkgID OBJECT IDENTIFIER,
verNum INTEGER (0..MAX),
decryptKeyID OCTET STRING OPTIONAL }
-- 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 {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
fwPkgID OBJECT IDENTIFIER OPTIONAL,
verNum INTEGER (0..MAX) OPTIONAL,
errorCode FirmwarePackageLoadErrorCode }
Housley [Page 51]
INTERNET DRAFT September 2003
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),
wrongBootstrapLoader (31),
wrongSeparationKernel (32),
insufficientMemory (33),
badFirmware (34),
other (99) }
Housley [Page 52]
INTERNET DRAFT September 2003
-- Other Name syntax for Hardware Module Name
id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) on(8) 4 }
HardwareModuleName ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }
END
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. In addition, the
ASN.1 module presented in Appendix A may be used in whole or in part
without inclusion of the copyright notice. However, this document
itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process shall be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS 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.
Housley [Page 53]