1

IoT-Proctor: A Secure and Lightweight DevicePatching Framework for Mitigating Malware Spread

in IoT NetworksMuhammad Naveed Aman, Member, IEEE, Uzair Javaid, and Biplab Sikdar, Senior Member, IEEE

Abstract—Traditional malware propagation control schemesdo not prevent device-to-device (D2D) malware spread, havehigh time cost, and may result in low probability of detectingcompromised devices. Moreover, the unprecedented scale andheterogeneity of IoT devices make these schemes inapplicableto IoT networks. Therefore, to rectify these issues, this paperpresents a secure patching framework for IoT with different net-work isolation levels to efficiently mitigate and control malwarepropagation. It uses remote attestation to detect compromised de-vices with a high probability and identify the origin of maliciousactivities. It also proposes virtual patching of devices via PhysicalUnclonable Functions (PUFs) to contain the malware spread. Theisolation levels are based on the susceptible, exposed, infected,and resistant (SEIR) model that act as an access control listto quantify device operation and mitigate D2D malware spread.We present a security analysis based on the Access Control Logicmodel. A performance evaluation with a comparative analysis isalso discussed using the SEIR model. These analyses confirmthe reduction in patching time and superior performance of ourframework, i.e. with 10% of initially infected devices, IoT-Proctorhad a reduction rate of malware five times faster than the existingtechniques.

Index Terms—Patching; Network Security; Internet of Things(IoT); Software Attestation; Malware

I. INTRODUCTION

A recent study by F-Secure showed that the attack trafficrelated to Internet of Things (IoT) in 2019 increased atan unprecedented rate with 2.9 billion events recorded [1],[2]. With the expected exponential growth of IoT devices,this increase may be attributed to the increasing number ofdevices. Also, a further increase in cyber attacks on IoT basedsystems can also be expected. Moreover, the lack of defensesin aging firmware or architecture as well as poor informa-tion security maintenance may also be exploited by cybercriminals. Common remedies against cyber attacks includefirewalls and intrusion prevention systems. However, thesesystems depend on Internet connectivity and are expensivefor remote IoT deployments [3]–[5]. Security researchers haverepeatedly highlighted the lack of proper security measures in

This work was supported in part by the National Research Foun-dation, Prime Minister’s Office, Singapore under its Corporate Labora-tory@University Scheme, National University of Singapore, and in part bythe Singapore Telecommunications Ltd.M. N. Aman is with School of Computing, National University of Singapore,13 Computing Drive, Singapore 117417 (email: naveed@comp.nus.edu.sg).U. Javaid and B. Sikdar are with Department of Electrical and ComputerEngineering, National University of Singapore, 4 Engineering Drive 3, Sin-gapore 117576 (email: uzair.javaid@u.nus.edu; bsikdar@nus.edu.sg).

existing IoT devices, where 95% of the vulnerabilities foundin smart devices come from malware [6]. The most commontype of malware targets vulnerable devices to form botnetsused to launch distributed denial of service (DDoS) attacks.For example, the Mirai botnet was used to take down accessto GitHub, Twitter, and Netflix websites in North America [7].

Malware in IoT devices may propagate through infras-tructure links or device-to-device (D2D) links [8], [9]. Theformer may be exploited when a connected device is targetedusing address space scanning, Telnet, and brute-force passwordcracking [10], whereas the latter has been exploited in the past,e.g., the Cabir and Commwarror mobile worms used Bluetoothto spread among Symbian based mobile phones. Many IoTdevices use near field communication (NFC), Bluetooth LowEnergy (BLE), and other wireless standards (e.g., Zigbee)for communication. Researchers have shown the feasibilityof malware spread via proximity-based wireless interfaces[11]. Regardless of how malware propagates, the risk of self-replicating malware is magnified by unpatched devices. Ad-ditionally, while some IoT devices may have security patchesavailable, patching remains costly and an ineffective practice.

The existing work on developing a framework to controlmalware propagation in IoT uses network traffic analysisto detect compromised devices and is focused on patchinggateways [8], [12], [13]. However, only applying the securitymeasures at gateways may not control D2D malware spread.Similarly, techniques relying on network traffic analysis mayresult in a lower probability of detecting compromised devices[14]. To solve these issues, this paper uses remote attestationto detect compromised IoT devices, and a Physical Unclon-able Function (PUF) based security framework to isolate andcontrol malware propagation in IoT systems. Thus, the majorcontributions of this paper are as follows:

i. Remote attestation for identifying compromised devices.ii. A PUF based patching protocol to control malware spread.

iii. A security analysis using Access Control Logic model.iv. A performance analysis with a patching scheme using sus-

ceptible, exposed, infected, and resistant (SEIR) model.

The rest of the paper is organized as follows. SectionII discusses the related work while Section III defines thepreliminaries. Section IV describes the network and attackmodels. Section V explains the proposed framework. SectionsVI and VII present the security analysis and performanceevaluation. Finally, Section VIII concludes the paper.

2

II. LITERATURE REVIEW

Some of the existing work on using PUFs as a securityprimitive include authentication [15]–[18], attestation [14],[19], [20], data integrity [21], and data provenance [22], [23].

The authors in [8] discuss a traffic-aware patching schemefor mobile IoT networks that can control the malware spread todirect D2D connections. Although an interesting proposition,it relies on intermediate nodes and has a high time cost forpatching devices. In [24] a machine learning based modelfor the identification of malware attacks in IoT networks ispresented. Although the authors claim that their framework isscalable with respect to the size of the network, it is not safeagainst physical attacks on devices and it inherently relies onthe function virtualization technique that contributes to a hightime cost. Guizani et al. [25] discuss a formulation by studyingthe structure of social network for its effects on the propagationdynamics of epidemic diseases with applications to ad-hocnetworks. They discuss a susceptible-infection-recover (SEIR)based epidemic spread model for different levels of popula-tion aggregation. Subsequently, they analyze and apply thedynamics of this model to mobile ad-hoc networks (MANETs)to better understand the dynamics associated with malwarepropagation in these networks. Furthermore, another interest-ing patching mechanism to provide an analytical frameworkfor evaluating the automatic patching in systems is presentedin [26]. However, this technique requires frequent updatemessages which may not be feasible.

Thus, we can see that most of the existing patching frame-works suffer from two limitations: (i) long time periods, i.e.,high time cost for patching a device; (ii) restricted contain-ment of malware propagation, i.e., no definition of isolationlevels to distinguish between compromised devices and non-compromised ones. Therefore, motivated by this challenge, wepropose a secure patching framework for IoT environmentsthat has low time cost and is able to effectively contain mal-ware propagation by defining three network isolation levels.

III. PRELIMINARY BACKGROUND

A. Physical Unclonable Functions

A PUF is a noisy function that is embedded into a physicalcircuit due to the inherent random variations introduced bythe chip manufacturing process [27]. When queried with achallenge x, a PUF produces a response y ← PUF (x)that depends on x and the internal (sub-)microscopic devicestructure. Due to variations in environmental factors such astemperature and voltages, the PUF output may vary slightlywhen queried with the same challenge multiple times. How-ever, fuzzy extractors may be used to eliminate these variationsand convert them into deterministic functions [27], [28].

A PUF can be used as a tool for hardware authentication andgenerating secure keys, among others [22], [23]. Robustnessagainst physical and invasive attacks, and the ability to retainkeys without actually storing them, makes PUFs ideal candi-dates for IoT security. A PUF can be of several types, e.g.,delay-based PUFs which leverage the variation among circuitdelays, and memory based PUFs which exploit the random

process variations in the memory cells [29], [30]. Some of thecommercially available PUFs include [31]–[34].

B. Remote Attestation

The process of verifying the integrity of an embeddeddevice’s internal state to detect any unintended and mali-cious modification of the software running on it. Remoteattestation (RA) is the procedure by which a trusted entity(the verifier) remotely initiates attestation while the embeddeddevice (the prover) proves the authenticity of its internalstate. RA techniques commonly work as follows. The verifierfirst sends a challenge to the prover. The prover calculatesa hash digest of its memory contents using the challengeand returns a response called the checksum to the verifier.The verifier uses the checksum to determine if the prover iscompromised or not. Attestation techniques can be categorizedas software based [35]–[37], hardware based [38], [39], andhybrid techniques [19], [40]–[42]. The major difference is inthe form of computational complexity and hardware require-ments, i.e., software based techniques are computationallyexpensive as they exploit the computational capabilities of anembedded device, while hardware based techniques are light-weight but require specialized hardware that is not commonlyavailable. On the other hand, hybrid techniques try to finda balance between computational complexity and hardwarerequirements.

In this paper, we use one of our remote hybrid attestationtechniques proposed for IoT devices called HAtt [14]. Thistechnique is chosen due to its extremely low security overheadand downtime for IoT devices. HAtt divides the memory of anIoT device into blocks and attests each memory block individ-ually. Then, using a random sampling of bits from the memoryto detect any malicious change in an IoT device’s software,HAtt can not only results in higher detection accuracy butalso results in low communication overhead. HAtt is light-weight and can be run on an IoT device without interruptingthe normal operation of IoT devices.

C. SEIR Virus Spread Model

The SEIR model captures the dynamics of virus spread andcategorizes nodes into four states described below [43].

i. Vulnerable (S): this state represents a node or a devicethat has weak security and is vulnerable to attacks.

ii. Infected (I): this state represents nodes or devices that areinfected with malicious software.

iii. Host (E): this state represents nodes or devices that areinfected and have the capability to infect other devicesand further spread the malware.

iv. Updated (R): this state represents nodes or devices thatwere infected and have been patched such that they donot accept any malware attacks.

IV. NETWORK MODEL AND ASSUMPTIONS

A. Network Model

The network model for the proposed patching framework isshown in Figure 1, while the notations used in this paper are

3

Fig. 1: An illustration of the network model.

listed in Table I. In this model, we have the following entities:

1) IoT Devices: Each IoT device is assumed to be anembedded system-on-chip (SoC) having its own PUF. Thesecurity module running on these nodes is called the EdgeModule (EM).

2) Server: This acts as the trusted server and the noderesponsible for registration, management, control, andpatching of IoT devices and the security module runningon these nodes is called the Backend Module (BM).

3) Infrastructure based links: IoT devices may have linksto infrastructure-based communication technologies, suchas GSM/GPRS/UMTS/LTE through cellular base stationsand WiFi through wireless local area network (WLAN)access points (AP). Due to a lack of full TCP/IP stack,the IoT devices are connected through 6LoWPAN based(or similar) router elements termed as the gateway nodes.The Gateway Module (GM) runs on these nodes.

4) Device-to-device (D2D) links: IoT devices may useproximity-based wireless interfaces such as WiFi Direct,Bluetooth Low Energy (BLE), and near field communi-cation (NFC) to communicate with each other.

B. Assumptions

i. An adversay is not able to tamper with an IoT device’sPUF. Moreover, any such attempt will make the PUFuseless [44], [45].

ii. As the micro-controller and the PUF are on the samechip forming an SoC, the communication between themis assumed to be secure [44], [45].

iii. IoT devices are assumed to have limited energy, memory,and processing capabilities while the servers and gatewaysdo not have such constraints.

V. PROPOSED SECURITY FRAMEWORK

This section describes the proposed security framework forIoT systems. In this section we discuss the details of theproposed framework and the roles of the three modules, i.e.,edge module, gateway module and backend module.

TABLE I: A summary of notations

Notation Description

PUF Physical Unclonable FunctionCRP Challenge Response PairMAC Message Authentication CodeACL Access Control List

< T, Ix > Device included in trusted list T with interfaces IxIDi ID of the IoT deviceH(X) Hash of X‖ Concatenation operator

{M}k Message M is encrypted using key kCi Challenge for the i−th iterationRi Response of the respective PUF for Ci

∧ AND operator

A. Network Isolation Levels

The proposed framework uses the following three levels fornetwork isolation of IoT devices:

1) Trusted: IoT devices which do not have any malware andare not compromised are added to the trusted network.Devices in this category are free to communicate usingall available communication interfaces.

2) Strict: IoT devices which are new to the user network ormay be compromised are added to the strict network. Thetraffic generated by these devices is filtered to avoid anymalicious packets or connection requests to the externalnetwork or other IoT devices.

3) Isolated: The IoT devices which have been compromisedby malware are added to the isolated network. Note thatIoT devices may have multiple communication interfacessuch as Bluetooth, LTE, WiFi etc. The IoT devices in thisnetwork are restricted to use only one basic communica-tion interface such as WiFi. Moreover, apart from basicdata packets, all connection requests and packets fromthese devices are blocked/dropped.

B. Device Registration

Before an IoT device can become part of the user IoTnetwork, it has to register itself with a gateway module. Duringregistration, the gateway module needs to obtain an initial CRP(Ci, Ri) for the device. We assume that this is done usinga secure protocol such as a time-based one-time passwordalgorithm (TOTP) [46] and an operator with a password. Foreach IoT device in its area, the gateway stores one CRP whilethe IoT device only stores a challenge Ci. Note that storing thechallenge in an IoT device does not compromise the securityof the proposed framework as an adversary cannot obtain Ri

using Ci because of the SoC assumption.

C. Edge Module

The flow of the operation of the edge module after regis-tration is shown in Figure 2. The edge module performs thefollowing two major operations:

1) Attestation: Figure 2 shows that if the edge modulereceives an attestation request, it invokes the HAtt routine forattesting the IoT device’s software. Once HAtt has completedcalculating the attestation response, the edge module sends itto the gateway module.

4

Fig. 2: Flowchart for the Edge module

2) Configuration: Configuration is performed in three in-stances: (i) if an IoT device is new to the network; (ii) ifthe time span for which a specific configuration was validexpires; or (iii) if an IoT device fails attestation. If any of thesethree events occurs, the edge module initiates the configurationprotocol (detailed in Section V-F). At the conclusion of thisprotocol, the IoT device may be asked to perform one of thefollowing operations:

i) Patching: If the IoT device fails attestation but thebackend module finds a patch for its firmware, the edgemodule invokes the secure patching protocol (detailed inSection V-G).

ii) Virtual Patching: If the IoT device fails attestation andthe backend module is unable to find a patch for thedevice (similar to the case of legacy devices), the backendmodule may have to rely on virtual patching. Thus,the backend module may instruct the edge module toblock the compromised IoT device’s communications toneutralize the effect of malware and also contain it frompropagating to other devices.

iii) Update Configuration: New IoT devices joining theuser network are initially placed in the strict network.Similarly, devices that fail attestation may also be placedin the strict or isolated network by the backend module.However, if an IoT device passes attestation after initialconfiguration or after installing a patch, the edge moduleneeds to update the IoT device’s security configuration byadding it to the trusted network.

3) Communication: When an IoT device wants to com-municate with another IoT device, the edge module mustdetermine the isolation level and accordingly the permissionsgranted to that IoT device. Thus, the edge module needsto communicate with the gateway module to obtain thisinformation. The proposed protocol for this purpose is shownin Figure 3. The following steps are carried out:

i) IoT device IDA sends a request to the gateway forcommunicating with IoT device IDB by sending Message1 in Figure 3.

IoT DeviceIDBGateway

IoT DeviceIDA

1

2_12_2

Fig. 3: Edge module protocol for isolation level information.

ii) The gateway verifies the message authentication code(MAC). If verification succeeds, it checks the isolationlevel of IoT devices IDA and IDB and sends a list ofinterfaces Int to both devices describing the permissionsthat the devices have. For example, if the devices are inthe trusted list then Int will contain all the availableinterfaces. However, if IoT device IDA is in the Isolatednetwork then Int may be empty, i.e., IoT device IDA

is not allowed to talk to any other IoT device.iii) Depending on the isolation level of the devices, the IoT

devices IDA and IDB receive a list of interfaces theyare allowed to communicate on along with a MAC inMessages 2 1 and 2 2.

D. Gateway Module

The gateway module operations are shown in Figure 4. Thetwo major operations of the gateway module are as follows:

1) Attestation: If the gateway module receives an attesta-tion request from the backend module it will carry out thefollowing steps:

i) The gateway module sends an attestation request to allthe IoT devices in its area.

ii) If the attestation is successful, the gateway module in-forms the backend module. Otherwise, the gateway mod-ule will inform the backend module of the compromiseddevice(s) and at the same time, update the security con-figuration parameters of the device(s) by adding it/themto the strict network.

iii) The backend module will inform the gateway modulewhether a patch is available or not. If a patch is available,the gateway module instructs the edge module to applythe patch to the compromised device(s). Otherwise, virtualpatching is applied by adding the device(s) to the isolatednetwork.

2) Configuration: If the gateway module receives a con-figuration request from an IoT device, it sends an attestationrequest to the IoT device along with the initial seed. If theattestation is not successful, the gateway module will followsteps 3 to 4 from Section V-D1. Otherwise, the gatewaymodule informs the backend module of the successful at-testation and receives new configuration parameters for thecorresponding IoT device. The gateway module finally applies

5

Fig. 4: Flowchart for the Gateway module.

the new configuration parameters by adding the IoT device tothe trusted or strict network as dictated by the backend module.

E. Backend Module

The flow chart for the backend module is shown in Figure 5.The two major operations performed by the backend moduleare as follows:

1) Configuration: When a new IoT device enters the usernetwork or when the time span of a current configurationexpires for an IoT device, the corresponding IoT device needsto perform configuration [47]. When the backend modulereceives a new configuration request, it sends an attestationrequest to the gateway of the IoT device requesting config-uration. If the attestation is successful, the IoT device canbe added into the trusted network. Otherwise, the backendmodule checks to see if there is a patch available for thecorresponding IoT device. If a patch is available, the IoTdevice is patched. Otherwise, virtual patching is employed byisolating the device’s communications.

2) Attestation: The backend module performs attestation ofall the IoT devices in the user network from time to time. Ifthe backend module desires to perform attestation of the IoTdevices in the area of some gateway, it can do so by sending anattestation request to the corresponding gateway module. Thegateway module will return back to the backend module with

Fig. 5: Flowchart for the Backend module.

success or failure. The backend module does nothing in caseof successful attestation. However, if the attestation fails, thecompromised IoT device may actually be patched or virtuallypatched depending on the availability of the patch.

F. Configuration Protocol

The protocol for when a device requests new configurationfrom the Backend Module is shown in Figure 6. The steps ofthe protocol are as follows:

1) The IoT device IDA initiates a configuration request bysending its ID and a random nonce N1 to the gatewaymodule.

2) The gateway module forwards the configuration requestto the backend module by adding its ID and a randomnonce N2 in message 2 of Figure 6 using kj as the secretkey for encryption. Note that we assume that the backendmodule and gateway module have a preshared symmetrickey kj .

3) The backend module verifies the integrity of the messageusing the corresponding MAC and then reads the storedCRP for IoT device IDA in its memory i.e., (Ci, Ri).The backend module then calculates z1 = aG for au-thentication purposes using ECC and generates an accesstoken T i. The access token specifies the configurationparameter to be used by the IoT device IDA. T i has thefollowing fields:

i) A key ki to be used as the symmetric key betweenthe gateway module and the edge module.

ii) An authorization field which identifies the networkisolation for the IoT device IDA. We propose threetypes of network isolations: i) devices that havepassed attestation can be added to the trusted net-work by allowing the device to communicate through

6

IoT Device IDA

GatewayIDG

1

ServerIDS

2

3

4

5

6

7

8

Fig. 6: The configuration protocol for an IoT device.

its communication ports and also upload data, ii)devices whose attestation status is not known orwhich have been added to the network recentlyor which have failed attestation but have a patchavailable are added to the strict network, i.e., thedevice may communicate through some ports but thegateway module will filter all the device’s packets,and finally iii) devices which have failed attestation

and do not have any available patch are added to theisolated network, i.e., all the device’s communica-tion requests and packets other than some basic datapackets are dropped by the gateway. Moreover, theedge module may block all the D2D links for thecompromised device stopping any possible malwarepropagation.

iii) A Time span field, indicating the time frame forwhich this configuration is applicable. Note thatwhen a new device is added to the user network thebackend module may add that device to the strictnetwork for a brief amount of time, sufficient forthe device to be attested by the gateway module.

iv) Other fields may be added in the future to enable/dis-able specific ports or filter specific packet types fromthe device.

The backend module then creates the message MSA forthe IoT device IDA by encrypting it using IoT deviceIDA’s CRP. The backend module then sends a messageMSG along with the corresponding MAC to the gatewaymodule as shown in message 3 of Figure 6.

4) The gateway module uses the symmetric key kj todecrypt MSG and obtain MSA, and the access token T i.The gateway module then uses T i to obtain the symmetrickey ki and applies the corresponding security policy byadding the IoT device IDA to the trusted, strict or isolatednetwork. The gateway module then generates the initialseed x0 and random nonce N4, stores the current timet′, and sends message MGA using symmetric key kialong with the corresponding MAC to IoT device IDA

as shown in Figure 6.5) The IoT device IDA carries out the following operations:

i) Uses Ci and its PUF to the generate the responseRi.

ii) Decrypts MSA using Ri to obtain the ECC parameterz1, and the access token T i.

iii) Applies configuration parameters in T i and obtainsthe symmetric key ki from T i.

iv) Decrypts MGA using ki and obtains the initial seedfor attestation, i.e., x0.

v) Calculates the attestation response σ.vi) Generates random numbers b and N5 and calculates

the ECC authentication parameters z2 and r.vii) Uses Ri and ki to create messages MAS and MAG

as shown in Figure 6.The IoT device IDA then sends MAG with the corre-sponding MAC in message 5 to the gateway module.

6) The gateway module checks the attestation response σand the time required by the device to calculate σ.The attestation response should be received within anexpected time interval δ. If attestation is successful, thegateway module sets a Boolean variable S, otherwise Sis reset to 0. The gateway module then creates a messageMGS using kj to send MAS and S to the backend moduleas shown in message 6 of Figure 6.

7) After receiving message 5, the backend module carriesout the following operations:

7

ServerIDS

IoT DeviceIDA

2

1

Fig. 7: The proposed secure patching protocol.

i) Verifies the MAC.ii) Calculates ERi = r − az2 using ECC and reverses

the embedding to obtain Ri. It then verifies the resultwith the Ri in its memory. The backend modulerejects the configuration request if the verificationfails.

iii) Updates the access token T i based on the Booleanvariable S, i.e., whether the device was successfullyattested or not. For example, if the device was suc-cessfully attested, then the access token will specifyto add this device to the trusted network. Otherwiseit may specify to add it to the strict or isolatednetworks.

The backend module finally sends the updated accesstoken to the gateway module in message 7 of Figure 6.

8) The gateway module verfies the MAC in message 7 and ifthe verification succeeds, it updates the IoT device IDA’sconfiguration parameters in its memory. The gatewaymodule then forwards the access token to the IoT deviceIDA.

9) In the final step, the IoT device IDA verifies the MAC inmessage 8 and obtains the access token T i by decryptingmessage 8 using ki. The edge module then updates itssecurity parameters using the configuration parameters inT i.

G. Secure Patching Protocol

When a new firmware or patch is available for an IoTdevice, the secure patching protocol in Figure 7 is used. Thesteps for the proposed secure patching protocol are as follows:

1) The edge module at IoT device IDA initiates the securepatching protocol by sending its ID, the version numberof its current firmware #V ER, and a random nonce N1

to the server.2) The server searches for IDA in its memory and rejects

the patch request if no record is found. Otherwise, thebackend module reads the corresponding CRP (Ci, Ri)

ACL says

d1 controls 〈T, I1〉∧d2 controls 〈T, I2〉∧

...dm controls 〈T, Im〉

∀ d(·) ∈ Trusted,

∧

dm+1 controls 〈S, Im+1〉∧dm+2 controls 〈S, Im+2〉∧

...dm+n controls 〈S, Im+n〉

∀ d(·) ∈ Strict,

∧

dm+n+1 controls 〈M, Im+n+1〉∧dm+n+2 controls 〈M, Im+n+2〉∧

...dN controls 〈M, IN 〉

∀ d(·) ∈ Isolated

(1)

Fig. 8: ACL.

for IoT device IDA’s PUF and checks whether an updatepatch (or firmware) is available for IDA. If a patchis not available then the backend module rejects theupdate request. Otherwise, the backend module generatesa random nonce N2 and creates an encrypted message(using Ri) MFW carrying the patch as shown in Figure7. The backend module then sends the version numberof the patch (or update), and MFW along with thecorresponding MAC to IoT device IDA.

3) The edge module at IoT device IDA generates Ri usingCi and its PUF. It then verifies the integrity of themessage 2 by verifying the MAC. If the verification failsthen the update request is terminated. Otherwise, the edgemodule uses Ri to decrypt MFW and obtain the patchor firmware update. Finally, the edge module applies thepatch to IoT device IDA.

VI. SECURITY ANALYSIS

The main objective of the proposed framework is to avoidthe propagation of malware by isolating compromised IoTdevices. For this purpose, we consider the three isolation levelsas protected resources, i.e., we need to prove that an IoT devicecan only access the interfaces dictated by its network isolationlevel. Thus, using this mapping of network isolation levels toresources, we adopt the ‘access control logic’ defined in [48].In this analysis, the gateway module and backend modules areconsidered as one entity, we refer to them as servers (τ ), withthe following set of assumptions:

i. Completeness: Servers cannot be successfully bypassed.ii. Isolation: Servers cannot be corrupted and are tamper

proof.iii. Verifiable: Servers are correctly implemented and they

operate as expected.We now define the network isolation of the proposed frame-work in terms of an access control list (ACL).

Definition 1. Network Isolation Levels: We deconstruct thenetwork isolation provided by the servers, to an ACL as shownin Figure 8. where d denotes an IoT device; T , S, and Mrepresent the trusted, strict, and isolated network isolationlevels, respectively; and I denotes the available interfaces foran IoT device. For example, the entry d1 controls 〈T, I1〉means that IoT device d1 is in the trusted network and

8

can communicate freely using all interfaces available in I1.Similarly, d1 controls 〈S, I1〉 may be used to restrict IoTdevice d1 to a few interfaces listed in I1. We can now deducethat an ACL securely lists all the devices of the network as wellas their corresponding communication rights, which controlsand sustains the inter-device communications. Thus, for any i,we can extract the following general description for any devicefrom the ACL:

ACL says (di controls 〈αi, Ii〉), ∀ αi ∈ {T, S,M}

Therefore, di needs to identify itself and subsequently, gener-ate its request for Ii to communicate in the network. The servers compares Ii against its allowed permissions αi accordingto the isolation level in the ACL: if there is a match, thendi is allowed to communicate. Moreover, the ACL requiresthe following three components, which we express as logicstatements:

Communication Policy:

τ controls (d controls 〈α, I〉)

This statement defines the basis for device communicationand asserts that τ has the authority to decide what type ofcommunication request a device is allowed to make.

Trust:τ ⇒ ACL⇒ authority

This statement concludes that ACL hosted by τ has theauthority to manage and control device communications.

Communication Request:

d says 〈α, I〉

This statement is used to represent when a communicationrequest is generated by a device d using isolation level αfor interface I . Note that when expressing ACL in logic, thefollowing two formulae are not equal:

(d controls r1) ∧ (d controls r2) 6= d controls (r1 ∧ r2)

Adversary Model: We assume that when an IoT device isinitially connected to a network, it may have security vulnera-bilities. However, the device is considered to be harmless, i.e.uncompromised by the attacker. The objective of the adversaryis to cause maximum physical and economic damage [49], [50]by exploiting IoT devices as follows:

1) Capture an IoT device and launch a physical attack toextract security credentials, data, or secret keys.

2) Use a compromised IoT device to infect other IoT deviceswith malignant software.

3) Inject malicious packets into the network to propagatefalse or tampered information in the user’s network.

The goal of this paper is to develop a complete framework toidentify and deal with compromised devices in the network.

The adversary model is defined as: a set of devicesD = {d1, d2, d3, · · · , dn} interact with a set of serversΓ = {τ1, τ2, τ3, · · · , τm} over an unsecured and vulnerablenetwork. After the device registration phase, the devices canstart to communicate with each other and the servers bysending communication requests to a server. Additionally,an adversary A is assumed to have the following abilities:

(i) compromise the devices and use them to send arbitraryamounts of data to the servers or other devices; (ii) full controlover the communication channel between servers and thedevices. This may include attacks like tampering, replaying,and injecting packets in the network. Thus, the followingqueries are used to model these attacks:• SendΓ(τ ,m0) is used to model the query where A acts

like a legitimate device and sends a message oracle m0to τ .

• SendD(d,m0) is used to model the query where A actslike a legitimate device and sends a message oracle m0to an IoT device d.

• Monitor models A’s ability to continuously eavesdropon the network traffic.

• Drop(A) is A’s ability to drop packets in the network.• Reveal(A) is used by A to launch a physical attack and

extract the secrets stored in a device.We assume that the adversary A can call SendΓ, SendD,Monitor, and Drop oracles any polynomial number oftimes. However, the A can call Reveal(A) only once as thedevice will not be usable after this query.

Lemma 1. A PUF is a unique and unclonable hardwarefingerprint that restricts an adversary from predicting itsbehavior.

Proof. A PUF can be modeled as: {0, 1}l1 → {0, 1}l2 , i.e.,when excited with an input of length l1, a PUF will producean output of length l2. We now model PUF security usinga security game, ExpSec

PUF,A, between a challenger C andadversary A, where A randomly chooses a challenge Ci tosend it to C. C uses the PUF to obtain the response Ri andtherefore, reveals Ri to A. C now selects a random challengeCx which has not been used before and obtains the responseRx such that: Rx = PUF (Cx). We assume that A can querythe PUF a polynomial number of times for challenges otherthan Cx. Thus, A outputs its guess Rx′

for the challenge Cx

and wins the game if Rx′= Rx. We can now define the

advantage of the A in this game as: AdvPUFA = Pr[Rx′

= Rx].Every PUF is unique and cannot be cloned [51]. Thus, theonly option left with the adversary is to make a random guess,therefore, AdvPUF

A = 12l2

.

Lemma 2. It is not possible for an adversary to extract anIoT device’s secrets even after calling the Reveal oracle.

Proof. The main secret of an IoT device is the response Ri.A may attempt to revel the secret response either by usinga physical attack or by using the stored challenge Ci toproduce Ri. However, both of these options are not feasible.Firstly, IoT devices do not store Ri in their memory, andtherefore, physical attacks will not be fruitful. Secondly, theSoC assumption makes it impossible for A to obtain Ri usingthe PUF. Thus, the adversary cannot reveal any secrets in theproposed framework.

Lemma 3. The probability of evading detection using HAtt isnegligible.

Proof. The authors in [14] show that the probability of evadingdetection in HAtt is negligible. Therefore, the advantage of an

9

adversary in successfully attacking the attestation routine isgiven by AdvAtt

A =(1e

)R=⇒ AdvAtt

A ≈ 0,∀ R ≥ 4 [14],where R is the number of iterations of the HAtt routine.Assuming R ≥ 4, the proposed framework is considered tobe safe against attestation evasion attacks [19].

Theorem 1. It is not possible for an adversary to tamper withdata.

Proof. Each message sent in the proposed patching frameworkis first translated into a hash digest using message authen-tication codes on the secret PUF response of a device andthen communicated to another device or a server. Therefore,to tamper with data in a message, A needs to construct avalid MAC to modify the contents of any message. However,to do so A needs to obtain the PUF response of a device.Therefore, by Lemmas 1 and 2, the advantage of an adversaryin successfully tampering with data in the proposed frameworkis given by AdvTamper

A = AdvPUFA = 1

2l2. Thus, data

embedded in a message cannot be tampered by A in theproposed framework.

Theorem 2. The network isolation levels successfully containthe propagation of malware or malicious requests in theproposed framework.

Proof. Each device in the proposed framework is embeddedwith a PUF that operates in conjunction with the SoC ofthe device. To successfully identify itself as a trusted deviceand interact with the network, an adversary A needs tosuccessfully run the communication protocol in Figure 3. Thiscan be modeled using the following security game between achallenger C and A:

1) C selects two IoT devices in the trusted list: d1 andd2. C then initiates a run of the communication protocolbetween d1 and d2.

2) A calls SendΓ, Monitor, and Drop a polynomialnumber of times on d1 and d2.

3) A uses the SendD oracle to authenticate itself as atrusted device to either d1 or d2.

4) If A can successfully complete the communication pro-tocol, he/she wins the game.

Let us assume A decides to impersonate d1 and sendsa message to d2. To do this, A needs to construct a validMAC in Message 1. However, to do so A requires the secretresponse Ri of d1. A’s advantage at successfully launchingan impersonation attack can be modeled as AdvComm

A =Pr[Ri′ = Ri] − AdvPUF

A . Applying Lemma 1, we getPr[Ri′ = Ri] = 1

2l2= αPUF

A . Thus, AdvCommA = 0.

An adversary may also attempt to attack the ACL andtry to bypass the ACL check. Let us assume that A suc-cessfully compromises a device d1 and tries to send amessage to the server τ . Thus, A generates his/her requestas: 〈T, I〉, 〈S, I〉, 〈M, I〉 = 〈αi, Ii〉, ∀ αi ∈ {T, S,M} toexercise the attack and spread the malware/malicious messagein all devices across the three network isolation levels. Tosuccessfully propagate the malware or malicious messagesin the whole network, A has to bypass τ . By access logicmodel assumptions, servers cannot be bypassed. Therefore,

A’s request is always contained with a server that maintainsthe ACL and has the authority to allow or deny communicationrequests of the devices with respect to the permissions definedon each device in the ACL. For example, let us assume a roguedevice dA tries to communicate with the trusted devices, theattack of A is contained in the following way:

i. dA says 〈T, I〉: communication request generated by A.ii. τ controls (dA controls 〈α, I〉): network isolation lists in

ACL.iii. ACL ⇒ authority: trust policy.

iv. ACL says

· · · ∧· · · ∧· · ·: registered devices list with permis-

sions by Definition 1.v. ACL says {dA controls 〈M, I〉}.

vi. Thus, A’s request is contained within one isolation,thereby limiting the attack’s impact and strictly restrictingthe propagation of the malware in the network.

Theorem 3. The proposed framework successfully protects thesystem from unauthorized and rogue devices.

Proof. An adversary A may try to run the configurationprotocol in order to register itself as a trusted device. Thiscan be modeled as the following security game:

1) C chooses a legitimate IoT device d1 and runs theconfiguration protocol.

2) A calls the SendΓ, SendD, Monitor, and Dropqueries a polynomial number of times on d1 and τ .

3) A calls the SendΓ oracle to initiate the configurationprotocol and register itself as a trusted device.

4) If A can successfully register itself as a trusted device,then A wins the game.

To successfully register as a trusted device, A needs toproduce valid attestation results, i.e., a valid attestation re-sponse. However, according to Lemma 3, the possibility for anadversary to calculate a valid attestation response is negligible,i.e., AdvAtt

A ≈ 0. Moreover, the configuration protocol useselliptic curve cryptography (ECC) for mutual authenticationof the server and the IoT device. In this regard, even if weassume that the attacker can somehow obtain the three ECCparameters, i.e., z1, z2, and r sent in messages 3 and 5 inFigure 6, he/she still needs to obtain a from aG or b frombG or to understand Ri + b(aG). Thus, A needs to solve anelliptic curve discrete logarithm problem (ECDLP).

Definition VI.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 shows that although the IoT device and server requiresimple addition and subtraction operations on the curve, A hasto solve a computationally intractable and extremely difficultfactorization problem [52]. This shows that the proposedframework is secure against unauthorized or rogue devices.ECC was chosen as the security primitive for the proposedprotocol because of the following advantages:

10

(a) Case 1 − proposed. (b) Case 2 − proposed. (c) Case 3 − proposed.

(d) Case 1 − [24]. (e) Case 2 − [24]. (f) Case 3 − [24].

Fig. 9: A comparison of patching turnaround times between the proposed scheme and [24] for three different cases.

1) computational efficiency: performing scalar multiplica-tions requires less computation both in software andhardware, as compared to implementing exponentiation.

2) key size: defining the security level as the time neededto break a system, ECC is well known to require shorterkey lengths for higher levels of security, as compared toother crypto-systems such as RSA or Diffie-Hellman. Asmaller key size translates to lower power, bandwidth,and computation requirements, which are critical in IoT.

TABLE II: Simulation parameters

Parameters Notation Value

No. of devices (cases) nd 1000No. of gateways ng 50No. of devices/gateway ngd 20Simulation time ts 200sTime period for D2D tdd 1sTime period for D2G tgd 2sAttestation time period ta (5, 6, 7)s

VII. PERFORMANCE EVALUATION

To evaluate IoT-Proctor, we conduct a comparative analysiswith a state-of-the-art patching scheme [24]. For this purpose,we conducted simulations using a custom discrete event sim-ulator in Python, which were carried out using the parameterslisted in Table II. For the simulation setup, we translated theparameters of SEIR model to our framework as follows.

A. Quantifying malware propagationWe analyse both the proposed framework and [24] by

simulating a malware attack in an IoT network. To present

a thorough analysis, we discuss results presented through theSEIR disease spread experimentation model [53], [54]. TheSEIR states are mapped to our framework as follows:

i. Trusted: This represents the ‘Updated (R)’ state of theSEIR model as ‘Trusted’.

ii. Strict: This represents the ‘Vulnerable (S)’ state of theSEIR model as ‘Strict’

iii. Isolated: The combines the ‘Infected (I)’ and ‘Host (E)’states of the SEIR model as ‘Isolated’

We can observe that the isolation levels in the proposedframework preserve all the four states of the SEIR model asthey function with the same attributes. Thus, we perform thesimulations based on SEIR formulation and evaluate the resultswith respect to the three isolated levels.

For evaluation, we considered three different scenarioswhere we initially begin with a fixed percentage of maliciousdevices. The simulation time ts for all the cases was 200seconds with an attestation time period (ta) of 5− 7 seconds,i.e., the frequency with which the IoT devices are checkedfor malware is once every 5 to 7 seconds. The results wereobtained using the average of 1000 simulations for eachscenario. Note that for these simulations, we assume 10%of the devices are supported by security patches while restof the 90% of devices (if infected) need to undergo virtualpatching. In the results, if a device is patched virtually, thenit is considered trusted and not infected.

Thus, we formulate three cases for our performance evalua-tion, where in each case we have a fixed percentage of infecteddevices. Note that for a fair comparison, we evaluated both theproposed scheme and [24] using Table II parameters.

a) Case 1: In this case, we considered 1% of devices tobe infected with malware, i.e., 10 devices since we considered

11

TABLE III: A summary of comparison between the proposed scheme and [24] for malware reduction in IoT

SchemeCase 1− 1% malicious devices Case 2− 5% malicious devices Case 3− 10% malicious devices

Patchtime(s)

Devicespatched

(%)

Breakeven(s)

Reductionrate

(d/s)

Patchtime(s)

Devicespatched

(%)

Breakeven(s)

Reductionrate

(d/s)

Patchtime(s)

Devicespatched

(%)

Breakeven(s)

Reductionrate

(d/s)

Proposed 60 95 25 8 50 95 19 9 46 95 16 10Guizani et al. [24] 100 80 55 2 85 80 40 2 76 80 37 2Improvement (%) 40 18.75 54.54 300 41.17 18.75 52.5 350 39.47 18.75 56.75 400

1000 devices in total (cf. Table II). Figure 9(a) demonstratesthat IoT-Proctor is able to effectively reduce the malwaredistribution among 95% of the devices over a short period oftime (60s). Moreover, the proposed scheme reaches the break-even point between ‘strict’ and ‘trusted’ levels in 25s with areduction rate of 400/50 = 8 devices per second (d/s). Notethat the break-even point represents the effective reduction rateof patching, i.e., number of devices patched per unit time.This point is useful in showing that how quickly a patchingscheme patches devices and reduces the number of deviceswhich are not patched. Furthermore, in contrast, [24] takesaround 55s to reach the break-even point with a reductionrate of 150/85 ≈ 2d/s, whereas it approximately takes 100sto patch 80% of the devices, as can be seen in Figure 9(d).

b) Case 2: In this, we considered 5% of devices tobe initially infected with malware, i.e., 50 devices. Figure9(b) demonstrates that IoT-Proctor is effective in reducing themalware distribution among the devices over a short periodof time. It can be seen that IoT-Proctor now patches 95% ofthe devices in 50s. Moreover, it reaches the break-even pointbetween in 19s with a reduction rate of 400/45 ≈ 9d/s. Incontrast, [24] takes 40s to reach the break-even point with areduction rate of 150/95 ≈ 2d/s. It now takes almost 85s topatch 80% of the devices, as can be seen in Figure 9(e).

c) Case 3: In this case, we considered 10% of devicesto be initially infected with malware, i.e., 100 devices. Figure9(c) demonstrates that IoT-Proctor patches 95% of the devicesin 46s. Moreover, it reaches the break-even point between in16s with a reduction rate of 400/41 ≈ 10d/s. In contrast,[24] takes 37s to reach the break-even point with a reductionrate of 150/75 = 2d/s. Whereas, it takes around 76s to patch80% of the devices, as can be seen in Figure 9(f).

From these cases, it can be observed that IoT-Proctor caneffectively control, contain, and mitigate malware spread. Asummary of the comparative analysis is given in Table III. Theresults show that even in the case of 10% of initially infecteddevices, IoT-Proctor restricted the malware from propagatingas well as the number of infected devices, which was reducedto only 5% in just 46 seconds. This attests the superiorperformance of IoT-Proctor over [24], with faster patchingturnaround times and higher rates of patched devices.

VIII. CONCLUSION

Traditional malware propagation control schemes for IoTrely on gateway patching and are usually constrained by hightime cost, low probability of compromised device detection,and network traffic analysis. Although they can successfully

contain malware spread to a certain degree, they can notcontrol the D2D malware propagation. This paper addressedthese issues and presented a device patching framework forIoT with different network isolation levels. The frameworkdetects compromised devices and highlights the origin ofmalicious activities via remote attestation. It also proposeda PUF based virtual patching protocol to contain and limitmalware spread. Moreover, the isolation levels act as an ACLto define the ambit of device operation and control D2Dmalware from propagating. A security analysis along witha performance evaluation were presented to demonstrate thefeasibility of our framework. A comparative study with a state-of-the-art patching scheme showed that the reduction rate forcompromised devices using IoT-Proctor was five times fasterthan the existing techniques.

IoT-Proctor considers access control lists to control malwarespread. However, it would be interesting to consider networkfunction virtualization (NFV) to isolate devices. Moreover,the attestation technique used in this paper considers indi-vidual device attestation which may result in low scalability.Therefore, as part of future work, a swarm-based attestationtechnique may be included into the framework of IoT-Proctor.

REFERENCES

[1] P. Newman, “The Internet Of Things 2020: Here’s what over400 IoT decision-makers say about the future of enterprise con-nectivity and how IoT companies can use it to grow revenue,”[Online] Available: https://www.businessinsider.com/internet-of-things-report, Accessed: Mar 2021.

[2] A. Spadafora, “IoT Devices Still Major Target for Cyberattacks.”[Online] Available: https://www.techradar.com/sg/news/iot-devices-still-major-target-for-cyberattacks, Accessed: Apr 2010.

[3] M. N. Aman, et. al. “Physical Unclonable Functions for IoT Security.”In Proc. ACM IoTPTS, New York, NY, USA, 10-13, 2016.

[4] S. A. Chaudhry, M. S. Farash, N. Kumar and M. H. Alsharif, “PFLUA-DIoT: A Pairing Free Lightweight and Unlinkable User Access ControlScheme for Distributed IoT Environments,” in IEEE Systems Journal,2020.

[5] U. Javaid, M. N. Aman, and B. Sikdar, “Defining trust in IoT envi-ronments via distributed remote attestation using blockchain”. In Proc.ACM Mobihoc ’20, New York, NY, USA, 2020, pp. 321–326.

[6] L. Ilascu, “When their firmware is vulnerable, its up toyou to protect your smart devices,” [Online] Available:https://www.bitdefender.com/box/blog/iot-news/bitdefender-box-data-firmware-vulnerable-protect-smart-devices/, Accessed: 5 May 2019.

[7] Heightened DDoS Threat Posed by Mirai and Other Botnets, AlertTA16-288A, US Department of Homeland Security CISA Cyber + In-frastructure. Available online: https://www.us-cert.gov/ncas/alerts/TA16-288A. Accessed: 05 Apr. 2020.

[8] S. Cheng et al., “Traffic-Aware Patching for Cyber Security in MobileIoT,” in IEEE Commun. Magazine, vol. 55, no. 7, pp. 29-35, July 2017.

[9] U. Javaid, M. N. Aman and B. Sikdar, “A Scalable Protocol for DrivingTrust Management in Internet of Vehicles With Blockchain,” in IEEEInternet of Things Journal, vol. 7, no. 12, pp. 11815-11829, Dec. 2020.

12

[10] Y. Minn et al., “IoTPOT: Analysing the Rise of IoT Compromises,” inProc. USENIC Wksp. 2015, Aug. 2015.

[11] B. McEvoy, “34C3: Fitbit Siniffing and Firmware Hacking,” HACKA-DAY, 2017.

[12] M. Miettinen et al., “IoT Sentinel Demo: Automated Device-TypeIdentification for Security Enforcement in IoT,” in Proc. IEEE ICDCS,Atlanta, GA, 2017, pp. 2511-2514.

[13] N. Hadar et al., “A Lightweight Vulnerability Mitigation Framework forIoT Devices,” in ACM IoT S&P, 2017, New York, USA, pp. 71–75.

[14] M. N. Aman et al., “HAtt: Hybrid Remote Attestation for the Internetof Things with High Availability,” in IEEE Internet of Things Journal.

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

[16] M. N. Aman, M. H. Basheer and B. Sikdar, “Two-Factor Authenticationfor IoT With Location Information,” in IEEE Internet of Things Journal,vol. 6, no. 2, pp. 3335-3351, April 2019.

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

[18] M. N. Aman, U. Javaid and B. Sikdar, “A Privacy-Preserving andScalable Authentication Protocol for the Internet of Vehicles,” in IEEEInternet of Things Journal, vol. 8, no. 2, pp. 1123-1139, 15 Jan.15.

[19] M. N. Aman, B. Sikdar, “ATT-Auth: A Hybrid Protocol for Industrial IoTAttestation With Authentication,” in IEEE Internet of Things Journal,vol. 5, no. 6, pp. 5119-5131, Dec. 2018.

[20] J. Kong, F. Koushanfar, P. K. Pendyala, A. Sadeghi and C. Wachsmann,“PUFatt: Embedded platform attestation based on novel processor-based PUFs,” in Proc. 2014 51st ACM/EDAC/IEEE Design AutomationConference (DAC), San Francisco, CA, USA, 2014, pp. 1-6.

[21] M. N. Aman, B. Sikdar, K. C. Chua and A. Ali, “Low Power DataIntegrity in IoT Systems,” in IEEE Internet of Things Journal, vol. 5,no. 4, pp. 3102-3113, Aug. 2018.

[22] M. N. Aman, M. H. Basheer and B. Sikdar, “Data Provenance for IoTWith Light Weight Authentication and Privacy Preservation,” in IEEEInternet of Things Journal, vol. 6, no. 6, pp. 10441-10457, Dec. 2019.

[23] M. N. Aman, M. H. Basheer and B. Sikdar, “A Lightweight Protocolfor Secure Data Provenance in the Internet of Things Using WirelessFingerprints,” in IEEE Systems Journal.

[24] N. Guizani and A. Ghafoor, “A Network Function Virtualization Systemfor Detecting Malware in Large IoT Based Networks,” in IEEE J. Sel.Areas Commun., vol. 38, no. 6, pp. 1218-1228, June 2020.

[25] N. Guizani et al., “Effects of Social Network Structure on EpidemicDisease Spread Dynamics with Application to Ad Hoc Networks,” inIEEE Network, vol. 33, no. 3, pp. 139-145, May/June 2019.

[26] M. Vojnovic and A. J. Ganesh, “On the race of worms, alerts, andpatches,” IEEE/ACM Trans. Netw., vol. 16, no. 5, pp. 1066–1079, Oct2008.

[27] P. Tuyls and L. Batina, “RFID-Tags for Anti-Counterfeiting,” In Proc.CT-RSA), vol. 3860 of LNCS, pp. 115-131, Springer Verlag, 2005.

[28] Y. Dodis et al., “ Fuzzy extractors: How to generate strong kesyfrom biometrics and other noisy data.” In Advances in Cryptology -EUROCRYPT ’2004, LNCS. Springer-Verlag, Berlin Germany, 2004.

[29] M. N. Aman, K. C. Chua and B. Sikdar, “Physically secure mutualauthentication for IoT,” in Proc. IEEE Conference on Dependable andSecure Computing, Taipei, Taiwan, 2017, pp. 310-317.

[30] A. Irshad et al., “Fuzzy-in-the-Loop-Driven Low-Cost and Secure Bio-metric User Access to Server,” in IEEE Transactions on Reliability, 2020.

[31] Verayo Inc., http://www.verayo.com/tech.php, 2013.[32] Intrinsic-ID, “SRAM PUF: The secure silicon fingerprint,” White Paper,

2016.[33] ICTK, Co. Ltd., http://www.ictk.com/servicenproduct/puf, 2014.[34] Invia PUF IP. http://invia.fr/infrastructure/physical-unclonable-function-

PUF.aspx, 2016.[35] A. Seshadri et al., “SWATT: Software-based attestation for embedded

devices.” In Proc. IEEE Symp. on Security and Privacy, 2004.[36] A. Seshadri et. al., “SCUBA: Secure Code Update By Attestation in

sensor networks,” In Proc. WiSe’06, pp. 85-94.[37] A. Seshadri, M. Luk, and A. Perrig, “SAKE: Software Attestation for

Key Establishment in Sensor Networks,” In Proc. International Conf.on Distributed Computing in Sensor Systems, pp. 372-385, 2008.

[38] A. Visintin et al., “SAFEd: Self-attestation for networksof heterogeneous embedded devices,” preprint, available:https://arxiv.org/abs/1909.08168.

[39] W. Yan et al., “EAPA: Efficient Attestation Resilient to Physical Attacksfor IoT Devices,” in Proc. ACM IoT S&P, 2019, New York, USA, 2–7.

[40] K. Eldefrawy, “SMART: Secure and minimal architecture for (establish-ing dynamic) root of trust,” in NDSS, 2012.

[41] P. Koeberl, “TrustLite: A security architecture for tiny embedded de-vices,” in ACM European Conf. on Computer Systems (EuroSys), 2014.

[42] F. Brasser, “TyTAN: tiny trust anchor for tiny devices,” in ACM/IEEE(DAC), 2016.

[43] B. K. Mishra and D. K. Saini, “SEIRS epidemic model with delayfor transmission of malicious objects in computer network”, AppliedMathematics and Computation, vol. 188, no. 2, pp. 1476 - 1482, 2007.

[44] S. Guilley, and R. Pacalet, “SoCs security: a war against side-channels”,Annals of Telecommunications, 59(7), pp. 998-1009, 2004.

[45] M. Kirkpatrick et. al., “System on Chip and Method for Cryptographyusing a Physically Unclonable Function,” U.S. Patent 8750502 B2,issued March 22, 2012.

[46] “TOTP: Time-Based One-Time Password Algorithm”, IETF RFC 6238.[47] S. Venkatasamy, et. al., “Design of Robust Mutual Authentication and

Key Establishment Security Protocol for Cloud-Enabled Smart GridCommunication.” in IEEE Systems Journal, 2020.

[48] S. K. Chin and S. B. Older, “Access control, security, and trust: A logicalapproach”, CRC Press, 2010.

[49] A. Ghani et al., “Security and key management in IoT-based wirelesssensor networks: An authentication protocol using symmetric key” inInt J Commun Syst., 32:e4139, 2019.

[50] K. Mansoor et al., “A. Securing IoT-Based RFID Systems: A RobustAuthentication Protocol Using Symmetric Cryptography”, in Sensors,vol(19), no 21, pp. 4752, 2019.

[51] M. Hofer and C. Bohm, “Physical Unclonable Functions in Theory andPractice”, Springer-Verlag New York, 2013.

[52] Z. Liu, H. Seo, J. Großschadl and H. Kim, “Efficient Implementationof NIST-Compliant Elliptic Curve Cryptography for 8-bit AVR-BasedSensor Nodes,” in IEEE Transactions on Information Forensics andSecurity, vol. 11, no. 7, pp. 1385-1397, Jul 2016.

[53] W. K. Chai, “Modelling Spreading Process Induced by Agent Mobilityin Complex Networks,” in IEEE Transactions on Network Science andEngineering, vol. 5, no. 4, pp. 336-349, 1 Oct.-Dec. 2018.

[54] L. Zhang and J. Xu, “Differential Security Game in HeterogeneousDevice-to-Device Offloading Network Under Epidemic Risks,” in IEEETransactions on Network Science and Engineering, vol. 7, no. 3, pp.1852-1861, 1 July-Sept. 2020.

Muhammad Naveed Aman received the B.Sc. de-gree in Computer Systems Engineering from KPKUET, Peshawar, Pakistan, M.Sc. degree in ComputerEngineering from the Center for Advanced Studiesin Engineering, Islamabad, Pakistan, M.Engg. de-gree in Industrial and Management Engineering andPh.D. in Electrical Engineering from the RensselaerPolytechnic Institute, Troy, NY, USA in 2006, 2008,and 2012 respectively. He is currently working asa Senior Research Fellow with the Department ofComputer Science at the National University of

Singapore, Singapore. His research interests include IoT and network security.

Uzair Javaid received the B.Sc. degree in Electri-cal Engineering from FAST-National University ofComputer and Emerging Sciences, Peshawar, Pak-istan, where he graduated with Magna Cum Laude.He is currently a Ph.D. research scholar with theDepartment of Electrical and Computer Engineeringat the National University of Singapore, Singapore.His research interests include blockchain, appliedcryptography, and network security.

Biplab Sikdar received the B.Tech. degree in elec-tronics and communication engineering from NorthEastern Hill University,Shillong, India, in 1996, theM.Tech. degree in electrical engineering from theIndian Institute of Technology, Kanpur, India, in1998, and the Ph.D. degree in electrical engineeringfrom the Rensselaer Polytechnic Institute, Troy, NY,USA, in 2001. He was on the faculty of RensselaerPolytechnic Institute from 2001 to 2013, first as anAssistant and then as an Associate Professor. He iscurrently an Associate Professor with Department of

Electrical and Computer Engineering, National University of Singapore. Hisresearch interests include wireless networks and IoT security.