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 }
The firmware package load error report content type has the ASN.1
type FirmwarePackageLoadError:
FirmwarePackageLoadError ::= SEQUENCE {
version FWErrorVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
errorCode FirmwarePackageLoadErrorCode,
vendorErrorCode VendorLoadErrorCode OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
config [1] SEQUENCE OF CurrentFWConfig OPTIONAL }
FWErrorVersion ::= INTEGER { v1(1) }
CurrentFWConfig ::= SEQUENCE {
fwPkgType INTEGER OPTIONAL,
fwPkgName PreferredOrLegacyPackageIdentifier }
FirmwarePackageLoadErrorCode ::= ENUMERATED {
decodeFailure (1),
badContentInfo (2),
badSignedData (3),
badEncapContent (4),
badCertificate (5),
badSignerInfo (6),
badSignedAttrs (7),
badUnsignedAttrs (8),
missingContent (9),
noTrustAnchor (10),
notAuthorized (11),
badDigestAlgorithm (12),
badSignatureAlgorithm (13),
unsupportedKeySize (14),
signatureFailure (15),
contentTypeMismatch (16),
badEncryptedData (17),
unprotectedAttrsPresent (18),
badEncryptContent (19),
badEncryptAlgorithm (20),
missingCiphertext (21),
noDecryptKey (22),
decryptFailure (23),
badCompressAlgorithm (24),
missingCompressedContent (25),
decompressFailure (26),
wrongHardware (27),
stalePackage (28),
notInCommunity (29),
unsupportedPackageType (30),
missingDependency (31),
wrongDependencyVersion (32),
insufficientMemory (33),
badFirmware (34),
unsupportedParameters (35),
breaksDependency (36),
otherError (99) }
VendorLoadErrorCode ::= INTEGER
The fields of the FirmwarePackageLoadError type have the following
meanings:
version is an integer, and it provides the syntax version number for
compatibility with future revisions of this specification.
Implementations that conform to this specification MUST set the
version to the default value, which is v1.
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.
errorCode identifies the error that occurred.
vendorErrorCode is optional; however, it MUST be present if the
errorCode contains a value of otherError. When errorCode contains
a value other than otherError, the vendorErrorCode can provide
vendor-specific supplemental information.
fwPkgName is optional. When it is present, it identifies the
firmware package that was being loaded when the error occurred.
As described in Section 2.2.3, two approaches to naming firmware
packages are supported: legacy and preferred. A legacy firmware
package name is an octet string. A preferred firmware package
name is a combination of the firmware package object identifier
and an integer version number.
config identifies the current firmware configuration. The field is
OPTIONAL, but support for this field is RECOMMENDED for hardware
modules that permit the loading of more than one firmware package.
One instance of CurrentFWConfig is used to provide information
about each firmware package in hardware module.
The fields of the CurrentFWConfig type have the following meanings:
fwPkgType identifies the firmware package type. The firmware package
type is an INTEGER, and the meaning of the integer value is
specific to each hardware module.
fwPkgName identifies the firmware package. As described in Section
2.2.3, two approaches to naming firmware packages are supported:
legacy and preferred. A legacy firmware package name is an octet
string. A preferred firmware package name is a combination of the
firmware package object identifier and an integer version number.
The errorCode values have the following meanings:
decodeFailure: The ASN.1 decode of the firmware package load 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.
badSignerInfo: Invalid SignerInfo syntax, or the version is unknown
or unsupported.
badSignedAttrs: Invalid signedAttrs syntax within SignerInfo.
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: 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 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.
badEncryptedData: Invalid EncryptedData syntax; the version is
unknown or unsupported.
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 signed
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.
missingDependency: The firmware package being loaded depends on
routines that are part of another firmware package, but that
firmware package is not available.
wrongDependencyVersion: The firmware package being loaded depends on
routines that are part of the another firmware package, and the
available version of that package has an older version number than
is required. The available firmware package 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 firmware-programmable
components could not find the internal tagging within the firmware
package to distribute executable code to each of the components.
unsupportedParameters: The signature on the firmware package could
not be validated because the signer used signature algorithm
parameters that are not supported by the hardware module signature
verification routines.
breaksDependency: Another firmware package has a dependency that can
no longer be satisfied if the firmware package being loaded is
accepted.
otherError: 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 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.
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, and support for the firmware package load error
reports, as discussed in Section 4, is OPTIONAL. Hardware modules
that support receipt or error report generation MUST have unique
serial numbers. Further, hardware modules that support signed
receipt or error report generation MUST have private signature keys
and corresponding signature validation certificates [PROFILE] or
their designators. The conventions for hardware module naming in the
signature validation certificates are specified in this section.
The hardware module vendor or a trusted third party MUST issue the
signature validation certificate prior to deployment of the hardware
module. The certificate is likely to be issued at the time of
manufacture. The subject alternative name in this certificate
identifies the hardware module. The subject distinguished name is
empty, but a critical subject alternative name extension contains the
hardware module name, using the otherName choice within the
GeneralName structure.
The hardware module name form is identified by the id-on-
hardwareModuleName object identifier:
id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) on(8) 4 }
A HardwareModuleName is composed of an object identifier and an octet
string:
HardwareModuleName ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }
The fields of the HardwareModuleName type have the following
meanings:
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. Security Considerations
This document describes the use of the Cryptographic Message Syntax
(CMS) to protect firmware packages; therefore, the security
considerations discussed in [CMS] apply to this specification as
well.
The conventions specified in this document raise a few security
considerations of their own.
6.1. Cryptographic Keys and Algorithms
Private signature keys must be protected. Compromise of the private
key used to sign firmware packages permits unauthorized parties to
generate firmware packages that are acceptable to hardware modules.
Compromise of the hardware module private key allows unauthorized
parties to generate signed firmware package load receipts and error
reports.
The firmware-decryption key must be protected. Compromise of the key
may result in the disclosure of the firmware package to unauthorized
parties.
Cryptographic algorithms become weaker with time. As new
cryptanalysis techniques are developed and computing performance
improves, the work factor to break a particular cryptographic
algorithm will be reduced. The ability to change the firmware
package provides an opportunity to update or replace cryptographic
algorithms. Although this capability is desirable, cryptographic
algorithm replacement can lead to interoperability failures.
Therefore, the rollout of new cryptographic algorithms must be
managed. Generally, the previous generation of cryptographic
algorithms and their replacements need to be supported at the same
time in order to facilitate an orderly transition.
6.2. Random Number Generation
When firmware packages are encrypted, the source of the firmware
package must randomly generate firmware-encryption keys. Also, the
generation of public/private signature key pairs relies on a random
numbers. The use of inadequate pseudo-random number generators
(PRNGs) to generate cryptographic keys can result in little or no
security. An attacker may find it much easier to reproduce the PRNG
environment that produced the keys, searching the resulting small set
of possibilities, rather than brute-force searching the whole key
space. The generation of quality random numbers is difficult. RFC
4086 [RANDOM] offers important guidance in this area.
6.3. Stale Firmware Package Version Number
The firmware signer determines whether a stale version number is
included. The policy of the firmware signer needs to consider many
factors. Consider the flaw found by Ian Goldberg and David Wagner in
the random number generator of the Netscape browser in 1996 [DDJ].
This flaw completely undermines confidentiality protection. A
firmware signer might use the stale version number to ensure that
upgraded hardware modules do not resume use of the flawed firmware.
However, another firmware signer may not consider this an appropriate
situation to employ the stale version number, preferring to delegate
this decision to someone closer to the operation of the hardware
module. Such a person is likely to be in a better position to
evaluate whether other bugs introduced in the newer firmware package
impose worse operational concerns than the confidentiality concern
caused by the flawed random number generator. For example, a user
who never uses the encryption feature of the flawed Netscape browser
will determine the most appropriate version to use without
considering the random number flaw or its fix.
The stale version number is especially useful when the security
interests of the person choosing which firmware package version to
load into a particular hardware module do not align with the security
interests of the firmware package signer. For example, stale version
numbers may be useful in hardware modules that provide digital rights
management (DRM). Also, stale version numbers will be useful when
the deployment organization (as opposed to the firmware package
vendor) is the firmware signer. Further, stale version numbers will
be useful for firmware packages that need to be trusted to implement
organizational (as opposed to the deployment organization) security
policy, regardless of whether the firmware signer is the deployment
organization or the vendor. For example, hardware devices employed
by the military will probably make use of stale version numbers.
The use of a stale version number in a firmware package that employs
the preferred firmware package name form cannot completely prevent
subsequent use of the stale firmware package. Despite this
shortcoming, the feature is included since it is useful in some
important situations. By loading different types of firmware
packages, each with its own stale firmware package version number
until the internal storage for the stale version number is exceeded,
the user can circumvent the mechanism. Consider a hardware module
that has storage for two stale version numbers. Suppose that FWPKG-A
version 3 is loaded, indicating that FWPKG-A version 2 is stale. The
user can sequentially load the following:
- FWPKG-B version 8, indicating that FWPKG-B version 4 is stale.
(Note: The internal storage indicates that FWPKG-A version 2
and FWPKG-B version 4 are stale.)
- FWPKG-C version 5, indicating that FWPKG-C version 3 is stale.
(Note: The internal storage indicates that FWPKG-B version 4
and FWPKG-C version 3 are stale.)
- FWPKG-A version 2.
Because many hardware modules are expected to have very few firmware
packages written for them, the stale firmware package version feature
provides important protections. The amount of non-volatile storage
that needs to be dedicated to saving firmware package identifiers and
version numbers depends on the number of firmware packages that are
likely to be developed for the hardware module.
The use of legacy firmware package name form does not improve this
situation. In fact, the legacy firmware package names are usually
larger than an object identifier. Thus, comparable stale version
protection requires more memory.
A firmware signer can ensure that stale version numbers are honored
by limiting the number of different types of firmware packages that
are signed. If all of the hardware modules are able to store a stale
version number for each of the different types of firmware package,
then the hardware module will be able to provide the desired
protection. This requires the firmware signer to have a deep
understanding of all of the hardware modules that might accept the
firmware package.
6.4. Community Identifiers
When a firmware package includes a community identifier, the
confidence that the package is only used by the intended community
depends on the mechanism used to configure community membership.
This document does not specify a mechanism for the assignment of
community membership to hardware modules, and the various
alternatives have different security properties. Also, the authority
that makes community identifier assignments to hardware modules might
be different than the authority that generates firmware packages.
7. References
7.1. Normative References
[COMPRESS] Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS)", RFC 3274, June
2002.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[SHA1] National Institute of Standards and Technology. FIPS
Pub 180-1: Secure Hash Standard. 17 April 1995.
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988.