| Internet-Draft | IDevID Considerations | June 2020 |
| Richardson & Pan | Expires 12 December 2020 | [Page] |
This document provides a number of operational modes that a manufacturer of devices that include IEEE 802.1AR IDevID certificates may choose from. Different ways of generating and signing the needed keypairs are detailed, and the security tradeoffs of each method are considered. This document provides a nomenclature for each mode.¶
IDevID certificates are used in ANIMA's BRSKI Manufacturer Authorized Signing Authority (MASA) process.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 12 December 2020.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
[I-D.ietf-anima-bootstrapping-keyinfra] introduces a mechanism for new devices (called pledges) to be onboarded into a network without intervention from an expert operator.¶
This mechanism leverages the pre-existing relationship between a device and the manufacturer that built the device. There are two aspects to this relationship: the provision of an identity for the device by the manufacturer (the IDevID), and a mechanism which convinces the device to trust the new owner (the [RFC8366] voucher).¶
This document is about the first part: where the device becomes trusted by a network operator through a manufacturer provided trust anchor. A second document, [I-D.richardson-anima-masa-considerations] deals with the trust anchors needed to establish the device to operator trust relationship.¶
The operator to device trust relationship is in the form of an [ieee802-1AR] certificate that is installed at manufacturing time in the device.¶
The manufacturer has the responsability to provision a keypair into each device as part of the manufacturing process. There are a variety of mechanisms to accomplish this, which this document will overview.¶
There are three fundamental ways to generate IDevID certificates for devices:¶
1) generating a private key on the device, creating a Certificate Signing Request (or equivalent), and then returning a certificate to the device.¶
2) generating a private key outside the device, signing the certificate, and the installing both into the device.¶
3) deriving the private key from a previously installed secret seed, that is shared with only the manufacturer¶
There is a fourth situation where the IDevID is provided as part of a Trusted Platform Module (TPM), in which case the TPM vendor may be making the same tradeoffs. Or the mechanisms to install the certificate into the TPM will use TPM APIs.¶
The document [I-D.moskowitz-ecdsa-pki] provides some practical instructions on setting up a reference implementation for ECDSA keys using a three-tier mechanism. This document recommends the use of ECDSA keys for the root and intermediate CAs, but there may be operational reasons why an RSA intermediate CA will be required for some legacy TPM equipment.¶
Generating the key on-device has the advantage that the private key never leaves the device. The disadvantage is that the device may not have a verified random number generator.¶
There are a number of options of how to get the public key securely from the device to the certification authority. This transmission must be done in an integral manner, and must be securely associated with the assigned serial number. The serial number goes into the certificate, and the resulting certificate needs to be loaded into the manufacturer's asset database. This asset database needs to be shared with the MASA.¶
One way to do the transmission is during a manufacturing during a Bed of Nails (see [BedOfNails]) or Boundary Scan. There are other ways that could be used where a certificate signing request is sent over a special network channel when the device is powered up in the factory. After the key generation, the device needs to set a flag such that it no longer generates a new key, or will accept a new IDevID via the factory connection. This may be a software setting, or could be as dramatic as blowing a fuse.¶
There may be risks with this method if an attacker with physical access is able to put the device back into an unconfigured mode, particularly if this may permit the attacker to get access to the private key material. When done on a single device, such an attack may be able to replace the IDevID with one signed by another manufacturer. That does not result in a risk of counterfeit devices. An attack that is able to extract the private key could clone the device.¶
Generating the key off-device has the advantage that the randomness of the private key can be better analyzed. As the private key is available to the manufacturing infrastructure, the authenticity of the public key is well known ahead of time. If the device does not come with a serial number in silicon, then one should be be assigned and placed into a certificate. The private key and certificate could be programmed into the device along with the initial bootloader firmware in a single step.¶
The major downside to generating the private key off-device is that it could be seen by the manufacturing infrastructure. This makes the manufacturing infrastructure a high-value attack target, so a mechanism is needed to keep the private key secure within the manufacturing process.¶
Encrypting the private key would solve this, but then the symmetric key would need to be shared with the device, which is back to the original problem.¶
If keys are generated by the manufacturing plant, and are immediately installed, but never stored, then the window in which an attacker can gain access to the private key is immensely reduced.¶
A hybrid of the previous two methods leverages a symmetric key that is often provided by a silicon vendor to OEM manufacturers. Each CPU (or a Trusted Execution Environment [I-D.ietf-teep-architecture], or a TPM) is provisioned at fabrication time with a unique, secret seed, usually at least 256-bits in size.¶
This value is revealed to the OEM board manufacturer only via a secure channel. Upon first boot, the system (probably within a TEE, or within a TPM) will generate a key pair using the seed to initialize a Pseudo-Random-Number-Generator (PRNG). The OEM, in a separate system, will initialize the same PRNG and generate the same key pair. The OEM then derives the public key part, signs it and turns it into a certificate. The private part is then destroyed, ideally never stored or seen by anyone. The certificate (being public information) is placed into a database, in some cases it is loaded by the device as its IDevID certificate, in other cases, it is retrieved during the onboarding process based upon a unique serial number asserted by the device.¶
This method appears to have all of the downsides of the previous two methods: the device must correctly derive its own private key, and the OEM has access to the private key, making it also vulnerable. The secret seed must be created in a secure way and it must also be communicated securely.¶
There are some advantages to the OEM however: the major one is that the problem of securely communicating with the device is outsourced to the silicon vendor. The private keys and certificates may be calculated by the OEM asynchronously to the manufacturing process, either done in batches in advance of actual manufacturing, or on demand when an IDevID is demanded. Doing the processing in this way permits the key derivation system to be completely disconnected from any network, and requires placing very little trust in the system assembly factory. Operational security such as often incorrectly presented fictionalized stories of a "mainframe" system to which only physical access is permitted begins to become realistic. That trust has been replaced with a heightened trust placed in the silicon (integrated circuit) fabrication facility.¶
The downsides of this method to the OEM are: they must be supplied by a trusted silicon fabrication system, which must communicate the set of secrets seeds to the OEM in batches, and they OEM must store and care for these keys very carefully. There are some operational advantages to keeping the secret seeds around in some form, as the same secret seed could be used for other things. There are some significant downsides to keeping that secret seed around.¶
A three-tier PKI infrastructure is appropriate. This entails having a root CA created with the key kept offline, and a number of intermediate CAs that have online keys that issue "day-to-day" certificates.¶
The root private key should be kept offline, quite probably in a Hardware Security Module if financially feasible. If not, then it should be secret-split across seven to nine people, with a threshold of four to five people. The split secrets should be kept in geographically diverse places if the manufacturer has operations in multiple places. For examples of extreme measures, see [kskceremony]. There is however a wide spectrum of needs, as exampled in [rootkeyceremony]. The SAS70 audit standard is usually used as a basis for the Ceremony, see [keyceremony2].¶
Ongoing access to the root-CA is important, but not as critical as access to the MASA key.¶
The root CA is then used to sign a number of intermediate entities. If manufacturing occurs in multiple factories, then an intermediate CA for each factory is appropriate. It is also reasonable to use different intermediate CAs for different product lines. It may also be valuable to split IDevID certificates across intermediate CAs in a round-robin fashion for products with high volumes.¶
Cycling the intermediate CAs after a period of a few months or so is a quite reasonable strategy. The intermediate CAs private key may be destroyed after it signed some number of IDevIDs, and a new key generated. The IDevID certificates have very long (ideally infinite) validity lifetimes for reasons that [ieee802-1AR] explains. The intermediate CA will have a private key, likely kept online, which is used to sign each generated IDevID. Once the IDevID are created, the private key is no longer needed and can either be destroyed, or taken offline. In other CAs, the intermediate CA's private key (or another designated key) is often needed to sign OCSP [RFC6960] or CRLS [RFC5280]. As the IDevID process does not in general support revocation, keeping such keys online is not necessary. {EDIT NOTE: REVIEW of this NEEDED}¶
The intermediate CA certificate SHOULD be signed by the root-CA with indefinite (notAfter: 99991231) duration as well.¶
In all cases the serialNumber embedded in the certificate must be unique across all products produced by the manufacturer. This suggests some amount of structure to the serialNumber, such that different intermediate CAs do not need to coordinate when issuing certificates.¶
many yet to be detailed¶
This entire document is a security considerations.¶
This document makes no IANA requests.¶
Hello.¶