1 Introduction

The notion of Internet of Things (IoT) is evolving very fast since past few years. It can be described as the ‘network of globally connected objects’. These objects or things might be computers, household appliances, vehicles, gadgets or even human beings and animals, etc., which are connected to the Internet making their location and other data available on the Internet. IoT helps objects to communicate easily and access services and get updates when required. This new area is built up on various concepts such as, wireless sensor networks, smart grid, smart homes, intelligent transportation, smart cities, radio frequency identifier (RFID), etc. [1–6]. RFID technology does not require any human assistance for its functioning. It was developed at the Auto-ID center. One of the major technologies behind IoT is the identification of the objects and it can be identified using the RFID tag embedded within the devices. RFID tags are capable of communicating with other objects and database server, identification of objects, etc. The RFID technology has contributed a lot towards the development of smart objects which are capable of communication [7, 8].

IoT being a new area of development, has very weak security mechanisms, and hence is susceptible to all kinds of attacks. Threats to IoT may be sophisticated or by an insider as they can operate from remote areas or from within the organization. Attacks may also target a certain device or network or a person as in social engineering or phishing [9].

Fig. 1
figure 1

a Stages in an attack. b IoT attack mechanism

Full size image

Considering the attack patterns, we present an attack mechanism (shown in Fig. 1) followed by the adversary while planning an IoT attack (or any other attack campaign). There are four steps taken by the attacker while carrying out IoT attack campaign (which can be generalized for any security attack) that are mentioned below:

  • Plan The first step taken by the adversary is planning of the attack, which is not specific to IoT only. Before carrying out an attack, the first step is to gain as much information as possible about the network that is to exploited. They can gain information by listening to messages between the IoT devices and server or between the devices.

  • Deploy After collecting sufficient information, the attacker plans the attack campaign, i.e., deciding the medium of attack, and getting access to the IoT devices to install malicious software and extracting information using a remote system.

  • Monitor/detect After the malware is successfully installed in the devices of an IoT network, the next step is to monitor the communication and other functionalities of the IoT objects and gather the required confidential information or take network down, etc.

  • Ex-filtrate After fulfilling their objectives, the adversary’s next aim is to ex-filtrate out of the network without being detected as to end their campaign successfully.

The term IoT was coined by Kevin Ashton in 1999, who was the director of the MIT’s auto-ID center at that time. In the late 1940s, the first use of Radar technology took place which was the first use of RFID technique and in 1948 the RFID technology was created by Harry Stockman at Auto-ID center. In the year 1959, the IFF long-range RFID system was functioning commercially. The first RFID transponder system was created in 1973 and in 1979 RFID chip were placed in objects. After the origination of IoT in 1999, MIT’s Auto-ID center had started working on RFID technology to develop IoT solutions. In the year 2006, first European IoT conference was held. After that, several major developments have been done in the field. Figure 2 presents brief overview of RFID and IoT history [9–12].

Fig. 2
figure 2

Brief history of IoT and RFID technology

Full size image

The RFID technology [13, 14] was initially developed to replace the bar code of the retail objects. After development of IoT, it has become one of its cornerstones and separate Internet protocols for smart objects have also been devised. In the coming years, it is expected that a single addressing scheme will be able to successfully identify the IoT objects. However, in the current scenario, RFID is an elegant and low-cost system able to satisfy all the prerequisites of IoT objects. They are also effective in terms of lifetime, as they depend on the reader for power requirements, thus their lifetime is infinity and they do not require any battery back-up which also reduces cost of the technology; moreover, there is no overhead of checking or replacing the batteries. However, issues related to security and privacy also need to be evaluated especially for such low-cost systems, as they have very limited resources they cannot use the traditional security algorithms [15, 16]. Therefore, in this paper, we propose an ultra-lightweight mutual authentication protocol to ensure the security and privacy of IoT devices where the RFID tag authenticates the reader and vice versa before exchanging important data. Our protocol uses only two bitwise operations, i.e., XOR and left rotation.

The rest of the paper is organized as follows: Sect. 2 presents related work. In Sect. 3, our proposed approach is discussed in detail. Sections 4 and 5 discuss the efficiency of our work in terms of security and performance. Finally, Sect. 6 concludes our paper and discusses the future work.

2 Related work

RFID’s applications are widespread these days, it was observed that there were about 3–4 billion things that had RFID tag in 2013. There is no doubt that RFID has become dynamic part of retail commerce all over the world. The Internet of Things is built up of some important components to ensure proper communication between the devices. RFID play an important role here, it makes the device or the object identifiable and therefore allows it communicate and monitor the data in real time, which enable the user to make better decisions and be aware of the current situation [17–19]. Moreover, the use of RFID has accelerated the development of the Internet of Things [20].

The IoT devices have limited resources and require updation and identification of other objects as well as server. Mutual authentication using RFID tag is the most common way to secure the devices from intrusion and ensure data integrity and confidentiality. However, due to the limited computation and storage capabilities, we need some lightweight mechanisms for this purpose [21].

Authentication protocols using RFID tags are classified into four types [22]: first is full-fledged class of protocols which consists of protocols which use classical cryptographic encryption and decryption protocols and have large computational overhead; the second class comprises of simpler protocols which require techniques such as elliptic curve cryptography, random number generator and hash function, etc., for mutual authentication purpose. The third class consists of lightweight mutual authentication protocols which use comparatively simple functions like random number generators, checksums, etc. The fourth class of protocols is the ultra-lightweight protocols which only use bitwise operations such as OR, AND, XOR, rotation or permutation, etc. These have the lowest overhead in terms of storage and computation.

In SASI [12], each tag has an ID and shares a pseudonym (IDS) and key value with the back end database server. The length of each of them is 96-bits. SASI ensures strong authentication and integrity. It uses bitwise XOR \((\oplus )\), bitwise OR \((\vee )\), bitwise AND \((\wedge )\), addition mod 2n(+) and left rotate (Rot(x, y)) operation which left rotates the value of x with y bits. Complex operations such as hash functions are not used by this protocol. However, this protocol is susceptible to disclosure attacks and does not ensure untraceability.

Henrici et al. [23] presented a mutual authentication technique which makes use of one-way hash functions for secure communications and after every successful protocol run the Tag ID is updated by both back end database server and the tag, to ensure tag anonymity and location privacy; however, it failed to provide backward un-traceability.

Molnar et al. [24] presented a protocol based on the hash tree approach so that computation cost is evenly distributed among all the devices (or nodes). They also proposed a new library model in order to ensure stronger security at the back end server. Although the library architecture is very efficient, the protocol does not ensure tag anonymity.

In Weis et al. [25] proposed protocol based on the hash lock approach which a Meta ID for the authentication, the Meta ID is the hash of some random number. On receiving the Meta ID, if the database finds match, then it sends a key value and authentication is successful. Rhee et al. [26] proposed a challenge response scheme that uses random numbers and one-way hash for authentication, the secret is updated after each protocol run, unlike [27] it provides security from spoofing and replay attacks but this protocol does not ensure forward secrecy. Juels et al. [28] proposed a human computer interaction based protocol which used the parity concept and symmetric key authentication, but this approach is susceptible to noise on parity values.

Peris-Lopez et al. [29] proposed LMAP protocol which used simple bitwise operations XOR \((\oplus )\), bitwise OR \((\vee )\), bitwise AND \((\wedge )\), and addition mod 2m (+). This protocol ensures mutual authentication and security from various attacks without the use of complex operations like hashing, etc. This scheme uses an index pseudonym (IDS) which is 96-bit in length. Here the IDS is the index of the row where all the tag-related data are stored. Each tag has key which is divided into four parts of 96-bits each.

M2AP [30] protocol which is very similar to LMAP, is also a lightweight mutual authentication protocol for RFID tags, where the index pseudonym updation procedure is different from LMAP while key updating operations remain the same. Both LMAP and M2AP ensure anonymity and mutual authentication and provide security against various attacks such as replay attacks and man-in-the-middle attacks, etc. However, both of these protocols are susceptible to de-synchronization and full-disclosure attacks.

Another protocol EMAP [31] which is based on challenge–response mechanism is an authentication scheme for passive tags. Most of the complex computations in this protocol are performed by the reader and tags perform lightweight operations such as hash, etc. It only requires one storage unit for the tag in addition to the ID for storing authentication related data. This protocol also ensures confidentiality, integrity and un-traceability.

Peris-Lopez et al. proposed the Gossamer protocol [31], which addresses the weaknesses of SASI [22] such as de-synchronization and disclosure attacks. It uses dual rotations and mixbits operation which is a lightweight function (combination of bitwise right shift and addition operations), although this protocol has low throughput.

The problem of ensuring security and privacy in RFID tags is of primary concern. The channel between the reader and the RFID tag is generally susceptible to various attacks as the traditional cryptographic schemes cannot be applied to these channels due to limited resources and computation power. Thus, in order to ensure security, RFID tags can implement simpler protocols for mutual authentication between the reader and the RFID tag. The protocol should be designed in such a way that it not only provides authentication but also integrity, confidentiality and tag anonymity in addition to defending against various attacks. Therefore, the motivation behind our work is to ensure a secure communication between the reader and tag with minimal cost and computations.

In this paper, we present an ultra-lightweight protocol for mutual authentication between the reader and the RFID tag, which uses only basic operations such as bitwise XOR and left-rotation (Rot(X,Y) where X is rotated by the hamming weight of Y). Our protocol ensures data confidentiality, integrity and tag anonymity and resistance to tracking; it is also secure from various attacks such as man-in-the-middle attacks, replay attacks, disclosure attacks, etc.

3 Proposed solution

In this section, we present our proposed protocol. The protocol involves the following entities: the tag, the reader and the back end database server. Moreover, our protocol uses only bitwise operations, i.e., bitwise XOR and rotation operations which makes it an ultra-lightweight solution for mutual authentication between reader and the RFID tag. The random number generation is performed by the server so it does not affect the performance of our protocol.

3.1 Preliminaries

Bitwise operations: As discussed earlier, our protocol uses two bitwise operations XOR \((\oplus )\) and left rotation operation (Rot (A,B)) [33, 34]. The bitwise XOR operation \((\oplus )\) stands for bitwise addition modulo 2. Rot (A,B) rotates A left by wt(B) (mod 96) bits, where the bit length of A is 96 bits and wt(B) is the hamming weight of B which the number of 1’s in B. The output we get from Rot(A,B) might be A with the probability 1 / 96, the probability distribution of Rot(A,B) is uniform. For example, consider two 8-bit strings:

Let, A = 10111010 and B = 10000110, and Rot (A,B) = left rotation of A by wt(B) (mod 8), where, wt (B) = 3, wt(B) (mod 8) = 3 mod 8 = 5.

Therefore, Rot(A,B) = Rot(A,5) = 01010111.

3.2 Mutual authentication protocol

Our proposed protocol assumes the channel between the reader and back end database server to be secure, but the channel between the reader and the RFID tag is assumed to be susceptible to various attacks. Each tag stores two sets 96-bit tag ID and a pseudonym and a key value, i.e, {IDS, K} are shared by both back end database server and the tag, each of them are 96 bits. The database server and the tag also store the old values \(\{{ IDS}_{old}, K_{old}\}\) from the previous authentication session. Thus, if at the end the values of {IDS, K} are not updated, the tag can be verified on the basis of old tag value [35]. Since the resources and computational capabilities of the IoT devices is limited, we proposed an ultra-lightweight mutual authentication protocol. The steps followed by our protocol are given below:

  1. 1.

    The protocol execution is initialized with a “hello” message sent by the reader to the device’s RFID tag.

  2. 2.

    On receiving the “hello” message from the reader, the device tag sends its pseudonym value \(\{{IDS}_{new}, { IDS}_{old}\}\) to the reader.

  3. 3.

    Upon receiving the IDS values from the device tag, the reader matches it with the values in the back end database server. If the values are not matched then the protocol terminates as the tag is not valid. Two cases arise while matching the values sent by the tag:

    • Case I: both \(\{\textit{IDS}_\textit{new}, \textit{IDS}_\textit{old }\}\) sent by the tag match the corresponding IDS values \(\{\textit{IDS}_\textit{new}, \textit{IDS}_\textit{old }\}\) stored in the database. Here we set:

      $$\begin{aligned}&{ back \, end \, server \, database\text {'}s} (\textit{IDS}_\textit{old}) = { back \, end \, server \, database\text {'}s} (\textit{IDS}_\textit{new}) ; \\&{ back \, end \, server \, database\text {'}s } (K_\textit{old}) = { back \, end \, server \, database\text {'}s } (K_\textit{new}); \end{aligned}$$

    • Case II: tag’s \(({ IDS}_{\mathrm{old}})\) = back end server database’s \(({ IDS}_{\mathrm{new}})\), which means in the last session, the updation process was not successful at the server side. Here we set:

      $$\begin{aligned}&{} { back \, end \, server \, database\text {'}s } (\textit{IDS}_\textit{new}) = { back \, end \, server \, database\text {'}s } (\textit{IDS}_{old})\\&\quad = {\textit{tag}}\text {'}{} { s} (\textit{IDS}_\textit{new});\\&{} { back \, end \, server \, database\text {'}s } (K_\textit{new}) = { back \, end \, server \, database\text {'}s} (K_\textit{old})\\&\quad = {\textit{tag}}\text {'}{} { s} (K_\textit{new}); \end{aligned}$$

    After this check, we use the values of \(\textit{IDS}_\textit{new}\) and \(K_\textit{new}\) and refer to them as IDS and K for simplicity in all the further communications. Thus, the synchronization between the tag and the server remains unbroken even if at the end of authentication step, the value of S is intercepted by the attacker and does not reach the reader.

    While the authentication protocol is on run and the server does not receive the value S, it terminates until the session expires.

    If a match is found in the database, the PRNG now generates two 96-bit random numbers m and n. Then, it calculates P and Q which mask the random numbers using IDS and key values, respectively. Then it calculates R for the purpose of device tag authentication:

    $$\begin{aligned} P= & {} \textit{IDS}\oplus m \oplus n; Q = K \oplus n;\\ R= & {} \textit{Rot}(\textit{Rot}(K \oplus n, \textit{IDS}), K \oplus m); \end{aligned}$$

    The values (P, Q, R) are then sent to the device tag.

  4. 4.

    On receiving the values (P, Q, R), the device tag obtains m by XOR value of P and IDS and n by the XOR value of Q and K. Then, using these values of m and n, it calculates \(R'\).

    $$\begin{aligned} n= & {} Q \oplus K;\\ m= & {} P \oplus n \oplus { IDS};\\ R^{\prime }= & {} \textit{Rot}(\textit{Rot}(K \oplus n, \textit{IDS}), K \oplus m). \end{aligned}$$

    If this \(R^{\prime }=R\), then the device tag next calculates S which is for the reader authentication by the device tag as follows:

    $$\begin{aligned} S = \textit{Rot}(\textit{Rot} (\textit{IDS} \oplus n, K), R^{\prime } \oplus m). \end{aligned}$$

    The value of S is then sent to the reader. If the values of R and \(R^{\prime }\) do not match, then, the protocol is immediately terminated.

  5. 5.

    Upon receiving the value S,  the reader now calculates the value \(S^{\prime }\) as:

    $$\begin{aligned} S^{\prime } = \textit{Rot}(\textit{Rot} (\textit{IDS} \oplus n, K), R \oplus m). \end{aligned}$$

    If \(S^{\prime } = S\), then mutual authentication process is successful.

The old values \(\{\textit{IDS}_\textit{old}, K_\textit{old}\}\) at the tag are changed as:

$$\begin{aligned} \textit{IDS}_\textit{old }= & {} \textit{IDS}_\textit{new}; \hbox { and } \\ K_\textit{old }= & {} K_\textit{new}. \end{aligned}$$

After the completion of this process, reader and device tag both will update their IDS and key value as:

$$\begin{aligned} \textit{IDS}_\textit{new}= & {} \textit{Rot}(\textit{IDS} \oplus n, K \oplus n), \textit{IDS} \oplus m); \\ K_\textit{new}= & {} \textit{Rot}(R \oplus n, \textit{IDS} m). \end{aligned}$$

Both the device tag and back end database replace the previous values of \((\textit{IDS}_\textit{new}, K_\textit{new})\) with the new values; therefore, if the attacker obtains IDS value for one execution of the protocol, it will not be valid for another protocol run. Figure 3 depicts the flow diagram of our protocol.

Fig. 3
figure 3

Flow diagram of the proposed protocol

Full size image

4 Security analysis

In this section, we prove the security of our approach by providing cryptanalysis of our algorithm using the general untraceable privacy model, to ensure that the tags in our approach cannot be traced. The model we describe is based on the Juels–Weis model for RFID protocols [36]. In [37], Phan has presented a cryptanalysis of the SASI protocol based on this model, which proves that SASI is vulnerable to tracking attacks. For our protocol we have also used the Juels–Weis model as in [37], to perform the cryptanalysis of our protocol.

4.1 The Juels–Weis challenge–response model

This model comprises a system with one reader R and ‘n’ RFID tags, every tag has its own secret key and one pseudonym which are reset after successful execution of each session, and the following messages are used:

  • To assign new secret key to the tag the SetKey message is used, when the tag receives SetKey message it discards the old key value and a new arbitrary secret is allotted to the tag.

  • The TagInit message initializes the session key to a new value, discarding the current session details and issuing a new session key.

  • The ReaderInit message is used by R to initialize a new session.

A is assumed to be an adversary which has the capability to generate any of the above messages. Once the tag is active it is entitled to respond to any number of challenge–response, i.e., (\(c_{i}, r_{i})\) messages, which is based on the information from previous sessions parameters and challenges-response messages. The tag stores a log which details previous sessions and challenge–response message pairs.

Whenever the reader R receives the message (sid, \(r_{i})\), it first evaluates a certain function based on its current status and all open as well closed sessions. On the basis of this function R outputs “accept” or “reject”. A can corrupt any existing tag and issue any new tag as it able to send any number of SetKey messages. Thus, if a tag receives SetKey message from A, it is said to be corrupted.

In this approach, it is assumed that the adversary A listens and controls all the ongoing communications and among the reader and the tags. At the end of every protocol session, the reader or tag (T Tags) outputs Accept message if it finds the other to be legitimate.

A has the ability to issue the following queries:

  • Execute(R, T, i): here A eavesdrops on an actual execution of the protocol between reader (R) and tag (T) in session i. It is a passive attack.

  • \(Send(P_{1},P_{2}, i,m)\): This query is the generalization of the challenge–response technique defined in Juels–Weis model along with the TagInit and ReaderInit messages. Here the adversary can impersonate a party \(\hbox {P}_{1}\) which could be the reader or a tag during session ‘i’ and sends m messages to some other party \(\hbox {P}_{2}\).

  • Corrupt(T, K): This query is same as the SetKey query, here the adversary changes the secret key of the tag to K. This is more powerful attack as compared to Send query as the adversary has access to the tag.

  • \(Test(T_{1}, T_{2}, i)\): When the Test query is issued, in the session ‘i’ depending upon b \(\in \) {0,1} an id \({ ID}_{b}\) is chosen from \(\{{ ID}_{1}\), \({ ID}_{2}\)} and A has to guess the bit ‘b’ correctly to succeed.

In the game that is to be played between the party and the adversary, the goal of the adversary is to identify the correct tag, and both of them must be fresh, i.e., it has not issued any corrupt queries. The following phases are considered in the game [38, 39]

  • Phase I (learning phase): During this phase, A is able to send any number of Execute, Send and Corrupt queries to learn about the tags and the reader.

  • Phase II (challenge phase): Here A chooses a new session and sends a Test message to the session. The session must be fresh and selects a random bit \(\in \) {0, 1} depending on which it is given a tag to guess. A then continues making the queries, ensuring that the tags that are chosen for guessing remain fresh.

  • Phase III (guessing phase): The game terminates when A outputs a bit value b, A wins if it successfully guesses the tag ID and is able to distinguish between \(\hbox {\textit{T}}_{0}\) and \(\hbox {\textit{T}}_{1}\). The success of A is quantitatively represented as advantage of A and denoted as:

In particular, consider an adversary A performing the following steps:

Learning phase: An execute query is issued so that A can listen to a protocol session between R and a tag \(\hbox {\textit{T}}_{1}\) to obtain the authentication variables R and S.

Challenge phase: A then chooses fresh tags \(T_{1}\), \(T_{2}\) with identifiers \(ID_{1}, ID_{2}\) (\(ID_1 \equiv 0\, mod\, 2\) and \(ID_2 \equiv 1 \, mod \, 2)\). A then sends a Test query. Subsequently, adversary A is given a test challenge identifier \(ID_b =\left\{ {ID_1 ,ID_2 } \right\} \). Note that by construction, \(b = ID_{bLSB}.\)

Guessing: The adversary A outputs a guess \({b}' \equiv S_\textit{LSB} \oplus R_\textit{LSB}\), which can be derived as:

$$\begin{aligned} \textit{Adv}_{A}(k)= & {} {\vert } \textit{Pr} [A \textit{ wins }] - 1/2 {\vert }\\= & {} {\vert } \textit{Pr} [b'=b] -- 1/2 {\vert } ={\vert } Pr [S \oplus R = b] - 1/2 {\vert } \end{aligned}$$

Considering only the LSBs we have:

$$\begin{aligned}= & {} {\vert }{} \textit{Pr } [S_\textit{LSB} \oplus R_\textit{LSB} =b ] - 1/2 {\vert }\\= & {} {\vert }{} \textit{Pr } [K_\textit{LSB} \oplus n_\textit{LSB } \oplus \textit{IDS}_\textit{LSB} \oplus m_\textit{LSB} ] - 1/2 {\vert }<< \in \left( k \right) \end{aligned}$$

Therefore, our advantage is negligible as compared to \(\in \left( k \right) \). As we have:

$$\begin{aligned} R_\textit{LSB}= & {} Rot\left( {Rot\left( {K_\textit{LSB} \oplus n_\textit{LSB}, \textit{IDS}_\textit{LSB} } \right) , K_\textit{LSB} \oplus m_\textit{LSB} } \right) \\ S_\textit{LSB}= & {} Rot\left( {Rot\left( {\textit{IDS}_\textit{LSB} \oplus m_\textit{LSB}, K_\textit{LSB} } \right) ,R_\textit{LSB} \oplus n_\textit{LSB} } \right) \end{aligned}$$

We have calculated the values of \(\hbox {\textit{S}}_{\mathrm{LSB}}\) and \(\hbox {\textit{R}}_{\mathrm{LSB}}\) using the truth tables and due to the use of rotation operation modulo 96, the values of R and S are always uncertain. Therefore, key and \({ IDS}\) values cannot be guessed by the adversary during the session. Tag and reader functionalities in the Juels–Weis Model are shown in Figs. 4 and 5, respectively.

Fig. 4
figure 4

Tag functionalities in the Juels–Weis model [36]

Full size image
Fig. 5
figure 5

Reader functionalities in the Juels–Weis model [36]

Full size image

4.2 Vulnerabilities due to modular operations

Here we perform the analysis of our protocol based on the modular operations, Hernandez–Castro et al. [40], have used this approach for the cryptanalysis of SASI. As we have also used rotation operations explicitly in calculating most of security parameters, another way to analyze the security of our protocol is to check the conditions where modular operation do not work, i.e., the value (wt(B) (mod n) = 0). In such case, we get the same variable A without rotation. Therefore, we have:

$$\begin{aligned} R= & {} \textit{Rot}(\textit{Rot}(K \oplus n, \textit{IDS}), K \oplus m);\\ R= & {} \textit{Rot}(\textit{Rot}(K \oplus n, \textit{IDS}), 0). \end{aligned}$$

Here, the probability of \((K \oplus m)\, mod n = 0\) is 1 / n (where \(n = 96\)). In this case, we have:

$$\begin{aligned} R = \textit{Rot}(K \oplus n, \textit{IDS}). \end{aligned}$$

Considering this case, our protocol will be safe as another rotation is to be performed and it will not give away any variable here. Therefore, if we also consider the case along with \(K \oplus m, { IDS}\) mod n = 0, we have:

$$\begin{aligned} R= & {} \textit{Rot}(K \oplus n, 0);\\ R= & {} K \oplus n. \end{aligned}$$

The probability of \({ IDS}\) mod n being zero will be 1/n. The total probability of R being \(K \oplus n \) will be \((1/n^{2})\) which is very low and ensure high security for our scheme, and even if such case arises, the value \(K \oplus n\) would not give away the key or any random variable as:

$$\begin{aligned} R \oplus P= & {} (K \oplus n) \oplus (\textit{IDS} \oplus m \oplus n); \\= & {} K \oplus \textit{IDS} \oplus m; \end{aligned}$$

and

$$\begin{aligned} R \oplus Q = (K \oplus n) \oplus (K \oplus n) = 0. \end{aligned}$$

Similarly, \(R \oplus S\) will also make no sense, thus in this case, our protocol is secure.

If we consider a similar case with the variable S, with the probability of \((1/n^{2})\), we have:

$$\begin{aligned} S = \textit{IDS} \oplus n. \end{aligned}$$

Here, if we try to extract other parameters by the help of S, we get:

$$\begin{aligned} S \oplus P = (\textit{IDS} \oplus n) \oplus (\textit{IDS} \oplus m \oplus n) = m; \end{aligned}$$

and

$$\begin{aligned} S \oplus Q = (\textit{IDS} \oplus n) \oplus (K \oplus n) = K \oplus \textit{IDS}. \end{aligned}$$

Here also, \(S \oplus R\) will make no sense, although the adversary has the value of random variable m, but if we examine our protocol carefully, the adversary will not be able to crack the values of any other variables with only ‘m’. Hence, our protocol is not vulnerable due to modular operation used during the rotations.

4.3 Security against other attacks

In this section, we evaluate the strength of our protocol on the basis of the basic requirements of any mutual authentication protocol, i.e., confidentiality, integrity and tracking, etc., and the attacks from which it needs to be secured.

Confidentiality The messages that are sent over the insecure channel between device tag and the reader make use of the shared key, IDS and the random numbers. It is hard to obtain the random numbers and the device tag ID, because it is not send over the insecure channel. It is also hard to guess the Key value and IDS from P and Q as they are masked with the random numbers. The other variables R and S also have the key and IDS values masked and then left rotated on a certain hamming weight, so that data confidentiality is ensured.

Data integrity The variables R and S which are used to ensure mutual authentication also ensure the data integrity. Suppose the attacker modifies the values of P and Q, then the value of \(R'\) will be invalid and the protocol will terminate. It is hard for the attacker to modify the values such that the value of \(R'\) is correctly calculated. Thus, our protocol ensures data integrity.

Anonymity and tracking As shown in Sect. 4.1, the value of the key and the pseudonym are updated after every successful protocol run and the random number are also different in each run. Since the device tag ID is not send in any messages, the attacker cannot acquire the tag ID, ensuring device tag anonymity. Thus, the attacker is also able to track the device tag using the key and pseudonym value and variable transmitted during the protocol run, as they are different every time.

Forward secrecy It refers to securing the previous communications between the device tag and the adversary if the device tag is compromised. Suppose the attacker is somehow able to acquire the tag ID. The adversary is still not able to determine the previous conversations as it involves random numbers, pseudonym and a key value. Suppose there is a case where the attacker obtains the \({ IDS}\) and key value, the adversary is still unable to get the previous data as after protocol run the values of \({ IDS}\) and key are different and the communication also involve random numbers which mask these values.

Security against man-in-the-middle attacks Our scheme is secure against the man-in-the-middle attack as the values of P, Q, R and S if intercepted and changed will cause the value of \(R'\) and \(S'\) to be different. Consequently, the authentication will be unsuccessful. Moreover, the attacker is also not successful in getting key and pseudonym value as they are masked with random numbers.

Security against replay attacks Our scheme is secure against the replay attacks, as each message involves random numbers which are different; therefore, the protocol will terminate, if the attacker tries to replay older messages. The replays of messages will not have any effect on the device tag.

Security against de-synchronization attacks De-synchronization attacks disturb the synchronization between the device tag and the reader. The attacker may try to desynchronize the device tag and the reader by enabling them to use different values of m and n. The messages can be modified so that different values of random number one obtained by both parties, but such modification also causes the values of R to change in an unpredicted fashion, thus, ensure synchronization between the reader and the device tag. As we save, both new as well as the old values if \({ IDS}\) and key at both tag and the reader, the attacker cannot use fake \({ IDS}\) value to break the synchronization between them.

Security against disclosure attacks The attacker cannot obtain any information; even if they have P, Q, R and S, even if the adversary has \({ IDS}\) they are able to obtain any of the random number or the key value from P and Q. Similarly, the attackers cannot extract any values from R and S with the help of P and Q. Thus, our protocol is safe from disclosure attacks.

5 Performance analysis

In this section, we evaluate the performance of our proposed scheme on the basis of its computation, storage and communication cost for each device tag. As our approach only requires XOR \((\oplus )\) and left rotation (Rot(.,.)), thus it has very low computation cost.

Table 1 Comparison of our protocol with existing ultra-lightweight protocols
Full size table

Each tag requires to store five 96-bit values which are: IDS, K, m, n and device tag ID. Thus, the total storage requirements is 5L bits where \(L = 96\) (i.e., \(5 \times 96 = 480\) bits) which is lesser than SASI. Each tag while undergoing mutual authentication sends two messages each having one 96-bit value (i.e., IDS and S); thus, the communication cost for each device tag is 2L = \(2 \times 96 = 192\) bits.

Table 1 shows the comparison of our work with existing ones. Our protocol performs significantly well as compared to SASI [22], LMAP [29], M2AP [30], EMAP[31] and RAPP [41] protocols in terms of security against attacks and storage and communication size. In addition, our protocol requires fewer operation as compared to others and thus without the use of AND and OR operations our protocol is safe from tango attacks.

6 Conclusion and future work

In this paper, we have discussed a new ultra-lightweight mutual authentication protocol for IoT device tags. Our scheme transmits data securely over an insecure channel ensuring security from various attacks such as DDOS, Replay and Tracking, etc., as discussed in the previous sections. We have also compared our approach with the existing approaches and we obtained promising results. In addition, our protocol uses only two bitwise operations for authentication, which makes it very efficient for IoT devices with limited resources and computation capabilities as these operations can be implemented with passive tags. The storage and communication cost is also very low as compared to other ultra-lightweight mutual authentication approaches. Our protocol is also secure from tango attacks as it does not use AND and OR operations for mutual authentication protocol. We also aim to study the security of our protocol against denial of service attacks at both tag and reader side. In future, we also aim to perform further in-depth cryptanalysis of our proposed approach.