Internet DRAFT - draft-anoopmis-eap-autoadd
draft-anoopmis-eap-autoadd
IETF Anoop Kumar Pandey
Internet-Draft C-DAC Bangalore
Intended status: Informational December 23, 2019
Expires: June 25, 2020
AutoAdd - Automatic Bootstrapping of IoT Devices
draft-anoopmis-eap-autoadd-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 June 25, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
Anoop Kumar Pandey Expires June 25, 2020 [Page 1]
Internet-Draft AutoAdd December 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) . . . . . . . . . . . . . . . . 4
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
3.6.1. Expiration of owner certificate . . . . . . . . . . . 6
3.6.2. Selling a device . . . . . . . . . . . . . . . . . . 7
4. Comparison Chart . . . . . . . . . . . . . . . . . . . . . . 7
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
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
Anoop Kumar Pandey Expires June 25, 2020 [Page 2]
Internet-Draft AutoAdd December 2019
your home into a computer means facing computer-like problems. The
security and performance issues associated are much scary.
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
Anoop Kumar Pandey Expires June 25, 2020 [Page 3]
Internet-Draft AutoAdd December 2019
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
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.
Anoop Kumar Pandey Expires June 25, 2020 [Page 4]
Internet-Draft AutoAdd December 2019
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.
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
Anoop Kumar Pandey Expires June 25, 2020 [Page 5]
Internet-Draft AutoAdd December 2019
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]}
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. We would also like to
share few use cases for the sake of understanding the complete
ecosystem of AutoAdd.
3.6.1. Expiration of owner certificate
The device has domain owner's or registrar's public key embedded in
its digital invoice which is used to verify the digital signature on
the note of acceptance and thereby authenticating the owner. If the
owner's digital signature certificate expires or is changed or is
revoked, the digital signature of the owner can't be verified and the
owner authentication will fail.
To overcome such situation, before the expiration of the certificate,
the owner will require to create another digital invoice by
specifying it's own new public key digitally signed by his old
private key and embedding it into the device. This will basically
create a chain of digital invoices. This process is similar to
attestation of own signature in real world. The verification will
basically verify the chain of digital invoices.
For the sake of clarity, let us consider R1_old as old public key of
Registrar and original digital invoice be
Anoop Kumar Pandey Expires June 25, 2020 [Page 6]
Internet-Draft AutoAdd December 2019
Dig_Invoice_Original = DigSign (PvtM, {IDevID, PubKey: [R1_old]})
Let R1_new be the new public key of the registrar and Pvt_R1_Old be
the old private key of the reigstrar. The registrar need to create a
new digital invoice digitally signed by his old private key.
Dig_Invoice_New = DigSign (Pvt_R1_Old , {IDevID, PubKey: [R1_new]} )
Let note of acceptance signed with new private key of R1 as follow:
Acceptance_Note = DigSign(Pvt_R1_new, {Note})
Verification will be done as per following steps:
Flag1 = VerifyDigSignDigInvoiceNew (Dig_Invoice_New,
PublicKeyFromDigInvoiceOriginalR1)
If(flag1) flag2 = VerifyDigSignRegistrar (Acceptance_Note,
PublicKeyFromDigInvoiceNewR1)
If(flag2) Output "Registrar or Owner verified"
These steps can be chained for multiple chain of digital invoices.
3.6.2. Selling a device
A device may be resold and in the new environment, the public key of
the new owner may need to be embedded in the device, else owner
verification will fail. Addition of the public key of the new owner
will follow similar steps as described in the previous section
(3.6.1) where the old owner will create a new digital invoice by
specifying the new owner's public key and digitally signing it. The
verification of the note of acceptance by the new owner will follow
similar steps as illustrated in section 3.6.1.
4. Comparison Chart
Anoop Kumar Pandey Expires June 25, 2020 [Page 7]
Internet-Draft AutoAdd December 2019
+--------------+-----------------------+----------------------------+
| Approach | Security | Constraints/Consequence |
+--------------+-----------------------+----------------------------+
| TOFU | Vulnerable initial | No authentication of |
| | communication | initial assertion |
+--------------+-----------------------+----------------------------+
| Resurrecting | No owner | Anyone can be the owner |
| Duckling | authentication | |
+--------------+-----------------------+----------------------------+
| EST | TLS secured HTTP | Need some pre-provisioned |
| | session between | credentials to establish |
| | client and Server | secure communication |
+--------------+-----------------------+----------------------------+
| BRSKI | Online service | Online service |
| | authenticating both | authenticating both device |
| | device and domain | and domain & MASA should |
| | | be always online; No |
| | | autorun of 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 | Public key is required for |
| | authentication of | each buyer. |
| | both device and | |
| | domain | |
+--------------+-----------------------+----------------------------+
Table 1: Comparison of various bootstrapping methods
5. Conclusion
We have outlined a number of approaches that are currently followed
for bootstrapping of IoT devices along with their merits and
demerits. We have also highlighted several security concerns that
would have to be addressed for booting up and bringing an IoT device
for operations. We have also presented AutoAdd and have done a
qualitative comparison against the existing methods in terms of
security and ease-of-use. AutoAdd can serve as a secure automatic
bootstrapping method for IoT devices.
We are also working on a internet draft to incorporate device
certificates with EAP-NOOB.
Anoop Kumar Pandey Expires June 25, 2020 [Page 8]
Internet-Draft AutoAdd December 2019
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.
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-07 (work in
progress), October 2019.
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-31 (work in progress), December 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>.
Anoop Kumar Pandey Expires June 25, 2020 [Page 9]
Internet-Draft AutoAdd December 2019
[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 June 25, 2020 [Page 10]
