idnits 2.17.1 draft-housley-cms-fw-wrap-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 2560. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2823. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2582. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 85 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 224: '...ror reports, a hardware module MUST be...' RFC 2119 keyword, line 233: '...t, the key words MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 234: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 240: '...bootstrap loader MUST have access to o...' RFC 2119 keyword, line 244: '...bootstrap loader MUST have access to a...' (255 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2005) is 7033 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'CMS' on line 2610 looks like a reference -- Missing reference section? 'OCSP' on line 192 looks like a reference -- Missing reference section? 'STDWORDS' on line 236 looks like a reference -- Missing reference section? 'AES' on line 440 looks like a reference -- Missing reference section? 'PROFILE' on line 2599 looks like a reference -- Missing reference section? 'SECREQMTS' on line 633 looks like a reference -- Missing reference section? 'COMPRESS' on line 2599 looks like a reference -- Missing reference section? 'UTF-8' on line 1406 looks like a reference -- Missing reference section? 'ESS' on line 1459 looks like a reference -- Missing reference section? 'SHA1' on line 1460 looks like a reference -- Missing reference section? '1' on line 2734 looks like a reference -- Missing reference section? 'RANDOM' on line 2460 looks like a reference -- Missing reference section? 'DDJ' on line 2468 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Housley 3 Internet Draft Vigil Security 4 expires in six months January 2005 6 Using CMS to Protect Firmware Packages 8 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than a "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 This document describes the use of the Cryptographic Message Syntax 36 (CMS) to protect firmware packages, which provide object code for one 37 or more hardware module components. CMS is specified in RFC 3852. A 38 digital signature is used to protect the firmware package from 39 undetected modification and provide data origin authentication. 40 Encryption is optionally used to protect the firmware package from 41 disclosure, and compression is optionally used to reduce the size of 42 the protected firmware package. A firmware package loading receipt 43 can optionally be generated to acknowledge the successful loading of 44 a firmware package. Similarly, a firmware package load error report 45 can optionally be generated to convey the failure to load a firmware 46 package. 48 Table of Contents 50 1 Introduction ............................................. 4 51 1.1 Terminology .............................................. 6 52 1.2 Architectural Elements ................................... 6 53 1.2.1 Hardware Module Requirements ............................. 7 54 1.2.2 Firmware Package Requirements ............................ 8 55 1.2.3 Bootstrap Loader Requirements ............................ 9 56 1.2.3.1 Legacy Stale Version Processing .......................... 11 57 1.2.3.2 Preferred Stale Version Processing ....................... 12 58 1.2.4 Trust Anchors ............................................ 12 59 1.2.5 Cryptographic and Compression Algorithm Requirements ..... 13 60 1.3 Hardware Module Security Architecture .................... 14 61 1.4 ASN.1 Encoding ........................................... 14 62 1.5 Protected Firmware Package Loading ....................... 15 64 2 Firmware Package Protection .............................. 15 65 2.1 Firmware Package Protection CMS Content Type Profile ..... 17 66 2.1.1 ContentInfo .............................................. 17 67 2.1.2 SignedData ............................................... 18 68 2.1.2.1 SignerInfo ............................................... 19 69 2.1.2.2 EncapsulatedContentInfo .................................. 19 70 2.1.3 EncryptedData ............................................ 20 71 2.1.3.1 EncryptedContentInfo ..................................... 20 72 2.1.4 CompressedData ........................................... 21 73 2.1.4.1 EncapsulatedContentInfo .................................. 21 74 2.1.5 FirmwarePkgData .......................................... 21 75 2.2 Signed Attributes ........................................ 22 76 2.2.1 Content Type ............................................. 23 77 2.2.2 Message Digest ........................................... 23 78 2.2.3 Firmware Package Identifier .............................. 23 79 2.2.4 Target Hardware Module Identifiers ....................... 25 80 2.2.5 Decrypt Key Identifier ................................... 25 81 2.2.6 Implemented Crypto Algorithms ............................ 26 82 2.2.7 Implemented Compression Algorithms ....................... 26 83 2.2.8 Community Identifiers .................................... 27 84 2.2.9 Firmware Package Information ............................. 28 85 2.2.10 Firmware Package Message Digest .......................... 30 86 2.2.11 Signing Time ............................................. 30 87 2.2.12 Content Hints ............................................ 30 88 2.2.13 Signing Certificate ...................................... 31 89 2.3 Unsigned Attributes ...................................... 32 90 2.3.1 Wrapped Firmware-Decryption Key .......................... 32 91 3 Firmware Package Load Receipt ............................ 34 92 3.1 Firmware Package Load Receipt CMS Content Type Profile ... 35 93 3.1.1 ContentInfo .............................................. 35 94 3.1.2 SignedData ............................................... 36 95 3.1.2.1 SignerInfo ............................................... 37 96 3.1.2.2 EncapsulatedContentInfo .................................. 38 97 3.1.3 FirmwarePackageLoadReceipt ............................... 38 98 3.2 Signed Attributes ........................................ 39 99 3.2.1 Content Type ............................................. 39 100 3.2.2 Message Digest ........................................... 40 101 3.2.3 Signing Time ............................................. 40 103 4 Firmware Package Load Error .............................. 40 104 4.1 Firmware Package Load Error CMS Content Type Profile ..... 42 105 4.1.1 ContentInfo .............................................. 42 106 4.1.2 SignedData ............................................... 42 107 4.1.2.1 SignerInfo ............................................... 43 108 4.1.2.2 EncapsulatedContentInfo .................................. 43 109 4.1.3 FirmwarePackageLoadError ................................. 43 110 4.2 Signed Attributes ........................................ 48 111 4.2.1 Content Type ............................................. 49 112 4.2.2 Message Digest ........................................... 49 113 4.2.3 Signing Time ............................................. 49 115 5 Hardware Module Name ..................................... 49 117 6 References ............................................... 50 118 6.1 Normative References ..................................... 50 119 6.2 Informative References ................................... 51 121 7 Security Considerations .................................. 52 122 7.1 Cryptographic Keys and Algorithms ........................ 52 123 7.2 Random Number Generation ................................. 53 124 7.3 Stale Firmware Package Version Number .................... 53 125 7.4 Community Identifiers .................................... 54 127 8 IANA Considerations ...................................... 55 129 9 IPR Considerations ....................................... 55 131 10 Author Address ........................................... 56 133 Appendix A: ASN.1 Module .......................................... 56 135 Full Copyright Statement ........................................... 61 137 1 Introduction 139 This document describes the use of the Cryptographic Message Syntax 140 (CMS) [CMS] to protect firmware packages. This document also 141 describes the use of CMS for receipts and error reports for firmware 142 package loading. The CMS is a data protection encapsulation syntax 143 that makes use of ASN.1 [X.208-88, X.209-88]. The protected firmware 144 package can be associated with any particular hardware module; 145 however, this specification was written with the requirements of 146 cryptographic hardware modules in mind, since such modules have 147 strong security requirements. 149 The firmware package contains object code for one or more 150 programmable components that make up the hardware module. The 151 firmware package, which is treated as an opaque binary object, is 152 digitally signed. Optional encryption and compression are also 153 supported. When all three are used, the firmware package is 154 compressed, then encrypted, and then signed. Compression simply 155 reduces the size of the firmware package, allowing more efficient 156 processing and transmission. Encryption protects the firmware 157 package from disclosure, which allows transmission of sensitive 158 firmware packages over insecure links. The encryption algorithm and 159 mode employed may also provide integrity, protecting the firmware 160 package from undetected modification. The encryption protects 161 proprietary algorithms, classified algorithms, trade secrets, and 162 implementation techniques. The digital signature protects the 163 firmware package from undetected modification and provides data 164 origin authentication. The digital signature allows the hardware 165 module to confirm that the firmware package comes from an acceptable 166 source. 168 If encryption is used, the firmware-decryption key must be made 169 available to the hardware module via a secure path. The key might be 170 delivered via physical media or delivered via an independent 171 electronic path. One optional mechanism for distributing the 172 firmware-decryption key is specified in section 2.3.1, but any secure 173 key distribution mechanism is acceptable. 175 The signature verification public key must be made available to the 176 hardware module in a manner that preserves its integrity and confirms 177 its source. CMS supports the transfer of certificates, and this 178 facility can be used to transfer a certificate that contains the 179 signature verification public key (a firmware-signing certificate). 180 However, use of this facility introduces a level of indirection. 181 Ultimately, a trust anchor public key must be made available to the 182 hardware module. Section 1.2 establishes a requirement that the 183 hardware module store one or more trust anchors. 185 Hardware modules may not be capable of accessing certificate 186 repositories or delegated path discovery (DPD) servers [DPD&DPV] to 187 acquire certificates needed to complete a certification path. Thus, 188 it is the responsibility of the firmware package signer to include 189 sufficient certificates to enable each module to validate the 190 firmware-signer certificate (see Section 2.1.2). Similarly, hardware 191 modules may not be capable of accessing a CRL repository, an OCSP 192 responder [OCSP], or delegated path validation (DPV) server [DPD&DPV] 193 to acquire revocation status information. Thus, if the firmware 194 package signature cannot be validated solely with the trust anchor 195 public key and the hardware module is not capable of performing full 196 certification path validation, then it is the responsibility of the 197 entity loading a package into a hardware module to validate the 198 firmware-signer certification path prior to loading the package into 199 a hardware module. The means by which this external certificate 200 revocation status checking is performed is beyond the scope of this 201 specification. 203 Hardware modules will only accept firmware packages with a valid 204 digital signature. The signature is either validated directly using 205 the trust anchor public key or using a firmware-signer certification 206 path that is validated to the trust anchor public key. Thus, the 207 trust anchors define the set of entities that can create firmware 208 packages for the hardware module. 210 The disposition of a previously loaded firmware package after the 211 successful validation of another firmware package is beyond the scope 212 of this specification. The amount of memory available to the 213 hardware module will determine the range of alternatives. 215 In some cases, hardware modules can generate receipts to acknowledge 216 the loading of a particular firmware package. Such receipts can be 217 used to determine which hardware modules need to receive an updated 218 firmware package whenever a flaw in an earlier firmware package is 219 discovered. Hardware modules can also generate error reports to 220 indicate the unsuccessful firmware package loading. To implement 221 either receipt or error report generation, the hardware module is 222 required to have a unique permanent serial number. Receipts and 223 error reports can be either signed or unsigned. To generate 224 digitally signed receipts or error reports, a hardware module MUST be 225 issued its own private signature key and a certificate that contains 226 the corresponding signature validation public key. In order to save 227 memory with the hardware module, the hardware module might store a 228 certificate designator instead of the certificate itself. The 229 private signature key requires secure storage. 231 1.1 Terminology 233 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 234 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as 235 described in [STDWORDS]. 237 1.2 Architectural Elements 239 The architecture includes the hardware module, the firmware package, 240 and a bootstrap loader. The bootstrap loader MUST have access to one 241 or more trusted public keys, called trust anchors, to validate the 242 signature on the firmware package. If a signed firmware package load 243 receipt or error report is created on behalf of the hardware module, 244 then the bootstrap loader MUST have access to a private signature key 245 to generate the signature and the signer identifier for the 246 corresponding signature validation certificate or its designator. A 247 signature validation certificate MAY be included to aid signature 248 validation. To implement this optional capability, the hardware 249 module MUST have a unique serial number and a private signature key; 250 the hardware module MAY also include a certificate that contains the 251 corresponding signature validation public key. These items MUST be 252 installed in the hardware module before it is deployed. The private 253 key and certificate can be generated and installed as part of the 254 hardware module manufacture process. Figure 1 illustrates these 255 architectural elements. 257 ASN.1 object identifiers are the preferred means of naming the 258 architectural elements. 260 Details of managing the trust anchors are beyond the scope of this 261 specification. However, one or more trust anchors MUST be installed 262 in the hardware module using a secure process before it is deployed. 263 These trust anchors provide a means of controlling the acceptable 264 sources of firmware packages. The hardware module vendor can include 265 provisions for secure, remote management of trust anchors. One 266 approach is to include trust anchors in the firmware packages 267 themselves. This approach is analogous to the optional capability 268 described later for updating the bootstrap loader. 270 In a cryptographic hardware module, the firmware package might 271 implement many different cryptographic algorithms. 273 When the firmware package is encrypted, the firmware-decryption key 274 and the firmware package MUST both be provided to the hardware 275 module. The firmware-decryption key is necessary to use the 276 associated firmware package. Generally, separate distribution 277 mechanisms will be employed for the firmware-decryption key and the 278 firmware package. An optional mechanism for securely distributing 279 the firmware-decryption key with the firmware package is specified in 280 section 2.3.1. 282 +------------------------------------------------------+ 283 | Hardware Module | 284 | | 285 | +---------------+ +--------------------------+ | 286 | | Bootstrap | | Firmware Package | | 287 | | Loader | | | | 288 | +---------------+ | +------------------+ | | 289 | | : Firmware Package : | | 290 | +---------------+ | : Identifier and : | | 291 | | Trust | | : Version Number : | | 292 | | Anchor(s) | | +------------------+ | | 293 | +---------------+ | | | 294 | | +-------------+ | | 295 | +---------------+ | : Algorithm 1 : | | 296 | | Serial Num. | | +-+-----------+-+ | | 297 | +---------------+ | : Algorithm 2 : | | 298 | | +-+-----------+-+ | | 299 | +---------------+ | : Algorithm n : | | 300 | | Hardware | | +-------------+ | | 301 | | Module Type | | | | 302 | +---------------+ +--------------------------+ | 303 | | 304 | +------------------------------------+ | 305 | | Optional Private Signature Key & | | 306 | | Signature Validation Certificate | | 307 | | or the Certificate Designator | | 308 | +------------------------------------+ | 309 | | 310 +------------------------------------------------------+ 312 Figure 1. Architectural Elements 314 1.2.1 Hardware Module Requirements 316 Many different vendors develop hardware modules, and each vendor 317 typically identifies its modules by product type (family) and 318 revision level. A unique object identifier MUST name each hardware 319 module type and revision. 321 Each hardware module within a hardware module family SHOULD have a 322 unique permanent serial number. However, if the optional receipt or 323 error report generation capability is implemented, then the hardware 324 module MUST have a unique permanent serial number. If the optional 325 receipt or error report signature capability is implemented, then the 326 hardware module MUST have a private signature key and a certificate 327 containing the corresponding public signature validation key or its 328 designator. If a serial number is present, the bootstrap loader uses 329 it for authorization decisions (see section 2.2.8), receipt 330 generation (see section 3), and error report generation (see section 331 4). 333 When the hardware module includes more than one firmware-programmable 334 component, the bootstrap loader distributes components of the package 335 to the appropriate components within the hardware module after the 336 firmware package is validated. The bootstrap loader is discussed 337 further in section 1.2.3. 339 1.2.2 Firmware Package Requirements 341 Two approaches to naming firmware packages are supported: legacy and 342 preferred. Firmware package names are placed in a CMS signed 343 attribute, not in the firmware package itself. 345 Legacy firmware package names are simply octet strings, and no 346 structure is assumed. This firmware package name form is supported 347 in order to facilitate existing configuration management systems. We 348 assume that the firmware signer and the Bootstrap Loader will 349 understand any internal structure to the octet string. In 350 particular, given two legacy firmware package names, we assume that 351 the firmware signer and the Bootstrap Loader will be able to 352 determine which one represents the newer version of the firmware 353 package. This capability is necessary to implement the stale version 354 feature. In case a firmware package with a disastrous flaw is 355 released, subsequent firmware package versions MAY designate a stale 356 legacy firmware package name to prevent subsequent rollback to the 357 stale version or versions earlier than the stale version. 359 Preferred firmware package names are a combination of the firmware 360 package object identifier and a version number. A unique object 361 identifier MUST identify the collection of features that characterize 362 the firmware package. For example, firmware packages for a cable 363 modem and a wireless LAN network interface card warrant distinct 364 object identifiers. Similarly, firmware packages that implement 365 distinct suites of cryptographic algorithms and modes of operation, 366 or which emulate different (non-programmable) cryptographic devices 367 warrant distinct object identifiers. The version number MUST 368 identify a particular build or release of the firmware package. The 369 version number MUST be a monotonically increasing non-negative 370 integer. Generally, an earlier version is replaced with a later one. 371 In case a firmware package with a disastrous flaw is released, 372 subsequent firmware package versions MAY designate a stale version 373 number to prevent subsequent rollback to the stale version or 374 versions earlier than the stale version. 376 Firmware packages are developed to run on one or more hardware module 377 type. The firmware package digital signature MUST bind the list of 378 supported hardware module object identifiers to the firmware package. 380 In many cases, the firmware package signature will be validated 381 directly with the trust anchor public key, avoiding the need to 382 construct certification paths. Alternatively, the trust anchor can 383 delegate firmware package signing to another public key through a 384 certification path. In the latter case, the firmware package SHOULD 385 contain the certificates needed to construct the certification path 386 that begins with a certificate issued by the trust anchors and ends 387 with a certificate issued to the firmware package signer. 389 The firmware package MAY contain a list of community identifiers. 390 These identifiers name the hardware modules that are authorized to 391 load the firmware package. If the firmware package contains a list 392 of community identifiers, then the bootstrap loader MUST reject the 393 firmware package if the hardware module is not a member of one of the 394 identified communities. 396 When a hardware module includes multiple programmable components, the 397 firmware package SHOULD contain executable code for all of the 398 components. Internal tagging within the firmware package MUST tell 399 the bootstrap loader which portion of the overall firmware package is 400 intended for each component; however, this tagging is expected to be 401 specific to each hardware module. Since this specification treats 402 the firmware package as an opaque binary object, the format of the 403 firmware package is beyond the scope of this specification. 405 1.2.3 Bootstrap Loader Requirements 407 The bootstrap loader MUST have access to a physical interface and any 408 related driver or protocol software necessary to obtain a firmware 409 package. The same interface SHOULD be used to deliver receipts and 410 error reports. Details of the physical interface as well as the 411 driver or protocol software are beyond the scope of this 412 specification. 414 The bootstrap loader can be a permanent part of the hardware module, 415 or it can be replaced by loading a firmware package. In Figure 1, 416 the bootstrap loader is implemented as separate logic within the 417 hardware module. Not all hardware modules will include the ability 418 to replace or update the bootstrap loader, and this specification 419 does not mandate such support. 421 If the bootstrap loader can be loaded by a firmware package, an 422 initial bootstrap loader MUST be installed in non-volatile memory 423 prior to deployment. All bootstrap loaders, including an initial 424 bootstrap loader if one is employed, MUST meet the requirements in 425 this section. However, the firmware package containing the bootstrap 426 loader MAY also contain other routines. 428 The bootstrap loader requires access to cryptographic routines. 429 These routines can be implemented specifically for the bootstrap 430 loader, or they can be shared with other hardware module features. 431 The bootstrap loader MUST have access to a one-way hash function and 432 digital signature verification routines to validate the digital 433 signature on the firmware package and to validate the certification 434 path for the firmware-signing certificate. 436 If firmware packages are encrypted, the bootstrap loader MUST have 437 access to a decryption routine. Access to a corresponding encryption 438 function is not required, since hardware modules need not be capable 439 of generating firmware packages. Since some symmetric encryption 440 algorithm implementations (such as AES [AES]), employ separate logic 441 for encryption and decryption, some hardware module savings might 442 result. 444 If firmware packages are compressed, the bootstrap loader MUST also 445 have access to a decompression function. The decompression function 446 can be implemented specifically for the bootstrap loader, or they can 447 be shared with other hardware module features. Access to a 448 corresponding compression function is not required, since hardware 449 modules need not be capable of generating firmware packages. 451 If the optional receipt generation or error report capability is 452 supported, the bootstrap loader MUST have access to the hardware 453 module serial number and the object identifier for the hardware 454 module type. If the optional signed receipt generation or signed 455 error report capability is supported, the bootstrap loader MUST also 456 have access to a one-way hash function and digital signature 457 routines, the hardware module private signing key and the 458 corresponding signature validation certificate or its designator. 460 The bootstrap loader requires access to one or more trusted public 461 keys, called trust anchors, to validate the firmware package digital 462 signature. One or more trust anchors MUST be installed in non- 463 volatile memory prior to deployment. The bootstrap loader MUST 464 reject a firmware package if it cannot validate the signature, which 465 MAY require the construction of a valid certification path from the 466 firmware-signing certificate to one of the trust anchors [PROFILE]. 467 However, in many cases, the firmware package signature will be 468 validated directly with the trust anchor public key, avoiding the 469 need to construct certification paths. 471 The bootstrap loader MUST reject a firmware package if the list of 472 supported hardware module type identifiers within the firmware 473 package does not include the object identifier of the hardware 474 module. 476 The bootstrap loader MUST reject a firmware package if the firmware 477 package includes a list of community identifiers and the hardware 478 module is not a member of one of the listed communities. The means 479 of determining community membership is beyond the scope of this 480 specification. 482 The bootstrap loader MUST reject a firmware package if it cannot 483 successfully decrypt the firmware package using the firmware- 484 decryption key available to the hardware module. The firmware 485 package contains an identifier of the firmware-decryption key needed 486 for decryption. 488 When an earlier version of a firmware package is replacing a later 489 one, the bootstrap loader SHOULD generate a warning. The manner in 490 which a warning is generated is highly dependent on the hardware 491 module and the environment in which it is being used. In case a 492 firmware package with a disastrous flaw is released and subsequent 493 firmware package versions designate a stale version, the bootstrap 494 loader SHOULD prevent loading of the stale version and versions 495 earlier than the stale version. 497 1.2.3.1 Legacy Stale Version Processing 499 In case a firmware package with a disastrous flaw is released, 500 subsequent firmware package versions that employ the legacy firmware 501 package name form MAY include a stale legacy firmware package name to 502 prevent subsequent rollback to the stale version or versions earlier 503 than the stale version. As described in the Security Considerations 504 section of this document, the inclusion of a stale legacy firmware 505 package name in a firmware package cannot completely prevent 506 subsequent use of the stale firmware package. However, many hardware 507 modules are expected to have very few firmware packages written for 508 them, allowing the stale firmware package version feature to provide 509 important protections. 511 Non-volatile storage for stale version numbers is needed. The number 512 of stale legacy firmware package names that can be stored depends on 513 the amount of storage that is available. When a firmware package is 514 loaded and it contains a stale legacy firmware package name, then it 515 SHOULD be added to a list that is kept in non-volatile storage. When 516 subsequent firmware packages are loaded, the legacy firmware package 517 name of the new package is compared to the list in non-volatile 518 storage. If the legacy firmware package name represents the same 519 version or an older version of a member of the list, then the new 520 firmware packages SHOULD be rejected. 522 The amount of non-volatile storage that needs to be dedicated to 523 saving legacy firmware package names and stale legacy firmware 524 packages names depends on the number of firmware packages that are 525 likely to be developed for the hardware module. 527 1.2.3.2 Preferred Stale Version Processing 529 In case a firmware package with a disastrous flaw is released, 530 subsequent firmware package versions that employ preferred firmware 531 package name form MAY include a stale version number to prevent 532 subsequent rollback to the stale version or versions earlier than the 533 stale version. As described in the Security Considerations section 534 of this document, the inclusion of a stale version number in a 535 firmware package cannot completely prevent subsequent use of the 536 stale firmware package. However, many hardware modules are expected 537 to have very few firmware packages written for them, allowing the 538 stale firmware package version feature to provide important 539 protections. 541 Non-volatile storage for stale version numbers is needed. The number 542 of stale version numbers that can be stored depends on the amount of 543 storage that is available. When a firmware package is loaded and it 544 contains a stale version number, then the object identifier of the 545 firmware package and the stale version number SHOULD be added to a 546 list that is kept in non-volatile storage. When subsequent firmware 547 packages are loaded, the object identifier and version number of the 548 new package are compared to the list in non-volatile storage. If the 549 object identifier matches and the version number is less than or 550 equal to the stale version number, then the new firmware packages 551 SHOULD be rejected. 553 The amount of non-volatile storage that needs to be dedicated to 554 saving firmware package identifiers and stale version numbers depends 555 on the number of firmware packages that are likely to be developed 556 for the hardware module. 558 1.2.4 Trust Anchors 560 A trust anchor MUST consist of a public key signature algorithm and 561 associated public key, which MAY optionally include parameters. A 562 trust anchor MUST also include a public key identifier. A trust 563 anchor MAY also include an X.500 distinguished name. 565 The trust anchor public key is used in conjunction with the signature 566 validation algorithm in two different ways. First, the trust anchor 567 public key is used directly to validate the firmware package 568 signature. Second, the trust anchor public key is used to validate 569 an X.509 certification path, and then the subject public key in the 570 final certificate in the certification path is used to validate the 571 firmware package signature. 573 The public key names the trust anchor, and each public key has a 574 public key identifier. The public key identifier identifies the 575 trust anchor as the signer when it is used directly to validate 576 firmware package signatures. This key identifier can be stored with 577 the trust anchor, or it can be computed from the public key whenever 578 needed. 580 The optional trusted X.500 distinguished name MUST be present in 581 order for the trust anchor public key to be used to validate an X.509 582 certification path. Without an X.500 distinguished name, 583 certification path construction cannot make use of the trust anchor. 585 1.2.5 Cryptographic and Compression Algorithm Requirements 587 A firmware package for a cryptographic hardware module includes 588 cryptographic algorithm implementations. In addition, a firmware 589 package for a non-cryptographic hardware module will likely include 590 cryptographic algorithm implementations to support the Bootstrap 591 Loader in the validation of firmware packages. 593 A unique algorithm object identifier MUST be assigned for each 594 cryptographic algorithm and mode implemented by a firmware package. 595 A unique algorithm object identifier MUST also be assigned for each 596 compression algorithm implemented by a firmware package. The 597 algorithm object identifiers can be used to determine whether a 598 particular firmware package satisfies the needs of a particular 599 application. To facilitate the development of algorithm agile 600 applications, the cryptographic module interface SHOULD allow 601 applications to query the cryptographic module for the object 602 identifiers associated with each cryptographic algorithm contained in 603 the currently loaded firmware package. Applications SHOULD also be 604 able to query the cryptographic module to determine attributes 605 associated with each algorithm. Such attributes might include the 606 algorithm type (symmetric encryption, asymmetric encryption, key 607 agreement, one-way hash function, digital signature, and so on), the 608 algorithm block size or modulus size, and parameters for asymmetric 609 algorithms. This specification does not establish the conventions 610 for the retrieval of algorithm identifiers or algorithm attributes. 612 1.3 Hardware Module Security Architecture 614 The bootstrap loader MAY be permanently stored in read-only memory or 615 separately loaded into non-volatile memory as discussed above. 617 In most hardware module designs, the firmware package execution 618 environment offers a single address space. When a single address 619 space is offered, the firmware package SHOULD contain a complete 620 firmware package load for the hardware module. In this situation, 621 the firmware package does not contain a partial or incremental set of 622 functions. A complete firmware package load will minimize complexity 623 and avoid potential security problems. From a complexity 624 perspective, the incremental loading of packages makes it necessary 625 for each package to identify any other packages that are required 626 (its dependencies), and the bootstrap loader needs to verify that all 627 of the dependencies are satisfied before attempting to execute the 628 firmware package. When a hardware module is based on a general 629 purpose processor or a digital signal processor, it is dangerous to 630 allow arbitrary packages to be loaded simultaneously unless there is 631 a reference monitor to ensure that independent portions of the code 632 cannot interfere with one another. Also, it is difficult to evaluate 633 arbitrary combinations of software modules [SECREQMTS]. For these 634 reasons, a complete firmware package load is RECOMMENDED; however, 635 this specification allows the firmware signer to identify 636 dependencies between firmware packages in order to handle all 637 situations. 639 The firmware packages MAY have dependencies on routines provided by 640 other firmware packages. To minimize the security evaluation 641 complexity of a hardware module employing such a design, the firmware 642 package MUST identify the package identifiers (and the minimum 643 version numbers when the preferred firmware package name form is 644 used) of the packages upon which it depends. The bootstrap loader 645 MUST reject a firmware package load if it contains a dependency on a 646 firmware package that is not available. 648 Loading a firmware package can impact the satisfactory resolution of 649 dependencies of other firmware packages that are already part of the 650 hardware module configuration. For this reason, the bootstrap loader 651 MUST reject the loading of a firmware package if the dependencies of 652 any firmware package in the resulting configurations will be 653 unsatisfied. 655 1.4 ASN.1 Encoding 657 The CMS makes use of Abstract Syntax Notation One (ASN.1) [X.208-88, 658 X.209-88]. ASN.1 is a formal notation used for describing data 659 protocols, regardless of the programming language used by the 660 implementation. Encoding rules describe how the values defined in 661 ASN.1 will be represented for transmission. The Basic Encoding Rules 662 (BER) are the most widely employed rule set, but they offer more than 663 one way to represent data structures. For example, definite length 664 encoding and indefinite length encoding are supported. This 665 flexibility is not desirable when digital signatures are used. As a 666 result, the Distinguished Encoding Rules (DER) [X.509-88] were 667 invented. DER is a subset of BER which ensures a single way to 668 represent a given value. For example, DER always employs definite 669 length encoding. 671 In this specification, digitally signed structures MUST be encoded 672 with DER. Other structures do not require DER, but the use of 673 definite length encoding is strongly RECOMMENDED. By always using 674 definite length encoding, the bootstrap loader will have fewer 675 options to implement. In situations where there is very high 676 confidence that only definite length encoding will be used, support 677 for indefinite length decoding MAY be omitted. 679 1.5 Protected Firmware Package Loading 681 This document does not attempt to specify a physical interface, any 682 related driver software, or a protocol necessary for loading firmware 683 packages. Many different delivery mechanisms are envisioned, 684 including portable memory devices, file transfer, and web pages. 685 Section 2 of this specification defines the format that MUST be 686 presented to the hardware module regardless of the interface that is 687 used. This specification also specifies the format of the response 688 that MAY be generated by the hardware module. Section 3 of this 689 specification defines the format that MAY be returned by the hardware 690 module when a firmware package loads successfully. Section 4 of this 691 specification defines the format that MAY be returned by the hardware 692 module when a firmware package load is unsuccessful. The firmware 693 package load receipts and firmware package load error reports can be 694 either signed or unsigned. 696 2 Firmware Package Protection 698 The Cryptographic Message Syntax (CMS) is used to protect a firmware 699 package, which is treated as an opaque binary object. A digital 700 signature is used to protect the firmware package from undetected 701 modification and provide data origin authentication. Encryption is 702 optionally used to protect the firmware package from disclosure, and 703 compression is optionally used to reduce the size of the protected 704 firmware package. The CMS ContentInfo content type MUST always be 705 present, and it MUST encapsulate the CMS SignedData content type. If 706 the firmware package is encrypted, then the CMS SignedData content 707 type MUST encapsulate the CMS EncryptedData content type. If the 708 firmware package is compressed, then either the CMS SignedData 709 content type (when encryption is not used) or the CMS EncryptedData 710 content type (when encryption is used) MUST encapsulate the CMS 711 CompressedData content type. Finally, either the CMS SignedData 712 content type (when neither encryption nor compression is used) or the 713 CMS EncryptedData content type (when encryption is used, but 714 compression is not used) or CMS CompressedData content type (when 715 compression is used) MUST encapsulate the simple firmware package 716 using the FirmwarePkgData content type defined in this specification 717 (see section 2.1.5). 719 The firmware package protection is summarized by (see [CMS] for the 720 full syntax): 722 ContentInfo { 723 contentType id-signedData, -- (1.2.840.113549.1.7.2) 724 content SignedData 725 } 727 SignedData { 728 version CMSVersion, -- always set to 3 729 digestAlgorithms DigestAlgorithmIdentifiers, -- Only one 730 encapContentInfo EncapsulatedContentInfo, 731 certificates CertificateSet, -- Signer cert. path 732 crls CertificateRevocationLists, -- Optional 733 signerInfos SET OF SignerInfo -- Only one 734 } 736 SignerInfo { 737 version CMSVersion, -- always set to 3 738 sid SignerIdentifier, 739 digestAlgorithm DigestAlgorithmIdentifier, 740 signedAttrs SignedAttributes, -- Required 741 signatureAlgorithm SignatureAlgorithmIdentifier, 742 signature SignatureValue, 743 unsignedAttrs UnsignedAttributes -- Optional 744 } 745 EncapsulatedContentInfo { 746 eContentType id-encryptedData, -- (1.2.840.113549.1.7.6) 747 -- OR -- 748 id-ct-compressedData, 749 -- (1.2.840.113549.1.9.16.1.9) 750 -- OR -- 751 id-ct-firmwarePackage, 752 -- (1.2.840.113549.1.9.16.1.16) 753 eContent OCTET STRING 754 } -- Contains EncryptedData OR 755 -- CompressedData OR 756 -- FirmwarePkgData 758 EncryptedData { 759 version CMSVersion, -- Always set to 0 760 encryptedContentInfo EncryptedContentInfo, 761 unprotectedAttrs UnprotectedAttributes -- Omit 762 } 764 EncryptedContentInfo { 765 contentType id-ct-compressedData, 766 -- (1.2.840.113549.1.9.16.1.9) 767 -- OR -- 768 id-ct-firmwarePackage, 769 -- (1.2.840.113549.1.9.16.1.16) 770 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 771 encryptedContent OCTET STRING 772 } -- Contains CompressedData OR 773 -- FirmwarePkgData 775 CompressedData { 776 version CMSVersion, -- Always set to 0 777 compressionAlgorithm CompressionAlgorithmIdentifier, 778 encapContentInfo EncapsulatedContentInfo 779 } 781 EncapsulatedContentInfo { 782 eContentType id-ct-firmwarePackage, 783 -- (1.2.840.113549.1.9.16.1.16) 784 eContent OCTET STRING -- Contains FirmwarePkgData 785 } 787 FirmwarePkgData OCTET STRING -- Contains firmware package 789 2.1 Firmware Package Protection CMS Content Type Profile 791 This section specifies the conventions for using the CMS ContentInfo, 792 SignedData, EncryptedData, and CompressedData content types. It also 793 defines the FirmwarePkgData content type. 795 2.1.1 ContentInfo 797 The CMS requires the outer most encapsulation to be ContentInfo 798 [CMS]. The fields of ContentInfo are used as follows: 800 contentType indicates the type of the associated content, and in this 801 case, the encapsulated type is always SignedData. The id- 802 signedData (1.2.840.113549.1.7.2) object identifier MUST be 803 present in this field. 805 content holds the associated content, and in this case, the content 806 field MUST contain SignedData. 808 2.1.2 SignedData 810 The SignedData content type [CMS] contains the signed firmware 811 package (which might be compressed, encrypted, or compressed and then 812 encrypted prior to signature), the certificates needed to validate 813 the signature, and one digital signature value. The fields of 814 SignedData are used as follows: 816 version is the syntax version number, and in this case, it MUST be 817 set to 3. 819 digestAlgorithms is a collection of message digest algorithm 820 identifiers, and in this case, it MUST contain a single message 821 digest algorithm identifier. The message digest algorithm 822 employed by the firmware package signer MUST be present. 824 encapContentInfo contains the signed content, consisting of a content 825 type identifier and the content itself. The use of the 826 EncapsulatedContentInfo type is discussed further in section 827 2.1.2.2. 829 certificates is an optional collection of certificates. If the trust 830 anchor directly signed the firmware package, then certificates 831 SHOULD be omitted. If the trust anchor did not directly sign the 832 firmware package, then certificates SHOULD include the X.509 833 certificate of the firmware package signer. The set of 834 certificates SHOULD be sufficient for the bootstrap loader to 835 construct a certification path from the trust anchor to the 836 firmware-signer's certificate. PKCS#6 extended certificates 838 [PKCS#6] and attribute certificates (either version 1 or version 839 2) [X.509-97, X.509-00, ACPROFILE] MUST NOT be included in the set 840 of certificates. 842 crls is an optional collection of certificate revocation lists 843 (CRLs), and in this case, CRLs SHOULD NOT be included by the 844 firmware package signer. It is anticipated that firmware packages 845 may be generated, signed, and made available in repositories for 846 downloading into hardware modules. In such contexts, it would be 847 difficult for the firmware package signer to include timely CRLs 848 in the firmware package. However, since the CRLs are not covered 849 by the signature, timely CRLs MAY be inserted by some other party 850 before the firmware package is delivered to the hardware module. 852 signerInfos is a collection of per-signer information, and in this 853 case, the collection MUST contain exactly one SignerInfo. The use 854 of the SignerInfo type is discussed further in section 2.1.2.1. 856 2.1.2.1 SignerInfo 858 The firmware package signer is represented in the SignerInfo type. 859 The fields of SignerInfo are used as follows: 861 version is the syntax version number, and it MUST be 3. 863 sid identifies the signer's public key. CMS supports two 864 alternatives: issuerAndSerialNumber and subjectKeyIdentifier. 865 However, the bootstrap loader MUST support the 866 subjectKeyIdentifier alternative. The subjectKeyIdentifier 867 alternative identifies the signer's public key directly. When 868 this public key is contained in a certificate, this identifier 869 SHOULD appear in the X.509 subjectKeyIdentifier extension. 871 digestAlgorithm identifies the message digest algorithm, and any 872 associated parameters, used by the firmware package signer. It 873 MUST contain the message digest algorithms employed by the 874 firmware package signer. (Note that this message digest algorithm 875 identifier MUST be the same as the one carried in the 876 digestAlgorithms value in SignedData.) 878 signedAttrs is an optional collection of attributes that are signed 879 along with the content. The signedAttrs are optional in the CMS, 880 but in this specification, signedAttrs are REQUIRED for the 881 firmware package; however, implementations MUST ignore 882 unrecognized signed attributes. The SET OF attributes MUST be DER 883 encoded [X.509-88]. Section 2.2 of this document lists the 884 attributes that MUST be included in the collection; other 885 attributes MAY be included as well. 887 signatureAlgorithm identifies the signature algorithm, and any 888 associated parameters, used by the firmware package signer to 889 generate the digital signature. 891 signature is the digital signature value. 893 unsignedAttrs is an optional SET of attributes that are not signed. 894 As described in section 2.3, this set can only contain a single 895 instance of the wrapped-firmware-decryption-key attribute and no 896 others. 898 2.1.2.2 EncapsulatedContentInfo 900 The EncapsulatedContentInfo content type encapsulates the firmware 901 package, which might be compressed, encrypted, or compressed and then 902 encrypted prior to signature. The firmware package, in any of these 903 formats, is carried within the EncapsulatedContentInfo type. The 904 fields of EncapsulatedContentInfo are used as follows: 906 eContentType is an object identifier that uniquely specifies the 907 content type, and in this case, the value MUST be either id- 908 encryptedData (1.2.840.113549.1.7.6), id-ct-compressedData 909 (1.2.840.113549.1.9.16.1.9), or id-ct-firmwarePackage 910 (1.2.840.113549.1.9.16.1.16). When it contains id-encryptedData, 911 then the firmware packages was encrypted prior to signing, and the 912 firmware package may also have been compressed prior to 913 encryption. When it contains id-ct-compressedData, then the 914 firmware package was compressed prior to signing, but the firmware 915 package was not encrypted. When it contains id-ct- 916 firmwarePackage, then the firmware package was not compressed or 917 encrypted prior to signing. 919 eContent contains the signed firmware package, which might also be 920 encrypted, compressed, or compressed and then encrypted, prior to 921 signing. The content is encoded as an octet string. The eContent 922 octet string need not be DER encoded. 924 2.1.3 EncryptedData 926 The EncryptedData content type [CMS] contains the encrypted firmware 927 package (which might be compressed prior to encryption). However, if 928 the firmware package was not encrypted, the EncryptedData content 929 type is not present. The fields of EncryptedData are used as 930 follows: 932 version is the syntax version number, and in this case, version MUST 933 be 0. 935 encryptedContentInfo is the encrypted content information. The use 936 of the EncryptedContentInfo type is discussed further in section 937 2.1.3.1. 939 unprotectedAttrs is an optional collection of unencrypted attributes, 940 and in this case, unprotectedAttrs MUST NOT be present. 942 2.1.3.1 EncryptedContentInfo 944 The encrypted firmware package, which might be compressed prior to 945 encryption, is encapsulated in the EncryptedContentInfo type. The 946 fields of EncryptedContentInfo are used as follows: 948 contentType indicates the type of content, and in this case, it MUST 949 contain either id-ct-compressedData (1.2.840.113549.1.9.16.1.9) or 950 id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16). When it 951 contains id-ct-compressedData, then the firmware package was 952 compressed prior to encryption. When it contains id-ct- 953 firmwarePackage, then the firmware package was not compressed 954 prior to encryption. 956 contentEncryptionAlgorithm identifies the firmware-encryption 957 algorithm, and any associated parameters, used to encrypt the 958 firmware package. 960 encryptedContent is the result of encrypting the firmware package. 961 The field is optional; however, in this case, it MUST be present. 963 2.1.4 CompressedData 965 The CompressedData content type [COMPRESS] contains the compressed 966 firmware package. If the firmware package was not compressed, then 967 the CompressedData content type is not present. The fields of 968 CompressedData are used as follows: 970 version is the syntax version number; in this case, it MUST be 0. 972 compressionAlgorithm identifies the compression algorithm, and any 973 associated parameters, used to compress the firmware package. 975 encapContentInfo is the compressed content, consisting of a content 976 type identifier and the content itself. The use of the 977 EncapsulatedContentInfo type is discussed further in section 978 2.1.4.1. 980 2.1.4.1 EncapsulatedContentInfo 982 The CompressedData content type encapsulates the compressed firmware 983 package, and it is carried within the EncapsulatedContentInfo type. 984 The fields of EncapsulatedContentInfo are used as follows: 986 eContentType is an object identifier that uniquely specifies the 987 content type, and in this case, it MUST be the value of id-ct- 988 firmwarePackage (1.2.840.113549.1.9.16.1.16). 990 eContent is the compressed firmware package, encoded as an octet 991 string. The eContent octet string need not be DER encoded. 993 2.1.5 FirmwarePkgData 995 The FirmwarePkgData content type contains the firmware package. It 996 is a straightforward encapsulation in an octet string, and it need 997 not be DER encoded. 999 The FirmwarePkgData content type is identified by the id-ct- 1000 firmwarePackage object identifier: 1002 id-ct-firmwarePackage OBJECT IDENTIFIER ::= { 1003 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1004 smime(16) ct(1) 16 } 1006 The FirmwarePkgData content type is a simple octet string: 1008 FirmwarePkgData ::= OCTET STRING 1010 2.2 Signed Attributes 1012 The firmware package signer MUST digitally sign a collection of 1013 attributes along with the firmware package. Each attribute in the 1014 collection MUST be DER encoded [X.509-88]. The syntax for attributes 1015 is defined in [CMS], but it is repeated here for convenience: 1017 Attribute ::= SEQUENCE { 1018 attrType OBJECT IDENTIFIER, 1019 attrValues SET OF AttributeValue } 1021 AttributeValue ::= ANY 1023 Each of the attributes used with this profile has a single attribute 1024 value, even though the syntax is defined as a SET OF AttributeValue. 1025 There MUST be exactly one instance of AttributeValue present. 1027 The SignedAttributes syntax within signerInfo is defined as a SET OF 1028 Attributes. The SignedAttributes MUST include only one instance of 1029 any particular attribute. 1031 The firmware package signer MUST include the following four 1032 attributes: content-type, message-digest, firmware-package- 1033 identifier, and target-hardware-module-identifiers. 1035 If the firmware package is encrypted, then the firmware package 1036 signer MUST also include the decrypt-key-identifier attribute. 1038 If the firmware package implements cryptographic algorithms, then the 1039 firmware package signer MAY also include the implemented-crypto- 1040 algorithms attribute. Similarly, if the firmware package implements 1041 compression algorithms, then the firmware package signer MAY also 1042 include the implemented-compress-algorithms attribute. 1044 If the firmware package is intended for use only by specific 1045 communities, then the firmware package signer MUST also include the 1046 community-identifiers attribute. 1048 If the firmware package depends on the presence of one or more other 1049 firmware packages to operate properly, then the firmware package 1050 signer SHOULD also include the firmware-package-info attribute. For 1051 example, the firmware-package-info attribute dependencies field might 1052 indicate that the firmware package contains a dependency on a 1053 particular bootstrap loader or separation kernel. 1055 The firmware package signer SHOULD also include the three following 1056 attributes: firmware-package-message-digest, signing-time, and 1057 content-hints. Additionally, if the firmware package signer has a 1058 certificate (meaning that the firmware package signer is not always 1059 configured as a trust anchor), then the firmware package signer 1060 SHOULD also include the signing-certificate attribute. 1062 The firmware package signer MAY include any other attribute that it 1063 deems appropriate. 1065 2.2.1 Content Type 1067 The firmware package signer MUST include a content-type attribute 1068 with the value of id-encryptedData (1.2.840.113549.1.7.6), id-ct- 1069 compressedData (1.2.840.113549.1.9.16.1.9), or id-ct-firmwarePackage 1070 (1.2.840.113549.1.9.16.1.16). When it contains id-encryptedData, 1071 then the firmware packages was encrypted prior to signing. When it 1072 contains id-ct-compressedData, then the firmware package was 1073 compressed prior to signing, but the firmware package was not 1074 encrypted. When it contains id-ct-firmwarePackage, then the firmware 1075 package was not compressed or encrypted prior to signing. Section 1076 11.1 of [CMS] defines the content-type attribute. 1078 2.2.2 Message Digest 1080 The firmware package signer MUST include a message-digest attribute, 1081 having as its value the message digest computed on the 1082 encapContentInfo eContent octet string, as defined in section 1083 2.1.2.2. This octet string contains the firmware package, and it MAY 1084 be compressed, encrypted, or both compressed and encrypted. Section 1085 11.2 of [CMS] defines the message-digest attribute. 1087 2.2.3 Firmware Package Identifier 1089 The firmware-package-identifier attribute names the protected 1090 firmware package. Two approaches to naming firmware packages are 1091 supported: legacy and preferred. The firmware package signer MUST 1092 include a firmware-package-identifier attribute using one of these 1093 name forms. 1095 A legacy firmware package name is an octet string, and no structure 1096 within the octet string is assumed. 1098 A preferred firmware package name is a combination of an object 1099 identifier and a version number. The object identifier names a 1100 collection of functions implemented by the firmware package, and the 1101 version number is a non-negative integer that identifies a particular 1102 build or release of the firmware package. 1104 In case a firmware package with a disastrous flaw is released, the 1105 firmware package that repairs the previously distributed flaw MAY 1106 designate a stale firmware package version to prevent the reloading 1107 of the flawed version. The hardware module bootstrap loader SHOULD 1108 prevent subsequent rollback to the stale version or versions earlier 1109 than the stale version. When the legacy firmware package name form 1110 is used, the stale version is indicated by a stale legacy firmware 1111 package name, which is an octet string. We assume that the firmware 1112 package signer and the bootstrap loader can determine whether a given 1113 legacy firmware package name represents a version that is more recent 1114 than the stale one. When the preferred firmware package name form is 1115 used, the stale version is indicated by a stale version number, which 1116 is an integer. 1118 The following object identifier identifies the firmware-package- 1119 identifier attribute: 1121 id-aa-firmwarePackageID OBJECT IDENTIFIER ::= { 1122 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1123 smime(16) aa(2) 35 } 1125 The firmware-package-identifier attribute values have ASN.1 type 1126 FirmwarePackageIdentifier: 1128 FirmwarePackageIdentifier ::= SEQUENCE { 1129 name PreferredOrLegacyPackageIdentifier, 1130 stale PreferredOrLegacyStalePackageIdentifier OPTIONAL } 1132 PreferredOrLegacyPackageIdentifier ::= CHOICE { 1133 preferred PreferredPackageIdentifier, 1134 legacy OCTET STRING } 1136 PreferredPackageIdentifier ::= SEQUENCE { 1137 fwPkgID OBJECT IDENTIFIER, 1138 verNum INTEGER (0..MAX) } 1140 PreferredOrLegacyStalePackageIdentifier ::= CHOICE { 1141 preferredStaleVerNum INTEGER (0..MAX), 1142 legacyStaleVersion OCTET STRING } 1144 2.2.4 Target Hardware Module Identifiers 1146 The target-hardware-module-identifiers attribute names the types of 1147 hardware modules that the firmware package supports. A unique object 1148 identifier names each supported hardware model type and revision. 1150 The bootstrap loader MUST reject the firmware package if its own 1151 hardware module type identifier is not listed in the target-hardware- 1152 module-identifiers attribute. 1154 The following object identifier identifies the target-hardware- 1155 module-identifiers attribute: 1157 id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= { 1158 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1159 smime(16) aa(2) 36 } 1161 The target-hardware-module-identifiers attribute values have ASN.1 1162 type TargetHardwareIdentifiers: 1164 TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER 1166 2.2.5 Decrypt Key Identifier 1168 The decrypt-key-identifier attribute names the symmetric key needed 1169 to decrypt the encapsulated firmware package. The CMS EncryptedData 1170 content type is used when the firmware package is encrypted. The 1171 decrypt-key-identifier signed attribute is carried in the SignedData 1172 content type that encapsulates EncryptedData content type, naming the 1173 symmetric key needed to decrypt the firmware package. No particular 1174 structure is imposed on the key identifier. The means by which the 1175 firmware-decryption key is securely distributed to all modules that 1176 are authorized to use the associated firmware package is beyond the 1177 scope of this specification; however, an optional mechanism for 1178 securely distributing the firmware-decryption key with the firmware 1179 package is specified in section 2.3.1. 1181 The following object identifier identifies the decrypt-key-identifier 1182 attribute: 1184 id-aa-decryptKeyID OBJECT IDENTIFIER ::= { 1185 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1186 smime(16) aa(2) 37 } 1188 The decrypt-key-identifier attribute values have ASN.1 type 1189 DecryptKeyIdentifier: 1191 DecryptKeyIdentifier ::= OCTET STRING 1193 2.2.6 Implemented Crypto Algorithms 1195 The implemented-crypto-algorithms attribute MAY be present in the 1196 SignedAttributes, and it names the cryptographic algorithms that are 1197 implemented by the firmware package and available to applications. 1198 Only those algorithms that are made available at the interface of the 1199 cryptographic module are listed. Any cryptographic algorithm that is 1200 used internally and not accessible via the cryptographic module 1201 interface MUST NOT be listed. For example, if the firmware package 1202 implements the decryption algorithm for future firmware package 1203 installations and this algorithm is not made available for other 1204 uses, then the firmware-decryption algorithm would not be listed. 1206 The object identifier portion of AlgorithmIdentifier identifies an 1207 algorithm and its mode of use. No algorithm parameters are included. 1208 Cryptographic algorithms include traffic-encryption algorithms, key- 1209 encryption algorithms, key transport algorithms, key agreement 1210 algorithms, one-way hash algorithms, and digital signature 1211 algorithms. Cryptographic algorithms do not include compression 1212 algorithms. 1214 The following object identifier identifies the implemented-crypto- 1215 algorithms attribute: 1217 id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= { 1218 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1219 smime(16) aa(2) 38 } 1221 The implemented-crypto-algorithms attribute values have ASN.1 type 1222 ImplementedCryptoAlgorithms: 1224 ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER 1226 2.2.7 Implemented Compression Algorithms 1228 The implemented-compress-algorithms attribute MAY be present in the 1229 SignedAttributes, and it names the compression algorithms that are 1230 implemented by the firmware package and available to applications. 1231 Only those algorithms that are made available at the interface of the 1232 hardware module are listed. Any compression algorithm that is used 1233 internally and not accessible via the hardware module interface MUST 1234 NOT be listed. For example, if the firmware package implements a 1235 decompression algorithm for future firmware package installations and 1236 this algorithm is not made available for other uses, then the 1237 firmware-decompression algorithm would not be listed. 1239 The object identifier portion of AlgorithmIdentifier identifies a 1240 compression algorithm. No algorithm parameters are included. 1242 The following object identifier identifies the implemented-compress- 1243 algorithms attribute: 1245 id-aa-implCompressAlgs OBJECT IDENTIFIER ::= { 1246 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1247 smime(16) aa(2) 43 } 1249 The implemented-compress-algorithms attribute values have ASN.1 type 1250 ImplementedCompressAlgorithms: 1252 ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER 1254 2.2.8 Community Identifiers 1256 If present in the SignedAttributes, the community-identifiers 1257 attribute names the communities that are permitted to execute the 1258 firmware package. The bootstrap loader MUST reject the firmware 1259 package if the hardware module is not a member of one of the 1260 identified communities. The means of assigning community membership 1261 is beyond the scope of this specification. 1263 The community-identifiers attributes names the authorized communities 1264 by a list of community object identifiers, by a list of specific 1265 hardware modules, or by a combination of the two lists. A specific 1266 hardware module is specified by the combination of the hardware 1267 module identifier (as defined in section 2.2.4) and a serial number. 1268 To facilitate compact representation of serial numbers, a contiguous 1269 block can be specified by the lowest authorized serial number and the 1270 highest authorized serial number. Alternatively, all of the serial 1271 numbers associated with a hardware module family identifier can be 1272 specified with the NULL value. 1274 If the bootstrap loader does not have a mechanism for obtaining a 1275 list of object identifiers that identify the communities to which the 1276 hardware module is a member, then the bootstrap loader MUST behave as 1277 though the list is empty. Similarly, if the bootstrap loader does 1278 not have access to the hardware module serial number, then the 1279 bootstrap loader MUST behave as though the hardware module is not 1280 included on the list of authorized hardware modules. 1282 The following object identifier identifies the community-identifiers 1283 attribute: 1285 id-aa-communityIdentifiers OBJECT IDENTIFIER ::= { 1286 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1287 smime(16) aa(2) 40 } 1289 The community-identifiers attribute values have ASN.1 type 1290 CommunityIdentifiers: 1292 CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier 1294 CommunityIdentifier ::= CHOICE { 1295 communityOID OBJECT IDENTIFIER, 1296 hwModuleList HardwareModules } 1298 HardwareModules ::= SEQUENCE { 1299 hwType OBJECT IDENTIFIER, 1300 hwSerialEntries SEQUENCE OF HardwareSerialEntry } 1302 HardwareSerialEntry ::= CHOICE { 1303 all NULL, 1304 single OCTET STRING, 1305 block SEQUENCE { 1306 low OCTET STRING, 1307 high OCTET STRING } } 1309 2.2.9 Firmware Package Information 1311 If a hardware module supports more than one type of firmware package, 1312 then the firmware package signer SHOULD include the firmware-package- 1313 info attribute with a populated fwPkgType field to identify the 1314 firmware package type. This value can aid the Bootstrap Loader in 1315 the correct placement of the firmware package within the hardware 1316 module. The firmware package type is an INTEGER, and the meaning of 1317 the integer value is specific to each hardware module. For example, 1318 a hardware module could assign different integer values for a 1319 bootstrap loader, a separation kernel, and an application. 1321 Some hardware module architectures permit one firmware package to use 1322 routines provided by another firmware package. If the firmware 1323 package contains a dependency on another firmware package, then the 1324 firmware package signer SHOULD also include the firmware-package-info 1325 attribute with a populated dependencies field. If the firmware 1326 package does not depend on any other firmware packages, then the 1327 firmware package signer MUST NOT include the firmware-package-info 1328 attribute with a populated dependencies field. 1330 Firmware package dependencies are identified by the firmware package 1331 identifier or they are identified by information contained in the 1332 firmware package itself, and in either case the bootstrap loader 1333 ensures that the dependencies are met. The bootstrap loader MUST 1334 reject a firmware package load if it identifies a dependency on a 1335 firmware package that is not already loaded. Also, the bootstrap 1336 loader MUST reject a firmware package load if the action will result 1337 in a configuration where the dependencies of an already loaded 1338 firmware package will no longer be satisfied. As described in 1339 section 2.2.3, two approaches to naming firmware packages are 1340 supported: legacy and preferred. When the legacy firmware package 1341 name form is used, the dependency is indicated by a legacy firmware 1342 package name. We assume that the firmware package signer and the 1343 bootstrap loader can determine whether a given legacy firmware 1344 package name represents the named version of an acceptable newer 1345 version. When the preferred firmware package name form is used, an 1346 object identifier and an integer are provided. The object identifier 1347 MUST exactly match the object identifier portion of a preferred 1348 firmware package name associated with a firmware package that is 1349 already loaded, and the integer MUST be less than or equal to the 1350 integer portion of the preferred firmware package name associated 1351 with the same firmware package. That is, the dependency specifies 1352 the minimum value of the version that is acceptable. 1354 The following object identifier identifies the firmware-package-info 1355 attribute: 1357 id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= { 1358 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1359 smime(16) aa(2) 42 } 1361 The firmware-package-info attribute values have ASN.1 type 1362 FirmwarePackageInfo: 1364 FirmwarePackageInfo ::= SEQUENCE { 1365 fwPkgType INTEGER OPTIONAL, 1366 dependencies SEQUENCE OF 1367 PreferredOrLegacyPackageIdentifier OPTIONAL } 1369 2.2.10 Firmware Package Message Digest 1371 The firmware package signer SHOULD include a firmware-package- 1372 message-digest attribute, which provides the message digest algorithm 1373 and the message digest value computed on the firmware package. The 1374 message digest is computed on the firmware package prior to any 1375 compression, encryption, or signature processing. The bootstrap 1376 loader MAY use this message digest to confirm that the intended 1377 firmware package has been recovered after all of the layers of 1378 encapsulation are removed. 1380 The following object identifier identifies the firmware-package- 1381 message-digest attribute: 1383 id-aa-fwPkgMessageDigest OBJECT IDENTIFIER ::= { 1384 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1385 smime(16) aa(2) 41 } 1387 The firmware-package-message-digest attribute values have ASN.1 type 1388 FirmwarePackageMessageDigest: 1390 FirmwarePackageMessageDigest ::= SEQUENCE { 1391 algorithm AlgorithmIdentifier, 1392 msgDigest OCTET STRING } 1394 2.2.11 Signing Time 1396 The firmware package signer SHOULD include a signing-time attribute, 1397 specifying the time at which the signature was applied to the 1398 firmware package. Section 11.3 of [CMS] defines the signing-time 1399 attribute. 1401 2.2.12 Content Hints 1403 The firmware package signer SHOULD include a content-hints attribute, 1404 including a brief text description of the firmware package. The text 1405 is encoded in UTF-8, which supports most of the world's writing 1406 systems [UTF-8]. Section 2.9 of [ESS] defines the content-hints 1407 attribute. 1409 When multiple layers of encapsulation are employed, the content-hints 1410 attribute is included in the outermost SignedData to provide 1411 information about the innermost content. In this case, the content- 1412 hints attribute provides a brief text description of the firmware 1413 package, which can help a person select the correct firmware package 1414 when more than one is available. 1416 When the preferred firmware package name forms are used, the content- 1417 hints attribute can provide a linkage to a legacy firmware package 1418 name. This is especially helpful when an existing configuration 1419 management system is in use, but the features associated with the 1420 preferred firmware package name are deemed useful. A firmware 1421 package name associated with such a configuration management system 1422 might look something like "R1234.C0(AJ11).D62.A02.11(b)." Including 1423 these firmware package names in the text description may be helpful 1424 to developers by providing a clear linkage between the two name 1425 forms. 1427 The content-hints attribute contains two fields, and in this case, 1428 both fields MUST be present. The fields of ContentHints are used as 1429 follows: 1431 contentDescription provides a brief text description of the firmware 1432 package. 1434 contentType provides the content type of the inner most content type, 1435 and in this case, it MUST be id-ct-firmwarePackage 1436 (1.2.840.113549.1.9.16.1.16). 1438 2.2.13 Signing Certificate 1440 When the firmware-signer's public key is contained in a certificate, 1441 the firmware package signer SHOULD include a signing-certificate 1442 attribute to identify the certificate that was employed. However, if 1443 the firmware package signature does not have a certificate (meaning 1444 that the signature will only be validated with the trust anchor 1445 public key), then the firmware package signer is unable to include a 1446 signing-certificate attribute. Section 5.4 of [ESS] defines the 1447 signing-certificate attribute. 1449 The signing-certificate attribute contains two fields: certs and 1450 policies. The certs field MUST be present, and the policies field 1451 MAY be present. The fields of SigningCertificate are used as 1452 follows: 1454 certs contains a sequence of certificate identifiers. In this case, 1455 sequence of certificate identifiers contains a single entry. The 1456 certs field MUST contain only the certificate identifier of the 1457 certificate that contains the public key used to verify the 1458 firmware package signature. The certs field uses the ESSCertID 1459 syntax specified in section 5.4 of [ESS], and it is comprised of 1460 the SHA-1 hash [SHA1] of the entire ASN.1 DER encoded certificate 1461 and, optionally, the certificate issuer and the certificate serial 1462 number. The SHA-1 hash value MUST be present. The certificate 1463 issuer and the certificate serial number SHOULD be present. 1465 policies is optional, and when it is present, it contains a sequence 1466 of policy information. The policies field, when present, MUST 1467 contain only one entry, and that entry MUST match one of the 1468 certificate policies in the certificate policies extension of the 1469 certificate that contains the public key used to verify the 1470 firmware package signature. The policies field uses the 1471 PolicyInformation syntax specified in section 4.2.1.5 of 1472 [PROFILE], and it is comprised of the certificate policy object 1473 identifier and, optionally, certificate policy qualifiers. The 1474 certificate policy object identifier MUST be present. The 1475 certificate policy qualifiers SHOULD NOT be present. 1477 2.3 Unsigned Attributes 1479 CMS allows a SET of unsigned attributes to be included; however, in 1480 this specification, the set MUST be absent or include a single 1481 instance of the wrapped-firmware-decryption-key attribute. Since the 1482 digital signature does not cover this attribute, it can be altered at 1483 any point in the delivery path from the firmware package signer to 1484 the hardware module. This property can be employed to distribute the 1485 firmware-decryption key along with an encrypted and signed firmware 1486 package, allowing the firmware-decryption key to be wrapped with a 1487 different key-encryption key for each link in the distribution chain. 1489 The syntax for attributes is defined in [CMS], and it is repeated at 1490 the beginning of section 2.2 of this document for convenience. Each 1491 of the attributes used with this profile has a single attribute 1492 value, even though the syntax is defined as a SET OF AttributeValue. 1493 There MUST be exactly one instance of AttributeValue present. 1495 The UnsignedAttributes syntax within signerInfo is defined as a SET 1496 OF Attributes. The UnsignedAttributes MUST include only one instance 1497 of any particular attribute. 1499 2.3.1 Wrapped Firmware Decryption Key 1501 The firmware package signer, or any other party in the distribution 1502 chain, MAY include a wrapped-firmware-decryption-key attribute. 1504 The following object identifier identifies the wrapped-firmware- 1505 decryption-key attribute: 1507 id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= { 1508 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1509 smime(16) aa(2) 39 } 1511 The wrapped-firmware-decryption-key attribute values have ASN.1 type 1512 of EnvelopedData. Section 6 of [CMS] defines the EnvelopedData 1513 content type, which is used to construct the value of the attribute. 1514 EnvelopedData permits the firmware-decryption key to be protected 1515 using symmetric or asymmetric techniques. The EnvelopedData does not 1516 include an encrypted content, rather the EnvelopedData feature of 1517 having the encrypted content in another location is employed. The 1518 encrypted content is found in the eContent field of the EncryptedData 1519 structure. The firmware-decryption key is contained in the 1520 recipientInfos field. Section 6 of [CMS] refers to this key as the 1521 content-encryption key. 1523 The EnvelopedData syntax support many different key management 1524 algorithms. Four general techniques are supported: key transport, 1525 key agreement, symmetric key-encryption keys, and passwords. 1527 The EnvelopedData content type is profiled for the wrapped-firmware- 1528 decryption-key attribute. The EnvelopedData fields are described 1529 fully in Section 6 of [CMS]. Additional rules apply when 1530 EnvelopedData is used as a wrapped-firmware-decryption-key attribute. 1532 Within the EnvelopedData structure: 1534 - The set of certificates included in OriginatorInfo MUST NOT include 1535 certificates with a type of extendedCertificate, v1AttrCert, or 1536 v2AttrCert [X.509-97, X.509-00, ACPROFILE]. The optional crls 1537 field MAY be present. 1539 - The optional unprotectedAttrs field MUST NOT be present. 1541 Within the EncryptedContentInfo structure: 1543 - contentType MUST match the content type object identifier carried 1544 in the contentType field within the EncryptedContentInfo structure 1545 of EncryptedData as described in section 2.1.3.1. 1547 - contentEncryptionAlgorithm identifies the firmware-encryption 1548 algorithm, and any associated parameters, used to encrypt the 1549 firmware package carried in the encryptedContent field of the 1550 EncryptedContentInfo structure of EncryptedData. Therefore, it 1551 MUST exactly match the value of the EncryptedContentInfo structure 1552 of EncryptedData as described in section 2.1.3.1. 1554 - encryptedContent is optional, and in this case, it MUST NOT be 1555 present. 1557 3 Firmware Package Load Receipt 1559 The Cryptographic Message Syntax (CMS) is used to indicate that a 1560 firmware package loaded successfully. Support for firmware package 1561 load receipts is OPTIONAL. However, those hardware modules that 1562 choose to generate such receipts MUST follow the conventions 1563 specified in this section. Since not all hardware modules will have 1564 private signature keys, the firmware package load receipt can either 1565 be signed or unsigned. Use of the signed firmware package load 1566 receipt is RECOMMENDED. 1568 Hardware modules that support receipt generation MUST have a unique 1569 serial number. Hardware modules that support signed receipt 1570 generation MUST have a private signature key to sign the receipt and 1571 the corresponding signature validation certificate or its designator. 1572 The designator is the certificate issuer name and the certificate 1573 serial number, or it is the public key identifier. Memory 1574 constrained hardware modules will generally store the public key 1575 identifier since it requires less storage. 1577 The unsigned firmware package load receipt is encapsulated by 1578 ContentInfo. Alternatively, the signed firmware package load receipt 1579 is encapsulated by SignedData, which is in turn encapsulated by 1580 ContentInfo. 1582 The firmware package load receipt is summarized by (see [CMS] for the 1583 full syntax): 1585 ContentInfo { 1586 contentType id-signedData, -- (1.2.840.113549.1.7.2) 1587 -- OR -- 1588 id-ct-firmwareLoadReceipt, 1589 -- (1.2.840.113549.1.9.16.1.17) 1590 content SignedData 1591 -- OR -- 1592 FirmwarePackageLoadReceipt 1593 } 1594 SignedData { 1595 version CMSVersion, -- always set to 3 1596 digestAlgorithms DigestAlgorithmIdentifiers, -- Only one 1597 encapContentInfo EncapsulatedContentInfo, 1598 certificates CertificateSet, -- Optional Module certificate 1599 crls CertificateRevocationLists, -- Optional 1600 signerInfos SET OF SignerInfo -- Only one 1601 } 1603 SignerInfo { 1604 version CMSVersion, -- either set to 1 or 3 1605 sid SignerIdentifier, 1606 digestAlgorithm DigestAlgorithmIdentifier, 1607 signedAttrs SignedAttributes, -- Required 1608 signatureAlgorithm SignatureAlgorithmIdentifier, 1609 signature SignatureValue, 1610 unsignedAttrs UnsignedAttributes -- Omit 1611 } 1613 EncapsulatedContentInfo { 1614 eContentType id-ct-firmwareLoadReceipt, 1615 -- (1.2.840.113549.1.9.16.1.17) 1616 eContent OCTET STRING -- Contains receipt 1617 } 1619 FirmwarePackageLoadReceipt { 1620 version INTEGER, -- The DEFAULT is always used 1621 hwType OBJECT IDENTIFIER, -- Hardware module type 1622 hwSerialNum OCTET STRING, -- H/W module serial number 1623 fwPkgName PreferredOrLegacyPackageIdentifier, 1624 trustAnchorKeyID OCTET STRING, -- Optional 1625 decryptKeyID OCTET STRING -- Optional 1626 } 1628 3.1 Firmware Package Load Receipt CMS Content Type Profile 1630 This section specifies the conventions for using the CMS ContentInfo 1631 and SignedData content types for firmware package load receipts. It 1632 also defines the firmware package load receipt content type. 1634 3.1.1 ContentInfo 1636 The CMS requires the outer most encapsulation to be ContentInfo 1637 [CMS]. The fields of ContentInfo are used as follows: 1639 contentType indicates the type of the associated content. If the 1640 firmware package load receipt is signed, then the encapsulated 1641 type MUST be SignedData, and the id-signedData 1642 (1.2.840.113549.1.7.2) object identifier MUST be present in this 1643 field. If the firmware load receipt is not signed, then the 1644 encapsulated type MUST be FirmwarePackageLoadReceipt, and the id- 1645 ct-firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17) object 1646 identifier MUST be present in this field. 1648 content holds the associated content. If the firmware package load 1649 receipt is signed, then this field MUST contain the SignedData. 1650 If the firmware package load receipt is not signed, then this 1651 field MUST contain the FirmwarePackageLoadReceipt. 1653 3.1.2 SignedData 1655 The SignedData content type contains the firmware package load 1656 receipt and one digital signature. If the hardware module locally 1657 stores its certificate, then the certificate can be included as well. 1658 The fields of SignedData are used as follows: 1660 version is the syntax version number, and in this case, is MUST be 1661 set to 3. 1663 digestAlgorithms is a collection of message digest algorithm 1664 identifiers, and in this case, it MUST contain a single message 1665 digest algorithm identifier. The message digest algorithms 1666 employed by the hardware module MUST be present. 1668 encapContentInfo is the signed content, consisting of a content type 1669 identifier and the content itself. The use of the 1670 EncapsulatedContentInfo type is discussed further in section 1671 3.1.2.2. 1673 certificates is an optional collection of certificates. If the 1674 hardware module locally stores its certificate, then the X.509 1675 certificate of the hardware module SHOULD be included. If the 1676 hardware module does not locally store its certificate, then the 1677 certificates field is omitted. PKCS#6 extended certificates 1678 [PKCS#6] and attribute certificates (either version 1 or version 1679 2) [X.509-97, X.509-00, ACPROFILE] MUST NOT be included in the set 1680 of certificates. 1682 crls is an optional collection of certificate revocation lists 1683 (CRLs). CRLs MAY be included, but they will normally be omitted 1684 since hardware modules will not generally have access to the most 1685 recent CRL. Signed receipt recipients SHOULD be able to handle the 1686 presence of the optional crls field. 1688 signerInfos is a collection of per-signer information, and in this 1689 case, the collection MUST contain exactly one SignerInfo. The use 1690 of the SignerInfo type is discussed further in section 3.1.2.1. 1692 3.1.2.1 SignerInfo 1694 The hardware module is represented in the SignerInfo type. The 1695 fields of SignerInfo are used as follows: 1697 version is the syntax version number, and it MUST be either 1 or 3, 1698 depending on the method used to identify the hardware module's 1699 public key. The use of the subjectKeyIdentifier is RECOMMENDED, 1700 which results in the use of version 3. 1702 sid specifies the hardware module's certificate (and thereby the 1703 hardware module's public key). CMS supports two alternatives: 1704 issuerAndSerialNumber and subjectKeyIdentifier. The hardware 1705 module MUST support one or both of the alternatives for receipt 1706 generation; however, the support of subjectKeyIdentifier is 1707 RECOMMENDED. The issuerAndSerialNumber alternative identifies the 1708 hardware module's certificate by the issuer's distinguished name 1709 and the certificate serial number. The identified certificate, in 1710 turn, contains the hardware module's public key. The 1711 subjectKeyIdentifier alternative identifies the hardware module's 1712 public key directly. When this public key is contained in a 1713 certificate, this identifier SHOULD appear in the X.509 1714 subjectKeyIdentifier extension. 1716 digestAlgorithm identifies the message digest algorithm, and any 1717 associated parameters, used by the hardware module. It MUST 1718 contain the message digest algorithms employed to sign the 1719 receipt. (Note that this message digest algorithm identifier MUST 1720 be the same as the one carried in the digestAlgorithms value in 1721 SignedData.) 1723 signedAttrs is an optional collection of attributes that are signed 1724 along with the content. The signedAttrs are optional in the CMS, 1725 but in this specification, signedAttrs are REQUIRED for use with 1726 the firmware package load receipt content. The SET OF attributes 1727 MUST be DER encoded [X.509-88]. Section 3.2 of this document 1728 lists the attributes that MUST be included in the collection. 1729 Other attributes MAY be included, but the recipient will ignore 1730 any unrecognized signed attributes. 1732 signatureAlgorithm identifies the signature algorithm, and any 1733 associated parameters, used to sign the receipt. 1735 signature is the digital signature. 1737 unsignedAttrs is an optional collection of attributes that are not 1738 signed, and in this case, there MUST NOT be any unsigned 1739 attributes present. 1741 3.1.2.2 EncapsulatedContentInfo 1743 The FirmwarePackageLoadReceipt is encapsulated in an OCTET STRING, 1744 and it is carried within the EncapsulatedContentInfo type. The 1745 fields of EncapsulatedContentInfo are used as follows: 1747 eContentType is an object identifier that uniquely specifies the 1748 content type, and in this case, it MUST be the value of id-ct- 1749 firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17). 1751 eContent is the firmware package load receipt, encapsulated in an 1752 OCTET STRING. The eContent octet string need not be DER encoded. 1754 3.1.3 FirmwarePackageLoadReceipt 1756 The following object identifier identifies the firmware package load 1757 receipt content type: 1759 id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= { 1760 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1761 smime(16) ct(1) 17 } 1763 The firmware package load receipt content type has the ASN.1 type 1764 FirmwarePackageLoadReceipt: 1766 FirmwarePackageLoadReceipt ::= SEQUENCE { 1767 version FWReceiptVersion DEFAULT v1, 1768 hwType OBJECT IDENTIFIER, 1769 hwSerialNum OCTET STRING, 1770 fwPkgName PreferredOrLegacyPackageIdentifier, 1771 trustAnchorKeyID OCTET STRING OPTIONAL, 1772 decryptKeyID [1] OCTET STRING OPTIONAL } 1774 FWReceiptVersion ::= INTEGER { v1(1) } 1776 The fields of the FirmwarePackageLoadReceipt type have the following 1777 meanings: 1779 version is an integer, and it provides the syntax version number for 1780 compatibility with future revisions of this specification. 1781 Implementations that conform to this specification MUST set the 1782 version to the default value, which is v1. 1784 hwType is an object identifier that identifies the type of hardware 1785 module on which the firmware package was loaded. 1787 hwSerialNum is the serial number of the hardware module on which the 1788 firmware package was loaded. No particular structure is imposed 1789 on the serial number; it need not be an integer. However, the 1790 combination of the hwType and hwSerialNum uniquely identifies the 1791 hardware module. 1793 fwPkgName identifies the firmware package that was loaded. As 1794 described in section 2.2.3, two approaches to naming firmware 1795 packages are supported: legacy and preferred. A legacy firmware 1796 package name is an octet string. A preferred firmware package 1797 name is a combination of the firmware package object identifier 1798 and an integer version number. 1800 trustAnchorKeyID is optional, and when it is present it identifies 1801 the trust anchor that was used to validate the firmware package 1802 signature. 1804 decryptKeyID is optional, and when it is present it identifies the 1805 firmware-decryption key that was used to decrypt the firmware 1806 package. 1808 The Firmware Package Load Receipt MUST include the version, hwType, 1809 hwSerialNum, and fwPkgName fields, and it SHOULD include the 1810 trustAnchorKeyID field. The Firmware Package Load Receipt MUST NOT 1811 include the decryptKeyID unless the firmware package associated with 1812 the receipt is encrypted, the firmware-decryption key is available to 1813 the hardware module, and the firmware package was successfully 1814 decrypted. 1816 3.2 Signed Attributes 1818 The hardware module MUST digitally sign a collection of attributes 1819 along with the firmware package load receipt. Each attribute in the 1820 collection MUST be DER encoded [X.509-88]. The syntax for attributes 1821 is defined in [CMS], and it was repeated in section 2.2 for 1822 convenience. 1824 Each of the attributes used with this profile has a single attribute 1825 value, even though the syntax is defined as a SET OF AttributeValue. 1826 There MUST be exactly one instance of AttributeValue present. 1828 The SignedAttributes syntax within signerInfo is defined as a SET OF 1829 Attributes. The SignedAttributes MUST include only one instance of 1830 any particular attribute. 1832 The hardware module MUST include the content-type and message-digest 1833 attributes. If the hardware module includes a real-time clock, then 1834 the hardware module SHOULD also include the signing-time attribute. 1835 The hardware module MAY include any other attribute that it deems 1836 appropriate. 1838 3.2.1 Content Type 1840 The hardware module MUST include a content-type attribute with the 1841 value of id-ct-firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17). 1842 Section 11.1 of [CMS] defines the content-type attribute. 1844 3.2.2 Message Digest 1846 The hardware module MUST include a message-digest attribute, having 1847 as its value the message digest of the FirmwarePackageLoadReceipt 1848 content. Section 11.2 of [CMS] defines the message-digest attribute. 1850 3.2.3 Signing Time 1852 If the hardware module includes a real-time clock, then hardware 1853 module SHOULD include a signing-time attribute, specifying the time 1854 at which the receipt was generated. Section 11.3 of [CMS] defines 1855 the signing-time attribute. 1857 4 Firmware Package Load Error 1859 The Cryptographic Message Syntax (CMS) is used to indicate that an 1860 error has occurred while attempting to load a protected firmware 1861 package. Support for firmware package load error reports is 1862 OPTIONAL. However, those hardware modules that choose to generate 1863 such error reports MUST follow the conventions specified in this 1864 section. Not all hardware modules have private signature keys; 1865 therefore the firmware package load error report can either be signed 1866 or unsigned. Use of the signed firmware package error report is 1867 RECOMMENDED. 1869 Hardware modules that support error report generation MUST have a 1870 unique serial number. Hardware modules that support signed error 1871 report generation MUST also have a private signature key to sign the 1872 error report and the corresponding signature validation certificate 1873 or its designator. The designator is the certificate issuer name and 1874 the certificate serial number, or it is the public key identifier. 1875 Memory constrained hardware modules will generally store the public 1876 key identifier since it requires less storage. 1878 The unsigned firmware package load error report is encapsulated by 1879 ContentInfo. Alternatively, the signed firmware package load error 1880 report is encapsulated by SignedData, which is in turn encapsulated 1881 by ContentInfo. 1883 The firmware package load error report is summarized by (see [CMS] 1884 for the full syntax): 1886 ContentInfo { 1887 contentType id-signedData, -- (1.2.840.113549.1.7.2) 1888 -- OR -- 1889 id-ct-firmwareLoadError, 1890 -- (1.2.840.113549.1.9.16.1.18) 1891 content SignedData 1892 -- OR -- 1893 FirmwarePackageLoadError 1894 } 1896 SignedData { 1897 version CMSVersion, -- Always set to 3 1898 digestAlgorithms DigestAlgorithmIdentifiers, -- Only one 1899 encapContentInfo EncapsulatedContentInfo, 1900 certificates CertificateSet, -- Optional Module certificate 1901 crls CertificateRevocationLists, -- Optional 1902 signerInfos SET OF SignerInfo -- Only one 1903 } 1905 SignerInfo { 1906 version CMSVersion, -- either set to 1 or 3 1907 sid SignerIdentifier, 1908 digestAlgorithm DigestAlgorithmIdentifier, 1909 signedAttrs SignedAttributes, -- Required 1910 signatureAlgorithm SignatureAlgorithmIdentifier, 1911 signature SignatureValue, 1912 unsignedAttrs UnsignedAttributes -- Omit 1913 } 1915 EncapsulatedContentInfo { 1916 eContentType id-ct-firmwareLoadError, 1917 -- (1.2.840.113549.1.9.16.1.18) 1918 eContent OCTET STRING -- Contains error report 1919 } 1920 FirmwarePackageLoadError { 1921 version INTEGER, -- The DEFAULT is always used 1922 hwType OBJECT IDENTIFIER, -- Hardware module type 1923 hwSerialNum OCTET STRING, -- H/W module serial number 1924 errorCode FirmwarePackageLoadErrorCode -- Error identifier 1925 vendorErrorCode VendorErrorCode, -- Optional 1926 fwPkgName PreferredOrLegacyPackageIdentifier, -- Optional 1927 config SEQUENCE OF CurrentFWConfig, -- Optional 1928 } 1930 CurrentFWConfig { -- Repeated for each package in configuration 1931 fwPkgType INTEGER, -- Firmware package type; Optional 1932 fwPkgName PreferredOrLegacyPackageIdentifier 1933 } 1935 4.1 Firmware Package Load Error CMS Content Type Profile 1937 This section specifies the conventions for using the CMS ContentInfo 1938 and SignedData content types for firmware package load error reports. 1939 It also defines the firmware package load error content type. 1941 4.1.1 ContentInfo 1943 The CMS requires the outer most encapsulation to be ContentInfo 1944 [CMS]. The fields of ContentInfo are used as follows: 1946 contentType indicates the type of the associated content. If the 1947 firmware package load error report is signed, then the 1948 encapsulated type MUST be SignedData, and the id-signedData 1949 (1.2.840.113549.1.7.2) object identifier MUST be present in this 1950 field. If the firmware package load error report is not signed, 1951 then the encapsulated type MUST be FirmwarePackageLoadError, and 1952 the id-ct-firmwareLoadError (1.2.840.113549.1.9.16.1.18) object 1953 identifier MUST be present in this field. 1955 content holds the associated content. If the firmware package load 1956 error report is signed, then this field MUST contain the 1957 SignedData. If the firmware package load error report is not 1958 signed, then this field MUST contain the FirmwarePackageLoadError. 1960 4.1.2 SignedData 1962 The SignedData content type contains the firmware package load error 1963 report and one digital signature. If the hardware module locally 1964 stores its certificate, then the certificate can be included as well. 1965 The fields of SignedData are used exactly as described in section 1966 3.1.2. 1968 4.1.2.1 SignerInfo 1970 The hardware module is represented in the SignerInfo type. The 1971 fields of SignerInfo are used exactly as described in section 1972 3.1.2.1. 1974 4.1.2.2 EncapsulatedContentInfo 1976 The FirmwarePackageLoadError is encapsulated in an OCTET STRING, and 1977 it is carried within the EncapsulatedContentInfo type. The fields of 1978 EncapsulatedContentInfo are used as follows: 1980 eContentType is an object identifier that uniquely specifies the 1981 content type, and in this case, it MUST be the value of id-ct- 1982 firmwareLoadError (1.2.840.113549.1.9.16.1.18). 1984 eContent is the firmware package load error report, encapsulated in 1985 an OCTET STRING. The eContent octet string need not be DER 1986 encoded. 1988 4.1.3 FirmwarePackageLoadError 1990 The following object identifier identifies the firmware package load 1991 error report content type: 1993 id-ct-firmwareLoadError OBJECT IDENTIFIER ::= { 1994 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1995 smime(16) ct(1) 18 } 1997 The firmware package load error report content type has the ASN.1 1998 type FirmwarePackageLoadError: 2000 FirmwarePackageLoadError ::= SEQUENCE { 2001 version FWErrorVersion DEFAULT v1, 2002 hwType OBJECT IDENTIFIER, 2003 hwSerialNum OCTET STRING, 2004 errorCode FirmwarePackageLoadErrorCode, 2005 vendorErrorCode VendorLoadErrorCode OPTIONAL, 2006 fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL, 2007 config [1] SEQUENCE OF CurrentFWConfig OPTIONAL } 2009 FWErrorVersion ::= INTEGER { v1(1) } 2011 CurrentFWConfig ::= SEQUENCE { 2012 fwPkgType INTEGER OPTIONAL, 2013 fwPkgName PreferredOrLegacyPackageIdentifier } 2015 FirmwarePackageLoadErrorCode ::= ENUMERATED { 2016 decodeFailure (1), 2017 badContentInfo (2), 2018 badSignedData (3), 2019 badEncapContent (4), 2020 badCertificate (5), 2021 badSignerInfo (6), 2022 badSignedAttrs (7), 2023 badUnsignedAttrs (8), 2024 missingContent (9), 2025 noTrustAnchor (10), 2026 notAuthorized (11), 2027 badDigestAlgorithm (12), 2028 badSignatureAlgorithm (13), 2029 unsupportedKeySize (14), 2030 signatureFailure (15), 2031 contentTypeMismatch (16), 2032 badEncryptedData (17), 2033 unprotectedAttrsPresent (18), 2034 badEncryptContent (19), 2035 badEncryptAlgorithm (20), 2036 missingCiphertext (21), 2037 noDecryptKey (22), 2038 decryptFailure (23), 2039 badCompressAlgorithm (24), 2040 missingCompressedContent (25), 2041 decompressFailure (26), 2042 wrongHardware (27), 2043 stalePackage (28), 2044 notInCommunity (29), 2045 unsupportedPackageType (30), 2046 missingDependency (31), 2047 wrongDependencyVersion (32), 2048 insufficientMemory (33), 2049 badFirmware (34), 2050 unsupportedParameters (35), 2051 breaksDependency (36), 2052 otherError (99) } 2054 VendorLoadErrorCode ::= INTEGER 2056 The fields of the FirmwarePackageLoadError type have the following 2057 meanings: 2059 version is an integer, and it provides the syntax version number for 2060 compatibility with future revisions of this specification. 2061 Implementations that conform to this specification MUST set the 2062 version to the default value, which is v1. 2064 hwType is an object identifier that identifies the type of hardware 2065 module on which the firmware package load was attempted. 2067 hwSerialNum is the serial number of the hardware module on which the 2068 firmware package load was attempted. No particular structure is 2069 imposed on the serial number; it need not be an integer. However, 2070 the combination of the hwType and hwSerialNum uniquely identifies 2071 the hardware module. 2073 errorCode identifies the error that occurred. 2075 vendorErrorCode is optional; however, it MUST be present if the 2076 errorCode contains a value of otherError. When errorCode contains 2077 a value other than otherError, the vendorErrorCode can provide 2078 vendor-specific supplemental information. 2080 fwPkgName is optional. When it is present, it identifies the 2081 firmware package that was being loaded when the error occurred. 2082 As described in section 2.2.3, two approaches to naming firmware 2083 packages are supported: legacy and preferred. A legacy firmware 2084 package name is an octet string. A preferred firmware package 2085 name is a combination of the firmware package object identifier 2086 and an integer version number. 2088 config identifies the current firmware configuration. The field is 2089 OPTIONAL, but support for this field is RECOMMENDED for hardware 2090 modules that permit the loading of more than one firmware package. 2091 One instance of CurrentFWConfig is used to provide information 2092 about each firmware package in hardware module. 2094 The fields of the CurrentFWConfig type have the following meanings: 2096 fwPkgType identifies the firmware package type. The firmware package 2097 type is an INTEGER, and the meaning of the integer value is 2098 specific to each hardware module. 2100 fwPkgName identifies the firmware package. As described in section 2101 2.2.3, two approaches to naming firmware packages are supported: 2102 legacy and preferred. A legacy firmware package name is an octet 2103 string. A preferred firmware package name is a combination of the 2104 firmware package object identifier and an integer version number. 2106 The errorCode values have the following meanings: 2108 decodeFailure: The ASN.1 decode of the firmware package load failed. 2109 The provided input did not conform to BER, or it was not ASN.1 at 2110 all. 2112 badContentInfo: Invalid ContentInfo syntax, or the contentType 2113 carried within the ContentInfo is unknown or unsupported. 2115 badSignedData: Invalid SignedData syntax, the version is unknown or 2116 unsupported, or more than one entry is present in 2117 digestAlgorithms. 2119 badEncapContent: Invalid EncapsulatedContentInfo syntax, or the 2120 contentType carried within the eContentType is unknown or 2121 unsupported. This error can be generated due to problems located 2122 in SignedData or CompressedData. 2124 badCertificate: Invalid syntax for one or more certificates in 2125 CertificateSet. 2127 badSignerInfo: Invalid SignerInfo syntax, or the version is unknown 2128 or unsupported. 2130 badSignedAttrs: Invalid signedAttrs syntax within SignerInfo. 2132 badUnsignedAttrs: The unsignedAttrs within SignerInfo contains an 2133 attribute other than the wrapped-firmware-decryption-key 2134 attribute, which is the only unsigned attribute supported by this 2135 specification. 2137 missingContent: The optional eContent is missing in 2138 EncapsulatedContentInfo, which is required in this specification. 2139 This error can be generated due to problems located in SignedData 2140 or CompressedData. 2142 noTrustAnchor: Two situations can lead to this error. In one case, 2143 the subjectKeyIdentifier does not identify the public key of a 2144 trust anchor or a certification path that terminates with an 2145 installed trust anchor. In the other case, the 2146 issuerAndSerialNumber does not identify the public key of a trust 2147 anchor or a certification path that terminates with an installed 2148 trust anchor. 2150 notAuthorized: The sid within SignerInfo leads to an installed trust 2151 anchor, but that trust anchor is not an authorized firmware 2152 package signer. 2154 badDigestAlgorithm: The digestAlgorithm in either SignerInfo or 2155 SignedData is unknown or unsupported. 2157 badSignatureAlgorithm: The signatureAlgorithm in SignerInfo is 2158 unknown or unsupported. 2160 unsupportedKeySize: The signatureAlgorithm in SignerInfo is known 2161 and supported, but the firmware package signature could not be 2162 validated because an unsupported key size was employed by the 2163 signer. 2165 signatureFailure: The signatureAlgorithm in SignerInfo is known and 2166 supported, but the signature in signature in SignerInfo could not 2167 be validated. 2169 contentTypeMismatch: The contentType carried within the eContentType 2170 does not match the content type carried in the signed attribute. 2172 badEncryptedData: Invalid EncryptedData syntax, the version is 2173 unknown or unsupported. 2175 unprotectedAttrsPresent: EncryptedData contains unprotectedAttrs, 2176 which are not permitted in this specification. 2178 badEncryptContent: Invalid EncryptedContentInfo syntax, or the 2179 contentType carried within the contentType is unknown or 2180 unsupported. 2182 badEncryptAlgorithm: The firmware-encryption algorithm identified by 2183 contentEncryptionAlgorithm in EncryptedContentInfo is unknown or 2184 unsupported. 2186 missingCiphertext: The optional encryptedContent is missing in 2187 EncryptedContentInfo, which is required in this specification. 2189 noDecryptKey: The hardware module does not have the firmware- 2190 decryption key named in the decrypt key identifier signed 2191 attribute. 2193 decryptFailure: The firmware package did not decrypt properly. 2195 badCompressAlgorithm: The compression algorithm identified by 2196 compressionAlgorithm in CompressedData is unknown or unsupported. 2198 missingCompressedContent: The optional eContent is missing in 2199 EncapsulatedContentInfo, which is required in this specification. 2201 decompressFailure: The firmware package did not decompress properly. 2203 wrongHardware: The processing hardware module is not listed in the 2204 target hardware module identifiers signed attribute. 2206 stalePackage: The firmware package is rejected because it is stale. 2208 notInCommunity: The hardware module is not a member of the community 2209 described in the community identifiers signed attribute. 2211 unsupportedPackageType: The firmware package type identified in the 2212 firmware package information signed attribute is not supported by 2213 the combination of the hardware module and the bootstrap loader. 2215 missingDependency: The firmware package being loaded depends on 2216 routines that are part of another firmware package, but that 2217 firmware package is not available. 2219 wrongDependencyVersion: The firmware package being loaded depends on 2220 routines that are part of the another firmware package, and the 2221 available version of that package has an older version number than 2222 is required. The available firmware package does not fulfill the 2223 dependencies. 2225 insufficientMemory: The firmware package could not be loaded because 2226 the hardware module did not have sufficient memory. 2228 badFirmware: The signature on the firmware package was validated, 2229 but the firmware package itself was not in an acceptable format. 2230 The details will be specific to each hardware module. For 2231 example, a hardware module that is composed of multiple firmware- 2232 programmable components could not find the internal tagging within 2233 the firmware package to distribute executable code to each of the 2234 components. 2236 unsupportedParameters: The signature on the firmware package could 2237 not be validated due to the use of signature algorithm parameters 2238 by the signer that are not supported by the hardware module 2239 signature verification routines. 2241 breaksDependency: Another firmware package has a dependency that can 2242 no longer be satisfied if the firmware package being loaded is 2243 accepted. 2245 otherError: An error occurred that does not fit any of the previous 2246 error codes. 2248 4.2 Signed Attributes 2250 The hardware module MUST digitally sign a collection of attributes 2251 along with the firmware package load error report. Each attribute in 2252 the collection MUST be DER encoded [X.509-88]. The syntax for 2253 attributes is defined in [CMS], and it was repeated in section 2.2 2254 for convenience. 2256 Each of the attributes used with this profile has a single attribute 2257 value, even though the syntax is defined as a SET OF AttributeValue. 2258 There MUST be exactly one instance of AttributeValue present. 2260 The SignedAttributes syntax within signerInfo is defined as a SET OF 2261 Attributes. The SignedAttributes MUST include only one instance of 2262 any particular attribute. 2264 The hardware module MUST include the content-type and message-digest 2265 attributes. If the hardware module includes a real-time clock, then 2266 the hardware module SHOULD also include the signing-time attribute. 2267 The hardware module MAY include any other attribute that it deems 2268 appropriate. 2270 4.2.1 Content Type 2272 The hardware module MUST include a content-type attribute with the 2273 value of id-ct-firmwareLoadError (1.2.840.113549.1.9.16.1.18). 2274 Section 11.1 of [CMS] defines the content-type attribute. 2276 4.2.2 Message Digest 2278 The hardware module MUST include a message-digest attribute, having 2279 as its value the message digest of the FirmwarePackageLoadError 2280 content. Section 11.2 of [CMS] defines the message-digest attribute. 2282 4.2.3 Signing Time 2284 If the hardware module includes a real-time clock, then hardware 2285 module SHOULD include a signing-time attribute, specifying the time 2286 at which the firmware package load error report was generated. 2287 Section 11.3 of [CMS] defines the signing-time attribute. 2289 5 Hardware Module Name 2291 Support for firmware package load receipts, as discussed in section 2292 3, is OPTIONAL, and support for the firmware package load error 2293 reports, as discussed in section 4, is OPTIONAL. Hardware modules 2294 that support receipt or error report generation MUST have a unique 2295 serial number. Further, hardware modules that support signed receipt 2296 or error report generation MUST have a private signature key and a 2297 corresponding signature validation certificate [PROFILE] or its 2298 designator. The conventions for hardware module naming in the 2299 signature validation certificates are specified in this section. 2301 The hardware module vendor or a trusted third party MUST issue the 2302 signature validation certificate prior to deployment of the hardware 2303 module. The certificate is likely to be issued at the time of 2304 manufacture. The subject alternative name in this certificate 2305 identifies the hardware module. The subject distinguished name is 2306 empty, but a critical subject alternative name extension contains the 2307 hardware module name, using the otherName choice within the 2308 GeneralName structure. 2310 The hardware module name form is identified by the id-on- 2311 hardwareModuleName object identifier: 2313 id-on-hardwareModuleName OBJECT IDENTIFIER ::= { 2314 iso(1) identified-organization(3) dod(6) internet(1) security(5) 2315 mechanisms(5) pkix(7) on(8) 4 } 2317 A HardwareModuleName is composed of an object identifier and an octet 2318 string: 2320 HardwareModuleName ::= SEQUENCE { 2321 hwType OBJECT IDENTIFIER, 2322 hwSerialNum OCTET STRING } 2324 The fields of the HardwareModuleName type have the following 2325 meanings: 2327 hwType is an object identifier that identifies the type of hardware 2328 module. A unique object identifier names a hardware model and 2329 revision. 2331 hwSerialNum is the serial number of the hardware module. No 2332 particular structure is imposed on the serial number; it need not 2333 be an integer. However, the combination of the hwType and 2334 hwSerialNum uniquely identifies the hardware module. 2336 6 References 2338 This section provides normative and informative references. 2340 6.1 Normative References 2342 COMPRESS Gutmann, P. Compressed Data Content Type for 2343 Cryptographic Message Syntax (CMS). RFC 3274. 2344 June 2002. 2346 CMS Housley, R. Cryptographic Message Syntax. 2347 RFC 3852. July 2004. 2349 ESS Hoffman, P. Enhanced Security Services for S/MIME. 2350 RFC 2634. June 1999. 2352 PROFILE Housley, R., W. Polk, W. Ford, and D. Solo. Internet 2353 X.509 Public Key Infrastructure Certificate and 2354 Certificate Revocation List (CRL) Profile. RFC 3280. 2355 April 2002. 2357 SHA1 National Institute of Standards and Technology. 2358 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 2360 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 2361 Requirement Levels. RFC 2119. March 1997. 2363 UTF-8 Yergeau, F. UTF-8, a transformation format of ISO 10646. 2364 RFC 3629. November 2003. 2366 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 2367 Syntax Notation One (ASN.1). 1988. 2369 X.209-88 CCITT. Recommendation X.209: Specification of Basic 2370 Encoding Rules for Abstract Syntax Notation One (ASN.1). 2371 1988. 2373 X.509-88 CCITT. Recommendation X.509: The Directory - Authentication 2374 Framework. 1988. 2376 6.2 Informative References 2378 ACPROFILE Farrell, S., and R. Housley. An Internet Attribute 2379 Certificate Profile for Authorization. RFC 3281. 2380 April 2002. 2382 AES National Institute of Standards and Technology. 2383 FIPS Pub 197: Advanced Encryption Standard (AES). 2384 26 November 2001. 2386 DDJ Goldberg, I., and D. Wagner. "Randomness and the 2387 Netscape Browser." Dr. Dobb's Journal, January 1996. 2389 DPD&DPV Pinkas, D., and R. Housley. Delegated Path Validation 2390 and Delegated Path Discovery Protocol Requirements. 2391 RFC 3379. September 2002. 2393 OCSP Myers, M., R. Ankney, A. Malpani, S. Galperin, and 2394 C. Adams. X.509 Internet Public Key Infrastructure - 2395 Online Certificate Status Protocol (OCSP). RFC 2560. 2396 June 1999. 2398 PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 2399 Standard, Version 1.5. November 1993. 2401 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 2402 Recommendations for Security. RFC 1750. December 1994. 2404 SECREQMTS National Institute of Standards and Technology. 2405 FIPS Pub 140-2: Security Requirements for Cryptographic 2406 Modules. 25 May 2001. 2408 X.509-97 ITU-T. Recommendation X.509: The Directory - Authentication 2409 Framework. 1997. 2411 X.509-00 ITU-T. Recommendation X.509: The Directory - Authentication 2412 Framework. 2000. 2414 7 Security Considerations 2416 This document describes the use of the Cryptographic Message Syntax 2417 (CMS) to protect firmware packages; therefore, the security 2418 considerations discussed in [CMS] apply to this specification as 2419 well. 2421 The conventions specified in this document raise a few security 2422 considerations of their own. 2424 7.1 Cryptographic Keys and Algorithms 2426 Private signature keys must be protected. Compromise of the private 2427 key used to sign firmware packages permits unauthorized parties to 2428 generate firmware packages that are acceptable to hardware modules. 2429 Compromise of the hardware module private key allows unauthorized 2430 parties to generate signed firmware package load receipts and error 2431 reports. 2433 The firmware-decryption key must be protected. Compromise of the key 2434 may result in the disclosure of the firmware package to unauthorized 2435 parties. 2437 Cryptographic algorithms become weaker with time. As new 2438 cryptanalysis techniques are developed and computing performance 2439 improves, the work factor to break a particular cryptographic 2440 algorithm will be reduced. The ability to change the firmware 2441 package provides an opportunity to update or replace cryptographic 2442 algorithms. While this capability is desirable, cryptographic 2443 algorithm replacement can lead to interoperability failures. 2444 Therefore, the roll out of new cryptographic algorithms must be 2445 managed. Generally, the previous generation of cryptographic 2446 algorithms needs to be supported at the same time as their 2447 replacements to facilitate an orderly transition. 2449 7.2 Random Number Generation 2451 When firmware packages are encrypted, the source of the firmware 2452 package must randomly generate firmware-encryption keys. Also, the 2453 generation of public/private signature key pairs relies on a random 2454 numbers. The use of inadequate pseudo-random number generators 2455 (PRNGs) to generate cryptographic keys can result in little or no 2456 security. An attacker may find it much easier to reproduce the PRNG 2457 environment that produced the keys, searching the resulting small set 2458 of possibilities, rather than brute force searching the whole key 2459 space. The generation of quality random numbers is difficult. RFC 2460 1750 [RANDOM] offers important guidance in this area. 2462 7.3 Stale Firmware Package Version Number 2464 The firmware signer determines whether or not a stale version number 2465 is included. The policy of the firmware signer needs to consider 2466 many factors. Consider the flaw found by Ian Goldberg and David 2467 Wagner in the random number generator of the Netscape Browser in 1996 2468 [DDJ]. This flaw completely undermines confidentiality protection. 2469 A firmware signer might use the stale version number to ensure that 2470 upgraded hardware modules do not resume use of the flawed firmware. 2471 However, another firmware signer may not consider this an appropriate 2472 situation to employ the stale version number, preferring to delegate 2473 this decision to someone closer to the operation of the hardware 2474 module. Such a person is likely to be in a better position to 2475 evaluate whether other bugs introduced in the newer firmware package 2476 impose worse operational concerns than the confidentiality concern 2477 caused by the flawed random number generator. For example, a user 2478 who never uses the encryption feature of the flawed Netscape Browser 2479 will determine the most appropriate version to use without 2480 considering the random number flaw or its fix. 2482 The stale version number is especially useful when the security 2483 interests of the person choosing which firmware package version to 2484 load into a particular hardware module do not align with the security 2485 interests of the firmware package signer. For example, stale version 2486 numbers may be useful in hardware modules that provide digital rights 2487 management (DRM). Also, stale version numbers will be useful when 2488 the deployment organization (as opposed to the firmware package 2489 vendor) is the firmware signer. Further, stale version numbers will 2490 be useful for firmware packages that need to be trusted to implement 2491 organizational (as opposed to the deployment organization) security 2492 policy, regardless of whether the firmware signer is the deployment 2493 organization or the vendor. For example, hardware devices employed 2494 by the military will probably make use of stale version numbers. 2496 The use of a stale version number in a firmware package that employs 2497 the preferred firmware package name form cannot completely prevent 2498 subsequent use of the stale firmware package. Despite this 2499 shortcoming, the feature is included since it is useful in some 2500 important situations. By loading different types of firmware 2501 packages, each with their own stale firmware package version number 2502 until the internal storage for the stale version number is exceeded, 2503 the user can circumvent the mechanism. Consider a hardware module 2504 that has storage for two stale version numbers. Suppose that FWPKG-A 2505 version 3 is loaded, indicating that FWPKG-A version 2 is stale. The 2506 user can sequentially load the following: 2508 - FWPKG-B version 8, indicating that FWPKG-B version 4 is stale. 2509 (Note: The internal storage indicates that FWPKG-A version 2 2510 and FWPKG-B version 4 are stale.) 2512 - FWPKG-C version 5, indicating that FWPKG-C version 3 is stale. 2513 (Note: The internal storage indicates that FWPKG-B version 4 2514 and FWPKG-C version 3 are stale.) 2516 - FWPKG-A version 2. 2518 Since many hardware modules are expected to have very few firmware 2519 packages written for them, the stale firmware package version feature 2520 provides important protections. The amount of non-volatile storage 2521 that needs to be dedicated to saving firmware package identifiers and 2522 version numbers depends on the number of firmware packages that are 2523 likely to be developed for the hardware module. 2525 The use of legacy firmware package name form does not improve this 2526 situation. In fact, the legacy firmware package names are usually 2527 larger than an object identifier. Thus, comparable stale version 2528 protection requires more memory. 2530 A firmware signer can ensure that stale version numbers are honored 2531 by limiting the number of different types of firmware packages that 2532 are signed. If all of the hardware modules are able to store a stale 2533 version number for each of the different types of firmware package, 2534 then the hardware module will be able to provide the desired 2535 protection. This requires the firmware signer to have a deep 2536 understanding of all of the hardware modules that might accept the 2537 firmware package. 2539 7.4 Community Identifiers 2541 When a firmware package includes a community identifier, the 2542 confidence that the package is only used by the intended community 2543 depends on the mechanism used to configure community membership. 2545 This document does not specify a mechanism for the assignment of 2546 community membership to hardware modules, and the various 2547 alternatives have different security properties. Also, the authority 2548 that makes community identifier assignments to hardware modules might 2549 be different than the authority that generates firmware packages. 2551 8 IANA Considerations 2553 No IANA actions are needed. 2555 9 IPR Considerations 2557 By submitting this Internet-Draft, I certify that any applicable 2558 patent or other IPR claims of which I am aware have been disclosed, 2559 or will be disclosed, and any of which I become aware will be 2560 disclosed, in accordance with RFC 3668. 2562 The IETF takes no position regarding the validity or scope of any 2563 Intellectual Property Rights or other rights that might be claimed to 2564 pertain to the implementation or use of the technology described in 2565 this document or the extent to which any license under such rights 2566 might or might not be available; nor does it represent that it has 2567 made any independent effort to identify any such rights. Information 2568 on the procedures with respect to rights in RFC documents can be 2569 found in BCP 78 and BCP 79. 2571 Copies of IPR disclosures made to the IETF Secretariat and any 2572 assurances of licenses to be made available, or the result of an 2573 attempt made to obtain a general license or permission for the use of 2574 such proprietary rights by implementers or users of this 2575 specification can be obtained from the IETF on-line IPR repository at 2576 http://www.ietf.org/ipr. 2578 The IETF invites any interested party to bring to its attention any 2579 copyrights, patents or patent applications, or other proprietary 2580 rights that may cover technology that may be required to implement 2581 this standard. Please address the information to the IETF at ietf- 2582 ipr@ietf.org. 2584 10 Author Address 2586 Russell Housley 2587 Vigil Security, LLC 2588 918 Spring Knoll Drive 2589 Herndon, VA 20170 2590 USA 2592 housley@vigilsec.com 2594 Appendix A: ASN.1 Module 2596 The ASN.1 module contained in this appendix defines the structures 2597 that are needed to implement the CMS-based firmware package wrapper. 2598 It is expected to be used in conjunction with the ASN.1 modules in 2599 [CMS], [COMPRESS], and [PROFILE]. 2601 CMSFirmwareWrapper 2602 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 2603 pkcs-9(9) smime(16) modules(0) cms-firmware-wrap(22) } 2605 DEFINITIONS IMPLICIT TAGS ::= 2606 BEGIN 2608 IMPORTS 2609 EnvelopedData 2610 FROM CryptographicMessageSyntax -- [CMS] 2611 { iso(1) member-body(2) us(840) rsadsi(113549) 2612 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }; 2614 -- Firmware Package Content Type and Object Identifier 2616 id-ct-firmwarePackage OBJECT IDENTIFIER ::= { 2617 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2618 smime(16) ct(1) 16 } 2620 FirmwarePkgData ::= OCTET STRING 2621 -- Firmware Package Signed Attributes and Object Identifiers 2623 id-aa-firmwarePackageID OBJECT IDENTIFIER ::= { 2624 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2625 smime(16) aa(2) 35 } 2627 FirmwarePackageIdentifier ::= SEQUENCE { 2628 name PreferredOrLegacyPackageIdentifier, 2629 stale PreferredOrLegacyStalePackageIdentifier OPTIONAL } 2631 PreferredOrLegacyPackageIdentifier ::= CHOICE { 2632 preferred PreferredPackageIdentifier, 2633 legacy OCTET STRING } 2635 PreferredPackageIdentifier ::= SEQUENCE { 2636 fwPkgID OBJECT IDENTIFIER, 2637 verNum INTEGER (0..MAX) } 2639 PreferredOrLegacyStalePackageIdentifier ::= CHOICE { 2640 preferredStaleVerNum INTEGER (0..MAX), 2641 legacyStaleVersion OCTET STRING } 2643 id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= { 2644 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2645 smime(16) aa(2) 36 } 2647 TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER 2649 id-aa-decryptKeyID OBJECT IDENTIFIER ::= { 2650 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2651 smime(16) aa(2) 37 } 2653 DecryptKeyIdentifier ::= OCTET STRING 2655 id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= { 2656 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2657 smime(16) aa(2) 38 } 2659 ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER 2660 id-aa-implCompressAlgs OBJECT IDENTIFIER ::= { 2661 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2662 smime(16) aa(2) 43 } 2664 ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER 2666 id-aa-communityIdentifiers OBJECT IDENTIFIER ::= { 2667 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2668 smime(16) aa(2) 40 } 2670 CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier 2672 CommunityIdentifier ::= CHOICE { 2673 communityOID OBJECT IDENTIFIER, 2674 hwModuleList HardwareModules } 2676 HardwareModules ::= SEQUENCE { 2677 hwType OBJECT IDENTIFIER, 2678 hwSerialEntries SEQUENCE OF HardwareSerialEntry } 2680 HardwareSerialEntry ::= CHOICE { 2681 all NULL, 2683 single OCTET STRING, 2684 block SEQUENCE { 2685 low OCTET STRING, 2686 high OCTET STRING } } 2688 id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= { 2689 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2690 smime(16) aa(2) 42 } 2692 FirmwarePackageInfo ::= SEQUENCE { 2693 fwPkgType INTEGER OPTIONAL, 2694 dependencies SEQUENCE OF 2695 PreferredOrLegacyPackageIdentifier OPTIONAL } 2697 -- Firmware Package Unsigned Attributes and Object Identifiers 2699 id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= { 2700 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2701 smime(16) aa(2) 39 } 2703 WrappedFirmwareKey ::= EnvelopedData 2704 -- Firmware Package Load Receipt Content Type and Object Identifier 2706 id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= { 2707 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2708 smime(16) ct(1) 17 } 2710 FirmwarePackageLoadReceipt ::= SEQUENCE { 2711 version FWReceiptVersion DEFAULT v1, 2712 hwType OBJECT IDENTIFIER, 2713 hwSerialNum OCTET STRING, 2714 fwPkgName PreferredOrLegacyPackageIdentifier, 2715 trustAnchorKeyID OCTET STRING OPTIONAL, 2716 decryptKeyID [1] OCTET STRING OPTIONAL } 2718 FWReceiptVersion ::= INTEGER { v1(1) } 2720 -- Firmware Package Load Error Report Content Type 2721 -- and Object Identifier 2723 id-ct-firmwareLoadError OBJECT IDENTIFIER ::= { 2724 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2725 smime(16) ct(1) 18 } 2727 FirmwarePackageLoadError ::= SEQUENCE { 2728 version FWErrorVersion DEFAULT v1, 2729 hwType OBJECT IDENTIFIER, 2730 hwSerialNum OCTET STRING, 2731 errorCode FirmwarePackageLoadErrorCode, 2732 vendorErrorCode VendorLoadErrorCode OPTIONAL, 2733 fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL, 2734 config [1] SEQUENCE OF CurrentFWConfig OPTIONAL } 2736 FWErrorVersion ::= INTEGER { v1(1) } 2738 CurrentFWConfig ::= SEQUENCE { 2739 fwPkgType INTEGER OPTIONAL, 2740 fwPkgName PreferredOrLegacyPackageIdentifier } 2742 FirmwarePackageLoadErrorCode ::= ENUMERATED { 2743 decodeFailure (1), 2744 badContentInfo (2), 2745 badSignedData (3), 2746 badEncapContent (4), 2747 badCertificate (5), 2748 badSignerInfo (6), 2749 badSignedAttrs (7), 2750 badUnsignedAttrs (8), 2751 missingContent (9), 2752 noTrustAnchor (10), 2753 notAuthorized (11), 2754 badDigestAlgorithm (12), 2755 badSignatureAlgorithm (13), 2756 unsupportedKeySize (14), 2757 signatureFailure (15), 2758 contentTypeMismatch (16), 2759 badEncryptedData (17), 2760 unprotectedAttrsPresent (18), 2761 badEncryptContent (19), 2762 badEncryptAlgorithm (20), 2763 missingCiphertext (21), 2764 noDecryptKey (22), 2765 decryptFailure (23), 2766 badCompressAlgorithm (24), 2767 missingCompressedContent (25), 2768 decompressFailure (26), 2769 wrongHardware (27), 2770 stalePackage (28), 2771 notInCommunity (29), 2772 unsupportedPackageType (30), 2773 missingDependency (31), 2774 wrongDependencyVersion (32), 2775 insufficientMemory (33), 2776 badFirmware (34), 2777 unsupportedParameters (35), 2778 breaksDependency (36), 2779 otherError (99) } 2781 VendorLoadErrorCode ::= INTEGER 2783 -- Other Name syntax for Hardware Module Name 2785 id-on-hardwareModuleName OBJECT IDENTIFIER ::= { 2786 iso(1) identified-organization(3) dod(6) internet(1) security(5) 2787 mechanisms(5) pkix(7) on(8) 4 } 2789 HardwareModuleName ::= SEQUENCE { 2790 hwType OBJECT IDENTIFIER, 2791 hwSerialNum OCTET STRING } 2793 END 2795 Full Copyright Statement 2797 Copyright (C) The Internet Society (2005). This document is subject 2798 to the rights, licenses and restrictions contained in BCP 78, and 2799 except as set forth therein, the authors retain all their rights. 2801 This document and translations of it may be copied and furnished to 2802 others, and derivative works that comment on or otherwise explain it 2803 or assist in its implementation may be prepared, copied, published 2804 and distributed, in whole or in part, without restriction of any 2805 kind, provided that the above copyright notice and this paragraph are 2806 included on all such copies and derivative works. In addition, the 2807 ASN.1 module presented in Appendix A may be used in whole or in part 2808 without inclusion of the copyright notice. However, this document 2809 itself may not be modified in any way, such as by removing the 2810 copyright notice or references to the Internet Society or other 2811 Internet organizations, except as needed for the purpose of 2812 developing Internet standards in which case the procedures for 2813 copyrights defined in the Internet Standards process shall be 2814 followed, or as required to translate it into languages other than 2815 English. 2817 This document and the information contained herein are provided on an 2818 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2819 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2820 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2821 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2822 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2823 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.