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

Abstract

Radio frequency identification (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 commercialisation 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.

1. 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 ECC-based RFID authentication protocol. In 2014, Liao et al. [8] designed an ECC-based RFID authentication scheme and proved the security of the protocol against various attacks using an efficient and convincing formal method. In 2016, Qian et al. [9] formally analysed the security of an ECC-based RFID lightweight authentication scheme using BAN logic. In 2021, Kumar et al. [10] designed a new ECC-based RFID authentication scheme by learning from the shortcomings of other scholars and simulated the protocol using AVISPA tool, and the results showed that the protocol is secure against all passive and active attacks. With the continuous development of the IoT, the advantages of information exchange and communication it provides become more and more obvious, and the security of the IoT becomes more and more important. To prevent the IoT from being invaded by malice, scholars have carried out a lot of work from the perspective of overall security [11,12,13].

At present, in the research on security analysis of ECC-based RFID authentication scheme, scholars mainly use BAN logic and some non-formal methods for analysis. The non-formal methods are based on the personal experience of scholars as well as known methods of attack on the protocol, so the security conclusions derived from the analysis of security protocols using the non-formal methods are inaccurate and unreliable. Also, because of the non-formal nature of the modal logic idealisation process, the incomplete logical semantics, and the over-reliance on initial assumptions, it is difficult to use it to institute ECC-based RFID security protocols and to carve out the security properties that need to be satisfied.

LoET belongs to the theorem-proving method, a formal logic for analysing the security of distributed systems [14]. In 2009, Meihua Xiao, in collaboration with the proponents of the logic of events theory, addressed the shortcomings of PCL [15] (Protocol Composition Logic), and he applied LoET to analyse security protocols [16]. In recent years, Prof. Meihua Xiao has led a team to extend LoET to formally analyse the security of security protocols in several different domains [17,18,19]. However, the existing LoET also has limitations: for some authentication protocols with complex cryptographic schemes, the event logic theory cannot perform a formal analysis of them.

In this paper, we look at the authentication protocol’s own authentication to verify the security of the protocol, so as to determine whether there is a replay attack on the protocol, which ensures the security of IoT information exchange. The main work and the innovations of this paper are as follows:

• Extending logic of events theory. Two new event classes are added, and relevant axioms and rules are expanded.
• 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.
• 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.

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

2.1. Symbol Description

The basic notations and semantics are given in

Table 1. The basic notations and semantics.

Notations	Semantics	Notations	Semantics
Id	Principals involved in protocols	Send(e)	Sending message from e
Atom	Class of secret information category	Rcv(e)	Receiving message from e
Data	All of the messages and plaintext	Encrypt(e)	Encrypting event
x	Members in data	Decrypt(e)	Decrypting event
e	An event	Sign(e)	Signature event
E	Event set	Verify(e)	Verification event
nonce	The set of random number	bs	Basic sequence
loc(e)	The location of event e	<	Cause and effect sequence of events
has	Logic contains	Key(e)	The secret key of the principal of event e
New(e)	A nonce in event e

.

2.2. Basic Concept

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

$$Thread{\equiv }_{def}\left\{thr:Act List|\forall i:thr[i]{<}_{loc}thr[i+1]\right\}$$

(1)

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\sim r$; if $s\sim r$ is satisfied and $s$ is a preorder event of $r$, then a strong match $s\mapsto r$ is formed, as defined below.

$$\left(\begin{array}{l}s\sim r{\equiv }_{def}s\in E(Send)\wedge r\in E(Rcv)\wedge Send(s)=Rcv(r)\\ s\mapsto r{\equiv }_{def}s\sim r\wedge s<r\end{array}\right)$$

(2)

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 $th{r}_1\stackrel{n}{\approx }th{r}_2$. If the above message event pairs satisfy only weak matching, then a weak matching session is satisfied, as $th{r}_1\stackrel{n}{\sim }th{r}_2$.

2.2.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:

$$\begin{array}{c}Pr\models auth(bs,n){\equiv }_{def}\\ \left(\begin{array}{c}\forall A,B.\forall th{r}_1.\\ (Honest(A)\wedge Honest(B)\wedge Pr(A)\wedge Pr(B)\wedge \\ A\ne B\wedge loc(th{r}_1)=A\wedge bs(A,B,th{r}_1))\end{array}\right)\Rightarrow \\ \exists th{r}_2.loc(th{r}_2)=B\wedge th{r}_1\stackrel{n}{\approx }th{r}_2\end{array}$$

(3)

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

2.3.1. 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{\equiv }_{def}Id\hspace{0.17em}+\hspace{0.17em}Atom\hspace{0.17em}+\hspace{0.17em}Atom$.

$$\begin{array}{c}AxiomK:\forall A,B:Id.\forall k,k^{\prime }:Key.\forall a:Atom\\ \left(\begin{array}{l}MatchingKeys(k;k^{\prime })\iff MatchingKeys(k^{\prime };k)\wedge \\ MatchingKeys(Symm(a);k)\iff k=Symm(a)\wedge \\ MatchingKeys(PrivKey(A);k)\iff k=A\wedge \\ MatchingKeys(A;k)\iff k=PrivKey(A)\wedge \\ PrivKey(A)=PrivKey(B)\iff A=B\end{array}\right)\end{array}$$

(4)

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.

2.3.2. Casual Axiom

The Causal Axiom relates the causal relationships between events and consists of $AxiomR$, $AxiomV$, and $AxiomD$. The detailed equation is shown below.

$$\left(\begin{array}{c}AxiomR:\forall e:E(Rcv).\exists e^{\prime }:E(Send).(e^{\prime }<e)\wedge Rcv(e)=Send(e^{\prime })\\ AxiomV:\forall e:E(Verify).\exists e^{\prime }:E(Sign).(e^{\prime }<e)\wedge Verify(e)=Sign(e^{\prime })\\ AxiomD:\forall e:E(Decrypt).\exists e^{\prime }:E(Encrypt).e^{\prime }<e\wedge DEMatch(e,e^{\prime }){\equiv }_{def}\\ plaintext(e)=plaintext(e^{\prime })\wedge ciphertext(e)=ciphertext(e^{\prime })\wedge \\ MatchingKeys(key(e);key(e^{\prime }))\end{array}\right)$$

(5)

$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 $Verify$ 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.

2.3.3. 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).

$$\begin{array}{c}AxiomS:\\ \forall A:Id.\forall s:E(Sign).\forall e:E(Encrypt).\forall d:E(Decrypt).Honest(A)\Rightarrow \\ \left(\begin{array}{c}signer(s)=A\Rightarrow (loc(s)=A)\wedge \\ key(e)=PrivateKey(A)\Rightarrow (loc(e)=A)\wedge \\ key(d)=PrivateKey(A)\Rightarrow (loc(d)=A)\end{array}\right)\end{array}$$

(6)

2.4. Extension of LoET

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

$$\{\begin{array}{l}New:EClass(Atom)\\ Send,Rcv:EClass(Data)\\ Encrypt,Decrypt:EClass(Data\times {\rm K}ey\times Atom)\\ Sign,Verify:EClass(Data\times Id\times Atom)\end{array}$$

(7)

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.

$$\left(\begin{array}{c}Compute,Retrieve:EClass(Data\times Ecckey\times Atom)\\ Generate:EClass(Data\times Ecckey)\end{array}\right)$$

(8)

If there exists an event $e_1$ satisfying $e_1\in 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\in 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\in E(Generate)$, then in the event $e$, the subject performs an elliptic curve scalar multiplication calculation and generates a public key.

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

$$\left(\begin{array}{c} \mathrm{AxiomC}:\\ \forall e:E(Retrieve).\exists e^{\prime }:E(Compute).\hfill \\ (e^{\prime }<e)\wedge Retrieve(e)=Compute(e^{\prime })\hfill \\ \wedge RCMatch(e,e^{\prime }){\equiv }_{def}plaintext(e)=plaintext(e^{\prime })\hfill \\ \hfill \wedge ciphertext(e)=ciphertext(e^{\prime })\\ \wedge ecckey(e)=ecckey(e^{\prime })\end{array}\right)$$

(9)

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.

$$\left(\begin{array}{l}Rule1(generate\hspace{0.17em}rule):\\ \forall A:Id.\exists e:E(Generate)=Generate(rP,R).\\ loc(e)=A\wedge e has\hspace{0.17em}(r,R)\end{array}\right)$$

(10)

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.

$$\left(\begin{array}{l}Rule2(unique\hspace{0.17em}ecckey\hspace{0.17em}rule):\\ \forall A:Id.\exists e_1:E(Generate)=Generate(rP,R).\\ \exists e_2:E(Send).e_1<e_2\wedge loc(e_1)=loc(e_2)=A\wedge \\ Send(e_2)\hspace{0.17em}has\hspace{0.17em}(r,R)\Rightarrow \\ \exists B:Id.\exists e_3:E(Rcv).loc(e_3)=B\wedge e_3\hspace{0.17em}has\hspace{0.17em}R\end{array}\right)$$

(11)

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.

$$\left(\begin{array}{c}Rule3(fresh\hspace{0.17em}ecckey\hspace{0.17em}rule):\\ (Generate(e_0)=R\Rightarrow Fresh(e_0,R))\vee \\ \left(\begin{array}{l}\forall A:Id.\exists e_1:E(Generate).\forall e_2:E_1.\exists e_3:E_2.loc(e_1)=loc(e_2)=loc(e_3)=A\wedge \\ e_1<e_2<e_3\wedge E_2(e_3)\hspace{0.17em}has\hspace{0.17em}R\wedge (\neg Send(e_2)\hspace{0.17em}has\hspace{0.17em}R)\vee \neg (e_2=E(Send))\end{array}\right)\Rightarrow \\ Fresh(e_3,R)\end{array}\right)$$

(12)

3. 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: $Tag\to Server:m_2=\left\{R_1\right\}$.

(2)

As the initiator, server generates a random number $r_1$ and performs a scalar multiplication operation, sending $R_1$ to tag.

(3)

Server authenticates tag: $Tag\to Server:m_2=\{R_2,R_3,A_T\}$.

(4)

After receiving the message, the tag generates a random number $r_2,r_3$, performs a scalar multiplication calculation, generates the authentication message ${\mathrm{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\to Tag:m_3=\left\{A_S\right\}$

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

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

4.1. 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 $SP|=auth(I_3,2)$.

$$\begin{array}{c}SP|=auth(I_3,2)\equiv def\forall Initiator,Responder.\forall thr1.\\ (Honest(Initiator)\wedge Honest(Responder)\\ \wedge SP(Initiator)\wedge SP(Responder)\\ \wedge Initiator\ne Responder\wedge loc(thr1)=Initiator\\ \wedge bs(Initiator,Responder,thr1))\\ \Rightarrow \exists thr2.loc(thr2)=Responder\wedge th{r}_1\stackrel{2}{\approx }th{r}_2\end{array}$$

(13)

Accordingly, the Responder must prove a strong authenticity that is $SP|=auth(R_3,2)$.

4.2. $SP|=auth(I_3,2)$ Proof Process

Assume that the honest subject $Initiator\ne 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 $th{r}_1$ be an instance of the basic sequence $I_3$. Then, there exists $e_0{<}_{loc}{e}_1{<}_{loc}\dots {<}_{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 $th{r}_1$ are

$$\left(\begin{array}{l}New(e_0)=<r_1>\wedge Generate(e_1)=<r_{1}P,R_1>\wedge Send(e_2)=<R_1>\wedge \\ Rcv(e_3)=<R_2,A_T,R_3>\wedge Generate(e_4)=<<x_S{R}_2,r_1{R}_2>,<T_{S1},T_{S2}>>\wedge \\ Retrieve(e_5)=<X_T,<T_{S1},T_{S2}>,A_T>\wedge Encrypt(e_6)=<R_3,x_S,A_S>\wedge \\ Send(e_7)=<A_S>\end{array}\right)$$

(14)

From the $AxiomC$ and $AxiomS$, for the recovery event $e_5$, there must be a computation event $e^{\prime }$ in some thread of the protocol and $e^{\prime }<e_5\wedge RCMatch(e_5,e^{\prime })\wedge loc(e^{\prime })=B\vee loc(e^{\prime })=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^{\prime }$ is the event in the $R_2$ sequence thread $th{r}_2$, then for the Atom type $r_2{}^{\prime },r_3{}^{\prime },R_1{}^{\prime },R_2{}^{\prime },R_3{}^{\prime },T_{T1}{}^{\prime },T_{T2}{}^{\prime },A_T{}^{\prime }$, the sequence of events $e_0{}^{\prime },e_1{}^{\prime },e_2{}^{\prime },e_3{}^{\prime }$ and $e^{\prime }$ on subject $B$ is present as

$$\left(\begin{array}{c}{e}_0{}^{\prime }{<}_{loc}{e}_1{}^{\prime }{<}_{loc}{e}_2{}^{\prime }{<}_{loc}{e}^{\prime }{<}_{loc}{e}_3{}^{\prime }\wedge \\ Rcv(e_0{}^{\prime })=<R_1{}^{\prime }>\wedge New(e_1{}^{\prime })=<r_2{}^{\prime },r_3{}^{\prime }>\wedge \\ Generate(e_2{}^{\prime })=<<r_2{}^{\prime }{P}^{\prime },r_3{}^{\prime }{P}^{\prime },r_2{}^{\prime }{P}_S{}^{\prime },r_2{}^{\prime }{R}_1{}^{\prime }>,<R_2{}^{\prime },R_3{}^{\prime },T_{T1}{}^{\prime },T_{T2}{}^{\prime }>>\wedge \\ Compute(e^{\prime })=<X_T{}^{\prime },<T_{T1}{}^{\prime },T_{T2}{}^{\prime }>,A_T{}^{\prime }>\wedge \\ Send(e_3{}^{\prime })=<R_2{}^{\prime },A_T{}^{\prime },R_3{}^{\prime }>\end{array}\right)$$

(15)

Since $RCMatch(e_5,e^{\prime })$, then

$$\left(\begin{array}{c}plaintext(e_5)=plaintext(e^{\prime })\\ \wedge ciphertext(e_5)=ciphertext(e^{\prime })\\ \wedge ecckey(e_5)=ecckey(e^{\prime })\Rightarrow \\ X_T{}^{\prime }=X_T\wedge A_T{}^{\prime }=A_T\end{array}\right)$$

(16)

can be derived.

$$\left(\begin{array}{c}{e}_0{}^{\prime }{<}_{loc}{e}_1{}^{\prime }{<}_{loc}{e}_2{}^{\prime }{<}_{loc}{e}^{\prime }{<}_{loc}{e}_3{}^{\prime }\wedge \\ Rcv(e_0{}^{\prime })=<R_1>\wedge New(e_1)=<r_2,r_3>\wedge \\ Generate(e_2{}^{\prime })=<<r_{2}P,r_{3}P,r_2{P}_S,r_2{R}_1>,<R_2,R_3,T_{T1},T_{T2}>>\wedge \\ Compute(e^{\prime })=<X_T,<T_{T1},T_{T2}>,A_T>\wedge \\ Send(e_3{}^{\prime })=<R_2,A_T,R_3>\end{array}\right)$$

(17)

From (14)–(17), we can see that $Send(e_2)=<R_1>=Rcv(e_0{}^{\prime })$ and $Rcv(e_3)=<R_2,A_T,R_3>=Send(e_3{}^{\prime })$, $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{}^{\prime },e_3{}^{\prime }<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{}^{\prime })=<R_1>$. Therefore, according to the honesty axiom in LoET, the sequence of events $e_2<e_0{}^{\prime }$ can be obtained. Similarly, $e_3{}^{\prime }<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.

4.3. $SP|=auth(R_3,2)$ Proof Process

Let $th{r}_1$ be an instance of the basic sequence $R_3$ in entity $B$. Define $e_0{<}_{loc}{e}_1{<}_{loc}\dots {<}_{loc}{e}_6$ to be the event of the thread $th{r}_1$. Then, for Atom type parameters $r_2,r_3,R_1,R_2,R_3,T_{T1},T_{T2},A_T,A_S$, have

$$\left(\begin{array}{c}Rcv(e_0)=<R_1>\wedge New(e_1)=<r_2,r_3>\wedge \\ Generate(e_2)=<<r_{2}P,r_{3}P,r_2{P}_S,r_2{R}_1>,<R_2,R_3,T_{T1},T_{T2}>>\wedge \\ Compute(e_3)=<X_T,<T_{T1},T_{T2}>,A_T>\wedge Send(e_4)=<R_2,A_T,R_3>\wedge \\ Rcv(e_5)=<A_S>\wedge Decrypt(e_6)=<R_3,P_S,A_S>\end{array}\right)$$

(18)

Based on the $AxiomD$ and $AxiomS$, there exists an encryption event $e^{\prime }$ that matches the decryption event $e_6$ and $e^{\prime }<e_6\wedge DEMatch(e_6,e^{\prime })\wedge loc(e^{\prime })=B\vee loc(e^{\prime })=A$, and the encryption action that contains $Encrypt()$ among all the basic sequences of the protocol is $I_4$. Assuming that $e^{\prime }$ is the event in $I_4$, then for the Atom type $r_1{}^{\prime },R_2{}^{\prime },R_3{}^{\prime },T_{S1}{}^{\prime },T_{S2}{}^{\prime },A_T{}^{\prime },A_S{}^{\prime }$, there exists a sequence of events consisting of $e_0{}^{\prime },e_1{}^{\prime },e_2{}^{\prime },e_3{}^{\prime }$ and $e^{\prime }$ in the $th{r}_2$ thread as follows:

$$\left(\begin{array}{c}{e}_0{}^{\prime }{<}_{loc}{e}_1{}^{\prime }{<}_{loc}{e}_2{}^{\prime }{<}_{loc}{e}^{\prime }{<}_{loc}{e}_3{}^{\prime }\wedge \\ Rcv(e_0{}^{\prime })=<R_2{}^{\prime },A_T{}^{\prime },R_3{}^{\prime }>\wedge Generate(e_1{}^{\prime })=<<x_S{}^{\prime }{R}_2{}^{\prime },r_1{}^{\prime }{R}_2{}^{\prime }>,<T_{S1}{}^{\prime },T_{S2}{}^{\prime }>>\wedge \\ Retrieve(e_2{}^{\prime })=<X_T{}^{\prime },<T_{S1}{}^{\prime },T_{S2}{}^{\prime }>,A_T{}^{\prime }>\wedge Encrypt(e^{\prime })=<R_3{}^{\prime },x_S{}^{\prime },A_S{}^{\prime }>\wedge \\ Send(e_3{}^{\prime })=<A_S{}^{\prime }>\end{array}\right)$$

(19)

Since $DEMatch(e_6,e^{\prime })$, according to the $AxiomK$, then we have

$$\left(\begin{array}{c}plaintext(e_6)=plaintext(e^{\prime })\\ \wedge ciphertext(e_6)=ciphertext(e^{\prime })\\ \wedge MatchingKeys(key(e_6),key(e^{\prime }))\Rightarrow \\ R_3{}^{\prime }=R_3\wedge A_S{}^{\prime }=A_S\end{array}\right)$$

(20)

This can be

$$\left(\begin{array}{c}{e}_0{}^{\prime }{<}_{loc}{e}_1{}^{\prime }{<}_{loc}{e}_2{}^{\prime }{<}_{loc}{e}^{\prime }{<}_{loc}{e}_3{}^{\prime }\wedge \\ Rcv(e_0{}^{\prime })=<R_2,A_T,R_3>\wedge Generate(e_1{}^{\prime })=<<x_S{R}_2,r_1{R}_2>,<T_{S1},T_{S2}>>\wedge \\ Retrieve(e_2{}^{\prime })=<X_T,<T_{S1},T_{S2}>,A_T>\wedge Encrypt(e^{\prime })=<R_3,x_S,A_S>\wedge \\ Send(e_3{}^{\prime })=<A_S>\end{array}\right)$$

(21)

Then, $A_S{}^{\prime }=A_S\Rightarrow Send(e_6{}^{\prime })=Rcv(e_5)$, and since there is a recovery event $e_2{}^{\prime }$ in the $th{r}_2$ thread, according to the $AxiomC$ and $AxiomS$, there exists $e^{″}$, satisfying $e^{″}<e_2{}^{\prime }\wedge RCMatch(e_2{}^{\prime },e^{″})\wedge loc(e^{″})=B\vee loc(e^{″})=A$, so a new round of protocol interaction analysis is required. Assume that $e^{″}$ is the computation event of the protocol instance $th{r}_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^{″}$$th{r}_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,

$$\left(\begin{array}{c}{e}_0{}^{″}{<}_{loc}{e}_1{}^{″}{<}_{loc}{e}_2{}^{″}{<}_{loc}{e}^{″}{<}_{loc}{e}_3{}^{″}\wedge \\ Rcv(e_0{}^{″})=<R_1{}^{″}>\wedge New(e_1{}^{″})=<r_2{}^{″},r_3{}^{″}>\wedge \\ Generate(e_2{}^{″})=<<r_2{}^{″}{P}^{″},r_3{}^{″}{P}^{″},r_2{}^{″}{P}_S{}^{″},r_2{}^{″}{R}_1{}^{″}>,<R_2{}^{″},R_3{}^{″},T_{T1}{}^{″},T_{T2}{}^{″}>>\wedge \\ Compute(e^{″})=<X_T{}^{″},<T_{T1}{}^{″},T_{T2}{}^{″}>,A_T{}^{″}>\wedge \\ Send(e_3{}^{″})=<R_2{}^{″},A_T{}^{″},R_3{}^{″}>\end{array}\right)$$

(22)

From Equations (21) and (22) above, it follows that the computation event $e^{″}$ in the thread $th{r}_3$$R_2$ instance satisfies the match $RCMatch(e_2{}^{\prime },e^{″})$ with the recovery event $e_2{}^{\prime }$ in the $th{r}_2$ thread. Then,

$$\left(\begin{array}{c}plaintext(e_2{}^{\prime })=plaintext(e^{″})\\ \wedge ciphertext(e_2{}^{\prime })=ciphertext(e^{″})\\ \wedge ecckey(e_2{}^{\prime })=ecckey(e^{″})\Rightarrow \\ X_T{}^{″}=X_T{}^{\prime }=X_T\wedge A_T{}^{″}=A_T{}^{\prime }=A_T\end{array}\right)$$

(23)

There are

$$\left(\begin{array}{c}{e}_0{}^{″}{<}_{loc}{e}_1{}^{″}{<}_{loc}{e}_2{}^{″}{<}_{loc}{e}^{″}{<}_{loc}{e}_3{}^{″}\wedge \\ Rcv(e_0{}^{″})=<R_1>\wedge New(e_1{}^{″})=<r_2,r_3>\wedge \\ Generate(e_2{}^{″})=<<r_{2}P,r_{3}P,r_2{P}_S,r_2{R}_1>,<R_2,R_3,T_{T1},T_{T2}>>\wedge \\ Compute(e^{″})=<X_T,<T_{T1},T_{T2}>,A_T>\wedge \\ Send(e_3{}^{″})=<R_2,A_T,R_3>\end{array}\right)$$

(24)

Based on the results of the above proof, it is obtained that

$$\left(\begin{array}{l}Rcv(e_0{}^{\prime })==<R_2,A_T,R_3>=Send(e_4)\\ \wedge Rcv(e_5)=<A_S>=Send(e_3{}^{\prime })\end{array}\right)$$

(25)

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{}^{\prime },e_3{}^{\prime }<e_5$. In the case where it has been specified that subject $A$≠$B$, by the definition of $Rule3$, we obtain

$$\begin{array}{c}(Generate(e_2)=<R_2,R_3>\Rightarrow Fresh(e_2,<R_2,R_3>))\wedge \\ \left(\begin{array}{l}B:Id.E_1.\forall e_3:E.loc(e_2)=loc(e_3)=loc(e_4)=B\wedge \\ e_2<e_3<e_4\wedge E(e_4)\hspace{0.17em}has\hspace{0.17em}<R_2,R_3>\wedge \neg (e_3=E(Send))\end{array}\right)\Rightarrow \\ Fresh(e_4,<R_2,R_3>)\end{array}$$

(26)

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{}^{\prime })==<R_2,A_T,R_3>$. Therefore, according to the $AxiomS$ in LoET, the sequence of events $e_4<e_0{}^{\prime }$ can be obtained. Similarly, $e_3{}^{\prime }<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)\wedge SP|=auth(R_3,2)$.

4.4. Comparison with Other Typical Proof Methods

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

3.

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.

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