]>
AutoAdd - Automatic Bootstrapping of IoT DevicesC-DAC Bangalore#68, Electronics CityBangalore560100Indiaanoop@cdac.inIETFIoT, Bootstrapping, EST, EAP-NooB, BRSKI, AutoAdd 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.
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 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. 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.ApproachSecurityConstraintsConsequenceTOFUVulnerable initial communicationNo authentication of initial assertionResurrecting DucklingNo owner authenticationAnyone can be the ownerESTTLS secured HTTP session between client and ServerBRSKIOnline service authenticating both device and domainMASA should be always online; No auto run of BRSKI on network or ownership changeEAP-NooBSecurity dependent on Ephemeral Elliptic
Curve Diffie-Hellman (ECDHE) key exchange and manual assistanceManual intervention for OOB authentication; Not ScalableAutoAddEasy offline authentication of both device and domainAutoAdd 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.
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.
&RFC7030;
&RFC2119;
The resurrecting ducklingSpringerPopular Internet of Things Forecast of 50 Billion Devices by 2020 Is OutdatedIEEE