Boot-IoT: A Privacy-Aware Authentication Scheme for Secure

Boot-IoT: A Privacy-Aware Authentication Scheme for Secure Bootstrapping of IoT Nodes Mahmud Hossain and Ragib Hasan {mahmud, ragib}@uab.edu Department of Computer and Information Sciences University of Alabama at Birmingham, AL 35294, USA Abstract—The Internet of Things (IoT) devices perform adversaries from tracing the locations of the IoT devices. security-critical operations and deal with sensitive information Furthermore, the research work modified existing network in the IoT-based systems. Therefore, the increased deployment access protocols, such as Extensible Authentication Protocol of smart devices will make them targets for cyber attacks. Adversaries can perform malicious actions, leak private infor- (EAP) [15] and Protocol for Carrying Authentication for mation, and track devices’ and their owners’ location by gaining Network Access (PANA) [16], to make them applicable to unauthorized access to IoT devices and networks. However, the IoT environment; but, relied on computation intensive conventional security protocols are not primarily designed for authentication methods, such as RSA X.509 certificate and Host resource constrained devices and therefore cannot be applied Identity Protocol (HIP) [17]. These methods are unsuitable for directly to IoT systems. In this paper, we propose Boot-IoT – a privacy-preserving, lightweight, and scalable security scheme for constrained smart devices which are most of the time battery limited resource devices. Boot-IoT prevents a malicious device driven and have limited computation power, storage capacity, from joining an IoT network. Boot-IoT enables a device to and communication bandwidth [18]. compute a unique identity for authentication each time the In this paper, we propose Boot-IoT – a security scheme device enters a network. Moreover, during device to device that authenticates IoT devices without revealing their identities. communication, Boot-IoT provides a lightweight mutual authentication scheme that ensures privacy-preserving identity usages. Boot-IoT provides security in two phases – Network access We present a detailed analysis of the security strength of Boot- phase and Service access phase. A device generates a oneIoT. We implemented a prototype of Boot-IoT on IoT devices time Device Identity (OTDI) by using Combined Public Key powered by Contiki OS and provided an extensive comparative (CPK) cryptosystem (see Section III-A) when it wants to join analysis of Boot-IoT with contemporary authentication methods. a network. Boot-IoT provides the device access to the network Our results show that Boot-IoT is resource efficient and provides after verifying its OTDI and issues the device a temporal Device better scalability compared to current solutions. ID (TDID), which is an Elliptic Curve Qu-Vanstone (ECQV) Keywords-Security, Privacy, Network Access, Service Access, implicit certificate. The device uses the TDID to access inThreat, Attack, Adversary, Internet of Things. network services and resources. During service access phase, communicating devices exchange their TDIDs securely for I. I NTRODUCTION mutual authentication. Therefore, adversaries cannot learn the The Internet of Things (IoT)-based systems are becoming identities of a service device and the client device. Every time ubiquitous in a wide range of application domains [1] due the device joins the network it generates a fresh OTDI and the to the recent advances in wireless communications and per- device is also issued a fresh TDID. Similarly, when a mobile vasive computing. Everyday, hundreds of physical things are IoT device leaves a network and joins another network at a getting connected to the Internet to share local information new site, then it generates a fresh OTDI. The mobile device to cyberspace [2]. However, the increased deployment of IoT- receives a new TDID at the new site. As a result, it becomes based systems brings some new challenges in security and impossible for adversaries to track the location of a device. privacy. Adversaries will find smart devices a very attractive Contribution: The contributions of this work are as follows: target of attacks. There are several cases where researchers 1) We have proposed a privacy-aware authentication method demonstrated the successful takeover of smart things [3, 4]. The based on CPK cryptography for secure network admission. attack strategies are simple and similar. First, an adversary gets 2) We have provided a privacy-preserving and ultra lightweight unauthorized access to an IoT network. Second, the adversary ECQV implicit certificate scheme for mutual authentication. eavesdrops on communications to learn about devices’ identity 3) We have presented a security analysis of Boot-IoT and credentials, such as cryptographic keys, certificates, and tokens. have implemented a prototype of Boot-IoT on the popular Finally, the adversary performs malicious actions in the IoT Contiki operating system for IoT devices and presented network towards another connected object impersonating a extensive experimental evaluation for Boot-IoT. legitimate device. The adversary can also use the identity information to launch privacy attacks, such as cyber espionage Organization: We present the threat model, background, and and warfare, on smart devices and their owners [5, 6]. related works in Section II, III and IV respectively. The details Researchers have proposed techniques to prevent malicious of architecture and operational model of Boot-IoT are described devices from accessing IoT resources, such as networks and in Section V and Section VI respectively. Section VII presents a services [7–14]. However, the proposed work do not consider security analysis of Boot-IoT. We provide experimental results the privacy-preserving identity usages; therefore, cannot prevent in Section VIII. Finally, we conclude in Section IX.

II. M OTIVATION AND T HREAT M ODEL

devices. The devices use certificates for mutual authentication (Figure 1). These certificates are exchanged in plain texts, and If the identity of a smart device is static and this identity is devices compute the Hash of the certificates as H(IC) to verify revealed during the authentication process, then an adversary their authenticities – Step 2 and 5 of the mutual authentication can trace the location of the device or its owner. The adversary process of Figure 1. However, In Boot-IoT, certificates are can attack the device or the owner knowing their whereabouts. obfuscated using a lightweight cryptographic technique, and For example, in connected car scenarios [19], a malicious smart devices do not compute hashes for certificates verification (see car being co-located with a victim car on a road tracks the Section VI-D). route of the victim. Later, the location information can be used Devicey Devicex CA to launch attacks, such as cyber-espionage, on the car or its a) Certificate Computation 1. Select r ϵ [1,n-1] owner [20]. Moreover, the malicious car can provides false 2. r *G information to the victim car which leads to an accident [21] 3. Select k ϵ [1,n-1] 4. Compute IC = r *G + k*G after recognizing the car by its identity on road. In smart home 5. e = H(IC ) 6. Certificate Signing s = ek + c (mod n) 7. s, IC scenarios, a compromised thermostat that communicates to the 8. Compute new pair (d Q ) home owner’s wearable medical device, can learn when the 9. d = r * H(IC ) + s (mod n) 10. Q = d *G wearable device joins and leaves the home network by looking 1. IC at the device’s identity. Adversaries can use these information 2. Q = H(IC ) * IC + Q to infer whether the owner is present at home and can break 3. k = d Q = d *d *G 4. IC into the home for burglary or to attack the residence [22]. The use of static identities can trigger DoS attacks during 5. Q = H(IC ) * IC + Q 6. k = d Q = d *d *G b) Mutual Authentication device to device communications. Let’s consider a scenario where a medical IoT device publishes the physical conditions Fig. 1: Implicit certificate-based authentication. of a patient to a Cloud IoT service periodically [23]. An attacker, who is residing in the same network with the medical IV. R ELATED W ORK device, learns about the identity of the device when it presents its static identity to the Cloud service for authentication Secure network admission schemes: Hernandez-Ramos et al. purposes. The adversary jams the communication channel [7] proposed an implementation of EAP for constrained devices. when it finds that the device is sending data to the Cloud CoAP-EAP [8] used CoAP [25] to transport EAP packets for service. Hence, the attacker blocks critical health information authentication. A lightweight version of PANA [16] has been from being transmitted to physicians, threating the life of the proposed in [9]. The use of HIP for the network access stage patient. Adversaries can come up with similar attack models is analyzed in [11]. However, none of these research works by exploiting IoT devices’ static identities. proposed a new authentication method that reduces computation Boot-IoT proposes authentication schemes that do not require and communication overheads on constrained devices; instead, devices to exchange their identities in plain texts. Moreover, relied on certificate, pre-shared key (PSK), and host identityBoot-IoT ensures that the authentication methods have less based schemes for authentication. However, certificate and host computation, communication, and memory overhead on devices identity-based schemes require computation intensive public compared to the current security schemes [10–13]. key cryptographic operations. PSK-based schemes provide a x

x

x

x

x

X

x, ,

x

x

x

x

x

x

x

x

uv

x

y*

x

x

y

ca

x

y

y

uv

III. BACKGROUND A. Combined Public Key (CPK) The CPK cryptosystem is based on the elliptic curve cryptography (ECC). Let G = (Gx , Gy ) is a base point on the elliptic curve, n is a prime number and has order G, and (d, Q) is an ECC key pair such that d and Q are elliptic curve private and public keys respectively: d ∈ [1, n − 1] and Q = (Qx , Qy ) which is the point Q = dG. One character of ECC key pair is that the combination of private keys and corresponding public keys in ECC is still a pair of elliptic curve keys. For example, d1 , d2 are private key in elliptic curve, the corresponding public keys are Q1 , Q2 , such that Q1 = d1 ∗ G, Q2 = d2 ∗ G; dt = d1 + d2 , Qt = dt ∗ G = (d1 + d2 ) ∗ G = (d1 ∗ G) + (d2 ∗ G) = Q1 + Q2 . So the combination of key pairs will generate a new key pairs. B. Implicit Certificates ECQV are one kind of implicit certificates [24]. A certificate authority (CA) has an ECC pair (c, QCA ) such that c ∈ [1, n − 1] and QCA = cG. The CA issues implicit certificates to smart

y

x*

y

y

x

ca

y

lower degree of scalability and security. Furthermore, these authentication methods do not provide support for privacyaware identity usages; hence, susceptible to location and targeted privacy attacks. Mutual authentication schemes: Kothmayr et al. [10] proposed a X.509 certificate-based DTLS scheme which does not consider scenarios for processing certificate chains and checking revocation lists; therefore, unsuitable for constrained devices. Garcia-Morchon et al. [11] proposed DTLS pre-shared key for mutual authentication. However, PSK-based schemes do not scale well and provide strong security. D-HIP [12] and HIP-TEX [13] reduce the computation overheads of the key exchange process; however, generate considerable amount of network traffics and increase a key establishment time. The authors in [26, 27] designed a two phase authentication schemes based on implicit certificates. Our mutual authentication method is also based on implicit certificates. However, unlike [26, 27], we protect the privacy of the certificates and reduce the cryptographic overheads of the certificate verification process.

APP2DRS

Public Network 6LowPAN Camera

DIP

DRS

NAS2DIP

6LBR NAS

D2NAS

D2D

Application APP2QR

Client and Service

Service

Fig. 2: System overview of Boot-IoT.

V. S YSTEM A RCHITECTURE The components of Boot-IoT framework are illustrated in Figure 2. A device manufacturer generates a QR code and attaches it to an IoT device. The manufacturer also publishes a mobile application for device registration. The owner of a device registers his/her device by using the application and QR code. The details of the components are as follows. QR code: The QR code contains information about the URL of the Device Registration Service and Device Identity Provider, the hardware number of the device, such as serial number (SN), and a one-time cryptographic key (δ ). Except for the key, other information is encoded in plain text. The key δ is encrypted using one-time pad encryption as δ ⊕ Hash(δ ).

DRS authenticates the device owner by checking her username and password. Step 5: The application provides the SN to the DRS. Step 6: The DRS retrieves the H(δ ) for the SN, signs the H(δ ) using the private key (Sdrs ) corresponds to the public key (Pdrs ) attaches to the DRS’s certificate. The DRS sends the signature (SignSdrs (H(δ ))) and H(δ ) back to the application. The DIP also marks the SN as USED; therefore, it rejects any future registration requests for SN. Step 7: The application decrypts the key as δ ⊕ H(δ ) ⊕ H(δ ) = δ . Step 8–9: The application and the DIP perform certificatebased mutual authentication and establish a secure channel. The application sends SN, δ , and SignSdrs (H(δ )) to the DIP. Step 10-11: The DIP computes hash of the δ and verifies the signature SignSdrs (H(δ ) using the DIP’s public key Pdrs ; thus, ensures that the δ has not been forged. Finally, the DIP computes H(SN) and stores the H(SN) and δ in its database. Hence, a device and the DIP shares δ which will be used to authenticate a device during the enrollment phase. QR

Application 1. Read QR Code

DIP

2.Udrs,Udip, SN, δ⊕H(δ)

SSL/TLS

Device registration service (DRS): Device manufacturers provide the DRS. An IoT device must be registered to the DRS; otherwise, the device cannot join a network and cannot provide or access services. The DRS stores the SN and Hash(δ ) of a device. The Hash(δ ) is used to decrypt δ ⊕ Hash(δ ). Device identity provider (DIP): The DIP maintains a three dimensional Public Key Matrix (PKM). The PKM is defined as u × v × w, such that u, v, and w represent the number of planes, rows, and columns respectively. An element of the PKM (Qi jk ) i , Qi ). An example of is the public key of an ECC pair (dIoT IoT the PKM is shown in Figure 4. The DIP stores the hash of the serial number Hash(SN) of a device and shares a one-time key δ with the device. The Mobile application transfers the Hash(SN) and δ to the DIP during the device registration process. A device and the DIP authenticate each other using the δ . The δ is used once, and after that it becomes obsolete.

DRS

3. Cert. based Auth. 4. Pass. based Auth. 5. POST /Udrs/SN 6. H(δ) || SingSdrs

7. Decrypt δ SSL/TLS

8. Cert. based Auth.

9. POST /Udip [SN, δ, SingSdrs] 10.Verify SingSdrs 11. Store SN, δ

Fig. 3: Device Registration

B. Enrollment

When a device boots up for the very first time, it registers a list of ECC public keys to the DIP. The NAS enables the device to communicate to the DIP. However, the NAS does not allow the device to access any devices and services in the local domain unless the device is authenticated. Mobile application: The mobile application reads the QR The DIP and the device authenticate each other by using code and retrieves δ ⊕Hash(δ ), SN, and URLs of the DRS and the one-time shared key δ . The DIP issues a list of cells from DIP. The application also decrypts δ ⊕ Hash(δ ) and transfers the PKM to an IoT device (Figure 4). The cells are selected δ and Hash(SN) to DIP securely. randomly and no two cells are selected from a same column. Network access service (NAS): It is the identity provider at The DIP executes Algorithm 1 for cell assignment. First, a the local domain. NAS verifies devices’ identities, provides plane (uid ) is selected from u number of planes randomly. Next, access to the local network, and issues Implicit Certificates. an array RIDs of length w is created such that the elements NAS interacts with the DIP to verify devices’ identities. of the array are the row indicies of the plane uid : RIDs[i] ∈ [1, v]. Let’s suppose that the PKM is a 4 × 4 × 4 matrix. The VI. O PERATIONAL M ODEL DIP assigns RIDsdevice-a = [Q111 , Q122 , Q133 , Q144 ] to a device; A. Device registration however, it might assign RIDsdevice-b = [Q121 , Q132 , Q143 , Q114 ] Figure 3 shows the device registration process. Step 1– to another device. Algorithm 1 ensures that no two devices are 2: The mobile application reads the QR code and retrieves the issued a same list of cells from the plane uid . Figure 4 shows URLs of the DRS (Udrs ) and DIP (Udip ), serial number (SN), an example of assigning a list of cells and steps to access them. and δ ⊕ H(δ ). Step 3-4: The application authenticates the DRS by verifying the DRS’s X.509 certificate. However, the The device enrollment process is shown in Figure 5.

Algorithm 1: Cell Assignment Output: Plane ID uid , RowIndices RIDs, Number of Column w 1: plane uid = Random()%u 2: occupiedCells = getOccupiedCells(PKM) 3: number of column w 4: number of rows v 5: rowIndices RIDs = new List(w) 6: for i = 1 to w do 7: j = Random()%v 8: while occupiedCells[uid ][i][ j] is true do 9: j = Random()%v 10: end while 11: RIDs.push( j) 12: end for 13: return {uid , RIDs, w}

Qu1w

Qu2w Q211 Q212 … Q21w . . Q22w Q … . 111 Q112 . Q121 Q122 … . Quvw . . .

PKM

DIP

1. Compute α = H(SN) and β=MACδ (α) 2. Send α || β

6. [uid, [RIDs], w] || MACδ

3. Retrieve δ for α 4. Verify β 5. Assign Cells

7. Verify MACδ (uid || [RIDs] || w) 8. Compute ECC pairs [(d1IoT,Q1IoT), …, (dwIoT,QwIoT)] 9. CT = E δ([Q1IoT, …,QwIoT]) || MAC δ ([Q1IoT, …,QwIoT])) 10. Verify MAC δ and Decrypt CT 11. Store [Q1IoT, …,QwIoT]) in PKM

12. QDIP 13. Destroy δ

Qu11 Qu12 …

Q2vw

Smart Device

. .

2

. . .

. .

Q1v1 Q1v2 … 1

Q11w Q12w

...

Q1vw

i = uid , j = RIDs[k] PKM [i][j] [k] = Qijk Row Indices i ϵ [1, …, u], j ϵ [1, …, v] 1 k ϵ [1, …, w] 2 . . . v

w Colum Indices

14. Destroy δ

Fig. 5: Enrollment

secure network access.

Cell Access (2)

Algorithm 2: Column and Row Indices Computation

Plane uid =1 1 1

2 2

…. ...

v RIDs w

List of Assigned Cells (1)

Fig. 4: An example of cell assignment.

Input: Private Keys S, Combination Keys Scomb Output: Column Indices CI, Row Indices RI 1: Bitstream CI = new BitStream of length w 2: List RI = new List () 3: for i = 1 to |S| do 4: if S[i] ∈ Scomb then 5: /* SET bit to 1 at position i */ 6: CI = CI | 1