Cryptanalysis of Two Recent Ultra-Lightweight Authentication Protocols

Abstract

Radio Frequency Identification (RFID) technology is a critical part of many Internet of Things (IoT) systems, including Medical IoT (MIoT) for instance. On the other hand, the IoT devices’ numerous limitations (such as memory space, computing capability, and battery capacity) make it difficult to implement cost- and energy-efficient security solutions. As a result, several researchers attempted to address this problem, and several RFID-based security mechanisms for the MIoT and other constrained environments were proposed. In this vein, Wang et al. and Shariq et al. recently proposed CRUSAP and ESRAS ultra-lightweight authentication schemes. They demonstrated, both formally and informally, that their schemes meet the required security properties for RFID systems. In their proposed protocols, they have used a very lightweight operation called $Cro(·)$ and $Rank(·)$, respectively. However, in this paper, we show that those functions are not secure enough to provide the desired security. We show that $Cro(·)$ is linear and reversible, and it is easy to obtain the secret values used in its calculation. Then, by exploiting the vulnerability of the $Cro(·)$ function, we demonstrated that CRUSAP is vulnerable to secret disclosure attacks. The proposed attack has a success probability of "1" and is as simple as a CRUSAP protocol run. Other security attacks are obviously possible by obtaining the secret values of the tag and reader. In addition, we present a de-synchronization attack on the CRUSAP protocol. Furthermore, we provide a thorough examination of ESRAS and its $Rank(·)$ function. We first present a de-synchronization attack that works for any desired $Rank(·)$ function, including Shariq et al.’s proposed $Rank(·)$ function. We also show that $Rank(·)$ does not provide the desired confusion and diffusion that is claimed by the designers. Finally, we conduct a secret disclosure attack against ESRAS.

1. Introduction

The fundamental concept underlying the Internet of Things is that any device can be technologically enhanced to transform into a computing device and communicate with its surroundings autonomously and in real-time. This vision is becoming a reality due to the exponential growth in the number of IoT-connected devices around the world. In other words, IoT is a cutting-edge technology that aims to connect a large number of smart devices to the Internet. Because of the many IoT applications in areas such as smart things, commuting, and healthcare systems, IoT has evolved into an indispensable aspect of our daily lives. Each smart device has a sensor that allows it to sense, collect, and communicate data about its surroundings. Each device connects to the Internet, uses a unique identifier as the name, and sends data from one location to another. This interconnected system has many advantages to enhancing traditional ecosystems. The use of sensors in medical devices, for example, has a number of benefits, including remote and ongoing patient health surveillance and real-time illness treatment, which lowers healthcare costs and raises the standard of living for the elderly and children. The Medical Internet of Things (MIoT) employs an intelligent system that allows devices to collect patient data and send it to a secure cloud-based platform where it can be saved, processed, and evaluated. In addition to storing the information of numerous patients, these systems recommend a real-time evaluation of the patient’s stored information in order to improve the effectiveness of healthcare systems. A significant number of corporations are making significant investments in the healthcare sector as a result of the incorporation of IoT in healthcare products. On the other hand, in this example, the patient’s data are incredibly important and critical. Hence, using it improperly could put the patient in jeopardy or perhaps bring the entire system to a halt. Consequently, when these smart medical devices are detecting and transferring data, it is essential to use suitable security mechanisms to protect those data. As a result, the sender and receiver’s identities must be verified using a security protocol known as the authentication protocol.

Chien et al. [1] categorized the four types of RFID authentication protocols as follows:

• Full-fledged protocols: These protocols should support common cryptographic components such as symmetric and asymmetric encryption functions, as well as other one-way cryptography functions. For example, they can support time-consuming primitives, such as Elliptic Curve Encryption (ECC) and RSA.
• Simple protocols: Support for one-way hash functions and symmetric encryption and the ability to generate pseudo-random numbers on tags are required for this category of protocols.
• Lightweight protocols: This category contains protocols that can generate pseudo-random numbers for tags and have simple operations, such as the Cyclic Redundancy Code (CRC) checksum, which is simpler than the one-way hash function.
• Ultra-lightweight protocols: This class of protocols allows only bit-wise logical operations on tags, e.g., bit-wise XOR, AND, OR, rotation, and so on. In addition, the tag’s side could include a pseudo-random number generator.

Recently, Wang et al. [2] proposed a new ultra-lightweight RFID authentication protocol based on a new ultra-lightweight function called $Cro(·)$ for MIoT devices. They also showed their scheme is appropriate for healthcare systems and meets the security criteria (such as consistency, synchronization, and tag anonymity) that are required for RFID systems. However, in this research, we present a de-synchronization attack against it that may be used against any chosen $Cro(·)$ function in this scheme. It reveals a vulnerability in the way their protocol was designed. We also show that since the building block of their protocol, i.e., $Cro(·)$, is linear and reversible, it has important security pitfalls. Then, we use the security vulnerability of $Cro(·)$ to conduct a secret disclosure attack with the success probability of one and complexity of one protocol’s execution and conducting some offline computations. In the same line, Shariq et al. [3] also proposed a new ultra-lightweight RFID authentication protocol called ESRAS based on a new ultra-lightweight operation called $Rank(·)$ for low-cost tags. They also showed their scheme provides the expected security criteria for RFID systems. In this paper, we demonstrate an efficient de-synchronization attack against this protocol and show that the proposed $Rank(·)$ function is not a good choice to provide the expected diffusion and confusion in a cryptographic protocol. We also presented a secret disclosure attack against Shariq et al.’s protocol.

1.1. Main Contribution

The following are this paper’s contributions:

• Presenting a de-synchronization attack against Wang et al.’s protocol called CRUSAP that may be used against any chosen $Cro(·)$ function.
• Presenting the security pitfall of $Cro(·)$ operation, which was recently proposed by Wang et al. They used $Cro(·)$ as a building operation of their proposed protocol, i.e., CRUSAP.
• Implementing a secret disclosure attack against CRUSAP, both theoretically and practically.
• Proposing an efficient de-synchronization attack against Shariq et al.’s scheme, ESRAS, which works for any desired $Rank(·)$ function.
• Analyzing the details of the proposed $Rank(·)$ and showing that it is equivalent to the rotation function in reality and does not provide a high level of security.
• We also propose a full secret disclosure attack against ESRAS.

1.2. Paper Organization

The remainder of the paper is structured as follows: The related works are reviewed in Section 2 and the explanation of the $Cro(·)$ operation and Wang et al.’s protocol, i.e., CRUSAP, is included in Section 3. In Section 4.1, we explain the de-synchronization attack against CRUSAP. The security pitfall of $Cro(·)$ is explained in Section 4.2, and then using that flaw, the Wang et al. protocol is subjected to our proposed secret disclosure attack in Section 4.3. We use the results of simulations in Section 4.4 to confirm that our proposed secret disclosure attack is practical and doable. The ESRAS protocol is described in Section 5 and its security pitfalls, including its vulnerability against de-synchronization and secret disclosure attacks and weakness of the cryptographic properties of $Rank(X,Y)$, are explained in detail in Section 6. We conclude the paper in Section 7 with concluding remarks.

2. Related Work

An authentication protocol is said to be rotation-based if a significant proportion of operations conducted on the parties are extremely lightweight functions, such as bitwise AND, OR, XOR, and rotations without the use of cryptographic primitives. The SASI protocol [1] is an RFID authentication system based on rotation functions, and several researchers have examined the security of these protocols. For instance, ref. [4] demonstrates that the protocols detailed in [1,5] are suspicious to de-synchronization and secret disclosure attacks. Tewari and Gupta [6] suggested another ultra-lightweight authentication scheme based on XOR and Rotation operations, but some research such as [7,8,9] showed that this scheme [6] is vulnerable to de-synchronization and secret disclosure attacks. Furthermore, ref. [7] introduced a modified version of Tewari and Gupta’s [6] scheme, while [10] illustrated that their protocol is not secure enough against secret disclosure, de-synchronization, and man-in-the-middle attacks. In 2017, Fan et al. [11] proposed another ultra-lightweight authentication scheme named ULRAS, which uses the specific bit operation called the RR method. However, ref. [12] showed that their protocol is not secure against secret disclosure attacks and proposed a modified version of [11]. After that, ref. [13] proved that the proposed protocols in [11,12] suffer from de-synchronization attacks. In this line, another RFID authentication scheme using the hash function and bitwise operations was developed by [14]. However, [15] examined the security of this protocol and demonstrated that it contains security and privacy flaws. Thus, the researchers then made an effort to enhance the security of the scheme [14] by retaining a minimal level of computational cost in the database and offering a new secure lightweight protocol. Ref. [16] proposed a double authentication scheme via secret sharing for low-cost RFID tags, while [17] showed that their protocol does not withstand replay and de-synchronization attacks. Furthermore, ref. [18] proposed a lightweight authentication scheme for cloud environments, but [19] proved that their protocol is suspicious of anonymity and impersonation attacks. Ref. [20] proposed an authentication scheme named URAP, and their protocol is secure against a wide range of attacks.

3. CRUSAP

In this section, first, the notations used in the paper are described. After that, the $Cro(·)$ function is explained, and then the CRUSAP, in which the $Cro(·)$ function is used as the main function, is described.

3.1. Notations

Throughout the paper, we used notations represented in

Table 1. Notations used in this paper.

Symbol	Description
L	The Length of secret key and message
$M_i$	The $i^{th}$ message was produced by one of three entities involved in the authentication phase
$TID$	The tag’s distinct static identifying $ID$
$RIDS$	The reader index pseudo $ID$ for the current session
$TIDS$	The tag index pseudo $ID$ in the current session
$TID{S}^{old}$	The tag index pseudo $ID$ from the previous session
$TID{S}^{new}$	The tag index pseudo $ID$ in the next session
$n_1,n_2,n_3$	Random numbers
$K_R$	The shared secret key between the reader and the cloud server in the current session
$K_T$	A shared key between the tag and the cloud server
$K_T^{old}$	The previous shared key between the tag and the cloud server
$K_T^{new}$	The most recent shared key between the tag and the cloud server
$K_1,K_2,K_3$	Subkeys of $K_T$
$Rot(X,Y)$	The left rotation of X in the amount of Y used in the CRUSAP
$RoR(X,Y)$	The right rotation of X in the amount of Y used in the security analysis of CRUSAP; $RoR\left(Rot\right(X,Y),Y)=X$;
$·Cro(X,Y)$	The proposed function in [2]
⊕	The bitwise Exclusive-OR operation
$PRNG$	The generator of pseudo random numbers
$IDT$	The mapping table in the cloud server
‖	The strings concatenation operation
$ID{S}^i$	The tag’s pseudonym in the $i^{th}$ session
$rank\left(X\right)$	The number of bits of X that are 1
$nullity\left(X\right)$	The number of bits of X that are 0
$Rot(X,Y)$	The left rotation of string X in amount of $rank\left(Y\right)$ in the ESRAS
$Groupping\left(X\right)$	The string X is divided into $X_1\parallel X_2$ based on $rank\left(X\right)$, and this partitioning is continued as far as $|X_i|>T_h$, where $T_h$ is a threshold value and suggested to be greater than 5 in the ESRAS
$Swapping\left(X^{\prime }\right)$	Assuming that the string $X^{\prime }$ has been partitioned based on $rank\left(X^{\prime }\right)$ and $nullity\left(X^{\prime }\right)$ into $X_1^{\prime }\parallel X_2^{\prime }$ then $Swapping(X_1^{\prime }\parallel X_2^{\prime })=X^{″}=X_2^{\prime }\parallel X_1^{\prime }$
$Swappin{g}^{-1}(·)$	The inverse of $Swapping(·)$
$Rank(X,Y)$	The special function used in the ESRAS
$R_1^i$	The random value generated in $i^{th}$ session of ESRAS by the reader
$B_L$, $B_R$	The left and right halves of B, respectively
$\sim X$	The bitwise complement of the string X

.

3.2. $Cro(·)$ Function

Wang et al. have claimed that $Cro(·)$ is a cryptographic operation that does not imposes a burden on tags and provides protocol security.In this paper, and in Section 4.3, we show that this function is very vulnerable against security attacks and the secret values used in its calculation can be easily obtained. Here, we describe the $Cro(·)$ operation. To describe $Cro(·)$, at first, a new bit operation called bit-wise crossover is declared by [2]. Given X, Y, and Z are three L bit binary strings (where L represents an even number) as follows:

$$\begin{array}{c}X=x_1{x}_2{x}_3\dots x_L;x\in \{0,1\},i=1,2,3,\dots ,L\\ Y=y_1{y}_2{y}_3\dots y_L;y\in \{0,1\},i=1,2,3,\dots ,L\\ Z=z_1{z}_2{z}_3\dots z_L;z\in \{0,1\},i=1,2,3,\dots ,L\end{array}$$

The bit-wise crossover rearrangement operation is divided into two steps. The processes that perform adjacent parity XOR on the strings X and Y are executed first. In the second step, the output produced by the first step’s operation is subjected to a bit-wise rearrangement operation. In the following, these two steps are described in more detail:

• XOR operation on a neighboring even–odd crossing XOR operation: This particular operation process entails performing an XOR operation on the value of the odd bit of X and the value of the next even bit of Y, as well as an XOR operation on the value of the even bit of X and the value of the next odd bit of Y. If i is odd, $Z_i$ is computed as $Z_i=X_i\oplus Y_{i+1}$, and if i is even, $Z_i$ is computed as $Z_i=X_i\oplus Y_{i-1}$. After completing this phase, the binary string Z can be represented as $Z=Z_1\parallel Z_2\parallel \dots \parallel Z_i\parallel \dots \parallel Z_L$, which equals to $Z=X_1\oplus Y_2\parallel X_2\oplus Y_1\parallel \dots \parallel X_{L-1}\oplus Y_L\parallel X_L\oplus Y_{L-1}$.
• Self-combination crossover rearrangement procedure: At this stage, the bits resulting from XOR of X and Y based on the relations explained above, represented by Z, are rearranged according to the following pattern and form the final output of the operation, which is $Cro(X,Y)$. Given X and Y are 8-bit strings, $Cro(X,Y)$ is computed as $Cro{(X,Y)}_0=Z_3$,$Cro{(X,Y)}_1=Z_4$,$Cro{(X,Y)}_2=Z_2$,$Cro{(X,Y)}_3=Z_5$,$Cro{(X,Y)}_4=Z_1$,$Cro{(X,Y)}_5=Z_6$, and $Cro{(X,Y)}_7=Z_7$. Figure 1 illustrates a recap of these procedures.

3.3. Protocol Description

CRUSAP includes three main entities, tags, (mobile) readers, and the cloud server. Following [2], Section 3.2, both channels between the reader and the tag and the reader and the server are wireless and insecure. It is worth noting the cloud server is connected to a database over the secure channel. This protocol is briefly reviewed in this section in two phases: Registration Phase and Authentication Phase.

Registration Phase: In this phase of CRUSAP, the cloud server stores the shared secret and information of tags and readers, including $TID{S}^{old}$, $TID{S}^{new}$, $RIDS$, and a mapping table $IDT$, which uses $TIDS\parallel RIDS$ as an index to find the related $K_T$ and $K_R$ necessary for verification. The tag also stores $TIDS$ and $K_T(K_1,K_2,K_3)$. Moreover, the reader stores $RIDS$ and $K_R$. It is worth noting that the mapping table $IDT$ will keep the index $TID{S}^{old}\parallel RIDS$ and its content during the previous round of verification.

Authentication Phase: To authenticate a legitimate tag in CRUSAP, the process is as follows:

• The reader transmits a “Hello” to the tag and asks for verification.
• As a response, the tag sends its $TIDS$ to the reader.
• Following receipt of the tag response, the reader generates a random number $n_1$ using $PRNG$, then computes a message $M_1=Rot(Cro(RIDS,K_R),n_1)$ and transmits it, along with the $TIDS$, $n_1$, and $RIDS$, to a cloud server over a public channel.
• The $TIDS\parallel RIDS$ will be queried to the database by the cloud server. The corresponding shared key information $K_T^{new}$ and $K_R$ can be obtained if the match is successful. If not, the database uses the previous version of $TID{S}^{old}\parallel RIDS$ and tries to match it. If it finds a matching, the server receives the crucial data $K_T^{old}$ and $K_R$ from the $IDT$, which corresponds to $TID{S}^{old}$ and $RIDS$; otherwise, the cloud server will deem this tag to be invalid and will end the verification process. In the case of successful matching, a confirmation message $M_2=Rot(Cro(RIDS\oplus n_1,K_R),K_R)$ is computed by the cloud server and sent to the reader over a public channel.
• The reader verifies the received $M_2$ to successfully authenticate the cloud server and tag. In addition, the reader produces another random number $n_2$ using $PRNG$, which is used to compute $M_3=Rot(Cro(TIDS,K_1),K_2)\oplus n_2$ and $M_4=Cro(Rot(TIDS,K_2\oplus n_2),K_1)$ values. After that, the reader sends $M_3$ and $M_4$ to the tag over a public channel.
• The tag extracts the random number $n_2^{\prime }$ from $M_3$ as $n_2^{\prime }=Rot(Cro(TIDS,K_1),K_2)\oplus M_3$ and verifies whether $M_4\stackrel{?}{=}Cro(Rot(TIDS,K_2\oplus n_2^{\prime }),K_1)$ to authenticate the reader. Next, the tag calculates and transmits the message $M_5=Cro(Rot(K_1+n_2,TIDS),K_2)$ to the reader over a public channel. If authentication failed, the tag refuses to authenticate it, and the process will end.
• Once $M_5$ is received, the reader verifies whether $M_5\stackrel{?}{=}Cro(Rot(K_1+n_2,TIDS),K_2)$ to authenticate the tag and update its local $RIDS$ and $K_R$. Then, using $PRNG$, the reader generates a random number $n_3$, calculates messages $M_6=Rot(Cro(K_3,n_2),K_2)\oplus n_3$, $M_7=Cro(Rot(K_3,K_1\oplus n_3),n_2)$, and sends $M_6\parallel M_7$ and $M_3\parallel M_6\parallel M_7$ to the tag and cloud server, respectively, over a public channel. The reader also carries out an updating step as $RIDS=Rot(Cor(RIDS\oplus K_1,K_2\oplus n_1),K_3)$ and $K_R=Rot(Cor(K_R,K_1),n_1\oplus K_2)$.
• The cloud server also extracts $n_2^{\prime }$ from $M_3$ and extracts $n_3^{\prime }$ from $M_6$, respectively, as $n_2^{\prime }=Rot(Cro(TIDS,K_1),K_2)\oplus M_3$ and $n_3^{\prime }=Rot(Cro(K_3,n_2^{\prime }),K_2)\oplus M_6$ and verifies whether $M_7\stackrel{?}{=}Cro(Rot(K_3,K_1\oplus n_3^{\prime }),n_2^{\prime })$ to authenticate the reader and the tag and start the update phase if its computed $M_7^{\prime }$ equals the received $M_7$. The updating includes these computations: $TID{S}^{old}=TIDS$, $TID{S}^{new}=Rot(Cor(TID{S}^{old}\oplus K_2,K_3\oplus n_2^{\prime }),K_1\oplus n_3^{\prime })$, $K_1^{new}=Rot(Cor(K_1,n_3^{\prime }),n_2^{\prime }\oplus K_2)$, $K_2^{new}=Rot(Cor(K_2,n_2^{\prime }),n_3^{\prime }\oplus K_3)$, $K_3^{new}=Rot(Cor(K_3,n_2^{\prime }),n_3^{\prime }\oplus K_1)$, $RID{S}^{new}=Rot(Cor(RIDS\oplus K_1,K_2\oplus n_1^{\prime }),K_3)$, and $K_R^{new}=Rot(Cor(K_R,K_1),n_1^{\prime }\oplus K_2)$.
• Upon the receipt of $M_6\parallel M_7$, the tag extracts $n_3^{\prime }$ from $M_6$ as $n_3^{\prime }=Rot(Cro(K_3,n_2^{\prime }),K_2)\oplus M_6$ and verifies whether $M_7\stackrel{?}{=}Cro(Rot(K_3,K_1\oplus n_3^{\prime }),n_2^{\prime })$ to authenticate the reader and carry out the update phase as: $TIDS=Rot(Cor(TID{S}^{old}\oplus K_2,K_3\oplus n_2^{\prime }),K_1\oplus n_3^{\prime })$, $K_1=Rot(Cor(K_1,n_3^{\prime }),n_2^{\prime }\oplus K_2)$, $K_2=Rot(Cor(K_2,n_2^{\prime }),n_3^{\prime }\oplus K_3)$, $K_3=Rot(Cor(K_3,n_2^{\prime }),n_3^{\prime }\oplus K_1)$.

4. Security Analysis of CRUSAP

In this part, we first provide a de-synchronization attack that may be used against any chosen $Cro(.)$ function that reveals a vulnerability in the way CRUSAP was designed. The security flaw in the $Cro(·)$ function will then be discussed. Then, a secret disclosure attack against CRUSAP is described to exploit that flaw.

4.1. De-Synchronization Attack

CRUSAP updates the tag’s index after each successful session to avoid traceability and also provides forward secrecy. However, the reader is the only party that contributes to the protocol’s exchanged messages’ randomness. Hence, it is possible to apply the proposed attack by Safkhani et al. [17] on this protocol as follows, assuming that the current records of the tag is $(TID{S}^i,K_1^i,K_2^i,K_3^i)$.

• The adversary eavesdrops a session between the tag and the reader and stores $TID{S}^i$, $M_3^i=Rot(Cro(TID{S}^i,K_1^i),K_2^i)\oplus n_2^i$, $M_4^i=Cro(Rot(TID{S}^i,K_2^i\oplus n_2^i),K_1^i)$, $M_5^i=Cro(Rot(K_1^i+n_2^i,TID{S}^i),K_2^i)$, $M_6^i=Rot(Cro(K_3^i,n_2^i),K_2^i)\oplus n_3^i$ and $M_7^i=Cro(Rot(K_3^i,K_1^i\oplus n_3^i),n_2^i)$, where $n_1^i$, $n_2^i$, and $n_3^i$ are random values generated in $i^{th}$ session by the reader. However, the session is terminated by blocking $M_6^i$ and $M_7^i$, which means that the tag will not update its records. Hence, the tag record is still $(TID{S}^i,K_1^i,K_2^i,K_3^i)$, but the cloud server has $(TID{S}^i,K_1^i,K_2^i,K_3^i)$ and $(TID{S}^{i+1},K_1^{i+1},K_2^{i+1},K_3^{i+1})$, where, for example, $TID{S}^{i+1}=Rot(Cro(TID{S}^i\oplus K_2^i,K_3^i\oplus n_2^i),K_1^i\oplus n_3^i)$.
• The adversary allows another session between the tag and the reader, where the communicated messages are $TID{S}^i$, $M_3^{i+1}$, $M_4^{i+1}$, $M_5^{i+1}$, $M_6^{i+1}$, and $M_7^{i+1}$, which are computed using $n_1^{i+1}$, $n_2^{i+1}$, and $n_3^{i+1}$, which are random values generated in $i+1^{th}$ session by the reader. However, the session is again terminated by blocking $M_6^{i+1}$ and $M_7^{i+1}$. It means that the tag will not update its records. Hence, the tag record is still $(TID{S}^i,K_1^i,K_2^i,K_3^i)$, but the cloud server has $(TID{S}^i,K_1^i,K_2^i,K_3^i)$ and $(TID{S}^{i+2},K_1^{i+2},K_2^{i+2},K_3^{i+2})$, where, for example, $TID{S}^{i+2}=Rot(Cro(TID{S}^i\oplus K_2^i,K_3^i\oplus n_2^{i+1}),K_1^i\oplus n_3^{i+1})$.
• The adversary impersonates the reader toward the tag based on the eavesdropped messages from Step 1 as follows:

  (a)

  The adversary transmits a message ("hello") to the tag and asks for another round of verification;

  (b)

  As a response, the tag sends its $TID{S}^i$;

  (c)

  Following receipt of the tag response, the adversary sends the stored $M_3^i$ and $M_4^i$ to the tag;

  (d)

  The tag verifies the received $M_3^i$ and $M_4^i$ and computes $M_5^i=Cro(Rot(K_1^i+n_2^i,TID{S}^i),K_2^i)$ to the reader/adversary;

  (e)

  The adversary returns the stored local $M_6^i$ and $M_7^i$ to the tag;

  (f)

  The tag authenticates the adversary as a legitimate reader and updates its records based on $n_1^i$, $n_2^i$, and $n_3^i$. Hence, the tag record is $(TID{S}^{i+1},K^{+1})$, but the cloud server has $(TID{S}^i,K_1^i,K_2^i,K_3^i)$ and $(TID{S}^{i+2},K_1^{i+2},K_2^{i+2},K_3^{i+2})$, where, for instance, $TID{S}^{i+1}=Rot(Cro(TID{S}^i\oplus K_2^i,K_3^i\oplus n_2^i),K_1^i\oplus n_3^i)$, while $TID{S}^{i+2}=Rot(Cro(TID{S}^i\oplus K_2^i,K_3^i\oplus n_2^{i+1}),K_1^i\oplus n_3^{i+1})$.

At the end of the above attack, the cloud server’s records for the tags $(TIDS,K)$ does not match the stored record in the tag’s side with a high probability; hence, they have been de-synchronized. The attack complexity is just eavesdropping/impersonating three sessions of the protocol, which shows that the proposed attack does not just have a high chance of success but also a high efficiency.

4.2. $Cro(.)$ Security Analysis

In this section, we concentrate on $Cro(X,Y)$ and show how by having the output of this function and one of its inputs, e.g., X, the adversary can obtain the other input, i.e., Y. For this purpose, it is enough to carry out the steps shown below in order:

• As previously stated, the $Cro(X,Y)$ relation can be used to calculate the value of Z. As mentioned before, Z is the result of applying XOR to bits of X and Y, which has been converted to $Cro(X,Y)$ by an especial rearrangement. Therefore, we can easily achieve Z by changing the bit positions of the $Cro(X,Y)$ relation according to the definition stated in Section 3.2.
• We also know that an XOR relationship can be retrieved if two specific values are known. In other words, if we have the Z and also one of the inputs of the $Cro(X,Y)$ function, e.g., X, one can obtain the other input of the $Cro(X,Y)$ function i.e., Y. In other words, in the $Cro(X,Y)$ function, Y different bits are calculated based on $Y_i=Z_{i+1}\oplus X_{i+1}$. As a result, Figure 2 shows how this process is completed.

In the next section of this paper, we will present a secret disclosure attack on CRUSAP based on this weakness of $Cro(·)$.

4.3. Secret Disclosure Attack

Secret disclosure attack is a powerful security attack in which the adversary tries to discover one or more secret values used in the protocol. It is obvious that after applying the full secret disclosure attack, it is possible to perform many other attacks, such as impersonating one of the parties involved in the protocol and so on.

Secret Disclosure Attack on CRUSAP

In this section, we demonstrate how Wang et al.’s protocol is vulnerable to a secret disclosure attack. The proposed secret disclosure attack runs in two phases:

Learning phase: In this phase of the attack, the adversary eavesdrops the transferred messages over public channels in one run of CRUSAP and retrieved the exchanged messages in CRUSAP such as $M_1$, $RIDS$, $n_1$, and $M_2\parallel K_T\oplus K_R$. In other words, all the required information for the attack is transferred over a public channel and can be captured by the adversary.

It is worth noting that the messages are transmitted in the insecure channel as they are, and everyone, including the adversary, can obtain those messages. On the other hand, a secure channel is a channel in which the adversary or any unauthorized person has no access to the messages exchanged in this channel and cannot obtain information about them. The channels that are used in the registration phase are usually of the secure type, and the channels that are usually used in the authentication phase are of the insecure type. In this section, we are facing an insecure channel used in the authentication phase of CRUSAP, in which the adversary can easily eavesdrop and obtain all the exchanged messages in this channel.

Secret disclosure phase: For this phase of the attack, it is enough if the adversary does as follows:

• Given $M_1=Rot(Cro(RIDS,K_R),n_1)$ and $n_1$, conduct $RoR(M_1,n_1)$, which equals to
  $Cro(RIDS,K_R)$. For the simplicity, the value of $Cro(RIDS,K_R)$ is called B, i.e., $B=Cro(RIDS,K_R)$.
• Given $RIDS$ and $B=Cro(RIDS,K_R)$, it can be easily seen that the secret value of $K_R$ can be calculated after rearranging B using the equation introduced in Section 3. Figure 3 shows an example of the implementation of our proposed secret disclosure attack against CRUSAP for $L=8$ bit values.
• Since the adversary retrieved $K_T\oplus K_R$ message in the learning phase of the attack, now with disclosing $K_R$, it is possible to retrieve $K_T$ as $K_T=K_T\oplus K_R\oplus K_R$.
• By obtaining $K_R$ and $K_T$ and also having $RIDS$ and $TIDS$ from the exchanged messages, other types of attacks can be applied to the protocol. The complexity of the attack described in this section is only one run of the protocol, and the adversary can perform this attack with a success probability of one.

4.4. Implementation of the Proposed Secret Disclosure Attack against CRUSAP with C#

(1) Calculation of CRUSAP main exchanged messages:

In this section, given $L=32$ bits for $RIDS$ and $K_R$, we can compute CRUSAP exchanged messages, such as $M_1$, as follows:

• $RIDS=$ 0 1 1 1 0 1 1 0, 0 1 1 1 0 1 1 0, 0 1 0 0 0 1 1 1, 1 1 0 0 0 1 1 0;
• $K_R=$ 1 0 1 0 0 1 0 0, 0 1 1 0 0 0 0 1, 1 0 1 0 0 1 0 0, 0 1 1 0 0 0 0 1;
• $K_T=$ 1 0 0 0 1 1 0 1, 0 1 1 1 1 1 1 0, 0 1 1 0 0 1 1 1, 1 1 0 0 1 0 0 1;
• $Z=SpecialXOR(RIDS,K_R)=$ 0 0 1 0 1 1 1 0, 1 1 1 0 0 1 0 0, 0 0 0 1 1 1 1 1, 0 1 0 1 0 1 0 0;
• $Cro(RIDS,K_R)=$ 0 1 1 1 1 1 0 0, 0 0 1 1 0 0 0 0, 0 0 1 1 1 1 1 1, 0 1 0 1 0 1 0 0;
• $n_1=$ 4;
• $M_1=Rot(Cro(RIDS,K_R),n_1)=$ 0 1 0 0 0 1 1 1, 1 1 0 0 0 0 1 1, 0 0 0 0 0 0 1 1, 1 1 1 1 0 1 0 1;
• $K_T\oplus K_R=$ 0 0 1 0 1 0 0 1, 0 0 0 1 1 1 1 1, 1 1 0 0 0 0 1 1, 1 0 1 0 1 0 0 0.

In the following step, we demonstrate how to calculate the value of $K_R$ and $K_T$ following the secret disclosure attack explained in Section 4.3.

(2) Disclosure of $K_R$ and $K_T$:

Given $L=32$ bits values for $M_1$ and $RIDS$ and a known $n_1$, it can be easily seen that we can compute $K_R$ and $K_T$ following the steps described in Section 4.3. It worth noting that $M_1$, $RIDS$, $K_T\oplus K_R$, and $n_1$ are accessible from the exchanged messages in the insecure channel of the protocol, which we assume are as follows:

• $M_1=$ 0 1 0 0 0 1 1 1, 1 1 0 0 0 0 1 1, 0 0 0 0 0 0 1 1, 1 1 1 1 0 1 0 1;
• $K_T\oplus K_R=$ 0 0 1 0 1 0 0 1, 0 0 0 1 1 1 1 1, 1 1 0 0 0 0 1 1, 1 0 1 0 1 0 0 0;
• $RIDS=$ 0 1 1 1 0 1 1 0, 0 1 1 1 0 1 1 0, 0 1 0 0 0 1 1 1, 1 1 0 0 0 1 1 0;
• $n_1=$ 4; then, we can carry out the following:
• Computing $RoR(M_1,n_1)=$ 0 1 1 1 1 1 0 0, 0 0 1 1 0 0 0 0, 0 0 1 1 1 1 1 1, 0 1 0 1 0 1 0 0$=Cro(RIDS,K_R)$;
• Obtaining Z from the rearrangement of $Cro(RIDS,K_R)$ as 0 0 1 0 1 1 1 0, 1 1 1 0 0 1 0 0, 0 0 0 1 1 1 1 1, 0 1 0 1 0 1 0 0;
• Then, since $Z=SpecialXOR(RIDS,K_R)$, given Z and $RIDS$, we can compute $K_R$ as 1 0 1 0 0 1 0 0, 0 1 1 0 0 0 0 1, 1 0 1 0 0 1 0 0, 0 1 1 0 0 0 0 1;
• Then, $K_T$ is calculated as $K_T=K_T\oplus K_R\oplus K_R=$ 1 0 0 0 1 1 0 1, 0 1 1 1 1 1 1 0, 0 1 1 0 0 1 1 1, 1 1 0 0 1 0 0 1.

It can be seen the retrieved values for $K_R$ and $K_T$, respectively, equal our assumptions of $K_R$ and $K_T$. Therefore, these implementations also showed that our proposed secret disclosure attack is practical and feasible.

5. ESRAS

ESRAS [3] is another ultra-lightweight authentication protocol that was recently proposed by Shariq et al. This scheme uses an ultra-lightweight operation called $Rank(X,Y)$ as the core of non-linearity to achieve desired diffusion and confusion, where X and Y are strings of bits as follows:

$$\begin{array}{cc}\hfill X=& x_1\parallel x_2\parallel \dots \parallel x_n\hfill \\ \hfill Y=& y_1\parallel y_2\parallel \dots \parallel y_n\hfill \end{array}$$

We describe this operation in this section first because it is crucial to understand the functionality of ESRAS. Through description, similar to the designers, we use the following strings for X and Y:

$$\begin{array}{cc}\hfill X=& 11000111101011101100011110011011\hfill \\ \hfill Y=& 10111101110101100011110111000010\hfill \end{array}$$

$Rank(X,Y)$ uses several other operations as follows:

• $rank\left(X\right)$: returns the number of bits of X that are 1, e.g., for the provided example $rank\left(X\right)=20$ and $rank\left(Y\right)=19$;
• $nullity\left(X\right)$: returns the number of bits of X that are 0, e.g., for the provided example $nullity\left(X\right)=12$ and $nullity\left(Y\right)=13$; it is obvious $rank\left(x\right)+nullity\left(x\right)=length\left(x\right)$;
• $Rot(X,Y)$: String X is left rotated by $rank\left(Y\right)$, for the given example $rank\left(Y\right)=19$ and $Rot(X,Y)=00111100110111100011110101110110$;
• $Groupping\left(X\right)$: The string X is divided into $X_1\parallel X_2$ based on $rank\left(X\right)$, and this partitioning is continued as far as $|X_i|>T_h$, where $T_h$ is a threshold value and suggested to be greater than 5. We will discuss $Groupping\left(X\right)$ in Section 6.2 in more detail;
• $Swapping\left(X^{\prime }\right)$: Assuming that the string $X^{\prime }$ has been partitioned based on $rank\left(X^{\prime }\right)$ and $nullity\left(X^{\prime }\right)$ into $X_1^{\prime }\parallel X_2^{\prime }$ then $Swapping(X_1^{\prime }\parallel X_2^{\prime })=X^{\prime \prime }=X_2^{\prime }\parallel X_1^{\prime }$.

Based on these operations, $Rank(X,Y)$ is computed as

$$\begin{array}{cc}\hfill Groupping\left(X\right)=& X^{\prime }\hfill \\ \hfill Groupping\left(Y\right)=& Y^{\prime }\hfill \\ \hfill Swapping\left(X^{\prime }\right)=X^{″}=& x_{m+1}\parallel x_{m+2}\parallel \dots \parallel x_n\parallel x_1\parallel x_2\parallel \dots \parallel x_m;wherem=rank\left(X^{\prime }\right)\hfill \\ \hfill Swapping\left(Y^{\prime }\right)=Y^{″}=& y_{m^{\prime }+1}\parallel y_{m^{\prime }+2}\parallel \dots \parallel y_y\parallel y_1\parallel y_2\parallel \dots \parallel y_{m^{\prime }};where{m}^{\prime }=rank\left(Y^{\prime }\right)\hfill \\ \hfill Rank(X,Y)=& \sim X^{″}\oplus \sim Y^{″}\hfill \end{array}$$

Protocol Description

The ESRAS protocol has two entities, i.e., RFID tag and the reader–server unit, and it includes two phases, i.e., initialization phase and authentication phase. It is worth noting that the channel between the tag and the reader–server is insecure, but the reader-to-sever communication considered over a secure channel.

In the initialization phase of ESRAS, for each tag $\mathcal{T}$, an identifier $ID$, a tag’s index $IDS$, and two secret keys $K_1$ and $K_2$ are generated by the manufacturer and stored in the tag’s internal memory and in the server side (BS). In addition, two records for $IDS$ are considered in BS as $ID{S}_{old}=IDS$ and $ID{S}_{new}=Null$.

The authentication phase of ESRAS is as follows, in which all messages are transferred over a public channel:

• The reader sends a Hello message to the tag.
• The tag in response returns its $IDS$.
• The reader generates a random number $R_1$ and computes $A=Rank(Rot(K_1,K_2),K_1)\oplus R_1$ and $B=Rank(Rot(K_1,R_1),K_1\oplus K_2)\oplus Rot(Rank(K_2,R_1\oplus K_2),K_1)$ and sends $\{A\parallel B_{RorL}\}$ to the tag. For sending messages, $B_L$ and $B_R$, respectively, denote the left and the right halves of B. If $rank\left(B\right)$ is odd, then $B_L$ is sent; otherwise, $B_R$ is sent.
• Once the message is received, the tag extracts $R_1$ from A and verifies $B_{RorL}$. Assuming that the verification was successful, the tag computes $C=Rank(Rank(K_1\oplus K_2,R_1),Rank(R_1,K_2))\oplus ID$ and sends it to the reader.
• The reader verifies the received C to authenticate the tag and update $ID{S}_{old}=IDS$ and $ID{S}_{new}=Rank\left(Rot(Rank(IDS\oplus R_1,K_1),K_2)\right)$. Next, it generates a random value $R_2$ and calculates $D=Rank(R_1,K_1\oplus K_2)\oplus Rank(K_1,K_2)\oplus R_2$ and $E=Rank(Rot(Rot(R_2,R_2),K_2),ID{S}_{new})\oplus Rot(Rank(R_1,R_1),R_2\oplus K_2)$. Finally, the reader sends $\{D,E_{RorL}\}$ to the tag.
• Once the message $\{D,E\}$ is received, the tag extracts $R_2$ from D, computes $ID{S}_{new}=Rank\left(Rot(Rank(IDS\oplus R_1,K_1),K_2)\right)$, and verifies $E_{RorL}$. Assuming that the verification was successful, the reader is authenticated, and $IDS$ is updated to $ID{S}_{new}$.

6. Security Analysis of ESRAS

In this section, we provide a more detailed security analysis of ESRAS. More precisely, while the authors claimed full diffusion and confusion by the introduced component $Rank(X,Y)$, and based on it, they claimed security against de-synchronization attacks and secret disclosure attacks, we show that the $Rank(X,Y)$ does not provide the expected diffusion and confusion. In addition, we show that despite of the used $Rank(X,Y)$, ESRAS suffers from the de-synchronization attack. Finally, we apply a successful secret disclosure attack on it.

6.1. De-Synchronization Attack

ESRAS updates the tag’s index after each successful session to avoid traceability and also provides forward secrecy. However, the reader is the only party that contributes to the protocol’s exchanged messages randomness. Hence, it is possible to apply the proposed attack by Safkhani et al. [17] on this protocol as follows, assuming that the current index of the tag is $ID{S}^i$:

• The adversary eavesdrops a session between the tag and the reader and stores $ID{S}^i,{\{A\parallel B_{LorR}\}}^i,C^i,{\{D\parallel E_{LorR}\}}^i$ but blocks ${\{D\parallel E_{LorR}\}}^i$ and does not allow the tag to update its $ID{S}^i$. Hence, the tag’s records of $IDS$ is $ID{S}^i$, but the reader has $ID{S}_{old}=ID{S}^i$ and $ID{S}_{new}=Rank\left(Rot(Rank(IDS\oplus R_1^i,K_1),K_2)\right)$, where $R_1^i$ is a random value generated in $i^{th}$ session by the reader.
• The adversary allows another session between the tag and the reader, where the communicated messages are $ID{S}^i,{\{A\parallel B_{LorR}\}}^{i+1},C^{i+1},{\{D\parallel E_{LorR}\}}^{i+1}$; however, again, the adversary blocks ${\{D\parallel E_{LorR}\}}^{i+1}$ and does not allow the tag to update its $ID{S}^i$. Hence, the tag’s records of $IDS$ is $ID{S}^i$ yet but the reader has $ID{S}_{old}=ID{S}^i$ and $ID{S}_{new}^i=Rank\left(Rot(Rank(IDS\oplus R_1^{i+1},K_1),K_2)\right)$, where $R_1^{i+1}$ is a random value generated in ${i+1}^{th}$ session by the reader.
• The adversary impersonates the reader toward the tag based on the eavesdropped messages from Step 1 as follows, i.e., $ID{S}^i,{\{A\parallel B_{LorR}\}}^i,C^i,{\{D\parallel E_{LorR}\}}^i$:

  (a)

  The adversary sends a Hello message to the tag;

  (b)

  The tag returns its $ID{S}^i$;

  (c)

  The adversary sends ${\{A\parallel B_{LorR}\}}^i$ to the tag;

  (d)

  Once the message is received, the tag extracts $R_1^i$ from $A^i$ and verifies $B_{RorL}^i$. The verification will be successful, and the tag computes $C^i=Rank(Rank(K_1\oplus K_2,R_1^i),Rank(R_1^i,K_2))\oplus ID$ and sends it to the reader/adversary;

  (e)

  The adversary sends ${\{D,E_{RorL}\}}^i$ to the tag;

  (f)

  Once the message ${\{D,E\}}^i$ is received, the tag extracts $R_2^i$ from $D^i$, computes $ID{S}_{new}^{i+2}=Rank\left(Rot(Rank(IDS\oplus R_1^i,K_1),K_2)\right)$, and verifies $E_{RorL}^i$. Assuming that the verification was successful, the reader is authenticated, and $IDS$ is updated to $ID{S}_{new}$.

At the end of the above procedure, the reader’s records for the tag’s index are $ID{S}_{old}=ID{S}^i$ and $ID{S}_{new}^i=Rank\left(Rot(Rank(IDS\oplus R_1^{i+1},K_1),K_2)\right)$, while the tag’s record is $ID{S}_{new}^{i+2}=Rank\left(Rot(Rank(IDS\oplus R_1^i,K_1),K_2)\right)$, where $R_1^i$ and $R_1^{i+1}$ are two independent random values generated, respectively, by the reader in $i^{th}$ and ${i+1}^{th}$ sessions. Hence, with the probability of $1-2^{-l}$, we have $R_1^i\ne R_1^{i+1}$ and with the same probability $ID{S}_{new}^{i+1}\ne ID{S}_{new}^{i+2}$. Since the probability for $ID{S}_{new}^{i+1}\ne ID{S}^i$ is also the same, the success probability of the proposed attack is $1-2^{-l+1}$. The attack complexity is just eavesdropping/impersonating three sessions of the protocol, which shows that the proposed attack not only has a high chance of success but also a high efficiency. This attack contradicts the designer’s claim against the protocol’s security against a de-synchronization attack in [3].

6.2. On the Cryptographic Properties of $Rank(X,Y)$

As it has been mentioned already, designers also used the operation $Groupping\left(X\right)=X^{\prime }$ through the computation of $Rank(X,Y)$, in which the string X is divided into $X_1\parallel X_2$ based on $Rank\left(X\right)$, and this partitioning is continued as far as $|X_i|>T_h$, where $T_h$ is a threshold value and suggested to be greater than 5. To understand $Groupping\left(X\right)$, the authors provided a numerical example [3] (Figure 1) based on $T_h=6$. Following that example, it is clear $Groupping\left(X\right)=X^{\prime }=X$. The provided example for $Groupping\left(X\right)=X^{\prime }=X$ in [3] (Figure 2) also confirms that $Groupping\left(X\right)=X^{\prime }=X$. Hence, we can omit the description of this operation. Following this, we can state that $Rank(X,Y)=\sim X^{″}\oplus \sim Y^{″}$, where $\sim X$ is the bitwise complement of the string X. On the other hand, for any bit $x_i$, we can state that $\sim x_i=1\oplus x_i$ and $\sim x_i\oplus \sim y_i=1\oplus x_i\oplus 1\oplus y_i$. Hence, $Rank(X,Y)=X^{″}\oplus Y^{″}$.

To accomplish $Swapping\left(X^{\prime }\right)$, assuming that $X^{\prime }=x_1^{\prime }\parallel x_2^{\prime }\parallel \dots \parallel x_n^{\prime }$ and $rank\left(X^{\prime }\right)=m$, it is computed as $Swapping\left(X^{\prime }\right)=X^{″}=x_{m+1}^{\prime }\parallel x_{m+2}^{\prime }\parallel \dots \parallel x_n^{\prime }\parallel x_1^{\prime }\parallel x_2^{\prime }\parallel \dots \parallel x_m^{\prime }$. Hence, given that $X^{\prime }=Groupping\left(X\right)=X$ and $Swapping\left(X^{\prime }\right)=X^{″}=x_{m+1}\parallel x_{m+2}\parallel \dots \parallel x_n\parallel x_1\parallel x_2\parallel \dots \parallel x_m$ and assuming that $rank\left(X\right)=m$ and $rank\left(Y\right)=m^{\prime }$, then:

$$\begin{array}{cc}\hfill Swapping\left(X\right)=X^{″}=& x_{m+1}\parallel x_{m+2}\parallel \dots \parallel x_n\parallel x_1\parallel x_2\parallel \dots \parallel x_m\hfill \\ \hfill Swapping\left(Y\right)=Y^{″}=& y_{m^{\prime }+1}\parallel y_{m^{\prime }+2}\parallel \dots \parallel y_y\parallel y_1\parallel y_2\parallel \dots \parallel y_{m^{\prime }}\hfill \\ \hfill Rank(X,Y)=X^{″}\oplus Y^{\prime }=& (x_{m+1}\parallel x_{m+2}\parallel \dots \parallel x_n\parallel x_1\parallel x_2\parallel \dots \parallel x_m)\oplus \hfill \\ \hfill & (x_{m+1}\parallel x_{m+2}\parallel \dots \parallel x_n\parallel x_1\parallel x_2\parallel \dots \parallel x_m)\hfill \end{array}$$

Given the definition of $Rot(X,Y)$ and $Rank(X,Y)$, we can represent $Rank(X,Y)$ as follows:

$$\begin{array}{cc}\hfill Rank(X,Y)=& Rot(X,\sim X)\oplus Rot(Y,\sim Y)\hfill \end{array}$$

It shows that $Rank(X,Y)$ does not provide the desired diffusion and confusion. More precisely, for $Rank(X,Y)$, they claimed that it provides full diffusion, while if it provides full diffusion, then any modification in input should change any bit of the output with the probability of $0.5$. However, for the given $Rank(X^1,Y)$, consider the case where for the string $X^1$, we have $x_1{x}_2=10$; thus, changing those bits into 01 to create $X^2$ does not affect $rank\left(X^2\right)$ compared to $rank\left(X^1\right)$. Additionally, $Rank(X^2,Y)$ is identical to $Rank(X^1,Y)$ in all $n-2$ bits that are not affected by those bits, and those bits of $Rank(X^2,Y)$ and $Rank(X^1,Y)$ complement each other exactly. It means that $rank(Rank(X^2,Y)\oplus Rank(X^1,Y))=2$ with the probability of 1. In addition, from $Rank(X^2,Y)\oplus Rank(X^1,Y)$, without the knowledge of $X^1$ or Y, the adversary can identify $rank\left(X\right)$, which contradicts another claim of the designers in which the claimed $Rank(X,Y)$ does not leak any information related to input values.

As another property of $Rank(X,Y)$, designers claimed that it is a one-way function, and given $Rank(X,Y)$ and Y for instance, it is not possible to determine X. However, given Y, the adversary easily computes:

$$\begin{array}{cc}\hfill Swapping\left(Y\right)=Y^{″}=& y_{m^{\prime }+1}\parallel y_{m^{\prime }+2}\parallel \dots \parallel y_n\parallel y_1\parallel y_2\parallel \dots \parallel y_{m^{\prime }}\hfill \end{array}$$

Given $Y^{″}$, $X^{″}$ is computed as $X^{″}=Rank(X,Y)\oplus Y^{″}$. On the other hand, $X^{″}=Swapping\left(X\right)=x_{m+1}\parallel x_{m+2}\parallel \dots \parallel x_n\parallel x_1\parallel x_2\parallel \dots \parallel x_m$ and $rank\left(X\right)=rank\left(X^{″}\right)=m$. Hence, given $X^{″}=x_1^{″}\parallel \dots \parallel x_n^{″}$, it is possible to invert the $Swapping(·)$ and determine X as follows, where $Swappin{g}^{-1}(·)$ is used to denote the inverse of $Swapping(·)$:

$$\begin{array}{cc}\hfill Swappin{g}^{-1}\left(X^{″}\right)=X=& x_{n-m}^{″}\parallel x_{n-m+1}^{″}\parallel \dots \parallel x_n^{″}\parallel x_1^{″}\parallel x^{″}2\parallel \dots \parallel x_m^{″}\hfill \end{array}$$

Hence, given $Rank(X,Y)$ and Y for instance, X is determined uniquely; vice versa, given $Rank(X,Y)$ and X for instance, Y is determined uniquely, which contradicts the designers’ claim in [3], Section 3.2.

6.3. Secret Disclosure Attack

While the proposed attack in Section 6.1 works for any $Rank(·)$ function and shows a structural flaw in the designed ESRAS, in Section 6.2, we described undesired properties of $Rank(·)$, which are used in this section to mount a more dedicated attack. The proposed attack in this section is a secret disclosure attack that reveals confidential information of a given tag. During the proposed attack, we use the fact that $rank\left(X\right)=rank\left(X^{\prime }\right)$, then $Rot(Y,X)=Rot(Y,X^{\prime })$.

The computed message through a session of the protocol are:

$$\begin{array}{cc}\hfill A=& Rank(Rot(K_1,K_2),K_1)\oplus R_1\hfill \\ \hfill B=& Rank(Rot(K_1,R_1),K_1\oplus K_2)\oplus Rot(Rank(K_2,R_1\oplus K_2),K_1)\hfill \\ \hfill C=& Rank(Rank(K_1\oplus K_2,R_1),Rank(R_1,K_2))\oplus ID\hfill \\ \hfill ID{S}_{new}=& Rank\left(Rot(Rank(IDS\oplus R_1,K_1),K_2)\right)\hfill \\ \hfill D=& Rank(R_1,K_1\oplus K_2)\oplus Rank(K_1,K_2)\oplus R_2\hfill \\ \hfill E=& Rank(Rot(Rot(R_2,R_2),K_2),ID{S}_{new})\oplus Rot(Rank(R_1,R_1),R_2\oplus K_2)\hfill \end{array}$$

and the messages are transferred over a public channel. $IDS$, $\{A\parallel B_{RorL}\}$, C and $\{D,E_{RorL}\}$ are accessible by the adversary. In addition, $IDS$ is updated at the end of each successful authentication.

Consider the transferred messages in the $i^{th}$ and $j^{th}$ sessions. Given that $K_1$ and $K_2$ are constant values for each tag and provided $A^i$ and $A^j$, we can state that:

$$\begin{array}{cc}\hfill A^i\oplus A^j=& [Rank(Rot(K_1,K_2),K_1)\oplus R_1^i]\oplus [Rank(Rot(K_1,K_2),K_1)\oplus R_1^j]\hfill \\ \hfill =& R_1^i\oplus R_1^j\hfill \end{array}$$

On the other hand, assuming that $rank\left(R_1^i\right)=rank\left(R_1^j\right)$, then $Rank(Rot(K_1,R_1^i),K_1\oplus K_2)=Rank(Rot(K_1,R_1^j),K_1\oplus K_2)$. In addition, if $rank(R_1^i\oplus K_2)=rank(R_1^j\oplus K_2)$ and $rank\left(R_1^i\right)=rank\left(R_1^j\right)$, then $rank(A^i\oplus A^j)=rank(B^i\oplus B^j)$.

Let us assume the adversary has stored $ID{S}^i$, $\{A^i\parallel B_{RorL}^i\}$, $C^i$, and $\{D^i,E_{RorL}^i\}$ for a session and blocked the last message to the tag. Thus, the tag’s record for its index is still $ID{S}^i$. Let us assume the adversary flips two bits of $A^i$ to achieve $A^{\prime i}$, e.g., $a_x^i$ and $a_y^i$, such that $|x-y|=\frac{l}{2}$, where l is the parameter length. In this case, assuming that $rank(R_1^i\oplus K_2)=rank(R_1^j\oplus K_2)$ and $rank\left(R_1^i\right)=rank\left(R_1^j\right)$, then considering $B^{\prime i}$ corresponds to $A^{\prime i}$, we have $rank(B_L^i\oplus B_L^{\prime i})=1$ and $rank(B_R^i\oplus B_R^{\prime i})=1$, and the probability of switching from left to right or vice versa in the required part of $B^i$ is $\frac{2}{l}$ and remains the same with the probability of $1-\frac{2}{l}$. Hence, if the adversary sends $\{A^{\prime i}\parallel B_{RorL}^{\prime i}\}$ to the tag such that $A^{\prime i}$ is computed by flipping two bits of $A^i$, as mentioned above, and $B_{RorL}^{\prime i}$ is computed by flipping a chosen bit of $B_{RorL}^{\prime i}$, with the probability of $(1-\frac{2}{l})\frac{1}{2}\times \frac{1}{2}\times \frac{1}{l/2}$, the sent message will be accepted by the tag, and the tag will return a response for C. Assuming that the tag returned a response, it means that the provided conditions were held. Hence, we can conclude that ${\left(Rank(Rot(K_1,K_2),K_1)\right)}_i\oplus {\left(Rank(Rot(K_1,K_2),K_1)\right)}_j=1$, where ${\left(Rank(Rot(K_1,K_2),K_1)\right)}_i$ and ${\left(Rank(Rot(K_1,K_2),K_1)\right)}_j$, respectively, denote $i^{th}$ and $j^{th}$ bits of $Rank(Rot(K_1,K_2),K_1)$. In this way, the adversary could achieve a single bit of information related to the secret parameters. The adversary can eavesdrop more $IDS$, $\{A\parallel B_{RorL}\}$, C, and $\{D,E_{RorL}\}$ and repeat the attack to extract whole ${\left(Rank(Rot(K_1,K_2),K_1)\right)}_i$. The expected complexity (in the term of sessions) of the attack is as follows:

$$l\times \frac{1}{(1-\frac{2}{l})\frac{1}{2}\times \frac{1}{2}\times \frac{1}{l/2}\times l}=\frac{1}{(1-\frac{2}{l})\frac{1}{2}\times \frac{1}{2}\times \frac{1}{l/2}}$$

Given ${\left(Rank(Rot(K_1,K_2),K_1)\right)}_i$ and eavesdropped A values, $R_1$ values are achievable. Then, from that information and the given values of $B_{RorL}$ on each session, the adversary can develop a linear equation system to extract $K_1$ and $K_2$. Following it and given C, it is possible to extract $ID$, which completes the secret disclosure attack on ESRAS.

7. Conclusions

Over the years, many ultra-authentication schemes have been proposed; however, unfortunately, all of those protocols are not secure. These protocols are commonly vulnerable to a variety of attacks, such as secret disclosure, de-synchronization, and impersonation attacks. This paper, similar to other papers in this field, once again showed that the ultra-lightweight operations, e.g., a limited number of bitwise operations, such as AND, OR, and XOR, are not enough to design a completely safe security protocol. This is why they are linear reversible operations.

In this paper, we proposed a de-synchronization attack and a secret disclosure attack against Wang et al.’s ultra-lightweight protocol called CRUSAP, with a success probability of one. We also show security vulnerabilities of ESRAS against de-synchronization and secret disclosure attacks.