[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

IETF                                                  Anoop Kumar Pandey
Internet-Draft                                           C-DAC Bangalore
Intended status: Informational                          January 31, 2019
Expires: August 4, 2019


            AutoAdd - Automatic Bootstrapping of IoT Devices
            draft-autoadd-auto-bootstrapping-iot-devices-00

Abstract

   IoT devices are fast getting embedded into our lives, and when put
   together they have the potential to generate a precise and detailed
   history of our lives and store them forever.  Their networking and
   communicational power can be unleashed for malicious and sabotage
   purposes, by a motivated attacker sitting in the far corner of the
   world.  Attacks on Industrial IoT systems can cause greater
   disasters.  It is therefore essential to inculcate the security
   aspect, right from design to development to operations.  The first
   operation of an IoT device is to bootstrap itself, and due importance
   should be placed to ensure that this operation is carried out
   securely and with due diligence.  However, it's easier said than
   done, and this paper outlines several approaches for secure automated
   bootstrapping and also proposes a new method, which is compared
   against the existing mechanisms for several qualitative factors.

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 August 4, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Anoop Kumar Pandey       Expires August 4, 2019                 [Page 1]


Internet-Draft                   AutoAdd                    January 2019


   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.

Table of Contents

   1.  Prologue  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Prior and Ongoing Contributions . . . . . . . . . . . . . . .   3
     3.1.  TOFU (Trust on First Use) . . . . . . . . . . . . . . . .   3
     3.2.  Resurrecting Duckling . . . . . . . . . . . . . . . . . .   4
     3.3.  Enrollment over Secure Transport  . . . . . . . . . . . .   4
     3.4.  BRSKI . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.5.  EAP-NooB  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.6.  AutoAdd (Work in Progress)  . . . . . . . . . . . . . . .   5
   4.  Comparison Chart  . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Prologue

   Amazon launched "Amazon Alexa" in November 2014.  Alexa is a virtual
   assistant which comes with Echo line of smart speakers.  It is
   capable of voice interaction, control of smart home devices, music
   playback, setting alarms, making calls, checking weather and news and
   much more.
   Google Home series smart speakers were launched in November 2016.
   Google Assistant can be used to control thousands of smart-home
   products from several brands like LG, GE, Whirlpool, Nest etc...
   Google Home can be asked to change the temperature, dim the lights,
   turn on a microwave or kettle, and also start Roomba (robotic vacuum
   cleaners).  It can also turn the TV on/off using Chromecast.
   The concept of smart home and devices is taking off very fast.  It
   appears to make our lives quite easy and comfortable.  But turning
   your home into a computer means facing computer-like problems.  The
   security and performance issues associated are much scary.



Anoop Kumar Pandey       Expires August 4, 2019                 [Page 2]


Internet-Draft                   AutoAdd                    January 2019


   It creates a method for transformation of the physical world into
   computer-based systems, resulting in performance and efficiency
   enhancement, financial gains, and reduces human involvement.  The
   number of IoT devices increased 31% year-over-year to 8.4 billion in
   2017 and it is estimated to have 30 billion IoT devices by 2020
   [iotscale].  Many more devices are/will be connected through serial
   link.

2.  Introduction

   Kevin Ashton coined the term "Internet of Things (IoT)" and defined
   it as a system where the internet is connected to the physical world
   via ubiquitous sensors.  While, the scale of IoT is going pretty
   bigger day by day, the task of adding new devices and bootstrapping
   it at such a large scale, remains at large.  Manual bootstrapping
   requires a human to add an IoT device to a network (network
   discovery), connect to registrar (system where a device can be
   registered), setting up the key for future secure communication and
   finally all configuration of the device for its functioning in the
   network domain.  Automatic bootstrapping methods are still evolving
   and are under testing and scrutiny for various environments and
   scenarios.  While security experts and engineers are toiling hard to
   mitigate risks associated with automatic bootstrapping, we propose a
   system AutoAdd (work in progress), which ensures automatic addition
   and initial bootstrapping of an IoT device while it is put on the
   network.  There are billions of devices and at least thousands of
   manufacturers.  So how do we identify and trust a device?  Similarly
   there are many networks, how does the device know that I am working
   only with my owner and not with some imposter network?  Remember,
   there are hostile devices on the network, and there are hostile
   networks that might attempt to take over the device.  Basically, we
   need to establish the identity/authenticity of the device; Check if
   device is compromised or not; establish the identity of the network/
   domain; and finally check if the domain is the correct one.

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Prior and Ongoing Contributions

3.1.  TOFU (Trust on First Use)

   TOFU (Trust on First Use) calls for accepting and storing a public
   key or credential associated with an asserted identity, without
   authenticating that assertion.  Subsequent communication that is



Anoop Kumar Pandey       Expires August 4, 2019                 [Page 3]


Internet-Draft                   AutoAdd                    January 2019


   authenticated using the cached key or credential is secure against an
   MiTM attack, if such an attack did not succeed during the vulnerable
   initial communication.

3.2.  Resurrecting Duckling

   In 'Resurrecting Duckling' [stajano1999resurrecting], a device
   recognises as its owner the first entity that sends it a secret key
   and will stay loyal to its owner for the rest of the life.  It may
   come to EoL (end of life), or may be reset.  The ownership of the
   device may also be transferred.  It is analogous to imprinting in
   ducks, where duckling emerging from its egg will recognise as its
   mother the first moving object it sees that makes a sound, regardless
   of what it looks like.

3.3.  Enrollment over Secure Transport

   In Enrollment over Secure Transport (EST) RFC 7030 [RFC7030], the
   client starts a TLS based HTTPS session with an EST server.  Through
   a part of URI, a specific EST service is requested during the
   session.  The client authenticates the server and the server
   authenticates the client.  The server verifies if the client is
   authorized to use the requested service.  Similarly the client
   verifies if the server has proper authorization to serve this client.
   Upon complete authentication and authorization check of both the
   parties, the server responds to the client request.

3.4.  BRSKI

   An ongoing internet draft BRSKI (Bootstrapping Remote Secure Key
   Infrastructures) [I-D.ietf-anima-bootstrapping-keyinfra] lists steps
   for auto bootstrapping as follow:

   o  Pledge discovers a communication channel to a Registrar.

   o  Pledge identifies itself.  This is done by presenting an X.509
      IDevID credential to the discovered Registrar (via the Proxy) in a
      TLS handshake.  (The Registrar credentials are only provisionally
      accepted at this time)

   o  Pledge requests to join the discovered Registrar using a voucher
      request.

   o  Registrar sends the voucher request to the MASA (manufacturer).
      URL of MASA can be in the voucher request or embedded in
      Registrar.

   o  MASA sends the voucher which is passed to pledge.



Anoop Kumar Pandey       Expires August 4, 2019                 [Page 4]


Internet-Draft                   AutoAdd                    January 2019


   o  MASA sends the voucher which is passed to pledge.

   o  Pledge verifies the voucher and imprints to the registrar by send
      voucher status telemetry.

   o  Registrar verifies the voucher and enrolls the pledge to the
      domain

   Here pledge is the device to be added to network/domain; registrar is
   the registration authority where devices are registered; MASA is
   manufacturer authorized signing authority; IDevID is an Initial
   Device Identity X.509 certificate installed by the vendor on new
   equipment and voucher is a signed statement from the MASA service
   that indicates to a Pledge the cryptographic identity of the
   Registrar it should trust.

3.5.  EAP-NooB

   EAP-NooB (Extensible Authentication Protocol Nimble out of Band)
   [I-D.aura-eap-noob] method is intended for bootstrapping all kinds of
   Internet-of-Things (IoT) devices that have a minimal user interface
   and no pre-configured authentication credentials.  The method makes
   use of a user-assisted one-directional OOB (out of band) channel
   between the peer device and authentication server.  The secure
   bootstrapping in this specification makes use of a user-assisted out-
   of-band (OOB) channel.  The security is based on the assumption that
   attackers are not able to observe or modify the messages conveyed
   through the OOB channel.  EAP-NooB follows the common approach of
   performing a Diffie-Hellman key exchange over the insecure network
   and authenticating the established key with the help of the OOB
   channel in order to prevent impersonation and man-in-the-middle
   (MitM) attacks.

3.6.  AutoAdd (Work in Progress)

   We propose AutoAdd: an automatic bootstrapping method for IoT
   devices.  This is a work in progress and open for comments.
   When a device is purchased in real world, usually an invoice is
   issued in the name of the purchaser with stamp of vendor/
   manufacturer.  We propose that similarly, a digital invoice can be
   issued which will contain the public key(s) of the <domain
   owner(s)/Registrar(s)> and digitally signed by the manufacturer.  The
   digital invoice may be embedded in the device along with the IDevID.
   A digital invoice may be contain the IDevID of the device and Public
   key of Registrars (Ri), digital signed by Manufacturer (M) and can be
   represented as below.

   Dig_Invoice = DigSignM {IDevID, PubKey: [R1, R2, .., Rn]}



Anoop Kumar Pandey       Expires August 4, 2019                 [Page 5]


Internet-Draft                   AutoAdd                    January 2019


   When the device starts the registration process, it will present the
   digital invoice along with IDevID.  The Registrar can verify the
   digital signature of the manufacturer on the digital invoice and sent
   a signed note of acceptance to the device.

   Flag = VerifyDigSignManufacturer (Dig_Invoice, PubKeyM)
   if (flag) Acceptance_Note = DigSignRi {Note}

   The device can verify the signed note using the public key(s)
   mentioned in the digital invoice, thereby verifying its true owner.

   VerifyDigSignRegistrar (Acceptance_Note, PublicKeyFromDigInvoiceRi)

   This process with eliminate all the communication overhead with MASA
   and multiple level verification (voucher request, voucher, telemetry
   etc.  at Registrar/ MASA/Device.  From security point of view, we can
   claim that given that the digital invoice is digitally signed by
   manufacturer, the public key of domain owner embedded in the digital
   invoice can't be changed, otherwise verification of digital signature
   of manufacturer at Registrar end will fail.

4.  Comparison Chart





























Anoop Kumar Pandey       Expires August 4, 2019                 [Page 6]


Internet-Draft                   AutoAdd                    January 2019


   +--------------+-------------------------+--------------------------+
   |   Approach   |         Security        | Constraints/Consequence  |
   +--------------+-------------------------+--------------------------+
   |     TOFU     |    Vulnerable initial   |   No authentication of   |
   |              |      communication      |    initial assertion     |
   +--------------+-------------------------+--------------------------+
   | Resurrecting | No owner authentication | Anyone can be the owner  |
   |   Duckling   |                         |                          |
   +--------------+-------------------------+--------------------------+
   |     EST      |     TLS secured HTTP    |                          |
   |              |  session between client |                          |
   |              |        and Server       |                          |
   +--------------+-------------------------+--------------------------+
   |    BRSKI     |      Online service     |  MASA should be always   |
   |              |   authenticating both   |  online; No auto run of  |
   |              |    device and domain    |   BRSKI on network or    |
   |              |                         |     ownership change     |
   +--------------+-------------------------+--------------------------+
   |   EAP-NooB   |  Security dependent on  | Manual intervention for  |
   |              |    Ephemeral Elliptic   | OOB authentication; Not  |
   |              |   Curve Diffie-Hellman  |         Scalable         |
   |              |   (ECDHE) key exchange  |                          |
   |              |  and manual assistance  |                          |
   +--------------+-------------------------+--------------------------+
   |   AutoAdd    |       Easy offline      |                          |
   |              |  authentication of both |                          |
   |              |    device and domain    |                          |
   +--------------+-------------------------+--------------------------+

           Table 1: Comparison of various bootstrapping methods

5.  Conclusion

   AutoAdd can serve as a secure automatic bootstrapping method for IoT
   devices.  The testing of the same is undergoing.  Details will follow
   soon in upcoming version.  We are also working on a internet draft to
   incorporate device certificates with EAP-NOOB.

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Security Considerations

   This draft proposes an automatic bootstrapping method for IoT
   devices.  The security of the protocol is inherent from the security
   of unforgeable digital signature and PKI.  A detailed security
   analysis is pending.



Anoop Kumar Pandey       Expires August 4, 2019                 [Page 7]


Internet-Draft                   AutoAdd                    January 2019


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/info/rfc7030>.

8.2.  Informative References

   [I-D.aura-eap-noob]
              Aura, T. and M. Sethi, "Nimble out-of-band authentication
              for EAP (EAP-NOOB)", draft-aura-eap-noob-04 (work in
              progress), October 2018.

   [I-D.ietf-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
              S., and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-18 (work in progress), January 2019.

   [iotscale]
              Nordrum, Amy., "Popular Internet of Things Forecast of 50
              Billion Devices by 2020 Is Outdated", 2016,
              <https://spectrum.ieee.org/tech-talk/telecom/internet/
              popular-internet-of-things-forecast-of-50-billion-devices-
              by-2020-is-outdated>.

   [stajano1999resurrecting]
              Frank, Stajano., "The resurrecting duckling", 1999,
              <https://cis.temple.edu/~wu/teaching/fall_2004_files/
              secure2.pdf>.

Author's Address

   Anoop Kumar Pandey
   C-DAC Bangalore
   #68, Electronics City
   Bangalore  560100
   India

   Email: anoop@cdac.in



Anoop Kumar Pandey       Expires August 4, 2019                 [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/