tech-invite   World Map     

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

RFC 4108

 Errata 
Proposed STD
Pages: 61
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~sec-cms

Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages

Part 1 of 3, p. 1 to 15
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                         R. Housley
Request for Comments: 4108                                Vigil Security
Category: Standards Track                                    August 2005


 Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes the use of the Cryptographic Message Syntax
   (CMS) to protect firmware packages, which provide object code for one
   or more hardware module components.  CMS is specified in RFC 3852.  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.  A firmware package loading receipt
   can optionally be generated to acknowledge the successful loading of
   a firmware package.  Similarly, a firmware package load error report
   can optionally be generated to convey the failure to load a firmware
   package.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................3
      1.1. Terminology ................................................5
      1.2. Architectural Elements .....................................5
           1.2.1. Hardware Module Requirements ........................7
           1.2.2. Firmware Package Requirements .......................8
           1.2.3. Bootstrap Loader Requirements .......................9
                  1.2.3.1. Legacy Stale Version Processing ...........11
                  1.2.3.2. Preferred Stale Version Processing ........12
           1.2.4. Trust Anchors ......................................12
           1.2.5. Cryptographic and Compression Algorithm
                  Requirements .......................................13
      1.3. Hardware Module Security Architecture .....................14
      1.4. ASN.1 Encoding ............................................14
      1.5. Protected Firmware Package Loading ........................15
   2. Firmware Package Protection ....................................15
      2.1. Firmware Package Protection CMS Content Type Profile ......18
           2.1.1. ContentInfo ........................................18
           2.1.2. SignedData .........................................18
                  2.1.2.1. SignerInfo ................................19
                  2.1.2.2. EncapsulatedContentInfo ...................20
           2.1.3. EncryptedData ......................................20
                  2.1.3.1. EncryptedContentInfo ......................21
           2.1.4. CompressedData .....................................21
                  2.1.4.1. EncapsulatedContentInfo ...................22
           2.1.5. FirmwarePkgData ....................................22
      2.2. Signed Attributes .........................................22
           2.2.1. Content Type .......................................23
           2.2.2. Message Digest .....................................24
           2.2.3. Firmware Package Identifier ........................24
           2.2.4. Target Hardware Module Identifiers .................25
           2.2.5. Decrypt Key Identifier .............................26
           2.2.6. Implemented Crypto Algorithms ......................26
           2.2.7. Implemented Compression Algorithms .................27
           2.2.8. Community Identifiers ..............................27
           2.2.9. Firmware Package Information .......................29
           2.2.10. Firmware Package Message Digest ...................30
           2.2.11. Signing Time ......................................30
           2.2.12. Content Hints .....................................31
           2.2.13. Signing Certificate ...............................31
      2.3. Unsigned Attributes .......................................32
           2.3.1. Wrapped Firmware Decryption Key ....................33
   3. Firmware Package Load Receipt ..................................34
      3.1. Firmware Package Load Receipt CMS Content Type Profile ....36
           3.1.1. ContentInfo ........................................36

Top      ToC       Page 3 
           3.1.2. SignedData .........................................36
                  3.1.2.1. SignerInfo ................................37
                  3.1.2.2. EncapsulatedContentInfo ...................38
           3.1.3. FirmwarePackageLoadReceipt .........................38
      3.2. Signed Attributes .........................................40
           3.2.1. Content Type .......................................40
           3.2.2. Message Digest .....................................40
           3.2.3. Signing Time .......................................40
   4. Firmware Package Load Error ....................................41
      4.1. Firmware Package Load Error CMS Content Type Profile ......42
           4.1.1. ContentInfo ........................................42
           4.1.2. SignedData .........................................43
                  4.1.2.1. SignerInfo ................................43
                  4.1.2.2. EncapsulatedContentInfo ...................43
           4.1.3. FirmwarePackageLoadError ...........................43
      4.2. Signed Attributes .........................................49
           4.2.1. Content Type .......................................49
           4.2.2. Message Digest .....................................49
           4.2.3. Signing Time .......................................50
   5. Hardware Module Name ...........................................50
   6. Security Considerations ........................................51
      6.1. Cryptographic Keys and Algorithms .........................51
      6.2. Random Number Generation ..................................51
      6.3. Stale Firmware Package Version Number .....................52
      6.4. Community Identifiers .....................................53
   7. References .....................................................54
      7.1. Normative References ......................................54
      7.2. Informative References ....................................54
   Appendix A: ASN.1 Module ..........................................56

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 receipts and error reports for firmware
   package loading.  The CMS is a data protection encapsulation syntax
   that makes use of ASN.1 [X.208-88, X.209-88].  The protected firmware
   package can be associated with any particular hardware module;
   however, this specification was written with the requirements of
   cryptographic hardware modules in mind, as these modules have strong
   security requirements.

   The firmware package contains object code for one or more
   programmable components 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, then encrypted, and then signed.  Compression simply

Top      ToC       Page 4 
   reduces the size of the firmware package, allowing more efficient
   processing and transmission.  Encryption protects the firmware
   package from disclosure, which allows transmission of sensitive
   firmware packages over insecure links.  The encryption algorithm and
   mode employed may also provide integrity, protecting the firmware
   package from undetected modification.  The encryption protects
   proprietary algorithms, classified algorithms, trade secrets, and
   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.  The key might be
   delivered via physical media or via an independent electronic path.
   One optional mechanism for distributing the firmware-decryption key
   is specified in Section 2.3.1, but any secure key distribution
   mechanism is acceptable.

   The signature verification public key must be made available to the
   hardware module in a manner that preserves its integrity and confirms
   its source.  CMS supports the transfer of certificates, and this
   facility can be used to transfer a certificate that contains the
   signature verification public key (a firmware-signing certificate).
   However, use of this facility introduces a 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 store one or more trust anchors.

   Hardware modules may not be capable of accessing certificate
   repositories or delegated path discovery (DPD) servers [DPD&DPV] 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 certificate revocation list
   (CRL) repository, an OCSP responder [OCSP], or a delegated path
   validation (DPV) server [DPD&DPV] to acquire revocation status
   information.  Thus, if the firmware package signature cannot be
   validated solely with the trust anchor public key and the hardware
   module is not capable of performing full certification path
   validation, then 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.

Top      ToC       Page 5 
   Hardware modules will only accept firmware packages with a valid
   digital signature.  The signature is either validated directly using
   the trust anchor public key or using a firmware-signer certification
   path that is validated to the trust anchor public key.  Thus, the
   trust anchors define the set of entities that can create firmware
   packages for the hardware module.

   The disposition of a previously loaded firmware package after the
   successful validation of another 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 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.  Hardware modules can also generate error reports to
   indicate the unsuccessful firmware package loading.  To implement
   either receipt or error report generation, the hardware module is
   required to have a unique permanent serial number.  Receipts and
   error reports can be either signed or unsigned.  To generate
   digitally signed receipts or error reports, a hardware module MUST be
   issued its own private signature key and a certificate that contains
   the corresponding signature validation public key.  In order to save
   memory with the hardware module, the hardware module might store a
   certificate designator instead of the certificate itself.  The
   private signature key requires secure storage.

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 bootstrap loader.  The bootstrap loader MUST have access to one
   or more trusted public keys, called trust anchors, to validate the
   signature on the firmware package.  If a signed firmware package load
   receipt or error report is created on behalf of the hardware module,
   then the bootstrap loader MUST have access to a private signature key
   to generate the signature and the signer identifier for the
   corresponding signature validation certificate or its designator.  A
   signature validation certificate MAY be included to aid signature
   validation.  To implement this optional capability, the hardware
   module MUST have a unique serial number and a private signature key;
   the hardware module MAY also include a certificate that contains the

Top      ToC       Page 6 
   corresponding signature validation public key.  These items MUST be
   installed in the hardware module before it is deployed.  The private
   key and certificate can be generated and installed as part of the
   hardware module manufacture process.  Figure 1 illustrates these
   architectural elements.

   ASN.1 object identifiers are the preferred means of naming the
   architectural elements.

   Details of managing the trust anchors are beyond the scope of this
   specification.  However, one or more trust anchors MUST be installed
   in the hardware module using a secure process before it is deployed.
   These trust 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 necessary to use the
   associated firmware package.  Generally, separate distribution
   mechanisms will be employed for the firmware-decryption key and the
   firmware package.  An optional mechanism for securely distributing
   the firmware-decryption key with the firmware package is specified in
   Section 2.3.1.

Top      ToC       Page 7 
            +------------------------------------------------------+
            |  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  |   |                          |   |
            |   +---------------+   +--------------------------+   |
            |                                                      |
            |        +------------------------------------+        |
            |        |  Optional Private Signature Key &  |        |
            |        |  Signature Validation Certificate  |        |
            |        |  or the Certificate Designator     |        |
            |        +------------------------------------+        |
            |                                                      |
            +------------------------------------------------------+

                     Figure 1.  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 hardware module family SHOULD have a
   unique permanent serial number.  However, if the optional receipt or
   error report generation capability is implemented, then the hardware
   module MUST have a unique permanent serial number.  If the optional
   receipt or error report signature capability is implemented, then the
   hardware module MUST have a private signature key and a certificate
   containing the corresponding public signature validation key or its
   designator.  If a serial number is present, the bootstrap loader uses

Top      ToC       Page 8 
   it for authorization decisions (see Section 2.2.8), receipt
   generation (see Section 3), and error report generation (see
   Section 4).

   When the hardware module includes more than one firmware-programmable
   component, the bootstrap loader distributes components of the package
   to the appropriate components within the hardware module after the
   firmware package is validated.  The bootstrap loader is discussed
   further in Section 1.2.3.

1.2.2.  Firmware Package Requirements

   Two approaches to naming firmware packages are supported: legacy and
   preferred.  Firmware package names are placed in a CMS signed
   attribute, not in the firmware package itself.

   Legacy firmware package names are simply octet strings, and no
   structure is assumed.  This firmware package name form is supported
   in order to facilitate existing configuration management systems.  We
   assume that the firmware signer and the bootstrap loader will
   understand any internal structure to the octet string.  In
   particular, given two legacy firmware package names, we assume that
   the firmware signer and the bootstrap loader will be able to
   determine which one represents the newer version of the firmware
   package.  This capability is necessary to implement the stale version
   feature.  If a firmware package with a disastrous flaw is released,
   subsequent firmware package versions MAY designate a stale legacy
   firmware package name in order to prevent subsequent rollback to the
   stale version or versions earlier than the stale version.

   Preferred firmware package names are a combination of the firmware
   package object identifier and a version number.  A unique object
   identifier 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 that 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.
   If a firmware package with a disastrous flaw is released, subsequent
   firmware package versions MAY designate a stale version number to
   prevent subsequent rollback to the stale version or versions earlier
   than the stale version.

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

   In many cases, the firmware package signature will be validated
   directly with the trust anchor public key, avoiding the need to
   construct certification paths.  Alternatively, the trust anchor can
   delegate firmware package signing to another public key through a
   certification path.  In the latter case, the firmware package SHOULD
   contain the certificates needed to construct the certification path
   that begins with a certificate issued by the trust anchors and ends
   with a certificate issued to the firmware package signer.

   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.

   When a hardware module includes multiple programmable components, the
   firmware package SHOULD contain executable code for all of the
   components.  Internal tagging within the firmware package MUST tell
   the bootstrap loader which portion of the overall firmware package is
   intended for each component; however, this tagging is expected to be
   specific to each hardware module.  Because 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 MUST have access to a physical interface and any
   related driver or protocol software necessary to obtain a firmware
   package.  The same interface SHOULD be used to deliver receipts and
   error reports.  Details of the physical interface as well as the
   driver or protocol software are beyond the scope of this
   specification.

   The bootstrap loader can be a permanent part of the hardware module,
   or it can be replaced by loading a 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.

   If the bootstrap loader can be loaded by a firmware package, an
   initial bootstrap loader MUST be installed in non-volatile memory
   prior to deployment.  All bootstrap loaders, including an initial

Top      ToC       Page 10 
   bootstrap loader if one is employed, MUST meet the requirements in
   this section.  However, the firmware package containing the bootstrap
   loader MAY also contain other routines.

   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.  Because some symmetric encryption
   algorithm implementations (such as AES [AES]) employ separate logic
   for encryption and decryption, some hardware module savings might
   result.

   If firmware packages are compressed, the bootstrap loader MUST also
   have access to a decompression function.  This function can be
   implemented specifically for the bootstrap loader, or it can be
   shared with other hardware module features.  Access to a
   corresponding compression function is not required, since hardware
   modules need not be capable of generating firmware packages.

   If the optional receipt generation or error report capability is
   supported, the bootstrap loader MUST have access to the hardware
   module serial number and the object identifier for the hardware
   module type.  If the optional signed receipt generation or signed
   error report capability is supported, the bootstrap loader MUST also
   have access to a one-way hash function and digital signature
   routines, the hardware module private signing key, and the
   corresponding signature validation certificate or its designator.

   The bootstrap loader requires access to one or more trusted public
   keys, called trust anchors, to validate the firmware package digital
   signature.  One or more trust anchors MUST be installed in non-
   volatile memory prior to deployment.  The bootstrap loader MUST
   reject a firmware package if it cannot validate the signature, which
   MAY require the construction of a valid certification path from the
   firmware-signing certificate to one of the trust anchors [PROFILE].
   However, in many cases, the firmware package signature will be
   validated directly with the trust anchor public key, avoiding the
   need to construct certification paths.

Top      ToC       Page 11 
   The bootstrap loader MUST reject a firmware package if the list of
   supported hardware module type identifiers within the firmware
   package does not include the object identifier of the hardware
   module.

   The bootstrap loader MUST reject a firmware package if the firmware
   package includes a list of community identifiers and the hardware
   module is not a member of one of the listed communities.  The means
   of determining community membership is beyond the scope of this
   specification.

   The bootstrap loader MUST reject a firmware package if it cannot
   successfully decrypt the firmware package using the firmware-
   decryption key available to the hardware module.  The firmware
   package contains an identifier of the firmware-decryption key needed
   for decryption.

   When an earlier version of a firmware package is replacing a later
   one, the bootstrap loader SHOULD generate a warning.  The manner in
   which a warning is generated is highly dependent on the hardware
   module and the environment in which it is being used.  If a firmware
   package with a disastrous flaw is released and subsequent firmware
   package versions designate a stale version, the bootstrap loader
   SHOULD prevent loading of the stale version and versions earlier than
   the stale version.

1.2.3.1.  Legacy Stale Version Processing

   In case a firmware package with a disastrous flaw is released,
   subsequent firmware package versions that employ the legacy firmware
   package name form MAY include a stale legacy firmware package name to
   prevent subsequent rollback to the stale version or versions earlier
   than the stale version.  As described in the Security Considerations
   section of this document, the inclusion of a stale legacy firmware
   package name in a firmware package cannot completely prevent
   subsequent use of the stale firmware package.  However, many hardware
   modules are expected to have very few firmware packages written for
   them, allowing the stale firmware package version feature to provide
   important protections.

   Non-volatile storage for stale version numbers is needed.  The number
   of stale legacy firmware package names that can be stored depends on
   the amount of storage that is available.  When a firmware package is
   loaded and it contains a stale legacy firmware package name, then it
   SHOULD be added to a list kept in non-volatile storage.  When
   subsequent firmware packages are loaded, the legacy firmware package

Top      ToC       Page 12 
   name of the new package is compared to the list in non-volatile
   storage.  If the legacy firmware package name represents the same
   version or an older version of a member of the list, then the new
   firmware packages SHOULD be rejected.

   The amount of non-volatile storage that needs to be dedicated to
   saving legacy firmware package names and stale legacy firmware
   packages names depends on the number of firmware packages that are
   likely to be developed for the hardware module.

1.2.3.2.  Preferred Stale Version Processing

   If a firmware package with a disastrous flaw is released, subsequent
   firmware package versions that employ preferred firmware package name
   form MAY include a stale version number to prevent subsequent
   rollback to the stale version or versions earlier than the stale
   version.  As described in the Security Considerations section of this
   document, the inclusion of a stale version number in a firmware
   package cannot completely prevent subsequent use of the stale
   firmware package.  However, many hardware modules are expected to
   have very few firmware packages written for them, allowing the stale
   firmware package version feature to provide important protections.

   Non-volatile storage for stale version numbers is needed.  The number
   of stale version numbers that can be stored depends on the amount of
   storage that is available.  When a firmware package is loaded and it
   contains a stale version number, then the object identifier of the
   firmware package and the stale version number SHOULD be added to a
   list that is kept in non-volatile storage.  When subsequent firmware
   packages are loaded, the object identifier and version number of the
   new package are compared to the list in non-volatile storage.  If the
   object identifier matches and the version number is less than or
   equal to the stale version number, then the new firmware packages
   SHOULD be rejected.

   The amount of non-volatile storage that needs to be dedicated to
   saving firmware package identifiers and stale version numbers depends
   on the number of firmware packages that are likely to be developed
   for the hardware module.

1.2.4.  Trust Anchors

   A trust anchor MUST consist of a public key signature algorithm and
   an associated public key, which MAY optionally include parameters.  A
   trust anchor MUST also include a public key identifier.  A trust
   anchor MAY also include an X.500 distinguished name.

Top      ToC       Page 13 
   The trust anchor public key is used in conjunction with the signature
   validation algorithm in two different ways.  First, the trust anchor
   public key is used directly to validate the firmware package
   signature.  Second, the trust anchor public key is used to validate
   an X.509 certification path, and then the subject public key in the
   final certificate in the certification path is used to validate the
   firmware package signature.

   The public key names the trust anchor, and each public key has a
   public key identifier.  The public key identifier identifies the
   trust anchor as the signer when it is used directly to validate
   firmware package signatures.  This key identifier can be stored with
   the trust anchor, or it can be computed from the public key whenever
   needed.

   The optional trusted X.500 distinguished name MUST be present in
   order for the trust anchor public key to be used to validate an X.509
   certification path.  Without an X.500 distinguished name,
   certification path construction cannot use the trust anchor.

1.2.5.  Cryptographic and Compression Algorithm Requirements

   A firmware package for a cryptographic hardware module includes
   cryptographic algorithm implementations.  In addition, a firmware
   package for a non-cryptographic hardware module will likely include
   cryptographic algorithm implementations to support the bootstrap
   loader in the validation of firmware packages.

   A unique algorithm object identifier MUST be assigned for each
   cryptographic algorithm and mode implemented by a firmware package.
   A unique algorithm object identifier MUST also be assigned for each
   compression algorithm implemented by a firmware package.  The
   algorithm object identifiers can be used to determine whether a
   particular firmware package satisfies the needs of a particular
   application.  To facilitate the development of algorithm-agile
   applications, the cryptographic module interface SHOULD allow
   applications to query the cryptographic module for the object
   identifiers associated with each cryptographic algorithm contained in
   the currently loaded firmware package.  Applications SHOULD also be
   able to query the cryptographic module to determine attributes
   associated with each algorithm.  Such attributes might include the
   algorithm type (symmetric encryption, asymmetric encryption, key
   agreement, one-way hash function, digital signature, and so on), the
   algorithm block size or modulus size, and parameters for asymmetric
   algorithms.  This specification does not establish the conventions
   for the retrieval of algorithm identifiers or algorithm attributes.

Top      ToC       Page 14 
1.3.  Hardware Module Security Architecture

   The bootstrap loader MAY be permanently stored in read-only memory or
   separately loaded into non-volatile memory as discussed above.

   In most hardware module designs, the firmware package execution
   environment offers a single address space.  If it does, the firmware
   package SHOULD contain a complete firmware package load for the
   hardware module.  In this situation, the firmware package does not
   contain a partial or incremental set of functions.  A complete
   firmware package load will minimize complexity and avoid potential
   security problems.  From a complexity perspective, the incremental
   loading of packages makes it necessary for each package to identify
   any other packages that are required (its dependencies), and the
   bootstrap loader needs to verify that all of the dependencies are
   satisfied before attempting to execute the firmware package.  When a
   hardware module is based on a general purpose processor or a digital
   signal processor, it is dangerous to allow arbitrary packages to be
   loaded simultaneously unless there is a reference monitor to ensure
   that independent portions of the code cannot interfere with one
   another.  Also, it is difficult to evaluate arbitrary combinations of
   software modules [SECREQMTS].  For these reasons, a complete firmware
   package load is RECOMMENDED; however, this specification allows the
   firmware signer to identify dependencies between firmware packages in
   order to handle all situations.

   The firmware packages MAY have dependencies on routines provided by
   other firmware packages.  To minimize the security evaluation
   complexity of a hardware module employing such a design, the firmware
   package MUST identify the package identifiers (and the minimum
   version numbers when the preferred firmware package name form is
   used) of the packages upon which it depends.  The bootstrap loader
   MUST reject a firmware package load if it contains a dependency on a
   firmware package that is not available.

   Loading a firmware package can impact the satisfactory resolution of
   dependencies of other firmware packages that are already part of the
   hardware module configuration.  For this reason, the bootstrap loader
   MUST reject the loading of a firmware package if the dependencies of
   any firmware package in the resulting configurations will be
   unsatisfied.

1.4.  ASN.1 Encoding

   The CMS uses Abstract Syntax Notation One (ASN.1) [X.208-88,
   X.209-88].  ASN.1 is a formal notation used for describing data
   protocols, regardless of the programming language used by the
   implementation.  Encoding rules describe how the values defined in

Top      ToC       Page 15 
   ASN.1 will be represented for transmission.  The Basic Encoding Rules
   (BER) are the most widely employed rule set, but they offer more than
   one way to represent data structures.  For example, definite length
   encoding and indefinite length encoding are supported.  This
   flexibility is not desirable when digital signatures are used.  As a
   result, the Distinguished Encoding Rules (DER) [X.509-88] were
   invented.  DER is a subset of BER that ensures a single way to
   represent a given value.  For example, DER always employs definite
   length encoding.

   In this specification, digitally signed structures MUST be encoded
   with DER.  Other structures do not require DER, but the use of
   definite length encoding is strongly RECOMMENDED.  By always using
   definite length encoding, the bootstrap loader will have fewer
   options to implement.  In situations where there is very high
   confidence that only definite length encoding will be used, support
   for indefinite length decoding MAY be omitted.

1.5.  Protected Firmware Package Loading

   This document does not attempt to specify a physical interface, any
   related driver software, or a protocol necessary for loading firmware
   packages.  Many different delivery mechanisms are envisioned,
   including portable memory devices, file transfer, and web pages.
   Section 2 of this specification defines the format that MUST be
   presented to the hardware module regardless of the interface that is
   used.  This specification also specifies the format of the response
   that MAY be generated by the hardware module.  Section 3 of this
   specification defines the format that MAY be returned by the hardware
   module when a firmware package loads successfully.  Section 4 of this
   specification defines the format that MAY be returned by the hardware
   module when a firmware package load is unsuccessful.  The firmware
   package load receipts and firmware package load error reports can be
   either signed or unsigned.



(page 15 continued on part 2)

Next RFC Part