A Highly Efficient ECC-Based Authentication Protocol for RFID

The availability of safety has always been a challenge in all fields of computing and networking, and the development of reliable security measures for low operating power systems has been a continuous task for researchers. This paper focuses on Radio Frequency Identification (RFID) systems, whose market is tremendously growing due to the increasing need for efficient supply chain and healthcare management. Two protocols are proposed that offer mutual authentication, confidentiality, forward security, anonymity, unlinkability, scalability, and resistance against the most important security attacks. They differ in storage requirements at the server side. Both proposed protocols are very efficient as the number of required elliptic curve multiplications is limited to two at the tag side. Moreover, the schemes are also more effective and secure than other related work presented in literature. In addition, we show how to extend the protocols in order to provide authentication with respect to multiple readers.


Introduction
Radio Frequency Identification (RFID) is a technology working on radio frequency and mainly used for the identification and tracking of tags attached to objects. RFID is considered to be one of the key technologies of the fast-growing Internet of Things (IoT) market, and its market value is expected to rise from $12.08 bn in 2020 to $16.23 billion by 2029 [1]. In recent years, RFID technology has also been commonly utilized in the healthcare context for applications such as child protection [2], position monitoring of medical assets [3], medical condition monitoring and validation [4], patient tracking and medication management [5,6], blood transfusion [7], and nursing home safety management [8]. Because health data is an integral aspect of personal privacy information [9], it is vital to secure private medical data and to guarantee anonymity and protection of tracking from access during the RFID authentication procedure. It is also already widespread deployed in a variety of other applications such as smart logistics management [10], safe access control [11], automated toll payment [12], staff monitoring, and theft prevention [12].
An RFID network consists of a device (including a tag), a reader, and a backend processor, where the reader has a special identification and can access the tag's working zone for read/write operations. As shown in Figure 1, after being initialized with the required security material from the backend server, the tag encrypts the identity details and transfers it to the reader. The reader can then authenticate the obtained data and the tag ID by relying on information available at the backend server, either in online or offline modus. Security and protection issues will be of considerable concern during the whole process for a lot of applications mentioned above. Besides confidentiality, authentication, and integrity, also anonymity and unlinkability are important features to assess in the development of the system in order to avoid tracking attacks.
The RFID device is classified as either passive or active, based on whether the device utilizes tags with an internal power source or is controlled by energy distributed by the RFID readers to relay signals on a continuous basis. Low-cost RFID devices highlight the challenges of securing systems, as traditional encryption primitives increase the cost of such devices due to their high power consumption. Although the difficulties in the design of low-cost protected RFID systems involve reduced computer size and processing capability, the introduction of a reliable and cost-effective authentication strategy to ensure the security of user information is critical. An RFID network consists of a device (including a tag), a reader, and a backend processor, where the reader has a special identification and can access the tag's working zone for read/write operations. As shown in Figure 1, after being initialized with the required security material from the backend server, the tag encrypts the identity details and transfers it to the reader. The reader can then authenticate the obtained data and the tag ID by relying on information available at the backend server, either in online or offline modus. Security and protection issues will be of considerable concern during the whole process for a lot of applications mentioned above. Besides confidentiality, authentication and integrity, also anonymity and unlinkability are important features to assess in the development of the system in order to avoid tracking attacks.
The RFID device is classified as either passive or active, based on whether the device utilizes tags with an internal power source or is controlled by energy distributed by the RFID readers to relay signals on a continuous basis. Lowcost RFID devices highlight the challenges of securing systems, as traditional encryption primitives increase the cost of such devices due to their high power consumption. Although the difficulties in the design of low-cost protected RFID systems involve reduced computer size and processing capability, the introduction of a reliable and cost-effective authentication strategy to ensure the security of user information is critical.
Previously, authentication protocols for RFID relied on hash functions and symmetric key cryptography. However, due to the good performance and low-key size specifications of elliptic curve cryptography (ECC), the creation of an effective RFID authentication protocol based on ECC is made possible. ECC has been already used in different authentication and key establishment protocols for IoT-based systems. ECC is a public key or asymmetric key cryptographic solution, offering smaller key sizes and lower computing costs compared to alternatives like RSA or systems relying on the discrete logarithm as trapdoor. In this paper, we propose two highly efficient EC-based authentication protocols for client-server architectures with a small client, e.g., sensor or tag and server, corresponding to the reader. The first protocol needs the storage of a list of acceptable tags and keys on the reader side, while the second protocol includes just the preservation of the list of revoked tags on the reader. The mathematical complexity of both protocols is limited by a maximum of two EC multiplications at the constrained tag side, which results in the best performance compared to other related work.
While both protocols satisfy many required security features, such as anonymity, untraceability, perfect forward secrecy, and mutual authentication, the only disadvantage is that the tag cannot validate the authenticity of the first received message, consisting of a random value from the reader. We therefore suggest to introduce an additional phase at the beginning of the procedure, requiring two additional EC multiplications at the tag side. The other benefit of this additional phase is that the authentication procedure can be   Journal of Sensors extended to any reader and not only to readers whose public key is prestored in the memory of the tag. We show that the proposed protocols have a comparable of even stronger security strength, compared to related work. The security of both protocols is proven in an informal way and formal way. For the formal review, the ProVerif [13] Model Checker is used. The paper is organized as follows. In Section 2, related work is described in more detail. Section 3 discusses some background on the architecture, attack model, and the EC-based operations. The proposed schemes are explained in Section 4. Section 5 shows the security of the scheme with respect to informal and formal evaluations. In Section 6, the performance of the protocols is discussed and compared with related work. Finally, Section 7 presents the conclusions of the paper.

Related Work
Client-server authentication is an essential operation, which is required in many use cases and application domains, for instance, health care, smart grid, and smart home. The literature on client-server authentication schemes can be divided into different areas. First, there are the schemes, where the client represents a user connected to a device or smartcard, enabling multifactor authentication schemes. Next, we can also distinguish the schemes in terms of the type of operations used, which mainly consists of symmetric and public key-based schemes. In our case, we focus on the schemes, where the client is a device with a limited amount of resources, but sufficient to still implement public key-based operations like EC operations. Examples of such clients are for instance a sensor or a tag, which requires authentication to be accepted by the reader.
In [14], a survey is given on the different classes of RFID authentication protocols, with a distinction in fully fledged, simple, lightweight, and ultralightweight protocols. Fully fledged protocols are defined as protocols supporting both symmetric and asymmetric operations and thus are the focus of this work. From the fully fledged protocols, EC-based operations are the most efficient ones and in particular [15][16][17][18] are analysed in their survey. Each of these schemes has also compared their strength and efficiency with other schemes in literature. For instance, the scheme of [15] has been compared with [14,19,20], the scheme of [16] with [21][22][23][24][25], the scheme of [17] with [14,20,26,27], and the scheme of [18] with [14,20,26,28]. From Table 2 of [14], it can be concluded that [18] is the most complete scheme with respect to security features and resistance against important security threats. However, when having a closer look to [18], we can also conclude that this scheme is not scalable as the reader needs to perform exhaustive search in the whole list of tags to verify the validity of the signature. This feature has not been considered in the survey. Moreover, unless it is considered secure against tracking and location privacy in [14], the attacker can easily follow the tag once the public key of the tag is known.
Recently, there are some new ECC-based schemes proposed. First, there is the scheme of [29], presented in the context of smart grid, which has been designed to satisfy resistance in the Canetti-Krawczyk (CK) security model. This model allows an attacker to also reveal session state-specific information, session keys, or long-term private keys, which is a pretty strong requirement. In [29], it has also been shown that the EC-based schemes of [30][31][32] were not resistant in the CK model and suffered also man-in-the-middle attacks and denial of service attacks. The scheme utilized the EC Qu Vanstone (ECQV) certificate mechanism [33]. We want to note that our second proposed scheme is inspired by this protocol but requires less computation as the proposed attack model is less strong than the CK model.
A second recent and interesting scheme is proposed in [34]. It is very efficient with only three EC multiplications at the tag side; however, not scalable as an exhaustive search at the reader side is required to find the Diffie Hellman key in order to decrypt the message and to be able to find the elementary information. Moreover, if the secret key of the reader or tag is known, the identity of the tag can be revealed. The protocol is compared against [35][36][37], where all of these schemes contain several shortcomings like no resistance against session-specific temporary information attack and time synchronisation attack.
Another important and recent protocol to be mentioned is given in [38]. Here, the tag identity and corresponding key shared with the reader are updated after each session. In order to avoid synchronisation attacks, there are two values stored at the reader, the last and previous one. Therefore, complete perfect forward security is not satisfied with respect to the second last session key. The scheme also suffers from the session-specific temporary information attacks as if the session data TK t1 , TK t2 is stored; the identity of the tag and corresponding key can be revealed for the current and next sessions. Consequently, if the attacker blocks the last communication message and the tag wants to restart the process, it uses its updated identity and key, which are now known to the attacker. In addition, the scheme is very weak for denial of service attacks as it consists of four phases and the authentication is only verified in the end. The scheme is compared with [39][40][41][42]. Again, each of these schemes contains significant weaknesses compared to [38], like no integrity check and no scalability. The scheme is very efficient due to the fact that the number of EC multiplications at the tag side is limited to three.
Finally, in [43], two ECC-based client-server authentication protocols have been proposed. The first protocol, which is an improved version of [44], is not secure for unlinkability in case of identity guessing, does not offer perfect forward secrecy, and is vulnerable for session temporary attacks. The second protocol, also called hash-based authentication protocol is developed in order to be used in a multireader-based scenario. It is very efficient as only 2 EC multiplications are required at the tag side. However, the scheme suffers from many security issues. First, it does not satisfy unlinkability as the attacker can send challenges at any moment to the tag, which enables the attacker to track a certain tag. Second, it is not secure against malicious insider servers as a server is able to impersonate the tag. It also does not offer perfect forward secrecy and is vulnerable for session temporary attacks.
To conclude, all the proposed EC-based authentication protocols in literature, satisfying at least anonymity, unlinkability, and mutual authentication, require at least three EC 3 Journal of Sensors multiplications at the tag side. Moreover, the schemes with three EC multiplications [34,38] suffer from several attacks, in particular when the attacker is allowed to get access to session information. In particular, it has been explicitly mentioned in [45] that the usage of the more expensive public key-based protocols is only allowed in case protection against a semitrusted TTP is needed, as otherwise all other security features can simply be addressed by a symmetric key-based protocol [46]. As shown in [45], almost all of the recently proposed EC-based protocols, defined for a more general client-server architecture (not limited to an RFID client), suffer from this weakness (e.g., [47,48]). Therefore, this has been carefully taken into account in our protocol designs. Finally, most of the protocols described in literature are only defined for tags authenticating to one predefined reader, which is not a very practical use case, and do not address scalability from the reader point of view.

Background
We first start to give some elementary background on the cryptographic operations. Next, we describe the architecture and corresponding adversary model.

Cryptographic Operations
The concatenation and xor operation of two messages M 1 and M 2 is denoted by M 1 ∥M 2 and M 1 ⊕ M 2 , respectively. We denote the symmetric encryption, like AES128, using a symmetric shared key K of message M by C = E K ðMÞ and the corresponding decryption by M = D K ðCÞ. Note that in our protocol, we only use the ⊕ operation for encryption and decryption, which corresponds with the one-pad scheme, offering perfect security [49].

Hash Functions.
For a one-way hash operation, we will use the latest SHA3 standard [50] and in particular the SHAKE128ðM, dÞ function on message M with variable input size and variable output size d. This function has a proven resistance of at least minðd/2,128Þ on collision attacks and preimage and second preimage attacks independent on the input length and output lengths larger than 256 bits. For ease of notation, we denote SHAKE128ðM, dÞ as HðMÞ.

Elliptic Curve-Based
Operations. ECC allows lightweight public key cryptographic solutions. In order to achieve 128-bit security, a field size of 256 bits for ECC is sufficient, compared to at least 3072 bits for RSA. ECC is based on the algebraic structure of ECs over finite fields F p . The E25519 curve [51] over the prime field p = 2 255 − 19 enables the fastest implementation for the EC operations and possesses also resistance against the well-known implementation attacks [52]. Compressed EC points, containing only the X coordinate, can be used to represent the complete point. We denote the EC addition of two points by P 1 + P 2 and multiplication by rP having r ∈ F q with q the order of the generator G. The security of ECC relies on the Elliptic Curve Discrete Logarithm Problem (ECDLP) and the Elliptic Curve Diffie Hellman Problem (ECDHP), both well-known computational hard problems.

Elliptic Curve Qu Vanstone
Mechanisms. The ECQV mechanism [33] allows to define certificates of very small size, compared to other approaches like X.509 certificates. Moreover, the scheme enables also the derivation of a secret key pair, with private key only known by the requested entity and not the trusted third party (TTP).
Denote the secret key pair of the TTP by ðd TTP , Q TTP Þ. The different steps in the derivation of the key pair ðd n , Q n Þ for an entity with identity id n are as follows. First, the entity sends its identity id n , together with an EC point R i = r i G, where r i is a randomly chosen variable. Next, also, the TTP chooses a random r T and computes R T = r T G. The certificate is then defined by Cert n = R i + R T . Next, an auxiliary value r = HðCert n ∥id n Þr T + d TTP is computed. The pair ðr, Cert n Þ is sent to the entity id n . The private key d n can now be derived as d n = HðCert n ∥id n Þr i + r. Only if Q n = d n G corresponds with HðCert n ∥id n ÞCert n + Q TTP the entity approves the key pair ðd n , Q n Þ and stores it in its memory. Note that this last derivation also corresponds to the operation, required to be executed by an outsider who is in the possession of the certificate Cert n and the identity id n .
3.2. Architecture. In our setting, we assume a tag (T), reader (R), and trusted third party (TTP). The tag is considered as a low-cost device in which efficiency plays an important role. The reader has to verify the legitimacy of the tag. Therefore, it needs to get access to the list of approved tags or a list of invoked tags. This can be either by storage at its own premises or by contacting a secure authentication service. Note that for the ease of notation, we consider here the first scenario. Finally, there is the trusted third party, who shares this list of tags to the reader during the initialisation process and does not participate in the actual authentication protocol.
3.2.1. Attack Model. The adversary has the following possibilities: (A1) The attacker can actively participate in the communication by modifying, replaying, or blocking the transmitted messages (A2) The attacker is able to passively monitor the communication and collect transmitted data in order to eventually exploit later on (A3) The attacker is able to derive the session-specific temporary information at both reader and tag, e.g., by means of timing attacks. Note that this can be simultaneously at the reader and tag at the same time (A4) The attacker can also get access to the long-term key material, stored at both reader and tag. Note 4 Journal of Sensors that this can be simultaneously at the reader and tag at the same time The attack scenarios (A1, A2) can be combined with (A3) or (A4). However, (A3) and (A4) cannot be executed at the same time, which is the main difference compared to the CK security model. Note that this security model is applied in most of the RFID-based authentication protocols.
For each of the above-described attack scenarios, our protocol should still be able to guarantee the following security criteria: (C1) Mutual authentication is offered in the protocol to avoid impersonation attacks. Both parties also need to participate in order to avoid key control attacks (C2) The anonymity of the tag should be guaranteed (C3) It should not be able to link the different requests to a specific tag and thus to track some particular tag (C4) Even if session-specific temporary information is leaked (cf (A3)), it should not be possible to impersonate or reveal the identity of the tag. This is called resistance against session-specific temporary information attack (C5) Even if the key material is revealed (cf (A4)), it should not be possible to impersonate the tag or to reveal its identity. This corresponds to the perfect forward secrecy feature (C6) Resistance against replay attacks should be realised (C7) Resistance against desynchronisation attacks should be offered. Even if the attacker blocks some messages, the reader and tag will still be able to successfully execute the protocol. This also results in the availability feature (C8) Scalability should be offered in order to find the matching record in the database of the reader in an efficient way, i.e., not through exhaustive search in all of the stored records (C9) Resistance against denial of service attacks should be provided as much as possible in order to avoid unnecessary work to be done by one of the entities before noticing a potential attack

Proposed Schemes
We first explain the two basic schemes, called Scheme 1.1 and Scheme 1.2, being a protocol with storage of individual key material for each legitimate tag (Scheme 1.1) and a protocol without storage of individual key material (Scheme 1.2). Note that in this last protocol, we can assume that only the list of revoked tags is stored. For both protocols, we discuss the initialisation and the actual authentication phase. We assume that all entities participating in the scheme implement the required EC parameters and the associated EC operations, together with the hash function. (1) Initialisation Phase. Each tag receives from the TTP the public key of the reader Q r = d r G to which it needs to authenticate to and the tuple ðid n , K n 1 , K n 2 Þ, representing a unique identity id n and two corresponding unique keys ðK n 1 , K n 2 Þ, respectively. These parameters are securely stored on the tag. The reader receives from the TTP the list of legitimate ðid n , K n 1 , K n 2 Þ n , which are securely stored in its database (DB). Also, its key pair ðd r , Q r Þ, containing private and public key, is securely stored at the reader.
(2) Authentication Phase. In the first step, the reader chooses a random value r r and computes R r = r r G = ðx r , y r Þ, which is sent to the tag. Note that by using the E25519 curve, it is sufficient to send x r as mentioned before. However, for clarity in notation, we still denote it as the full point R r .
Then, the tag also chooses a random value r n and computes R n = ðr n + K n 2 ÞG. Next, it derives Hððr n + K n 2 ÞðQ r + R r ÞÞ = ðhr 1 , hr 2 Þ in order to compute A 1 = K n 1 ⊕ hr 1 . Finally, the tag computes Hðid n ∥K n 1 ∥K n 2 ∥R r ∥R n ∥hr 2 Þ = ðh 1 ∥h 2 Þ and sends the message R n , A 1 , h 2 to the reader.
Upon receiving this message, with its private key d r and the temporary local variable r r , the reader first computes ð d r + r r ÞR n = ðhr 1 , hr 2 Þ in order to retrieve K n 1 = A 1 ⊕ hr 1 and looks it up in the DB containing the list of legitimate tags. If it does not exist, the protocol is aborted. Otherwise, it retrieves the corresponding identity-related material of that tag id n and the second key K n 2 and computes Hðid n ∥K n 1 ∥ K n 2 ∥R r ∥R n ∥hr 2 Þ = ðh 1 ∥h 2 Þ. If the second part of the output corresponds with the received h 2 , the reader approves the request and forwards h 1 to the tag.
The tag compares the stored h 1 value with the received one, and in case it is similar, the authentication is approved, otherwise the tag aborts the process. The different steps in this protocol are illustrated in Table 1.

Scheme 1.2: Without Storage at Reader Side
(1) Initialisation Phase. The tag first derives its private and public key by means of the ECQV protocol. As a result, it receives its identity id n , certificate Cert n , and key pair ðd n , Q n Þ with Q n = d n G = HðCert n ∥id n ÞCert n + Q TTP as shown in Equation (1). The values ðid n , Cert n , ðd n , Q n Þ, Q r Þ are stored on the tag.
The reader receives from the TTP the list of revoked tags containing ðid rn , Cert rn Þ rn .
(2) Authentication Phase. The first step is the same as in Scheme 1.1. The reader chooses a random value r r and computes R r = r r G. This value R r is sent to the tag.
Then, the tag also chooses a random value r n and computes R n = ðr n + d n ÞG. Next, it derives a Diffie Hellmann 5 Journal of Sensors key by computing K = ðr n + d n ÞðQ r + R r Þ = ðx k , y k Þ, which is used to encrypt the identity-related information, i.e., C = E K ðid n ∥Cert n ∥rÞ = ðid n ∥Cert n ∥rÞ ⊕ K, with r a randomly chosen value. Then, it computes Hðid n ∥Cert n ∥R r ∥R n ∥rÞ = ðh 1 ∥h 2 Þ and the corresponding signature s n = ðr n + d n Þ − d n h 2 . The message C, R n , s n is sent to the reader. Readerd r , Q r ð Þ, DB : id n , K n 1 , K n 2 À Á n Tagid n , K n 1 , K n 2 , Q r À Á Choose r r , R r = r r G = x r , y r ð Þ ⟶

[A3] Session-specific temporary information-SSReveal queries SSReveal
Long-term key material-corrupt queries Journal of Sensors In order to be able to construct a valid outcome in the protocol, the attacker needs to construct a legitimate h 2 (in the case of the tag) or h 1 (in the case of the reader). To do so, the attacker should know at the same time either id n , K n 1 , K n 2 , r n È É or id n , K n 1 , K n 2 , r r , d r È É . This is not possible, since both sets contain outcomes of both SSReveal and corrupt (see Table 3), which is not considered in the attack model. In addition, the hash function is assumed to be resistant for collision and preimage attacks.
In order to construct a valid signature s n by the tag or valid response h 1 by the reader, the attacker needs to possess at the same time either d n , r n f gor d r , r r f gdue to the ECDLP as these values require the computation of the session key K = d n + r n ð ÞQ r + R r ð Þ= d r + r r ð ÞR n used to encrypt the message id n , Cert n , r ð Þ . Note that this key is not stored as a separate variable in the protocol in order to avoid exploitation in a session-specific temporary information attack. Also, here, these sets contain outcomes of both SSReveal and corrupt (see Table 3), which is a contradiction in the attack model.
[C2] Anonymity The identity id n is considered as secret key material and is only included in the hash function. Due to the one-way property of the hash function, its value cannot be revealed. It can even not be guessed, since that allows the knowledge of K n 1 , which is hidden in A 1 relying on the strength of the ECDLP.
To find the identity of the tag, the message C should be decrypted. Therefore, either d n , r n f gor d r , r r f gis required due to the ECDHP. However, as mentioned before, this is in contradiction with the attack model, cf Table 3. If also the identity and certificate are guessed, the validity cannot be verified as it requires the knowledge of a random value r , which is included in the encrypted message C.
[C3] Unlinkability As explained in the criteria of anonymity, the identity of the tag cannot be revealed, but the best to be leaked is K n 1 from A 1 , which would threaten the unlinkability feature. However, this is not possible as it requires the knowledge of either r n , K n 2 È É or d r , r r f g, which is not possible, cf Table 3.

Identity-related information is packed in the parameters
C, s n , h 1 f g . From C, nothing can be leaked as explained before. From the second one s n , an attacker can try to verify the signature with a collected public key of the tag (similar to dictionary attack). However, now, the attacker will not be successful as it first needs to find h 2 , which includes the additional random value r, to be able to verify the equation s n G = R n − h 2 Q n . On the other hand, if id n , Cert n f gis leaked, similar to a dictionary attack, together with the session data r, the validity of h 1 can be verified and thus, the tag can be tracked.
[C4] Sessionspecific temporary information Given SSReveal(T)=r n , it still does not result in making a fake message containing A 1 , h 2 , h 1 as also corresponding secret keys K n 1 , K n 2 of the tag need to be known. Also, with additional SSReveal(R)=r r , no fake messages can be constructed.
With SSReveal T ð Þ = r n , r f gand SSReveal R ð Þ = r r f g, no fake messages containing legitimate C, s n , h 1 parameters can be made without knowledge of valid credentials of the tag as it requires the additional usage of either the private key d n of the tag or the private key d R of the reader due to the ECDLP.
[C5] Perfect forward secrecy When the corrupt queries of tag and reader are executed, we are still not able to create a fake message containing A 1 , h 2 , h 1 as also the session-specific information r n or r r should be known to derive the last concatenated value in the hash operation due to the ECDHP. In addition, the identity cannot be tracked as in the computation ofA 1 , temporary session information is included.
Executing the corrupt queries on both reader and tag does not result in additional gain for the attacker as still the temporary session information is required to encrypt the ciphertext for deriving the identity of the tag and for constructing valid hash outcomes. This follows from the ECDHP.
[C6] Replay attacks This attack is avoided thanks to the usage of random numbers, both at the side of the reader and the tag. Even if the attacker replays the random value of the reader in the beginning of the protocol, the tag still chooses another random value, such that the h 1 value also changes. Also, the message of the tag cannot be replayed as it relies on the usage of the random R r sent in the beginning by the reader. Due to the large size p of the space (field size of the curve) in which the random variables are defined, the probability to obtain a collision is following the birthday paradox smaller than n 2 /2p, with n the number of collected variables.
The same reasoning for the protection against replay attack holds for this protocol. Again, random values are used by both reader and tag and should be unique in each call of the protocol. The probability of not being unique is smaller than n 2 /2l, with l the space size in which the randoms are defined and thus equal to the field size.
[C7] Desynchronisation attack Since the identity and key material of the tag remain fixed, there is no desynchronisation possible. The only potential problem might be if the tag has a built-in protection to The similar reasoning as in Scheme 1.1 holds due to the fixed key material of the tag and results in protection against desynchronisation attacks.

Journal of Sensors
After receiving this message, the reader derives K = ðd r + r r ÞR n in order to retrieve ðid n ∥Cert n ∥rÞ = D K ðCÞ = C ⊕ K. Next, it checks the validity of the signature by computing H ðid n ∥Cert n ∥R r ∥R n ∥rÞ = ðh 1 ∥h 2 Þ and checking if the equality s n G = R n − h 2 Q n holds. If so, the reader sends h 1 as a confirmation message to the tag. Else, the protocol is aborted.
If the tag receives the same value h 1 as stored in its memory, the authentication process is successfully executed. The different steps in this protocol are illustrated in Table 2.

Extension.
In the current two versions, the tag receives a random value from the reader but is not able to verify the validity of the request. This will not cause denial-of-service attacks as it is possible to build in a security guideline to block the number of potential requests to a certain threshold.
However, in order to avoid such potential problems, it is possible to replace the first message in both protocols by a message containing the signature of the TTP on the random value generated by the reader. In this way, any reader with a valid signature can send a request to the tag and the tag does not need to store the corresponding public key of the reader.
Let R r be the random value generated by the reader. The reader requests a signature of the TTP on the pair ðR r , Q r Þ, which can be easily realised by the Schnorr signature scheme as also done in Scheme 1.2. Therefore, the TTP chooses a random value r 1 and computes R 1 = r 1 G. The corresponding signature s r = r 1 − HðR r ∥Q r ∥R 1 ∥T i Þd TTP , with T i being the current active time interval, is now sent to the reader. As a consequence, the first transmitted message now consists of ðR r , Q r , R 1 , T i , s r Þ. This signature can be easily verified by the tag by checking if the following equality holds: The tag does not need to prestore the public key of the reader Q r anymore, but only the initialisation timestamp T 0 . It is implemented to accept random values within a certain given time interval from the initial T 0 . There is a trade-off in size of this time interval (cf efficiency) and security as the longer the time interval, the more it can become possible that revoked readers can replay their approved random values. In the case that all readers are trustworthy, the usage of timestamps can even be avoided. Note that for Schemes 1.1 and 1.2, we have assumed a trustworthy reader, as there is only one reader involved. We will call Schemes 1.1 and 1.2 with the extension part also Schemes 2.1 and 2.2.

Security Evaluation
The security will be both informally and formally evaluated.

Informal Security Evaluation.
We now discuss the strength of both protocols with respect to the attack scenarios and the security features defined in Section 3. We also compare the security strength of our scheme with the most relevant related work described in Section 2.
In order to analyze the security, we first summarize the knowledge that the attacker gains following the different attack scenarios [A1-A4] in Table 3, being the results of send, execute, session reveal, and corrupt queries, respectively. We want to note that hr 1 , hr 2 are no session-specific temporary information at the tag side as it is possible to compute K n 1 ⊕ Hððr n + K n 2 ÞðQ r + R r ÞÞ and to take the first 128 bits of the operation as A 1 and the bits 129 till 256 as hr 2 , since K n 1 is considered to be a variable of length 128 bits.
This knowledge can then be exploited in the different attacks, as explained in Table 4.
It can be concluded from Table 4 that both our Schemes 1.1 and 1.2 satisfy the same security features with respect to the above defined criteria [C1-C9]. However, the main difference from a security point of view between both of them is with respect to the resistance against a curious TTP. In Scheme 1.1, with knowledge of the session-specific variables, thus after SSReveal(T), the TTP is able to verify and track the activity of the tag. The TTP can also impersonate the tag as it knows all the security material. Compared to Scheme 1.2, both attacks are not possible if the private key of the tag has been constructed by means of the ECQV mechanism. Consequently, the TTP can never be in the possession of both session data and secret data, like in Scheme 1.1.
In addition, the main added value from a security point of view of Schemes 2.1 and 2.2, including the implementation of the extension in the beginning of the algorithm, is to immediately detect denial-of-service attacks at the tag side. In the case where many invalid requests are sent, it makes sense to include this extension. In addition, it makes the protocol avoid denial-of-service attacks to limit the number of unsuccessful authentication requests by a fixed amount.
[C8] Scalability This scheme is linearly scalable with the amount of sensors stored at the reader side, since the reader has to go linearly over the different records of its database in order to find the matching record.
Since the reader only stores the list of revoked sensors, the system is highly scalable with a complexity limited to the size of the revoked sensors and not the list of legitimate sensors, which is typically considered to be much smaller.
[C9] Denial-ofservice attack The validity of the second and third message can be immediately verified. Only for the first message the tag needs to wait upon the final response in order to decide the legitimacy of the authentication request. However, from the side of the reader, there is no problem as each request can be immediately verified and no sessions need to be stored waiting for approval.
The same protection against denial-of-service attacks holds for Scheme 1.2 as also, here, the first message is the only one which cannot be immediately verified for its legitimacy and this message is sent from the reader to the tag.    Journal of Sensors independent of one particular reader and allows authentication of the tag to a large number of readers. However, it comes of course with an additional communication and computation cost as will be shown in Section 6.
To conclude, we have compared the security of our four protocols with the latest most relevant schemes [29,34,38,43] in literature as discussed in Section 3, considering an attack satisfying the attack scenarios [A1-A4]. We also added two other criteria, as explained above, in order to differentiate our four developed schemes.

(C10) Resistant against curious TTP (C11) Multireader authentication
The comparison is provided in Table 5. As can be seen, our Scheme 2.2 satisfies all the criteria, while the other Schemes 1.1 and 1.2 still satisfy a nice number of criteria. In particular, with respect to [C1-C9], they clearly outperform the state of the art [34,38,43]. Only [29] possesses similar strength as it satisfies resistance in the CK adversary model that is even a stronger requirement, which also attack scenarios [A3] and [A4] can be combined.
Only the second scheme of [43] also offers authentication with respect to multiple readers. With respect to inherent architecture, it is best to compare their proposed scheme with Scheme 2.1 as it also requires the storage of legitimate identities. As can be seen from Table 5, the scheme [43] does not possess sufficient security strength.

Formal Security Evaluation.
Formal verification is a successful approach to provide security assurances by mathematically ascertaining the accuracy of prototypes utilizing a combination of mathematical and logical methods. Such approaches are especially valuable for extracting objective information on the protection and security properties of digital devices.
ProVerif is one of the most common used formal verification tools focusing on security protocols. We refer to [53] for an in-depth survey on the different formal security tools. Pro-Verif is a command line method to automatically evaluate the protection of cryptographic protocols based on the basic description of the protocol by the Prolog rules. In ProVerif, an algorithm is implemented that effectively determines whether or not a fact can be proven by the Prolog rules [13,[54][55][56]. Due to the usage of integration, the state space explosion issue is prevented. Another benefit is that there is no need to restrict the amount of runs of the protocol.
The ProVerif structure is shown in Figure 2. ProVerif uses the protocol paradigm in the extension of the pi calculus with cryptography as data, analogous to the modified pi calculus. It follows a broad range of cryptographic primitives, defined by rewrite codes or equations. ProVerif also uses the protection properties that we want to show as data. Numerous protection features, like anonymity, authentication, and certain empirical equivalence products, can be checked. It instantly converts this knowledge into an internal version of the Horn clauses: the protocol is translated into a collection of Horn clauses, and the protection properties to be proven are translated into the derivability queries for such clauses. ProVerif uses a resolution algorithm with free choice to determine whether a fact can be derived from the clauses. Unless the facts are not derivable, the required protection property shall be identified.
Some more background and the ProVerif modeling are given in Appendix. Also, the results on the proof verification have been explained there. To summarize, the program reveals for the first two schemes a potential flow on the random value R r , which has also been described in the informal security analysis and shown to imply no direct security attack as shown in Appendices A and B. The last two schemes do not reveal any security threats, please see Appendices C and D.

Performance
We now compare the efficiency of our four schemes with respect to computation and communication costs.
6.1. Computation Cost. Our four protocols and the related work of [29,34,38] consist of a combination of xor, hash, and elliptic curve operations. From all these operations, the EC multiplication is the most compute-intensive operation and dominates the total cost of the process. Therefore, we limit our analysis to the comparison of the amount of EC multiplications required by both reader and tag. Denote this number by T M . To give an estimation of the timings, we implemented an EC multiplication with 256 bits, corresponding to a 128 security level, both on a Zolertia RE-  Table 6 compares the number of EC multiplications T M at reader and tag side, together with their corresponding timings. As can be concluded from this table, our Schemes 1.1 and 1.2 are the fastest as they both require only 2 EC multiplications. In addition, Scheme 1.1 also only requires 2 EC multiplications at the reader side and thus has the lowest impact with respect to security operations.

Communication Cost.
We now calculate the length of the transmitted messages sent in the protocols, taking into account a security level of 128 bits. This means that the size of the EC points and the outputs of the hash function should be at least 256 bits in order to avoid all types of collision and preimage attacks. We further consider the length of the identities equal to 128 bits in order to avoid exhaustive search attacks. The number of sent bits is denoted by N S , and the number of received bits by N R from the point of view of the tag. Table 7 summarizes the comparison of the performance with respect to communication costs. It can be concluded that our Scheme 1.1 is outperforming the others with respect to number of bits communicated in the channel. Only [38] is able to establish the authentication in two phases. However, it should be noted that in practice, an additional phase should be added as in their implementation, the tag starts the communication and does not receive an approval of the authentication. In order to effectively obtain mutual authentication, at least three phases are needed. It is clear that Schemes 2.1 and 2.2 have the highest communication cost, but they are also the most generic as they are able to handle different readers in the same protocol.

Conclusion
This paper introduces four highly effective authentication algorithms for client-server (tag-reader) or RFID system based on ECC. The first scheme (v1.1) requires storage of the identities and related key material of all active tags, while the second scheme (v1.2) only needs the list of revoked tags. An additional phase is proposed on both protocols (v2.1 and v2.2) to enable multireader authentication. The main difference in security strength (between .1 and .2 version) is the additional protection against an honest but curious TTP, offered by the second version.
The proposed schemes were compared with five other recent ECC-based protocols for the computational time, communication costs, storage costs, and protection level they offer. The findings reveal that our proposed schemes have small computing overheads, small storage costs for the code, and better protection rates than other related protocols (see Tables 6 and 7). 7.1. ProVerif for Specifications on the Schemes. In [54], the manual of the ProVerif tool includes explanation on the installation, configuration, and programming syntaxes and is provided with rich examples for a good understanding. When writing a file in ProVerif, you model what the honest participants are allowed to do and what you give as knowledge to the attacker. Then, ProVerif checks any possible interaction between the honest participant and the attacker (provided that the attacker actions are bound by the model, e.g., an attacker cannot break the cryptography). After that, if you have specific properties, you need to think how to model them.