tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4108

 
 
 

Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages

Part 2 of 3, p. 15 to 40
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 15 
2.  Firmware Package Protection

   The Cryptographic Message Syntax (CMS) is used to protect a firmware
   package, which is treated as an opaque binary object.  A digital
   signature is used to protect the firmware package from undetected
   modification and to provide data origin authentication.  Encryption
   is optionally used to protect the firmware package from disclosure,
   and compression is optionally used to reduce the size of the
   protected firmware package.  The CMS ContentInfo content type MUST
   always be present, and it MUST encapsulate the CMS SignedData content
   type.  If the firmware package is encrypted, then the CMS SignedData
   content type MUST encapsulate the CMS EncryptedData content type.  If
   the firmware package is compressed, then either the CMS SignedData

Top      Up      ToC       Page 16 
   content type (when encryption is not used) or the CMS EncryptedData
   content type (when encryption is used) MUST encapsulate the CMS
   CompressedData content type.  Finally, (1) the CMS SignedData content
   type (when neither encryption nor compression is used), (2) the CMS
   EncryptedData content type (when encryption is used, but compression
   is not), or (3) the CMS CompressedData content type (when compression
   is used) MUST encapsulate the simple firmware package using the
   FirmwarePkgData content type defined in this specification (see
   Section 2.1.5).

   The firmware package protection is summarized as follows (see [CMS]
   for the full syntax):

      ContentInfo {
        contentType          id-signedData, -- (1.2.840.113549.1.7.2)
        content              SignedData
      }

      SignedData {
        version              CMSVersion, -- always set to 3
        digestAlgorithms     DigestAlgorithmIdentifiers, -- Only one
        encapContentInfo     EncapsulatedContentInfo,
        certificates         CertificateSet, -- Signer cert. path
        crls                 CertificateRevocationLists, -- Optional
        signerInfos          SET OF SignerInfo -- Only one
      }

      SignerInfo {
        version              CMSVersion, -- always set to 3
        sid                  SignerIdentifier,
        digestAlgorithm      DigestAlgorithmIdentifier,
        signedAttrs          SignedAttributes, -- Required
        signatureAlgorithm   SignatureAlgorithmIdentifier,
        signature            SignatureValue,
        unsignedAttrs        UnsignedAttributes -- Optional
      }

Top      Up      ToC       Page 17 
      EncapsulatedContentInfo {
        eContentType         id-encryptedData, -- (1.2.840.113549.1.7.6)
                             -- OR --
                             id-ct-compressedData,
                                       -- (1.2.840.113549.1.9.16.1.9)
                             -- OR --
                             id-ct-firmwarePackage,
                                       -- (1.2.840.113549.1.9.16.1.16)
        eContent             OCTET STRING
      }                            -- Contains EncryptedData OR
                                   -- CompressedData OR
                                   -- FirmwarePkgData

      EncryptedData {
        version              CMSVersion, -- Always set to 0
        encryptedContentInfo EncryptedContentInfo,
        unprotectedAttrs     UnprotectedAttributes -- Omit
      }

      EncryptedContentInfo {
        contentType          id-ct-compressedData,
                                       -- (1.2.840.113549.1.9.16.1.9)
                             -- OR --
                             id-ct-firmwarePackage,
                                       -- (1.2.840.113549.1.9.16.1.16)
        contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
        encryptedContent OCTET STRING
      }                                -- Contains CompressedData OR
                                       -- FirmwarePkgData

      CompressedData {
        version              CMSVersion, -- Always set to 0
        compressionAlgorithm CompressionAlgorithmIdentifier,
        encapContentInfo     EncapsulatedContentInfo
      }

      EncapsulatedContentInfo {
        eContentType         id-ct-firmwarePackage,
                                         -- (1.2.840.113549.1.9.16.1.16)
        eContent             OCTET STRING -- Contains FirmwarePkgData
      }

      FirmwarePkgData         OCTET STRING -- Contains firmware package

Top      Up      ToC       Page 18 
2.1.  Firmware Package Protection CMS Content Type Profile

   This section specifies the conventions for using the CMS ContentInfo,
   SignedData, EncryptedData, and CompressedData content types.  It also
   defines the FirmwarePkgData content type.

2.1.1.  ContentInfo

   The CMS requires that the outermost encapsulation be ContentInfo
   [CMS].  The fields of ContentInfo are used as follows:

      contentType indicates the type of the associated content, and in
         this case, the encapsulated type is always SignedData.  The
         id-signedData (1.2.840.113549.1.7.2) object identifier MUST be
         present in this field.

      content holds the associated content, and in this case, the
         content field MUST contain SignedData.

2.1.2.  SignedData

   The SignedData content type [CMS] contains the signed firmware
   package (which might be compressed, encrypted, or compressed and then
   encrypted prior to signature), the certificates needed to validate
   the signature, and one digital signature value.  The fields of
   SignedData are used as follows:

   version is the syntax version number, and in this case, it MUST be
      set to 3.

   digestAlgorithms is a collection of message digest algorithm
      identifiers, and in this case, it MUST contain a single message
      digest algorithm identifier.  The message digest algorithm
      employed by the firmware package signer MUST be present.

   encapContentInfo contains the signed content, consisting of a content
      type identifier and the content itself.  The use of the
      EncapsulatedContentInfo type is discussed further in Section
      2.1.2.2.

   certificates is an optional collection of certificates.  If the trust
      anchor signed the firmware package directly, then certificates
      SHOULD be omitted.  If it did not, then certificates SHOULD
      include the X.509 certificate of the firmware package signer.  The
      set of certificates SHOULD be sufficient for the bootstrap loader
      to construct a certification path from the trust anchor to the
      firmware-signer's certificate.  PKCS#6 extended certificates

Top      Up      ToC       Page 19 
      [PKCS#6] and attribute certificates (either version 1 or
      version 2) [X.509-97, X.509-00, ACPROFILE] MUST NOT be included in
      the set of certificates.

   crls is an optional collection of certificate revocation lists
      (CRLs), and in this case, CRLs SHOULD NOT be included by the
      firmware package signer.  It is anticipated that firmware packages
      may be generated, signed, and made available in repositories for
      downloading into hardware modules.  In such contexts, it would be
      difficult for the firmware package signer to include timely CRLs
      in the firmware package.  However, because the CRLs are not
      covered by the signature, timely CRLs MAY be inserted by some
      other party before the firmware package is delivered to the
      hardware module.

   signerInfos is a collection of per-signer information, and in this
      case, the collection MUST contain exactly one SignerInfo.  The use
      of the SignerInfo type is discussed further in Section 2.1.2.1.

2.1.2.1.  SignerInfo

   The firmware package signer is represented in the SignerInfo type.
   The fields of SignerInfo are used as follows:

   version is the syntax version number, and it MUST be 3.

   sid identifies the signer's public key.  CMS supports two
      alternatives: issuerAndSerialNumber and subjectKeyIdentifier.
      However, the bootstrap loader MUST support the
      subjectKeyIdentifier alternative, which identifies the signer's
      public key directly.  When this public key is contained in a
      certificate, this identifier SHOULD appear in the X.509
      subjectKeyIdentifier extension.

   digestAlgorithm identifies the message digest algorithm, and any
      associated parameters, used by the firmware package signer.  It
      MUST contain the message digest algorithms employed by the
      firmware package signer.  (Note that this message digest algorithm
      identifier MUST be the same as the one carried in the
      digestAlgorithms value in SignedData.)

   signedAttrs is an optional collection of attributes that are signed
      along with the content.  The signedAttrs are optional in the CMS,
      but in this specification, signedAttrs are REQUIRED for the
      firmware package; however, implementations MUST ignore
      unrecognized signed attributes.  The SET OF attributes MUST be DER

Top      Up      ToC       Page 20 
      encoded [X.509-88].  Section 2.2 of this document lists the
      attributes that MUST be included in the collection; other
      attributes MAY be included as well.

   signatureAlgorithm identifies the signature algorithm, and any
      associated parameters, used by the firmware package signer to
      generate the digital signature.

   signature is the digital signature value.

   unsignedAttrs is an optional SET of attributes that are not signed.
      As described in Section 2.3, this set can only contain a single
      instance of the wrapped-firmware-decryption-key attribute and no
      others.

2.1.2.2.  EncapsulatedContentInfo

   The EncapsulatedContentInfo content type encapsulates the firmware
   package, which might be compressed, encrypted, or compressed and then
   encrypted prior to signature.  The firmware package, in any of these
   formats, is carried within the EncapsulatedContentInfo type.  The
   fields of EncapsulatedContentInfo are used as follows:

   eContentType is an object identifier that uniquely specifies the
      content type, and in this case, the value MUST be 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 eContentType contains id-
      encryptedData, the firmware package was encrypted prior to
      signing, and may also have been compressed prior to encryption.
      When it contains id-ct-compressedData, the firmware package was
      compressed prior to signing, but was not encrypted.  When it
      contains id-ct-firmwarePackage, the firmware package was not
      compressed or encrypted prior to signing.

   eContent contains the signed firmware package, which might also be
      encrypted, compressed, or compressed and then encrypted, prior to
      signing.  The content is encoded as an octet string.  The eContent
      octet string need not be DER encoded.

2.1.3.  EncryptedData

   The EncryptedData content type [CMS] contains the encrypted firmware
   package (which might be compressed prior to encryption).  However, if
   the firmware package was not encrypted, the EncryptedData content
   type is not present.  The fields of EncryptedData are used as
   follows:

Top      Up      ToC       Page 21 
   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, which might be compressed prior to
   encryption, is encapsulated in the EncryptedContentInfo type.  The
   fields of EncryptedContentInfo are used as follows:

   contentType indicates the type of content, and in this case, it MUST
      contain either id-ct-compressedData (1.2.840.113549.1.9.16.1.9) or
      id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16).  When it
      contains id-ct-compressedData, then the firmware package was
      compressed prior to encryption.  When it contains id-ct-
      firmwarePackage, then the firmware package was not compressed
      prior to encryption.

   contentEncryptionAlgorithm identifies the firmware-encryption
      algorithm, and any associated parameters, used to encrypt the
      firmware package.

   encryptedContent is the result of encrypting the firmware package.
      The field is optional; however, in this case, it MUST be present.

2.1.4.  CompressedData

   The CompressedData content type [COMPRESS] contains the compressed
   firmware package.  If the firmware package was not compressed, then
   the CompressedData content type is not present.  The fields of
   CompressedData are used as follows:

   version is the syntax version number; in this case, it MUST be 0.

   compressionAlgorithm identifies the compression algorithm, and any
      associated parameters, used to compress the firmware package.

   encapContentInfo is the compressed content, consisting of a content
      type identifier and the content itself.  The use of the
      EncapsulatedContentInfo type is discussed further in Section
      2.1.4.1.

Top      Up      ToC       Page 22 
2.1.4.1.  EncapsulatedContentInfo

   The CompressedData content type encapsulates the compressed 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, it MUST be the value of id-ct-
      firmwarePackage (1.2.840.113549.1.9.16.1.16).

   eContent is the compressed firmware package, encoded as an octet
      string.  The eContent octet string need not be DER encoded.

2.1.5.  FirmwarePkgData

   The FirmwarePkgData content type contains the firmware package.  It
   is a straightforward encapsulation in an octet string, and it need
   not be DER encoded.

   The FirmwarePkgData content type is identified by the id-ct-
   firmwarePackage object identifier:

      id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        smime(16) ct(1) 16 }

   The FirmwarePkgData content type is a simple octet string:

      FirmwarePkgData ::= OCTET STRING

2.2.  Signed Attributes

   The firmware package 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.

Top      Up      ToC       Page 23 
   The SignedAttributes syntax within signerInfo is defined as a SET OF
   Attribute.  The SignedAttributes MUST include only one instance of
   any particular attribute.

   The firmware package 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 package
   signer MUST also include the decrypt-key-identifier attribute.

   If the firmware package implements cryptographic algorithms, then the
   firmware package signer MAY also include the implemented-crypto-
   algorithms attribute.  Similarly, if the firmware package implements
   compression algorithms, then the firmware package signer MAY also
   include the implemented-compress-algorithms attribute.

   If the firmware package is intended for use only by specific
   communities, then the firmware package signer MUST also include the
   community-identifiers attribute.

   If the firmware package depends on the presence of one or more other
   firmware packages to operate properly, then the firmware package
   signer SHOULD also include the firmware-package-info attribute.  For
   example, the firmware-package-info attribute dependencies field might
   indicate that the firmware package contains a dependency on a
   particular bootstrap loader or separation kernel.

   The firmware package signer SHOULD also include the three following
   attributes: firmware-package-message-digest, signing-time, and
   content-hints.  Additionally, if the firmware package signer has a
   certificate (meaning that the firmware package signer is not always
   configured as a trust anchor), then the firmware package signer
   SHOULD also include the signing-certificate attribute.

   The firmware package signer MAY include any other attribute that it
   deems appropriate.

2.2.1.  Content Type

   The firmware package 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, the
   firmware package was encrypted prior to signing.  When it contains
   id-ct-compressedData, the firmware package was compressed prior to
   signing, but was not encrypted.  When it contains

Top      Up      ToC       Page 24 
   id-ct-firmwarePackage, 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 package signer MUST include a message-digest attribute,
   having as its value the message digest computed on the
   encapContentInfo eContent octet string, as defined in Section
   2.1.2.2.  This octet string contains the firmware package, and it MAY
   be compressed, encrypted, or both compressed and encrypted.  Section
   11.2 of [CMS] defines the message-digest attribute.

2.2.3.  Firmware Package Identifier

   The firmware-package-identifier attribute names the protected
   firmware package.  Two approaches to naming firmware packages are
   supported:  legacy and preferred.  The firmware package signer MUST
   include a firmware-package-identifier attribute using one of these
   name forms.

   A legacy firmware package name is an octet string, and no structure
   within the octet string is assumed.

   A preferred firmware package name is a combination of 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.

   If a firmware package with a disastrous flaw is released, the
   firmware package that repairs the previously distributed flaw MAY
   designate a stale firmware package version to prevent the reloading
   of the flawed version.  The hardware module bootstrap loader SHOULD
   prevent subsequent rollback to the stale version or versions earlier
   than the stale version.  When the legacy firmware package name form
   is used, the stale version is indicated by a stale legacy firmware
   package name, which is an octet string.  We assume that the firmware
   package signer and the bootstrap loader can determine whether a given
   legacy firmware package name represents a version that is more recent
   than the stale one.  When the preferred firmware package name form is
   used, the stale version is indicated by a stale version number, which
   is an integer.

Top      Up      ToC       Page 25 
   The following object identifier identifies the firmware-package-
   identifier attribute:

      id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        smime(16) aa(2) 35 }

   The firmware-package-identifier attribute values have ASN.1 type
   FirmwarePackageIdentifier:

      FirmwarePackageIdentifier ::= SEQUENCE {
        name PreferredOrLegacyPackageIdentifier,
        stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }

      PreferredOrLegacyPackageIdentifier ::= CHOICE {
        preferred PreferredPackageIdentifier,
        legacy OCTET STRING }

      PreferredPackageIdentifier ::= SEQUENCE {
        fwPkgID OBJECT IDENTIFIER,
        verNum INTEGER (0..MAX) }

      PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
        preferredStaleVerNum INTEGER (0..MAX),
        legacyStaleVersion OCTET STRING }

2.2.4.  Target Hardware Module Identifiers

   The target-hardware-module-identifiers attribute names the types of
   hardware modules that the firmware package supports.  A unique object
   identifier names each supported hardware model type and revision.

   The bootstrap loader MUST reject the firmware package if its own
   hardware module type identifier is not listed in the target-
   hardware-module-identifiers attribute.

   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

Top      Up      ToC       Page 26 
2.2.5.  Decrypt Key Identifier

   The decrypt-key-identifier attribute names the symmetric key needed
   to decrypt the encapsulated firmware package.  The CMS EncryptedData
   content type is used when the firmware package is encrypted.  The
   decrypt-key-identifier signed attribute is carried in the SignedData
   content type that encapsulates EncryptedData content type, naming the
   symmetric key needed to decrypt the 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; however, an optional mechanism for
   securely distributing the firmware-decryption key with the firmware
   package is specified in Section 2.3.1.

   The following object identifier identifies the decrypt-key-identifier
   attribute:

      id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        smime(16) aa(2) 37 }

   The decrypt-key-identifier attribute values have ASN.1 type
   DecryptKeyIdentifier:

      DecryptKeyIdentifier ::= OCTET STRING

2.2.6.  Implemented Crypto Algorithms

   The implemented-crypto-algorithms attribute MAY be present in the
   SignedAttributes, and it 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 listed.  Any cryptographic algorithm that is
   used internally and is not accessible via the cryptographic module
   interface MUST NOT be listed.  For example, if the firmware package
   implements the decryption algorithm for future firmware package
   installations and this algorithm is not made available for other
   uses, then the firmware-decryption algorithm would not be listed.

   The object identifier portion of AlgorithmIdentifier identifies an
   algorithm and its mode of use.  No algorithm parameters are included.
   Cryptographic algorithms include traffic-encryption algorithms, key-
   encryption algorithms, key transport algorithms, key agreement
   algorithms, one-way hash algorithms, and digital signature
   algorithms.  Cryptographic algorithms do not include compression
   algorithms.

Top      Up      ToC       Page 27 
   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.  Implemented Compression Algorithms

   The implemented-compress-algorithms attribute MAY be present in the
   SignedAttributes, and it names the compression algorithms that are
   implemented by the firmware package and available to applications.
   Only those algorithms that are made available at the interface of the
   hardware module are listed.  Any compression algorithm that is used
   internally and is not accessible via the hardware module interface
   MUST NOT be listed.  For example, if the firmware package implements
   a decompression algorithm for future firmware package installations
   and this algorithm is not made available for other uses, then the
   firmware-decompression algorithm would not be listed.

   The object identifier portion of AlgorithmIdentifier identifies a
   compression algorithm.  No algorithm parameters are included.

   The following object identifier identifies the implemented-compress-
   algorithms attribute:

      id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        smime(16) aa(2) 43 }

   The implemented-compress-algorithms attribute values have ASN.1 type
   ImplementedCompressAlgorithms:

      ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER

2.2.8.  Community Identifiers

   If present in the SignedAttributes, the community-identifiers
   attribute names the communities that are permitted to execute the
   firmware package.  The bootstrap loader MUST reject the firmware
   package if the hardware module is not a member of one of the
   identified communities.  The means of assigning community membership
   is beyond the scope of this specification.

Top      Up      ToC       Page 28 
   The community-identifiers attributes names the authorized communities
   by a list of community object identifiers, by a list of specific
   hardware modules, or by a combination of the two lists.  A specific
   hardware module is specified by the combination of the hardware
   module identifier (as defined in Section 2.2.4) and a serial number.
   To facilitate compact representation of serial numbers, a contiguous
   block can be specified by the lowest authorized serial number and the
   highest authorized serial number.  Alternatively, all of the serial
   numbers associated with a hardware module family identifier can be
   specified with the NULL value.

   If the bootstrap loader does not have a mechanism for obtaining a
   list of object identifiers that identify the communities to which the
   hardware module is a member, then the bootstrap loader MUST behave as
   though the list is empty.  Similarly, if the bootstrap loader does
   not have access to the hardware module serial number, then the
   bootstrap loader MUST behave as though the hardware module is not
   included on the list of authorized hardware modules.

   The following object identifier identifies the community-identifiers
   attribute:

      id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        smime(16) aa(2) 40 }

   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 {
        all NULL,
        single OCTET STRING,
        block SEQUENCE {
          low OCTET STRING,
          high OCTET STRING } }

Top      Up      ToC       Page 29 
2.2.9.  Firmware Package Information

   If a hardware module supports more than one type of firmware package,
   then the firmware package signer SHOULD include the firmware-
   package-info attribute with a populated fwPkgType field to identify
   the firmware package type.  This value can aid the bootstrap loader
   in the correct placement of the firmware package within the hardware
   module.  The firmware package type is an INTEGER, and the meaning of
   the integer value is specific to each hardware module.  For example,
   a hardware module could assign different integer values for a
   bootstrap loader, a separation kernel, and an application.

   Some hardware module architectures permit one firmware package to use
   routines provided by another.  If the firmware package contains a
   dependency on another, then the firmware package signer SHOULD also
   include the firmware-package-info attribute with a populated
   dependencies field.  If the firmware package does not depend on any
   other firmware packages, then the firmware package signer MUST NOT
   include the firmware-package-info attribute with a populated
   dependencies field.

   Firmware package dependencies are identified by the firmware package
   identifier or by information contained in the firmware package
   itself, and in either case the bootstrap loader ensures that the
   dependencies are met.  The bootstrap loader MUST reject a firmware
   package load if it identifies a dependency on a firmware package that
   is not already loaded.  Also, the bootstrap loader MUST reject a
   firmware package load if the action will result in a configuration
   where the dependencies of an already loaded firmware package will no
   longer be satisfied.  As described in Section 2.2.3, two approaches
   to naming firmware packages are supported: legacy and preferred.
   When the legacy firmware package name form is used, the dependency is
   indicated by a legacy firmware package name.  We assume that the
   firmware package signer and the bootstrap loader can determine
   whether a given legacy firmware package name represents the named
   version of an acceptable newer version.  When the preferred firmware
   package name form is used, an object identifier and an integer are
   provided.  The object identifier MUST exactly match the object
   identifier portion of a preferred firmware package name associated
   with a firmware package that is already loaded, and the integer MUST
   be less than or equal to the integer portion of the preferred
   firmware package name associated with the same firmware package.
   That is, the dependency specifies the minimum value of the version
   that is acceptable.

Top      Up      ToC       Page 30 
   The following object identifier identifies the firmware-package-info
   attribute:

      id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        smime(16) aa(2) 42 }

   The firmware-package-info attribute values have ASN.1 type
   FirmwarePackageInfo:

      FirmwarePackageInfo ::= SEQUENCE {
        fwPkgType INTEGER OPTIONAL,
        dependencies SEQUENCE OF
          PreferredOrLegacyPackageIdentifier OPTIONAL }

2.2.10.  Firmware Package Message Digest

   The firmware package signer SHOULD include a firmware-package-
   message-digest attribute, which provides the message digest algorithm
   and the message digest value computed on the firmware package.  The
   message digest is computed on the firmware package prior to any
   compression, encryption, or signature processing.  The bootstrap
   loader MAY use this message digest to confirm that the intended
   firmware package has been recovered after all of the layers of
   encapsulation are removed.

   The following object identifier identifies the firmware-package-
   message-digest attribute:

      id-aa-fwPkgMessageDigest OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        smime(16) aa(2) 41 }

   The firmware-package-message-digest attribute values have ASN.1 type
   FirmwarePackageMessageDigest:

      FirmwarePackageMessageDigest ::= SEQUENCE {
        algorithm AlgorithmIdentifier,
        msgDigest OCTET STRING }

2.2.11.  Signing Time

   The firmware package signer SHOULD include a signing-time attribute,
   specifying the time at which the signature was applied to the
   firmware package.  Section 11.3 of [CMS] defines the signing-time
   attribute.

Top      Up      ToC       Page 31 
2.2.12.  Content Hints

   The firmware package 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.

   When multiple layers of encapsulation are employed, the content-hints
   attribute is included in the outermost SignedData to provide
   information about the innermost content.  In this case, the content-
   hints attribute provides a brief text description of the firmware
   package, which can help a person select the correct firmware package
   when more than one is available.

   When the preferred firmware package name forms are used, the
   content-hints attribute can provide a linkage to a legacy firmware
   package name.  This is especially helpful when an existing
   configuration management system is in use, but the features
   associated with the preferred firmware package name are deemed
   useful.  A firmware package name associated with such a configuration
   management system might look something like
   "R1234.C0(AJ11).D62.A02.11(b)."  Including these firmware package
   names in the text description may be helpful to developers by
   providing a clear linkage between the two name forms.

   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.13.  Signing Certificate

   When the firmware-signer's public key is contained in a certificate,
   the firmware package signer SHOULD include a signing-certificate
   attribute to identify the certificate that was employed.  However, if
   the firmware package signature does not have a certificate (meaning
   that the signature will only be validated with the trust anchor
   public key), then the firmware package signer is unable to include a
   signing-certificate attribute.  Section 5.4 of [ESS] defines this
   attribute.

Top      Up      ToC       Page 32 
   The signing-certificate attribute contains two fields: certs and
   policies.  The certs field MUST be present, and the policies field
   MAY be present.  The fields of SigningCertificate are used as
   follows:

   certs contains a sequence of certificate identifiers.  In this case,
      sequence of certificate identifiers contains a single entry.  The
      certs field MUST contain only the certificate identifier of the
      certificate that contains the public key used to verify the
      firmware package 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; 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.

Top      Up      ToC       Page 33 
   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.

Top      Up      ToC       Page 34 
   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.

Top      Up      ToC       Page 35 
   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
   }

Top      Up      ToC       Page 36 
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

Top      Up      ToC       Page 37 
      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.)

Top      Up      ToC       Page 38 
   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 }

Top      Up      ToC       Page 39 
   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

Top      Up      ToC       Page 40 
   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.


Next RFC Part