AutoAdd - Automatic Bootstrapping of IoT Devices

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 onoff 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 computerlike 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 . Many more devices arewill be connected through serial link.

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.

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.

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.

In 'Resurrecting Duckling' , 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.

In Enrollment over Secure Transport (EST) RFC 7030, 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.

An ongoing internet draft BRSKI (Bootstrapping Remote Secure Key Infrastructures) lists steps for auto bootstrapping as follow: Pledge discovers a communication channel to a Registrar. 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) Pledge requests to join the discovered Registrar using a voucher request. Registrar sends the voucher request to the MASA (manufacturer). URL of MASA can be in the voucher request or embedded in Registrar. MASA sends the voucher which is passed to pledge. MASA sends the voucher which is passed to pledge. Pledge verifies the voucher and imprints to the registrar by send voucher status telemetry. Registrar verifies the voucher and enrolls the pledge to the domain Here pledge is the device to be added to networkdomain; 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.

EAP-NooB (Extensible Authentication Protocol Nimble out of Band) 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.

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 vendormanufacturer. 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. 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 MASADevice. 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.

The device has domain owners or registrars 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 owners digital signature certificate expires or is changed or is revoked, the digital signature of the owner cant 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 R1_old as old public key of Registrar and original digital invoice be 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. Let note of acceptance signed with new private key of R1 as follow: Verification will be done as per following steps: These steps can be chained for multiple chain of digital invoices.

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

Approach Security ConstraintsConsequence TOFU Vulnerable initial communication No authentication of initial assertion Resurrecting Duckling No owner authentication Anyone can be the owner 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 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 Easy offline authentication of both device and domain Public key is required for each buyer.

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.

This memo includes no request to IANA.

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.