Security and Operational considerations for manufacturer generated IDevID
draft-richardson-secdispatch-idevid-considerations-00

anima Working Group                                        M. Richardson
Internet-Draft                                  Sandelman Software Works
Intended status: Standards Track                                  W. Pan
Expires: 12 December 2020                            Huawei Technologies
                                                            10 June 2020

   Security and Operational considerations for manufacturer generated
                                 IDevID
         draft-richardson-secdispatch-idevid-considerations-00

Abstract

   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.

Status of This Memo

   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 Notice

   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

Richardson & Pan        Expires 12 December 2020                [Page 1]
Internet-Draft            IDevID Considerations                June 2020

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Operational Considerations for Manufacturer IDevID Public Key
           Infrastructure  . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Key Generation process  . . . . . . . . . . . . . . . . .   3
       2.1.1.  On-device private key generation  . . . . . . . . . .   3
       2.1.2.  Off-device private key generation . . . . . . . . . .   4
       2.1.3.  Key setup based on 256-bit secret seed  . . . . . . .   5
     2.2.  Public Key infrastructure for IDevID  . . . . . . . . . .   6
   3.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   [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.

Richardson & Pan        Expires 12 December 2020                [Page 2]
Internet-Draft            IDevID Considerations                June 2020

2.  Operational Considerations for Manufacturer IDevID Public Key
    Infrastructure

   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.

2.1.  Key Generation process

2.1.1.  On-device private key generation

   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.

Richardson & Pan        Expires 12 December 2020                [Page 3]
Internet-Draft            IDevID Considerations                June 2020

   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.

2.1.2.  Off-device private key generation

   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.

Richardson & Pan        Expires 12 December 2020                [Page 4]
Internet-Draft            IDevID Considerations                June 2020

2.1.3.  Key setup based on 256-bit secret seed

   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.

Richardson & Pan        Expires 12 December 2020                [Page 5]
Internet-Draft            IDevID Considerations                June 2020

2.2.  Public Key infrastructure for IDevID

   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.

Richardson & Pan        Expires 12 December 2020                [Page 6]
Internet-Draft            IDevID Considerations                June 2020

   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.

3.  Privacy Considerations

   many yet to be detailed

4.  Security Considerations

   This entire document is a security considerations.

5.  IANA Considerations

   This document makes no IANA requests.

6.  Acknowledgements

   Hello.

7.  Changelog

8.  References

8.1.  Normative References

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [I-D.moskowitz-ecdsa-pki]
              Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson,
              "Guide for building an ECC pki", Work in Progress,
              Internet-Draft, draft-moskowitz-ecdsa-pki-08, 14 February
              2020, <http://www.ietf.org/internet-drafts/draft-
              moskowitz-ecdsa-pki-08.txt>.

   [ieee802-1AR]
              IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier",
              2009, <http://standards.ieee.org/findstds/
              standard/802.1AR-2009.html>.

8.2.  Informative References

Richardson & Pan        Expires 12 December 2020                [Page 7]
Internet-Draft            IDevID Considerations                June 2020

   [I-D.richardson-anima-masa-considerations]
              Richardson, M. and W. Pan, "Operational Considerations for
              Manufacturer Authorized Signing Authority", Work in
              Progress, Internet-Draft, draft-richardson-anima-masa-
              considerations-03, 9 March 2020, <http://www.ietf.org/
              internet-drafts/draft-richardson-anima-masa-
              considerations-03.txt>.

   [I-D.ietf-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", Work in Progress, Internet-
              Draft, draft-ietf-anima-bootstrapping-keyinfra-41, 8 April
              2020, <http://www.ietf.org/internet-drafts/draft-ietf-
              anima-bootstrapping-keyinfra-41.txt>.

   [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
              "A Voucher Artifact for Bootstrapping Protocols",
              RFC 8366, DOI 10.17487/RFC8366, May 2018,
              <https://www.rfc-editor.org/info/rfc8366>.

   [BedOfNails]
              Wikipedia, "In-circuit test", 2019,
              <https://en.wikipedia.org/wiki/In-
              circuit_test#Bed_of_nails_tester>.

   [RambusCryptoManager]
              Qualcomm press release, "Qualcomm Licenses Rambus
              CryptoManager Key and Feature Management Security
              Solution", 2014, <https://www.rambus.com/qualcomm-
              licenses-rambus-cryptomanager-key-and-feature-management-
              security-solution/>.

   [kskceremony]
              Verisign, "DNSSEC Practice Statement for the Root Zone ZSK
              Operator", 2017, <https://www.iana.org/dnssec/dps/zsk-
              operator/dps-zsk-operator-v2.0.pdf>.

   [rootkeyceremony]
              Community, "Root Key Ceremony, Cryptography Wiki", April
              2020,
              <https://cryptography.fandom.com/wiki/Root_Key_Ceremony>.

   [keyceremony2]
              Digi-Sign, "SAS 70 Key Ceremony", April 2020,
              <http://www.digi-sign.com/compliance/key%20ceremony/
              index>.

Richardson & Pan        Expires 12 December 2020                [Page 8]
Internet-Draft            IDevID Considerations                June 2020

   [nistsp800-57]
              NIST, "SP 800-57 Part 1 Rev. 4 Recommendation for Key
              Management, Part 1: General", 1 January 2016,
              <https://csrc.nist.gov/publications/detail/sp/800-57-part-
              1/rev-4/final>.

   [I-D.ietf-teep-architecture]
              Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
              "Trusted Execution Environment Provisioning (TEEP)
              Architecture", Work in Progress, Internet-Draft, draft-
              ietf-teep-architecture-08, 4 April 2020,
              <http://www.ietf.org/internet-drafts/draft-ietf-teep-
              architecture-08.txt>.

   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
              Galperin, S., and C. Adams, "X.509 Internet Public Key
              Infrastructure Online Certificate Status Protocol - OCSP",
              RFC 6960, DOI 10.17487/RFC6960, June 2013,
              <https://www.rfc-editor.org/info/rfc6960>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

Authors' Addresses

   Michael Richardson
   Sandelman Software Works

   Email: mcr+ietf@sandelman.ca

   Wei Pan
   Huawei Technologies

   Email: william.panwei@huawei.com

Richardson & Pan        Expires 12 December 2020                [Page 9]