research article secure and efficient control transfer for...

Hindawi Publishing CorporationInternational Journal of Distributed Sensor NetworksVolume 2013 Article ID 503404 8 pageshttpdxdoiorg1011552013503404

Research ArticleSecure and Efficient Control Transfer for IoT Devices

Zhi Wang Han Ding Jinsong Han and Jizhong Zhao

School of Electronic and Information Engineering Xirsquoan Jiaotong University Xirsquoan 710049 China

Correspondence should be addressed to Zhi Wang zhiwangmailxjtueducn

Received 3 July 2013 Accepted 2 October 2013

Academic Editor Yunhuai Liu

Copyright copy 2013 Zhi Wang et alThis is an open access article distributed under theCreativeCommonsAttribution License whichpermits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

The prevalence of Internet of Things (IoT) requires flexible and fine-grained controls over the IoT devices Existing works relyon specific controllers or programs to remotely control IoT devices which is inefficient to support intelligent control in IoTenvironments In contrast utilizing a common portal device for example smart phone to control variant IoT devices is a promisingsolution However it is challenging to guarantee the security when transferring the control of IoT devices In this paper we designa lightweight protocol to enable secure control transfer among the IoT devices portal devices and backend serverWe demonstratethe effectiveness of our protocol in defending against mainstream attacks Experimental results show the efficiency of our protocolin the authentication and key-updating during the control transfer

1 Introduction

With the rapid development of electronics existing electronicdevices such as the TV refrigerator electromagnetic ovenand even electric lamp become intelligent such that they canenable adaptive control to meet time-varying needs of usersWith the emergence of the Internet ofThings (IoT)many IoTdevices have been equippedwith IoT technology [1ndash5] whichprovides more intelligent services to users

Remotely controlling these devices is essential for sup-porting the intelligent IoT service Most of existing devicesadopt the former patterns which is cost-inefficient Somerecent solutions are designed to adopt portal devices forexample smart phones or portal tablets to control IoTdevices Those works still depend on the specific programdesigned for targeted devices however they are sufferringfrom inefficiency and poor scalability

To enablemore flexible and fine-grained controls over theIoT devices we are motivated to design a common controlmanagement system which allows users to leverage theirportal devices for example smart phones to control variantdevices in IoT environments Imagine a scenario of smartspace in hotels When passengers check in they can use theirown smart phones or iPad-like devices to control the IoTdevices in the room In this way the service will be moreconvenient to the customer and the cost of maintenance for

the hotel will be significantly reduced Our control systemconsists of IoT devices portal devices and backend serverThe control over IoT devices should be managed by thebackend server For each user his portal device plays therole as a single access entry to control different IoT devicesAfter validating the user the backend server will transfer thecontrol on the targeted devices to the userrsquos portal deviceThe user then employs his portal device to control differenttargeted devices including operating on a TV controlling theair condition or selectively playing CDs on a HiFi

However using a portal device to safely control IoTdeviceis nontrivial in IoT applications In particular it is challengingto guarantee that the control can be securely transferredfrom the backend server to a validate userrsquos portal deviceconsidering the insecure IoT environments For examplea host would like to allow his close friends to control hismain door while an intruder should not be allowed to openit Obviously effective authentication or verification is ofimportance to transfer controls among IoT devices portaldevices and backend server Nevertheless IoT devices areusually source limitedThus it is difficult and cost-inefficientto directly adopt complex asymmetric key-based algorithmsfor authentication It is also challenging to securely controlIoT devices with low overhead

In this paper we propose a secure and efficient controltransfer protocol to allow users to control IoT devices using

2 International Journal of Distributed Sensor Networks

their portal devices for example smart phones We use alightweight cryptographic hash function as the cryptobuild-ing block to support authentication in source-limited IoTdevices Each IoT device will share a transfer key 119870

119879with

the backend server The IoT device also has a control key119870119862 When a user wants to control an IoT device he sends a

request to the IoT device via his smart phoneThe IoT devicereplies with a cipher encrypted with 119870

119862 The smart phone

relays this response to the backend serverThe backend serverlocates the 119870

119862in the database and hence identifies the IoT

device Then the backend server can verify the validation ofthe user If the user is valid the backend server grants thecontrol over the requested device and an updated 1198701015840

119862to the

userrsquos phone The control is indeed a chipper encrypted withthe key 119870

119879and 1198701015840

119862 The user relays the control over the IoT

device The IoT device checks the validation of the controland gets1198701015840

119862by using119870

119879 Finally the userrsquos phone obtains the

control1198701015840119862 from the backend serverThemain contributions

of our protocols are as follows

(i) We propose a common control transfer scheme inwhich the control over IoT devices does not dependon specific controllers The user can leverage his por-tal device as a common controller to control differentIoT devices To our knowledge our work is amongthe first steps towards secure control transfer over IoTdevices

(ii) We perform a lightweight hash function as the cryp-tographic component which significantly improvesthe authentication efficiency with sufficient securityguarantee

(iii) We conduct comprehensive analysis on the security ofproposed protocol and demonstrate its effectivenessin defending against existing attacksWe also performsimulations to evaluate the performance of our proto-cols The results show that our protocols can achievesecure control transfer with low overhead and latency

The rest of the paper is organized as follows In Section 2we discuss related works We outline the requirements ofsecure control transfer in Section 3 In Section 4 we presentour protocol design We analyze the privacy and security ofprotocol in Section 5 Section 6 reports the simulation resultand Section 7 concludes the paper

2 Related Work

In this section we discuss the related work in authenticationand ownership transfer in IoT environments

Authentication In RFID systems the identity of tag (TID)is easily traced and cloned Many solutions such as [6ndash10] have been proposed to employ traditional cryptographicmethods to enhance the IoT systems However these pro-tocols are not often compatible with commercial industrialstandards for example EPC C1G2 specifications [2] Due tothe extremely limited resource RFID tags require lightweightsolutions such as hash functions [3] or PRNGs [11] in the

authentication Chabanne and Fumaroli [12] propose a noise-based protocol in which they adopt a Bit Pair Iterationscheme to correct transmission errors and prevent passiveeavesdropping Juelsrsquo protocol [13] generates a PINSet toprovide reader-to-tag authentication After hiding the correctaccess password (the correct PIN value) in a set containing119896 values the probability of a correct guess is 1119896 and thesecurity level approaches 119874(119896)

M2AP [14] is an ultralightweight mutual authenticationprotocol for low-cost RFID tags by only using simple oper-ations such as XOR OR AND and SUM of modulo Laterresearchers present some attacks to M2AP [15] SASI [16]is another ultralightweight protocol using the same basicoperations as M2AP but it suffers from the desynchroniza-tion attack Without changing the protocol flow of existingair interface protocol the authors in [1] propose a newauthentication protocol-Gen2+ which is a multiple roundprotocol using shared pseudonyms and cyclic redundancycheck (CRC) It achieves the reader-to-tag authenticationand provides sufficient security level for real-world settingsSimilarly the works proposed in [2 17] also aim to be fullycompatible with EPC C1G2 specifications

Ownership transfer has two fundamental requirementsFirst the former owner should not obtain the secret of newowner after the transfer Second the new owner should notdeduce past transactions as well as the secret related to formerownerThere are also a few solutions to address the ownershiptransfer problem Some of them rely on hash functions orsymmetric encryption functions [15 18ndash25] The authors in[26] propose a two-party ownership transfer protocol whichis based on the security of the backwards channelThe authorsin [27] design a mutual authentication protocol for secureownership transferTheir work is based onminimal hardwarePhysical Unclonable Functions

The work proposed in [28] presents a detail survey onthe security requirements such as indistinguishability for-ward security resistance against replay attack resistanceagainst tag killing and ownership transferability In order tosecurely deliver the services to the user devices the authorsin [29] propose a technique ldquosecure three way authentication(STWA)rdquo intending to protect the user privacy and accom-plish ownership authentication

3 Control Transfer Protocol Requirements

In this section we first present our systemmodel and assum-ptions We then introduce the requirements of privacy secu-rity and performance relevant to control transfer protocoldesign

31 System Model and Assumption The control transfer pro-tocol considered in this paper operates with the followingmodel and assumptions

(i) The communicating parties include a server a portaldevice for instance a phone and an IoT device Theserver also plays the role as a trust center (TC) Theportal device acts as a common controller denoted asP We denote the IoT device as IoD

International Journal of Distributed Sensor Networks 3

(ii) P and IoD communicate via an unsecure wirelesschannel In this paper the wireless protocol is Zigbee

(iii) TC and P communicate via a WiFi connection pro-tected by WPAWPA2

(iv) TC maintains a database containing the secure infor-mation for IoD and P

(v) IoD is source limited and hence can only affordlightweight cryptographic operations for examplehash functions We assume that such a device usuallyhas a rewritable memory that is tamper resistant

32 Privacy Requirements There are twomajor threats to theuser privacy in remote control systems [2 3 18 19 27]

Control Leakage In a typical remotely controlling systemwhen TC queries a device D D responds with its profileIf unauthorized entities obtain its profile they may be ableto obtain the control on P from the TCrsquos database Theessential requirement of the control privacy is that onlyauthorized entities are able to access the information andcontrol associated with IoDs

Device Tracking If the responses of an IoD are distinguishablefrom those of other devices the device can be trackedEven worse the social interactions of the individual usercarrying the IoD may be disclosed while the user is unawareof the risk of being traced Remotely controlling systemsshould be able to resist the device tracking attack by makingthe messages from devices indistinguishable from others Indetail the track resistance should meet two guarantees (a)New controller privacy once the control on an IoD has beentransferred to a newP only the newP can identify and controlthe device The previous controller of the device shouldno longer identify or control the device (b) Old controllerprivacy when the control on an IoD has been transferred toa new P the new P should not trace past interactions betweenthe IoD and its previous controller P

33 Security Requirements Communications between a con-troller and a device via an insecure wireless channel are sus-ceptible to attacks We outline the major attacks threateningremotely controlling systems Due to the cost constraint IoTdevices usually cannot afford complex cryptographic algo-rithms to provide privacy and security Therefore remotelycontrolling schemes should meet the following requirements[2 12ndash14 18 19]

Resistance to Device Impersonation The attacker can imper-sonate a targeted IoD to a P without knowing the devicersquosinternal secrets If the attacker succeeds it will be authenti-cated as the targeted device In our work an adversary shouldnot be able to impersonate an IoD by compromising attacks

Resistance to Controller Impersonation The attacker can im-personate a legitimate P to a compromised IoD In this casethe attacker may need the knowledge of the devicersquos internalstate If the attacker succeeds the attacker may ask the IoDto update its internal state As a result any legal P will no

longer be able to successfully communicate with IoDs [17]We should resist such an impersonation even if the adversarycompromises the IoDs

Resistance to Replay AttackThe attacker can replay messagespreviously exchanged between a legitimate P and IoD Ifthe attack succeeds the attacker may conduct a successfulauthentication between a device and a controller We shouldprevent the adversary from building a session with a legit-imate P and IoD by replaying their previously exchangedmessages

Resistance toMan-in-the-Middle (MITM)AttackTheattackercan interfere with messages exchanged between a legitimateP and IoD (eg by insertion modification or deletion) Thepurpose of MITM is to impersonate the legitimate P or IoDto cheat another communicating party Our solution shouldprevent themanipulation of themessages exchanged betweena legitimate P and IoD to perform MITM

Resistance to Desynchronization Attack The attacker canblock messages transmitted between a legitimate P and IoDthey would no longer be able to authenticate each otherThusblocking themessages transmitted between a legitimate P andIoD should not lead to a desynchronization

Backward Traceability An adversary should not be able totrace the prior transactions between a legitimate P and IoDeven if it compromises the devices [6 20 21 27]

Forward Traceability An adversary should not be able to de-duce future transactions between a legitimate P and IoD evenif it compromises the devices

34 Performance Requirements

(i) Small Storage the volume of data stored in an IoDshould be minimized

(ii) LowComputationComplexity the complexity of com-putations especially those for cryptooperations sho-uld be minimized

(iii) Efficient Communication the number and size ofmessages exchanged between a legitimate P and IoDshould be minimized

4 Control Transfer Protocol

In this Section we present our protocol control transfer(CT) The basic idea of CT is that a P can obtain the controlon an IoD from TC CT is realized by authentication andkey-updating among three major parties TC P and IoD CTis comprised of three phases initialization control transferand control confirmation In the initialization phase TC willissue two keys to IoDs One is the control key 119870

119860 another

is the transfer key 119870119879 Note that TC knows every IoDrsquos keys

But P only knows 119870119860of an IoD if P obtains the control of

this device In the control transfer phase P and IoD performmutual authentication with the help of TC At the meantime


P will be granted the control on IoD from TC for exampleobtaining a new control key from TC if it is verified by theIoD and TC In this phase IoD will update its transfer keyIn the control confirmation phase P will confirm that itscontrol key is the same as the one on the IoD side and IoD hassuccessfully updated its transfer key Then P will inform TCto update the transfer key in the database for synchronization

Note that the communication between TC and P isvia a secure WiFi connection for example protected byWPAWPA2 While the communication channel between Pand IoDs is not secure we employ Zigbee as the communica-tion protocol between P and IoDs in this paper

41 Initialization First we define the system parameters asfollows

(i) 119897 is the bit length of a key(ii) 119897119903is the bit length of a random string

(iii) The concatenation operator is represented by (iv) 119870

119862is the control key which is initially generated by

TC and embedded in an IoD during the issuance ofthe IoD Once the control on the IoD is transferred toa new P119870

119862will be updatedWe denote1198701015840

119862as the new

control key updated from119870119862

(v) 119870119879is the transfer key shared by TC and IoD 119870

119879

should never be disclosed to any third party includingP 119870119879will be updated on the side of IoD and syn-

chronized with TC along with the control transferand confirmation phases 119870

119879is also issued by TC

For each IoD there is an entry in the database ofTC containing a tuple (119870

119862 119870119879) After the control

confirmation phase TC will update 119870119879with 1198701015840

119879to

ensure the consistency with IoD

(vi) ℎ is a lightweight hash function ℎ 0 1lowast rarr 0 1119897We assume that TC and IoD have the same hashfunction ℎ ℎ is collision resistant and suitable forimplementation in IoT devices

42 Control Transfer The phase of control transfer is com-prised of two steps authentication and key-updating Figure 1shows the entire authentication process

421 Authentication

(a) When a userwants to use his portal device P to controlan IoD P first generates a 119897

119903-bits random number 119903

1

and sends 1199031to the IoDThen the IoD computes119873

1=

ℎ(119870119862 1199031) and sends119873

1back to P

(b) 119875 concatenates 1198731with 119903

1and sends 119903

1 1198731to

TC TC searches in its database to find 119870119862 For each

control key 119870119862stored in the database TC computes

1198721= ℎ(119870

119862 1199031) and compares it with 119873

1 If there

exists a 119870119862such that119872

1= 1198731 119870119862is found and the

tuple of (119870119862 119870119879) can be identified immediately

(c) TC generates a 119897119903-bits random number 119903

2 It computes

1198722= ℎ(119870

119862 1199031 1199032) and 1198701015840

119862= ℎ(119870

119862 1199032 119870119879) TC then

Trust center (TC) Phone (P) IoT device (IoD)

Generate r1

Generate r3

r1

N1

N3

r1 N1

Query DB for KCKT

Calculate M1 = h(KC r1)

Calculate N1 = h(KC r1)

If M1 = N1

Verify the IoD successGenerate r2

Calculate M2 = h(KC r1 r2)

Calculate K998400C = h(KC r2 KT)

r1 r2 M2

r1 r2 M2 K998400C

Calculate N2 = h(KC r1 r2)

If M2 = N2

Verify the P successCalculate K998400

C = h(KC r2 KT)

Update KC with K998400C

Calculate K998400T = h(KT r1 r2)

Update KT with K998400T

Calculate N3 = h(K998400C r1 r2)

Timer

If time out1

0Comm r3 r3 h(K

998400C Comm)

If M3 = N3Update transfer key

success

WiFi Zigbee

Update control key K998400C

Calculate M3 = h(K998400C r1 r2)

SuccessCalculate K998400

T = h(KT r1 r2)



Save K998400C

KC KT KCKT

Figure 1 Control transfer protocol

sends 1199031 1199032 1198722 1198701015840

119862as well as a message of

SUCCESS to P This message is to inform P that theIoD is valid

422 Key Update P forwards the 1199031 1199032 1198722to the IoD

The IoD calculates 1198732= ℎ(119870

119862 1199031 1199032) using its own control

key 119870119862 and compares 119873

2with 119872

2 If there is a match P

is successfully verified by the IoD Otherwise the protocolterminates If P is valid IoD then updates 119870

119862by calculating

1198701015840

119862= ℎ(119870

119862 1199032 119870119879) and 119870

119879by computing 1198701015840

119879= ℎ(119870

119879 1199031 1199032)

The IoD sends a message1198733= ℎ(119870

1015840

119862 1199031 1199032) to P

43 Control Confirmation When P receives1198733 it computes

1198723= ℎ(119870

1015840

119862 1199031 1199032) using the 1198701015840

119862received from TC P

compares 1198733with 119872

3 If they match each other P is aware

of the fact that IoD has successfully updated its119870119862and119870

119879

One challenge is that the control confirmation might beinterrupted if attackers block the delivery of119873

3 resulting in a

potential flaw that the119870119879of IoD will be desynchronized with

the one in the database of TC To address the problem weintroduce a probe mechanism to P The probe mechanism isindeed an iterative process When P sends out the messageof 1199031 1199032 1198722in the control transfer phase it will set

a timer 119879 The length of the timer denoted as |119879| dependson the duration of key-updating step on the IoD side plusthe delivery of 119873

3 If the timer is triggered P will send a

request 119877 = comm 119903119894 ℎ(119870

1015840

119862 119903119894 comm) to IoD where

the comm is a command to ask for resending 1198733 When


sending the request P sets the timer again When the timeris triggered later P sends 119903

1 1199032 1198722to IoD and sets the

timer as |119879| This process will be repeated for 119888 times 119888 isa system parameter based on real applications Note that Palternatively sends 119877 and 119903

1 1199032 1198722 The purpose of this

treatment is to guarantee that the protocol can be correctlyexecuted nomatter whether IoD updates its119870

119879or not In our

experiments we set the value of 119888 as 4 If P cannot receiveany expected 119873

3from IoD within 119888 times 119879 P terminates the

protocol and alert TC that IoD is out of control Along withthe correct execution of the previously mentioned controltransfer protocol P and IoD achieve mutual authentication

5 Privacy and Security Analysis

In this section we analyze the privacy and security of ourprotocol based on the requirement raised in Section 3

51 Privacy

Control Privacy In our protocol the control indeed is repre-sented as the control key and transfer key shared among TCP and IoD All these keys are not delivered in plaintext Weemploy cryptographic hash function to generate ciphers forsecure transmission As a result only TC knows the secretkeys of P and IoD and only legal P and IoDs can successfullyconduct the control transfer protocolTherefore our protocolis resilient to control leakage

Tracking Resistance As we analyzed in control privacy themessages delivered in our protocol are encrypted usingcryptographic hash function The usage of random numbersfurther enhances the security Due to the properties of hashfunction the hash value of inputs will be evenly mappedto the output space Thus it is negligible to distinguish twodevices from each other based on their messages that is thehash values computed from the involved keys and randomnumbers In particular P will never know the transfer keyshared between TC and IoDs As a result a P cannot revealthe new transfer keys of IoDs only based on its control keyafter a control transfer On the other hand the P will onlyget its control key from TC but have no idea of the controlkey used by the previous P In short our protocol can achieveprivacy for both the old and new P

52 Security

Resistance to Device Impersonation For a legitimate P a mali-cious IoD can launch the impersonation attack by manipu-lating 119873

1 However it cannot succeed because of the lack of

control key 119870119862 Thus the device impersonation is infeasible

Resistance to Controller Impersonation A P can only controla legitimate IoD after it obtains the control key from TCSince the communication between TC and P is protectedby WPAWPA2 which supports TC to verify P a malicious

party thereby cannot impersonate a legitimate P without thepermission from TC

Resistance to Replay Attack Our protocol encrypts the mes-sages using the time-varying random number as inputsAs a result an adversary cannot relay messages previouslyexchanged between a legitimate P and IoD to successfullybuild a session between them

Resistance to MITM Attack Again due to the usage of hashfunctions on the components contained in the message anadversary should not be able to manipulate messages ex-changed between a legitimate P and IoD to perform cheating

Resistance to DoS Attack In our protocol blocking mostlikely happens in the control confirmation phase sincethe attacker can block the transmission of 119873

3to yield a

desynchronization We address this problem twofold Firstwe introduce an interactive probe mechanism for IoD toresend 119873

3or 1199031 1199032 1198722 Second we set timers to avoid

infinite loop of running the probe process As a consequenceour protocol can effectively mitigate the impact of blockingattacks

Backward Untraceability For an IoD its new control key 1198701015840119862

is computed by hashing the old control key 119870119862 transfer key

119870119879 and a random number generated by TC Due to the one-

way feature of hash functions it is infeasible to recover old119870119862and 119870

119879based on the new control key Then the attacker

cannot track the transactions of this IoD in previous sessionsThe attacker can intercept the unsecure channel between theP and IoD to get the information used to compute the controlkey However the attacker still has no knowledge of 119870

119879to

compute the legal control key to trace past transactions

Forward Untraceability Because of the use of cryptographichash function and key-updating during each control transferit is difficult for attackers to deduce future transactionmessages of a given IoD The most severe case is that an oldP is malicious Such a P can get 119903

1and 1199032by overhearing the

unsecure channel between the victim IoD and a new P It thencalculates the119872

2with 119870

119862 1199031 and 119903

2 This may lead to a flaw

that the attacker can trace transactions in future sessions Inour protocol the old P has no knowledge of119870

119879 and the new

control key 1198701015840119862is generated by TC using the transfer key 119870

119879

Enhanced by this treatment even if the attacker intercepts themessage exchanged between the legal P and IoD it has nochance to reveal the new control key let alone computing thefuture transactions The privacy and security features of ourprotocol are summarized in Table 1

6 Performance Evaluation

61 Experiment Setup and Metrics Zigbee is a mainstreamshort-distance wireless communication technology withattractive features such as near distance low complexity lowpower consumption low data rate low cost and flexiblecommunicating mode Those features make Zigbee suitablefor the intelligent control IoT devices especially for those


Table 1 Privacy and security properties

Properties

Privacy Control privacy YTracking resistance Y

Security

Device impersonation YController impersonation Y

Relay attack YMITM attack YDoS attack Y

Backward untraceability YForward untraceability Y

nonintelligent devices such as lights air conditioners andrefrigerators On the other hand we can also adopt othercommunication protocols or schemes such as NFC orBluetooth in our solution In this way a concern aboutthe usability or scalability may be raised considering theimplementation of variant IoT device

We set up a testbed to examine the performance ofour control transfer protocol The testbed simulates thereal IoT environment We employ a notebook to simulateTC The portal device is by a combination of a cellphone(HTC Diamond) and a TelosB Node TC and portal devicecommunicate through IEEE 80211bg in a WPA mode Wesimulate IoDs using 10 TelosB nodes The purpose of usingTelosB nodes is twofold First the TelosB node is suitablefor reflecting the limited resource of IoT devices SecondTelosB nodes communicate with each other via Zigbeewhich is a mainstream communication protocol in remotelycontrolling systems The detail information of experimentsetup is summarized in Table 2We choose BKDR as the hashfunction and program it over the TelosB node We conduct1000 round tests over 10 simulated IoDs say 100 times perIoD In each test we perform a complete control transferprocedure

Performance Metrics We evaluate the performance of ourprotocol via three critical metrics storage computationoverhead and communication latency The storage reflectshow many bits one needed for storing 119870

119862and 119870

119879on

the IoT device side Considering the source constrain thisparameter should be minimized We also have a concern onthe computation efficiency of our protocol especially for theIoD to conduct cryptographic hash functions In addition thecommunication latency of our protocol includes the messageexchanged between IoD and P and between P and TC

Performing authentication is important to ensure thesecurity among control transfer processesThe authenticationin our protocol is mainly based on the cryptographic hashfunctions On the other hand the efficiency of authenticationis also important because most IoT devices work with weakcapacity of computation and storage Considering these inorder to analyze the efficiency of our protocol we makea comparison with the schemes proposed in [30 31] Thefront protocol works in WSN and provides a two-factor

Has

h tim

e (m

s)

TC Phone IoD

10minus1

10minus2

10minus3

1

MinAvgMax

Figure 2 Hash time

user authentication before the legitimate users access datain the sensorgateway nodes The latter one is a bidirec-tional efficiency-privacy transferable (BEST) authenticationprotocol which can balance the privacy and communicationefficiency dynamically

62 Experiment Result In our control transfer protocol thestorage mainly consists of the space for storing the keys onthe sides of IoDs and TC The length of hash value is 128bits if using BKDR hash function which determines the keysize of our protocol Since each IoD will have two keys 119870

119862

and 119870119879 the total storage is 256 bits in each IoD During

the authentication and key updating each IoD also needs totemporally store two random numbers which are also in thesame size as keys Thus the total storage will be 512 bits foreach IoDOn the TC side TC takes only119874(119873) for the storagewhere119873 is the number of IoDs in the system

A complete control transfer involves 10 hash computa-tions among TC P and IoD In particular the IoD under-takes 5 hash computations It is necessary to investigate theoverhead of hash computation of each party which indicatesthe computation complexity of our protocol In Figure 2 weplot the average time for conducting one hash function in TCP and IoD respectively From the result we can find that theIoD has lowest computation speed 078 in averageThis valueis acceptable because the system can still afford more than100000 control transfers per second in this case Consideringthe rapid configuration update on the hardware on the portaland IoT devices the computation overhead of our protocolwill be trivial in future

We also check the communication latency when per-forming our protocol The communication latency is mainlycaused by the message exchange We examine the timeconsumed to send 119873

1 1199031 1199032 1198722 and 119873

3 because those

messages are delivered between P and IoD which may pot-entially become the system bottleneck Figure 3 shows theaverage time used for transmitting above messages via theZigbee channel The result shows that the communicationlatency is sufficiently small to enable an efficient controltransferComputation Cost From Table 3 it is easy to find that in ourprotocol IoD requires 2 hash operations for authentication


Table 2 Experiment setup

Role Device type Device modelTrust center Notebook Thinkpad T400Portal device Smart phone HTC Diamond 2 QualcommMSM7200A 528MHzIoT device TelosB Node Telosb RevBCommunication equipment Wireless router and Zigbee component TP-Link WR740N 300M

Table 3 Computation cost of the protocols

Scheme AuthenticationUserphone Gatewaytrust center Sensor nodeIoD

Das [30] 4H 4H 1HQi et al [31] mdash 1H 2HProposed mdash 2H 2H

MinAvgMax

N1 N3r1 r2 N3

140

120

100

80

60

40

20

0

Tran

smiss

ion

time (

ms)

Figure 3 Transmission time

which is the same as Qirsquos work whereas the sensor nodeneeds only 1 hash operation in M L Dasrsquo protocol But fromFigure 2 in our protocol 2 hash operations are completedin 2ms which is acceptable for IoT devices and meets therequirements of controlling the device in our applicationsIn addition M L Dasrsquo protocol does not provide mutualauthentication between the sensor and gateway node alsoQirsquos protocol suffers from the DoS attack while our protocolachieves higher security

Communication Cost Due to the cost constraint and limitedsource of IoT devices we need an efficient communicationbetween IoD and the controller We compare the com-munication time and the size of exchanged messages inan authentication process Three messages are exchangedfor a successful authentication in M L Dasrsquo Qirsquos and ourprotocols However we observe that the total data size ofthree exchanges is different In M L Dasrsquo protocol about532 bits are required In Qirsquos protocol a successful single tagauthentication needs about 266 bits However the existenceof inevitable conflicts enlarges the required size of message to

be transferredThe demand size of message in our protocol is512 bits In summary without a reduction in the performanceour protocol achieves better security enhancement

7 Conclusions

In this paper we propose a control transfer protocol toenable common portal devices to control large-volume IoTdevices The protocol leverages lightweight hash functions toachieve secure and efficient control transfer among resource-limited IoT devices We analyze the privacy and securityguarantee of our protocol We also conduct simulations overreal IoT devices to evaluate the performance The resultsdemonstrate the effectiveness of our protocol Our futurework includes releasing the constraint of using secure channeland conducting our protocol in large scale IoT applications

Acknowledgments

This work is partially supported by the National NaturalScience Foundation of China (NSFC) under Grants nos61033015 and 61170220 the Fundamental Research Fundsfor the Central Universities of China under Project no2012jdgz02 (Xirsquoan Jiaotong University) and the ResearchCooperation Special Funds of Guangdong under Project no2011B090400563

References

[1] H Sun and W Ting ldquoA Gen2-based RFID authentication pro-tocol for security and privacyrdquo IEEE Transactions on MobileComputing vol 8 no 8 pp 1052ndash1062 2009

[2] M Burmester and JMunilla ldquoLightweight RFID authenticationwith forward and backward securityrdquo ACM Transactions onInformation and System Security vol 14 no 1 p 11 2011

[3] T Dimitriou ldquoA secure and efficient RFID protocol that couldmake big brother (partially) obsoleterdquo in Proceedings of the 4thAnnual IEEE International Conference on Pervasive Computingand Communications (PerCom rsquo06) pp 269ndash274 March 2006

[4] D Zanetti B Danev and S Capkun ldquoPhysical-layer identifica-tion of UHF RFID tagsrdquo in Proceedings of the 16th Annual Con-


ference on Mobile Computing and Networking (MobiCom rsquo10)pp 353ndash364 September 2010

[5] N Saxena M B Uddin J Voris and N Asokan ldquoVibrate-to-unlock mobile phone assisted user authentication to multiplepersonal RFID tagsrdquo inProceedings of the 9th IEEE InternationalConference on Pervasive Computing and Communications (Per-Com rsquo11) pp 181ndash188 March 2011

[6] C C Tan B Sheng and Q Li ldquoServerless search and authen-tication protocols for RFIDrdquo in Proceedings of the 5th AnnualIEEE International Conference on Pervasive Computing andCommunications (PerCom rsquo07) pp 3ndash12 March 2007

[7] M Conti R Di Pietro L V Mancini and A Spognardi ldquoRIPP-FS an RFID identification privacy preserving protocol withforward secrecyrdquo in Proceedings of the 5th Annual IEEE Interna-tional Conference on Pervasive Computing and CommunicationsWorkshops (PerCom rsquo07) pp 229ndash234 March 2007

[8] S A Weis S E Sarma R L Rivest and DW Engels ldquoSecurityand privacy aspects of low-cost radio frequency identificationsystemsrdquo in Security in Pervasive Computing vol 2802 ofLectureNotes in Computer Science pp 201ndash212 2003

[9] G Tsudik ldquoA family of dunces Trivial RFID identification andauthentication protocolsrdquo in Proceeding of the 7th InternationalSymposium on Privacy Enhancing Technologies (PET rsquo07) 2007

[10] M Burmester T Van Le and B De Medeiros ldquoProvably secureubiquitous systems universally composable RFID authentica-tion protocolsrdquo in Proceedings of the 2nd International Con-ference on Security and Privacy in Communication Networks(SecureComm rsquo06) September 2006

[11] E Y Choi D H Lee and J I Lim ldquoAnti-cloning protocol suit-able to EPCglobal Class-1 Generation-2 RFID systemsrdquo Com-puter Standards and Interfaces vol 31 no 6 pp 1124ndash1130 2009

[12] H Chabanne and G Fumaroli ldquoNoisy cryptographic protocolsfor low-cost RFID tagsrdquo IEEE Transactions on InformationThe-ory vol 52 no 8 pp 3562ndash3566 2006

[13] A Juels ldquoStrengthening EPC tags against cloningrdquo in Proceed-ings of the 4th ACM Workshop on Wireless Security (WiSe rsquo05)pp 67ndash75 September 2005

[14] P Peris-Lopez J C Hernandez-Castro J M Estevez-Tapiadorand A Ribagorda ldquoM2AP a minimalist mutual-authenticationprotocol for low-cost RFID tagsrdquo in Proceedings of the 3rd Inter-national Conference on Ubiquitous Intelligence and Computing(UIC rsquo06) 2006

[15] M Barasz B Boros P Ligeti et al ldquoPassive attack against theM2AP mutual authentication protocol for RFID tagsrdquo in Pro-ceedings of the 1st International Workshop on RFID Technology(EURASIP rsquo07) September 2007

[16] H Chien ldquoSASI a new ultralightweight RFID authenticationprotocol providing strong authentication and strong integrityrdquoIEEE Transactions on Dependable and Secure Computing vol 4no 4 pp 337ndash340 2007

[17] A Juels and S A Weis ldquoDefining strong privacy for RFIDrdquoACM Transactions on Information and System Security vol 13no 1 p 7 2009

[18] S Fouladgar andH Afifi ldquoA simple delegation scheme for RFIDsystems (SiDeS)rdquo in Proceedings of the IEEE InternationalConference on RFID 2007

[19] B Song ldquoRFID tag ownership transferrdquo in Proceedings of theRadio Frequency Identification System Security (RFIDsec rsquo08)2008

[20] Y Seo T Asano H Lee and K Kim ldquoA lightweight protocolenabling ownership transfer and granular data access of RFID

tagsrdquo in Proceedings of the Symposium on Cryptography andInformation Security (SCIS rsquo07) 2007

[21] KH S S Koralalage SMReza JMiura YGoto and J ChengldquoPOPmethod an approach to enhance the security and privacyof RFID systems used in product lifecycle with an anonymousownership transferring mechanismrdquo in Proceedings of the ACMSymposium on Applied Computing pp 270ndash275 March 2007

[22] K Osaka T Takagi K Yamazaki and O Takahashi ldquoAn effi-cient and secure RFID security method with ownership trans-ferrdquo in Computational Intelligence and Security vol 4456 ofLecture Notes in Computer Science pp 778ndash787 2007

[23] T Li W Luo Z Mo and S Chen ldquoPrivacy-preserving RFIDauthentication based on cryptographical encodingrdquo in Pro-ceedings of the 31st Annual IEEE International Conference onComputer Communications (IEEE INFOCOM rsquo12) 2012

[24] M Li C Fung K Sampigethaya et al ldquoPublic key basedauthentication for secure integration of sensor data and RFIDrdquoin Proceedings of the 9th ACM International Symposium onMobile Ad Hoc Networking and Computing (MobiHoc rsquo08) pp61ndash65 May 2008

[25] M E Hoque F Rahman and S I Ahamed ldquoAnonPri anefficient anonymous private authentication protocolrdquo in Pro-ceedings of the 9th IEEE International Conference on PervasiveComputing and Communications (PerCom rsquo11) pp 102ndash110March 2011

[26] J Saito K Imamoto and K Sakurai ldquoReassignment scheme ofan RFID tag key for owner transferrdquo in Embedded and Ubiqui-tous Computing-EUC2005Workshops vol 3823 ofLectureNotesin Computer Science pp 1303ndash1312 2005

[27] L Kulseng Z Yu Y Wei and Y Guan ldquoLightweight mutualauthentication and ownership transfer for RFID systemsrdquo inProceedings of IEEE INFOCOM 2010 March 2010

[28] K Osaka T Takagi K Yamazaki and O Takahashi ldquoAn effic-ient and secure RFID securitymethodwith ownership transferrdquoin Proceedings of the International Conference on ComputationalIntelligence and Security (ICCIAS rsquo06) pp 1090ndash1095 October2006

[29] B H Pradeep and S Singh ldquoPrivacy preserving and ownershipauthentication in ubiquitous computing devices using securethree way authenticationrdquo httparxivorgabs12060978

[30] M L Das ldquoTwo-factor user authentication in wireless sensornetworksrdquo IEEE Transactions on Wireless Communications vol8 no 3 pp 1086ndash1090 2009

[31] S Qi L Lu Z Li and M Li ldquoBEST a bidirectional efficiency-privacy transferable authentication protocol for RFID-enabledsupply chainrdquo in Proceedings of the IEEE 18th InternationalConference on Parallel and Distributed Systems (ICPADS rsquo12)December 2012

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014


Active and Passive Electronic Components

Control Scienceand Engineering

Journal of



RotatingMachinery


Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances inOptoElectronics


Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of


Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation



DistributedSensor Networks



their portal devices for example smart phones We use alightweight cryptographic hash function as the cryptobuild-ing block to support authentication in source-limited IoTdevices Each IoT device will share a transfer key 119870

119879with

the backend server The IoT device also has a control key119870119862 When a user wants to control an IoT device he sends a

request to the IoT device via his smart phoneThe IoT devicereplies with a cipher encrypted with 119870

119862 The smart phone

relays this response to the backend serverThe backend serverlocates the 119870

119862in the database and hence identifies the IoT

device Then the backend server can verify the validation ofthe user If the user is valid the backend server grants thecontrol over the requested device and an updated 1198701015840

119862to the

userrsquos phone The control is indeed a chipper encrypted withthe key 119870

119879and 1198701015840

119862 The user relays the control over the IoT

device The IoT device checks the validation of the controland gets1198701015840

119862by using119870

119879 Finally the userrsquos phone obtains the

control1198701015840119862 from the backend serverThemain contributions

of our protocols are as follows

(i) We propose a common control transfer scheme inwhich the control over IoT devices does not dependon specific controllers The user can leverage his por-tal device as a common controller to control differentIoT devices To our knowledge our work is amongthe first steps towards secure control transfer over IoTdevices

(ii) We perform a lightweight hash function as the cryp-tographic component which significantly improvesthe authentication efficiency with sufficient securityguarantee

(iii) We conduct comprehensive analysis on the security ofproposed protocol and demonstrate its effectivenessin defending against existing attacksWe also performsimulations to evaluate the performance of our proto-cols The results show that our protocols can achievesecure control transfer with low overhead and latency

The rest of the paper is organized as follows In Section 2we discuss related works We outline the requirements ofsecure control transfer in Section 3 In Section 4 we presentour protocol design We analyze the privacy and security ofprotocol in Section 5 Section 6 reports the simulation resultand Section 7 concludes the paper

2 Related Work

In this section we discuss the related work in authenticationand ownership transfer in IoT environments

Authentication In RFID systems the identity of tag (TID)is easily traced and cloned Many solutions such as [6ndash10] have been proposed to employ traditional cryptographicmethods to enhance the IoT systems However these pro-tocols are not often compatible with commercial industrialstandards for example EPC C1G2 specifications [2] Due tothe extremely limited resource RFID tags require lightweightsolutions such as hash functions [3] or PRNGs [11] in the

authentication Chabanne and Fumaroli [12] propose a noise-based protocol in which they adopt a Bit Pair Iterationscheme to correct transmission errors and prevent passiveeavesdropping Juelsrsquo protocol [13] generates a PINSet toprovide reader-to-tag authentication After hiding the correctaccess password (the correct PIN value) in a set containing119896 values the probability of a correct guess is 1119896 and thesecurity level approaches 119874(119896)

M2AP [14] is an ultralightweight mutual authenticationprotocol for low-cost RFID tags by only using simple oper-ations such as XOR OR AND and SUM of modulo Laterresearchers present some attacks to M2AP [15] SASI [16]is another ultralightweight protocol using the same basicoperations as M2AP but it suffers from the desynchroniza-tion attack Without changing the protocol flow of existingair interface protocol the authors in [1] propose a newauthentication protocol-Gen2+ which is a multiple roundprotocol using shared pseudonyms and cyclic redundancycheck (CRC) It achieves the reader-to-tag authenticationand provides sufficient security level for real-world settingsSimilarly the works proposed in [2 17] also aim to be fullycompatible with EPC C1G2 specifications

Ownership transfer has two fundamental requirementsFirst the former owner should not obtain the secret of newowner after the transfer Second the new owner should notdeduce past transactions as well as the secret related to formerownerThere are also a few solutions to address the ownershiptransfer problem Some of them rely on hash functions orsymmetric encryption functions [15 18ndash25] The authors in[26] propose a two-party ownership transfer protocol whichis based on the security of the backwards channelThe authorsin [27] design a mutual authentication protocol for secureownership transferTheir work is based onminimal hardwarePhysical Unclonable Functions

The work proposed in [28] presents a detail survey onthe security requirements such as indistinguishability for-ward security resistance against replay attack resistanceagainst tag killing and ownership transferability In order tosecurely deliver the services to the user devices the authorsin [29] propose a technique ldquosecure three way authentication(STWA)rdquo intending to protect the user privacy and accom-plish ownership authentication

3 Control Transfer Protocol Requirements

In this section we first present our systemmodel and assum-ptions We then introduce the requirements of privacy secu-rity and performance relevant to control transfer protocoldesign

31 System Model and Assumption The control transfer pro-tocol considered in this paper operates with the followingmodel and assumptions

(i) The communicating parties include a server a portaldevice for instance a phone and an IoT device Theserver also plays the role as a trust center (TC) Theportal device acts as a common controller denoted asP We denote the IoT device as IoD
























119860 another













119862as the new



119879







119879to




421 Authentication



1


1=

ℎ(119870119862 1199031) and sends119873

1back to P


1and sends 119903

1 1198731to



1198721= ℎ(119870


1 If there


1= 1198731 119870119862is found and the



2 It computes

1198722= ℎ(119870

119862 1199031 1199032) and 1198701015840

119862= ℎ(119870

119862 1199032 119870119879) TC then


Generate r1

Generate r3

r1

N1

N3

r1 N1

Query DB for KCKT



If M1 = N1




r1 r2 M2

r1 r2 M2 K998400C


If M2 = N2


C = h(KC r2 KT)





Timer

If time out1

0Comm r3 r3 h(K

998400C Comm)


success

WiFi Zigbee




T = h(KT r1 r2)



Save K998400C

KC KT KCKT


sends 1199031 1199032 1198722 1198701015840






key 119870119862 and compares 119873

2with 119872




1198701015840

119862= ℎ(119870

119862 1199032 119870119879) and 119870

119879by computing 1198701015840

119879= ℎ(119870

119879 1199031 1199032)


1015840

119862 1199031 1199032) to P


1198723= ℎ(119870

1015840

119862 1199031 1199032) using the 1198701015840





119879


3 resulting in a





request 119877 = comm 119903119894 ℎ(119870

1015840

119862 119903119894 comm) to IoD where








119879or not In our






51 Privacy



52 Security









3to yield a










119879to





2with 119870

119862 1199031 and 119903



119879 and the new


119879






Properties


Security







119862and 119870

119879on



Has

h tim

e (m

s)

TC Phone IoD

10minus1

10minus2

10minus3

1

MinAvgMax

Figure 2 Hash time



119862





1 1199031 1199032 1198722 and 119873

3 because those








MinAvgMax

N1 N3r1 r2 N3

140

120

100

80

60

40

20

0

Tran

smiss

ion

time (

ms)





7 Conclusions


Acknowledgments


References





































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation
































119860 another













119862as the new



119879







119879to




421 Authentication



1


1=

ℎ(119870119862 1199031) and sends119873

1back to P


1and sends 119903

1 1198731to



1198721= ℎ(119870


1 If there


1= 1198731 119870119862is found and the



2 It computes

1198722= ℎ(119870

119862 1199031 1199032) and 1198701015840

119862= ℎ(119870

119862 1199032 119870119879) TC then


Generate r1

Generate r3

r1

N1

N3

r1 N1

Query DB for KCKT



If M1 = N1




r1 r2 M2

r1 r2 M2 K998400C


If M2 = N2


C = h(KC r2 KT)





Timer

If time out1

0Comm r3 r3 h(K

998400C Comm)


success

WiFi Zigbee




T = h(KT r1 r2)



Save K998400C

KC KT KCKT


sends 1199031 1199032 1198722 1198701015840






key 119870119862 and compares 119873

2with 119872




1198701015840

119862= ℎ(119870

119862 1199032 119870119879) and 119870

119879by computing 1198701015840

119879= ℎ(119870

119879 1199031 1199032)


1015840

119862 1199031 1199032) to P


1198723= ℎ(119870

1015840

119862 1199031 1199032) using the 1198701015840





119879


3 resulting in a





request 119877 = comm 119903119894 ℎ(119870

1015840

119862 119903119894 comm) to IoD where








119879or not In our






51 Privacy



52 Security









3to yield a










119879to





2with 119870

119862 1199031 and 119903



119879 and the new


119879






Properties


Security







119862and 119870

119879on



Has

h tim

e (m

s)

TC Phone IoD

10minus1

10minus2

10minus3

1

MinAvgMax

Figure 2 Hash time



119862





1 1199031 1199032 1198722 and 119873

3 because those








MinAvgMax

N1 N3r1 r2 N3

140

120

100

80

60

40

20

0

Tran

smiss

ion

time (

ms)





7 Conclusions


Acknowledgments


References





































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation


















119862as the new



119879







119879to




421 Authentication



1


1=

ℎ(119870119862 1199031) and sends119873

1back to P


1and sends 119903

1 1198731to



1198721= ℎ(119870


1 If there


1= 1198731 119870119862is found and the



2 It computes

1198722= ℎ(119870

119862 1199031 1199032) and 1198701015840

119862= ℎ(119870

119862 1199032 119870119879) TC then


Generate r1

Generate r3

r1

N1

N3

r1 N1

Query DB for KCKT



If M1 = N1




r1 r2 M2

r1 r2 M2 K998400C


If M2 = N2


C = h(KC r2 KT)





Timer

If time out1

0Comm r3 r3 h(K

998400C Comm)


success

WiFi Zigbee




T = h(KT r1 r2)



Save K998400C

KC KT KCKT


sends 1199031 1199032 1198722 1198701015840






key 119870119862 and compares 119873

2with 119872




1198701015840

119862= ℎ(119870

119862 1199032 119870119879) and 119870

119879by computing 1198701015840

119879= ℎ(119870

119879 1199031 1199032)


1015840

119862 1199031 1199032) to P


1198723= ℎ(119870

1015840

119862 1199031 1199032) using the 1198701015840





119879


3 resulting in a





request 119877 = comm 119903119894 ℎ(119870

1015840

119862 119903119894 comm) to IoD where








119879or not In our






51 Privacy



52 Security









3to yield a










119879to





2with 119870

119862 1199031 and 119903



119879 and the new


119879






Properties


Security







119862and 119870

119879on



Has

h tim

e (m

s)

TC Phone IoD

10minus1

10minus2

10minus3

1

MinAvgMax

Figure 2 Hash time



119862





1 1199031 1199032 1198722 and 119873

3 because those








MinAvgMax

N1 N3r1 r2 N3

140

120

100

80

60

40

20

0

Tran

smiss

ion

time (

ms)





7 Conclusions


Acknowledgments


References





































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation















119879or not In our






51 Privacy



52 Security









3to yield a










119879to





2with 119870

119862 1199031 and 119903



119879 and the new


119879






Properties


Security







119862and 119870

119879on



Has

h tim

e (m

s)

TC Phone IoD

10minus1

10minus2

10minus3

1

MinAvgMax

Figure 2 Hash time



119862





1 1199031 1199032 1198722 and 119873

3 because those








MinAvgMax

N1 N3r1 r2 N3

140

120

100

80

60

40

20

0

Tran

smiss

ion

time (

ms)





7 Conclusions


Acknowledgments


References





































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation











Properties


Security







119862and 119870

119879on



Has

h tim

e (m

s)

TC Phone IoD

10minus1

10minus2

10minus3

1

MinAvgMax

Figure 2 Hash time



119862





1 1199031 1199032 1198722 and 119873

3 because those








MinAvgMax

N1 N3r1 r2 N3

140

120

100

80

60

40

20

0

Tran

smiss

ion

time (

ms)





7 Conclusions


Acknowledgments


References





































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation















MinAvgMax

N1 N3r1 r2 N3

140

120

100

80

60

40

20

0

Tran

smiss

ion

time (

ms)





7 Conclusions


Acknowledgments


References





































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation









































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation









research article secure and efficient control transfer for...

Documents