idnits 2.17.1 draft-richardson-secdispatch-idevid-considerations-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (10 June 2020) is 1416 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: 'RFC8174' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'RambusCryptoManager' is defined on line 354, 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-03 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-41 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-08 Summary: 1 error (**), 0 flaws (~~), 8 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 W. Pan 5 Expires: 12 December 2020 Huawei Technologies 6 10 June 2020 8 Security and Operational considerations for manufacturer generated 9 IDevID 10 draft-richardson-secdispatch-idevid-considerations-00 12 Abstract 14 This document provides a number of operational modes that a 15 manufacturer of devices that include IEEE 802.1AR IDevID certificates 16 may choose from. Different ways of generating and signing the needed 17 keypairs are detailed, and the security tradeoffs of each method are 18 considered. This document provides a nomenclature for each mode. 20 IDevID certificates are used in ANIMA's BRSKI Manufacturer Authorized 21 Signing Authority (MASA) process. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 12 December 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Operational Considerations for Manufacturer IDevID Public Key 58 Infrastructure . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Key Generation process . . . . . . . . . . . . . . . . . 3 60 2.1.1. On-device private key generation . . . . . . . . . . 3 61 2.1.2. Off-device private key generation . . . . . . . . . . 4 62 2.1.3. Key setup based on 256-bit secret seed . . . . . . . 5 63 2.2. Public Key infrastructure for IDevID . . . . . . . . . . 6 64 3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 8.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 [I-D.ietf-anima-bootstrapping-keyinfra] introduces a mechanism for 77 new devices (called pledges) to be onboarded into a network without 78 intervention from an expert operator. 80 This mechanism leverages the pre-existing relationship between a 81 device and the manufacturer that built the device. There are two 82 aspects to this relationship: the provision of an identity for the 83 device by the manufacturer (the IDevID), and a mechanism which 84 convinces the device to trust the new owner (the [RFC8366] voucher). 86 This document is about the first part: where the device becomes 87 trusted by a network operator through a manufacturer provided trust 88 anchor. A second document, 89 [I-D.richardson-anima-masa-considerations] deals with the trust 90 anchors needed to establish the device to operator trust 91 relationship. 93 The operator to device trust relationship is in the form of an 94 [ieee802-1AR] certificate that is installed at manufacturing time in 95 the device. 97 2. Operational Considerations for Manufacturer IDevID Public Key 98 Infrastructure 100 The manufacturer has the responsability to provision a keypair into 101 each device as part of the manufacturing process. There are a 102 variety of mechanisms to accomplish this, which this document will 103 overview. 105 There are three fundamental ways to generate IDevID certificates for 106 devices: 108 1) generating a private key on the device, creating a Certificate 109 Signing Request (or equivalent), and then returning a certificate to 110 the device. 112 2) generating a private key outside the device, signing the 113 certificate, and the installing both into the device. 115 3) deriving the private key from a previously installed secret seed, 116 that is shared with only the manufacturer 118 There is a fourth situation where the IDevID is provided as part of a 119 Trusted Platform Module (TPM), in which case the TPM vendor may be 120 making the same tradeoffs. Or the mechanisms to install the 121 certificate into the TPM will use TPM APIs. 123 The document [I-D.moskowitz-ecdsa-pki] provides some practical 124 instructions on setting up a reference implementation for ECDSA keys 125 using a three-tier mechanism. This document recommends the use of 126 ECDSA keys for the root and intermediate CAs, but there may be 127 operational reasons why an RSA intermediate CA will be required for 128 some legacy TPM equipment. 130 2.1. Key Generation process 132 2.1.1. On-device private key generation 134 Generating the key on-device has the advantage that the private key 135 never leaves the device. The disadvantage is that the device may not 136 have a verified random number generator. 138 There are a number of options of how to get the public key securely 139 from the device to the certification authority. This transmission 140 must be done in an integral manner, and must be securely associated 141 with the assigned serial number. The serial number goes into the 142 certificate, and the resulting certificate needs to be loaded into 143 the manufacturer's asset database. This asset database needs to be 144 shared with the MASA. 146 One way to do the transmission is during a manufacturing during a Bed 147 of Nails (see [BedOfNails]) or Boundary Scan. There are other ways 148 that could be used where a certificate signing request is sent over a 149 special network channel when the device is powered up in the factory. 150 After the key generation, the device needs to set a flag such that it 151 no longer generates a new key, or will accept a new IDevID via the 152 factory connection. This may be a software setting, or could be as 153 dramatic as blowing a fuse. 155 There may be risks with this method if an attacker with physical 156 access is able to put the device back into an unconfigured mode, 157 particularly if this may permit the attacker to get access to the 158 private key material. When done on a single device, such an attack 159 may be able to replace the IDevID with one signed by another 160 manufacturer. That does not result in a risk of counterfeit devices. 161 An attack that is able to extract the private key could clone the 162 device. 164 2.1.2. Off-device private key generation 166 Generating the key off-device has the advantage that the randomness 167 of the private key can be better analyzed. As the private key is 168 available to the manufacturing infrastructure, the authenticity of 169 the public key is well known ahead of time. If the device does not 170 come with a serial number in silicon, then one should be be assigned 171 and placed into a certificate. The private key and certificate could 172 be programmed into the device along with the initial bootloader 173 firmware in a single step. 175 The major downside to generating the private key off-device is that 176 it could be seen by the manufacturing infrastructure. This makes the 177 manufacturing infrastructure a high-value attack target, so a 178 mechanism is needed to keep the private key secure within the 179 manufacturing process. 181 Encrypting the private key would solve this, but then the symmetric 182 key would need to be shared with the device, which is back to the 183 original problem. 185 If keys are generated by the manufacturing plant, and are immediately 186 installed, but never stored, then the window in which an attacker can 187 gain access to the private key is immensely reduced. 189 2.1.3. Key setup based on 256-bit secret seed 191 A hybrid of the previous two methods leverages a symmetric key that 192 is often provided by a silicon vendor to OEM manufacturers. Each CPU 193 (or a Trusted Execution Environment [I-D.ietf-teep-architecture], or 194 a TPM) is provisioned at fabrication time with a unique, secret seed, 195 usually at least 256-bits in size. 197 This value is revealed to the OEM board manufacturer only via a 198 secure channel. Upon first boot, the system (probably within a TEE, 199 or within a TPM) will generate a key pair using the seed to 200 initialize a Pseudo-Random-Number-Generator (PRNG). The OEM, in a 201 separate system, will initialize the same PRNG and generate the same 202 key pair. The OEM then derives the public key part, signs it and 203 turns it into a certificate. The private part is then destroyed, 204 ideally never stored or seen by anyone. The certificate (being 205 public information) is placed into a database, in some cases it is 206 loaded by the device as its IDevID certificate, in other cases, it is 207 retrieved during the onboarding process based upon a unique serial 208 number asserted by the device. 210 This method appears to have all of the downsides of the previous two 211 methods: the device must correctly derive its own private key, and 212 the OEM has access to the private key, making it also vulnerable. 213 The secret seed must be created in a secure way and it must also be 214 communicated securely. 216 There are some advantages to the OEM however: the major one is that 217 the problem of securely communicating with the device is outsourced 218 to the silicon vendor. The private keys and certificates may be 219 calculated by the OEM asynchronously to the manufacturing process, 220 either done in batches in advance of actual manufacturing, or on 221 demand when an IDevID is demanded. Doing the processing in this way 222 permits the key derivation system to be completely disconnected from 223 any network, and requires placing very little trust in the system 224 assembly factory. Operational security such as often incorrectly 225 presented fictionalized stories of a "mainframe" system to which only 226 physical access is permitted begins to become realistic. That trust 227 has been replaced with a heightened trust placed in the silicon 228 (integrated circuit) fabrication facility. 230 The downsides of this method to the OEM are: they must be supplied by 231 a trusted silicon fabrication system, which must communicate the set 232 of secrets seeds to the OEM in batches, and they OEM must store and 233 care for these keys very carefully. There are some operational 234 advantages to keeping the secret seeds around in some form, as the 235 same secret seed could be used for other things. There are some 236 significant downsides to keeping that secret seed around. 238 2.2. Public Key infrastructure for IDevID 240 A three-tier PKI infrastructure is appropriate. This entails having 241 a root CA created with the key kept offline, and a number of 242 intermediate CAs that have online keys that issue "day-to-day" 243 certificates. 245 The root private key should be kept offline, quite probably in a 246 Hardware Security Module if financially feasible. If not, then it 247 should be secret-split across seven to nine people, with a threshold 248 of four to five people. The split secrets should be kept in 249 geographically diverse places if the manufacturer has operations in 250 multiple places. For examples of extreme measures, see 251 [kskceremony]. There is however a wide spectrum of needs, as 252 exampled in [rootkeyceremony]. The SAS70 audit standard is usually 253 used as a basis for the Ceremony, see [keyceremony2]. 255 Ongoing access to the root-CA is important, but not as critical as 256 access to the MASA key. 258 The root CA is then used to sign a number of intermediate entities. 259 If manufacturing occurs in multiple factories, then an intermediate 260 CA for each factory is appropriate. It is also reasonable to use 261 different intermediate CAs for different product lines. It may also 262 be valuable to split IDevID certificates across intermediate CAs in a 263 round-robin fashion for products with high volumes. 265 Cycling the intermediate CAs after a period of a few months or so is 266 a quite reasonable strategy. The intermediate CAs private key may be 267 destroyed after it signed some number of IDevIDs, and a new key 268 generated. The IDevID certificates have very long (ideally infinite) 269 validity lifetimes for reasons that [ieee802-1AR] explains. The 270 intermediate CA will have a private key, likely kept online, which is 271 used to sign each generated IDevID. Once the IDevID are created, the 272 private key is no longer needed and can either be destroyed, or taken 273 offline. In other CAs, the intermediate CA's private key (or another 274 designated key) is often needed to sign OCSP [RFC6960] or CRLS 275 [RFC5280]. As the IDevID process does not in general support 276 revocation, keeping such keys online is not necessary. {EDIT NOTE: 277 REVIEW of this NEEDED} 279 The intermediate CA certificate SHOULD be signed by the root-CA with 280 indefinite (notAfter: 99991231) duration as well. 282 In all cases the serialNumber embedded in the certificate must be 283 unique across all products produced by the manufacturer. This 284 suggests some amount of structure to the serialNumber, such that 285 different intermediate CAs do not need to coordinate when issuing 286 certificates. 288 3. Privacy Considerations 290 many yet to be detailed 292 4. Security Considerations 294 This entire document is a security considerations. 296 5. IANA Considerations 298 This document makes no IANA requests. 300 6. Acknowledgements 302 Hello. 304 7. Changelog 306 8. References 308 8.1. Normative References 310 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 311 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 312 May 2017, . 314 [I-D.moskowitz-ecdsa-pki] 315 Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson, 316 "Guide for building an ECC pki", Work in Progress, 317 Internet-Draft, draft-moskowitz-ecdsa-pki-08, 14 February 318 2020, . 321 [ieee802-1AR] 322 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 323 2009, . 326 8.2. Informative References 328 [I-D.richardson-anima-masa-considerations] 329 Richardson, M. and W. Pan, "Operational Considerations for 330 Manufacturer Authorized Signing Authority", Work in 331 Progress, Internet-Draft, draft-richardson-anima-masa- 332 considerations-03, 9 March 2020, . 336 [I-D.ietf-anima-bootstrapping-keyinfra] 337 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 338 and K. Watsen, "Bootstrapping Remote Secure Key 339 Infrastructures (BRSKI)", Work in Progress, Internet- 340 Draft, draft-ietf-anima-bootstrapping-keyinfra-41, 8 April 341 2020, . 344 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 345 "A Voucher Artifact for Bootstrapping Protocols", 346 RFC 8366, DOI 10.17487/RFC8366, May 2018, 347 . 349 [BedOfNails] 350 Wikipedia, "In-circuit test", 2019, 351 . 354 [RambusCryptoManager] 355 Qualcomm press release, "Qualcomm Licenses Rambus 356 CryptoManager Key and Feature Management Security 357 Solution", 2014, . 361 [kskceremony] 362 Verisign, "DNSSEC Practice Statement for the Root Zone ZSK 363 Operator", 2017, . 366 [rootkeyceremony] 367 Community, "Root Key Ceremony, Cryptography Wiki", April 368 2020, 369 . 371 [keyceremony2] 372 Digi-Sign, "SAS 70 Key Ceremony", April 2020, 373 . 376 [nistsp800-57] 377 NIST, "SP 800-57 Part 1 Rev. 4 Recommendation for Key 378 Management, Part 1: General", 1 January 2016, 379 . 382 [I-D.ietf-teep-architecture] 383 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 384 "Trusted Execution Environment Provisioning (TEEP) 385 Architecture", Work in Progress, Internet-Draft, draft- 386 ietf-teep-architecture-08, 4 April 2020, 387 . 390 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 391 Galperin, S., and C. Adams, "X.509 Internet Public Key 392 Infrastructure Online Certificate Status Protocol - OCSP", 393 RFC 6960, DOI 10.17487/RFC6960, June 2013, 394 . 396 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 397 Housley, R., and W. Polk, "Internet X.509 Public Key 398 Infrastructure Certificate and Certificate Revocation List 399 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 400 . 402 Authors' Addresses 404 Michael Richardson 405 Sandelman Software Works 407 Email: mcr+ietf@sandelman.ca 409 Wei Pan 410 Huawei Technologies 412 Email: william.panwei@huawei.com