# A Highly Efficient ECC-Based Authentication Protocol for RFID

Authors: Hasnae Lamrani Alaoui; Abdellatif El Ghazi; Mustapha Zbakh; Abdellah Touhafi; An Braeken
Journal: Journal of Sensors
 (2021)

---

## Abstract

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.


---

## Body

## 1. 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 Figure1, 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.Figure 1
An example of an RFID authentication system.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 Figure1, 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.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 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, theProVerif [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.


## 2. 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–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–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–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–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 TKt1,TKt2 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–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 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.


## 3. Background

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


### 3.1. Cryptographic Operations

#### 3.1.1. Low-Cost Operations

The concatenation and xor operation of two messagesM1 and M2 is denoted by M1∥M2 and M1⊕M2, respectively. We denote the symmetric encryption, like AES128, using a symmetric shared key K of message M by C=EKM and the corresponding decryption by M=DKC. 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].


#### 3.1.2. Hash Functions

For a one-way hash operation, we will use the latest SHA3 standard [50] and in particular the SHAKE128M,d function on message M with variable input size and variable output size d. This function has a proven resistance of at least mind/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 SHAKE128M,d as HM.


#### 3.1.3. 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 fieldsFp. The E25519 curve [51] over the prime field p=2255−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 P1+P2 and multiplication by rP having r∈Fq 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.


#### 3.1.4. 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 bydTTP,QTTP. The different steps in the derivation of the key pair dn,Qn for an entity with identity idn are as follows. First, the entity sends its identity idn, together with an EC point Ri=riG, where ri is a randomly chosen variable. Next, also, the TTP chooses a random rT and computes RT=rTG. The certificate is then defined by Certn=Ri+RT. Next, an auxiliary value r=HCertn∥idnrT+dTTP is computed. The pair r,Certn is sent to the entity idn. The private key dn can now be derived as dn=HCertn∥idnri+r. Only if Qn=dnG corresponds with HCertn∥idnCertn+QTTP the entity approves the key pair dn,Qn and stores it in its memory. Note that this last derivation
(1)Qn=HCertn∥idnCertn+QTTPalso corresponds to the operation, required to be executed by an outsider who is in the possession of the certificate Certn and the identity idn.


### 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 that this can be simultaneously at the reader and tag at the same timeThe 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


## 3.1. Cryptographic Operations

### 3.1.1. Low-Cost Operations

The concatenation and xor operation of two messagesM1 and M2 is denoted by M1∥M2 and M1⊕M2, respectively. We denote the symmetric encryption, like AES128, using a symmetric shared key K of message M by C=EKM and the corresponding decryption by M=DKC. 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].


### 3.1.2. Hash Functions

For a one-way hash operation, we will use the latest SHA3 standard [50] and in particular the SHAKE128M,d function on message M with variable input size and variable output size d. This function has a proven resistance of at least mind/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 SHAKE128M,d as HM.


### 3.1.3. 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 fieldsFp. The E25519 curve [51] over the prime field p=2255−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 P1+P2 and multiplication by rP having r∈Fq 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.


### 3.1.4. 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 bydTTP,QTTP. The different steps in the derivation of the key pair dn,Qn for an entity with identity idn are as follows. First, the entity sends its identity idn, together with an EC point Ri=riG, where ri is a randomly chosen variable. Next, also, the TTP chooses a random rT and computes RT=rTG. The certificate is then defined by Certn=Ri+RT. Next, an auxiliary value r=HCertn∥idnrT+dTTP is computed. The pair r,Certn is sent to the entity idn. The private key dn can now be derived as dn=HCertn∥idnri+r. Only if Qn=dnG corresponds with HCertn∥idnCertn+QTTP the entity approves the key pair dn,Qn and stores it in its memory. Note that this last derivation
(1)Qn=HCertn∥idnCertn+QTTPalso corresponds to the operation, required to be executed by an outsider who is in the possession of the certificate Certn and the identity idn.


## 3.1.1. Low-Cost Operations

The concatenation and xor operation of two messagesM1 and M2 is denoted by M1∥M2 and M1⊕M2, respectively. We denote the symmetric encryption, like AES128, using a symmetric shared key K of message M by C=EKM and the corresponding decryption by M=DKC. 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].


## 3.1.2. Hash Functions

For a one-way hash operation, we will use the latest SHA3 standard [50] and in particular the SHAKE128M,d function on message M with variable input size and variable output size d. This function has a proven resistance of at least mind/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 SHAKE128M,d as HM.


## 3.1.3. 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 fieldsFp. The E25519 curve [51] over the prime field p=2255−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 P1+P2 and multiplication by rP having r∈Fq 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.


## 3.1.4. 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 bydTTP,QTTP. The different steps in the derivation of the key pair dn,Qn for an entity with identity idn are as follows. First, the entity sends its identity idn, together with an EC point Ri=riG, where ri is a randomly chosen variable. Next, also, the TTP chooses a random rT and computes RT=rTG. The certificate is then defined by Certn=Ri+RT. Next, an auxiliary value r=HCertn∥idnrT+dTTP is computed. The pair r,Certn is sent to the entity idn. The private key dn can now be derived as dn=HCertn∥idnri+r. Only if Qn=dnG corresponds with HCertn∥idnCertn+QTTP the entity approves the key pair dn,Qn and stores it in its memory. Note that this last derivation
(1)Qn=HCertn∥idnCertn+QTTPalso corresponds to the operation, required to be executed by an outsider who is in the possession of the certificate Certn and the identity idn.


## 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 that this can be simultaneously at the reader and tag at the same timeThe 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


## 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 that this can be simultaneously at the reader and tag at the same timeThe 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


## 4. 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.


### 4.1. Basic Schemes

#### 4.1.1. Scheme 1.1: With Storage at Reader Side

(1) Initialisation Phase. Each tag receives from the TTP the public key of the reader Qr=drG to which it needs to authenticate to and the tuple idn,Kn1,Kn2, representing a unique identity idn and two corresponding unique keys Kn1,Kn2, respectively. These parameters are securely stored on the tag. The reader receives from the TTP the list of legitimate idn,Kn1,Kn2n, which are securely stored in its database (DB). Also, its key pair dr,Qr, containing private and public key, is securely stored at the reader.(2) Authentication Phase. In the first step, the reader chooses a random value rr and computes Rr=rrG=xr,yr, which is sent to the tag. Note that by using the E25519 curve, it is sufficient to send xr as mentioned before. However, for clarity in notation, we still denote it as the full point Rr.Then, the tag also chooses a random valuern and computes Rn=rn+Kn2G. Next, it derives Hrn+Kn2Qr+Rr=hr1,hr2 in order to compute A1=Kn1⊕hr1. Finally, the tag computes Hidn∥Kn1∥Kn2∥Rr∥Rn∥hr2=h1∥h2 and sends the message Rn,A1,h2 to the reader.Upon receiving this message, with its private keydr and the temporary local variable rr, the reader first computes dr+rrRn=hr1,hr2 in order to retrieve Kn1=A1⊕hr1 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 idn and the second key Kn2 and computes Hidn∥Kn1∥Kn2∥Rr∥Rn∥hr2=h1∥h2. If the second part of the output corresponds with the received h2, the reader approves the request and forwards h1 to the tag.The tag compares the storedh1 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.Table 1
Steps and computations in the proposed authentication with storage.
Reader-dr,Qr,DB:idn,Kn1,Kn2nTag-idn,Kn1,Kn2,QrChooserr,Rr=rrG=xr,yr⟶RrChoosern,Rn=rn+Kn2GHrn+Kn2Qr+Rr=hr1,hr2A1=Kn1⊕hr1Hidn∥Kn1∥Kn2∥Rr∥Rn∥hr2=h1∥h2←Rn,A1,h2dr+rrRn=hr1,hr2Kn1=A1⊕hr1If notKn1 in DB, stop, elseHidn∥Kn1∥Kn2∥Rr∥Rn∥hr2=h1∥h2If h2 not correct, stop, else⟶h1Ifh1 correct OK, else not


#### 4.1.2. 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 idn, certificate Certn, and key pair dn,Qn with Qn=dnG=HCertn∥idnCertn+QTTP as shown in Equation (1). The values idn,Certn,dn,Qn,Qr are stored on the tag.The reader receives from the TTP the list of revoked tags containingidrn,Certrnrn.(2) Authentication Phase. The first step is the same as in Scheme 1.1. The reader chooses a random value rr and computes Rr=rrG. This value Rr is sent to the tag.Then, the tag also chooses a random valuern and computes Rn=rn+dnG. Next, it derives a Diffie Hellmann key by computing K=rn+dnQr+Rr=xk,yk, which is used to encrypt the identity-related information, i.e., C=EKidn∥Certn∥r=idn∥Certn∥r⊕K, with r a randomly chosen value. Then, it computes Hidn∥Certn∥Rr∥Rn∥r=h1∥h2 and the corresponding signature sn=rn+dn−dnh2. The message C,Rn,sn is sent to the reader.After receiving this message, the reader derivesK=dr+rrRn in order to retrieve idn∥Certn∥r=DKC=C⊕K. Next, it checks the validity of the signature by computing Hidn∥Certn∥Rr∥Rn∥r=h1∥h2 and checking if the equality snG=Rn−h2Qn holds. If so, the reader sends h1 as a confirmation message to the tag. Else, the protocol is aborted.If the tag receives the same valueh1 as stored in its memory, the authentication process is successfully executed. The different steps in this protocol are illustrated in Table 2.Table 2
Steps and computations in the proposed authentication without storage.
Reader-dr,Qr,DB:idrn,CertrnrnTag-idn,Certn,dn,Qn,QrChooserr,Rr=rrG⟶RrChoosern,Rn=rn+dnGChoose r,C=idn∥Certn∥r⊕rn+dnQr+RrHidn∥Certn∥Rr∥Rn∥r=h1∥h2sn=rn+dn−dnh2←Rn,C,snidn∥Certn∥r=C⊕dr+rrRnIf idn in DB, stop, elseHidn∥Certn∥Rr∥Rn∥r=h1∥h2If not snG=Rn−h2Qn, stop, else⟶h1Ifh1 correct OK, else not


### 4.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.LetRr be the random value generated by the reader. The reader requests a signature of the TTP on the pair Rr,Qr, which can be easily realised by the Schnorr signature scheme as also done in Scheme 1.2. Therefore, the TTP chooses a random value r1 and computes R1=r1G. The corresponding signature sr=r1−HRr∥Qr∥R1∥TidTTP, with Ti being the current active time interval, is now sent to the reader. As a consequence, the first transmitted message now consists of Rr,Qr,R1,Ti,sr. This signature can be easily verified by the tag by checking if the following equality holds: srG=R1−HRr∥Qr∥R1∥TiQTTP.The tag does not need to prestore the public key of the readerQr anymore, but only the initialisation timestamp T0. It is implemented to accept random values within a certain given time interval from the initial T0. 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.


## 4.1. Basic Schemes

### 4.1.1. Scheme 1.1: With Storage at Reader Side

(1) Initialisation Phase. Each tag receives from the TTP the public key of the reader Qr=drG to which it needs to authenticate to and the tuple idn,Kn1,Kn2, representing a unique identity idn and two corresponding unique keys Kn1,Kn2, respectively. These parameters are securely stored on the tag. The reader receives from the TTP the list of legitimate idn,Kn1,Kn2n, which are securely stored in its database (DB). Also, its key pair dr,Qr, containing private and public key, is securely stored at the reader.(2) Authentication Phase. In the first step, the reader chooses a random value rr and computes Rr=rrG=xr,yr, which is sent to the tag. Note that by using the E25519 curve, it is sufficient to send xr as mentioned before. However, for clarity in notation, we still denote it as the full point Rr.Then, the tag also chooses a random valuern and computes Rn=rn+Kn2G. Next, it derives Hrn+Kn2Qr+Rr=hr1,hr2 in order to compute A1=Kn1⊕hr1. Finally, the tag computes Hidn∥Kn1∥Kn2∥Rr∥Rn∥hr2=h1∥h2 and sends the message Rn,A1,h2 to the reader.Upon receiving this message, with its private keydr and the temporary local variable rr, the reader first computes dr+rrRn=hr1,hr2 in order to retrieve Kn1=A1⊕hr1 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 idn and the second key Kn2 and computes Hidn∥Kn1∥Kn2∥Rr∥Rn∥hr2=h1∥h2. If the second part of the output corresponds with the received h2, the reader approves the request and forwards h1 to the tag.The tag compares the storedh1 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.Table 1
Steps and computations in the proposed authentication with storage.
Reader-dr,Qr,DB:idn,Kn1,Kn2nTag-idn,Kn1,Kn2,QrChooserr,Rr=rrG=xr,yr⟶RrChoosern,Rn=rn+Kn2GHrn+Kn2Qr+Rr=hr1,hr2A1=Kn1⊕hr1Hidn∥Kn1∥Kn2∥Rr∥Rn∥hr2=h1∥h2←Rn,A1,h2dr+rrRn=hr1,hr2Kn1=A1⊕hr1If notKn1 in DB, stop, elseHidn∥Kn1∥Kn2∥Rr∥Rn∥hr2=h1∥h2If h2 not correct, stop, else⟶h1Ifh1 correct OK, else not


### 4.1.2. 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 idn, certificate Certn, and key pair dn,Qn with Qn=dnG=HCertn∥idnCertn+QTTP as shown in Equation (1). The values idn,Certn,dn,Qn,Qr are stored on the tag.The reader receives from the TTP the list of revoked tags containingidrn,Certrnrn.(2) Authentication Phase. The first step is the same as in Scheme 1.1. The reader chooses a random value rr and computes Rr=rrG. This value Rr is sent to the tag.Then, the tag also chooses a random valuern and computes Rn=rn+dnG. Next, it derives a Diffie Hellmann key by computing K=rn+dnQr+Rr=xk,yk, which is used to encrypt the identity-related information, i.e., C=EKidn∥Certn∥r=idn∥Certn∥r⊕K, with r a randomly chosen value. Then, it computes Hidn∥Certn∥Rr∥Rn∥r=h1∥h2 and the corresponding signature sn=rn+dn−dnh2. The message C,Rn,sn is sent to the reader.After receiving this message, the reader derivesK=dr+rrRn in order to retrieve idn∥Certn∥r=DKC=C⊕K. Next, it checks the validity of the signature by computing Hidn∥Certn∥Rr∥Rn∥r=h1∥h2 and checking if the equality snG=Rn−h2Qn holds. If so, the reader sends h1 as a confirmation message to the tag. Else, the protocol is aborted.If the tag receives the same valueh1 as stored in its memory, the authentication process is successfully executed. The different steps in this protocol are illustrated in Table 2.Table 2
Steps and computations in the proposed authentication without storage.
Reader-dr,Qr,DB:idrn,CertrnrnTag-idn,Certn,dn,Qn,QrChooserr,Rr=rrG⟶RrChoosern,Rn=rn+dnGChoose r,C=idn∥Certn∥r⊕rn+dnQr+RrHidn∥Certn∥Rr∥Rn∥r=h1∥h2sn=rn+dn−dnh2←Rn,C,snidn∥Certn∥r=C⊕dr+rrRnIf idn in DB, stop, elseHidn∥Certn∥Rr∥Rn∥r=h1∥h2If not snG=Rn−h2Qn, stop, else⟶h1Ifh1 correct OK, else not


## 4.1.1. Scheme 1.1: With Storage at Reader Side

(1) Initialisation Phase. Each tag receives from the TTP the public key of the reader Qr=drG to which it needs to authenticate to and the tuple idn,Kn1,Kn2, representing a unique identity idn and two corresponding unique keys Kn1,Kn2, respectively. These parameters are securely stored on the tag. The reader receives from the TTP the list of legitimate idn,Kn1,Kn2n, which are securely stored in its database (DB). Also, its key pair dr,Qr, containing private and public key, is securely stored at the reader.(2) Authentication Phase. In the first step, the reader chooses a random value rr and computes Rr=rrG=xr,yr, which is sent to the tag. Note that by using the E25519 curve, it is sufficient to send xr as mentioned before. However, for clarity in notation, we still denote it as the full point Rr.Then, the tag also chooses a random valuern and computes Rn=rn+Kn2G. Next, it derives Hrn+Kn2Qr+Rr=hr1,hr2 in order to compute A1=Kn1⊕hr1. Finally, the tag computes Hidn∥Kn1∥Kn2∥Rr∥Rn∥hr2=h1∥h2 and sends the message Rn,A1,h2 to the reader.Upon receiving this message, with its private keydr and the temporary local variable rr, the reader first computes dr+rrRn=hr1,hr2 in order to retrieve Kn1=A1⊕hr1 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 idn and the second key Kn2 and computes Hidn∥Kn1∥Kn2∥Rr∥Rn∥hr2=h1∥h2. If the second part of the output corresponds with the received h2, the reader approves the request and forwards h1 to the tag.The tag compares the storedh1 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.Table 1
Steps and computations in the proposed authentication with storage.
Reader-dr,Qr,DB:idn,Kn1,Kn2nTag-idn,Kn1,Kn2,QrChooserr,Rr=rrG=xr,yr⟶RrChoosern,Rn=rn+Kn2GHrn+Kn2Qr+Rr=hr1,hr2A1=Kn1⊕hr1Hidn∥Kn1∥Kn2∥Rr∥Rn∥hr2=h1∥h2←Rn,A1,h2dr+rrRn=hr1,hr2Kn1=A1⊕hr1If notKn1 in DB, stop, elseHidn∥Kn1∥Kn2∥Rr∥Rn∥hr2=h1∥h2If h2 not correct, stop, else⟶h1Ifh1 correct OK, else not


## 4.1.2. 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 idn, certificate Certn, and key pair dn,Qn with Qn=dnG=HCertn∥idnCertn+QTTP as shown in Equation (1). The values idn,Certn,dn,Qn,Qr are stored on the tag.The reader receives from the TTP the list of revoked tags containingidrn,Certrnrn.(2) Authentication Phase. The first step is the same as in Scheme 1.1. The reader chooses a random value rr and computes Rr=rrG. This value Rr is sent to the tag.Then, the tag also chooses a random valuern and computes Rn=rn+dnG. Next, it derives a Diffie Hellmann key by computing K=rn+dnQr+Rr=xk,yk, which is used to encrypt the identity-related information, i.e., C=EKidn∥Certn∥r=idn∥Certn∥r⊕K, with r a randomly chosen value. Then, it computes Hidn∥Certn∥Rr∥Rn∥r=h1∥h2 and the corresponding signature sn=rn+dn−dnh2. The message C,Rn,sn is sent to the reader.After receiving this message, the reader derivesK=dr+rrRn in order to retrieve idn∥Certn∥r=DKC=C⊕K. Next, it checks the validity of the signature by computing Hidn∥Certn∥Rr∥Rn∥r=h1∥h2 and checking if the equality snG=Rn−h2Qn holds. If so, the reader sends h1 as a confirmation message to the tag. Else, the protocol is aborted.If the tag receives the same valueh1 as stored in its memory, the authentication process is successfully executed. The different steps in this protocol are illustrated in Table 2.Table 2
Steps and computations in the proposed authentication without storage.
Reader-dr,Qr,DB:idrn,CertrnrnTag-idn,Certn,dn,Qn,QrChooserr,Rr=rrG⟶RrChoosern,Rn=rn+dnGChoose r,C=idn∥Certn∥r⊕rn+dnQr+RrHidn∥Certn∥Rr∥Rn∥r=h1∥h2sn=rn+dn−dnh2←Rn,C,snidn∥Certn∥r=C⊕dr+rrRnIf idn in DB, stop, elseHidn∥Certn∥Rr∥Rn∥r=h1∥h2If not snG=Rn−h2Qn, stop, else⟶h1Ifh1 correct OK, else not


## 4.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.LetRr be the random value generated by the reader. The reader requests a signature of the TTP on the pair Rr,Qr, which can be easily realised by the Schnorr signature scheme as also done in Scheme 1.2. Therefore, the TTP chooses a random value r1 and computes R1=r1G. The corresponding signature sr=r1−HRr∥Qr∥R1∥TidTTP, with Ti being the current active time interval, is now sent to the reader. As a consequence, the first transmitted message now consists of Rr,Qr,R1,Ti,sr. This signature can be easily verified by the tag by checking if the following equality holds: srG=R1−HRr∥Qr∥R1∥TiQTTP.The tag does not need to prestore the public key of the readerQr anymore, but only the initialisation timestamp T0. It is implemented to accept random values within a certain given time interval from the initial T0. 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.


## 5. Security Evaluation

The security will be both informally and formally evaluated.


### 5.1. Informal Security Evaluation

We now discuss the strength of both protocols with respect to the attack scenarios and the security features defined in Section3. 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 Table3, being the results of send, execute, session reveal, and corrupt queries, respectively. We want to note that hr1,hr2 are no session-specific temporary information at the tag side as it is possible to compute Kn1⊕Hrn+Kn2Qr+Rr and to take the first 128 bits of the operation as A1 and the bits 129 till 256 as hr2, since Kn1 is considered to be a variable of length 128 bits.Table 3
Results in the different attack scenarios.
CharacteristicScheme 1.1Scheme 1.2[A1] Active attacker—send queriesSend0,R=Rr, send1,T=Rn,A1,h2, send2,R=h1Send0,R=Rr, send1,T=C,Rn,sn, send2,R=h1[A2] Passive attacker—execute queriesExecute(send0,R)=Rr, execute(send(1,T))=Rn,A1,h2, execute(send(2,R))=h1Execute(send(0,R))=Rr, execute(send(1,T))=C,Rn,sn, execute(send(2,R))=h1[A3] Session-specific temporary information—SSReveal queriesSSRevealT=rn, SSRevealR=rrSSRevealT=rn,r, SSRevealR=rr[A4] Long-term key material—corrupt queriesCorruptT=idn,Kn1,Kn2, corruptR= dr,idn,Kn1,Kn2nCorrupt(T)=dn,idn,Certn, corrupt(R)= drThis knowledge can then be exploited in the different attacks, as explained in Table4.Table 4
Informal security analysis of both protocols.
CharacteristicScheme 1.1Scheme 1.2[C1] Mutual authenticationIn order to be able to construct a valid outcome in the protocol, the attacker needs to construct a legitimateh2 (in the case of the tag) or h1 (in the case of the reader). To do so, the attacker should know at the same time either idn,Kn1,Kn2,rn or idn,Kn1,Kn2,rr,dr. 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 signaturesn by the tag or valid response h1 by the reader, the attacker needs to possess at the same time either dn,rn or dr,rr due to the ECDLP as these values require the computation of the session key K=dn+rnQr+Rr=dr+rrRn used to encrypt the message idn,Certn,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] AnonymityThe identityidn 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 Kn1, which is hidden in A1 relying on the strength of the ECDLP.To find the identity of the tag, the message C should be decrypted. Therefore, eitherdn,rn or dr,rr is 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] UnlinkabilityAs explained in the criteria of anonymity, the identity of the tag cannot be revealed, but the best to be leaked isKn1 from A1, which would threaten the unlinkability feature. However, this is not possible as it requires the knowledge of either rn,Kn2 or dr,rr, which is not possible, cf Table 3.Identity-related information is packed in the parametersC,sn,h1. From C, nothing can be leaked as explained before. From the second one sn, 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 h2, which includes the additional random value r, to be able to verify the equation snG=Rn−h2Qn.On the other hand, ifidn,Certn is leaked, similar to a dictionary attack, together with the session data r, the validity of h1 can be verified and thus, the tag can be tracked.[C4] Session-specific temporary informationGiven SSReveal(T)=rn, it still does not result in making a fake message containing A1,h2,h1 as also corresponding secret keys Kn1,Kn2 of the tag need to be known. Also, with additional SSReveal(R)=rr, no fake messages can be constructed.With SSRevealT=rn,r and SSRevealR=rr, no fake messages containing legitimate C,sn,h1 parameters can be made without knowledge of valid credentials of the tag as it requires the additional usage of either the private key dn of the tag or the private key dR of the reader due to the ECDLP.[C5] Perfect forward secrecyWhen the corrupt queries of tag and reader are executed, we are still not able to create a fake message containingA1,h2,h1 as also the session-specific information rn or rr 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 ofA1, 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 attacksThis 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 theh1 value also changes. Also, the message of the tag cannot be replayed as it relies on the usage of the random Rr 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 n2/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 thann2/2l, with l the space size in which the randoms are defined and thus equal to the field size.[C7] Desynchronisation attackSince 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 avoid denial-of-service attacks to limit the number of unsuccessful authentication requests by a fixed amount.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.[C8] ScalabilityThis 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-of-service attackThe 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.It can be concluded from Table4 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 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 Section6.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 authenticationThe comparison is provided in Table5. 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.Table 5
Comparison of security strength with related and recent literature with respect to the security criteria [C1-C11] (Y: yes; N: no; P: partially).
Scheme (authors+year)[C1][C2][C3][C4][C5][C6][C7][C8][C9][C10][C11]Braeken et al. 2018 [29]YYYYYYYYPYNSowjanya et al. 2020 [34]YYYNYYYNYNNDinarvand and Barati 2019 [38]YYYYPYYYNNNMerabet et al., Scheme 1, 2019 [43]YYNNNYYYNNNMerabet et al., Scheme 2, 2019 [43]YYNNNYYYNNYScheme 1.1YYYYYYYYPNNScheme 1.2YYYYYYYYPYNScheme 2.1YYYYYYYYYNYScheme 2.2YYYYYYYYYYYOnly 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.


### 5.2. 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. ProVerif 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–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.TheProVerif 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.Figure 2
ProVerif structure.Some more background and theProVerif 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 Rr, 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.


## 5.1. Informal Security Evaluation

We now discuss the strength of both protocols with respect to the attack scenarios and the security features defined in Section3. 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 Table3, being the results of send, execute, session reveal, and corrupt queries, respectively. We want to note that hr1,hr2 are no session-specific temporary information at the tag side as it is possible to compute Kn1⊕Hrn+Kn2Qr+Rr and to take the first 128 bits of the operation as A1 and the bits 129 till 256 as hr2, since Kn1 is considered to be a variable of length 128 bits.Table 3
Results in the different attack scenarios.
CharacteristicScheme 1.1Scheme 1.2[A1] Active attacker—send queriesSend0,R=Rr, send1,T=Rn,A1,h2, send2,R=h1Send0,R=Rr, send1,T=C,Rn,sn, send2,R=h1[A2] Passive attacker—execute queriesExecute(send0,R)=Rr, execute(send(1,T))=Rn,A1,h2, execute(send(2,R))=h1Execute(send(0,R))=Rr, execute(send(1,T))=C,Rn,sn, execute(send(2,R))=h1[A3] Session-specific temporary information—SSReveal queriesSSRevealT=rn, SSRevealR=rrSSRevealT=rn,r, SSRevealR=rr[A4] Long-term key material—corrupt queriesCorruptT=idn,Kn1,Kn2, corruptR= dr,idn,Kn1,Kn2nCorrupt(T)=dn,idn,Certn, corrupt(R)= drThis knowledge can then be exploited in the different attacks, as explained in Table4.Table 4
Informal security analysis of both protocols.
CharacteristicScheme 1.1Scheme 1.2[C1] Mutual authenticationIn order to be able to construct a valid outcome in the protocol, the attacker needs to construct a legitimateh2 (in the case of the tag) or h1 (in the case of the reader). To do so, the attacker should know at the same time either idn,Kn1,Kn2,rn or idn,Kn1,Kn2,rr,dr. 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 signaturesn by the tag or valid response h1 by the reader, the attacker needs to possess at the same time either dn,rn or dr,rr due to the ECDLP as these values require the computation of the session key K=dn+rnQr+Rr=dr+rrRn used to encrypt the message idn,Certn,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] AnonymityThe identityidn 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 Kn1, which is hidden in A1 relying on the strength of the ECDLP.To find the identity of the tag, the message C should be decrypted. Therefore, eitherdn,rn or dr,rr is 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] UnlinkabilityAs explained in the criteria of anonymity, the identity of the tag cannot be revealed, but the best to be leaked isKn1 from A1, which would threaten the unlinkability feature. However, this is not possible as it requires the knowledge of either rn,Kn2 or dr,rr, which is not possible, cf Table 3.Identity-related information is packed in the parametersC,sn,h1. From C, nothing can be leaked as explained before. From the second one sn, 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 h2, which includes the additional random value r, to be able to verify the equation snG=Rn−h2Qn.On the other hand, ifidn,Certn is leaked, similar to a dictionary attack, together with the session data r, the validity of h1 can be verified and thus, the tag can be tracked.[C4] Session-specific temporary informationGiven SSReveal(T)=rn, it still does not result in making a fake message containing A1,h2,h1 as also corresponding secret keys Kn1,Kn2 of the tag need to be known. Also, with additional SSReveal(R)=rr, no fake messages can be constructed.With SSRevealT=rn,r and SSRevealR=rr, no fake messages containing legitimate C,sn,h1 parameters can be made without knowledge of valid credentials of the tag as it requires the additional usage of either the private key dn of the tag or the private key dR of the reader due to the ECDLP.[C5] Perfect forward secrecyWhen the corrupt queries of tag and reader are executed, we are still not able to create a fake message containingA1,h2,h1 as also the session-specific information rn or rr 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 ofA1, 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 attacksThis 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 theh1 value also changes. Also, the message of the tag cannot be replayed as it relies on the usage of the random Rr 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 n2/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 thann2/2l, with l the space size in which the randoms are defined and thus equal to the field size.[C7] Desynchronisation attackSince 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 avoid denial-of-service attacks to limit the number of unsuccessful authentication requests by a fixed amount.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.[C8] ScalabilityThis 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-of-service attackThe 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.It can be concluded from Table4 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 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 Section6.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 authenticationThe comparison is provided in Table5. 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.Table 5
Comparison of security strength with related and recent literature with respect to the security criteria [C1-C11] (Y: yes; N: no; P: partially).
Scheme (authors+year)[C1][C2][C3][C4][C5][C6][C7][C8][C9][C10][C11]Braeken et al. 2018 [29]YYYYYYYYPYNSowjanya et al. 2020 [34]YYYNYYYNYNNDinarvand and Barati 2019 [38]YYYYPYYYNNNMerabet et al., Scheme 1, 2019 [43]YYNNNYYYNNNMerabet et al., Scheme 2, 2019 [43]YYNNNYYYNNYScheme 1.1YYYYYYYYPNNScheme 1.2YYYYYYYYPYNScheme 2.1YYYYYYYYYNYScheme 2.2YYYYYYYYYYYOnly 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.


## 5.2. 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. ProVerif 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–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.TheProVerif 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.Figure 2
ProVerif structure.Some more background and theProVerif 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 Rr, 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.


## 6. 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 TM. 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-Mote with ARM Cortex-M3 at 32 MHz and 32 KB RAM using the HW acceleration engine and on a Raspberry Pi 3B Quad Core 1.2 GHz with 1GB RAM using the BouncyCastle library. As a result, we obtained 344.66 ms for the first one and 37.94 ms for the second one, mimicking the tag and reader, respectively.Table6 compares the number of EC multiplications TM 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.Table 6
Comparison of the computation costs.
Scheme (authors+year)TM readerTime readerTM tagTime tagTotal timeBraeken et al. 2018 [29]5189.75 ms41378.64 ms1568.39 msSowjanya et al. 2020 [34]5189.75 ms31033.66 ms1223.41 msDinarvand et al. 2019 [38]3113.85 ms31033.66 ms1167.51 msMerabet et al., Scheme 1, 2019 [43]3113.85 ms31033.66 ms1167.51 msMerabet et al., Scheme 2, 2019 [43]275.88 ms2689.32 ms765.20 msScheme 1.1275.88 ms2689.32 ms765.20 msScheme 1.24151.80 ms2689.32 ms841.12 msScheme 2.14151.80 ms51723.30 ms1875.10 msScheme 2.24151.80 ms41378.64 ms1430.44 ms


### 6.2. 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 byNS, and the number of received bits by NR from the point of view of the tag.Table7 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.Table 7
Comparison of the communication costs.
Scheme (authors+year)NS (bits)NR (bits)Total bitsNr of phasesBraeken et al. 2018 [29]89651214083Sowjanya et al. 2020 [34]80051213122Dinarvand et al. 2019 [38]76851212804Merabet et al., Scheme 1, 2019 [43]76851212803Merabet et al., Scheme 2, 2019 [43]76851212803Scheme 1.176851212803Scheme 1.2102451215363Scheme 2.1768156823363Scheme 2.21024156825923


## 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 TM. 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-Mote with ARM Cortex-M3 at 32 MHz and 32 KB RAM using the HW acceleration engine and on a Raspberry Pi 3B Quad Core 1.2 GHz with 1GB RAM using the BouncyCastle library. As a result, we obtained 344.66 ms for the first one and 37.94 ms for the second one, mimicking the tag and reader, respectively.Table6 compares the number of EC multiplications TM 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.Table 6
Comparison of the computation costs.
Scheme (authors+year)TM readerTime readerTM tagTime tagTotal timeBraeken et al. 2018 [29]5189.75 ms41378.64 ms1568.39 msSowjanya et al. 2020 [34]5189.75 ms31033.66 ms1223.41 msDinarvand et al. 2019 [38]3113.85 ms31033.66 ms1167.51 msMerabet et al., Scheme 1, 2019 [43]3113.85 ms31033.66 ms1167.51 msMerabet et al., Scheme 2, 2019 [43]275.88 ms2689.32 ms765.20 msScheme 1.1275.88 ms2689.32 ms765.20 msScheme 1.24151.80 ms2689.32 ms841.12 msScheme 2.14151.80 ms51723.30 ms1875.10 msScheme 2.24151.80 ms41378.64 ms1430.44 ms


## 6.2. 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 byNS, and the number of received bits by NR from the point of view of the tag.Table7 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.Table 7
Comparison of the communication costs.
Scheme (authors+year)NS (bits)NR (bits)Total bitsNr of phasesBraeken et al. 2018 [29]89651214083Sowjanya et al. 2020 [34]80051213122Dinarvand et al. 2019 [38]76851212804Merabet et al., Scheme 1, 2019 [43]76851212803Merabet et al., Scheme 2, 2019 [43]76851212803Scheme 1.176851212803Scheme 1.2102451215363Scheme 2.1768156823363Scheme 2.21024156825923


## 7. 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 Tables6 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.


## 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.



---

*Source: 8876766-2021-07-03.xml*