Advertisement

SN Computer Science

, 1:46 | Cite as

AutoAdd: Automated Bootstrapping of an IoT Device on a Network

  • Anoop Kumar PandeyEmail author
  • Balaji Rajendran
  • V. S. Kumari Roshni
Review Article
  • 222 Downloads
Part of the following topical collections:
  1. Advances in Internet Research and Engineering

Abstract

The explosion in the number of IoT Devices have raised Herculean security challenges. Security of IoT devices begins from the time of bootstrapping to initial configuration, and then proceeds with routine operations of the device. It is therefore essential to have a secure process for bootstrapping of IoT devices. In this paper, we bring out the existing methods for bootstrapping of IoT devices along with their challenges and constraints. We propose “AutoAdd” an automated bootstrapping mechanism that overcomes the limitations of the other approaches and provides for off-line authentication of the devices, with the only constraint of requirement of a public key. Our approach is qualitatively evaluated against other existing approaches.

Keywords

Bootstrapping IOT Digital signature AutoAdd EST 

Prologue

A number of smart devices in the general infotainment category, targeting the home users, have been launched in the market. Few of the names include: Alexa [1] from Amazon—a smart speaker that can recognize the voice commands of its user and respond to it by fetching the requested information, and Google Home [2] from Google, a smart speaker with almost the same features of the above, but powered by the Google’s own search engine in the backend.

All of the above-mentioned devices have the ability to interface with other smart devices at home, including the home router, personal computer, household appliances, entertainment devices, locks, lights, etc.… This brings in a host of security issues associated with these interfaces. For instance, an issue like an expired certificate could make the owners lose control of their devices and their homes [3].

Introduction

We get Internet of Things (IoT) when all devices can autonomously communicate with each other over a network. Each IoT devices consists of at least two components—sensors for capturing the data; interfaces for communication with its master or other devices. However the new generation of devices are invariably equipped with internal processing capabilities, which are sandwiched between the sensors and communication interfaces and are generally marketed as “Smart” devices. The ability of these “Smart” IoT devices to communicate over a network (Internet) makes them even more vulnerable—as it opens up new channels of attack [4].

Considering the explosion of IoT devices, which was estimated to be at 8.4 billion in 2017 [5] and likely to touch 30 billion by 2020 [6], the security perspective of the IoT devices demands paramount attention. The security of an IoT device starts from its manufacturing and goes forward to commissioning, to operations, to upgrades and decommissioning at the end of its life cycle. It is essential to incorporate security features and make it hack-proof at every step in the life cycle. We focus on the secure bootstrapping of IoT devices, a part of the commissioning step in the device life cycle.

Classic information security has been about confidentiality, integrity and availability. An attacker should not steal our data (confidentiality), or modify it (integrity), or prevent us from obtaining it (availability).

Confidentiality attacks have been targeting the Internet world for a very long time. They are expensive, embarrassing and harmful. In August 2014, a collection of private pictures of celebrities, stored in private cloud from their mobile phones, were hacked and shared publicly through imageboards like 4chan and later disseminated to other websites and social media [7]. The access was gained through targeted phishing attacks.

While confidentiality attack seems more pertinent, integrity and availability attacks pose graver risks. While threats like breaking into a house or house arresting someone by hacking a smart door lock, remote murder through hacked medical devices, denying someone access of his own car or allowing a stranger to access to one’s car, freezing water pipes through hacked thermostat, shutting down electric grid remotely, releasing toxic chemicals or gas in air through hacked robots or machinery, crashing an aeroplane and many more, may seem overhyped, but may turn into reality soon.

These increased risks or threats may be attributed to the following factors [8]:

Turning Everything into a Computer and Allowing Software Control

More and more devices are getting software enabled and controlled, thereby making them prone to all the attacks that one witnessed against computers. Though software control gives lots of flexibility and ease of use, it also brings insecurities and vulnerabilities with it. Consider the example of mobiles: while new mobile device models are getting released every few days from one or the other OEM, the monthly security patch updates are limited, leave apart major updates (e.g. Android Version Update from Oreo to Pie). As many of these devices are expensive and last long, we do not replace them frequently and as a result will be vulnerable with older software. Even though some devices get their updates for lifetime, their performance decreases as they become older and we need to make a choice between performance and a new update [9]. A recent Princeton survey [10] found more than 500,000 insecure devices on the Internet.

Connectivity

As systems become interconnected, vulnerabilities in one device can lead to attacks against other devices. The recent WannaCry [11] ransomware attack in May 2017 included a “transport” mechanism to automatically spread itself. It scans for vulnerable systems, then uses the EternalBlue [12] exploit to gain access, and the DoublePulsar [13] tool to install and execute a copy of itself. With the Internet of Things, exploitable vulnerabilities will be exploited more often.

Quantitatively, if n systems are all interacting with each other, that is about n × (n − 1)/2 interactions, so 100 systems mean approximately 5000 interactions and apparently 5000 potential vulnerable points resulting from those interactions. It can increase to 45 K interactions with just 300 systems and half a million with 1 K systems.

Autonomous Systems

As we are moving towards autonomous systems, autonomous networks, driverless cars, self-regulating electricity grids, automatic payment systems, auto selling/buying of stocks, etc., it also implies that the impact of attacks can be devastating as they can run automatically and propagate ubiquitously. The less number of humans in the loop of an attack, the faster will it propagate.

One of the challenges in security is not to make things difficult for the users. The trade-off between security and user convenience has always been a challenge that requires to be addressed in every device. So, as the security engineers work to balance between security and user convenience, one of the key aspects is to ensure that the device is able to configure itself and is ready to run.

The alternative to automated bootstrapping requires significant user intervention—from initiating the device for connecting with a network (network discovery), connect with its master or manufacturer (registrar), initializing the keys for secure communication, and all other configurations that would be required to operationalize the device.

A central problem in initial secure communications of the IoT device is that there exists hundreds and hundreds of manufacturers, manufacturing millions of devices, essentially requiring unique identification of each device. Moreover there would be hostile devices waiting to take over the new device. A unique identification mechanism for the devices will pave way for authenticated communications and will help in connecting to the right network and right registrar.

Study of Current Approaches

TOFU (Trust on First Use)

In this Internet protocol [14], a public key is asserted as its identity by the end device and presented to the master. The master accepts the assertion and starts using the asserted public key for all future communications, thereby making the communications encrypted and secure. The weakness with this approach is that if an attacker had captured the initial communication, then all subsequent conversations between the client and server could be accessed by the attacker forever.

Resurrecting Duckling

In this work [15], the authors propose a mechanism mimicking the way how ducklings recognize their parents by trusting the first moving object they see around them. In this technique, a device recognizes its master, when the latter is the first to send a secret key to the device. The receiving end device accepts the secret key from the sending master and uses it for all subsequent communications. The limitations with this approach is that the client has to blindly trust a device that sends it a key as its master and use the same forever. Also, issues such as change in master over the due course of time could not be addressed in this mechanism.

Enrollment over Secure Transport (EST)

In this Internet protocol [16], an HTTPS session is established by the device (EST Client) to its registrar, (EST Server). There would be many services running in the EST server, and therefore the device has to request for a specific service, and it does so using the request URI. The EST client then authenticates the EST server and vice versa, and upon successful mutual authentication the EST server responds to the request of the EST client.

Bootstrapping Remote Secure Key Infrastructures (BRSKI)

A recent Internet protocol draft [17], Bootstrapping Remote Key Infrastructure [BRSKI], uses a trusted third party service for facilitating authentication of IoT device to its master and vice versa. The following are the brief steps in the process outlined in the above work.

The device (pledge) comes embedded with an X.509 IDevID certificate. (IDevID is a certificate, containing a unique identity of the device, imprinted by the manufacturer of the device)

The device figures out a network to communicate with the registrar, and presents its IDevID to the registrar which accepts it temporarily and both establish a TLS handshake, thereby creating an HTTPS connection.

The device then asks the registrar to allow it to join its network, by presenting a voucher request. The registrar forwards the voucher request to MASA (manufacturer and an authorized signing authority). The URL of the MASA is contained in the voucher request.

MASA upon due authentication of the voucher-request, sends the voucher (a digitally signed statement by MASA indicating the cryptographic credentials of the registrar, whom the device can trust) to the registrar which is passed to the device. The device verifies the voucher and updates the registrar by sending voucher status information. Registrar verifies the voucher and enrols the device. In this way, a mutual trust is established between the device and the registrar.

BRSKI uses a pool of known manufacturers and a well-laid procurement process. It basically whitelists all manufacturers and accepts devices only from known manufacturers during bootstrapping. Moreover, BRSKI is a one-time process. It is not automatically restarted when the pledge detects a change in ownership or network which should be mandatory, given that the device may get stolen or put in some other network after initial bootstrapping.

EAP-NooB

In this proposed Internet protocol [18], Extensible Authentication Protocol Nimble Out-of-Band (EAP-NooB), the authors propose a two-phase process. In the first phase, the end device and authentication server (registrar) derive at a symmetric key use DHKE (Diffie–Hellman Key Exchange) and then in the second phase, the derived symmetric key is authenticated through an out of band communication channel using human intervention.

The second phase aims to eliminate the man-in-the-middle attack problem with DHKE, wherein the user of the device will manually provide the derived key to the server for verifying, whether it is the right derived key for communication between the device and the server. In this way, if there has been a man-in-the-middle attack during the first phase, it would get detected, as the server will see a mismatch between its key and the key presented by the user, and in such cases the keys will be discarded and the process will have to be restarted again.

AutoAdd

In our work, “AutoAdd”, we propose a mechanism, to ensure automatic bootstrapping of an IoT device. It starts with the manufacturer of the device creating a digital invoice, containing the details of the buyer in the form of the public key of the buyer, the details of the registrars whom the device can trust in the form of public keys of the registrar, and the digital invoice being digitally signed by the manufacturer and adding it to the root of the trust anchor and embedding it in the device along with IDevID. The trust anchor [19] is implemented as a secure hardware chip that has capability for storing and processing cryptographic information.

The buyer can be a reseller or could be registrar or could be the end user. The buyer can further sell the device to another buyer (second) by creating a new digital invoice containing the second buyer’s public key, the fingerprint of the first digital invoice and the digital signature of the first buyer. This mechanism ensures that a chain is established starting from the root and also helps to trace through to the current legitimate user of the device. If a provision could be made to enable to current owner of the device to write once (only once) into the trust anchor, it could provide remarkable integrity to the process and eliminate all probable attacks. This also eliminates the need for a third party like MASA and multiple levels of verification.

Digital Invoice Format

D_Invoice = DigSign (PvtM, {IDevID, PubKey: [R i ]})

where Ri are public keys of the registrars or owners and PvtM is the private key of the manufacturer for signing the content {IDevID, PubKey: [Ri]}.

Bootstrapping Using Digital Invoice

During the bootstrapping process, the device presents the digital invoice to the registrar. The registrar verifies the authenticity of the device by verifying the digital signature of the manufacturer on the digital invoice which also carries the IDevID of the device.

VerificationStatus = VerifySignManufacturer (D_Invoice, Pub M )

Where PubM is the public key of the manufacturer. Further he send a signed note to device confirming the registration of the device.

If (VerificationStatus) SignedNote = DigSign(PvtRi, {Note}),

where PvtRi is the private key of the registrar Ri.

The device verifies the signature of the registrar on the signed note using the embedded public key of the registrar in the digital invoice and verifying the ownership subsequently.

VerifyRegistrarSign (SignedNote, PubKeyFromD_Invoice Ri ).

We would also like to share few use cases for the sake of understanding the complete ecosystem of AutoAdd.

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 cannot 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 its 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 R1old as old public key of Registrar and original digital invoice be

D_Invoice_Original = DigSign (PvtM, {IDevID, PubKey: [R1old]}).

Let R1new be the new public key of the registrar and PvtR1Old be the old private key of the reigstrar. The registrar needs to create a new digital invoice digitally signed by his old private key.

D_Invoice_New = DigSign (PvtR1Old, {IDevID, PubKey: [R1new]}).

Let the note of acceptance signed with new private key of R1 is as follows:

SignedNote = DigSign(PvtR1new, {Note}).

Verification will be done as per the following steps:

Flag1 = VerifyDigSignD_InvoiceNew (D_Invoice_New, PublicKeyFromDigInvoiceOriginalR1).

If(flag1) flag2 = VerifyDigSignRegistrar (SignedNote, PubKeyFromD_InvoiceR1).

If(flag2) Output “Registrar/Owner verified”.

These steps can be chained for multiple chain of digital invoices.

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, or else owner verification will fail. Addition of the public key of the new owner will follow similar steps as described in the previous section “Digital Invoice Format” 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  “Digital Invoice Format”.

Comparison Chart

See Table 1.
Table 1

Comparison of different bootstrapping methods

Approach

Security

Constraints

TOFU

Vulnerable initial communication

No authentication of initial assertion

Resurrecting duckling

Anyone can be the owner

No owner authentication

EST

TLS secured HTTP session between client and server

Need some pre-provisioned credentials to establish secure communication

BRSKI

Online service authenticating both device and domain

Online service authenticating both device and domain and MASA should be always online; no autorun of BRSKI on network or ownership change

EAP-NooB

Security dependent on Ephemeral Elliptic Curve Diffie–Hellman (ECDHE) key exchange and manual assistance

Manual intervention for OOB authentication; not scalable

AutoAdd

Mutual authentication of device and registrar (domain) in off-line mode

Public key is required for each buyer

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 therefore could effectively serve as an automatic and secure means for bootstrapping of IoT devices.

Notes

Funding

This study was not funded.

Compliance with Ethical Standards

Conflict of Interest

The authors declare that they have no conflict of interest.

References

  1. 1.
  2. 2.
  3. 3.
    Wink smart home hubs knocked out by security certificate. https://www.engadget.com/2015/04/19/wink-home-automation-hub-bricked/. Accessed 8 Aug 2018.
  4. 4.
  5. 5.
  6. 6.
    Nordrum A. Popular internet of things forecast of 50 billion devices by 2020 is outdated. IEEE. 2016. https://spectrum.ieee.org/tech-talk/telecom/internet/popular-internet-of-things-forecast-of-50-billion-devices-by-2020-is-outdated. Accessed 18 Aug 2016.
  7. 7.
    iCloud leaks of celebrity photos. https://en.wikipedia.org/wiki/ICloud_leaks_of_celebrity_photos. Accessed 25 July 2016.
  8. 8.
    The Internet of Things Will Turn Large-Scale Hacks into Real World Disasters. https://motherboard.vice.com/en_us/article/qkjzwp/the-internet-of-things-will-cause-the-first-ever-large-scale-internet-disaster. Accessed 3 Oct 2019.
  9. 9.
    Message from Apple. https://www.apple.com/in/iphone-battery-and-performance/. Accessed 6 Aug 2013.
  10. 10.
  11. 11.
    WannaCry ransomware attack. https://en.wikipedia.org/wiki/WannaCry_ransomware_attack. Accessed 19 Jan 2016.
  12. 12.
    EternalBlue. https://en.wikipedia.org/wiki/EternalBlue. Accessed 4 Nov 2019.
  13. 13.
    DoublePulsar. https://en.wikipedia.org/wiki/DoublePulsar. Accessed 17 Oct 2019.
  14. 14.
    Opportunistic Security: Some Protection Most of the Time. https://tools.ietf.org/html/rfc7435. Accessed Dec 2014.
  15. 15.
    The Resurrecting Duckling: Security Issues for Ad hoc Wireless Networks. https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-duckling.pdf. Accessed 26 Apr 2018.
  16. 16.
    Enrollment over Secure Transport. https://tools.ietf.org/html/rfc7030. Accessed 14 June 1999.
  17. 17.
    Bootstrapping Remote Secure Key Infrastructures (BRSKI). https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-15. Accessed Oct 2013.
  18. 18.
    Aura T, Sethi M. Nimble out-of-band authentication for EAP (EAP-NOOB). Draft-aura-eap-noob-01 (work in progress). 2016.Google Scholar
  19. 19.
    Song Z, Molina J, Gordon J. Hardware trust anchor. U.S. Patent 8,505,103, issued August 6. 2013.Google Scholar

Copyright information

© Springer Nature Singapore Pte Ltd 2019

Authors and Affiliations

  • Anoop Kumar Pandey
    • 1
    Email author
  • Balaji Rajendran
    • 1
  • V. S. Kumari Roshni
    • 1
  1. 1.Centre for Development of Advanced ComputingBangaloreIndia

Personalised recommendations