Comparison and Feasibility of Various RFID Authentication Methods Using ECC

Radio frequency identification (RFID) is a technology that has grown in popularity and in the applications of use. However, there are major issues regarding security and privacy with respect to RFID technology which have caught the interest of many researchers. There are significant challenges which must be overcome to resolve RFID security and privacy issues. One reason is the constraints attached to the provision of security and privacy in RFID systems. Along with meeting the security and privacy needs of RFID technology, solutions must be inexpensive, practical, reliable, scalable, flexible, inter-organizational, and long-lasting. To make RFID identifiers effective and efficient they must identify the item(s) while resisting attacks aimed at obtaining the tag’s information and compromising the system or making it possible to bypass the protection RFID tags are supposed to provide. Different authentication methods have been proposed, researched, and evaluated in the literature. In this work, we proposed our methodology in evaluating RFID authentication, and a few of the most promising authentication methods are reviewed, compared, and ranked in order to arrive at a possible best choice of protocol to use.


Introduction
RFID wireless technology uses radio frequency signals to communicate between the tags which are attached to objects, and the readers, that identify the objects and are connected to a back-end server. RFID is a technology that has grown in popularity and has found many applications across multiple industries. Most people have seen RFID tags used in their everyday lives but may not have realized what the technology behind them is. Every time we go shopping we see RFID tags, they are on the items we are trying to purchase, from clothing to books to games, and even medicines. Many companies have been using RFID technology to maintain and track their inventory, while others have recently been experimenting with its use for secure entry and access control.
RFID systems have three main parts, the tag, the reader, and the server, as depicted in Figure 1. The server contains the database housing all of the identification information for the tags and the objects to which they are attached. The reader is the part of the system that plays the middleman between the tags and the server. It reads the tags' information and confirms it against what is held on the database of the server. The reader and server in the majority of cases have a wired connection which is considered secure. The tag is the most populous part of the system. There will be numerous tags in a system communicating with multiple readers, all running off of one database. The allure of using RFID is that it does not require line of sight in order to communicate between tag and reader, and multiple tags can be read simultaneously. One use of RFID systems is in loss prevention, where the tags are used to uniquely identify the object they are attached to while providing a measure of security to that object against theft. This makes it a great optional for many Internet of things (IoT) and AI applications. When someone tries to remove the object with an RFID tag from the vicinity, readers near the exit sound an alert if the tag has not been deactivated, only to mention some of the most common applications of RFID.
Another use of the RFID tags has been in stock and inventory control. RFID technology communicates using wireless radio signals, therefore line of sight is not needed for a tag and reader to communicate, unlike barcodes, that require line of sight with a laser reader. Another tremendous advantage over the barcoding is that barcoding requires scanning one item at a time, which is tedious and time-consuming and can also be greatly influenced by human error. RFID tags can simultaneously communicate with a reader that is within range and the reader can read and identify multiple tags simultaneously. As long as each object has been properly tagged, the reader can quickly and easily identify the tagged objects, saving time and lowering the possibility of human error in inventory tracking.
In recent years, the use of RFID technology, specifically in the High Frequency (HF) 13.56 MHz range has received quite a bit of attention. In this range particularly, the NFC standard has been developed and improved. There are five NFC types, each corresponding to different ISO/IEC and JIS standards. Types 1, 2, and 4 are covered under ISO/IEC 14443-A while only Type 4 is covered under both ISO/IEC 14443 A/B. Type 3 NFC is covered by JIS X 6319, and Type 5 by ISO/IEC 15693 (18000-3) [1]. Manufacturers, such as NXP Semiconductor (Newburyport, MA, USA), have pushed NFC forward with their ntag213/215/216 products. Each is Type 2 ISO/IEC 1443 A compliant with memory capacities of 144, 504, and 888 bytes and a data rate of 106 kbps. These NFC cards are ideal for use in access control to improve secure access for enterprises.
However, RFID systems, since they broadcast wirelessly, have downfalls; securing any kind of a wireless system is always a huge concern. Radio signals are omnidirectional and can be picked up by an antenna that can operate on the same frequency. We see this kind of interference all the time. If you have ever listened to the radio and heard walkie-talkie or closed band (CB) radio interference at odd moments, more common nowadays are cell phones near speakers that will produce a static (white noise) type of sound. Even with wireless networks, the signal broadcast goes out in every direction (on most standard antennae). Due to the susceptibility of wireless communications to interference, thus possible security weaknesses, securing RFID communications has become paramount.
In the years of its various industry applications, RFID security has been studied, researched, improved, and the process shall continue. Many authentication protocols for RFID have evolved over the years, but many have failed to accomplish the security goals needed for the application, and some have not only met but surpassed these same security goals. For those that have met the security goals, the biggest question in application comes in the form of cost. What would it cost for this technology to be used? Not that the monetary cost for the system is not a concern, but more so the cost in time of running the system and the cost of the tags needed to secure the system. It would matter more to any organization if the RFID system were affordable, but took a long time to authenticate and identify the tagged objects, in such a case a company can lose customers, due to wait time and incur more One use of RFID systems is in loss prevention, where the tags are used to uniquely identify the object they are attached to while providing a measure of security to that object against theft. This makes it a great optional for many Internet of things (IoT) and AI applications. When someone tries to remove the object with an RFID tag from the vicinity, readers near the exit sound an alert if the tag has not been deactivated, only to mention some of the most common applications of RFID.
Another use of the RFID tags has been in stock and inventory control. RFID technology communicates using wireless radio signals, therefore line of sight is not needed for a tag and reader to communicate, unlike barcodes, that require line of sight with a laser reader. Another tremendous advantage over the barcoding is that barcoding requires scanning one item at a time, which is tedious and time-consuming and can also be greatly influenced by human error. RFID tags can simultaneously communicate with a reader that is within range and the reader can read and identify multiple tags simultaneously. As long as each object has been properly tagged, the reader can quickly and easily identify the tagged objects, saving time and lowering the possibility of human error in inventory tracking.
In recent years, the use of RFID technology, specifically in the High Frequency (HF) 13.56 MHz range has received quite a bit of attention. In this range particularly, the NFC standard has been developed and improved. There are five NFC types, each corresponding to different ISO/IEC and JIS standards. Types 1, 2, and 4 are covered under ISO/IEC 14443-A while only Type 4 is covered under both ISO/IEC 14443 A/B. Type 3 NFC is covered by JIS X 6319, and Type 5 by ISO/IEC 15693 (18000-3) [1]. Manufacturers, such as NXP Semiconductor (Newburyport, MA, USA), have pushed NFC forward with their ntag213/215/216 products. Each is Type 2 ISO/IEC 1443 A compliant with memory capacities of 144, 504, and 888 bytes and a data rate of 106 kbps. These NFC cards are ideal for use in access control to improve secure access for enterprises.
However, RFID systems, since they broadcast wirelessly, have downfalls; securing any kind of a wireless system is always a huge concern. Radio signals are omnidirectional and can be picked up by an antenna that can operate on the same frequency. We see this kind of interference all the time. If you have ever listened to the radio and heard walkie-talkie or closed band (CB) radio interference at odd moments, more common nowadays are cell phones near speakers that will produce a static (white noise) type of sound. Even with wireless networks, the signal broadcast goes out in every direction (on most standard antennae). Due to the susceptibility of wireless communications to interference, thus possible security weaknesses, securing RFID communications has become paramount.
In the years of its various industry applications, RFID security has been studied, researched, improved, and the process shall continue. Many authentication protocols for RFID have evolved over the years, but many have failed to accomplish the security goals needed for the application, and some have not only met but surpassed these same security goals. For those that have met the security goals, the biggest question in application comes in the form of cost. What would it cost for this technology to be used? Not that the monetary cost for the system is not a concern, but more so the cost in time of running the system and the cost of the tags needed to secure the system. It would matter more to any organization if the RFID system were affordable, but took a long time to authenticate and identify the tagged objects, in such a case a company can lose customers, due to wait time and incur more costs due to employee productivity, or lack thereof. However, an organization may be willing to pay a little more for an RFID system that is secure and runs quickly enough to not disrupt the natural flow of business. One more concern is the size of tags. The more sophisticated circuit we use the bigger the tag is. The types of RFID tags used will vary based on company needs, if the company is looking to use low frequency (LF) low capacity RFID tags, the use of elliptic curve cryptography protocols may well exceed the available memory capacity on the tags. In those instances, other lightweight protocols that can preserve anonymity while providing secure authentication such as those proposed by Gope in [2,3] may be a more feasible choice. For use with NFC cards, such as the ntag21x's mentioned above, which include ECC for originality signatures, and can be programmed as needed, exploring multiple ECC authentication protocols for use in secure authentication for access control is a natural approach.
For the purposes of this paper, we focus on public key cryptography, specifically Elliptic Curve Cryptography (ECC). Our goal in this paper is to survey and compare seven different RFID ECC authentication protocols based on their computational costs, communication costs, storage costs, security features, and ability to resist various attacks. A successful RFID protocol must be lightweight, secure, easy to implement, and able to be scaled up or down based on company needs. In all the research for secure communications, many methods have been developed. The seven protocols compared in this paper were selected because they each incorporate randomization, secure authentication, and are lightweight. All of the studied protocols use Elliptic Curve Cryptography to secure the communication between tag and reader, though each takes a slightly different approach. To compare each protocol on the even ground we make the following assumptions: 1.
The connection between the reader and server is wired and secure, so the focus is on communication between tag and reader.

2.
NIST secp160R1 a 160-bit ECC base is used for each protocol.

3.
Scalar multiplication speed, the time needed to perform a 160-bit ECC calculation on a 5 MHz tag is 0.064 s.

4.
Any XOR or Scalar addition calculation time is negligible and therefore not factored into cost calculations.
The RFID tags have a memory capacity of 504 bytes.
The testing of each protocol compared in this paper is based on the original authors' testing methodology and results, which were then taken and applied using the NIST secp160R1 standard and recalculated to compare each protocol on equal terms. With these assumptions in place, the rest of the paper is organized as follows:

•
In Section 2, related work on ECC studies is reviewed.

•
In Section 3, the various methods studied will be summarized.

•
In Section 4, each of the methods will be compared in three cost areas: computational, communication, and storage cost; and two security areas: security features and attack resistance.

•
In Section 5, each of the reviewed protocols will be ranked based on the 5 criteria covered in Section 4.

•
In Section 6, we discuss the results of the data comparisons and provide an overall rank of the protocols. We will conclude and determine which of the studied methods provide the best-case implementation for RFID authentication.

Related Work
Many studies have been conducted over the last decade on the use of RFID over standard barcodes. The advantages of using RFID tags in place of barcodes greatly outweighed their shortcomings. However, with the advancement of technology over the last 10 years and its forward progress, the weaknesses inherent in RFID have become more problematic. Some of these weaknesses as stated in [4] are replay attacks, impersonation attacks, brute-force attacks, denial-of-service attacks, man-in-the-middle attacks, and tracking attacks. To address these weaknesses various methods of encryption and authentication have been researched. All the studies researched are conclusive in the use of elliptic curve cryptography (ECC) in providing the most effective base for RFID authentication. Each covers different ECC application methods to meet their goal.
ECC protocols, such as elliptic curve discrete logarithm problem (ECDLP) and elliptic curve factorization problem (ECFP), with random numbers generated to produce keys by both the tag and receiver are investigated in [4][5][6][7][8][9][10][11][12][13][14][15][16][17][18]. These random numbers are included in the calculations to create a key and send it to the receiving device that responds with its own challenge based on the information received to provide mutual authentication. Zheng et al. [5] use an ECC protocol similar to the others but with an elliptic curve Diffie-Hellman (ECDH) key agreement protocol used between the tag and reader. Each study demonstrates that using only one ECC protocol will provide only one-way authentication and leaves the overall system vulnerable. With the addition of a second ECC protocol, two-way authentication has been proven to be established and therefore providing better security to the system overall. The differences in the coupling of the protocols lead to different efficiency and security improvements in the system. For this survey, we will compare the protocols suggested by Alamr et al. [4], Liao et al. [18], Zheng et al. [5], Zhang et al. [13], Zhoa [15], Jin et al. [16], and Dinarvand [17]. While surveying the literature, we believe these articles have provided the top seven methods for RFID authentication using ECC. In addition, we were able to set up a similar test-bed for all the proposed methods so we can have accurate comparisons. Our proposed test-bed could be applied to many other methods as well.
As we compare each protocol we will focus on the aspects of computational costs, storage costs, communication costs (traffic), security features, and attack resistance. The security features we are looking for are mutual authentication, confidentiality, anonymity, availability, scalability, forward security, location privacy, and data integrity. Additionally, we are comparing resistance to the following types of attacks: man-in-the-middle (MIMA), replay, impersonation, key compromise, location tracking, denial-of-service (DoS), cloning, server spoofing, and desynchronization. A comparison of how each of these studied protocols has met the requirements and aspects has been conducted to draw a conclusion as to which ECC protocol combination will be most effective and efficient in providing a low-cost, lightweight, secure RFID system.

ECC Methods
Each of the protocols uses the same base elements through their calculations, however, authentications vary. The list below describes the common variables and values of each protocol: P: base point on elliptical curve (320-bits) S S : secret key of the server/reader (160-bits) S P : public key of the server/reader (320-bits) T S : secret key of the tag (160-bits) T P : public key of the tag (320-bits) A S : authentication value of server/reader (320-bits) A T : authentication value of tag (320-bits) r 1 , r 2 , r 3 : randomly generated numbers (160-bits each) T: 1000, the sample number of tags in the system for comparison.
In the Alamr et al. [4] protocol the server chooses a random number for S S and T S and calculates S P and T P , respectively. From here, the protocol takes five steps to authenticate between the tag and reader undergoing four scalar multiplications on the tag side and five on the reader/server side, see Figure 2 below. In step 1, the server generates a random number r 1 , then calculates R 1 = r 1 ×P and sends R 1 to the tag. In step 2, the tag receives R 1 from the server. The tag then generates a random number r 2 and calculates R 2 = r 2 ×P. The tag also calculates two secret keys SK 1T = T P ×R 1 and SK 2T = r 2 ×R 1 , then encrypts the key as C 1 = SK 1T + SK 2T and sends R 2 and C 1 to the server. The server in step 3 receives R 2 and C 1 then calculates two secret keys of its own, SK 1S = r 1 ×T P and SK 2S = r 1 ×R 2 then calculates X = SK 1S + SK 2S . The server then compares X and C 1 , if they are not equal the tag is not authenticated, and the session stops, otherwise, the server calculates C 2 = R 2 ×S S , generates another random number r 3 and calculates R 3 = r 3 ×P to be used for key agreement. The server then sends C 2 and R 3 to the tag. The tag receives C 2 and R 3 in step 4 then computes Y = r 2 ×S P . The tag then compares Y and C 2 , if they are not equal the server is not authenticated, and the session stops, otherwise, the server is authenticated, and both the tag and server set their key agreement in step 5. In step 5 both the tag and the server set their key agreements as TK AG = r 2 ×R 3 and SK AG = r 3 ×R 2 . These steps require communicating two scalar products from tag to reader and three scalar products from reader to tag. The tag stores its key pair and the system parameters for a total of 1920-bits, the reader/server stores its key pair, the system parameters, and the T P for each tag. This equates to 1120 + 320T bits. random number r3 and calculates R3 = r3P to be used for key agreement. The server then sends C2 and R3 to the tag. The tag receives C2 and R3 in step 4 then computes Y = r2SP. The tag then compares Y and C2, if they are not equal the server is not authenticated, and the session stops, otherwise, the server is authenticated, and both the tag and server set their key agreement in step 5. In step 5 both the tag and the server set their key agreements as TKAG = r2R3 and SKAG = r3R2. These steps require communicating two scalar products from tag to reader and three scalar products from reader to tag. The tag stores its key pair and the system parameters for a total of 1920-bits, the reader/server stores its key pair, the system parameters, and the TP for each tag. This equates to 1120 + 320T bits. The Liao et al. [18] protocol has the server set the domain parameters for both the server/reader and the tag. It chooses random numbers for SS and TS and calculates SP and TP respectively. It has a 4-step authentication process consisting of five scalar multiplications for each the tag and the reader/server, see Figure 3 below. In step 1 the server generates a random number r1, calculates R1 = r1P, and sends R1 to the tag. In step 2 the tag receives R1, generates a random number r2, calculates R2 = r2P, calculates two temporary secret keys: TKT1 = r2R1 and TKT2 = r2SP, and sets its authenticator AT = TP + TKT1 + TkT2. The tag then sends AT and R2 to the server. For step 3 the server receives AT and The Liao et al. [18] protocol has the server set the domain parameters for both the server/reader and the tag. It chooses random numbers for S S and T S and calculates S P and T P respectively. It has a 4-step authentication process consisting of five scalar multiplications for each the tag and the reader/server, see Figure 3 below. In step 1 the server generates a random number r 1 , calculates R 1 = r 1 ×P, and sends R 1 to the tag. In step 2 the tag receives R 1 , generates a random number r 2 , calculates R 2 = r 2 ×P, calculates two temporary secret keys: TK T1 = r 2 ×R 1 and TK T2 = r 2 ×S P , and sets its authenticator A T = T P + TK T1 + Tk T2 . The tag then sends A T and R 2 to the server. For step 3 the server receives A T and R 2 from the tag, computes two temporary secret keys of its own: TK S1 = r 1 ×R 2 and TK S2 = S S ×R 2 , and then computes T P as A T − TK S1 − TK S2 . If T P is in the server's database then the tag is authenticated, otherwise, the session stops. If the tag is authenticated, then the server sets its authenticator A S = T S ×R 2 + r 1 ×T P and sends A S to the tag. Finally, in step 4 the tag receives A S and compares A S to r 2 ×T P + T S ×R 1 , if they are equal the server is authenticated, otherwise the session stops. For this protocol, there are two scalar products each, communicated from the tag to the reader/server and from the reader/server to the tag. In this protocol the tag stores its key pair, the reader/server's public key, and the domain parameters totaling 1920-bits, whereas, the reader/server stores its key pair, the system parameters, and the key pair for each tag, equaling 1280 + 800T bits. TSR2 + r1TP and sends AS to the tag. Finally, in step 4 the tag receives AS and compares AS to r2TP + TSR1, if they are equal the server is authenticated, otherwise the session stops. For this protocol, there are two scalar products each, communicated from the tag to the reader/server and from the reader/server to the tag. In this protocol the tag stores its key pair, the reader/server's public key, and the domain parameters totaling 1920-bits, whereas, the reader/server stores its key pair, the system parameters, and the key pair for each tag, equaling 1280 + 800T bits. The Zheng et al. [5] protocol includes an ID in addition to the common variables listed above. In this protocol, the server and tag each choose a random number on their own that is assigned as their private keys, the tag's ID is the same as its TP. There is a 5-step authentication process in this protocol with three scalar multiplications for the tag and four for the reader/server, see Figure 4 below. In step 1 the server generates a random number r1, calculates R1 = r1P, and sends R1 to the tag. In step 2 the tag receives R1, generates a random number r2, and calculates R2 = r2P. The tag also computes two authenticators AT = TP + r2SP and AT' = TS*R1 − r2R1, then sends R2, AT, and AT' to the server. In step 3 the server receives R2, AT, and AT'. The server then calculates TP from AT − SSR2 and finds the The Zheng et al. [5] protocol includes an ID in addition to the common variables listed above. In this protocol, the server and tag each choose a random number on their own that is assigned as their private keys, the tag's ID is the same as its T P . There is a 5-step authentication process in this protocol with three scalar multiplications for the tag and four for the reader/server, see Figure 4 below. In step 1 the server generates a random number r 1 , calculates R 1 = r 1 ×P, and sends R 1 to the tag. In step 2 the tag receives R 1 , generates a random number r 2 , and calculates R 2 = r 2 ×P. The tag also computes two authenticators A T = T P + r 2 ×S P and A T ' = T S *R 1 − r 2 ×R 1 , then sends R 2 , A T , and A T ' to the server. In step 3 the server receives R 2 , A T , and A T '. The server then calculates T P from A T − S S ×R 2 and finds the corresponding T P in its database. Then the server compares A T ' to T S ×r 1 − R 2 r 1 , if they are equal then the tag is authenticated, and the protocol continues, otherwise, the session stops. In step 4 the server calculates its authenticator A S = S S ×R 2 − r 1 *R 2 and sends A S to the tag. For step 5 the tag receives A S and compares it to r 2 ×S P − r 2 ×R 1 , if they are equal the server is authenticated, otherwise, the session stops. There are two scalar products each exchanged between the reader/server and the tag in this protocol. The tag stores the system parameters along with the tag's key pair and ID and the server/reader's public key totaling 2080-bits, while the reader/server stores the system parameters, the reader/server's key pair, and the ID for each tag which equates to 1760 + 320T bits. protocol. The tag stores the system parameters along with the tag's key pair and ID and the server/reader's public key totaling 2080-bits, while the reader/server stores the system parameters, the reader/server's key pair, and the ID for each tag which equates to 1760 + 320T bits. The Zhang et al. [13] protocol was an improvement on ECDLP-based Random Access Control (EC-RAC) proposed by Lee et al. [14]. This protocol, like the original, has two steps for authentication. Both the server/reader and tag generate random numbers, the tag performs four scalar multiplications through the authentication process while the reader/server performs two, see Figure  5 below. In step 1 the server generates a random number r1 and sends r1 to the tag. In step 2 the tag receives r1, generates two random numbers r2 and r3, then checks r1. If r1 = 0 then the session stops, otherwise the tag computes X1' = x1 + r3, where x1 and x2 are the tags secret keys. The tag also computes three authenticators: AT1 = r2P, AT2 = (r2 + X1') Y, and AT3 = r2x1 + r1x2, then sends AT1, AT2, AT3, and r3 to the server. For step 3, the server receives AT1, AT2, AT3, and r3 then calculates y −1 AT2 − AT1 = X1'P, remembering that X1'P = (x1 + r3). The server then searches its database for x1 and x2 paired with X1' and retrieves the corresponding tag information. Finally, the server compares (AT3P − x1*AT1) x2 −1 to X2, if they are equal the tag is authenticated, otherwise the session is stopped. In this protocol, the communication between the reader/server and the tag is a 160-bit randomly-generated-number, while the tag sends back two scalar products and two 160-bit number values. The tag stores the system parameters along with the tag's key pair, and the reader/server's public key for a total of 1600- The Zhang et al. [13] protocol was an improvement on ECDLP-based Random Access Control (EC-RAC) proposed by Lee et al. [14]. This protocol, like the original, has two steps for authentication. Both the server/reader and tag generate random numbers, the tag performs four scalar multiplications through the authentication process while the reader/server performs two, see Figure 5 below. In step 1 the server generates a random number r 1 and sends r 1 to the tag. In step 2 the tag receives r 1 , generates two random numbers r 2 and r 3 , then checks r 1 . If r 1 = 0 then the session stops, otherwise the tag computes X 1 ' = x 1 + r 3 , where x 1 and x 2 are the tags secret keys. The tag also computes three authenticators: A T1 = r 2 ×P, A T2 = (r 2 + X 1 ') ×Y, and A T3 = r 2 x 1 + r 1 x 2 , then sends A T1 , A T2 , A T3 , and r 3 to the server. For step 3, the server receives A T1 , A T2 , A T3 , and r 3 then calculates y −1 ×A T2 − A T1 = X 1 '×P, remembering that X 1 '×P = (x 1 + r 3 ). The server then searches its database for x 1 and x 2 paired with X 1 ' and retrieves the corresponding tag information. Finally, the server compares (A T3 ×P − x 1 *A T1 ) ×x 2 −1 to X 2 , if they are equal the tag is authenticated, otherwise the session is stopped. In this protocol, the communication between the reader/server and the tag is a 160-bit randomly-generated-number, while the tag sends back two scalar products and two 160-bit number values. The tag stores the system parameters along with the tag's key pair, and the reader/server's public key for a total of 1600-bits, while the reader/server stores the system parameters, its key pair, and the key pair of each tag equating to 1440 + 480T. Zhao's [15] protocol has the reader/server select the domain parameters along with a random number to be used as its private key, while also selecting random numbers for each tag to be used as the tag's private key; from these the public keys are calculated. Throughout its 4-step authentication process, the tag and reader/server perform five scalar multiplications each, see Figure 6 below. In step 1 the server generates a random number r1, calculates R1 = r1P, and sends R1 to the tag. In step 2 the tag receives R1, generates a random number r2, and calculates R2 = r2P, which it also sees as (kx,ky). The tag calculates two temporary keys: TKT1 = (r2kx) R1 and TKT2 = (r2ky) SP, from these the tag's authenticator is computed as AT = TP + TKT1 + TKT2, and the tag sends AT and R2 to the server. The server receives AT and R2 in step 3 then calculates two temporary keys of its own: TKS1 = (r1kx) R2 and TKS2 = (SSky). The server uses these to determine TP from AT − TKS1 − TKS2 and searches its database for TP. If TP is not in the database the session is stopped, otherwise, the tag is authenticated, the server retrieves the tag's corresponding information and calculates its authenticator AS = TSR2 + r1TP and sends AS to the tag. In step 4 the tag receives AS and compares it to r2TP + TSR2, if they are equal, the server is authenticated, otherwise, the session is terminated. The tag communicates two scalar products to the reader/server and the reader/server communicates two scalar products to the tag. The tag in this protocol stores the system parameters, its public and private keys, and the reader/server's public key totaling 1760-bits. The reader/server stores the system parameters, its own public, and private keys, along with the key pair for each tag, which is 1120 + 480T bits.
In the Jin et al. [16] protocol, like many of the other protocols, the reader/server selects the domain parameters and chooses random numbers to be used as the reader/server's private key and the private keys for each of the tags. This 4-step authentication process yields four scalar multiplications from the tag and three scalar multiplications from the reader/server, see Figure 7 Zhao's [15] protocol has the reader/server select the domain parameters along with a random number to be used as its private key, while also selecting random numbers for each tag to be used as the tag's private key; from these the public keys are calculated. Throughout its 4-step authentication process, the tag and reader/server perform five scalar multiplications each, see Figure 6 below. In step 1 the server generates a random number r 1 , calculates R 1 = r 1 ×P, and sends R 1 to the tag. In step 2 the tag receives R 1 , generates a random number r 2 , and calculates R 2 = r 2 ×P, which it also sees as (k x ,k y ). The tag calculates two temporary keys: TK T1 = (r 2 ×k x ) ×R 1 and TK T2 = (r 2 ×k y ) ×S P , from these the tag's authenticator is computed as A T = T P + TK T1 + TK T2 , and the tag sends A T and R 2 to the server. The server receives A T and R 2 in step 3 then calculates two temporary keys of its own: TK S1 = (r 1 ×k x ) ×R 2 and TK S2 = (S S ×k y ). The server uses these to determine T P from A T − TK S1 − TK S2 and searches its database for T P . If T P is not in the database the session is stopped, otherwise, the tag is authenticated, the server retrieves the tag's corresponding information and calculates its authenticator A S = T S ×R 2 + r 1 ×T P and sends A S to the tag. In step 4 the tag receives A S and compares it to r 2 ×T P + T S ×R 2 , if they are equal, the server is authenticated, otherwise, the session is terminated. The tag communicates two scalar products to the reader/server and the reader/server communicates two scalar products to the tag. The tag in this protocol stores the system parameters, its public and private keys, and the reader/server's public key totaling 1760-bits. The reader/server stores the system parameters, its own public, and private keys, along with the key pair for each tag, which is 1120 + 480T bits.
The server receives AT and R2 in step 3, sets its temporary key as STK = SSR2, then compares TID to AT ⊕ H1(R1,STK). If TID is not in the server's database the session is terminated, otherwise, the tag is authenticated and the server uses another predetermined hash function, H2, to calculate e = H2(R1,R2,TID) and s ≡ SSe + r1 mod n. The server then sends s to the tag. In the 4th and final step the tag receives s from the server, calculates e = H2(R1,R2,TID) and checks if sP ≡ SPe + R1 mod n if they are not the session is stopped, otherwise, the server is authenticated. In this protocol, the tag sends two scalar products to the reader/server throughout the authentication process and the reader/server sends two scalar products to the tag. The tags store the domain parameters along with its key pair and the reader/server's public key for 1600-bits of storage; the reader/server stores the domain parameters, its key pair, and the identifier for each tag leading to 1120 + 320T bits of storage.
The Dinarvand et al. [17] protocol has a more complex approach. The reader/server selects the domain parameters and a random number for the reader/server's private key. It also selects random points on the elliptic for each tag to serve as the tag's unique ID, it also selects two random numbers for each tag to serve as the tag's pseudonym and the shared secret key between the tag and reader/server respectively. Throughout the five authentication steps, there are three scalar multiplications for each the tag and reader/server, see Figure 8 below. In the Jin et al. [16] protocol, like many of the other protocols, the reader/server selects the domain parameters and chooses random numbers to be used as the reader/server's private key and the private keys for each of the tags. This 4-step authentication process yields four scalar multiplications from the tag and three scalar multiplications from the reader/server, see Figure 7 below. In step 1 the server generates a random number r 1 , calculates R 1 = r 1 ×P, and sends R 1 to the tag. In step 2 the tag receives R 1 , generates a random number r 2 , calculates R 2 = r 2 ×P, sets a temporary key T TK = r 2 ×S P , and uses these values with a predetermined hash function, H 1 , to calculate its authenticator, A T = T ID ⊕ H 1 (R 1 ,T TK ) and sends A T and R 2 to the server.
The server receives A T and R 2 in step 3, sets its temporary key as S TK = S S ×R 2 , then compares T ID to A T ⊕ H 1 (R 1 ,S TK ). If T ID is not in the server's database the session is terminated, otherwise, the tag is authenticated and the server uses another predetermined hash function, H 2 , to calculate e = H 2 (R 1 ,R 2 ,T ID ) and s ≡ S S ×e + r 1 mod n. The server then sends s to the tag. In the 4th and final step the tag receives s from the server, calculates e = H 2 (R 1 ,R 2 ,T ID ) and checks if s×P ≡ S P ×e + R 1 mod n if they are not the session is stopped, otherwise, the server is authenticated. In this protocol, the tag sends two scalar products to the reader/server throughout the authentication process and the reader/server sends two scalar products to the tag. The tags store the domain parameters along with its key pair and the reader/server's public key for 1600-bits of storage; the reader/server stores the domain parameters, its key pair, and the identifier for each tag leading to 1120 + 320T bits of storage. In step 1 the server generates a random number r1, calculates R1 = r1P, and sends R1 to the tag. In step 2 the tag receives R1, generates a random number r2, calculates R2 = r2P, then sends R2 and its IDS (tag pseudonym) to the server. In step 3 the server receives R2 and IDS from the tag and searches its database for the IDS. If the IDS is not in its database the session is terminated, otherwise, the server retrieves the corresponding shared secret key, K, and tag ID, TID. The server then calculates two temporary secret keys: STK1 = r1KR2 and STK2 = SSKR2. These are used to set its authenticator AS = STK1 ⊕ STK2 ⊕ TID and then send AS to the tag. In step 4 the tag receives AS, calculates two temporary secret keys: TTK1 = r2KR1 and TTK2 = r2KSP. The tag then compares TID' to TTK1 ⊕ TTK2 ⊕ AS. If they are not equal the session is stopped, otherwise, the server is authenticated. The tag then calculates its authenticator, AT = TID' ⊕ 2TTK1 ⊕ 2TTK2 and sends AT to the server. In the 5th and final step, the server receives AT and compares it to TID ⊕ 2STK1 ⊕ 2STK2. If they are not equal the session is terminated, otherwise, the tag is authenticated. The tag sends two scalar products to the reader/server; the reader/server sends two scalar products and a randomly generated 160-bit number to the tag in this protocol. The tag stores the system parameters, its unique ID, the reader/server's public key, and their shared secret key for 1760-bits of storage. The reader/server stores the system parameters, its key pair, each tag's unique ID, pseudonym, and shared secret key totaling 1120 + 800T bits of storage. The Dinarvand et al. [17] protocol has a more complex approach. The reader/server selects the domain parameters and a random number for the reader/server's private key. It also selects random points on the elliptic for each tag to serve as the tag's unique ID, it also selects two random numbers for each tag to serve as the tag's pseudonym and the shared secret key between the tag and reader/server respectively. Throughout the five authentication steps, there are three scalar multiplications for each the tag and reader/server, see Figure 8 below.
In step 1 the server generates a random number r 1 , calculates R 1 = r 1 ×P, and sends R 1 to the tag. In step 2 the tag receives R 1 , generates a random number r 2 , calculates R 2 = r 2 ×P, then sends R 2 and its IDS (tag pseudonym) to the server. In step 3 the server receives R 2 and IDS from the tag and searches its database for the IDS. If the IDS is not in its database the session is terminated, otherwise, the server retrieves the corresponding shared secret key, K, and tag ID, T ID . The server then calculates two temporary secret keys: S TK1 = r 1 ×K×R 2 and S TK2 = S S ×K×R 2 . These are used to set its authenticator A S = S TK1 ⊕ S TK2 ⊕ T ID and then send A S to the tag. In step 4 the tag receives A S , calculates two temporary secret keys: T TK1 = r 2 ×K×R 1 and T TK2 = r 2 ×K×S P . The tag then compares T ID ' to T TK1 ⊕ T TK2 ⊕ A S . If they are not equal the session is stopped, otherwise, the server is authenticated. The tag then calculates its authenticator, A T = T ID ' ⊕ 2×T TK1 ⊕ 2×T TK2 and sends A T to the server. In the 5th and final step, the server receives A T and compares it to T ID ⊕ 2×S TK1 ⊕ 2×S TK2 . If they are not equal the session is terminated, otherwise, the tag is authenticated. The tag sends two scalar products to the reader/server; the reader/server sends two scalar products and a randomly generated 160-bit number to the tag in this protocol. The tag stores the system parameters, its unique ID, the reader/server's public key, and their shared secret key for 1760-bits of storage. The reader/server stores the system parameters, its key pair, each tag's unique ID, pseudonym, and shared secret key totaling 1120 + 800T bits of storage.

ECC Comparisons
In this section, we provide various comparisons between each of the seven protocols. Table 1 shows the number of scalar multiplications for the tag and reader for each protocol and calculates the total computation time based on the aforementioned assumption of 64 ms per scalar multiplication.

ECC Comparisons
In this section, we provide various comparisons between each of the seven protocols. Table 1 shows the number of scalar multiplications for the tag and reader for each protocol and calculates the total computation time based on the aforementioned assumption of 64 ms per scalar multiplication. Security features are vital to any authentication protocol. Table 4 shows each protocol and which security features are provided by the protocol. The security features were verified based on the original authors' proofs and comparisons made in some of the other researched studies. Only 3 of the 7 protocols provide all the listed security features, Liao et al. [18], Zheng et al. [5], and Dinarvand et al. [17].
In addition to the security features, the protocol must be able to resist multiple types of attacks so that the system will not be compromised. The attack resistances were verified based on the original authors' proofs and comparisons made in the other researched studies. Table 5 shows each protocol and which types of attack they can resist. In this table a yes means that the protocol can resist that specified attack type.
Based on the comparisons made in Tables 1-5 the next section ranks each of the protocols; there are rankings for each protocol based on costs and security.

ECC Rankings
All of the rankings in this section look at the tables covered in Section 4 and sort orders the protocols based on their computational, communication, and storage costs on both the tag and the reader/server. Additionally, the ranking has been done based on the number of security features met and the number of attacks the protocol can resist.
Tables 6 and 7 below show the total computational time for each protocol and rank them from lowest computational time to highest; Table 6 shows the rankings for the tag while Table 7 shows the rankings for the reader/server computational costs. Table 6. Ranking based on tag computational cost.

Protocol
Total Tag Calculation Time (ms) Rank Order