Mutual Authentication in IoT Systems using Physical Unclonable Functions

Muhammad Naveed Aman, Kee Chaing Chua, and Biplab Sikdar Department of ECE, National University of Singapore, Singapore

Abstract—The Internet of Things (IoT) represents a great “headless” because these devices are not operated by a human opportunity to connect people, information, and things, which and have to make their own decisions [3]. Finally, many will in turn cause a paradigm shift in the way we work, interact, IoT devices will not have any batteries or a constant power and think. IoT devices are usually small, low cost and have limited resources, which makes them vulnerable to physical, side- source; they will rely on energy harvesting or wireless transfer channel, and cloning attacks. Therefore, any protocol designed of energy [2]. These properties make the task of designing for IoT systems should not only be secure but also efficient in security protocols for IoT systems very challenging. Thus, any terms of usage of chip area, energy, storage, and processing. To security protocol designed for IoT systems should have very address this issue, we present light-weight mutual authentication low processing, communication, and memory requirements. protocols for IoT systems based on Physical Unclonable Functions (PUFs). Protocols for two scenarios are presented, one when The existing security protocols and techniques of the In- an IoT device and server wish to communicate and the other ternet cannot be adopted for IoT systems due to two reasons when two IoT devices want to establish a session. A security and [3], [4]. First, the implicit assumption of the nodes having performance analysis of the protocols shows that they are not only unlimited power and memory is not valid in IoT systems. robust against different types of attacks, but are also very efficient Second, Internet devices are considered to be physically well- in terms of computation, memory, energy, and communication overhead. The proposed protocols are suitable for real time protected. Unlike the Internet, IoT devices are small, simple, applications and are an attractive choice for implementing mutual low cost, and are installed in locations where an adversary authentication in IoT systems. can capture them easily. Therefore, physical security of IoT devices is a major concern. For example, keys stored in the I.INTRODUCTION memory may be read off a physically captured device and The number of IoT devices has been increasing rapidly over used by an adversary to launch an attack. To address these the past decade, outnumbering humans by a ratio 1.5 to 1 as issues, we consider the use of hardware security primitives of 2014 [1]. IoT is envisioned as the enabling technology for based on physical unclonable functions, which work on a smart cities, power grids, health care, and control systems for challenge-response mechanism. In this paper we show how critical installments and public infrastructure. This diversity, PUFs can be used to eliminate the requirement of storing increased control and interaction of devices, and the fact that secrets in the nodes of a network. PUFs take advantage of the IoT systems use public networks to transfer large amounts inherent variability of the manufacturing/fabrication process of of data make them a prime target for cyber attacks. IoT integrated circuits (ICs). The output of the challenge-response security and human safety are tied to each other, e.g., causing mechanism of a PUF is correlated to the input and the physical accidents by disrupting vehicular networks, putting a patient (sub-)microscopic structure of the device. The random and at risk by tampering with a body network, causing blackouts uncontrollable effects of the IC fabrication process result in by interfering the smart grid, and causing accidents in nuclear the uniqueness of PUFs i.e., it is not possible to create two reactors etc. identical copies of a PUF. Network and Internet security has been an area of active One of the important security requirements in IoT systems research over the last two decades. However, existing se- is authentication. A device/user should be able to verify that curity mechanisms are far from perfect and major security the data received from another device/user is indeed collected breaches involving personal, corporate and government data by the stated sensor. Therefore, authentication is the first step are reported regularly. Similar to the Internet, IoT systems towards establishing a session after a secure boot of the IoT have a long way to go in terms of achieving the desired device. However, as mentioned previously, this authentication security level. The major areas of concern in the context of IoT must be done in a secure and efficient way, without saving systems are secure booting, authentication, privacy protection, any secrets in the IoT device’s memory. To address this data integrity, user profiling and tracking, access control, and issue, this paper presents a secure and light-weight mutual digital forgetting [2], [3], [4]. authentication protocol for IoT systems. The proposed protocol IoT devices can be considered as embedded systems that achieves the desired security and efficiency requirements using have the following properties. First, they are designed for a PUFs. The major contributions of this work are as follows: (i) specific task and have enough memory and processing power Design of a mutual authentication protocol using PUFs, which for that task [2], [3]. Second, IoT devices are considered has very low energy, memory, and communication overhead. 2

Moreover, the protocol is safe against physical attacks; (ii) A mechanism to establish a secure session key without any extra computational or communication overhead. The rest of the paper is organized as follows. In Sec- tion II, we discuss the related work. Section III gives a brief introduction to PUFs. Section IV discusses the network model, threat model, requirements and assumptions for our IoT system. Section V presents the proposed PUF based mutual authentication protocols. Section VI presents a security analysis of the proposed protocols and Section VII discusses the protocol simulations. We present a formal verification of the proposed protocols in Section VIII. Finally, in Section IX we present the performance analysis of the proposed protocols and conclude the paper in Section X.

II.LITERATURE REVIEW Fig. 1: Network model. The different security challenges for designing IoT sys- tems are outlined in [2]. The authors recommend the use authentication, which reduces the effectiveness of this protocol of hardware security primitives such as PUFs for securing in IoT systems. Moreover, their protocol can only be used IoT systems. A one-time password (OTP) based authentica- to perform authentication between a user and a server and tion protocol for IoT devices is presented in [5]. However, not for two devices authenticating each other. The use of the multiple iterations and the requirement of computing the ZKPK of discrete logarithm also increases the complexity of OTP using public/private keys increases the complexity and the protocol. computational burden of the algorithm. In another work [6], III.PRELIMINARY BACKGROUND the authors propose a group authentication protocol. However, collective authentication and key sharing among multiple Before presenting the proposed protocol, we first present a nodes puts multiple nodes at risk even if one of the nodes brief introduction to PUFs in this section. is compromised. A certificate-based authentication protocol A PUF may be regarded as a unique physical feature of a for distributed IoT systems is proposed in [7]. However, the device, just like the biometric features of human beings such cryptographic credentials are stored in the edge node, exposing as fingerprints. A good definition of a PUF is given in [17] as the protocol to cloning attacks. Similarly, other works like [8], “an expression of an inherent and unclonable instance-specific [9], [10] describe different mechanisms for authentication in feature of a physical object”. The most notable property of IoT systems. a PUF is that it cannot be reproduced using cryptographic PUFs have been previously used in authentication protocols primitives, rather, it requires a physical basis. Moreover, the for wireless sensor networks (WSNs) and radio-frequency term “physically unclonable” means that it can be shown identification (RFID) systems [11], [12], [13], [14], [15]. How- through physical reasoning that it is extremely hard or even ever, these PUF based as well as non-PUF based authentication impossible to produce a physical clone of a PUF [18]. So the protocols mentioned previously rely on some secrets (e.g. idea behind using a PUF in IoT systems is that just like human public/private keys) being stored in the memory of an IoT beings, every device will have a unique fingerprint in the form device. Some of these works propose to store the secrets in a of a PUF and this fingerprint cannot be reproduced or cloned. highly secure manner. However, even if the memory is highly In another place, a PUF is defined as “A Physical Un- secure the bits still need to be stored in a non-volatile digital clonable Function (PUF) is a function that maps a set of memory which opens doors for attackers. Moreover, some of challenges to a set of responses based on an intractably the PUF based authentication protocols require a trusted party complex physical system” [11]. Therefore, a PUF can be to store a large number of challenge response pairs (CRPs) considered as a function, which takes a challenge in the form for each IoT device [11], [12]. Given the increasing number of a string of bits and produces a response in the form of a of IoT devices, these protocols are not scalable. Moreover, string of bits. We represent a PUF as a function P as follows for PUF based authentication protocols, storing secrets locally R = P (C) (1) contradicts with the philosophy of using PUFs. The most relevant PUF based authentication protocol is pre- where R is the response of a PUF, while C is the challenge sented in [16]. The authors of [16] propose an authentication given to the PUF. A challenge C and its response R from a protocol based on PUFs that uses the zero-knowledge proof PUF is called a challenge response pair (CRP). PUFs have the of knowledge (ZKPK) of discrete logarithm. Their protocol following properties in terms of the response: does not reveal the CRP in any of its messages by using 1) The PUF produces the same response with the same the zero-knowledge proofs. However, their protocol requires challenge with high probability even if the same challenge a user to input a password to the device each time it requires is used multiple times. 3

TABLE I: Notations accidents. The objective of this paper is to develop a mutual Notation Description authentication protocol which is secure against different kinds of attacks including illegal user profiling, cloning attacks, man- IDi ID of the IoT device H(X) Hash of X in-the middle attacks, replay attacks, tampering attacks, and k Concatenation operator physical attacks. {M}k Message M is encrypted using key k D. Security Requirements Ci Challenge for the i-th iteration i i To achieve mutual authentication, we designed the proposed R Response of the respective PUF for C protocol according to the following security requirements: 2) The same challenge will produce responses far apart with 1) Achieve mutual authentication between an IoT device and high probability if it is input to different PUFs. a server or between two IoT devices. 2) Establish a secure session key between the two entities IV. NETWORK MODELAND ASSUMPTIONS before packet transmission. A. Network Model 3) Attacker cannot compromise the security of the scheme even if he/she captures an IoT device. Figure 1 describes our network model. In this model we have IoT devices connected to the Internet through border V. PROPOSED PUF BASED MUTUAL AUTHENTICATION router elements (e.g. based on 6LoWPAN). Each IoT device AND KEY EXCHANGE PROTOCOL is equipped with a PUF. The IoT devices send the information In this section we present the proposed mutual authentica- (over the Internet) to a server in the data center. tion protocol. The following two scenarios are considered for mutual authentication: B. Assumptions 1) An IoT device wants to establish a connection with a In this paper, we make the following assumptions regarding server in the data center. the system: 2) One IoT device wants to talk to another IoT device. a. An IoT device consists of an embedded system equipped The server starts with a single CRP for each IoT device. with a PUF. Any physical tampering with the PUF such as This initial CRP can be obtained by the server using the Time- an attempt to separate it from the embedded system will based One-time Password Algorithm (TOTP) mechanism [22]. destroy the PUF. When an IoT device is deployed in the field for the first time, b. The IoT device micro-controller and the PUF are con- an operator inputs a password into the device to exchange sidered to be a system on chip, and the communication the initial CRP with the server using the TOTP approach. between them is considered secure [19], [20]. Once the initial CRP is exchanged with the server, the IoT c. The data center is considered the trusted party and has device can function independently without the need for any no limitation of resources. However, the IoT devices have operator. Thus, the server stores the identity IDA, and the limited resources. CRP (Ci,Ri) for each IoT device, while the IoT device does d. Table I gives the set of notations used to describe the not store anything. protocol. A. Protocol 1: IoT Device and Server Mutual Authentication C. Attack Model The proposed mutual authentication protocol for the case IoT devices send their data to the data center server through when an IoT device and a server want to communicate with the Internet. We assume that the IoT devices use the standard each other is shown in Figure 2. The steps are as follows: or compressed (e.g. 6LoWPAN) TCP/IP protocol suite to 1) IoT device IDA sends its ID, IDA, and a randomly send data to the server [21]. The packets containing IoT generated nonce, N1, to the server. data may follow different paths and pass through multiple 2) The server tries to locate IDA in its memory and if communication links and network routers. We assume that the the search fails the authentication request is rejected. adversary may compromise one or more network entities and Otherwise, the server reads the CRP (Ci,Ri) stored in may even capture an IoT device. We assume the adversary its memory for this device. The server then generates a i can eavesdrop, inject packets, mimic other devices, initiate a random number RS1 and uses R to form the encrypted i session, and replay older messages. message MA = {IDA,N1,RS1 }R . The server then i The objective of the adversary is to gain authentication into sends C , MA, and the message authentication code the data center server or any of the IoT devices without being (MAC) to the IoT device IDA in message 2 in Figure 2. detected. By getting access into the data center server or an The MAC ensures data integrity and freshness. The first IoT device, the adversary wishes to launch various attacks with two parameters in the MAC function ensure data integrity the intention of causing physical or economical damage. For while the last parameter, i.e., RS1 serves as the freshness example, if vehicles equipped with IoT devices are talking to identifier for the source, which in this case is the server. the traffic light and the adversary manages to authenticate itself The same approach is followed for data integrity, message to the vehicles as the traffic light, it can cause large scale road freshness, and source identifier throughout the protocol. 4

Fig. 2: Mutual authentication for IoT device and server.

i 3) IoT device IDA generates R using its PUF and challenge i C as given in (1). The device then obtains RS1 using Ri and verifies the source, integrity, and freshness of the message using the MAC. If verification fails, IoT device IDA terminates the authentication. Otherwise, it generates a random number NA and computes the new i+1 response R by using the new challenge H(NA k RS1 ) and its PUF. This new CRP (Ci+1,Ri+1) will be used for future authentications. IoT device IDA then sends an encrypted message MS = i+1 i {IDA,RS1 ,NA,R }R and the corresponding MAC to the server and then deletes all the temporary variables i i+1 stored in its memory including RS1 ,NA,R ,C , and Ri+1. Fig. 3: Mutual authentication of two IoT devices. i+1 i 4) The server computes NA and R using R and verifies the MAC. If the verification fails, the server rejects tablish a session with another IoT device IDB. The mutual the authentication. Otherwise, mutual authentication is authentication protocol for this scenario is shown in Figure 3. considered complete and the two entities can now form The steps for the mutual authentication protocol are as follows:

a session. 1) IoT device IDA sends its ID, IDA, and a random nonce,

We can use RS1 and NA to construct a session key as N1, to IoT device IDB. follows 2) IoT device IDB sends the two ID’s IDA and IDB with the corresponding nonces to the server as shown H(R ) ⊕ H(N ). (2) S1 A in message 2 in Figure 3. We note that the session key is constructed using the hash of 3) The server searches its memory for IDA and IDB, and reads the respective CRPs (Ci,Ri), and (Cj,Rj). The the two random nonces RS1 and NA. Therefore, even if the session key is obtained by an adversary, he/she still cannot server then generates two random numbers RS1 and RS2 calculate Ri. and uses Ri and Rj to form the following encrypted messages B. Protocol 2: Mutual Authentication for Two IoT Devices j MB = {IDA,IDB,N2,RS1 ,RS2 }R (3) In this section we describe the mutual authentication and M = {ID ,ID ,N ,R ,R ,M } i . (4) key exchange protocol for the scenario when two IoT devices A A B 1 S1 S2 B R want to start a session and need to authenticate each other. The server then sends the challenges Ci and Cj along Consider a scenario where IoT device IDA wants to es- with MA and the two MACs to IoT device IDA. 5

i i 4) IoT device IDA obtains R using the challenge C and logical approaches for the security analysis of protocols is its PUF. It then carries out the following tasks: important to make sure an adversary cannot obtain or alter (i) It decrypts the received message using Ri to obtain vital information. The work of Burrows, Abadi, and Needham [23], called the BAN logic, has been widely used for the secu- RS1 , RS2 , and MB. (ii) It verifies the MAC. If the verification fails, IoT rity analysis of authentication and key distribution protocols. device IDA does not respond and terminates the However, Mao and Boyd [24] showed several weaknesses in current authentication attempt. the BAN logic and put forward an improved extension of the (iii) It generates a random number NA and computes the BAN logic. We analyze our mutual authentication protocols new challenge Ci+1 and new response Ri+1 from using the Mao and Boyd logic and show that the protocols are its PUF. secure against different types of attacks. For ease of notation, i+1 we represent IoT device IDA, IoT device IDB, and the server IoT device IDA sends R in an encrypted message by A, B, and S respectively. MS1 along with a MAC to the server as shown in message 4 in Figure 3. IoT device IDA sends another message A. Security Analysis For Protocol 1 M = {ID ,N } along with the corresponding MAC B1 A 3 In this section we present a security analysis of the mutual ID Cj to IoT device B. It also forwards the challenge , authentication protocol for an IoT device and a server. To M message B and the corresponding MAC received from establish the security claims of the proposed protocol, we the server to IoT device IDB. This is shown in message i+1 show that the secrets RS1 , NA, and R are good shared 5 in Figure 3. secrets between IoT device ID and the server (i.e. these N Ri+1 Ri A 5) The server obtains A and using . The server secrets cannot be obtained or altered by an adversary). To then verifies the MAC. If the verification fails, the server apply the Mao and Boyd logic, the first step is to idealize the rejects the new CRP. Otherwise, the server updates the messages of a given protocol. The details on protocol message ID CRP for IoT device A. idealization are given in the Appendix. We start the formal ID Rj 6) On receiving message 5, IoT device B obtains proof by presenting the idealized versions of the message Cj using and its PUF. It then carries out the following exchanged by protocol 1 as follows: tasks: 1) A → S : A, N1. (i) It decrypts M using Rj to obtain R , and R . B S1 S2 i 2) S → A : {A, N1RRS1 }R . (ii) It decrypts MB using RS to obtain the nonce N3. i+1 1 2 3) A → S : {A, RS RNARR }Ri . (iii) It verifies the corresponding MACs. If the verifica- 1 Note that our protocol uses MACs for effective data integrity tion fails, IoT device ID does not respond and B and origin verification which is a pre-requisite for the Mao terminates the current authentication attempt. and Boyd logic. To establish the security of shared secrets, (iv) It generates a random number N and computes the B the Mao and Boyd logic uses a set of inference rules. The set new challenge Cj+1 and new response Rj+1 from of inference rules used in our analysis can be found in the its PUF. Appendix. The initial beliefs/assumptions for Protocol 1 are j j+1 IoT device IDB uses R to encrypt and send R in given below: message MS along with a MAC to the server as shown i i 2 1) A A ↔R S and S A ↔R S: S saves a CRP for each in message 6 in Figure 3. IoT device IDB sends another IoT device in its memory while A can generate Ri by message as an acknowledgment to IoT device IDA, as shown in message 7 in Figure 3. using the respective challenge. j+1 j 2) A Sc/ k N and S A {S}c/kN : N is generated 7) The server obtains NB and R using R and verifies A A A by A. the corresponding MAC. If the verification fails, the i server rejects the new CRP. Otherwise, the server updates R 3) A |∼ NA: Message 3 in the idealized protocol. the CRP for IoT device ID . B 4) A #(N ) and A #(N ): A generates a new N 8) On receiving message 7, IoT device ID verifies the A 1 A A and N each time. MAC. If verification fails the authentication is rejected. 1 5) S #(R )): S generates a new R each time. Otherwise, the authentication is considered complete and S1 S1 6) A sup(S): S is the super principal with-respect-to RS1 . IoT device IDA and IoT device IDB have successfully authenticated each other. 7) S sup(A): A is the super principal with-respect-to NA and Ri+1. Similar to Section V-A, the two IoT devices can now use Ri 8) A /N1 R RS1 : Message 2 in the idealized protocol. RS1 and RS2 to establish a secret symmetric key. For example, i i R R i+1 H(RS1 ) ⊕ H(RS2 ) can be used as the session key between 9) S /RS1 R NA and S /RS1 R R : Message 3 in IoT device IDA and IoT device IDB. the idealized protocol. c c 10) A S {A} /kRS1 and S A /kRS1 : S generates a new VI.SECURITY ANALYSIS RS1 each time. In this section we present a formal security analysis of the 11) A {S}c/kRi+1 and S A {S}c/kRi+1 and A proposed mutual authentication protocols. The use of formal #(Ri+1): A computes a new response each time using 6

its PUF. NB. This shows that the proposed protocol is resilient against i R various kinds of attacks including replay attacks, tampering 12) S |∼ RS1 : Message 2 in the idealized protocol. Ri attacks, cloning attacks, interleaving attacks, eavesdropping, 13) A |∼ Ri+1: Message 3 in the idealized protocol. and man-in-the middle attacks etc. The tableau of Figure 4(b), shows the proof of the fact that C. Protection Against Cloning A believes N is a good shared secret between A and S. A A large number of IoT devices are deployed out in the open, To establish this fact, we write the statement to prove i.e., NA making them vulnerable to cloning attacks. However, each A A ↔ S at the bottom. Next we apply the good-key rule PUF has a unique output and it is not possible to recreate from (26). This rule states that NA is a good secret between a PUF [11], [12]. The proposed protocol exploits this unique A and S, if we can show that A is certain that no one else c feature of a PUF to prevent it from cloning attacks. In the except A and S has seen NA (A {A, S} / k NA) and proposed protocol each IoT device is equipped with its own that NA is a fresh nonce (A #(NA)). The confidentiality PUF and as it is not possible to clone a PUF, our proposed c rule from (23) can be used to prove A {A, S} / k NA, protocol is secure against cloning attacks. which requires us to show that A and S share a good secret i D. Protection against Physical Attacks i R R (A A ↔ S), and A sent NA to S encrypting it with Ri One of the security requirements for IoT devices outlined i R (A |∼ NA). We observe that these statements as well as in Section IV-D is that an IoT device should not expose any A #(NA) can be found in the set of initial beliefs. Thus, we secrets even if it is captured by an attacker. As described in N can infer the truth of our initial statement i.e., A A ↔A S. Section II, most of the authentication protocols proposed in existing literature require the device to store one or more Similarly, Figure 4(a) establishes the fact that RS is a good 1 secrets. This requirement greatly reduces the effectiveness shared secret between A and S. Similar analysis for NA and of these protocols as it makes them susceptible to physical RS1 on the site of principal S is shown in the tableaux of Figures 4(c) and 4(d) respectively. We can conduct a similar attacks. The proposed mutual authentication protocol has two analysis to prove the secrecy of Ri+1 as given in the tableaux features which safeguard it against physical attacks. First, of Figures 4(e) and 4(f), respectively. the devices do not need to store any secrets. Second, the i i+1 communication between the IoT device’s micro-controller and Without the knowledge of R , R , RS1 , and NA it is not possible for an adversary to construct valid data. It does not its PUF is considered to be secure as they are on the same matter what kind of attack the adversary uses, the adversary chip [19]. Thus, even if an attacker has physical access to an cannot obtain these secrets as shown in the formal proofs. IoT device, he/she cannot obtain any secrets. This shows that Moreover, even if the attacker captures the IoT device, he/she our proposed mutual authentication protocol is secure against cannot obtain a valid CRP or any other secret because the physical attacks. device does not store any secrets and any attempt to remove VII.SIMULATIONS the PUF from the IoT device destroys the PUF and makes it The security properties of the proposed protocols were ver- useless. Therefore, the proposed protocol is considered safe ified using rigorous simulations and experimentation using the against all the major security attacks such as the spoofing at- security verification tool ProVerif (PV) [25]. PV is considered tacks, cloning attacks, interleaving attacks, man-in-the-middle to be sound (correct) in proving security properties [25] and attacks, eavesdropping, and replay attacks. can thus be used to prove reachability properties, observational B. Security Analysis of Protocol 2 equivalence, and correspondence assertions. We model the IoT devices and the server as separate processes and simulate In this section we present the security analysis for the arbitrarily many sessions of the protocol between the protocol proposed mutual authentication protocol for two IoT devices. entities. The simulation scripts for the proposed protocols can Following the same approach as the previous section, the be downloaded from [26]. idealized versions of the messages exchanged during protocol 2 are given as follows: A. Protocol 1 Simulation

1) A → B : A, N1. The primary objective of protocol 1 is to ensure mutual au- 2) B → S : A, B, N1|N2. thentication of the IoT device IDA and the server. Therefore,

j i 3) S → A : {A, B, N1RRS1 RRS2 , {A, B, N2RRS1 RRS2 }R }R . when the protocol reaches the end and the IoT device IDA i+1 i 4) A → S : A, {A, NARRS1 RR }R . believes it has completed the protocol with the server, then IoT A → B : {A, B, N RR RR } j , {A, N } . 2 S1 S2 R 3 RS2 device IDA has indeed engaged in a session with the server. j+1 j 5) B → S : {B,NBRRS2 RR }R . Similarly, when the server reaches the end of the protocol, it The tableaux created using the Mao and Boyd logic for has indeed engaged in a session with the IoT device IDA. To prove the desired security properties of the proposed protocol the security analysis of the secrets RS1 and RS2 on the site of principals A and B are shown in Figure 5. Again, an we define the following events in PV: adversary cannot compromise the proposed protocol without • event beginAfull(IDA,IDS,NA,NB) is used by the i j i+1 j+1 the knowledge of R , R , R , R , RS1 , RS2 , NA, and server to record the belief that the IoT device IDA with 7

i i Ri V R i R A A↔S A /N1 R V c V A A↔S A S /kNA A |∼NA A #(N ) V 1 i V A #(N ) R i Ri A R V c A S |∼N1 A A↔S A /RS1 A {A,S} /kNA V c V A S {A} /kRS Ri 1 Ri A S A↔S NA A S |∼RS1 Ri A A ↔ S V A sup(S) A /N1 R RS V 1 A S {A,S}c/kR A #(N1) S1 A/N1 R RS1 V A sup(S) V c (b) Proof of “A believes NA is a good A {A,S} /kRS1 A #(RS1 )

RS shared key of A and S”. A A ↔1 S

(a) Proof of “A believes RS1 is a good shared key of A and S”.

i i Ri R i R V R V c V S A↔S S /RS1 S A↔S S A /kRS S |∼RS V 1 1 V S #(RS ) S #(RS ) 1 Ri i 1 Ri R c V S {A,S} /kRS S A |∼RS1 S A↔S S /NA 1 c V S A {S} /kN V R i A i S1 S A AR↔S R S A ↔ S S A |∼NA Ri V S sup(A) S /RS1 R NA c V S A {A,S} /kN S #(RS1 ) A S/RS1 R NA V (d) Proof of “S believes RS1 is a good c S {A,S} /kNA S #(NA) shared key of A and S”.

N S A ↔AS

(c) Proof of “S believes NA is a good shared key of A and S”.

i i Ri R i R V R V c i+1 V i+1 S A↔S S /RS1 A A↔S A S /kR A |∼R V V i+1 S #(RS1 ) i A #(R ) R i i c i+1 R V R i+1 A {A,S} /kR S A |∼RS1 S A↔S S /R V c i+1 V S A {S} /kR Ri+1 Ri Ri A A ↔ S S A A↔S i+1 i S A |∼R R i+1 V S /RS R R S sup(A) V 1 c i+1 S #(RS1 ) i+1 S A {A,S} /kR S/RS R R i+1 V 1 (f) Proof of “A believes R is a good S {A,S}c/kRi+1 S #(Ri+1) shared key of A and S”. i+1 S AR↔ S

(e) Proof of “S believes Ri+1 is a good shared key of A and S”. Fig. 4: Security Proofs for Protocol 1

shared secret NA has commenced a run of the protocol Note that in PV the statement EA ==> EB is used with it (where NB is the shared secret of the server). to check the fact “if an event EA has been executed, • event endAfull(IDA,IDS,NA,NB) which means the then it has been preceded by the execution of event EB IoT device IDA has successfully completed the protocol previously.” with the server, and the two parties agree to the shared 2) Authentication of IoT device IDA to the server: The secrets NA and NB. server can establish a session with any of its client • event beginBfull(IDA,IDS,NA,NB) which denotes IoT devices. Thus, if it believes it has completed the IoT device IDA’s intention to launch the protocol with protocol with IoT device IDA, authentication from IoT the server with the given protocol parameters. device IDA to the server should hold. The following • event endBfull(IDA,IDS,NA,NB) which means the correspondence assertion is used to prove this property server has successfully completed the protocol with IoT in PV: device ID with the given protocol parameters. A inj − event(endAfull(··· )) ==> The protocol is expected to satisfy the following properties: inj − event(beginAfull(··· )). (6)

1) Authentication of the server to IoT device IDA: IoT 3) Secrecy for IoT device IDA and the server: If IoT device IDA intends to to share its data only with the device IDA completes a run of the protocol with the

server. Thus, if it believes it has executed the protocol server, then the secrets NA and RS1 that IoT device IDA with the server, then IoT device IDA indeed completed has are good secrets. In PV we can check which terms the protocol with the server. Thus, authentication of the are available to an attacker by querying an attacker. We server to IoT device IDA holds. PV uses correspon- prove the secrecy of a term by using it as a session key to dence assertions to prove authentication. We define the encrypt an arbitrary term M and then checking whether following correspondence assertions in PV to prove this an attacker can successfully obtain M. The syntactic i+1 property: secrecy of NA, RS1 , and R is established using this inj−event(endBfull(··· )) ==> inj−event(beginBfull(··· )). (5) 8

i i Ri V R Ri V R A A↔S A /N1 i A A↔S A / (RS1 ,B) V R V c V A #(N1) A S A↔S A S S /kRS Ri 1 Ri i Ri V R A S |∼N1 A S |∼(RS ,B) A A↔S A /RS V 1 V 1 i i R c R A S A↔S A S {B,S} /kRS1 A S |∼RS1 Ri V A sup(S) A /N1 R RS V 1 A S {A,B,S}c/kR A #(N1) S1 A/N1 R RS1 V A sup(S) V c A {A,B,S} /kRS1 A #(RS1 )

RS A A ↔1 B

(a) Proof of “A believes RS1 is a good shared key of A and B”.

i i Ri V R Ri V R A A↔S A /N1 i A A↔S A / (RS2 ,B) V R V c V A #(N1) A S A↔S A S S /kRS Ri 2 Ri i Ri V R A S |∼N1 A S |∼(RS ,B) A A↔S A /RS V 2 V 2 i i R c R A S A↔S A S {B,S} /kRS2 A S |∼RS2 Ri V A sup(S) A /N1 R RS V 2 A S {A,B,S}c/kR A #(N1) S2 A/N1 R RS2 V A sup(S) V c A {A,B,S} /kRS2 A #(RS2 )

RS A A ↔2 B

(b) Proof of “A believes RS2 is a good shared key of A and B”.

j j Rj V R Rj V R B B↔S B /N2 j B B↔S B / (RS1 ,A) V R V c V B #(N2) B S B↔S B S S /kRS Rj 1 Rj j Rj V R B S |∼N2 B S |∼(RS ,A) B B↔S B /RS V 1 V 1 j j R c R B S B↔S B S {A,S} /kRS1 B S |∼RS1 Rj V B sup(S) B /N2 R RS V 1 B S {A,B,S}c/kR B #(N2) S1 B/N2 R RS1 V B sup(S) V c B {A,B,S} /kRS1 B #(RS1 )

RS B A ↔1 B

(c) Proof of “B believes RS1 is a good shared key of A and B”.

j j Rj V R Rj V R B B↔S B /N2 j B B↔S B / (RS2 ,A) V R V c V B #(N2) B S B↔S B S S /kRS Rj 2 Rj j Rj V R B S |∼N2 B S |∼(RS ,A) B B↔S B /RS V 2 V 2 j j R c R B S B↔S B S {A,S} /kRS2 B S |∼RS2 Rj V B sup(S) B /N2 R RS V 2 B S {A,B,S}c/kR B #(N2) S2 B/N2 R RS2 V B sup(S) V c B {A,B,S} /kRS2 B #(RS2 )

RS B A ↔2 B

(d) Proof of “B believes RS2 is a good shared key of A and B”. Fig. 5: Security Proofs for Protocol 2

i+1 approach in PV as follows: secrecy of NA, RS1 , and R on the site principal of the server is proved using BNa, BNb, and BR new, query attacker(ANa); attacker(BNa); (7) respectively. The PV simulations show that the proposed attacker(ANb); attacker(BNb); (8) protocol is secure against any definite or possible attack. attacker(AR new); attacker(SR new) (9) B. Protocol 2 Simulation where, ANa, ANb, and ARnew are used to prove the i+1 The primary objective of protocol 2 is the mutual authen- secrecy of NA, RS1 , and R , respectively, on the site of tication of principals IoT device IDA and IoT device IDB principal IoT device IDA, i.e., we encrypt these arbitrary terms using the respective secrets and then check whether using the server as the trusted party. We define the following an attacker can obtain these terms. For example, the events in PV to prove the desired security properties: arbitrary term ANa is encrypted using NA and is sent • event beginAfull(IDA,IDB,NA,NB) which is used by IoT device IDA on an open channel. Later we check by IoT device IDB to record IoT device IDA’s intention whether ANa is available to an attacker. Similarly, the to commence the protocol with IoT device IDB using NA and NB as the shared secrets. 9

• event endAfull(IDA,IDB,NA,NB) records IoT de- the end of the protocol then the secrets RS1 , RS2 , NB, j+1 vice IDA’s belief that it has successfully completed the and R are good secrets at the site principal of IoT protocol with IoT device IDB with NA and NB being device IDB. The PV queries for this property are as the shared secrets . follows: • event beginBfull(ID ,ID ,N ,N ), which repre- A B A B query attacker(BRs1); attacker(BRs2); (14) sents the IoT device IDA’s intention to initiate the pro- tocol with the IoT device IDB using the given protocol attacker(BNa); attacker(BR new); (15) parameters. j+1 where the secrecy of Rs1, Rs2, NA, and R is • event endBfull(IDA,IDB,NA,NB), which means IoT checked using the arbitrary terms BRs1, BRs2, BNa, device IDB has successfully completed the protocol with and BR new, respectively. the IoT device IDA with the given protocol parameters. 6) Secrecy for the server: If the server believes it has The desired security properties proved for protocol 2 are as successfully completed the protocol with IoT device IDA i+1 follows: and IoT device IDB, then RS1 , RS2 , NA, NB, R , and Rj+1 are good secrets at the site principal of the server. 1) Authentication of IoT device ID to IoT device ID : B A We use the following PV queries to prove this property: IoT device IDA intends to engage in a session with IoT device IDB. Hence, if it completes the protocol, it has query attacker(SRs1); attacker(SRs2); (16) indeed done so with IoT device IDB and the two parties attacker(SNa); attacker(SNb); (17) agree on the set of given protocol parameters. We prove attacker(SR newA); attacker(SR newB); (18) this property in PV as follows: SRs1 SRs2 SNa SNb SR newA inj − event(endBfull(··· )) ==> where , , , , , and SR newB are used to prove the secrecy of RS1 , RS2 , inj − event(beginBfull(··· )). (10) i+1 j+1 NA, NB, R , and R , respectively at the site prin- cipal of the server. 2) Authentication of IoT device IDA to IoT device IDB: If IoT device IDB believes it has reached the end of the Running the simulation script for protocol 2 in [26] in PV protocol with IoT device IDA, it has indeed done so with shows that the proposed protocol satisfies all the desired IoT device IDA. We use the following correspondence security properties. assertion using the following: VIII.VERIFICATION inj − event(endAfull(··· )) ==> In this section we provide a formal verification for the inj − event(beginAfull(··· )). (11) correctness of the proposed protocols. A protocol is considered

3) Authentication of IoT device IDA and IoT device IDB correct if it possesses the following properties [27]: to the server: Each time an authentication protocol is 1) Completeness: All valid inputs are accepted by the run, the server needs to update its CRP for the respective protocol. IoT device. In protocol 2, the server needs to update the 2) Deadlock freeness: The protocol does not enter a state CRPs for both IoT device IDA and IoT device IDB. For where it can stay indefinitely. this purpose it is also desirable that mutual authentication 3) Livelock or tempo-blocking freeness: There are no between the respective IoT devices and the server is infinite loops in the protocol. also satisfied. The authentication properties between IoT 4) Termination: The protocol always reaches a well-defined device IDA and the server, and IoT device IDB and the final state starting from the initial state. server are proved in a similar fashion as protocol 1 and 5) Absence of non-executable interactions: The protocol can be found in [26]. only contains transmission, reception, and interaction 4) Secrecy for IoT device IDA: If IoT device IDA com- paths realizable under normal operating conditions.

pletes the protocol successfully then the secrets RS1 , RS2 , i+1 We use a finite state machine (FSM) and reachability analysis NA, and R can be considered good secrets at the site technique proposed in [27] to verify the correctness of the principal of IoT device IDA. We establish the syntactic proposed protocols. Note that this section provides a proof that security of these secrets using the following queries in the protocol is correct with respect to its specifications, and PV: does not provide any proof of security. The security analysis query attacker(ARs1); attacker(ARs2); (12) of the protocol is given in Section VI. The first step to prove the correctness of the protocol using attacker(ANa); attacker(AR new); (13) [27] is to represent each entity of a protocol as a directed where ARs1, ARs2, ANa, and AR new are arbitrary graph. The directed graphs for the two entities in Protocol 1 are

terms used to check the secrecy of RS1 , RS2 , NA, and shown in Figure 6, where gA and gserver represent the directed i+1 R , respectively, at the site principal IoT device IDA. graphs for IoT device IDA and the server, respectively. Each 5) Secrecy for IoT device IDB: If IoT device IDB reaches of these directed graphs can be considered as an FSM for that 10

Fig. 6: Directed graphs for Protocol 1.

Fig. 8: Reachability analysis for Protocol 1.

  A A → B A → Server  STATE CHANNEL CHANNEL       B → A B B → Server    . (20)  CHANNEL STATE CHANNEL       Server → A Server → B Server  Fig. 7: Directed graphs for Protocol 2. CHANNEL CHANNEL STATE Each element in the above matrices represents either the entity. Similarly, the directed graphs for the three entities of current state of the FSM of an entity or a message sent by an Protocol 2 are shown in Figure 7. The state of the protocol entity. In (19), the element in row 1 and column 1 represents machine is represented by numbers in the nodes, while -n and the state of entity A while the element in row 1 and column 2 +n represents the transmission and reception of a message, represents the message sent by A to the server. Similarly, the respectively. Moreover, transitions or events are represented element in row 2 and column 1 represents the message sent by the integer labels on the arcs joining two states i.e., +m/- by the server to A while the element in row 2 and column 2 n represents the reception of a message m followed by the represents the current state of the server entity. For example, transmission of message n. For example, the interaction paths at the start of a protocol all the protocol entities are in their for g and g corresponding to one run of Protocol 1 are A S start states i.e, S0, and the channels are empty, as shown in given below: Figures 6 and 7. Let us consider protocol 1, in which IoT ID • gA : [0] − 1[1] + 2/ − 3[0] device A sends message 1 to the server. This will cause a ID S • gS : [0] + 1/ − 2[1] + 3[0] transition in the state of the FSM of IoT device A from 0 to S1, as shown in Figure 6. The overall system state matrix where “[]” denotes a state in Figure 6. The interaction path is then given as follows: for IoT device IDA represents the following sequence of   S1 1 activities: IoT device IDA starts in state 0, sends message . (21) ES0 1 to the server and enters state 1 of its FSM. IoT device IDA then sends message 2 and receives message 3, entering state 0 The element at row 1 and column 1 of (21) shows that IoT again. We can similarly interpret the interaction patch for the device IDA is in state 1, while the element at row 1 and server. Moreover, S0 is considered the final state for both IoT column 2 of the matrix shows that IoT device IDA has sent device IDA and the server in case of Protocol 1. However, S4 message 1 to the server. Moreover, this matrix also shows that is considered the final state for IoT devices IDA and IDB, the server is in state 0 (row 2 and column 2) and has not while S0 is the final state for the server in the case of Protocol sent any message to IoT device IDA (row 2 column 1). We 2. represent the overall system state by SSi, while the state of We use the reachability analysis technique proposed in [27], the constituent subsystems (entities) is represented by Si. [28] to prove that our protocol possesses the properties (1) - We always start the reachability analysis from the initial (5). Figures 8 and 9 show the result of the reachability analysis state SS0. This is the state in which all the channels are for the proposed protocols. In this technique a matrix is used empty, i.e., E, and all the protocol entities are in their initial +i −i to represent the state of the overall system. This matrix is states, i.e, S0. Moreover, X and X represent the reception constructed using the states of all the entities in the protocol. and transmission of message i by entitiy X, respectively. The Equations (19) and (20) show the state matrices for protocol reachability analysis for protocols 1 and 2 is shown in Figures 1 and 2, respectively. 8 and 9, respectively. Figure 8 shows a sequence of transitions for the overall   system state for protocol 1. When IoT device IDA sends A A → Server message 1, the overall system state transitions from the initial  STATE CHANNEL    state SS0 to SS1, followed by subsequent transitions. Figure   (19)  Server → A Server  8 shows that the protocol accepts all valid messages implying CHANNEL STATE the completeness property. We defined a potential deadlock 11

Fig. 9: Reachability analysis for Protocol 2. state as an overall system state in which all the channels are TABLE II: Computational Complexity empty and it is not an initial or final state. We observe that Task IoT Device Server Figure 8 does not have any potential deadlock states, implying Protocol 1 1NH + 2NMAC + 2NENC 1NH + 2NMAC + 2NENC deadlock freeness. We also observe that there are no loops [16] 2NH + 2Nexp + N× 1NH + 3Nexp among the overall system states implying livelock or tempo- Protocol 2 1NH + 4NMAC + 3NENC 2NH + 4NMAC + 4NENC blocking freeness. Moreover, Figure 9 covers all the possible transmissions, interaction paths, receptions and states and we see that following any of the interaction paths we always end that the reachability analysis of Protocol 2 covers all the up in the state SS0. This shows that the protocol possesses the interaction paths, states, transmissions, and receptions. This termination property and does not possess any non-executable shows that the proposed protocol does not contain any non- interactions. Thus, the proposed protocol is considered to be executable interactions. This proves that the proposed protocol correct. is correct.

The reachability analysis for Protocol 2 shows that SS18 IX.PERFORMANCE ANALYSIS is the final state for Protocol 2, i.e., the channels are empty In this section we present a performance analysis of the and all the subsystems are in their respective final states. We proposed protocols and compare it with the most relevant observe that Protocol 2 always starts from the initial state protocol in literature, proposed by Frikken et al. [16]. SS0 and terminates at the final state SS18, implying the termination property. The protocol has one potential deadlock A. Computational Complexity state i.e., SS16. However, SS16 has outgoing transitions Table II shows the number of hash (NH ), MAC involving a decision based on the random numbers N1 and (NMAC ), encryption/decryption (NENC ), modular exponen- N2 in the protocol. Note that SS16 is observed by the system tiation (Nexp), and modular multiplication (N×) operations when both IoT devices IDA and IDB attempt to initiate required by the proposed mutual authentication protocols and authentication concurrently. We assume that the protocol uses [16]. We can directly obtain these values by counting the the random nonces N1 and N2 to break the tie. For example, occurrence of the respective operations in Figures 2 and 3. if N1 > N2 then IoT device IDA gets to act as the initiator Let us assume the use of message authentication codes of the authentication and IoT device IDB sends message 2 based on universal hashing (UMACs) [29], that have a worst to the server and vice versa. This leads to IoT device IDB case running time of O(n) [30], [31], where n is the message transitioning to state 2 as shown by the overall system state size. Moreover, let us assume the use of block ciphers. Then SS3. This shows that the proposed protocol possesses the the encryption and decryption operations can be considered deadlock freeness property. We observe that there are no O(n). Thus, the proposed protocols have a complexity of loops in Figure 9. Therefore, the proposed protocol can be O(n) for the IoT devices as well as the server. However, considered free from livelocks or tempo-blocking. We observe the technique in [16] requires hash operations and modular 12

TABLE III: Parameter Lengths X.CONCLUSIONS Parameter Size (bits) This paper presented mutual authentication protocols for ID 8 [35] two different scenarios in IoT systems: (i) for cases when N1, N2 48 [36] an IoT device and a server want to communicate with each

NA, RS1 , RS2 128 [33] other, and (ii) for the case when two IoT devices want to C, R 128 [33] communicate with each other. The proposed protocols are MAC 32/64/96/128 [29] based on a challenge-response mechanism using PUFs and have the unique security feature of not saving any secrets in the IoT devices, while keeping the storage requirements at the exponentiation. Therefore, the complexity of their protocol server to the minimum. Moreover, a session key can also be is O(n + M(l)k) for both the IoT devices as well as the established using the proposed protocols. Performance analysis server, where M(l) represents the complexity of a general of the proposed protocols shows that they have very low modular multiplication with l bit operands, and k is the the computation, storage, and communication overhead. However, exponent. Moreover, M(l) is generally quadratic in l [32]. to use these protocols for applications with strict timing Thus the computational complexity of the proposed mutual requirements such as vehicular networks, it is desirable to authentication protocols is lower. further reduce the latency of authentication by reducing the number of messages exchanged between the entities. B. Communication Overhead

We observe that message 2 is the longest message in REFERENCES Protocol 1, while message 3 is the longest message in Protocol 2 as shown in Figures 2 and 3. To calculate the length of [1] The Internet of Things Reference Model, CISCO, 2014, http://cdn.iotwf.com/resources/71/IoT Reference Model White these messages we use the parameter sizes given in Table Paper June 4 2014.pdf. III. We assume the use of block ciphers such as CLEFIA [2] T. Xu, J. B. Wendt, and M. Potkonjak, “Security of IoT Systems: Design with 128-bit keys [33]. Note that the parameters in Table Challenges and Opportunities,”Proceedings of IEEE/ACM ICCAD, pp. 417-423, San Jose, CA, November 2014. III which are used to encrypt data in the proposed protocols [3] Security in the Internet of Things, Wind River, January 2015, http: are 128-bit long. Moreover, we assume the use of UMAC as //www.windriver.com/whitepapers/security-in-the-internet-of-things/ the MAC, which provides the flexibility in meeting security wr security-in-the-internet-of-things.pdf. [4] G. Woo, P. Kheradpour, D. Shen and D. Katabi, “Gartner Says the as well as performance needs [29]. UMAC offers MACs of Internet of Things will Transform the Data Center,” Gartner, March varying lengths as given in Table III. 2014. For the purposes of calculating the communication over- [5] Shivraj, V.L., Rajan, M.A., Singh, M., and Balamuralidhar, P., “One time password authentication scheme based on elliptic curves for Internet head, we use a MAC length of 32 bits. Thus, the length of Things (IoT),” Proceedings of National Symposium on Information of message 2 in Protocol 1 is 42 bytes, while the length of Technology: Towards New Smart World (NSITNSW), pp.1-6, Riyadh, message 3 in Protocol 2 is 120 bytes1. Moreover, the longest KSA, February 2015. [6] P. N. Mahalle, N. R. Prasad, and R. Prasad, “Threshold Cryptography- message in [16] is approximately 68 bytes which is much based Group Authentication (TCGA) Scheme for the Internet of Things larger compared to Protocol 1. (IoT),” Proceedings of IEEE VITAE, pp. 1-5, Aalborg, Denmark, May 2014. C. Storage Requirement [7] P. Porambage, C. Schmitt, P. Kumar, A. Gurtov, and M. Ylianttila, “Two-phase Authentication Protocol for Wireless Sensor Networks in The proposed protocols are very efficient in terms of storage Distributed IoT Applications,” Proceedings of IEEE WCNC, pp. 2728- requirements. Variables such as NA, NB, RS , and RS 2733, Istanbul, Turkey, April 2014. 1 2 [8] X. Yao, X. Han, and X. Du,“A Lightweight Multicast Authentication are only stored temporarily during authentication and deleted Mechanism for Small Scale IoT Applications,” IEEE Sensors Journal, i i afterward. Moreover, only one CRP pair (C ,R ), and the vol.13, no.10, pp.3693-3701, Oct 2013. respective IDi are stored for each IoT device in the server. [9] V. Petrov, S. Edelev, M. Komar, and Y. Koucheryavy,“Towards the Era of Wireless Keys: How the IoT Can Change Authentication Paradigm,” In contrast, most of the protocols in existing literature impose Proceedings of IEEE WF-IoT, pp.51-56, Seoul, South Korea, Mar 2014. one the following requirements: [10] Y. Kim, S. Yoo, and C. Yoo,“DAoT: Dynamic and Energy-aware 1) The IoT devices store secret information. Authentication for Smart Home Appliances in Internet of Things,” Proceedings of IEEE ICCE, pp.196-197, Las Vegas, NV, Jan 2015. 2) The server stores a large number of CRPs for each IoT [11] G. E. Suh, and S. Devadas “Pysical Unclonable Functions for Device device. One of the CRPs is used each time the server Authentication and Secret Key Generation,” Proceedings of IEEE/ACM authenticates an IoT device. Given the large number of DAC, pp. 9-14, San Diego, CA, June 2007. [12] P. Tuyls, and L. Batina, “RFID-tags for Anti-Counterfeiting, Topics in IoT devices, this approach is not scalable. Cryptology CT-RSA”, Lecture Notes in Computer Science, Vol. 3860, The proposed mutual authentication protocols do not impose pp.115-131, San Jose, CA,2006. [13] P. Cotese, F. Gemmiti, B. Palazzi et al., “Bernardo, Efficient and these requirements and have very low storage requirements. Practical Authentication of PUF-Based RFID Tags in Supply Chains,” Proceedings of IEEE RFIDTA, pp. 182-188, Guangzhou, China, June 1Note that 6LoWPAN has a maximum transmission unit (MTU) size of 2010. 127 bytes [34]. Although the maximum length of messages in the proposed [14] H. Ghaith, O. Erdinc, and S. Berk, “A Tamper-Proof and Lightweight protocols is less than 127 bytes, the addition of IP and other headers may Authentication Scheme”, Pervasive Mobile Computing, Vol.4, no.6, pp. result in fragmentation of the packets at the 6LoWPAN adaptation layer [34]. 807-818, 2008. 13

[15] Y. S. Lee, H. J. Lee, and E. Alasaarela, “Mutual Authentication in • #(M): M is fresh (not used before). Wireless Body Sensor Networks (WBSN) based on Physical Unclonable • sup(S): Principal S is the trusted party. Function (PUF),” International Wireless Communications and Mobile Computing Conference (IWCMC), pp.1314-1318, Sardinia, July 2013. • P/ k M: Message M is not available to principal P . [16] K. Frikken et. al., “Robust Authentication Using Physically Unclonable Next, we present some definitions to understand the rules Functions”, In: P. Samarati et al. (eds.): ISC 2009, LNCS 5735, pp. 262-277, Springer, Heidelberg 2009. for protocol message idealisation. [17] R. Maes, “Physically Unclonable Functions: Constructions, Properties • Atomic Message: A piece of data in a message con- and Applications,” Katholieke Universiteit Leuven Belgium DEngg Thesis, 2013. structed without using any of the symbols “,”, “|”, “R”, or [18] C. Bohm, and M. Hofer, “Physical Unclonable Functions in Theory and “{}” is called an atomic message. We use “,” to separate Practice,” Springer, 2012. fields in a message and “{}” for encryption. The purpose [19] S. Guilley, and R. Pacalet, “SoCs security: a war against side-channels”, | R Annals of Telecommunications, Vol. 59, no. 7, pp 998-1009, 2004. of the symbols “ ” and “ ” is defined below. [20] M. Kirkpatrick et. al., “System on Chip and Method for Cryptography • Challenge: An atomic message sent and received in using a Physically Unclonable Function,” U.S. Patent 8750502 B2, separate lines by the same principal (the originator). A issued March 22, 2012. time stamp is not considered an atomic message. [21] W. R. Stevens, TCP/IP Illustrated, Volume 1: The Protocols, Addison- Welsey Publishing Company, 1994. • Replied Challenge: A challenge that appears in a mes- [22] “TOTP: Time-Based One-Time Password Algorithm”, IETF RFC 6238, sage sent to the originator. 2011. • Response: An atomic message (except timestamps) and [23] M. Burrows, M. Abadi, and R. Needham, “A logic of authentication”, ACM Transactions on Computer Systems, 8, February 1990. a replied challenge sent together by the sender of the [24] W. Mao and C. Boyd, “Towards formal analysis of security protocols”, response. Proc. Computer Security Foundations Workshop VI, pp. 147-158, June • Nonsense: An atomic message is a nonsense if it is not 1993. [25] B. Blanchet and B. Smyth, ProVerif: Automatic Cryptographic Protocol a challenge, response, or a timestamp. Verier, User Manual and Tutorial. We idealize the messages of a protocol using the following [26] https://www.ece.nus.edu.sg/stfpage/bsikdar/scripts/IoTJ. [27] D. P. Sidhu, “Authentication protocols for computer networks: I”, rules: Computer Networks and ISDN systems, Vol. 11, pp. 287-310, 1986. 1) Any nonsense is removed. [28] G. V. Bochman, “Finite state description of communication protocols”, Computer Networks, Vol. 2, pp. 361-372, 1978. 2) An atomic message is considered a response if it acts as [29] T. Krovetz, “UMAC: Message Authentication Code using Universal a challenge as well as a response in a line. Hashing”, IETF RFC 4418, March 2006. 3) Combine challenges separated by commas using operator [30] M. Babka, “Properties of Universal Hashing,” Charles University in Prague, Master Thesis, 2010. “|”. [31] Y. Mansour, N. Nissan and P. Tiwari, “The Computational Complexity 4) Combine responses separated by commas using operator of Universal Hashing,” Theoretical Computer Science, vol. 107, no. 1, “|” to form a combined response. pp. 121-133, 1993. [32] T. Kivinen and M. Kojo, “More Modular Exponential (MODP) Diffie- 5) Combine a challenge and its response using “R” into Hellman groups for Internet Key Exchange (IKE),” IETF RFC 3526, “response R replied challenge”. May 2003. 6) Combine a message and its corresponding timestamp [33] M. Katagi and S. Moriai, “The 128-bit blockcipher CLEFIA,” IETF RFC 6114, March 2011. using “R” into “message R timestamp”. [34] G. Montenegro et. al., “Transmission of IPv6 Packets over IEEE Finally we use the following inference rules: 802.15.4 Networks,” IETF RFC 4944, September 2007. [35] P. Kim, “ IoT Specific IPv6 Stateless Address Autoconfiguration with 1) Authentication Rule: If K is a shared secret key between Modified EUI-64,” IETF Internet-Draft, July 2015. P and Q, and P used K to decrypt a received message [36] D. Whiting et. al., “Counter with CBC-MAC (CCM),” IETF RFC 3610, M, then P can believe that Q sent M. The rule is given September 2003. as

K APPENDIX P P ↔K Q V P /M . (22) This section serves as a brief introduction to the formal K P Q |∼M analysis of security protocols using the Mao and Boyd logic [24]. In this techniqe we start by idealizing the protocol mes- 2) Confidentiality Rule: If K is a shared secret key between sages. Three types of information is used to construct logical P and Q and P encrypted M with K and sent it without formulas: M: messages, P : principals, and F : formula. We use sharing it with anyone else, then P can believe that M is capital letters A, B, P , Q, ··· to represent principals, letters only available to P and Q. The rule can be represented K, M, N, ··· to denote messages, while X, Y , Z, ··· are as K used for formulas. We use the following predicate constructs P P ↔K Q V P Sc/kM V P |∼M in our analysis: . (23) P (S∪{Q})c/kM • P X: P believes X is true and may act accordingly. K 3) Super-Principal Rule: P believes what Q believes if P • P |∼ X: P encrypted X using key K. K believes Q is a trusted server. The rule is given as • P /X: P sees X using decipherment key K. In the absence of encryption we use P/X. P Q X V P sup(Q) K . (24) • P ↔ Q: K is a good shared key for P and Q. P X 14

This rule can be interpreted as P can trust Q about X. R and no one else, and P trusts R, and P knows K is This means that an IoT device can be the super-principal fresh, then P can believe K is a good key between P for a nonce it generated. For example, in Protocol 1 IoT and Q. The rule is given as device IDA generates NA. Therefore, we can consider P {P,Q,R}c/kK V P sup(R) V P #(K) IDA as the super principal in terms of NA. This fact has . (27) been used in the tableaux of Figures 4(c) and 4(e). P P ↔K Q 4) The Fresh Rule: P can believe N is fresh if P believes 6) Intuitive Rule: P has seen message M if it can decrypt M is fresh and P has recieved N and M together in a message M using K. The rule is given as message. The rule is given as K P /M V P #(M) P /NRM P /M . (28) . (25) P #(N) 7) Derived Rule: This rule is obtained by combining the belief axiom 5) The Good-Key Rule: There are two variations to this ^ rule: (i) if P believes K is only available to P and Q, P (X Y ) if and only if P X V P Y (29) and P knows that K is fresh, then P can believe K is a good key between P and Q with the confidentiality rule. The rule can be represented as c P {P,Q} /kK V P #(K) K (26) P Q P ↔K Q V P Q Sc/kM V P Q |∼M P P ↔K Q . (30) P Q (S∪{P })c/kM and (ii) if P believes K is only available to P , Q and