1

Token-Based Security for the Internet of ThingsWith Dynamic Energy-Quality Tradeoff

Muhammad Naveed Aman, Member, IEEE, Sachin Taneja, Student Member, IEEE, Biplab Sikdar, SeniorMember, IEEE, Kee Chaing Chua, and Massimo Alioto, Fellow, IEEE.

Abstract—In this paper, token-based security protocols withdynamic energy-security level tradeoff for Internet of Things(IoT) devices are explored. To assure scalability in the mechanismto authenticate devices in large-sized networks, the proposedprotocol is based on the OAuth 2.0 framework, and on secretsgenerated by on-chip Physically Unclonable Functions (PUFs).This eliminates the need to share the credentials of the protectedresource (e.g., server) with all connected devices, thus overcomingthe weaknesses of conventional client-server authentication. Toreduce the energy consumption associated with secure datatransfers, dynamic energy-quality tradeoff is introduced to saveenergy when lower security level (or, equivalently, quality inthe security sub-system) is acceptable. Energy-quality scaling isintroduced at several levels of abstraction, from the individualcomponents in the security sub-system to the network protocollevel. The analysis on a MICA 2 mote platform shows that theproposed scheme is robust against different types of attacks andreduces the energy consumption of IoT devices by up to 69%for authentication and authorization, and up to 45% during datatransfer, compared to a conventional IoT device with fixed keysize.

Index Terms—Internet of Things, Physically Unclonable Func-tions, Network Security, Authentication, Energy-Quality Scala-bility.

I. INTRODUCTION

The Internet of Things (IoT) engulfs a wide range of sys-tems including Internet-connected wearables, wireless sensornetworks, low-power embedded systems, mobile phones, smartmeters, and vehicular networks, among others [1]. Securitybreaches entail a very large cost per annum, which is $445Billion in the United States alone [2]. Moreover, the risk ofcyberattacks is expected to grow by 20.3% per year in thenext ten years [3], and the expected growth of the IoT willresult in a further increase. Assuring adequate security in IoTnodes is particularly challenging in view of their very limitedenergy availability. Indeed, many IoT nodes are untetheredand need to achieve a long lifetime while preserving extrememiniaturization, which severely limits the size and the capacityof the energy source. Also, their distributed nature providesattackers and adversaries with easy physical access to edgedevices. The traditional notion for Internet connected devicesis to consider them physically well-protected. However, thisassumption is not valid for the IoT and therefore, security

The authors are with the Deptt. of Electrical and Computer Engineer-ing, National University of Singapore, 4 Engineering Drive 3, Singa-pore 117576. E-mail: elemna@nus.edu.sg, sachin.taneja@u.nus.edu , mas-simo.alioto@nus.edu.sg, bsikdar@nus.edu.sg, and chuakc@nus.edu.sg. .

protocols designed for the IoT need to be secure againstphysical attacks [4].

Achieving further reductions in the energy consumptionof IoT nodes is crucial, and is expected to be even morechallenging than in the past. Indeed, continuing the historicalenergy scaling trend of 100X reduction every 10 years [5] canno longer rely on technology scaling, due to the substantialslow-down of Moores law and the excessive cost per transistorin sub-32nm technologies [6]. In addition, aggressive voltagescaling is running out of steam, as it has already been lever-aged to reduce energy in the recent past [1]. Hence, furtherinnovation is required to drive down the energy consumptionof edge devices.

In this paper, the general concept of energy-quality scalingis explored in the security domain, based on the observationthat different tasks and data require different levels of security.For example, non-critical data such as temperature measure-ments do not need as much security as information relatedto the identity of occupants in a room. This diversity of therequired security levels across tasks, contexts and applicationscan be exploited to reduce energy whenever a lower levelof security is acceptable. More in detail, the quality metricadopted in this work is the size of the key used to establishthe root of trust among the parties for authentication and dataexchange. Indeed, the key size determines the time taken byan attacker to recover the key (e.g., by brute-force attacks).Accordingly, energy-quality scalability is introduced by dy-namically scaling the key size to the minimum allowed bythe specific task, and hence minimize the energy based on itsinstantaneous requirement. In particular, this work focuses onsecurity systems and protocols based on Physically UnclonableFunctions (PUFs), which are security primitives that havebecome popular and are being adopted in various commercialproducts [7]- [10].

From an IoT network perspective, trust needs to be es-tablished between any pair of communicating nodes (e.g.,node to node, node to gateway, gateway to server), whichis particularly challenging due to the disparity in capabilitiesand energy constraints of the devices involved. Accordingly,authentication frameworks that scale across different devicesneed to be adopted. For this purpose, we propose the use of theOAuth 2.0 open authentication and authorization standard [11]combined with different key sizes to introduce the concept ofenergy-quality scaling across different levels of abstractions.Since OAuth 2.0 simply provides a framework for authen-tication but no protocols, in this paper we present a noveltoken-based protocol for authentication and authorization in

2

IoT systems that explicitly leverages the energy-quality scalingcapability of hardware, and make it available at the networklevel.

The rest of the paper is organized as follows. SectionII discusses the existing related literature and Section IIIprovides the background for this work. Section IV discussesthe energy-quality tradeoff in security. Section V discusses ournetwork model, assumptions, security requirements and attackmodel. Section VI presents the proposed protocol, Section VIIpresents a formal verification of its correctness, and its securityanalysis is discussed in Section VIII. Section IX presents thesimulations for the cryptographic verification of the protocoland Section X evaluates its performance. Finally, Section XIconcludes the paper.

II. RELATED WORK

Some of the recent works on IoT authentication includethe following. The authors of [12] propose an authenticationmechanism based on deep neural networks by exploiting thewireless hardware imperfections of IoT devices. However,this technique requires extensive training and is sensitive tochanges in the wireless channel. In another work, the authorspropose an authentication mechanism using blockchains [13].However, for large IoT networks, this technique suffers fromthe scalability issues attributed to blockchains. The authorsof [14] propose an authentication mechanism for the IoTbased on three-factor authentication. However, the proposedtechnique requires a user to enter a password and dependson complex modular multiplication. Similarly, [15] proposesthe use of Elliptic Curve Cryptography for authentication ofnodes in wireless sensor networks (WSN) within the IndustrialIoT systems. However, the proposed protocol requires usersto input passwords and uses complex modular multiplication.Thus, most of the existing authentication protocols suffer fromthe following problems:

1) Rely on complex computations.2) Require user assistance in the form of passwords.3) Secrets are stored in the device memory making them

vulnerable to physical attacks.Some of the recent work on authentication using PUFs

include [16]- [18]. However, all these techniques use a fixedsize for PUF outputs. This restricts the authentication protocolto use the highest level of security for any type of applicationwithout considering the resource constrained nature of mostIoT devices. In this paper we solve this issue by proposinga PUF with variable output size. Thus, this paper uses theproposed scalable PUF to develop an authentication protocolthat considers both resource constraints as well as securityrequirements for a wide range of application domains.

Recent works on PUFs [19]- [21] demonstrate state-of-the-art energy efficiency with low area. The fully-synthesizablePUF implementation described in [20] enables the designscalability of the PUF system using the hardware descrip-tion language (HDL) to enable the concept of scalable key(see Fig. 6) with very low design effort and time. Scalableimplementation of multibit error correcting codes that maybe used with PUFs are presented in [22] and [23] for error

Fig. 1: SoC for an IoT device with dynamic energy-qualitymanagement in hardware security sub-system.

Fig. 2: Physically Unclonable Functions

correction bit count [22] and word length [23], respectively.A cryptographic core implementing the advanced encryptionstandard (AES) with scalable keys (128, 192 and 256 bitskey) as coprocessor for enabling scalable key encryption anddecryption operation is presented in [24]. These componentsform the building blocks of the hardware for the proposedsystem.

III. PRELIMINARY BACKGROUND

A. Hardware Security Sub-Systems Based on PUFs

A general scheme of a PUF-based hardware security sub-system of a system on chip (SoC) is depicted in Figure 1.This sub-system comprises of the PUF circuit for on-chip keygeneration, the related Error Correcting Code (ECC) and thedigital circuits for cryptography. Once data is encrypted, thesub-system passes it to the wireless interface for transmissionto other devices.

PUFs are security primitives that provide a hardware rootof trust exploiting the inherent random variations introducedby the chip manufacturing process [25] - [27]. PUFs map theinput (known as the “challenge”) into a non-invertible output(the “response”) through a relationship that is unpredictablefor an external observer, and is repeatable. The basic idea of aPUF is shown in Figure 2, where the response R of a PUF canbe represented as a function P of the challenge C, forming achallenge-response pair (CRP).

PUFs can be used for hardware authentication and securekey generation for cryptography, among others [26], [27].As a main advantage, PUFs retain keys without actually

3

Fig. 3: PUFs combined with ECC

storing them or requiring any programming, thus counter-acting traditional physical and invasive attacks to memoriesstoring keys. Several types of PUFs have been proposed, suchas delay-based and memory-based PUFs, which respectivelyleverage the variations among circuit delays (or ring oscillatorfrequency) and the state that memory cells naturally assume atthe power-up due to random process variations [25]. PUFs arecharacterized by several design metrics, such as area/bit (i.e.,silicon cost), energy/bit, uniqueness (i.e., difference betweendifferent silicon dice), output stability across repeated mea-surements and against fluctuations in voltage and temperature[25]- [27]. A detailed comparison and scaling trends in state-of-the-art PUFs is available in the public PUF database [21].Typically, state-of-the-art energy-efficient PUFs consume anenergy of 10-200 fJ/bit, and exhibit a native output instabilityof 3-20% [19]- [21].

If the same challenge is given to a PUF multiple times, itis likely to have slightly different outputs on each evaluationdue to environmental variations (e.g., temperature) and on-chipnoise. However, cryptographic primitives require every bit ofthe key to be perfectly stable. To avoid instability, an errorcorrecting code (ECC) is typically cascaded to process thePUF output (e.g., temporal and spatial majority voting). Suchtechniques are relatively inexpensive and are typically utilizedto preliminarily decrease the bit error rate (BER). Applicationsthat use the PUF outputs as security primitive typically requireBERs in the range of 10−6 to 10−9 [27], and hence requirethe introduction of ECC, in view of its ability to reduce theBER by orders of magnitude. ECCs can reduce the BER byorders of magnitude [27]. Figure 3 shows the use of ECCs withPUFs. In the provisioning phase, an ECC encoder computesthe k-bit helper data (or syndrome) from the PUF output andstores it in a non-secure non-volatile memory. To regenerateexactly the same PUF output, the PUF first uses the challengeto produce a PUF output and then the ECC decoder uses thehelper data to correct any bit flips in the PUF output [28].Note that the attacker may obtain the helper data (also knownas parity), however, he/she may only be able to learn at mostk bits out of the N PUF output bits. Thus, an adversary stillneeds to guess at least N − k bits to recover the correct PUFoutput. In other words, the PUF output can be used effectivelyas secure cryptographic key, if N−k is large enough. The keylength needs to be chosen accordingly, to assure the desiredlevel of security. The recommendations for minimum key sizesfor symmetric keys in various applications are given in TableI, and range from 64 to 256 bits.

TABLE I: Key Size RecommendationsMinimumKey Size Protection

64 bitsVery short-term protection against small organization [29] i.e hackers with a10, 000 USD budget and using FPGA(s) [30].

96 bitsLegacy Standard level [29],protection from 2017 to 2020 [29]

128 bits

Long-term protection [29],Sufficient for most general purpose and commercial applications until beyond 2030 [31]French Network and Information Security Agency (ANSSI) [32],German federal office for information security (BSI) [33]

192 bitsReal time applications or media streams (e.g., audio and video) [34],Protection from 2016 to 2030 and beyond [31]

256 bits

“Foreseeable future” [29],Protection against quantum computers [29],Products Created for the US Government [35]Protection from 2016 to 2030 and beyond [31]

TABLE II: Energy Cost of building blocks in the HW securitysub-system and wireless transceiver

Sub-component Domain Energy Example

PUF Baseband (digital) 10 - 200 fJ/bit PUF [19]- [21]ECC Baseband (digital) 20 - 60 pJ/bit BCH [22], [23]

Crypto Baseband (digital) 1 - 30 pJ/bit AES [24], [36], [37]Wireless Radio Frequency (RF) 2-10 nJ/bit BLE [1]

Once a stable PUF key is available at the ECC output,the cryptographic core in Figure 1 performs data encryption.Advanced Encryption Standard (AES) and Simon are amongtwo popular choices [24], [36], [37]. The cryptographic coreis necessary to avoid the in-plain communication of keysand data. State-of-the-art cryptography cores support the re-configuration in terms of key size and consume about 1-30pJ/bit for the encryption and decryption process [24], [36],as summarized in Table II.

Once secure data is generated by the cryptographic coreand hence the security sub-system, data can be transmittedwirelessly to the server or other nodes. The radio frequencytransceiver typically reads the data to be transmitted from theintermediate transmission FIFO (TXFIFO), which is filled bythe baseband sub-system (see Figure 1). The structure and sizeof the data packet to be transmitted is typically configured bywriting to internal registers in the transceiver. As an example,in the popular CC2500 transceiver by Texas Instruments, thepacket length is set by writing on the “PKTLEN” configurationregister in variable packet length mode [38]. The data in theTXFIFO is then transmitted wirelessly by ultra-low powerradios for short-range communication, such as Bluetooth lowenergy and Zigbee. Best-in-class radios consume about 2-10nJ/bit, and no substantial energy reduction is expected fromradio frequency circuits in the foreseeable future [38].

B. OAuth 2.0

OAuth 2.0 is a token-based authentication and authorizationopen standard for Internet communications defined in [11]. Inthe traditional client-server authentication model, a client canaccess a protected resource on a server using the resourceowner’s credentials. If the client is a third party application,the resource owner’s secret credentials need to be sharedwith the client. This may lead to password leakage, databreach, and access to protected resources. To solve this issue,OAuth 2.0 provides a framework for authentication decisionsand mechanisms by adding an authorization layer. Instead of

4

Fig. 4: Smart healthcare system example

using the resource owner’s credentials to access a protectedresource, the client is issued an access token by a protectedauthorization server. This access token defines the scope,lifetime, and other access attributes, and four entities areinvolved [11]. First, a resource owner (RO) controls access toa protected resource. Second, authorization server (AS) issues,controls, and revokes tokens after successfully authenticatingand obtaining authorization from a resource owner. Third, aclient is the application, or IoT node that makes protected datarequests on behalf of the resource owner. Finally, the resourceserver hosts the protected resources such as data. A basic flowin OAuth 2.0 can be described as follows:• the client sends an authorization request to the AS.• the AS authenticates the client and sends an access token

to the client.• the client uses the access token to authenticate itself to

the resource server and access it.For example, consider a health care system consisting of anIoT device collecting heart beat and blood pressure data, andbeing connected to the Internet through a medical servicesgateway as shown in Figure 4. In this example, the RO is theperson whose data is being collected by the IoT device. Whenthe IoT device needs to send data to the data server it acts as aclient and it first obtains an access token from the authorizationserver. Then, it uses this token to authenticate and forward thedata to the data server. Similarly, the applications that analyzeand render the sensed medical data obtain an access tokenfrom the authorization server, and present this access tokento the data server when requesting the data. Note that in thisexample none of the entities were provided with the resourceowner’s credentials, as the access tokens were instead used forauthentication and authorization.

IV. ENERGY-QUALITY TRADEOFF IN PUF-BASEDHARDWARE SECURITY SUB-SYSTEMS

Energy-quality scalability has been recently investigatedfor various sub-systems of typical system on a chip (SoC)[39], such as SRAM memories, arithmetic circuits, Analog-to-Digital Converters, and machine learning accelerators (e.g.,K-means clustering). This concept can be extended to thehardware security sub-system that is responsible for hardwareauthentication and secure data exchange (see Figure 1). In-deed, the adoption of the highest available level of quality (i.e.,security) regardless of the task at hand introduces pessimism

Fig. 5: Energy consumption of building blocks in the HWsecurity sub-system and wireless transceiver vs key size (Inthis figure, PUF in [21], Simon crypto-core [37] and a radiotransceiver consuming 5 nJ/bit are assumed. The packet con-tains 300-bit message and MAC equal to the key size).

and over-design, and misses the available opportunities toreduce energy whenever lower levels of quality are acceptable.

In the following, quality is defined as the size of the keyto establish the root of trust among the parties. Longer keysexponentially increase the time and effort to recover the key(i.e., quality in the above context), at the expense of largerenergy consumption in all the building blocks belonging tothe security sub-system.

The energy consumption of the building blocks in the se-curity sub-system linearly depends on the key size. As shownin Figure 5, the energy required to generate a reliable keyincludes the PUF energy and ECC decoder energy. The energyper access in PUFs is proportional to the PUF word-length[1] (i.e., the key size), since the dominant energy consumedby each bit is independent of the number of bits being readsimultaneously. Similarly, the energy of ECC circuits usedto stabilize PUFs (e.g., using Bose Chaudhuri Hocquenghem(BCH) codes) is proportional to the number of errors thatcan be corrected [22], as well as the PUF word-length [23](i.e., again the key size). As an example, assuming a typical25fJ/bit energy at a 7.5% BER for a PUF [21], generatinga 64-bit PUF key requires the generation of 128 PUF bits(assuming a targeted 50% entropy loss in the ECC), whichrequires 3.2pJ of energy. A synthesized BCH decoder in 40nmat 0.9V was found to consume approximately 42pJ to correcteach bit error with 128 bit input data size. Therefore, witha 7.5% BER in 128 PUF bits (i.e., 10 bit errors or fewer),the BCH decoder requires 420pJ to stabilize the PUF key.Cryptographic primitives with scalable key size (e.g., AES,Simon, Speck) also consume an energy that is proportional tothe key size [24], [36], [37]. For example, in a 32/64 Simonsynthesized in 40nm CMOS, the energy required to encrypta 32-bit data block is approximately 35pJ at 0.9V, as shownin Figure 5. Note that the energy taken by the cryptographiccore includes the energy to encrypt the message block andthe generation of a message authentication code (MAC), asdiscussed below. The above examples repeated for differentkey sizes in the security sub-system are summarized in TableII, which shows that the dominant energy contributions aredue to the ECC and the cryptographic core.

Similarly to the PUF-based security sub-system, the total

5

Fig. 6: Proposed scalable PUF design.

energy for the transmission of a packet scales approximatelyproportionaly to the packet size, which is defined by the lengthof the message and the MAC to provide data integrity in eachpacket. The MAC size is typically proportional to the key size[40], [41], hence the total wireless energy per packet linearlydepends on the size of the key. For example, consider an IoTdevice that consolidates 30 samples (with a resolution of 10bits) from a sensor and then sends the consolidated data in apacket to a data server. Without energy quality scalability, eachIoT device thus sends 300 bits of data constantly using thestrongest level of security (e.g., 256-bit keys and hence MAC).Compared to the energy strictly required for the message,the additional 256-bit MAC determines a substantial energyoverhead, especially when short message and packet lengthsare adopted. However, the adoption of a shorter key resultsin the transmission of proportionally fewer bits for the MAC,thereby saving energy as shown in Figure 5.

From the above considerations, the adoption of shorter keyscan reduce the energy of all building blocks in the hardwaresecurity sub-system, and the large wireless transceiver energycontribution. In this work, such possibility is introduced byusing an adaptive key size that is minimized to fit the requiredlevel of security, as opposed to conventional security systemswith fixed key size. This tradeoff is managed by dynamicallyadjusting the key size as appropriate, from circuits to thenetwork protocol. To this aim, as shown in Figure 1, theextra key size input is inserted in all building blocks of thehardware security sub-system and the transceiver, and controlsthe related key size. key size is mapped in the memory sub-system, and is set by the processor core by writing on theassociated memory address (i.e., it can be defined by thesoftware application). In the following, these blocks are shownto be readily made energy-quality scalable with minor designchanges.

Regarding the PUF energy-quality scalability, Figure 6shows a hybrid PUF where different Key sizes can be ob-tained through a hybrid approach of different key sizes withnon-overlapping addressing space and I/O control (interface)module. This allows for controlling the length of the responsewith the key size, and disoverlap them to prevent any brute-force attack targeting the longest PUF keys through the re-covery of shorter keys. In regard to the ECC, scalable datalength and error correction capability have been previously

Fig. 7: Network model.

demonstrated for adaptive error correction in static randomaccess memories (SRAMs) [22], [23]. In ECC, the parameterkey size is used to select and configure the specific data sizeand error correction capability. When synthesized in 40nmCMOS at 0.9V, such reconfigure-ability entails a relativelysmall overhead of less than 10% in area and power, comparedto a non-scalable ECC. To enable energy-quality scalability,a cryptographic standard offering variable data and key sizeis needed. As an example, Simon and Speck support a widerange of data and key sizes. Simon cryptographic core can beused to encrypt data ranging from 32 to 256 bits with key sizefrom 64 to 256 bits [37].

Regarding the transceiver, dynamic energy-quality scalingis achieved by simply selecting the appropriate MAC lengthused in the transmission FIFO, based on key size.

V. NETWORK MODEL AND ASSUMPTIONS

A. Network Model

According to the network model adopted in this work, eachIoT device is equipped with a PUF and is connected to theInternet using 6LoWPAN based (or similar) router elements.IoT devices may access a service on another IoT device ormay access a resource on an online server. For example, anIoT device in a vehicle may want to reserve a parking spaceusing a cloud based server or an IoT device controlling thetemperature in an room may want to access temperature datafrom another IoT device.

B. Assumptions

We make the following assumptions regarding our system:a. Each IoT device is an embedded SOC equipped with a PUF.

Any attempt to tamper with the PUF such as separating itfrom the IoT device will destroy the PUF [42], [43].

b. Being on the same chip, the communication between thePUF and the microcontroller can be assumed to be secure[42], [43].

c. The IoT devices are resource constrained, whereas the au-thorization server and the resource server have no limitationof resources. Moreover, the authorization server is assumedto be the trusted party.

6

d. IDi, {M}k, Ci, Ri, and key sizei respectively denote theID of an IoT device, the message M encrypted using keyk, challenge for the i-th iteration, the response of a PUFfor Ci, and the key size used in the current session.

C. Attack ModelIn the communication over the Internet of the IoT device

with the authorization/resource server and other devices, weassume that an attacker may compromise multiple networkentities and can inject packets, initiate a session, eavesdrop,impersonate other devices, and replay older messages. More-over, we assume that the IoT devices are not physically wellprotected and may even be captured by an attacker. Therefore,an attacker may also launch a physical attack on an IoT device.

The objective of the adversary is to authenticate itself withthe authorization server or any of the IoT devices withoutbeing detected, and intends to launch attacks to cause physicaland economic damage. For example, if an adversary succeedsinto gaining access into an industrial plant, he/she can causea large scale accident which can even cost human lives. Thegoal of this paper is to develop protocols for an authorizationframework that is secure against different types of attackssuch as cloning, man-in-the middle, physical, and tamperingattacks.

D. Security RequirementsThe security objectives of the proposed protocol are:

1) Achieve mutual authentication between an IoT device andan authorization server

2) gain limited access to another IoT device or a resourceserver using an access token obtained from the authoriza-tion server

3) providing different levels of security according to theapplications needs

4) even if an adversary captures an IoT device, he/she shouldnot be able to compromise the security of the scheme

VI. PROPOSED PROTOCOL

In the OAuth 2.0 authorization framework, every IoT deviceneeds to authenticate itself with an authorization server beforeit can access a service on another IoT device or resource server.The authorization server grants the IoT device with an accesstoken that defines the scope and lifetime of the session. So weconsider two phases, the first phase obtains an access tokenfrom an authorization server and the second phase involvesaccessing a service or resource.

The authorization server starts with a single CRP for eachIoT device. The Time-based One-time Password algorithm[44] can be used by the server to obtain the initial CRP. Weassume that the IoT device exchanges the initial CRP withthe server with the help of an operator when it is installed inthe field for the first time. Once the initial CRP is exchanged,the IoT device does not need an operator and can functionindependently. Thus, the IoT devices do not need to store anyinformation, while the authorization server stores the followingfor each IoT device: the identity of the IoT device (i.e., IDA)and one CRP (i.e., (Ci, Ri)) for each key size used by theIoT device.

A. Phase 1: Authentication and Token Exchange

The proposed protocol for an IoT device to authenticateitself and obtain an access token from the authorizationserver is shown in Figure 8. This protocol uses elliptic curvecryptography [45] for authentication. We consider an ellipticcurve C defined over a prime finite field Fq , where q = pn.We assume that C, q, a point G ∈ C, and an embeddingfunction m 7→ Em, are publicly available [45]. The steps ofthe protocol for this phase are as follows:

1) the IoT device IDA sends its ID, IDA, and random nonceN1 to the authorization server IDS .

2) the authorization server searches its memory to locateIDA. If IDA is not found, the authentication requestis rejected. Otherwise, the authorization server readsthe CRP (Ci, Ri) stored against IDA. Note that theauthorization server manages the energy-quality tradeoffby selecting the CRP with key size that is appropriatefor the current application, i.e. wherever possible theauthorization server uses a smaller key size to minimizethe overall energy requirement for the IoT device. Theauthorization server then generates a random integer aand calculates z1 = aG. The server then sends Ci,key sizei, z1 and the corresponding MAC to the IoTdevice IDA in message 2 in Figure 8. The last parameterof the MAC (i.e., N1 in message 2) is the freshnessidentifier. The other parameters ensure data integrity.The same approach is adopted for data integrity, sourceidentifier, and message freshness throughout the protocol.

3) The IoT device IDA uses its PUF to generate Ri usingthe challenge Ci and key sizei parameter for energy-quality tradeoff as shown in Figure 6. The IoT deviceIDA then verifies the MAC. If the verification fails, theauthentication request is terminated. Otherwise, the IoTdevice IDA then generates a random integer b for theelliptic curve cryptography operations, and N3 as a fresh-ness identifier for subsequent messages. The IoT deviceIDA uses b to calculate z2 = bG and r = ERi + bz1,where ERi represents applying the embedding functionto Ri. The IoT device IDA then sends IDA, IDB , z2,r, and N3 in message 3 in Figure 8.

4) The authorization server calculates r − az2 = ERi andreverses the embedding to obtain Ri. It then comparesthe result with the Ri in its memory. If the verificationfails, the authentication request is denied. Otherwise, ifIDB is an IoT device the authorization server reads theCRP (Cj , Rj) for the respective key sizei stored againstIDB . If IDB is a resource server, the authorization serverreads the public key of IDB . The authorization serverthen generates an access token T i with the followingfields:

(i) IDA: identity of the IoT device requesting accessto a service or resource.

(ii) IDB : identity of the resource server or IoT deviceproviding a service or resource.

(iii) TTL: time to live field.(iv) Scope: the scope field provides access control and

is used to obtain limited access to specific services

7

or resources.(v) ki: secret symmetric key to be used by the initiating

IoT device IDA and the resource server or IoTdevice IDB for creating a session. To exploit theenergy-quality tradeoff in the session between theIoT device IDA and the resource server or IoTdevice IDB , the size of ki is set to key sizei. kiis also used as the secret for the MACs used duringthe authorization phase.

The token is encrypted using Rj if IDB is an IoT device,i.e., T i = {IDA, IDB , TTL, Scope, ki}Rj . However, ifIDB is a resource server the token is encrypted using theresource server’s public key. The authorization server thengenerates a random integer N4 and sends an encryptedmessage MA = {IDA, length, ki, T

i, N3, N4}Ri to IoTdevice IDA, where length is the length of the accesstoken T i. Note that the Scope field in the access token canbe of variable length, therefore, the access token lengthneeds to be specified in message MA. To ensure dataintegrity and freshness, the authorization server also sendsthe corresponding MAC to the IoT device IDA. Note thatthe length of the MAC is proportional to the key size.

5) The IoT device IDA uses Ri to obtain the access tokenT i. The IoT device IDA then verifies the MAC and thelength of the token. If verification fails, the authenticationrequest is terminated. Otherwise, the authentication isconsidered complete and the IoT device can proceed tophase 2.

B. Phase 2: Authorization

Let us first consider a scenario where an IoT device IDA

intends to establish a session with another IoT device IDB .In this phase the two entities authenticate each other usingthe access token. Moreover, the access token determines theresources/services that the IoT device IDA has access to. Theauthorization protocol for this scenario is shown in Figure 9.

After completing the first phase of the proposed protocol,the IoT device IDA holds the challenge Cj for the IoT deviceIDB , the energy-quality knob key sizei, a symmetric key ki,and an access token T i. The steps for the authorization phaseof the proposed protocol are as follows:

1) the IoT device IDA generates a random integer NA andforms an encrypted message M1 = {IDA, IDB , NA}ki .The IoT device IDA then sends Cj , key sizei, T i, M1

and the corresponding MAC to the IoT device IDB .2) the IoT device IDB obtains Rj using Cj , key sizei,

and its PUF. The IoT device IDB then decrypts thetoken T i to obtain the symmetric key ki. The key kiis then used by IoT device IDB to obtain the randomnonce NA. The IoT device IDB then verifies the MAC.If the verification fails, IoT device IDB rejects theauthorization request. Otherwise, the IoT device IDB

generates a random integer NB and forms an encryptedmessage M2 = {IDA, IDB , NA, NB}ki . The IoT deviceIDB then sends M2 and the corresponding MAC to theIoT device IDA.

Fig. 8: Authentication and token exchange.

Fig. 9: Authorization phase for two IoT devices.

3) the IoT device IDA obtains the random nonce NB usingki and verifies the MAC. If the verification fails the IoTDevice IDA terminates the current authorization request.Otherwise, authorization is considered complete and theIoT device IDA may obtain data or some service fromIoT device IDB .

8

Fig. 10: Authorization phase for IoT device and resourceserver.

The authorization protocol for the scenario when an IoTdevice intends to access a resource server is shown in Figure10. We observe that the protocols in Figures 9 and 10 aresimilar except for step 2. In Figure 10 the resource serverdecrypts the token T i using its private key instead of a PUFresponse as in Figure 9. The remaining steps of the protocolin Figure 10 are similar to Figure 9 and do not require anyfurther explanation.

Note that the random nonces NA and NB in Figures 9and 10 can also be used to establish a secret symmetrickey between the two entities. For example, we can useH(RNA

)⊕H(NB) as a session key between IoT device IDA

and IoT device IDB or the resource server.

VII. VERIFICATION OF PROTOCOL CORRECTNESS

In the section we present a formal verification for thecorrectness of the proposed protocol. Note that this sectiondoes not provide any proof of security but focuses on provingthat the proposed protocol is correct with respect to itsspecifications. A protocol is said to be correct if it holds thefollowing properties:

1) Completeness: The protocol accepts all valid inputs.2) Deadlock freeness: The protocol does not enter a state

where it can stay forever.3) Livelock or tempo-blocking freeness: The protocol does

not contain any infinite loops.4) Termination: The protocol always ends in a legible final

state starting from the initial state.5) Absence of non-executable interactions: The protocol

only contains practicable transmission, reception, andinteraction paths.

Fig. 11: Directed graphs.

We prove the correctness of our protocol using the techniqueproposed by Sidhu and Varadharajan [46], [47]. The first stepis to draw a directed graph for each entity of a protocol.The directed graphs for the entities involved in our proposedprotocol are shown in Figure 11. In this figure, gS , gA, andgB/gR represent the FSMs for the authorization server, IoTdevice IDA and IoT device IDB or the resource server,respectively. The number in the circles represent the state ofa protocol machine, while the arcs are labeled with +n or -n for a transmission or reception of a message, respectively.For example, the interaction paths for gS , gA, and gB/gRcorresponding to one run of the protocol are given below:• gS : [0] + 1/− 2[1] + 3/− 4[0]• gA : [0]− 1[1] + 2/− 3[2] + 4[3]− 5[4] + 6/− 7[0]• gB/gR : [0] + 5/− 6[1] + 7[0]

where the state of a protocol machine is denoted by “[]”.For example, the authorization server’s interaction path showsthe following sequence of activities: The authorization serverstarts in state 0, receives message 1 and sends message 2to IoT device IDA to enter state 1 of its FSM. Finally, theauthorization server receives message 3 and sends message 4to enter state 0 again. The interaction paths for gA and gB/gRcan be interpreted similarly. S0 is considered the final statefor all the entities in our protocol.

The next step in our analysis is to prove that our proposedprotocol possesses the above properties 1-5. For this purposewe use the reachability analysis technique proposed in [46] -[48]. Using this technique, the state of the overall system isrepresented with the matrix

ASTATE

A → B/RCHANNEL

A → SCHANNEL

B/R → ACHANNEL

B/RSTATE

B/R → SCHANNEL

S → ACHANNEL

S → B/RCHANNEL

SSTATE

(1)

where the authorization server, IoT device IDA, and IoTdevice IDB or resource server IDR are denoted by S, A, andB/R, respectively. Moreover, the diagonal elements representthe current state of the FSM of an entity while rest of theelements represent a message sent by an entity. In (1), theelement in row 2 and column 2 represents the state of entity Bor R. Similarly, the element in row 3 and column 1 representsthe message sent by the authorization server to IoT deviceIDA. For example, at the start of the protocol, all the channels

9

Fig. 12: Reachability analysis.

are empty i.e., E and the protocol entities are in their startstates i.e., S0. Accordingly, the initial state matrix can berepresented by (2) as follows:

SS0 =

S0 E EE S0 EE E S0

. (2)

Let us assume that IoT device IDA sends message 1 to theauthorization server. This causes the FSM of the IoT deviceIDA to transition from state 0 to state 1. The overall systemmatrix in this case is shown as follows:S1 E 1

E S0 EE E S0

(3)

where the element in row 1 and column 3 shows that the IoTdevice IDA has sent message 1 to the authorization server,while the element in row 1 and column 1 shows that the FSMof the IoT device IDA is in state 1. Moreover, this matrixalso shows that the authorization server is still in state 0 andhas not yet received message 1 from IoT device IDA. In ouranalysis, we denote the overall system state by SSi and thestate of the individual entities by Si.

The reachability analysis for the proposed protocol is shownin Figure 12. In this figure, we denote the transmission orreception of message i by the entity X as X+i or X−i,respectively. Figure 12 shows the sequence of transition forthe overall system for the proposed protocol. We start withthe initial state SS0 and transition to state SS1 when theIoT device IDA sends message 1 to the authorization server,followed by subsequent transitions until we reach the finalstate SS8. The completeness and termination property issatisfied by our protocol as our system always starts fromthe initial state and terminates at the final state SS8 whileaccepting all valid messages. An overall system state whichis neither an initial nor a final state and in which all thechannels are empty is said to be a potential deadlock state.Figure 12 shows that the proposed protocol does not containany potential deadlock state satisfying the deadlock freenessproperty. We observe that the overall system is free of anyloops implying livelock or tempo-blocking freeness. Moreover,Figure 12 shows that the system does not possess any non-executable interactions, and thus the proposed protocol satisfythe fifth and last property for correct protocols.

VIII. SECURITY ANALYSIS

In this section we present a formal security analysis of theproposed protocol based on the Mao and Boyd logic [50].

For ease of notation, in the following we represent theIoT device IDA, the IoT device IDB , the resource serverIDR, and the authorization server IDS by A, B, R and S,respectively.

A. Security Analysis For Phase 1

To evaluate the security claims of the protocol given inFigure 8, we show that the access token T i is a good sharedsecret between the IoT device IDA and the authorizationserver. The first step in applying the Mao and Boyd logic ismessage idealization. The purpose of message idealization isto convert implicit context-dependent information in a protocolinto explicit specification. Protocol message idealization isdescribed in the Appendix. The idealized versions of themessages exchanged in the protocol for phase 1 are as follows:

1) A→ S : A,N1

2) S → A : z13) A→ S : A,B, z2|rRz1|N3

4) S → A : {A, T iRN3|N4}Ri

Note that the Mao and Boyd logic implies an effectiveapproach to provide data integrity and origin verification asa pre-requisite. For this purpose our protocol uses the MACs.The set of initial beliefs/assumptions for the protocol in phase1 are given as follows:

1) A ARi

↔ S and S ARi

↔ S: A can generate Ri ifprovided with the correct challenge while S stores a CRPfor each IoT device in its memory.

2) S Ac/ ‖ T i and A S {S}c/‖T i: S generates theaccess token T i.

3) A #(N3): A generates a new random nonce N3 eachtime.

4) S #(T i): S generates a new access token T i eachtime with a new symmetric key ki.

5) A sup(S): S is the super principal with-respect-to RS1 .

6) ARi

/ T i R N3: Message 4 in the idealized protocol.

7) ARi

/ N3 and ARi

/ T i: Message 4 in the idealizedprotocol.

8) SRi

|∼ T i: Message 2 in the idealized protocol.The Mao and Boyd logic uses a set of inference rules to provedifferent security properties. These rules can be found in theAppendix. The tableau used to prove the security of phase 1of our protocol is shown in Figure 13. To prove that T i isa good shared secret between A and S we need to establishthis claim on the site of principle S as well as A as shownin Figures 13(b) and 13(a), respectively. For example, Figure13(b) is used to prove the fact that T i is a good secret betweenA and S at the site of principle S. To prove this, we start with

the statement we intend to prove i.e., S ARi

↔ S, which canbe interpreted as “A believes T i is a good secret between Aand S”. Next we observe that we can apply the good-key rulefrom [50]. This rule states that T i is a good secret between

10

A and S, if we can prove that no one else except A and S

has seen T i i.e., S {A,S}c/ ‖ T i, and that T i is freshi.e., S #(T i). Next to prove S {A,S}c/ ‖ T i we canapply the confidentiality rule from [50]. This rule requires usto show the following three facts:

(i) Ri is a good secret shared between A and S i.e., S

ARi

↔ S.(ii) No one except A has seen T i i.e., S Ac/ ‖ T i.

(iii) S sent T i after encrypting it with Ri i.e., SRi

| ∼ T i.We observe that all these statements and S #(T i) arepart of the initial beliefs. Thus, we can conclude that in theproposed protocol, S believes A and S share a good andsuitable secret T i. Similarly, the proof of A believes T i isa good secret between A and S is given in Figure 13(a). Anadversary cannot launch a successful attack without knowledgeof T i, and these proofs show that he/she cannot obtain ortamper with T i.

B. Security Analysis For Phase 2

In this phase we have two scenarios: an IoT device isrequesting access to another IoT device or an IoT device re-quests access to a service or resource in a resource server. Theprotocol messages for the former scenario after idealization aregiven below:

1) A→ B : {A,B, ki}Rj , {A,B,NA}ki

2) B → A : {A,B,NBRNA}ki

3) A→ B : {A,B,NBRNA}ki

The set of initial beliefs/assumption is given as follows:

1) A Aki↔ B and B A

ki↔ B: A and B are providedwith a symmetric key ki by the authorization server.

2) A #(NA): A generates a new random nonce NA eachtime.

3) B #(NB): B generates a new random nonce NB eachtime.

4) A Bc/ ‖ NA and A B {B}c/‖NA: A generatesthe random nonce NA.

5) B Ac/ ‖ NB and B A {A}c/‖NB : B generatesthe random nonce NB .

6) A sup(B): B is the super principal with-respect-toNB .

7) B sup(A): A is the super principal with-respect-toNA.

8) Aki/ NB R NA: Message 2 in the idealized protocol.

9) Bki/ NB R NA: Message 3 in the idealized protocol.

10) AKi

|∼ NA: Message 1 in the idealized protocol.

11) BKi

|∼ NB : Message 2 in the idealized protocol.The tableaux for the security proofs for the proposed

protocol in the access phase are shown in Figure 14. Withoutthe knowledge of T i, NA, NB , Ri or Rj an adversary cannotconstruct valid data. Moreover, the use of PUFs makes theIoT devices safe against physical attacks i.e., IoT devices donot need to store any secrets and even if an attacker capturesan IoT device, he/she can not obtain any secrets. This showsthat the proposed protocol can be considered safe against all

major security attacks including cloning, man-in-the-middle,spoofing, interleaving, replay, and eavesdropping attacks etc.

C. Elliptic Curve Cryptography Security

The first three messages in Figure 8 use elliptic curvecryptography for mutual authentication. We observe that anattacker has to work with three pieces of information to breakthis scheme i.e., z1, z2 and r. So the attacker’s goal is to obtaina from aG or b from bG or to understand Ri + b(aG). Thisshows that the problem of an attacker reduces to an ellipticcurve discrete logarithm problem (ECDLP):

Definition 8.1: Given an elliptic curve C defined over Fq

and two points P , Q ∈ C, then the ECDLP problem is to findan integer x such that Q = xP .This problem is considered more difficult than various factor-ization problems, and the general discrete logarithm problemused in contemporary crypto-systems. In other words, IoTdevice IDA and the authorization server need to performsimple operations such as addition and subtraction on thecurve, whereas the task that needs to be executed by theattacker is intractable. The reasons behind choosing ellipticcurve cryptography for our protocol are as follows:

1) computational efficiency: performing scalar multiplica-tions requires less computational power both in softwareand hardware, as compared to implementing multiplica-tions or exponentiations.

2) key size: defining the security level as the time neededto break the system, elliptic curve cryptography is wellknown to require shorter key lengths for higher levelsof security, as compared to other crypto-systems such asRSA or Diffie-Hellman. A smaller key size translates tolower power, bandwidth, and computational requirements,which are all critical in IoT devices.

D. Protection against Physical and Cloning Attacks

The deployed IoT devices are generally accessible by theattacker. This may expose the secrets stored in the memory ofthe IoT device (e.g., cryptographic keys) through the widerange of techniques that are available to attacks memories[51], [52]. To protect IoT devices against such type of attacks,PUFs are used to generate secrets within the same chip whenneeded, without physically storing them [26], [27]. In otherwords, the availability of the PUF on chip permits to overcomethe weaknesses of conventional memories against physicalattacks, and makes the secret physically inaccessible (unlessvery expensive techniques to tamper PUFs are used [1]).

Moreover, an attacker may try to disguise or facade as alegitimate IoT device by extracting secrets from a captureddevice. However, launching this type of cloning attack onPUFs is widely considered extremely difficult and econom-ically nonviable, making PUFs an effective tool for hardwareauthentication [53], [54].

IX. SECURITY VERIFICATION AND SIMULATION RESULTS

The security of the proposed protocol was verified withthe security verification tool ProVerif (PV) [55], based on thescripts developed by the authors in [56].

11

A ATi↔S

A {A,S}c/‖Ti

A S {A,S}c/‖Ti

A S ARi↔S

A #(N3)∧

A SRi

|∼N3

A ARi↔S

∧A

Ri

/ N3

∧A S {S}c/‖Ti

∧A S

Ri

|∼Ti

A ARi↔S

∧A

Ri

/ Ti

∧A sup(S) ∧

A sup(S)∧

A #(Ti)

A #(N3)∧

A/N3 R RB

ARi

/ N3 R Ti

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

S ATi↔S

S {A,S}c/‖Ti

S ARi↔S

∧S Ac/‖Ti

∧S

Ri

|∼Ti ∧S #(Ti)

(b) “S believes Ti is a good shared key ofA and S”.

Fig. 13: Security Proofs for Authentication & Token Exchange

A ANB↔B

A {A,B}c/‖NB

A B {A,B}c/‖NB

A B Aki↔B

A #(NA)∧

A Bki|∼NA

A Aki↔B

∧A

ki/NA

∧A B {B}c/‖NB

∧A B

ki|∼NB

A Aki↔B

∧A

ki/NB

∧A sup(B) ∧

A #(NB)

A #(NA)∧

A/NA R NB

Aki/NA R NB

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

A ANA↔B

A {A,B}c/‖NA

A Aki↔B

∧A Bc/‖NA

∧A

ki|∼NA ∧

A #(NA)

(b) “A believes NA is a good shared secretof A and B”.

B ANA↔B

B {A,B}c/‖NA

B A {A,B}c/‖NA

B A Aki↔B

B #(NA)∧

B Aki|∼NA

B Aki↔B

∧B

ki/NA

∧B A {A}c/‖NA

∧B A

ki|∼NA

B Aki↔B

∧B

ki/NA

∧B sup(A) ∧

B #(NA)

B #(NB)∧

B/NA R NB

Bki/NA R NB

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

B ANB↔B

B {A,B}c/‖NB

B Aki↔B

∧B Ac/‖NB

∧B

ki|∼NB ∧

B #(NB)

(d) “B believes NB is a good shared keyof A and B”.

Fig. 14: Security Proofs for Access Phase

A. Phase 1

The authentication and token exchange phase involves twoentities: an IoT device IDA and the authorization server.In phase 1, our primary objective is to establish mutualauthentication of the IoT device IDA and the authorizationserver and also to securely exchange the access token. Eventsform the basis of the verification model in PV. To verify thesecurity of mutual authentication, the following events aredefined in PV:

• event beginAfull(IDA, IDS , Ri, T i, ki): the authoriza-

tion server IDS believes that the IoT device IDA hascommenced a run of the protocol with it, with Ri, T i,and ki as the shared secrets.

• event endAfull(IDA, IDS , Ri, T i, ki): the IoT device

IDA beleives that it has successfully completed theprotocol with the authorization server IDS , with Ri, T i,and ki as the shared secrets.

• event beginBfull(IDA, IDS , Ri, T i, ki): the IoT device

IDA believes that it has started a run of the protocolwith the authorization server IDS with the given protocolparameters.

• event endBfull(IDA, IDS , Ri, T i, ki): the server IDS

has successfully completed the protocol with the IoTdevice IDA with the given protocol parameters.

The mutual authentication goals for the proposed protocolare as follows:

1) Authentication of IDS to IDA: The IoT device IDA iswilling to share its data only with the authorization serverIDS . Therefore, if it believes that it has completed theprotocol with the authorization server IDS , then the IoTdevice IDA has indeed executed the protocol with theauthorization server IDS . PV can prove authenticationgoals using correspondence assertions [57]. We evaluatethe following correspondence queries in PV to prove thisproperty:

inj−event(endBfull(· · · )) ==>

inj−event(beginBfull(· · · )). (4)

Note that PV’s native support for predicates defined byHorn clauses leads to statements like EA ==> EB

where the goal is to check the fact “if an event EA isreachable, then EB must have been reached beforehand.”

2) Authentication of IDA to IDS: The authorizationServer IDS is willing to engange in a session with anyof its client IoT devices. Therefore, if it has executed theprotocol with the IoT device IDA then authenticationfrom the IoT device IDA to the authorization serverneeds to hold. We use the following correspondence

12

assertion to prove this property in PV:

inj − event(endAfull(· · · )) ==>

inj − event(beginAfull(· · · )). (5)

The other goal of the proposed protocol in this phase is thesuccessful exchange of the access token from the authorizationserver to the IoT device IDA. To achieve this goal the secrecyof T i and Ki needs to be established. This can be done inPV by querying an attacker and checking whether a term isavailable to an attacker or not. Note that reachability queries onthe attacker’s knowledge are used to encode syntactic secrecygoals in PV. For example, the secrecy of a term x is proven byusing x to encrypt an arbitrary term M . Then the attacker isqueried for the term M , and its reachability to M is checked(i.e., whether an attacker can obtain M or not). The syntacticsecrecy of T i and ki used in our protocol is established usingthe following queries in PV:

query attacker(ATi); attacker(AKi); (6)attacker(BTi); attacker(BKi). (7)

where ATi and AKi are used to establish the secrecy of T i

and ki at the site of principle IoT device IDA. Similarly, BTiand BKi are used to evaluate the secrecy of T i and Ki at thesite of the authorization server. The PV simulations showedthat the authentication goals are met and that the attackercannot obtain T i or ki using any definite or possible attack.

B. Phase 2The primary objective of phase 2 of the proposed protocol

is to authorize an IoT device to access another IoT device or aresource server. This involves mutual authentication of the IoTdevice IDA with either the IoT device IDB or the resourceserver IDR using the access token T i. The secret nonces NA

and NB in Figures 9 and 10 are used to establish the securitygoals in this phase. The protocol is considered secure if thetwo entities can successfully complete a run of the protocol,authenticating each other and secretly exchanging NA and NB .For this purpose the following events in PV are defined:• event beginAfull(IDA, IDB , NA, NB), which is used

by the IoT device IDB to record the initiation of theprotocol by IoT device IDA, using NA and NB as theshared secrets.

• event endAfull(IDA, IDB , NA, NB) which means thatthe IoT device IDA believes that it has successfullyreached the end of the protocol with the IoT device IDB

using NA and NB as the shared secrets.• event beginBfull(IDA, IDB , NA, NB), which means

that the IoT device IDA intends to execute the protocolwith the IoT device IDB utilizing the given protocolparameters.

• event endBfull(IDA, IDB , NA, NB), which representthe fact the IoT device IDB believes it has successfullycompleted a run of the protocol with the IoT device IDA

utilizing the given protocol parameters.The authentication goals in phase 2 are as follows:

1) Authentication of IDB /IDR to IDA: The IoT deviceIDA plans to establish a session with the IoT device IDB

or the resource server IDR. Therefore, if it successfullyreaches the end of the protocol, it has indeed executedthe protocol with the IoT device IDB or the resourceserver IDR; and the participants concur on the set ofgiven secrets. This property is proved in PV using thefollowing correspondence assertion:

inj − event(endBfull(· · · )) ==>

inj − event(beginBfull(· · · )). (8)

2) Authentication of IDA to IDB /IDR: If the IoT deviceIDB or the resource server IDR believes it has com-pleted the protocol with the IoT device IDA, then it hasin truth done so with the IoT device IDA. The followingcorrespondence assertion is used to prove this property:

inj − event(endAfull(· · · )) ==>

inj − event(beginAfull(· · · )). (9)

Note that only IoT device IDA and IoT Device IDB orresource server IDR can obtain the secret key ki in Figures9 and 10. Therefore, the syntactic secrecy of NA and NB isestablished as these secrets are exchanged using the symmetrickey ki. This is done using the following queries:

query attacker(ANa); attacker(ANb); (10)attacker(BNa); attacker(BNb); (11)

where, ANa, and ANb are arbitrary terms encrypted usingNA and NB , respectively, at the site principle of IoT deviceIDA. Similarly, BNa and BNb are arbitrary terms encryptedusing NA and NB , respectively, at the site principle of IoTdevice IDB or resource server IDR.

Running the simulation scripts for phase 2 of the proposedprotocol in PV confirmed that the proposed protocol satisfiesthe desired security goals.

X. PERFORMANCE ANALYSIS

In this section, we evaluate the performance of the proposedprotocol in terms of computational complexity and energyrequirements. The proposed protocol was also compared tothe authentication protocol based on the state-of-the-art au-thentication technique ZKPK using PUFs [58]. This protocolis adopted as a reference in view of the fact that many state-of-the-art protocols are instantiations of ZKPK [59].

A. Computational Complexity

Table III shows the number of hashes (NH ), MACs(NMAC), encryptions/decryptions (NENC), modular exponen-tiations (Nexp), modular multiplications (N×), point addi-tion (NECC+ ) and point multiplication (NECC× ) operationsrequired by the proposed protocol and [58]. Counting theoccurrence of the respective operations from Figures 8 - 10results in these values.

If we assume MACs using universal hashing (UMACS)[61], then the worst case time complexity for MAC operationsis O(n) [62], [63] for a message size n. Similarly, the timecomplexity for encryption and decryption is O(n) for blockciphers. If we assume a finite field size of m bits for elliptic

13

TABLE III: Computational Complexity

Task IoT Device IDAAuthorization

ServerIoT Device IDB /Resource Server

Authentication2NMAC + 1NENC

+1NECC++ 1NECC×

2NMAC + 1NENC

+1NECC+2NECC×

–

Authorization 3NMAC + 2NENC – 3NMAC + 2NENC

[58]2NH + 2Nexp

+N× + 2NMAC1NH + 3Nexp + 1NMAC –

TABLE IV: Parameter Lengths

Parameter Size (bits)ID 8 [67]N3, N4 48 [68]NA, NB , ki, C, R 64, 128, 192, 256TTL, length, Scope 8key size 2

curve cryptography, then the time complexity of point additionand point multiplication is given by O(mk) and O(mk+1),respectively, where k = 1.585 using Karatsuba multiplica-tion [65]. Thus, the complexity of the proposed protocol isO(n +mk+1) for the IoT device IDA and the authorizationserver, while it isO(n) for IoT device IDB and the resourceserver.

It is worth observing that authentication protocols based onZKPK require modular exponentiation, which is a computa-tionally expensive operation. If M(l) represents the complex-ity of a general modular multiplication with l-bit operands(key size), then the time complexity for [58] is O(n+M(l)k)for the IoT device IDA and the authorization server. Inturn, M(l) is generally quadratic in l [64], and k is theexponent. Accordingly, the complexity in the algorithm in [58]is O(n + l2k), where the key size for [58] is at least fiveorders of magnitude larger than the field size m of ellipticcurve cryptography [60]. Thus, the proposed protocol has asignificantly lower complexity than [58].

B. Energy Reduction and a Case Study

The proposed protocol was emulated on the MICA 2 moteplatform to characterize the related energy consumption usingthe AVRORA energy analysis tool [66]. AVRORA is a cycle-accurate instruction-level sensor network simulator with anal-ysis tools for the Atmel AVR microcontroller and the MICA 2sensor nodes. The MICA 2 mote is based on the MPR400CBprocessor and a radio with an 868/910 MHz, 433 or 315MHz multi-channel transceiver. The adopted parameters usedto emulate the proposed protocol are given in Table IV.

In the following, the energy associated with the CPU of themote includes the security sub-system, and other tasks suchas boot, idle state, among the others. The energy associatedwith the security sub-system comprises the contribution ofphases 1-2 discussed in Section 5. Since phase 1 involves thecompute-intensive calculation of the elliptic curve parameters,its energy largely dominates over the contribution of phase2. The energy associated with the radio transceiver includesthe contribution due to the data payload (i.e., message) andthe associated MAC, of which only the latter benefits from

the key size reduction. Hence, the proposed energy-qualityscalable protocol is expected to deliver more substantial energybenefits at shorter message lengths, which is typical of mostof IoT devices.

For each energy contribution, the ability to scale down theenergy at lower key size is quantified by the energy scalability,which is defined as the percentage energy reduction for 1-bit key size reduction (i.e., the ratio between the percentageenergy reduction divided by the number of bits by which thekey size is reduced). In the following, the considered key (or,equivalently, MAC) size covers the entire range of 64-256bits in Table 1. The data payload size is set to the valuesof 8, 64, 256 and 1,024 bits. As an example, these valuesare respectively representative of the information related tothe battery status, an individual sample of an indoor weatherstation, an event timestamp (e.g., date and time), and a seriesof samples in an event detected by a motion sensor in anindustrial machine.

The CPU energy consumption for an IoT device in Phase1 and Phase 2 with key sizes ranging from 64 to 256 bits isshown in Table V. At the maximum security level of 256 bits,which would remain fixed in a conventional system withoutenergy-quality scalability, 71.57% (0.21%) of the CPU energyis due to phase 1 (2), whereas 28.22% is associated withall other tasks. From Table V, the reduction of the key sizedown to 64 bits leads to a 77.05% (46.48%) reduction in theenergy associated with the security sub-system in phase 1 (2),whereas the energy associated with all other tasks is reducedby 17.10% (as the CPU needs to stay idle for a shorter timewhen transmitting shorter messages). Overall, this leads to anoverall reduction in the CPU energy by 60.07%. Figure 15summarizes the CPU energy for various key sizes and payloadsizes. From this figure, the energy scalability of the CPUenergy around the intermediate key size of 128 bits for a datapayload carrying 8 bits is 0.21%/bit. The energy scalabilityexpectedly decreases when the data payload is longer, as thelinear reduction in the dominant energy associated with theMAC transmission becomes a smaller fraction of the overallenergy. As a consequence, the CPU energy saving at key sizeof 64 bits compared to 256 bits decreases from 39.80% at datapayload with 8 bits to 35.49% with 1,024 bits.

As summarized in Table V, the energy associated with theradio transceiver with 256-bit key in phase 1 (2) is 2.11%(2.28%), and 95.6% is associated with other tasks. Even thelatter energy contribution benefits from the key size reduction,as this reduces the time when the radio is kept on whileexecuting other security-related tasks. The key size reductionto 64 bits reduces the energy due to phase 1 (2) by 56.00%(64.67%), and 77.18% for all other tasks. Overall, this leadsto a transceiver energy reduction by 76.44%. The transceiverenergy is plotted versus the key size in Figure 16 under variousdata payload sizes. From this figure, the transceiver energy isreduced by 44.78% down to 13.30%, under payloads rangingfrom 8 bits up to 1,024 bits, when the key size is reduced from256 to 64 bits. The energy scalability of the transceiver energyaround the intermediate key size of 128 bits for a data payloadsize of 8 bits is 0.23%/bit, which is reduced to 0.07%/bit at1,024-bit payload size.

14

Fig. 15: Energy consumed for various data payload sizes.

When the overall energy due to both the CPU and thetransceiver is considered, the energy scalability associated withthe proposed protocol for the reduction of the key size from256 down to 64 bits leads to an overall energy reduction of0.36%/bit. Accordingly, the reduction from 1,024 down to 8bits during data transfer leads to an overall energy reductionranging from 0.08%/bit to 0.23%/bit, which is substantial fordata payload sizes that are comparable or shorter than the keysize.

The proposed protocol was also compared to [58] interms of energy efficiency. Like most authentication proto-cols, ZKPK uses modular exponentiation, hence the proposedprotocol is expected to entail lower computational effort andenergy, thanks to the use of elliptic curve cryptography. TableVI reports the energy consumed by the protocol in [58],whose overall value is approximately the same as the proposedprotocol for a key size of 64 bits, and is substantially largerfor larger key sizes. This is explained by considering that thecomplexity of modular exponentiation used in ZKPK growsexponentially with the key size. The energy consumed bythe proposed protocol is 72.58% lower in terms of the CPUcontribution and 86.35% lower for the radio transceiver, for akey size of 256 bits. The transceiver in [58] consumes higherenergy due to longer protocol messages, and the fact that theradio stays idle for a longer time as required by the parametercalculation such as the public/private keys (included in othertasks in Table VI). Moreover, the proposed protocol has afundamental energy advantage as its large energy contributionrequired by phase 1 is consumed only infrequently, since theIoT device can reuse the same token several times as per theOAuth framework. Overall, the proposed protocol consumessubstantially lower energy compared to [58], thanks to thetoken reuse, the avoidance of modular exponentiation, andenergy-quality scalability, which are respectively responsiblefor 80%, 65.86% and 51.54% energy reduction.

XI. CONCLUSIONS

In this paper, a token-based security protocol with energy-quality tradeoff for authentication and authorization in IoTsystems has been introduced. The proposed protocol is based

Fig. 16: Energy consumed for various data payload sizes.

on the OAuth 2.0 framework which makes it suitable fordiverse and large scale systems as required by the IoT. Theproposed protocol is based on a challenge-response mecha-nism combined with elliptic curve cryptography using PUFs.Dynamic energy-quality tradeoff is enabled from the hardwaresubsystems up to the protocol. The security of the proposedprotocol has been assessed through formal analysis and sim-ulations. Emulation of the popular MICA 2 mote has shownthat energy-quality reduces the energy by 0.31-0.4% for each1-bit reduction in the key size, when it is dynamically adjustedto the actually required security level. Results have shownthat energy is reduced by up to 69% for authentication andauthorization, and up to 45% during data transfer, especiallywhen short messages are transmitted (as representative ofmany IoT devices). Finally, the proposed protocol has beenshown to require less energy than state-of-the-art protocols,thanks to the token reuse enabled by the OAuth framework, theavoidance of modular exponentiation, in addition to energy-quality scalability.

ACKNOWLEDGMENT

The authors thank the Singapore Ministry of Education(MOE2016-T2-1-150 grant) for funding support.

REFERENCES

[1] M. Alioto (Ed.), Enabling the Internet of Things from Integrated Circuitsto Integrated Systems, Springer, 2017.

[2] “The Economic Impact of Cybercrime and Cyber Espionage”, Centerfor Strategic and International Studied Report, 2013.

[3] Global Risks 2015 Report.10th Ed., World Economic Forum, Geneva.[4] M. N. Aman, et. al. “Physical Unclonable Functions for IoT Security.”

In Proc. ACM IoTPTS, New York, NY, USA, 10-13, 2016.[5] J. Koomey et. al., “Implications of Historical Trends in the Electrical

Efficiency of Computing,” in IEEE Annals of the History of Computing,vol. 33, no. 3, pp. 46-54, March 2011.

[6] S. Borkar, “Design challenges of technology scaling,” in IEEE Micro,vol. 19, no. 4, pp. 23-29, Jul-Aug 1999.

[7] Verayo Inc., http://www.verayo.com/tech.php, 2013.[8] ICTK, Co. Ltd., http://www.ictk.com/servicenproduct/puf, 2014.[9] Intrinsic-ID, SRAM PUF: The secure silicon fingerprint, White Paper,

2016.[10] Invia PUF IP. http://invia.fr/infrastructure/physical-unclonable-function-

PUF.aspx, 2016.[11] “The OAuth 2.0 Authorization Framework”, IETF RFC 6749, 2012.

15

TABLE V: Energy Consumption for Proposed Protocol and Savings Compared to Fixed 256-bit Key

Key SizePhase 1µJ

SavingsµJ

Phase 2µJ

SavingsµJ

Other TasksµJ

SavingsµJ

TotalµJ

SavingsµJ

EnergyScalability

(%/bit)CPU

64 bits 18,611.04 62,472.85 (77.05%) 127.51 110.73 (46.48%) 26,503.00 5,467.57 (17.10%) 45,241.51 68,051.19 (60.07%) 0.31128 bits 39,311.60 41,772.29 (51.52%) 163.71 74.53 (31.28%) 28,321.25 3,649.32 (11.41%) 67,796.56 45,496.14 (40.16%) 0.31192 bits 60,183.29 20,900.60 (25.78%) 200.74 37.50 (15.74%) 30,144.27 1826.30 (5.71%) 90,528.30 22,764.40 (20.09%) 0.31256 bits 81,083.89 – 238.24 – 31,970.57 – 113,292.7 – –

Radio64 bits 1,073.92 1,361.23 (56.00%) 930.03 1,701.50 (64.67%) 25,191.57 85,191.91 (77.18%) 27,195.52 88,254.64 (76.44%) 0.40128 bits 1,527.95 907.20 (37.26%) 1,497.53 1,134.00 (43.10%) 53,576.63 56,806.85 (51.46%) 56,602.12 58,848.04 (50.97%) 0.40192 bits 1,981.55 453.58 (18.63%) 2,064.53 567.02 (21.55%) 81,982.98 28,400.50 (25.73%) 86,029.06 29,421.10 (25.48%) 0.40256 bits 2,435.15 – 2,631.53 – 110,383.48 – 115,450.16 – –

TABLE VI: Energy Consumption for Protocol Proposed by[58]

Key SizeProtocolµJ

Other tasksµJ

TotalµJ

CPU64-bits 15,684.14 26,569.03 42,253.15128-bits 47,711.48 30,131.76 77,843.01192-bits 87,738.38 33,694.50 121,432.86256-bits 127,765.47 37,257.24 165,022.71

Radio64-bits 1,361.40 24,923.80 26,285.19128-bits 1,924.85 82,036.25 83,961.11192-bits 2,488.31 139,148.70 141,637.01256-bits 3,051.77 196,261.16 199,312.92

[12] R. Das et al., “A Deep Learning Approach to IoT Authentication,” inProc. IEEE ICC, Kansas City, MO, USA, 2018, pp. 1-6.

[13] A. Z. Ourad, B. Belgacem, K. Salah, “Using Blockchain for IOT AccessControl and Authentication Management,” in D. Georgakopoulos, LJ.Zhang (eds) Internet of Things ICIOT 2018, Lecture Notes in ComputerScience, vol 10972. Springer, Cham.

[14] X. Li et. al., “A three-factor anonymous authentication scheme forwireless sensor networks in internet of things environments,” in J.Network and Comp. Applications, vol. 103, pp. 194-204, Feb. 2018.

[15] X. Li et. al., “A Robust ECC-Based Provable Secure AuthenticationProtocol With Privacy Preserving for Industrial Internet of Things,” inIEEE Trans. Indust. Inform., vol. 14, no. 8, pp. 3599-3609, Aug. 2018.

[16] U. Chatterjee et al., “A PUF-Based Secure Communication Protocol forIoT,” in ACM Trans. Embedded Comput. Sys., vol. 16, no. 3, pp. 67-91,Jul. 2017.

[17] U. Chatterjee et al., “Building PUF based Authentication and KeyExchange Protocol for IoT without Explicit CRPs in Verifier Database,”in IEEE Trans. Dependable and Secure Computing, preprint, May 2018.

[18] M. N. Aman, K. C. Chua and B. Sikdar, “Mutual Authentication inIoT Systems Using Physical Unclonable Functions,” in IEEE Internetof Things Journal, vol. 4, no. 5, pp. 1327-1340, Oct. 2017.

[19] K. Yang et al., “A 553F2 2-transistor amplifier-based Physically Unclon-able Function (PUF) with 1.67% native instability,” in IEEE Interna-tional Solid-State Circuits Conference, San Francisco, CA, pp. 146-147,2017.

[20] S. Taneja, A. Alvarez, M. Alioto, “Fully Synthesizable PUF FeaturingHysteresis and Temperature Compensation for 3.2% Native BER and1.02fJ/b in 40nm,” in IEEE Journal of Solid-State Circuits, vol. 53, no.10, pp. 2828-2839, Oct. 2018.

[21] M. Alioto, A. Alvarez, “Physically Unclonable Function database,”[Online]. Available: http://www.green-ic.org/pufdb.

[22] A. Basak et. al., “Reconfigurable ECC for adaptive protection ofmemory,” 2013 IEEE MWSCAS, Co-lumbus, OH, 2013.

[23] J. Park et. al., “VL-ECC: Variable Data-Length Error Correction Codefor Embedded Memory in DSP Applications,” in IEEE Trans. on Circ.and Sys. II: Express Briefs, 61(2), pp. 120-124, Feb. 2014.

[24] S. K. Mathew et al., “53 Gbps Native GF(24)2 Composite-Field AES-Encrypt/Decrypt Accelerator for Content-Protection in 45 nm High-Performance Microprocessors,” in IEEE Journal of Solid-State Circuits,vol. 46, no. 4, pp. 767-776, April 2011.

[25] B. Gassend et. al., “Silicon physical random functions.” In Proc. ACMCCS, Vijay Atluri (Ed.), New York, NY, USA, 148-160, 2002.

[26] J. W. Lee et. al., “A technique to build a secret key in integrated circuitsfor identification and authentication applications,” 2004 Symp. on VLSICircuits. Digest of Technical Papers (IEEE Cat. No.04CH37525), 2004,pp. 176-179.

[27] R. Maes, Physically Unclonable Functions: Construction, Propertiesand Applications (Springer, London, 2013).

[28] G. E. Suh et. al., “Aegis: A Single-Chip Secure Processor,” in IEEEDesign & Test of Computers, 24(6), pp. 570-580, Dec. 2007.

[29] “Yearly Report on Algorithms and Keysizes (2012)”, D.SPA.20 Rev. 1.0,ICT-2007-216676 ECRYPT II, 09/2012.

[30] M. Blaze, et. al., “Minimal Key Lengths for Symmetric Ciphers toProvide Adequate Commercial Security”, Report of ad hoc panel ofcryptographers and computer scientists, Jan. 1996.

[31] “Recommendation for Key Management”, Special Publication 800-57Part 1 Rev. 4, NIST, 01/2016.

[32] “Mcanismes cryptographiques - Rgles et recommandations”, Rev. 2.03,ANSSI , 02/2014.

[33] “Kryptographische Verfahren: Empfehlungen und Schlssellngen”, TR-02102-1 v2017-01, BSI, 02/2017.

[34] “The Use of AES-192 and AES-256 in Secure RTP”, IETF RFC 6188.[35] “Commercial National Security Algorithm”, Information Assurance Di-

rectorate at the NSA, 01/2016.[36] W. Zhao et. al., “AES architectures for minimum-energy operation and

silicon demonstration in 65nm with low-est energy per encryption,” 2015IEEE ISCAS, Lisbon, 2015, pp. 2349-2352.

[37] R. Beaulieu et. al., “The SIMON and SPECK lightweight block ciphers,”2015 52nd ACM/EDAC/IEEE Design Automation Conference (DAC),San Francisco, CA, 2015, pp. 1-6.

[38] Texas Instruments Low Power 2.4GHz RF Transceiver CC2500datasheet, http://www.ti.com/lit/ds/symlink/cc2500.pdf

[39] M. Alioto, ”Energy-quality scalable adaptive VLSI circuits and systemsbeyond approximate computing,” Proc. DATE, 2017, Lausanne, 2017,pp. 127-132.

[40] I.A.Dhotre V.S.Bagad, Networks and Information Security, TechnicalPublications 2008.

[41] J. R. Vacca (Ed.), Network and System Security, Elsevier, 2014[42] S. Guilley, and R. Pacalet, “SoCs security: a war against side-channels”,

Annals of Telecommunications, 59(7), pp. 998-1009, 2004.[43] M. Kirkpatrick et. al., “System on Chip and Method for Cryptography

using a Physically Unclonable Function,” U.S. Patent 8750502 B2,issued March 22, 2012.

[44] “TOTP: Time-Based One-Time Password Algorithm”, IETF RFC 6238,2011.

[45] D. Hankerson et. al., Guid to Elliptic Curve Cryptography (1st ed.),Springer, 2010.

[46] D. P. Sidhu, “Authentication protocols for computer networks: I”,Computer Networks and ISDN systems, Vol. 11, pp. 287-310, 1986.

[47] V. Varadharajan, “Verification of network security protocols”, Computersand Security 8, pp. 693708, 1989.

[48] G. V. Bochman, “Finite state description of communication protocols”,Computer Networks, Vol. 2, pp. 361-372, 1978.

[49] M. Burrows et. al., “A logic of authentication”, ACM Trans. on ComputerSystems, 8, Feb. 1990.

16

[50] W. Mao and C. Boyd, “Towards formal analysis of security protocols”,Proc. Comp. Sec. Foundations Workshop VI, pp. 147-158, 1993.

[51] O. Kommerling and M. Kuhn, “Design Principles for Tamper- Resis-tant Security Processors,” USENIX Workshop on Smartcard Technol-ogy, Chicago, IL (1011 May 1999) http://www.cl.cam.ac.uk/Research/Security/tamper.

[52] K. Nohl and C. Tarnovsky, “Reviving smart card analysis,” in Blackhat2011, Las Vegas, NV, Aug. 2010.

[53] G. E. Suh, and S. Devadas “Pysical Unclonable Functions for DeviceAuthentication and Secret Key Generation,” Proceedings of IEEE/ACMDAC, pp. 9-14, San Diego, CA, June 2007.

[54] J. B. Wendt and M. Potkonjak, “Hardware obfuscation using PUF basedlogic,” Proc. ICCAD, pp. 18, 2014.

[55] B. Blanchet and B. Smyth, ProVerif: Automatic Cryptographic ProtocolVerier, User Manual and Tutorial.

[56] https://www.ece.nus.edu.sg/stfpage/bsikdar/scripts/TDSCJ.[57] T.Y.C. Woo and S.S. Lam. “A semantic model for authentication

protocols”. In IEEE Symp. on Sec. and Privacy, pp. 178194, 1993.[58] K. Frikken et. al., “Robust Authentication Using Physically Unclonable

Functions”, In: P. Samarati et al. (eds.): ISC 2009, LNCS 5735, pp.262-277, Springer, Heidelberg 2009.

[59] U. Maurer. “Unifying Zero-Knowledge Proofs of Knowledge”. In Proc.AFRICACRYPT, Bart Preneel (Ed.). Springer-Verlag, Berlin, Heidelberg,272-286, 2009.

[60] C. F. Kerry, “Digital signature standard (DSS)”, National Institute ofStandards and Technology, 2013.

[61] T. Krovetz, “UMAC: Message Authentication Code using UniversalHashing”, IETF RFC 4418, March 2006.

[62] M. Babka, “Properties of Universal Hashing,” Charles University inPrague, Master Thesis, 2010.

[63] Y. Mansour et. al., “The Computational Complexity of Universal Hash-ing,” Theoretical Computer Science, vol. 107, no. 1, pp. 121-133, 1993.

[64] T. Kivinen and M. Kojo, “More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE),” IETF RFC 3526,May 2003.

[65] A. Karatsuba. “The complexity of computations”, in Proc. of the SteklovInstitute of Mathematics, volume 211, pp. 169183, 1995.

[66] B. L. Titzer et. al., “Avrora: scalable sensor network simulation withprecise timing”. In Proc. IEEE IPSN, NJ, USA, , 2005 .

[67] P. Kim, “ IoT Specific IPv6 Stateless Address Autoconfiguration withModified EUI-64,” IETF Internet-Draft, July 2015.

[68] D. Whiting et. al., “Counter with CBC-MAC (CCM),” IETF RFC 3610,September 2003.

APPENDIX

In this we introduce the formal analysis of security protocolsusing the Mao and Boyd logic [50]. Logical formulas areconstructed using messages M , principals P and formulasF . We denote principals by capital letters A, B, P , Q, · · · ,messages by K, M , N, · · · , and formulas by X , Y , Z, · · · .The predicate constructs used in our analysis are as follows:• P X: P believes X is true and may act accordingly.

• PK

|∼ X: P encrypted X using key K.• P

K/ X: P obtains X using decipherment key K. P /X

is used when there is no encryption.• P

K↔ Q: K is a good shared secret for P and Q.• #(M): M is not used before and can be considered fresh.• sup(S): Principal S is the trusted party.• P/ ‖M : Message M is not available to principal P .• P c: Denotes complement of P and represents everyone

else except the principal P .Next, the rules for protocol message idealisation are given

as follows:• Atomic Message: An atomic message is a piece of data

constructed without using any of the symbols “,”, “|”,“R”, or “{}”. We use “,” to separate fields in a message

and “{}” for encryption. We will define the purpose ofthe symbols “|” and “R” below.

• Challenge: An atomic message sent and received by thesame principal (the initiator) in separate lines except fortime stamps. receive it in another line.

• Replied Challenge: A challenge that is sent back in amessage to the initiator.

• Response: An atomic message (except timestamps) sentin reply to a challenge.

• Nonsense: If an atomic message is not a challenge,response, or a timestamp, it is considered a nonsense.

The rules for protocol message idealization are as follows:1) Remove any nonsense.2) An atomic message that is a challenge as well as a

response in a line is considered a response.3) Challenges or responses separated by commas are com-

bined using operator “|”.4) A challenge and its response is combined using “R” into

“response R replied challenge”.5) A timestamp is combined with a message using “R” into

“message R timestamp”.Finally we present the inference rules as follows:

1) Authentication Rule: P believes Q sent M , if K is agood secret key between P and Q, and P decrypted themessage M using K to decrypt a received message M ,then P can believe that . The rule is given as

P QK

|∼M

P PK↔Q

∧P

K/M

. (12)

2) Confidentiality Rule: P beleives no one else except Pand Q has seen M if K is a shared secret key betweenP and Q and P used K to encrypt M and sent it withoutsharing it with anyone else. The rule is represented as

P (S∪{Q})c/‖M

P PK↔Q

∧P Sc/‖M

∧P

K

|∼M. (13)

3) Super-Principal Rule: P believes what ever Q believesif P believes Q is a trusted principle:

P X

P Q X∧

P sup(Q)

. (14)

4) The Fresh Rule: If P has seen N and M together in amessage and P believes M is fresh then P can believeN is fresh too. The rule is given as

P #(N)

P #(M)∧

P/NRM

. (15)

5) The Good-Key Rule: There are two variations to thisrule: (i) P can trust K as a good key between P and Q,if P believes that no one else except P and Q has seenK, and P knows that K is fresh:

P PK↔Q

P {P,Q}c/‖K∧

P #(K)

(16)

and (ii) if P believes that no one except P , Q and R has

17

seen K, and P trusts R, and P believes K is fresh, thenP can believe K is a good secret between P and Q:

P PK↔Q

P {P,Q,R}c/‖K∧

P sup(R)∧

P #(K)

. (17)

6) Derived Rule: The belief axiom

P (X∧Y ) if and only if P X

∧P Y (18)

is combined with the confidentiality rule. The rule can berepresented as

P Q (S∪{P})c/‖M

P Q PK↔Q

∧P Q Sc/‖M

∧P Q

K

|∼M. (19)

Muhammad Naveed Aman (S12-M17) receivedthe B.Sc. degree in Computer Systems Engineeringfrom KPK UET, Peshawar, Pakistan, M.Sc. degreein Computer Engineering from the Center for Ad-vanced Studies in Engineering, Islamabad, Pakistan,M.Engg. degree in Industrial and Management En-gineering and Ph.D. in Electrical Engineering fromthe Rensselaer Polytechnic Institute, Troy, NY, USAin 2006, 2008, and 2012 respectively.He is currently working as a Senior Research Fellowwith the Department of Computer Science at the Na-

tional University of Singapore, Singapore. Dr. Aman previously served on thefaculty of National University of Computer and Emerging Sciences Pakistanas an Assistant Professor. His research interests include IoT and networksecurity, wireless and mobile networks, and secure embedded systems.

Sachin Taneja (S16) received the bachelors degreein electronics engineering from Indraprastha Uni-versity, New Delhi, India, in 2013. He is currentlypursuing the Ph.D. degree in electrical and com-puter engineering with the National University ofSingapore, Singapore. He was with Synopsys Inc.,India, where he was involved in designing high-speed memory circuits. His current research interestsinclude the design of energy-efficient circuits andarchitectures to enable hardware security in Internetof Things platforms.

Biplab Sikdar (S98-M02-SM09) received theB.Tech. degree in electronics and communica-tion engineering from North Eastern Hill Univer-sity,Shillong, India, in 1996, the M.Tech. degree inelectrical engineering from the Indian Institute ofTechnology, Kanpur, India, in 1998, and the Ph.D.degree in electrical engineering from the RensselaerPolytechnic Institute, Troy, NY, USA, in 2001. Hewas on the faculty of Rensselaer Polytechnic Insti-tute from 2001 to 2013, first as an Assistant and thenas an Associate Professor.

He is currently an Associate Professor with the Department of Electricaland Computer Engineering, National University of Singapore, Singapore. Hisresearch interests include wireless network, and security for IoT and cyberphysical systems. Dr. Sikdar is a member of Eta Kappa Nu and Tau Beta Pi. Heserved as an Associate Editor for the IEEE Transactions on Communicationsfrom 2007 to 2012. He currently serves as an Associate Editor for the IEEETransactions on Mobile Computing.

Kee Chaing Chua received a Ph.D. in electricalengineering from the University of Auckland, NewZealand, in 1990 and joined the Department ofElectrical Engineering at the National University ofSingapore (NUS) as a Lecturer. He is now a Pro-fessor in the Department of Electrical & ComputerEngineering at NUS. He served as the Faculty ofEngineerings Vice Dean for Research twice, from2003 to 2006 and from 2008 to 2009. From 1995 to2000, he was seconded to the Center for WirelessCommunications (now the Institute for Infocomm

Research), a national telecommunication R&D center funded by the SingaporeAgency for Science, Technology, and Research as its Deputy Director. From2001 to 2003, he was on leave of absence from NUS to work at SiemensSingapore where he was the Founding Head of the Mobile Core R&DDepartment funded by Siemens ICM Group. From 2006 to 2008, he wasseconded to the National Research Foundation as a Director. He was appointedHead of the Department of Electrical & Computer Engineering at NUS in2009. He chaired the World Economic Forums Global Agenda Council onRobotics and Smart Devices in 2011 and spoke on the role of robotics andsmart devices in shaping new models of development at the World EconomicForum in Davos in January 2012. He is a Fellow of the Singapore Academyof Engineering.

Massimo Alioto (M01-SM07-F16) received theLaurea (MSc) degree in Electronics Engineering andthe Ph.D. degree in Electrical Engineering from theUniversity of Catania (Italy) in 1997 and 2001,respectively. He is with the Department of Electricaland Computer Engineering, National University ofSingapore where he leads the Green IC group and isthe Director of the Integrated Circuits and EmbeddedSystems area. Previously, he held positions at theUniversity of Siena, Intel Labs CRL (2013), Uni-versity of Michigan Ann Arbor (2011-2012), BWRC

University of California, Berkeley (2009-2011), and EPFL (Switzerland,2007).

He has authored or co-authored more than 250 publications on journalsand conference proceedings. One of them is the second most downloadedTCAS-I paper in 2013. He is co-author of three books, Enabling the Internetof Things - from Circuits to Systems (Springer, 2017), Flip-Flop Design inNanometer CMOS - from High Speed to Low Energy (Springer, 2015) andModel and Design of Bipolar and MOS Current-Mode Logic: CML, ECL andSCL Digital Circuits (Springer, 2005). His primary research interests includeself-powered wireless integrated systems, near-threshold circuits for greencomputing, energy-quality scalable integrated systems, data-driven integratedsystems, hardware-level security, and emerging technologies, among theothers.

He is the Editor in Chief of the IEEE Transactions on VLSI Systems (2019-2020), and Deputy Editor in Chief of the IEEE Journal on Emerging andSelected Topics in Circuits and Systems. In 2009-2010 he was DistinguishedLecturer of the IEEE Circuits and Systems Society, for which he is/was alsomember of the Board of Governors (2015-2020), and Chair of the VLSISystems and Applications Technical Committee (2010-2012). In the last fiveyears, he has given 50+ invited talks in top conferences, universities andleading semiconductor companies. He served as Guest Editor of several IEEEjournal special issues (e.g., TCAS-I, TCAS-II, JETCAS). He also serves orhas served as Associate Editor of a number of IEEE and ACM journals. Heis/was Technical Program Chair (ISCAS 2022, SOCC, ICECS, NEWCAS,VARI, ICM, PRIME) and Track Chair in a number of conferences (ICCD,ISCAS, ICECS, VLSI-SoC, APCCAS, ICM). Currently, he is also in theIEEE Digital circuits ISSCC subcommittee, and the IEEE ASSCC technicalprogram committee. Prof. Alioto is an IEEE Fellow.