path for the firmware-signing certificate.
If firmware packages are encrypted, the bootstrap loader MUST have
access to a decryption routine. Access to a corresponding encryption
function is not required, since hardware modules need not be capable
of generating firmware packages. Because some symmetric encryption
algorithm implementations (such as AES [AES]) employ separate logic
for encryption and decryption, some hardware module savings might
result.
If firmware packages are compressed, the bootstrap loader MUST also
have access to a decompression function. This function can be
implemented specifically for the bootstrap loader, or it can be
shared with other hardware module features. Access to a
corresponding compression function is not required, since hardware
modules need not be capable of generating firmware packages.
If the optional receipt generation or error report capability is
supported, the bootstrap loader MUST have access to the hardware
module serial number and the object identifier for the hardware
module type. If the optional signed receipt generation or signed
error report capability is supported, the bootstrap loader MUST also
have access to a one-way hash function and digital signature
routines, the hardware module private signing key, and the
corresponding signature validation certificate or its designator.
The bootstrap loader requires access to one or more trusted public
keys, called trust anchors, to validate the firmware package digital
signature. One or more trust anchors MUST be installed in non-
volatile memory prior to deployment. The bootstrap loader MUST
reject a firmware package if it cannot validate the signature, which
MAY require the construction of a valid certification path from the
firmware-signing certificate to one of the trust anchors [PROFILE].
However, in many cases, the firmware package signature will be
validated directly with the trust anchor public key, avoiding the
need to construct certification paths.
The bootstrap loader MUST reject a firmware package if the list of
supported hardware module type identifiers within the firmware
package does not include the object identifier of the hardware
module.
The bootstrap loader MUST reject a firmware package if the firmware
package includes a list of community identifiers and the hardware
module is not a member of one of the listed communities. The means
of determining community membership is beyond the scope of this
specification.
The bootstrap loader MUST reject a firmware package if it cannot
successfully decrypt the firmware package using the firmware-
decryption key available to the hardware module. The firmware
package contains an identifier of the firmware-decryption key needed
for decryption.
When an earlier version of a firmware package is replacing a later
one, the bootstrap loader SHOULD generate a warning. The manner in
which a warning is generated is highly dependent on the hardware
module and the environment in which it is being used. If a firmware
package with a disastrous flaw is released and subsequent firmware
package versions designate a stale version, the bootstrap loader
SHOULD prevent loading of the stale version and versions earlier than
the stale version.
1.2.3.1. Legacy Stale Version Processing
In case a firmware package with a disastrous flaw is released,
subsequent firmware package versions that employ the legacy firmware
package name form MAY include a stale legacy firmware package name to
prevent subsequent rollback to the stale version or versions earlier
than the stale version. As described in the Security Considerations
section of this document, the inclusion of a stale legacy firmware
package name in a firmware package cannot completely prevent
subsequent use of the stale firmware package. However, many hardware
modules are expected to have very few firmware packages written for
them, allowing the stale firmware package version feature to provide
important protections.
Non-volatile storage for stale version numbers is needed. The number
of stale legacy firmware package names that can be stored depends on
the amount of storage that is available. When a firmware package is
loaded and it contains a stale legacy firmware package name, then it
SHOULD be added to a list kept in non-volatile storage. When
subsequent firmware packages are loaded, the legacy firmware package
name of the new package is compared to the list in non-volatile
storage. If the legacy firmware package name represents the same
version or an older version of a member of the list, then the new
firmware packages SHOULD be rejected.
The amount of non-volatile storage that needs to be dedicated to
saving legacy firmware package names and stale legacy firmware
packages names depends on the number of firmware packages that are
likely to be developed for the hardware module.
1.2.3.2. Preferred Stale Version Processing
If a firmware package with a disastrous flaw is released, subsequent
firmware package versions that employ preferred firmware package name
form MAY include a stale version number to prevent subsequent
rollback to the stale version or versions earlier than the stale
version. As described in the Security Considerations section of this
document, the inclusion of a stale version number in a firmware
package cannot completely prevent subsequent use of the stale
firmware package. However, many hardware modules are expected to
have very few firmware packages written for them, allowing the stale
firmware package version feature to provide important protections.
Non-volatile storage for stale version numbers is needed. The number
of stale version numbers that can be stored depends on the amount of
storage that is available. When a firmware package is loaded and it
contains a stale version number, then the object identifier of the
firmware package and the stale version number SHOULD be added to a
list that is kept in non-volatile storage. When subsequent firmware
packages are loaded, the object identifier and version number of the
new package are compared to the list in non-volatile storage. If the
object identifier matches and the version number is less than or
equal to the stale version number, then the new firmware packages
SHOULD be rejected.
The amount of non-volatile storage that needs to be dedicated to
saving firmware package identifiers and stale version numbers depends
on the number of firmware packages that are likely to be developed
for the hardware module.
1.2.4. Trust Anchors
A trust anchor MUST consist of a public key signature algorithm and
an associated public key, which MAY optionally include parameters. A
trust anchor MUST also include a public key identifier. A trust
anchor MAY also include an X.500 distinguished name.
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 names the trust anchor, and each public key has a
public key identifier. The public key identifier identifies the
trust anchor as the signer when it is used directly to validate
firmware package signatures. This key identifier can be stored with
the trust anchor, or it can be computed from the public key whenever
needed.
The optional trusted X.500 distinguished name MUST be present in
order for the trust anchor public key to be used to validate an X.509
certification path. Without an X.500 distinguished name,
certification path construction cannot use the trust anchor.
1.2.5. Cryptographic and Compression Algorithm Requirements
A firmware package for a cryptographic hardware module includes
cryptographic algorithm implementations. In addition, a firmware
package for a non-cryptographic hardware module will likely include
cryptographic algorithm implementations to support the bootstrap
loader in the validation of firmware packages.
A unique algorithm object identifier MUST be assigned for each
cryptographic algorithm and mode implemented by a firmware package.
A unique algorithm object identifier MUST also be assigned for each
compression algorithm implemented by a firmware package. The
algorithm object identifiers can be used to determine whether a
particular firmware package satisfies the needs of a particular
application. To facilitate the development of algorithm-agile
applications, the cryptographic module interface SHOULD allow
applications to query the cryptographic module for the object
identifiers associated with each cryptographic algorithm contained in
the currently loaded firmware package. Applications SHOULD also be
able to query the cryptographic module to determine attributes
associated with each algorithm. Such attributes might include the
algorithm type (symmetric encryption, asymmetric encryption, key
agreement, one-way hash function, digital signature, and so on), the
algorithm block size or modulus size, and parameters for asymmetric
algorithms. This specification does not establish the conventions
for the retrieval of algorithm identifiers or algorithm attributes.
1.3. Hardware Module Security Architecture
The bootstrap loader MAY be permanently stored in read-only memory or
separately loaded into non-volatile memory as discussed above.
In most hardware module designs, the firmware package execution
environment offers a single address space. If it does, the firmware
package SHOULD contain a complete firmware package load for the
hardware module. In this situation, the firmware package does not
contain a partial or incremental set of functions. A complete
firmware package load will minimize complexity and avoid potential
security problems. From a complexity perspective, the incremental
loading of packages makes it necessary for each package to identify
any other packages that are required (its dependencies), and the
bootstrap loader needs to verify that all of the dependencies are
satisfied before attempting to execute the firmware package. When a
hardware module is based on a general purpose processor or a digital
signal processor, it is dangerous to allow arbitrary packages to be
loaded simultaneously unless there is a reference monitor to ensure
that independent portions of the code cannot interfere with one
another. Also, it is difficult to evaluate arbitrary combinations of
software modules [SECREQMTS]. For these reasons, a complete firmware
package load is RECOMMENDED; however, this specification allows the
firmware signer to identify dependencies between firmware packages in
order to handle all situations.
The firmware packages MAY have dependencies on routines provided by
other firmware packages. To minimize the security evaluation
complexity of a hardware module employing such a design, the firmware
package MUST identify the package identifiers (and the minimum
version numbers when the preferred firmware package name form is
used) of the packages upon which it depends. The bootstrap loader
MUST reject a firmware package load if it contains a dependency on a
firmware package that is not available.
Loading a firmware package can impact the satisfactory resolution of
dependencies of other firmware packages that are already part of the
hardware module configuration. For this reason, the bootstrap loader
MUST reject the loading of a firmware package if the dependencies of
any firmware package in the resulting configurations will be
unsatisfied.
1.4. ASN.1 Encoding
The CMS uses Abstract Syntax Notation One (ASN.1) [X.208-88,
X.209-88]. ASN.1 is a formal notation used for describing data
protocols, regardless of the programming language used by the
implementation. Encoding rules describe how the values defined in
ASN.1 will be represented for transmission. The Basic Encoding Rules
(BER) are the most widely employed rule set, but they offer more than
one way to represent data structures. For example, definite length
encoding and indefinite length encoding are supported. This
flexibility is not desirable when digital signatures are used. As a
result, the Distinguished Encoding Rules (DER) [X.509-88] were
invented. DER is a subset of BER that ensures a single way to
represent a given value. For example, DER always employs definite
length encoding.
In this specification, digitally signed structures MUST be encoded
with DER. Other structures do not require DER, but the use of
definite length encoding is strongly RECOMMENDED. By always using
definite length encoding, the bootstrap loader will have fewer
options to implement. In situations where there is very high
confidence that only definite length encoding will be used, support
for indefinite length decoding MAY be omitted.
1.5. Protected Firmware Package Loading
This document does not attempt to specify a physical interface, any
related driver software, or a protocol necessary for loading firmware
packages. Many different delivery mechanisms are envisioned,
including portable memory devices, file transfer, and web pages.
Section 2 of this specification defines the format that MUST be
presented to the hardware module regardless of the interface that is
used. This specification also specifies the format of the response
that MAY be generated by the hardware module. Section 3 of this
specification defines the format that MAY be returned by the hardware
module when a firmware package loads successfully. Section 4 of this
specification defines the format that MAY be returned by the hardware
module when a firmware package load is unsuccessful. The firmware
package load receipts and firmware package load error reports can be
either signed or unsigned.
2. Firmware Package Protection
The Cryptographic Message Syntax (CMS) is used to protect a firmware
package, which is treated as an opaque binary object. A digital
signature is used to protect the firmware package from undetected
modification and to provide data origin authentication. Encryption
is optionally used to protect the firmware package from disclosure,
and compression is optionally used to reduce the size of the
protected firmware package. The CMS ContentInfo content type MUST
always be present, and it MUST encapsulate the CMS SignedData content
type. If the firmware package is encrypted, then the CMS SignedData
content type MUST encapsulate the CMS EncryptedData content type. If
the firmware package is compressed, then either the CMS SignedData
content type (when encryption is not used) or the CMS EncryptedData
content type (when encryption is used) MUST encapsulate the CMS
CompressedData content type. Finally, (1) the CMS SignedData content
type (when neither encryption nor compression is used), (2) the CMS
EncryptedData content type (when encryption is used, but compression
is not), or (3) the CMS CompressedData content type (when compression
is used) MUST encapsulate the simple firmware package using the
FirmwarePkgData content type defined in this specification (see
Section 2.1.5).
The firmware package protection is summarized as follows (see [CMS]
for the full syntax):
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData
}
SignedData {
version CMSVersion, -- always set to 3
digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Signer cert. path
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one
}
SignerInfo {
version CMSVersion, -- always set to 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Required
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Optional
}
EncapsulatedContentInfo {
eContentType id-encryptedData, -- (1.2.840.113549.1.7.6)
-- OR --
id-ct-compressedData,
-- (1.2.840.113549.1.9.16.1.9)
-- OR --
id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
eContent OCTET STRING
} -- Contains EncryptedData OR
-- CompressedData OR
-- FirmwarePkgData
EncryptedData {
version CMSVersion, -- Always set to 0
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs UnprotectedAttributes -- Omit
}
EncryptedContentInfo {
contentType id-ct-compressedData,
-- (1.2.840.113549.1.9.16.1.9)
-- OR --
id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent OCTET STRING
} -- Contains CompressedData OR
-- FirmwarePkgData
CompressedData {
version CMSVersion, -- Always set to 0
compressionAlgorithm CompressionAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo
}
EncapsulatedContentInfo {
eContentType id-ct-firmwarePackage,
-- (1.2.840.113549.1.9.16.1.16)
eContent OCTET STRING -- Contains FirmwarePkgData
}
FirmwarePkgData OCTET STRING -- Contains firmware package
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 that the outermost encapsulation 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
content field MUST contain SignedData.
2.1.2. SignedData
The SignedData content type [CMS] contains the signed firmware
package (which might be compressed, encrypted, or compressed and then
encrypted prior to signature), the certificates needed to validate
the signature, and one digital signature value. The fields of
SignedData are used as follows:
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 package signer MUST be present.
encapContentInfo contains the signed content, consisting of a content
type identifier and the content itself. The use of the
EncapsulatedContentInfo type is discussed further in Section
2.1.2.2.
certificates is an optional collection of certificates. If the trust
anchor signed the firmware package directly, then certificates
SHOULD be omitted. If it did not, then certificates SHOULD
include the X.509 certificate of the firmware package signer. The
set of certificates SHOULD be sufficient for the bootstrap loader
to construct a certification path from the trust anchor to the
firmware-signer’s certificate. PKCS#6 extended certificates
[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 SHOULD NOT be included by the
firmware package signer. It is anticipated that firmware packages
may be generated, signed, and made available in repositories for
downloading into hardware modules. In such contexts, it would be
difficult for the firmware package signer to include timely CRLs
in the firmware package. However, because the CRLs are not
covered by the signature, timely CRLs MAY be inserted by some
other party before the firmware package is delivered to the
hardware module.
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 package 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, which identifies the signer’s
public key directly. When this public key is contained in a
certificate, this identifier SHOULD appear in the X.509
subjectKeyIdentifier extension.
digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the firmware package signer. It
MUST contain the message digest algorithms employed by the
firmware package signer. (Note that this message digest algorithm
identifier MUST be the same as the one carried in the
digestAlgorithms value in SignedData.)
signedAttrs is an optional collection of attributes that are signed
along with the content. The signedAttrs are optional in the CMS,
but in this specification, signedAttrs are REQUIRED for the
firmware package; however, implementations MUST ignore
unrecognized signed attributes. The SET OF attributes MUST be DER
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 package 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