Formal Security Analysis of ECC-Based RFID in Logic of Events Theory

: Radio frequency identiﬁcation (RFID) is a crucial component of the Internet of Things (IoT), and RFID using elliptic curve Cryptography (ECC) is a public key cryptosystem authentication approach that tackles the problem of electronic tag data encryption in RFID systems. The commercial-isation and large-scale deployment of RFID systems has raised a number of security-related issues that suggest the need for security protocols. Logic of events theory (LoET) is a formal method for constructing and reasoning about distributed systems and protocols involving security concepts. This paper proposes three event classes, Compute, Retrieve, and Generate, and related axioms and inference rules to formally abstract the ECC session key generation function and formally institute the authentication process of both parties, and the ex-tended LoET is used to analyse the security properties of ECC-based RFID security protocols. Under reasonable assumptions, an ECC-based RFID mutual authentication scheme is shown to satisfy the strong mutual authentication feature. It is shown that extended logic of events theory may be used to prove the security properties of this class of ECC-based RFID protocols.


Introduction
RFID, a contactless automatic identification technology based on radio frequency signals [1], is widely used in logistics management, healthcare, and industrial manufacturing. With the rapid development and application of RFID technology, RFID system security and privacy issues are becoming increasingly prominent, and a high-security authentication protocol needs to be designed to ensure RFID system security. Among public key cryptosystems, an elliptic curve cipher is the preferred cryptosystem for RFID authentication protocols because of its technical advantages such as short key length, high encryption strength, and small bandwidth consumption [2].
In 2006, Tuyls and Batina [3] proposed the first RFID authentication protocol based on elliptic curve cryptography (ECC). In 2011, Zhang et al. [4] introduced the idea of random keys and proposed an ECDLP-based RFID authentication protocol, but they did not solve the most basic mutual authentication problem. Subsequently, Liao et al. [5] designed an ECC-based RFID two-way authentication protocol in 2013, but the data integrity was flawed and there was a key compromise problem. In 2016, Alamr et al. [6] proposed an ECDH-based RFID two-way authentication protocol, which solved the key leakage and tracking attack problems but did not consider the data integrity. In 2019, Dinarvand et al. [7] proposed a new ECC-based RFID authentication scheme with improved security but low efficiency in key finding.
Based on elliptic encryption algorithms, scholars have designed a large number of RFID authentication schemes, but in the process of practical application, there are a variety of attacks. In the face of these problems, scholars have launched a security analysis of the 1.
Extending logic of events theory. Two new event classes are added, and relevant axioms and rules are expanded.

2.
Formally abstracting the elliptic curve session key generation function, instituting the mutual authentication process of ECC-based RFID authentication protocol, and portraying the security properties that the protocol needs to satisfy. 3.
Using ECC-based RFID protocol in [20] as an example, the strong authentication of the protocol is proved using extended LoET. The application of LoET is extended to enable formal analysis of authentication protocols with elliptical cryptography regimes.
The rest of the paper is organised as follows: Section 2 describes LoET, including the basic concept, proof system, and extension of LoET. Section 3 introduces the ECC-based RFID protocol. In Section 4, the proof of the mutual authentication property of ECC-based RFID protocol is elaborated in detail, and finally, our conclusions and suggestions for future work are given in Section 5. The specific framework is shown in Figure 1.

LoET Theory
LoET is based on a message automaton design that defines possible protocol actions, and the analysis process abstracts the interaction actions between honest subjects into different types of events, defines the interaction of the protocol formally as a basic sequence using an event language, and proves the security properties of the protocol based on LoET axiomatic system reasoning. Logic of events theory and related rules are referred to in the literature [14][15][16][17][18][19], and the related theories involved in this paper are given below.

Symbol Description
The basic notations and semantics are given in Table 1.

LoET Theory
LoET is based on a message automaton design that defines possible protocol actions, and the analysis process abstracts the interaction actions between honest subjects into different types of events, defines the interaction of the protocol formally as a basic sequence using an event language, and proves the security properties of the protocol based on LoET axiomatic system reasoning. Logic of events theory and related rules are referred to in the literature [14][15][16][17][18][19], and the related theories involved in this paper are given below.

Symbol Description
The basic notations and semantics are given in Table 1.

. Threads and Matching Sessions
A thread is an ordered list of operations on a single-state bit of the protocol, defined by the following equation.
In the authentication process of the protocol, if there are different threads of send event s and receive event r, and the messages of both are consistent, then s and r are a weak match s ∼ r; if s ∼ r is satisfied and s is a preorder event of r, then a strong match s → r is formed, as defined below.
Two threads, thr1 and thr2, both have n message event pairs. If their corresponding message event pairs < Send(s), Rcv(r) > both satisfy strong matching, then threads thr1 and thr2 form a strong matching session of length n, denoted as thr 1 n ≈ thr 2 . If the above message event pairs satisfy only weak matching, then a weak matching session is satisfied, as thr 1 n ∼ thr 2 .

Strong Authentication Properties of Protocol
The protocol is formally defined as the set of threads of each participating honest subject, and the authentication of the protocol is proved by analysing whether different threads in the protocol satisfy the matching sessions. The basic sequence bs is the set of action events in the thread. A protocol is proven to have strong authentication properties if it satisfies a strong matching session for the basic sequence of both sides of the honest subject. As in protocol Pr, the authentication property of an honest subject A authenticating an n message to B is formally defined as follows:

Proof System
LoET proves the protocol security properties using axioms and related inference rules. In this paper, only the relevant axioms and rules used in the protocol analysis are described.

Key Axiom
Keys that cannot be guessed, such as symmetric or private keys, are usually represented by atoms, and public keys are represented by identifiers. Since the private key is different from the symmetric key, the Key class can be represented as Key ≡ de f Id + Atom + Atom.
The Key Axiom defines the relationship between keys: a symmetric key can only match itself, a private key can only match the public key it corresponds to, and two different subjects cannot have the same private key.

Casual Axiom
The Causal Axiom relates the causal relationships between events and consists of AxiomR, AxiomV, and AxiomD. The detailed equation is shown below.
AxiomR, AxiomV are similar. Both elaborate the matching of protocol behaviours (i.e., there exists a Send event corresponding to each before the Rcv event occurs, and there exists a Sign event corresponding to each before the Veri f y event occurs), and the information content of both is the same. AxiomD introduces a new key element that specifies that the Decrypt event preorder holds the same information as its corresponding Encrypt event and that the keys match each other.

Honest Axiom
The function Honest is defined in LoET to describe the honesty of protocol principals. An honest principal does not release its own private key. Sign, encrypt, or decrypt events with a private key of an honest principal must occur in that honest principal's instance. The honesty axiom is called AxiomS, shown in Equation (6).

Event Class Extensions
In LoET, the event class describes the interaction actions between the honest subjects in the protocol, which are the generation of challenge numbers, the sending and receiving of messages, the encryption and decryption events, and the verification of signatures and signatures, as defined in the following way.
Sign, Veri f y : EClass(Data × Id × Atom) However, these seven event classes do not cover all protocol actions. In today's emerging protocols, the behaviour among protocol participants is more diverse and the encryption mechanism is more complex, and the existing LoET is not sufficient to prove their security properties. Therefore, new event classes Compute, Retrieve, and Generate are proposed for ECC-based RFID protocols, which can effectively verify the causal relationships between events of such protocols. Their definitions are shown below.
If there exists an event e 1 satisfying e 1 ∈ E(Compute), then in the event e 1 , subject A performs an elliptic curve calculation on the data item and generates an authentication message. If A is an honest subject, then loc(e 1 ) = A. If there exists an event e 2 satisfying e 2 ∈ E(Retrieve), then in the event e 2 , subject B successfully retrieves the authentication message generated by A and obtains the original data item, loc(e 2 ) = B. If there exists an event e ∈ E(Generate), then in the event e, the subject performs an elliptic curve scalar multiplication calculation and generates a public key.

Extension of Relevant Axioms and Rules
The introduction of the Compute and Retrieve event classes requires an extension to the Causal Axiom. It is stipulated that there exists a Compute event corresponding to it in the preorder of the Retrieve event, both of which have the same information and equal elliptic curve session keys. The definition of AxiomC is shown below.
After introducing the Generate event class, it is necessary to define the relevant rules to facilitate the subsequent proof of the protocol. First, the public and private keys of the subject A are generated when the subject A performs a scalar multiplication calculation, as shown in the following equation, Rule1.
When the subject A performs the scalar multiplication computation and sends the resulting public key, there exists a subject B who receives the message, obtains the subject A's public key, and is unable to obtain A's private key through the computation, as shown in the following equation, Rule2.
When a scalar multiplication of subject A exists during Generate event e 1 and generate R, then this event retains the freshness of R. If, after the Generate() event e 1 occurs and before the event e 3 containing R occurs, all send events do not contain R, then we consider the event e 3 to retain the freshness of R, as shown in Rule3.

ECC-Based RFID Protocol
ECC-based RFID is used to provide mutual authentication between reader and tag in low cost RFID systems. The protocol is divided into a system setup phase and an authentication phase. The system setup phase stores the nth-order base point P on the elliptic curve, the server's public key P s , and the tag's authentication factor X T in the tag's memory. The authentication process of the ECC-based RFID two-way authentication protocol analysed in this paper is shown in Figure 2. ECC-based RFID has three subjects involved in the protocol session, which are the tag, the reader, and the server. During the authentication process, we usually assume that the communication between the reader and the server is secure, so we can treat reader and server as a whole. Focusing on analysing the mutual authentication process between the tag and the server, the steps of the authentication process are detailed below.
(1) Authentication request: (2) As the initiator, server generates a random number 1 r and performs a scalar multiplication operation, sending 1 R to tag. (3) Server authenticates tag: (4) After receiving the message, the tag generates a random number 2 3 , r r , performs a scalar multiplication calculation, generates the authentication message A T , and sends 2 m to the server. After receiving the authentication information from the tag, the server recovers T X , then compares the recovery result with its own locally stored tag authentication factor, and terminates the protocol if it does not exist; otherwise, it certifies the tag as a legitimate tag and then uses its private key S A to calculate and send to the tag. is valid. If it is valid, it accepts the server as a legitimate server; otherwise, it terminates the protocol.
LoET is a theory based on the formal analysis of protocols by process evolution, firstly by defining the processes of the different roles of the protocol, analysing the messages of the matching sessions in the basic sequence, and analysing whether the messages of the sending and receiving actions are the same between subjects and the temporal relationship of the actions, using theorems to inscribe the strong authentication properties to be satisfied by the protocol.
Before studying the ECC-based RFID mutual authentication protocol, it is necessary to first abstract the functions implemented by ECC, as shown in Figure 3, since the ECC functions cannot be directly described formally in LoET basic modelling theory. ECC-based RFID has three subjects involved in the protocol session, which are the tag, the reader, and the server. During the authentication process, we usually assume that the communication between the reader and the server is secure, so we can treat reader and server as a whole. Focusing on analysing the mutual authentication process between the tag and the server, the steps of the authentication process are detailed below.
(2) As the initiator, server generates a random number r 1 and performs a scalar multiplication operation, sending R 1 to tag.
(4) After receiving the message, the tag generates a random number r 2 , r 3 , performs a scalar multiplication calculation, generates the authentication message A T , and sends m 2 to the server. After receiving the authentication information from the tag, the server recovers X T , then compares the recovery result with its own locally stored tag authentication factor, and terminates the protocol if it does not exist; otherwise, it certifies the tag as a legitimate tag and then uses its private key A S to calculate and send to the tag.
(5) Tag authenticates server: Server → Tag : m 3 = {A S } (6) After the tag receives the authentication message A S from the server, it checks whether A S = r 3 P s is valid. If it is valid, it accepts the server as a legitimate server; otherwise, it terminates the protocol.
LoET is a theory based on the formal analysis of protocols by process evolution, firstly by defining the processes of the different roles of the protocol, analysing the messages of the matching sessions in the basic sequence, and analysing whether the messages of the sending and receiving actions are the same between subjects and the temporal relationship of the actions, using theorems to inscribe the strong authentication properties to be satisfied by the protocol.
Before studying the ECC-based RFID mutual authentication protocol, it is necessary to first abstract the functions implemented by ECC, as shown in Figure 3, since the ECC functions cannot be directly described formally in LoET basic modelling theory. Electronics 2023, 12, x FOR PEER REVIEW 8 of 14

Proving Mutual Authentication
We implement the proof of authentication property in four steps, as shown in Figure  4. Firstly, we need to define the basic sequences of authentication actions in principal threads.

Proving Mutual Authentication
We implement the proof of authentication property in four steps, as shown in Figure 4. Firstly, we need to define the basic sequences of authentication actions in principal threads.

Proving Mutual Authentication
We implement the proof of authentication property in four steps, as shown in Figure  4. Firstly, we need to define the basic sequences of authentication actions in principal threads.  Then, we analyse the message matching conversation in the basic sequence and specify the authentication property of the protocol by analysing whether the messages of sending and receiving actions between principals are the same and whether the time sequence of actions satisfies the Casual Axiom.
Next, we need to analyse all the message actions in the basic sequence of the authentication principal and then infer whether there is a matching message action in the other principal, that is, whether the sending message is consistent with the receiving message of the matching action. If it is consistent, the protocol satisfies the weak authentication.
Finally, we need to further analyse the time sequence of the matching actions among the principals of the protocol. If there are matching sending actions before all the receiving actions of each principal, the protocol satisfies strong authentication.

Protocol Basic Sequence
Define the processes Initiator and Responder to describe the authentication server and tag body protocol interaction, where I1, I2, I3, and R1, R2, R3 are the Initiator and Responder base sequences, respectively, as shown in Figure 5. Then, we analyse the message matching conversation in the basic sequence and specify the authentication property of the protocol by analysing whether the messages of sending and receiving actions between principals are the same and whether the time sequence of actions satisfies the Casual Axiom.
Next, we need to analyse all the message actions in the basic sequence of the authentication principal and then infer whether there is a matching message action in the other principal, that is, whether the sending message is consistent with the receiving message of the matching action. If it is consistent, the protocol satisfies the weak authentication.
Finally, we need to further analyse the time sequence of the matching actions among the principals of the protocol. If there are matching sending actions before all the receiving actions of each principal, the protocol satisfies strong authentication.

Protocol Basic Sequence
Define the processes Initiator and Responder to describe the authentication server and tag body protocol interaction, where I1, I2, I3, and R1, R2, R3 are the Initiator and Responder base sequences, respectively, as shown in Figure 5. By analysing the protocol's basic sequence above, we can see that the initiator must engage in two message sending and receiving actions with the Responder in order to satisfy the protocol's strong authentication requirements. The property is portrayed as By analysing the protocol's basic sequence above, we can see that the initiator must engage in two message sending and receiving actions with the Responder in order to satisfy the protocol's strong authentication requirements. The property is portrayed as SP|= auth(I 3 , 2) .
Accordingly, the Responder must prove a strong authenticity that is SP|= auth(R 3 , 2) .

SP|= auth(I 3 , 2) Proof Process
Assume that the honest subject Initiator = Responder (referred to by A, B, respectively, later), A, and B share the public key P S and the tag authentication information X T , and since the honest subject follows the protocol rules, any threads of A and B participating in the protocol run are instances of the basic sequence of SP. Let thr 1 be an instance of the basic sequence I 3 . Then, there exists e 0 < loc e 1 < loc . . . < loc e 7 event sequence for the Atom type parameter r 1 , R 1 , R 2 , R 3 , T S1 , T S2 , A T , A S , and the event sequence instances of thr 1 are From the AxiomC and AxiomS, for the recovery event e 5 , there must be a computation event e in some thread of the protocol and e < e 5 ∧ RCMatch(e 5 , e ) ∧ loc(e ) = B ∨ loc(e ) = A, and there are R 2 , R 3 in all basic sequences of the protocol that contain Compute() computation actions. Since it is based on the current event, all events that have not occurred are not taken into account, so R 3 is excluded. Assuming that e is the event in the R 2 sequence thread thr 2 , then for the Atom type r 2 , r 3 , R 1 , R 2 , R 3 , T T1 , T T2 , A T , the sequence of events e 0 , e 1 , e 2 , e 3 and e on subject B is present as Since RCMatch(e 5 , e ), then ∧ciphertext(e 5 ) = ciphertext(e ) ∧ecckey(e 5 ) = ecckey(e ) ⇒ can be derived.
From (14)- (17), we can see that Send(e 2 ) =< R 1 >= Rcv(e 0 ) and Rcv(e 3 ) =< R 2 , A T , R 3 >= Send(e 3 ), e 2 , e 3 form two complete Send − Rcv events, and a weak matching session of length 2 can be obtained at this point. Next, we analyse whether they are strong matching sessions, i.e., we analyse whether the session events satisfy the e 2 < e 0 , e 3 < e 3 time event sequence. In the case that subject A =B has been specified, the definition of Rule3 leads to Fresh(e 2 , R 1 ), which proves that R 1 was first sent in the event e 2 . It follows from Rule2 that all operations containing R 1 must occur after the event e 2 , including the event Rcv(e 0 ) =< R 1 >. Therefore, according to the honesty axiom in LoET, the sequence of events e 2 < e 0 can be obtained. Similarly, e 3 < e 3 can be analysed.
The above analysis shows that the subject A authentication thread has a strong matching session with subject B, i.e., SP|= auth(I 3 , 2) is proven.

SP|= auth(R 3 , 2) Proof Process
Let thr 1 be an instance of the basic sequence R 3 in entity B. Define e 0 < loc e 1 < loc . . . < loc e 6 to be the event of the thread thr 1 . Then, for Atom type parameters Based on the AxiomD and AxiomS, there exists an encryption event e that matches the decryption event e 6 and e < e 6 ∧ DEMatch(e 6 , e ) ∧ loc(e ) = B ∨ loc(e ) = A, and the encryption action that contains Encrypt() among all the basic sequences of the protocol is I 4 .
Assuming that e is the event in I 4 , then for the Atom type r 1 , R 2 , R 3 , T S1 , T S2 , A T , A S , there exists a sequence of events consisting of e 0 , e 1 , e 2 , e 3 and e in the thr 2 thread as follows: Since DEMatch(e 6 , e ), according to the AxiomK, then we have ∧ciphertext(e 6 ) = ciphertext(e ) ∧MatchingKeys(key(e 6 ), key(e )) ⇒ This can be Then, A S = A S ⇒ Send(e 6 ) = Rcv(e 5 ) , and since there is a recovery event e 2 in the thr 2 thread, according to the AxiomC and AxiomS, there exists e , satisfying e < e 2 ∧ RCMatch(e 2 , e ) ∧ loc(e ) = B ∨ loc(e ) = A, so a new round of protocol interaction analysis is required. Assume that e is the computation event of the protocol instance thr 3 and contains Compute() with R 2 , R 3 , similar to the analysis in the previous section, excluding the non-occurrence event R 3 . Assume that is the instance computation event of the e thr 3 thread on R 2 and that for r 2 , r 3 , R 1 , R 2 , R 3 , T T1 , T T2 , A T , the event e 0 , e 1 , e 2 , e 3 occurs for subject B. Then, From Equations (21) and (22) above, it follows that the computation event e in the thread thr 3 R 2 instance satisfies the match RCMatch(e 2 , e ) with the recovery event e 2 in the thr 2 thread. Then, ∧ciphertext(e 2 ) = ciphertext(e ) ∧ecckey(e 2 ) = ecckey(e ) ⇒ Based on the results of the above proof, it is obtained that For any thread of honest subject B, there exists a thread with message number 2 with which honest subject A forms a weak matching session. The next step to prove whether they are strong matching sessions is to prove e 4 < e 0 , e 3 < e 5 . In the case where it has been specified that subject A =B, by the definition of Rule3, we obtain (Generate(e 2 ) =< R 2 , R 3 >⇒ Fresh(e 2 , < R 2 , R 3 >))∧ B : Id.E 1 .∀e 3 : E.loc(e 2 ) = loc(e 3 ) = loc(e 4 ) = B∧ e 2 < e 3 < e 4 ∧ E(e 4 ) has < R 2 , R 3 > ∧¬(e 3 = E(Send)) ⇒ Fresh(e 4 , < R 2 , R 3 >) Then, prove that < R 2 , R 3 > is sent for the first time in the event e 4 , and from Rule2, it follows that all operations containing < R 2 , R 3 > must occur after the event e 4 , including the event Rcv(e 0 ) ==< R 2 , A T , R 3 >. Therefore, according to the AxiomS in LoET, the sequence of events e 4 < e 0 can be obtained. Similarly, e 3 < e 5 can be analysed.
In summary, it is known that any thread of subject B has a strong matching session in subject A, i.e., SP|= auth(R 3 , 2) is authenticated. The final protocol satisfies two-way strong authenticity, denoted as SP|= auth(I 3 , 2) ∧ SP|= auth(R 3 , 2) .

1.
Comparison with BAN-like logic BAN-like logic requires initialisation assumptions before analysing security protocols, which are subjective to the analyst's intentions and are not formalised. These initialisation assumptions reflect the subjective intention of the analyst and are not formal, and the idealisation of the protocols relies too much on the analyst's intuition and experience. The idealisation process will cause problems, and the idealised protocol will have some gap with the original protocol. LoET is based on rigorous mathematical rules that regulate a series of axiomatic inference rule constraints, thus ensuring the reliability of the proof process.

2.
Comparison with PCL In the verification of protocol security properties, PCL can only portray some protocol properties, not the authentication properties of data signature protocols, whereas LoET can portray the authentication properties of other properties. PCL is not rigorous enough in modelling protocol interaction actions, and it lacks the definition of a mechanism for describing the sequence of preceding actions of a thread. LoET specifies the successive thread states in which an event occurs by means of atomic independence.

Comparison with Model Checking
The verification approach of the model-checking method is falsification, while the verification approach of LoET is proof, i.e., focusing on proving that the security protocol is correct. The model-checking method requires the system model to have an infinite state space. The number of security protocols running and the number of protocol subjects will make the state space grow exponentially, although there are a series of optimisation algorithms that can reduce the size of the protocol state space, but the problem still exists Meanwhile, LoET has no requirements for the security protocol state space and will not face the problem of state explosion.

Conclusions
This paper extends logic of events theory by defining the event classes Compute, Retrieve, and Generate, adding corresponding axioms and related rules for analysing the security properties of ECC-based RFID mutual authentication protocols, formally abstracting the ECC session key establishment function, defining the protocol process and basic sequences for describing the protocol, and formalising the strong authentication properties that need to satisfied by both parties to the protocol. Theorem-proving methods are used to reason that the basic sequences of both parties of the protocol satisfy strong authentication. Based on extended LoET, we can formally analyse authentication protocols with complex encryption mechanisms (e.g., elliptic curve cryptography), extending the use of LoET.
Although this paper extends LoET to analyse the authenticity of ECC-based RFID authentication protocols, it does not take into account the security of the protocols in the actual operating environment, so further work will be carried out to verify the security at the protocol code implementation level in the future. Verification of protocol security based on a single formal approach is generally flawed and does not guarantee absolute protocol security, and attempts to combine other formal approaches are needed.