number. The SHA-1 hash value MUST be present. The certificate
issuer and the certificate serial number SHOULD be present.
policies is optional; when it is present, it contains a sequence of
policy information. 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 package 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. Because
the digital signature does not cover this attribute, it can be
altered at any point in the delivery path from the firmware package
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
OF Attribute. The UnsignedAttributes MUST include only one instance
of any particular attribute.
2.3.1. Wrapped Firmware Decryption Key
The firmware package 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; rather, the EnvelopedData feature of
having the encrypted content in another location is employed. The
encrypted content is found in the eContent field of the EncryptedData
structure. The firmware-decryption key is contained in the
recipientInfos field. Section 6 of [CMS] refers to this key as the
content-encryption key.
The EnvelopedData syntax supports 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 following apply:
- The set of certificates included in OriginatorInfo MUST NOT
include certificates with a type of extendedCertificate,
v1AttrCert, or v2AttrCert [X.509-97, X.509-00, ACPROFILE]. The
optional crls field MAY be present.
- The optional unprotectedAttrs field MUST NOT be present.
Within the EncryptedContentInfo structure, the following apply:
- contentType MUST match the content type object identifier carried
in the contentType field within the EncryptedContentInfo structure
of EncryptedData as described in Section 2.1.3.1.
- contentEncryptionAlgorithm identifies the firmware-encryption
algorithm, and any associated parameters, used to encrypt the
firmware package carried in the encryptedContent field of the
EncryptedContentInfo structure of EncryptedData. Therefore, it
MUST exactly match the value of the EncryptedContentInfo structure
of EncryptedData as described in Section 2.1.3.1.
- 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. Because not all hardware modules will
have private signature keys, the firmware package load receipt can be
either 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
the corresponding signature validation certificate or its designator.
The designator is the certificate issuer name and the certificate
serial number, or it is the public key identifier. Memory-
constrained hardware modules will generally store the public key
identifier since it requires less storage.
The unsigned firmware package load receipt is encapsulated by
ContentInfo. Alternatively, the signed firmware package load receipt
is encapsulated by SignedData, which is in turn encapsulated by
ContentInfo.
The firmware package load receipt is summarized as follows (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 --
FirmwarePackageLoadReceipt
}
SignedData {
version CMSVersion, -- always set to 3
digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Optional Module certificate
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one
}
SignerInfo {
version CMSVersion, -- either set to 1 or 3
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 {
version INTEGER, -- The DEFAULT is always used
hwType OBJECT IDENTIFIER, -- Hardware module type
hwSerialNum OCTET STRING, -- H/W module serial number
fwPkgName PreferredOrLegacyPackageIdentifier,
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 that the outermost encapsulation be ContentInfo
[CMS]. The fields of ContentInfo are used as follows:
contentType indicates the type of the associated content. If the
firmware package load receipt is signed, then the encapsulated
type MUST be SignedData, and the id-signedData
(1.2.840.113549.1.7.2) object identifier MUST be present in this
field. If the 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 package load
receipt is signed, then this field MUST contain the SignedData.
If the receipt is not signed, then this field MUST contain the
FirmwarePackageLoadReceipt.
3.1.2. SignedData
The SignedData content type contains the firmware package load
receipt and one digital signature. If the hardware module locally
stores its certificate, then the certificate can be included as well.
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 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. If the
hardware module locally stores its certificate, then the X.509
certificate of the hardware module SHOULD be included. If the
hardware module does not, then the certificates field is omitted.
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). CRLs MAY be included, but they will normally be omitted
since hardware modules will not generally have access to the most
recent CRL. Signed receipt recipients SHOULD be able to handle
the presence of the optional crls field.
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.
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. The hardware
module MUST support one or both of the alternatives for receipt
generation; however, the support of subjectKeyIdentifier is
RECOMMENDED. 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 SHOULD appear in the X.509
subjectKeyIdentifier extension.
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.
Other attributes MAY be included, but the recipient will ignore
any unrecognized signed attributes.
signatureAlgorithm identifies the signature algorithm, and any
associated parameters, used 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.
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 {
version FWReceiptVersion DEFAULT v1,
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING,
fwPkgName PreferredOrLegacyPackageIdentifier,
trustAnchorKeyID OCTET STRING OPTIONAL,
decryptKeyID [1] OCTET STRING OPTIONAL }
FWReceiptVersion ::= INTEGER { v1(1) }
The fields of the FirmwarePackageLoadReceipt type have the following
meanings:
version is an integer that 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 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.
fwPkgName identifies the firmware package that was loaded. 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.
trustAnchorKeyID is optional, and when it is present, it 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 version, hwType,
hwSerialNum, and fwPkgName fields, and it SHOULD include the
trustAnchorKeyID field. The firmware package load receipt MUST NOT
include the decryptKeyID, unless the firmware package associated with
the receipt is encrypted, the firmware-decryption key is available to
the hardware module, 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 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.
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 the 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 attempting 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. Not all hardware modules have private signature keys;
therefore the firmware package load error report can be either signed
or unsigned. Use of the signed firmware package error report is
RECOMMENDED.
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 the corresponding signature validation certificate
or its designator. The designator is the certificate issuer name and
the certificate serial number, or it is the public key identifier.
Memory-constrained hardware modules will generally store the public
key identifier since it requires less storage.
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 error report is summarized as follows (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 --
FirmwarePackageLoadError
}
SignedData {
version CMSVersion, -- Always set to 3
digestAlgorithms DigestAlgorithmIdentifiers, -- Only one
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Optional Module certificate
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one
}
SignerInfo {
version CMSVersion, -- either set to 1 or 3
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 {
version INTEGER, -- The DEFAULT is always used
hwType OBJECT IDENTIFIER, -- Hardware module type
hwSerialNum OCTET STRING, -- H/W module serial number
errorCode FirmwarePackageLoadErrorCode -- Error identifier
vendorErrorCode VendorErrorCode, -- Optional
fwPkgName PreferredOrLegacyPackageIdentifier, -- Optional
config SEQUENCE OF CurrentFWConfig, -- Optional
}
CurrentFWConfig { -- Repeated for each package in configuration
fwPkgType INTEGER, -- Firmware package type; Optional
fwPkgName PreferredOrLegacyPackageIdentifier
}
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 that the outermost encapsulation be ContentInfo
[CMS]. The fields of ContentInfo are used as follows:
contentType indicates the type of the associated content. If the
firmware package load error report is signed, then the
encapsulated type MUST be SignedData, and the id-signedData
(1.2.840.113549.1.7.2) object identifier MUST be present in this
field. If the 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 package load
error report is signed, then this field MUST contain the
SignedData. If the report is not signed, then this field MUST
contain the FirmwarePackageLoadError.
4.1.2. SignedData
The SignedData content type contains the firmware package load error
report and one digital signature. If the hardware module locally
stores its certificate, then the certificate can be included as well.
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: