Network Working Group R. Housley Internet Draft Vigil Security expires in six months April 2003 Using CMS to Protect Firmware Packages 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 April 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 .................... 9 1.2.4 Cryptographic Algorithm Requirements ............. 11 2 Firmware Package Protection .................................... 11 2.1 Firmware Package Protection CMS Content Type Profile ..... 13 2.1.1 ContentInfo ...................................... 13 2.1.2 SignedData ....................................... 14 2.1.2.1 SignerInfo ............................. 15 2.1.2.2 EncapsulatedContentInfo ................ 16 2.1.3 EncryptedData .................................... 16 2.1.3.1 EncryptedContentInfo ................... 16 2.1.4 CompressedData ................................... 17 2.1.4.1 EncapsulatedContentInfo ................ 17 2.1.5 FirmwarePkgData .................................. 17 2.2 Signed Attributes ........................................ 18 2.2.1 Content Type ..................................... 19 2.2.2 Message Digest ................................... 19 2.2.3 Firmware Package Identifier ...................... 19 2.2.4 Target Hardware Module Identifiers ............... 20 2.2.5 Decrypt Key Identifier ........................... 20 2.2.6 Implemented Crypto Algorithms .................... 21 2.2.7 Community Identifiers ............................ 21 2.2.8 Signing Time ..................................... 22 2.2.9 Content Hints .................................... 22 2.2.10 Signing Certificate .............................. 23 2.3 Unsigned Attributes ...................................... 24 2.3.1 Wrapped Firmware-Decryption Key .................. 24 3 Firmware Package Load Receipt .................................. 25 3.1 Firmware Package Load Receipt CMS Content Type Profile ... 27 3.1.1 ContentInfo ...................................... 27 3.1.2 SignedData ....................................... 27 3.1.2.1 SignerInfo ............................. 28 3.1.2.2 EncapsulatedContentInfo ................ 29 3.1.3 FirmwarePackageLoadReceipt ....................... 29 3.2 Signed Attributes ........................................ 30 3.2.1 Content Type ..................................... 30 3.2.2 Message Digest ................................... 30 3.2.3 Signing Time ..................................... 30 Housley [Page 2] INTERNET DRAFT April 2003 4 Hardware Module Name ........................................... 31 5 References ..................................................... 32 5.1 Normative References ..................................... 32 5.2 Informative References ................................... 32 6 Security Considerations ........................................ 33 7 Author Address ................................................. 34 Appendix A: ASN.1 Module .......................................... 35 Appendix B: Change History ........................................ 38 Full Copyright Statement ........................................... 39 Housley [Page 3] INTERNET DRAFT April 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 firmware package load receipts. The CMS is a data protection encapsulation syntax that makes use of ASN.1 [X.208-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. 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 efficient 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. However, the key might be delivered via physical media, delivered via an independent electronic path, or embedded in the hardware module at the factory by the hardware module vendor. (This latter approach might be appropriate if a security analysis determines that the module provides adequate security for an embedded firmware-decryption key and a permanent key is acceptable for this application. Alternatively, an embedded key-encryption key might be employed to facilitate electronic firmware-decryption delivery.) Similarly, the signature verification public key must be made available to the module in a secure fashion. CMS provides for carriage of certificates, and this facility is used to transfer a certificate that contains the signature verification public key (a firmware-signing certificate). However, use of this facility introduces one or more 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 Housley [Page 4] INTERNET DRAFT April 2003 contain one or more embedded trust anchors. Hardware modules may not be capable of accessing certificate repositories or delegated path discovery (DPD) servers to acquire certificates needed to complete a certification path. Thus, it is the responsibility of the firmware package signer to include sufficient certificates to enable each module to validate the firmware-signer certificate (see Section 2.1.2). Similarly, hardware modules may not be capable of accessing a CRL repository, an OCSP responder, or delegated path validation (DPV) server to acquire revocation status information. Thus, 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 and a valid firmware-signer certification path. Thus, the trust anchors define the set of entities that can create firmware packages for the hardware module. After the hardware module successfully validates a firmware package for loading, the disposition of the previous 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. 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 Housley [Page 5] INTERNET DRAFT April 2003 access to one or more trusted public keys, called trust anchors, to validate the firmware signer's certificate. If a firmware loading receipt is generated, the bootstrap loader uses the private signature key to sign the receipt and includes the signature validation certificate to aid receipt validation. To implement this optional capability, 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 are usually generated and installed as part of the hardware module manufacture process. Figure 1 illustrates these 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 | | | | | +---------------+ +--------------------------+ | | | | +------------------------------------+ | | | Private Signature Key and | | | | Signature Validation Certificate | | | +------------------------------------+ | | | +------------------------------------------------------+ Figure 1. Architectural Elements Details of managing the trust anchors are outside the scope of this specification. However, the module vendor is REQUIRED to embed one or more trust anchors in a module during manufacture. These trust Housley [Page 6] INTERNET DRAFT April 2003 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. ASN.1 object identifiers are used to name the architectural elements. 1.2.1 Hardware Module Requirements Many different vendors develop hardware modules, and each vendor typically identifies its modules by product type (family) and revision level. A unique object identifier MUST name each hardware module type and revision. Each hardware module within a family of hardware modules SHOULD have a unique serial number. If present, the bootstrap loader MUST have read access to the serial number. The bootstrap loader uses the serial number for authorization decisions (see section 2.2.7) and receipt generation (see section 3). If the optional receipt generation capability is implemented, then the hardware module MUST have a unique serial number, a private signature key, and a certificate containing the corresponding public signature validation key. The hardware module includes one or more processors. When there are multiple processors, one of the processors MUST be responsible for bootstrap loader processing. Once the firmware package is validated, the bootstrap loader processor distributes components of the package to the appropriate processors within the hardware module. 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. A unique object identifier Housley [Page 7] INTERNET DRAFT April 2003 MUST identify the collection of features that characterize the firmware package. For example, firmware packages for a cable modem and a wireless LAN network interface card warrant distinct object identifiers. Similarly, firmware packages that implement distinct suites of cryptographic algorithms and modes of operation, or 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. 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. The firmware package MUST contain a certificate path that begins with a certificate issued by one of the trust anchors and ends with a certificate issued to the firmware signer. 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 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. 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]. Housley [Page 8] INTERNET DRAFT April 2003 When 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 a new one contained in a subsequent firmware package. In Figure 1, the bootstrap loader is implemented as separate logic within the hardware module. Not all hardware modules will include the ability to replace or update the bootstrap loader, and this specification does not mandate such support. Moreover, this specification does not make explicit provisions for separate carriage of a replacement bootstrap loader within the firmware package. The firmware package contents are treated as an opaque binary object. When the bootstrap loader is part of the firmware package, the factory MUST install the first firmware package and the trusted anchors in non-volatile memory. This initial firmware package MUST contain the bootstrap loader; it MAY also contain other routines. When using separate logic within the hardware module to implement the bootstrap loader, two approaches are anticipated. The bootstrap loader can be implemented directly in the hardware, or more likely, the bootstrap loader can be implemented by a separate firmware package stored in read-only memory or a reserved portion of non- volatile memory. As before, the factory MUST install the bootstrap loader and the trust anchors. 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 (like AES), employ separate logic for encryption and decryption, some hardware module savings might result. Housley [Page 9] INTERNET DRAFT April 2003 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 certification path of the firmware package signer. The bootstrap loader MUST reject a firmware package if it cannot construct a valid certification path from the firmware-signing certificate to one of the trust anchors [PROFILE]. 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 it cannot validate the firmware package digital signature using the public key from the firmware-signing certificate. The bootstrap loader MUST reject a firmware package if the package's list of supported modules 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; however, two mechanisms are anticipated, but others are possible. One mechanism uses an attribute certificate signed by an appropriate trust anchor to bind the hardware module serial number and a community identifier. Another mechanism explicitly names the community members by hardware module serial number. 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. Housley [Page 10] INTERNET DRAFT April 2003 1.2.4 Cryptographic Algorithm Requirements Firmware for cryptographic hardware modules will include cryptographic algorithm implementations; however, firmware for other types of hardware modules MAY include cryptographic algorithm implementations for the validation 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 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 encoding conventions for these attributes. 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). Housley [Page 11] INTERNET DRAFT April 2003 The firmware protection is summarized by: 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 } 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 } Housley [Page 12] INTERNET DRAFT April 2003 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 } 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. Housley [Page 13] INTERNET DRAFT April 2003 2.1.2 SignedData The SignedData content type [CMS] contains the signed firmware package (which might be encrypted or compressed 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, 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 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. certificates is an optional collection of certificates. If the trust anchor directly signed the firmware package, then certificates is omitted. If the trust anchor signed a certificate, then certificates MUST include the X.509 certificate of the firmware signer. The set of certificates MUST 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. Housley [Page 14] INTERNET DRAFT April 2003 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 either 1 or 3, depending on the method used to identify the firmware signer's public key. The use of the subjectKeyIdentifier (resulting in a version of 3) is RECOMMENDED. sid specifies the signer's certificate (and thereby the signer's public key). Two alternatives are supported, and the bootstrap loader MUST support both alternatives. The issuerAndSerialNumber alternative identifies the signer's certificate by the issuer's distinguished name and the certificate serial number; the subjectKeyIdentifier alternative identifies the signer's certificate by the X.509 subjectKeyIdentifier extension value. The use of the subjectKeyIdentifier by firmware signers is RECOMMENDED. 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 a collection of attributes that are signed along with the firmware package. The signedAttrs are optional in the CMS, but in this specification, signedAttrs are REQUIRED. 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 collection of attributes that are not signed. Section 2.3 of this document lists the attributes that MAY be included in the collection. Housley [Page 15] INTERNET DRAFT April 2003 2.1.2.2 EncapsulatedContentInfo The EncryptedData content type encapsulates the encrypted firmware package, 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, 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. 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). The fields of EncryptedData are used as 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- Housley [Page 16] INTERNET DRAFT April 2003 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 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. Housley [Page 17] INTERNET DRAFT April 2003 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. 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. The firmware signer SHOULD also include the three following Housley [Page 18] INTERNET DRAFT April 2003 attributes: signing-time, content-hints, and signing-certificate. 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 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 of the signed firmware package (which might be encrypted or compressed prior to signing). 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 MAY designate a stale version number. 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 } Housley [Page 19] INTERNET DRAFT April 2003 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. 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 Housley [Page 20] INTERNET DRAFT April 2003 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 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 load 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 determining community membership is beyond the scope of this specification. Two mechanisms are anticipated, but others are possible. One mechanism uses an attribute certificate signed by an appropriate trust anchor to bind the hardware module serial number and a community identifier. In this case, an object identifier names the community. Another mechanism explicitly names the community members by hardware module serial number. The community-identifiers attribute type names the authorized communities by a list of object identifiers, by a list of hardware module identifiers, or by a combination of the two. 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 Housley [Page 21] INTERNET DRAFT April 2003 by the lowest authorized serial number and the highest authorized serial number. 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 } 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 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.9 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. Housley [Page 22] INTERNET DRAFT April 2003 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.10 Signing Certificate The firmware signer SHOULD include a signing-certificate attribute, identifying the certificate the used by the firmware signer. Section 5.4 of [ESS] defines the signing-certificate attribute. 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 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 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. Housley [Page 23] INTERNET DRAFT April 2003 2.3 Unsigned Attributes A collection of unsigned attributes MAY be included. Since the digital signature does not cover these attributes, they 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 the 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 NOT be zero nor more than one instances of AttributeValue present. The UnsignedAttributes syntax within signerInfo is defined as a SET OF Attributes. The UnsignedAttributes MUST include only one instance of any particular attribute. The signed firmware package MAY include the wrapped-firmware- decryption-key attribute. The signed firmware package MUST NOT include any unsigned attributes other than the wrapped-firmware- decryption-key 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. 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, Housley [Page 24] INTERNET DRAFT April 2003 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. 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 be used to sign a firmware package load receipt. 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. 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 to include in the receipt to aid validation. The firmware package load receipt is encapsulated by SignedData, which is in turn encapsulated by ContentInfo. Housley [Page 25] INTERNET DRAFT April 2003 The firmware package load receipt protection is summarized by: ContentInfo { contentType id-signedData, -- (1.2.840.113549.1.7.2) content SignedData } 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 decryptKeyID OCTET STRING -- Optional } Housley [Page 26] INTERNET DRAFT April 2003 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, 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. 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.) Housley [Page 27] INTERNET DRAFT April 2003 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 (resulting in a version of 3) is RECOMMENDED. sid specifies the hardware module's certificate (and thereby the hardware module's public key). There are two alternatives, but 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 subjectKeyIdentifier alternative identifies the hardware module's certificate by the X.509 subjectKeyIdentifier extension value. 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 a collection of attributes that are signed along with the firmware package load receipt. The signedAttrs are optional in the CMS, but in this specification, signedAttrs are REQUIRED. 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 28] INTERNET DRAFT April 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), decryptKeyID 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. The combination of the fwPkgID and verNum specify a particular Housley [Page 29] INTERNET DRAFT April 2003 firmware package. The version number is a non-negative integer that identifies a particular build or release of the firmware package. decryptKeyID is optional, and when it is present it identifies the firmware-decryption key that was used to decrypt the firmware package. 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. 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. Housley [Page 30] INTERNET DRAFT April 2003 4 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 issues the signature validation certificate. It is expected that this will be done at the time of manufacture. The subject 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 } The fields of the HardwareModuleName type have the following meanings: hwType is an object identifier that identifies the type of hardware module. 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. Housley [Page 31] INTERNET DRAFT April 2003 5 References This section provides normative and informative references. 5.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. X.509-88 CCITT. Recommendation X.509: The Directory - Authentication Framework. 1988. 5.2 Informative References ACPROFILE Farrell, S., and R. Housley. An Internet Attribute Certificate Profile for Authorization. RFC 3281. April 2002. Housley [Page 32] INTERNET DRAFT April 2003 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. 6 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. The firmware-decryption key must be protected. Compromise of the key may result in the disclosure of the firmware to unauthorized parties. 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 Housley [Page 33] INTERNET DRAFT April 2003 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 with common trust anchors that are likely to be developed for the hardware module. 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. 7 Author Address Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA housley@vigilsec.com Housley [Page 34] INTERNET DRAFT April 2003 Appendix A: ASN.1 Module 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 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 Housley [Page 35] INTERNET DRAFT April 2003 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 } } -- 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 Housley [Page 36] INTERNET DRAFT April 2003 -- 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 } -- 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 Housley [Page 37] INTERNET DRAFT April 2003 Appendix B: Change History Changes in version -01: - Added an optional decryptKeyID to the firmware package load receipt. - Assigned object identifiers. - State that disposition of previously loaded firmware package is beyond scope of this document. - Update Figure 1 by adding two boxes: one for "Hardware Module Type" and one for "Firmware Package Identifier and Version Number" - Removed redundancy between section 1.2.2 and section 1.2.3 regarding the stale version number. - In section 2.1.2, make it clear that the trust anchor itself is not represented in the certificates. - In section 2.3.1, require the content type object identifier to be set to id-data. - Many editorial updates. Housley [Page 38] INTERNET DRAFT April 2003 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 39]