idnits 2.17.1 draft-richardson-secdispatch-idevid-considerations-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 July 2020) is 1368 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) == Unused Reference: 'BCP14' is defined on line 826, but no explicit reference was found in the text == Unused Reference: 'I-D.richardson-anima-masa-considerations' is defined on line 850, but no explicit reference was found in the text == Unused Reference: 'RambusCryptoManager' is defined on line 913, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-moskowitz-ecdsa-pki-08 ** Downref: Normative reference to an Informational draft: draft-moskowitz-ecdsa-pki (ref. 'I-D.moskowitz-ecdsa-pki') -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802-1AR' == Outdated reference: A later version (-08) exists of draft-richardson-anima-masa-considerations-04 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-41 == Outdated reference: A later version (-08) exists of draft-richardson-rats-usecases-07 == Outdated reference: A later version (-16) exists of draft-ietf-suit-architecture-11 == Outdated reference: A later version (-06) exists of draft-ietf-emu-eap-noob-02 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-05 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-15 == Outdated reference: A later version (-08) exists of draft-bormann-lwig-7228bis-06 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-12 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track J. Yang 5 Expires: 28 January 2021 Huawei Technologies Co., Ltd. 6 27 July 2020 8 Security and Operational considerations for manufacturer installed keys 9 and anchors 10 draft-richardson-secdispatch-idevid-considerations-02 12 Abstract 14 This document provides a nomenclature to describe ways in which 15 manufacturers secure private keys and public trust anchors in 16 devices. 18 RFCEDITOR: please remove this paragraph. This work is occuring in 19 https://github.com/mcr/idevid-security-considerations 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 28 January 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Applicability Model . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. A reference manufacturing/boot process . . . . . . . . . 6 58 3. Types of Trust Anchors . . . . . . . . . . . . . . . . . . . 7 59 3.1. Secured First Boot Trust Anchor . . . . . . . . . . . . . 8 60 3.2. Software Update Trust Anchor . . . . . . . . . . . . . . 8 61 3.3. Trusted Application Manager anchor . . . . . . . . . . . 8 62 3.4. Public WebPKI anchors . . . . . . . . . . . . . . . . . . 9 63 3.5. DNSSEC root . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.6. What else? . . . . . . . . . . . . . . . . . . . . . . . 9 65 4. Types of Identities . . . . . . . . . . . . . . . . . . . . . 9 66 4.1. Manufacturer installed IDevID certificates . . . . . . . 10 67 4.1.1. Operational Considerations for Manufacturer IDevID 68 Public Key Infrastructure . . . . . . . . . . . . . . 10 69 4.1.2. Key Generation process . . . . . . . . . . . . . . . 11 70 5. Public Key Infrastructures (PKI) . . . . . . . . . . . . . . 14 71 5.1. Number of levels of certification authorities . . . . . . 14 72 5.2. Protection of CA private keys . . . . . . . . . . . . . . 15 73 5.3. Supporting provisioned anchors in devices . . . . . . . . 16 74 6. Evaluation Questions . . . . . . . . . . . . . . . . . . . . 16 75 6.1. Integrity and Privacy of on-device data . . . . . . . . . 16 76 6.2. Integrity and Privacy of device identify 77 infrastructure . . . . . . . . . . . . . . . . . . . . . 17 78 6.3. Integrity and Privacy of included trust anchors . . . . . 17 79 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 83 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 86 12.2. Informative References . . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 89 1. Introduction 91 An increasing number of protocols derive a significant part of their 92 security by using trust anchors that are installed by manufacturers. 93 Disclosure of the list of trust anchors does not usually cause a 94 problem, but changing them in any way does. This includes adding, 95 replacing or deleting anchors. 97 Many protocols also leverage manufacturer installed identities. 98 These identities are usually in the form of [ieee802-1AR] Initial 99 Device Identity certificates (IDevID). The identity has two 100 components: a private key that must remain under the strict control 101 of a trusted part of the device, and a public part (the certificate), 102 which (ignoring, for the moment, personal privacy concerns) may be 103 freely disclosed. 105 There also situations where identities which are tied up in the 106 provision of symmetric shared secret. A common example is the SIM 107 card ([_3GPP.51.011]), which now comes as a virtual SIM, but which is 108 usually not provisioned at the factory. The provision of an initial, 109 per-device default password also falls into the category of symmetric 110 shared secret. 112 It is further not unusual for many devices (particularly smartphones) 113 to also have one or more group identity keys. This is used in, for 114 instance, in [fidotechnote] to make claims about being a particular 115 model of phone (see [I-D.richardson-rats-usecases]). The keypair 116 that does this is loaded into large batches of phones for privacy 117 reasons. 119 The trust anchors are used for a variety of purposes. The following 120 uses are specifically called out: 122 * to validate the signature on a software update (as per 123 [I-D.ietf-suit-architecture]). 125 * to verify the end of a TLS Server Certificate, such as when 126 setting up an HTTPS connection. 128 * to verify the [RFC8366] format voucher that provides proof of an 129 ownership change 131 Device identity keys are used when performing enrollment requests (in 132 [I-D.ietf-anima-bootstrapping-keyinfra], and in some uses of 133 [I-D.ietf-emu-eap-noob]. The device identity certificate is also 134 used to sign Evidence by an Attesting Environment (see 135 [I-D.ietf-rats-architecture]). 137 These security artifacts are used to anchor other chains of 138 information: an EAT Claim as to the version of software/firmware 139 running on a device (XXX and [I-D.birkholz-suit-coswid-manifest]), an 140 EAT claim about legitimate network activity (via 141 [I-D.birkholz-rats-mud], or embedded in the IDevID in [RFC8520]). 142 Known software versions lead directly to vendor/distributor signed 143 Software Bill of Materials (SBOM), such as those described by 144 [I-D.ietf-sacm-coswid] and the NTIA/SBOM work [ntiasbom] and CISQ/OMG 145 SBOM work underway [cisqsbom]. 147 In order to manage risks and assess vulnerabilities in a Supply 148 Chain, it is necessary to determine a degree of trusthworthiness in 149 each device. A device may mislead audit systems as to its 150 provenance, about its software load or even about what kind of device 151 it is. (see [RFC7168] for a humourous example). In order to properly 152 assess the security of a Supply Chain it is necessary to understand 153 the kinds and severity of the threats which a device has been 154 designed to resist. To do this, it is necessary to understand the 155 ways in which the different trust anchors and identities are 156 initially provisioned, are protected, and are updated. 158 To do this, this document details the different trust anchors (TrA) 159 and identities (IDs) found in typical devices. The privacy and 160 integrity of the TAs and IDs is often provided by a different, 161 superior artifacts. This relationship is examined. 163 While many might desire to assign numerical values to different 164 mitigation techniques in order to be able to rank them, this document 165 does not attempt to do, as there are too many other (mostly human) 166 factors that would come into play. Such an effort is more properly 167 in the purvue of a formal ISO9001 process such as ISO14001. 169 1.1. Terminology 171 This document is not a standards track document, and it does not make 172 use of formal requirements language. 174 This section will be expanded to include needed terminology as 175 required. 177 The words Trust Anchor are contracted to TrA rather than TA, in order 178 not to confuse with [I-D.ietf-teep-architecture]'s "Trusted 179 Application". 181 This document defines a number of hyphenated terms, and they are 182 summarized here: 184 device-generated : a private or symmetric key which is generated on 185 the device 187 infrastructure-generated : a private or symmetric key which is 188 generated by some system, likely located at factory that built the 189 device 191 mechanically-installed : when a key or certificate is programmed 192 into flash by out-of-band mechanism like JTAG 194 mechanically-transfered : when a key or certificate is transfered 195 into a system via private interface, such as serial console, JTAG 196 managed mailbox, or other physically private interface 198 network-transfered : when a key or certificate is transfered into a 199 system using a network interface which would be available after 200 the device has shipped. This applies even if the network is 201 physically attached using a bed-of-nails. 203 device/infrastructure-co-generated : when a private or symmetric key 204 is derived from a secret previously synchronized between the 205 silicon vendor and the factory using a common algorithm. 207 2. Applicability Model 209 There is a wide variety of devices to which this analysis can apply. 210 (See [I-D.bormann-lwig-7228bis]) This document will use a J-group 211 class C13 as a sample. This class is sufficiently large to 212 experience complex issues among multiple CPUs, packages and operating 213 systems, but at the same time, small enough that this class is often 214 deployed in single-purpose IoT-like uses. Devices in this class 215 often have Secure Enclaves (such as the "Grapeboard"), and can 216 include silicon manufacturer controlled processors in the boot 217 process (the Raspberry PI boots under control of the GPU). 219 Almost all larger systems (servers, laptops, desktops) include a 220 Baseboard Management Controller (BMC), which ranges from a M-Group 221 Class 3 MCU, to a J-Group Class 10 CPU (see, for instance [openbmc] 222 which uses a Linux kernel and system inside the BMC). As the BMC 223 usually has complete access to the main CPU's memory, I/O hardware 224 and disk, the boot path security of such a system needs to be 225 understood first as being about the security of the BMC. 227 2.1. A reference manufacturing/boot process 229 In order to provide for immutability and privacy of the critical TANs 230 and IDs, many CPU manufacturers will provide for some kind of private 231 memory area which is only accessible when the CPU is in certain 232 priviledged states. See the Terminology section of 233 [I-D.ietf-teep-architecture], notably TEE, REE, and TAM, and also 234 section 4, Architecture. 236 The private memory that is important is usually non-volatile and 237 rather small. It may be located inside the CPU silicon die, or it 238 may be located externally. If the memory is external, then it is 239 usually encrypted by a hardware mechanism on the CPU, with only the 240 key kept inside the CPU. 242 The entire mechanism may be external to the CPU in the form of a 243 hardware-TPM module, or it may be entirely internal to the CPU in the 244 form of a firmware-TPM. It may use a custom interface to the rest of 245 the system, or it may implement the TPM 1.2 or TPM 2.0 246 specifications. Those details are important to performing a full 247 evaluation, but do not matter that to this model (see initial- 248 enclave-location below). 250 During the manufacturing process, once the components have been 251 soldered to the board, the system is usually put through a system- 252 level test. This is often done on as a "bed-of-nails" test 253 [BedOfNails], where the board has key points attached mechanically to 254 a test system. A [JTAG] process tests the System Under Test, and 255 then initializes some firmware into the still empty flash storage. 256 It is now common for a factory test image to be loaded first: this 257 image will include code to initialize the private memory key 258 described above, and will include a first-stage bootloader and some 259 kind of (primitive) Trusted Application Manager (TAM). Embedded in 260 the stage one bootloader will be a Trust Anchor that is able to 261 verify the second-stage bootloader image. 263 After the system has undergone testing, the factory test image is 264 erased, leaving the first-stage bootloader. One or more second-stage 265 bootloader images is installed. The production image may be 266 installed at that time, or if the second-stage bootloader is able to 267 install it over the network, it may be done that way instead. 269 There are many variations of the above process, and this section is 270 not attempting to be prescriptive, but to be provide enough 271 illustration to motivate subsequent terminology. 273 There process may be entirely automated, or it may be entirely driven 274 by humans working in the factory. 276 Or a combination of the above. 278 These steps may all occur on an access-controlled assembly line, or 279 the system boards may be shipped from one place to another (maybe 280 another country) before undergoing testing. 282 Some systems are intended to be shipped in a tamper-proof state, but 283 it is usually not desireable that bed-of-nails testing be possible 284 without tampering, so the initialization process is usually done 285 prior to rendering the system tamper-proof. 287 Quality control testing may be done prior to as well as after the 288 application of tamper-proofing, as systems which do not pass 289 inspection may be reworked to fix flaws, and this should ideally be 290 impossible once the system has been made tamper-proof. 292 3. Types of Trust Anchors 294 Trust Anchors are fundamentally public keys. They are used to 295 validate other digitally signed artifacts. Typically, these are 296 chains of PKIX certificates leading to an End-Entity certificate 297 (EE). 299 The chains are usually presented as part of an externally provided 300 object, with the term "externally" to be understood as being as close 301 as untrusted flash, to as far as objects retrieved over a network. 303 There is no requirement that there be any chain at all: the trust 304 anchor can be used to validate a signature over a target object 305 directly. 307 The trust anchors are often stored in the form of self-signed 308 certificates. The self-signature does not offer any cryptographic 309 assurange, but it does provide a form of error detection, providing 310 verification against non-malicious forms of data corruption. If 311 storage is at a premium (such as inside-CPU non-volatile storage) 312 then only the public key itself need to be stored. For a 256-bit 313 ECDSA key, this is 32-bytes of space. 315 When evaluating the degree of trust for each trust anchor there are 316 four aspects that need to be determined: 318 * can the trust anchor be replaced or modified? 320 * can additional trust anchors be added? 322 * can trust anchors be removed? 323 * how is the private key associated with the trust anchor stored? 325 The first three things are device specific properties of how the 326 integrity of the trust anchor is maintained. 328 The fourth property has nothing to do with the device, but has to do 329 with the reputation and care of the entity that maintains the private 330 key. 332 Different anchors have different purposes. 334 These are: 336 3.1. Secured First Boot Trust Anchor 338 This anchor is part of the first-stage boot loader, and it is used to 339 validate a second-stage bootloader which may be stored in external 340 flash. 342 3.2. Software Update Trust Anchor 344 This anchor is used to validate the main application (or operating 345 system) load for the device. 347 It can be stored in a number of places. First, it may be identical 348 to the Secure Boot Trust Anchor. 350 Second, it may be stored in the second-stage bootloader, and 351 therefore it's integrity is protected by the Secured First Boot Trust 352 Anchor. 354 Third, it may be stored in the application code itself, where the 355 application validates updates to the application directly (update in 356 place), or via a double-buffer arrangement. The initial (factory) 357 load of the application code initializes the trust arrangement. 359 In this situation the application code is not in a secured boot 360 situation, as the second-stage bootloader does not validate the 361 application/operating system before starting it, but it may still 362 provide measured boot mechanism. 364 3.3. Trusted Application Manager anchor 366 This anchor is part of a [I-D.ietf-teep-architecture] Trusted 367 Application Manager. Code which is signed by this anchor will be 368 given execution privileges as described by the manifest which 369 accompanies the code. This privilege may include updating anchors. 371 3.4. Public WebPKI anchors 373 These anchors are used to verify HTTPS certificates from web sites. 374 These anchors are typically distributed as part of desktop browsers, 375 and via desktop operating systems. 377 The exact set of these anchors is not precisely defined: it is 378 usually determined by the browser vendor (e.g., Mozilla, Google, 379 Apple, Safari, Microsoft), or the operating system vendor (e.g., 380 Apple, Google, Microsoft, Ubuntu). In most cases these vendors look 381 to the CA/Browser Forum ([CABFORUM]) for inclusion criteria. 383 3.5. DNSSEC root 385 This anchor is part of the DNS Security extensions. It provides an 386 anchor for securing DNS lookups. Secure DNS lookups may be important 387 in order to get access to software updates. This anchor is now 388 scheduled to change approximately every 3 years, with the new key 389 announced several years before it is used, making it possible to 390 embed a keys that will be valid for up to five years. 392 This trust anchor is typically part of the application/operating 393 system code and is usually updated by the manufacturer when they do 394 updates. However, a system which is connected to the Internet may 395 update the DNSSEC anchor itself through the mechanism described in 396 [RFC5011]. 398 There are concerns that there may be a chicken and egg situation for 399 devices have remained in a powered off state (or disconnected from 400 the Internet) for some period of years. That upon being reconnected, 401 that the device would be unable to do DNSSEC validation. This 402 failure would result in them being unable to obtain operating system 403 updates that would then include the updates to the DNSSEC key. 405 3.6. What else? 407 TBD? 409 4. Types of Identities 411 Identities are installed during manufacturing time for a variety of 412 purposes. 414 Identities require some private component. Asymmetric identities 415 (e.g., RSA, ECDSA, EdDSA systems) require a co-responding public 416 component, usually in the form of a certificate signed by a trusted 417 third party. 419 The process of making this coordinated key pair and then installing 420 it into the device is called identity provisioning. 422 4.1. Manufacturer installed IDevID certificates 424 [ieee802-1AR] defines a category of certificates that are to 425 installed by the manufacturer, which contain at the least, a device 426 unique serial number. 428 A number of protocols depend upon this certificate. 430 * [I-D.ietf-anima-bootstrapping-keyinfra] introduces a mechanism for 431 new devices (called pledges) to be onboarded into a network 432 without intervention from an expert operator. A number of derived 433 protocols such as {{I-D. 435 * [I-D.ietf-rats-architecture] depends upon a key provisioned into 436 the Attesting Environment to sign Evidence. 438 * [I-D.ietf-suit-architecture] may depend upon a key provisioned 439 into the device in order to decrypt software updates. 441 * TBD 443 4.1.1. Operational Considerations for Manufacturer IDevID Public Key 444 Infrastructure 446 The manufacturer has the responsability to provision a keypair into 447 each device as part of the manufacturing process. There are a 448 variety of mechanisms to accomplish this, which this document will 449 overview. 451 There are three fundamental ways to generate IDevID certificates for 452 devices: 454 1. generating a private key on the device, creating a Certificate 455 Signing Request (or equivalent), and then returning a certificate 456 to the device. 458 2. generating a private key outside the device, signing the 459 certificate, and the installing both into the device. 461 3. deriving the private key from a previously installed secret seed, 462 that is shared with only the manufacturer 464 There is a fourth situation where the IDevID is provided as part of a 465 Trusted Platform Module (TPM), in which case the TPM vendor may be 466 making the same tradeoffs. 468 The document [I-D.moskowitz-ecdsa-pki] provides some practical 469 instructions on setting up a reference implementation for ECDSA keys 470 using a three-tier mechanism. 472 This document recommends the use of ECDSA keys for the root and 473 intermediate CAs, but there may be operational reasons why an RSA 474 intermediate CA will be required for some legacy TPM equipment. 476 4.1.2. Key Generation process 478 4.1.2.1. On-device private key generation 480 Generating the key on-device has the advantage that the private key 481 never leaves the device. The disadvantage is that the device may not 482 have a verified random number generator. [factoringrsa] is an example 483 of this scenario! 485 There are a number of options of how to get the public key securely 486 from the device to the certification authority. 488 This transmission must be done in an integral manner, and must be 489 securely associated with the assigned serial number. The serial 490 number goes into the certificate, and the resulting certificate needs 491 to be loaded into the manufacturer's asset database. This asset 492 database needs to be shared with the MASA. 494 One way to do the transmission is during a factory Bed of Nails test 495 (see [BedOfNails]) or Boundary Scan. When done via a physical 496 connection like this, then this is referred to as a _device- 497 generated_ / _mechanically-transfered_ . 499 There are other ways that could be used where a certificate signing 500 request is sent over a special network channel when the device is 501 powered up in the factory. This is referered to as the _device- 502 generated_ / _network-transfered_ method. 504 Regardless of how the certificate signing request is sent from the 505 device to the factory, and the certificate is returned to the device, 506 a concern from production line managers is that the assembly line may 507 have to wait for the certification authority to respond with the 508 certificate. 510 After the key generation, the device needs to set a flag such that it 511 no longer generates a new key, or will accept a new IDevID via the 512 factory connection. This may be a software setting, or could be as 513 dramatic as blowing a fuse. 515 The risk is that if an attacker with physical access is able to put 516 the device back into an unconfigured mode, then the attacker may be 517 able to substitute a new certificate into the device. It is 518 difficult to construct a rational for doing this, unless the network 519 initialization also permits an attacker to load or replace trust 520 anchors at the same time. 522 Because the key is generated inside the device, it is assumed that 523 the device can never be convinced to disclose the private key. 525 4.1.2.2. Off-device private key generation 527 Generating the key off-device has the advantage that the randomness 528 of the private key can be better analyzed. As the private key is 529 available to the manufacturing infrastructure, the authenticity of 530 the public key is well known ahead of time. 532 If the device does not come with a serial number in silicon, then one 533 should be be assigned and placed into a certificate. The private key 534 and certificate could be programmed into the device along with the 535 initial bootloader firmware in a single step. 537 Aside from the the change of origin for the randomness, a major 538 advantage of this mechanism is that it can be done with a single 539 write to the flash. The entire firmware of the device, including 540 configuration of trust anchors and private keys can be loaded in a 541 single write pass. Given some pipelining of the generation of the 542 keys and the creation of certificates, it may be possible to install 543 unique identities without taking any additional time. 545 The major downside to generating the private key off-device is that 546 it could be seen by the manufacturing infrastructure. It could be 547 compromised by humans in the factory, or the equipment could be 548 compromised. The use of this method increases the value of attacking 549 the manufacturing infrastructure. 551 If keys are generated by the manufacturing plant, and are immediately 552 installed, but never stored, then the window in which an attacker can 553 gain access to the private key is immensely reduced. 555 As in the previous case, the transfer may be done via physical 556 interfaces such as bed-of-nails, giving the _infrastructure- 557 generated_ / _mechanically-transfered_ method. 559 There is also the possibility of having a _infrastructure-generated_ 560 / _network-transfered_ key. There is a support for "server- 561 generated" keys in [RFC7030], [I-D.gutmann-scep], and [RFC4210]. All 562 methods strongly recommend encrypting the private key for transfer. 564 This is difficult to comply with as there is not yet any private key 565 material in the device, so in many cases it will not be possible to 566 encrypt the private key. 568 4.1.2.3. Key setup based on 256-bit secret seed 570 A hybrid of the previous two methods leverages a symmetric key that 571 is often provided by a silicon vendor to OEM manufacturers. 573 Each CPU (or a Trusted Execution Environment 574 [I-D.ietf-teep-architecture], or a TPM) is provisioned at fabrication 575 time with a unique, secret seed, usually at least 256-bits in size. 577 This value is revealed to the OEM board manufacturer only via a 578 secure channel. Upon first boot, the system (probably within a TEE, 579 or within a TPM) will generate a key pair using the seed to 580 initialize a Pseudo-Random-Number-Generator (PRNG). The OEM, in a 581 separate system, will initialize the same PRNG and generate the same 582 key pair. The OEM then derives the public key part, signs it and 583 turns it into a certificate. The private part is then destroyed, 584 ideally never stored or seen by anyone. The certificate (being 585 public information) is placed into a database, in some cases it is 586 loaded by the device as its IDevID certificate, in other cases, it is 587 retrieved during the onboarding process based upon a unique serial 588 number asserted by the device. 590 This method appears to have all of the downsides of the previous two 591 methods: the device must correctly derive its own private key, and 592 the OEM has access to the private key, making it also vulnerable. 593 The secret seed must be created in a secure way and it must also be 594 communicated securely. 596 There are some advantages to the OEM however: the major one is that 597 the problem of securely communicating with the device is outsourced 598 to the silicon vendor. The private keys and certificates may be 599 calculated by the OEM asynchronously to the manufacturing process, 600 either done in batches in advance of actual manufacturing, or on 601 demand when an IDevID is demanded. Doing the processing in this way 602 permits the key derivation system to be completely disconnected from 603 any network, and requires placing very little trust in the system 604 assembly factory. Operational security such as often incorrectly 605 presented fictionalized stories of a "mainframe" system to which only 606 physical access is permitted begins to become realistic. That trust 607 has been replaced with a heightened trust placed in the silicon 608 (integrated circuit) fabrication facility. 610 The downsides of this method to the OEM are: they must be supplied by 611 a trusted silicon fabrication system, which must communicate the set 612 of secrets seeds to the OEM in batches, and they OEM must store and 613 care for these keys very carefully. There are some operational 614 advantages to keeping the secret seeds around in some form, as the 615 same secret seed could be used for other things. There are some 616 significant downsides to keeping that secret seed around. 618 5. Public Key Infrastructures (PKI) 620 [RFC5280] describes the format for certificates, and numerous 621 mechanisms for doing enrollment have been defined (including: EST: 622 [RFC7030], CMP: [RFC4210], SCEP [I-D.gutmann-scep]). 624 [RFC5280] provides mechanisms to deal with multi-level certification 625 authorities, but it is not always clear what operating rules apply. 627 PKIs can suffer two kinds of failures: 1. disclosure of a private 628 key. 2. loss of a private key. 630 A PKI which discloses one or more private certification authority 631 keys is no longer secure. An attacker can create new identities, and 632 forge certificates connecting existing identities to attacker 633 controlled public/private keypairs. This can permit the attacker to 634 impersonate the specific device. 636 If the PKI uses Certificate Revocation Lists (CRL)s, then an attacker 637 can also revoke existing identities. 639 In the other direction, a PKI which loses access to a private key can 640 no longer function. Existing identities may continue to function, 641 unless CRLs or OCSP is in use, in which case, the inability to sign a 642 fresh CRL or OCSP response will result in all identities becoming 643 invalid. 645 This section details some nomenclature about the structure of 646 certification authorities. 648 5.1. Number of levels of certification authorities 650 The certification authority (CA) starts with a Trust Anchor (TA). 651 This is counted as the zeroth level of the authority. 653 In the degenerate case of a self-signed certificate, then this a 654 level zero PKI. 656 .-------<-. |Issuer= X | | |Subject=X |-' '-------' 657 The Trust Anchor signs one or more certificates. When this first 658 level authority trusts only End-Entity (EE) certificates, then this 659 is a level one PKI. 661 .-------.<-. |Issuer= X | | |Subject=X |-' '-------' | -----\ v | . 662 ---EE---. .---EE---. |Issuer= X | |Issuer= 663 X | |Subject=Y1| |Subject=Y2| '-------' '-------' 665 When this first level authority signs intermediate certification 666 authorities, and those certification authorities sign End-Entity 667 certificates, then this is a level two PKI. 669 .-------.<-. |Issuer= X | | |Subject=X |-' '-------' | 670 ----------------\ v | .-------. .-------. |Issuer= X | |Issuer= 671 X | |Subject=Y1| |Subject=Y2| '-------' '-------' | ------\ | ------\ 672 V | V | .---EE---. .---EE---. .---EE---. .---EE---. |Issuer= 673 Y1| |Issuer= Y1| |Issuer= Y2| |Issuer= 674 Y2| |Subject=Z1| |Subject=Z1| |Subject=Z3| |Subject=Z4| '-------' 675 '-------' '-------' '-------' 677 In general, when arranged as a tree, with the End-Entity certificates 678 at the bottom, and the Trust Anchor at the top, then the level is 679 where the deepest EE certificates are, counting from zero. 681 It is quite common to have a two-level PKI, where the root of the CA 682 is stored in a Hardware Security Module, while the level one 683 intermediate CA is available online. 685 5.2. Protection of CA private keys 687 The private key for the certification authorities must be protected 688 from disclosure. The strongest protection is afforded by keeping 689 them in a offline device, passing Certificate Signing Requests (CSR)s 690 to the offline device by human process. 692 For examples of extreme measures, see [kskceremony]. There is 693 however a wide spectrum of needs, as exampled in [rootkeyceremony]. 694 The SAS70 audit standard is usually used as a basis for the Ceremony, 695 see [keyceremony2]. 697 This is inconvenient, and may involve latencies of days, possibly 698 even weeks to months if the offline device is kept in a locked 699 environment that requires multiple keys to be present. 701 There is therefore a tension between protection and convenience. 702 This is often accomplished by having some levels of the PKI be 703 offline, and some levels of the PKI be online. 705 There is usually a need to maintain backup copies of the critical 706 keys. It is often appropriate to use secret splitting technology 707 such as Shamir Secret Sharing among a number of parties [shamir79] 708 This mechanism can be setup such that some threshold k (less than the 709 total n) of shares are needed in order to recover the secret. 711 5.3. Supporting provisioned anchors in devices 713 IDevID-type Identity (or Birth) Certificates which are provisioned 714 into devices need to be signed by a certification authority 715 maintained by the manufacturer. The manufacturer needs to maintain 716 availability of this PKI. 718 Trust anchors which are provisioned in the devices will have 719 corresponding private keys maintained by the manufacturer. The trust 720 anchors will often anchor a PKI which is going to be used for a 721 particular purpose. There will be End-Entity (EE) certificates of 722 this PKI which will be used to sign particular artifacts (such as 723 software updates), or communications protocols (such as TLS 724 connections). The private key associated with these EE certificates 725 are not stored in the device, but are maintained by the manufacturer. 726 These need even more care than the private keys stored in the 727 devices, as compromise of the software update key compromises all of 728 the devices, not just a single device. 730 6. Evaluation Questions 732 This section recaps the set of questions that may need to be 733 answered. This document does not assign valuation to the answers. 735 6.1. Integrity and Privacy of on-device data 737 initial-enclave-location : Is the location of the initial software 738 trust anchor internal to the CPU package? 740 initial-enclave-integrity-key : If the first-stage bootloader is 741 external to the CPU, and it is integrity protected, where is the 742 key used to check the integrity? 744 initial-enclave-privacy-key : If the first-stage data is external to 745 the CPU, is it encrypted? 747 first-stage-initialization : The number of people involved in the 748 first stage initialization. An entirely automated system would 749 have a number zero. A factory with three 8 hour shifts might have 750 a number that is a multiple of three. A system with humans 751 involved may be subject to bribery attacks, while a system with no 752 humans may be subject to attacks on the system which are hard to 753 notice. 755 first-second-stage-gap : If a board is initialized with a first- 756 stage bootloader in one location (factory), and then shipped to 757 another location, there may situations where the device can not be 758 locked down until the second step. 760 6.2. Integrity and Privacy of device identify infrastructure 762 For IDevID provisioning, which includes a private key and matching 763 certificate installed into the device, the associated public key 764 infrastructure that anchors this identity must be maintained by the 765 manufacturer. 767 identity-pki-level : how deep are the IDevID certificates that are 768 issued? 770 identity-time-limits-per-intermediate : how long is each 771 intermediate CA maintained before before a new intermediate CA key 772 is generated? There may be no time limit, only a device count 773 limit. 775 identity-number-per-intermediate : how many identities are signed by 776 a particular intermediate CA before it is retired? There may be 777 no numeric limit, only a time limit. 779 identity-anchor-storage : how is the root CA key stored? How many 780 people are needed to recover it? 782 6.3. Integrity and Privacy of included trust anchors 784 For each trust anchor (public key) stored in the device, there will 785 be an associated PKI. For each of those PKI the following questions 786 need to be answered. 788 pki-level : how deep is the EE that will be evaluated 790 pki-level-locked : (a boolean) is the level where the EE cert will 791 be found locked by the device, or can levels be added or deleted 792 by the PKI operator without code changes to the device. 794 pki-breadth : how many different EE certificates exist in this PKI 795 pki-lock-policy : can any EE certificate be used with this trust 796 anchor to sign? Or, is there some kind of policy OID or Subject 797 restriction? Are specific intermediate CAs needed that lead to 798 the EE? 800 pki-anchor-storage: how is the root CA stored? How many people are 801 needed to recover it? 803 7. Privacy Considerations 805 many yet to be detailed 807 8. Security Considerations 809 This entire document is a security considerations. 811 9. IANA Considerations 813 This document makes no IANA requests. 815 10. Acknowledgements 817 Robert Martin of MITRE provides some guidance about citing the SBOM 818 efforts. 820 11. Changelog 822 12. References 824 12.1. Normative References 826 [BCP14] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 827 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 828 May 2017, . 830 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 831 Housley, R., and W. Polk, "Internet X.509 Public Key 832 Infrastructure Certificate and Certificate Revocation List 833 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 834 . 836 [I-D.moskowitz-ecdsa-pki] 837 Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson, 838 "Guide for building an ECC pki", Work in Progress, 839 Internet-Draft, draft-moskowitz-ecdsa-pki-08, 14 February 840 2020, . 843 [ieee802-1AR] 844 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 845 2009, . 848 12.2. Informative References 850 [I-D.richardson-anima-masa-considerations] 851 Richardson, M. and W. Pan, "Operatonal Considerations for 852 Voucher infrastructure for BRSKI MASA", Work in Progress, 853 Internet-Draft, draft-richardson-anima-masa- 854 considerations-04, 9 June 2020, . 858 [I-D.ietf-anima-bootstrapping-keyinfra] 859 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 860 and K. Watsen, "Bootstrapping Remote Secure Key 861 Infrastructures (BRSKI)", Work in Progress, Internet- 862 Draft, draft-ietf-anima-bootstrapping-keyinfra-41, 8 April 863 2020, . 866 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 867 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 868 September 2007, . 870 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 871 "A Voucher Artifact for Bootstrapping Protocols", 872 RFC 8366, DOI 10.17487/RFC8366, May 2018, 873 . 875 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 876 "Enrollment over Secure Transport", RFC 7030, 877 DOI 10.17487/RFC7030, October 2013, 878 . 880 [I-D.gutmann-scep] 881 Gutmann, P., "Simple Certificate Enrolment Protocol", Work 882 in Progress, Internet-Draft, draft-gutmann-scep-16, 27 883 March 2020, . 886 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 887 "Internet X.509 Public Key Infrastructure Certificate 888 Management Protocol (CMP)", RFC 4210, 889 DOI 10.17487/RFC4210, September 2005, 890 . 892 [_3GPP.51.011] 893 3GPP, "Specification of the Subscriber Identity Module - 894 Mobile Equipment (SIM-ME) interface", 3GPP TS 51.011 895 4.15.0, 15 June 2005, 896 . 898 [BedOfNails] 899 Wikipedia, ., "Bed of nails tester", July 2020, 900 . 903 [pelionfcu] 904 ARM Pelion, "Factory provisioning overview", 28 June 2020, 905 . 908 [factoringrsa] 909 "Factoring RSA keys from certified smart cards: 910 Coppersmith in the wild", 16 September 2013, 911 . 913 [RambusCryptoManager] 914 Qualcomm press release, "Qualcomm Licenses Rambus 915 CryptoManager Key and Feature Management Security 916 Solution", 2014, . 920 [kskceremony] 921 Verisign, "DNSSEC Practice Statement for the Root Zone ZSK 922 Operator", 2017, . 925 [rootkeyceremony] 926 Community, "Root Key Ceremony, Cryptography Wiki", April 927 2020, 928 . 930 [keyceremony2] 931 Digi-Sign, "SAS 70 Key Ceremony", April 2020, 932 . 935 [shamir79] Shamir, A., "How to share a secret.", 1979, 936 . 939 [nistsp800-57] 940 NIST, "SP 800-57 Part 1 Rev. 4 Recommendation for Key 941 Management, Part 1: General", 1 January 2016, 942 . 945 [fidotechnote] 946 FIDO Alliance, ., "FIDO TechNotes: The Truth about 947 Attestation", July 2018, . 950 [ntiasbom] NTIA, ., "NTIA Software Compoment Transparency", n.d., 951 . 953 [cisqsbom] CISQ/Object Management Group, ., "TOOL-TO-TOOL SOFTWARE 954 BILL OF MATERIALS EXCHANGE", July 2020, . 957 [openbmc] Linux Foundation/OpenBMC Group, ., "Defining a Standard 958 Baseboard Management Controller Firmware Stack", July 959 2020, . 961 [JTAG] IEEE Standard, ., "1149.7-2009 - IEEE Standard for 962 Reduced-Pin and Enhanced-Functionality Test Access Port 963 and Boundary-Scan Architecture", 2009, 964 . 966 [rootkeyrollover] 967 ICANN, ., "Proposal for Future Root Zone KSK Rollovers", 968 2019, . 971 [CABFORUM] CA/Browser Forum, ., "CA/Browser Forum Baseline 972 Requirements for the Issuance and Management of Publicly- 973 Trusted Certificates, v.1.2.2", October 2014, 974 . 976 [I-D.richardson-rats-usecases] 977 Richardson, M., Wallace, C., and W. Pan, "Use cases for 978 Remote Attestation common encodings", Work in Progress, 979 Internet-Draft, draft-richardson-rats-usecases-07, 9 March 980 2020, . 983 [I-D.ietf-suit-architecture] 984 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 985 Firmware Update Architecture for Internet of Things", Work 986 in Progress, Internet-Draft, draft-ietf-suit-architecture- 987 11, 27 May 2020, . 990 [I-D.ietf-emu-eap-noob] 991 Aura, T. and M. Sethi, "Nimble out-of-band authentication 992 for EAP (EAP-NOOB)", Work in Progress, Internet-Draft, 993 draft-ietf-emu-eap-noob-02, 12 July 2020, 994 . 997 [I-D.ietf-rats-architecture] 998 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 999 W. Pan, "Remote Attestation Procedures Architecture", Work 1000 in Progress, Internet-Draft, draft-ietf-rats-architecture- 1001 05, 10 July 2020, . 1004 [I-D.birkholz-suit-coswid-manifest] 1005 Birkholz, H., "A SUIT Manifest Extension for Concise 1006 Software Identifiers", Work in Progress, Internet-Draft, 1007 draft-birkholz-suit-coswid-manifest-00, 17 July 2018, 1008 . 1011 [I-D.birkholz-rats-mud] 1012 Birkholz, H., "MUD-Based RATS Resources Discovery", Work 1013 in Progress, Internet-Draft, draft-birkholz-rats-mud-00, 9 1014 March 2020, . 1017 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 1018 Description Specification", RFC 8520, 1019 DOI 10.17487/RFC8520, March 2019, 1020 . 1022 [I-D.ietf-sacm-coswid] 1023 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 1024 Waltermire, "Concise Software Identification Tags", Work 1025 in Progress, Internet-Draft, draft-ietf-sacm-coswid-15, 1 1026 May 2020, . 1029 [RFC7168] Nazar, I., "The Hyper Text Coffee Pot Control Protocol for 1030 Tea Efflux Appliances (HTCPCP-TEA)", RFC 7168, 1031 DOI 10.17487/RFC7168, April 2014, 1032 . 1034 [I-D.bormann-lwig-7228bis] 1035 Bormann, C., Ersue, M., Keranen, A., and C. Gomez, 1036 "Terminology for Constrained-Node Networks", Work in 1037 Progress, Internet-Draft, draft-bormann-lwig-7228bis-06, 9 1038 March 2020, . 1041 [I-D.ietf-teep-architecture] 1042 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 1043 "Trusted Execution Environment Provisioning (TEEP) 1044 Architecture", Work in Progress, Internet-Draft, draft- 1045 ietf-teep-architecture-12, 13 July 2020, 1046 . 1049 Authors' Addresses 1051 Michael Richardson 1052 Sandelman Software Works 1054 Email: mcr+ietf@sandelman.ca 1056 Jie Yang 1057 Huawei Technologies Co., Ltd. 1059 Email: jay.yang@huawei.com