Proving Mutual Authentication Property of Industrial Internet of Things Multi-Factor Authentication Protocol Based on Logic of Events

Abstract

Security protocols are the basis of modern network communication, proving that the security problem of protocols is one of the hot research topics today. The data in industrial IoT are usually transmitted through insecure channels, which brings certain security risks. The Logic of Events is a formal method for proving the security properties of protocols based on event systems. The new theoretical extension is based on the Logic of Events theory, which proposes new event classes Compurte, TimeGap, Construct, and Reconstruct and an axiom AxiomRe and related inference rules for malicious attacks and security privacy issues in emerging protocols, as well as extending the matching descriptions of protocol behaviours in complex cryptographic algorithms and information sharing techniques for applications for the formal analysis of authentication protocols for the Industrial Internet of Things. Finally, formal analysis is carried out using the example of a secure multi-factor authentication protocol for the industrial IoT, which proves the security of the protocol.

1. Introduction

The Internet of Things (IoT) plays an indispensable role in the smart era. IoT data are extremely private and valuable, and privacy protection and secure communication have always been the focus of attention [1]. Data are often transmitted through insecure channels, which gives rise to security and privacy issues arising from malicious attacks on the IoT [2]. In order to defend against malicious attacks by adversaries and to secure the transmitted data, researchers have proposed a large number of key negotiation schemes, which require the formal analysis of the security properties of security protocols [3]. The commonly used formal methods include theorem proving [4] and Model Checking [5]. Currently, the commonly used formal description techniques for protocols include the finite state machine model, the Petri net model, the Logic of Events theory, and the Common Authentication Protocol Specification Language (CAPSL) [6].

The Logic of Events theory is a theorem-proving formal logic used for analysing the security of distributed systems [7]. In 2009, Xiao Meihua et al. [8,9,10] used the Logic of Events for the first time in the formal analysis of security protocols. The Logic of Events theory mainly includes event systems, axiom systems, inference rules, and formal description protocols. The Logic of Events theory can formally describe cryptographic protocols and security properties by deriving the interactions between honest subjects in cryptographic protocols without analysing the behaviour of the attackers [11].

The multi-factor authentication protocols for the Industrial Internet of Things aim at fulfilling user authentication and key agreement schemes dealing with security and privacy issues. In 1991, Chang et al. pioneered a smartcard-based authentication scheme, which is also the basis of a three-factor authentication scheme [12]. In 2014, Yuan [13] first used finger-print-based biometrics to implement a lightweight authentication protocol for wireless sensor networks, but it was later shown to be incapable of resist offline password guessing attacks, privileged insider attacks, and gateway node masquerading attacks, and offers no protection against interrogation results. In 2017, Srinivas et al. [14] demonstrated that the Das scheme is not able to withstand denial-of-service attacks and node intrusion attacks. To secure communication in wireless sensor networks, Srinivas et al. proposed an improved authentication scheme that addresses the irreversibility and privacy issues of traditional biometrics. In 2018, Wang et al. [15] found that Srinivas et al.’s scheme is susceptible to offline guessing attacks and does not support users’ anonymity. In 2018, Li et al. designed an IoT-oriented three-factor authentication scheme using biometrics for the Internet and proposed a three-factor authentication scheme based on ECC (Elliptic Curve Cryptography), but the scheme could not resist smart card loss attacks and did not provide forward security. In 2019, Guo et al. [16] found that the protocol of Wu et al. could not resist offline password and identity guessing attacks, insider attacks, and user tracking attacks, sensor forgery attacks, and proposed a provably secure three-factor AKA (authentication and key agreement) protocol for mobile lightweight devices based on extended chaotic mapping. In 2020, Yu et al. [17] combined IoT with cloud computing and proposed an improved IoT-based authentication scheme for cloud computing environments.

This paper develops a theoretical extension related to the security and privacy issues arising from malicious attacks in IoT protocols based on the Logic of Events (LoET). The secure multi-factor authentication protocol [18] for the industrial IoT is defined as an example, and a formal description of the protocol is given to prove the security of the protocol. The contributions of this paper are as follows:

• The introduction of the computational event class $Compute$ with corresponding inference rules extends the ability of Logic of Events to describe algorithms;
• The definition of $TimeGap$ is given, and the relationship of time during protocol interaction is given according to its definition;
• The $Construct,Reconstruct$ and the corresponding axiom $AxiomRe$ are introduced for describing the key decomposition and reconstruction, and successfully proving some of the security properties of multi-factor authentication protocols for the Industrial Internet of Things.

The paper is organised as follows: Section 1 introduces the Logic of Events and related theories and proposes related extensions based on the Logic of Events; Section 2 introduces the secure multi-factor authentication protocol for the industrial IoT; Section 3 provides a detailed proof of the secure multi-factor authentication protocol for the industrial IoT; and Section 4 concludes the paper.

2. Logic of Events Theory

The Logic of Events Affiliation Theorem-Proving Method is a formal method that is based on the design of message automata and defines the possible protocol actions. The method provides new proof rules and mechanisms for protocol actions by assigning keys, challenge numbers, and different types of messages. The security of cryptographic protocols can be verified through the Logic of Events theory approach, which constructs an authentication theory by defining events, event classes, and event structures and proves the strong authentication nature of the protocol.

2.1. Basic Concepts

Security protocols can be abstracted into a model with addresses and events as basic types that have the characteristics of concurrent systems, including temporality and spatiality. The different addresses communicate with each other through message interactions. Information is stored in the addresses in various forms and passed between the different addresses according to different message forms. To describe the different message forms, the following table lists the interpretation and semantics of some of the Logic of Events symbols. The basic notations and semantics are given in

Table 1. Basic symbols and semantics.

Basic Symbol	Meaning of Words
$Atom$	Classes representing secret information
$Data$	All messages and plaintext
$e$	Indicates an event
$E$	denotes the set of events
$Nonce$	random number event
$n$	$Nonce$$A$ random number in the event
$\parallel$	Logical relationships indicate independence
$\le$	Denote the local finite partial order
$loc(e)$	$loc(e)$ is a function on $E$ that represents the body of the event $e$ that occurred
$Key(e)$	Event $e$ Subject’s key
$New(e)$	Random numbers in the event $e$
$Send(e)$	$Data$ class message sent in event $e$
$Rcv(e)$	$Data$ class message received in event $e$
$Encrypt(e)=<x,k,c>$	The body of the event $e$ encrypts the plaintext $x$ with the key $k$ to get the ciphertext $c$.
$Decrypt(e^{\prime })=<x,k^{\prime },c>$	$\mathrm{The} \mathrm{body} \mathrm{of} \mathrm{the} \mathrm{event} e^{\prime }$ decrypts the ciphertext $c$ with the key $\mathrm{with} \mathrm{the} \mathrm{key} k^{\prime }$ to get the plaintext $x$.
$e_1<e_2$	$\mathrm{Indicates} \mathrm{that} \mathrm{the} \mathrm{event} e_1$$\mathrm{occurred} \mathrm{before} \mathrm{the} \mathrm{event} e_2$
$<E,loc,<,info>$	Indicates event language

.

There are three main proto-type values used to construct the Logic of Events theory authentication, including Boolean values, identifiers, and atomic types. Boolean values are used to determine the truth and falsehoods, identifiers are used to separate the subjects, and the atomic type $Atom$ denotes unguessable information, where the members are denoted by $atoms$, and $atoms$ are unpredictable. $Atom$-type members are basic elements that have no structure and cannot be generated. $atoms$ is the first step in building a model, the computational system is a generic model in distributed systems, i.e., message automata.

Independence refers to the logical theory of events that defines $(\mathrm{State} \mathrm{after} e)$ to denote the state in which the subject emerges after the event $atoms$ occurs, and the event $e$ is essentially a space or point in time. $atoms$, it is a term of the paradigm $tok(b)$, of which $b$ is a parameter. The independence proposition $(x:T\parallel a)$ is true if, and only if, $a$ is the value $tok(b)$, and $y$ exists, satisfying $\left(x=y\in T\right)\wedge y\notin b$.

Event structure is the formal model of distributed computing that can be defined for distributed system arithmetic and authentication. In computing, messages such as $e$, $events$, are migrated, and the initial stage of information interaction is $info(e)$. The set of events is the spatial time point of the appearance of the event in some storage location of the message (e.g., the subject at the time of the event processes, or threads); the events do not overlap at a single location time point because it they have an overall order. Regardless of any migration (message passing and message sharing), causal sequences are generated between the subjects of the event.

2.1.1. Threads and Matching Sessions

A thread is an ordered list, the elements of which are the actions of a single state, but at a given location, and its formal formula is defined as follows.

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

(1)

$thr1$ and $thr2$ are two threads. There is a sequential or causal relationship between $thr1$ and $thr2$. That is, both threads, $thr1$ and $thr2$, may occur adjacent to each other before the other, and there is a causal relationship. The only information interacting in the threads is $Send$ and $Rcv$, and the corresponding actions $Send(s)$ and $Rec(r)$.

If two messages exist, $s$ and $r$, where message $s$ is a sending message, and message $r$ is a receiving message with the same content as message $s$, then message $s$ forms a weak match with message $r$, denoted as $s~r$. If a sequential relationship between message $s$ and message $r$ exists, in which message $s$ is preceded by message $r$, then there exists a direct causal relationship between message $s$ and message $r$, and then a strong match is formed, denoted as $s\mapsto r$.

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

(2)

2.1.2. Protocol Descriptions

LoET defines the protocols using basic sequences of the type Basic, which are formally described as predicates on state relations. One can formally define the protocol Pr steps as follows: assume that an honest subject A that follows the protocol, and that subject B is also an honest subject that follows the protocol. If subject A initiates an instance of a basic sequence, subject B initiates a response sequence that forms a legitimate matching dialog with A’s sequence, and the first and second message-matching sessions in the basic sequence of the protocol are formed from the above instance.

$$\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.1.3. Event Class

An event class ($Event Class$) refers to the Logic of Events theory using event sequences and another key concept event class, which describes the protocol by categorising the events in the protocol. During the protocol operation, there are message sending and receiving, challenge number generation, signing, signature verification, and encryption and decryption events; events in each class have associated information, and the type of this information depends on the event class. The following is a list of types of these seven event classes:

$$\left\{\begin{array}{l}New:EClass(Atom)\\ Send,Rcv:EClass(Data)\\ Encrypt,Decrypt:EClass(Data\times Key\times Atom)\\ Sign,Verify:EClass(Data\times Id\times Atom)\end{array}\right.$$

(4)

2.1.4. Key Axiom

Key axioms ($AxiomK$) specify the relationships between the keys. These relationships include key matching, which is a symmetric relationship. When using symmetric encryption algorithms, the key matches itself, whereas in asymmetric encryption algorithms, the subject’s private key is matched only with the corresponding public key. The public key is usually represented by a subject identifier, and different subjects will not have the same private key. This means that each subject’s private key is unique. The $MatchingKeys$ function is defined to represent the matching relationship between two keys, and the $PrivKey$ function is defined to assign an $atom$ private key to each subject. The details are shown below:

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

(5)

2.1.5. Honest Axiom

Honesty axioms ($HonestAxiom$ and $AxiomS$), according to the Logic of Events theory, contain the function $Honest:Id\to \mathbb{B}$, which makes an assumption about the honest subject and that the honest subject’s private key will not be released. The signature event, encryption event and decryption event all occur on the current honest subject, and the honesty axiom $AxiomS$ characterises the nature of the honest signer as follows:

$$\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}{l}signer(s)=A\Rightarrow (loc(s))=A\wedge \\ key(e)=\mathrm{Pr}ivateKey(A)\Rightarrow (loc(e)=A)\wedge \\ key(d)=\mathrm{Pr}ivateKey(A)\Rightarrow (loc(d)=A)\end{array}\right\}\end{array}$$

(6)

2.1.6. Causal Axioms

Causal axioms ($CausalAxioms$) are the event axioms corresponding to receive $Rcv$, verify $Verify$, and decrypt $Decrypt$ in the event class, and the relationship between the receive axiom $AxiomR$, verify axiom $AxiomV$, and decrypt axiom $AxiomD$ is integrated. The receive axiom $AxiomR$ is similar to the verify axiom $AxiomV$ in that any receive or verify event is preceded by a corresponding send or sign event with the same message content. The formal expression is as follows:

$$\left(\begin{array}{l}AxiomR:\forall e:E(Rcv).\exists e^{\prime }:E(Send).\\ Rcv(e)=Send(e^{\prime })\wedge e^{\prime }<e\\ AxiomV:\forall e:E(Verify).\exists e^{\prime }:E(Sign).\\ Verify(e)=Sign(e^{\prime })\wedge e^{\prime }<e\end{array}\right)$$

(7)

The decryption axiom $AxiomD$ indicates that any decryption event must be preceded by a corresponding encryption event, and that the encryption and decryption events have the same plaintext and ciphertext, and the ciphertexts match, as defined below:

$$\left(\begin{array}{l}AxiomD:\forall e:E(Decrypt).\exists e^{\prime }:E(Encrypt).e^{\prime }<e\wedge DEMatch(e,e^{\prime }){\equiv }_{def}\\ pla\mathrm{int}ext(e)=pla\mathrm{int}ext(e^{\prime })\wedge ciphertext(e)=ciphertext(e^{\prime })\\ \wedge MatchingKeys(key(e);key(e^{\prime }))\end{array}\right)$$

(8)

2.2. Event Classes and Related Axiomatic Extensions

Among the current emerging protocols, the protocol encryption mechanisms are more diverse, and the behaviour of the participants is more complex, so four new event classes $Compute,TimeGap,Construct,Reconstruct$ and a new axiom $AxiomRe$ are proposed to describe the protocols more accurately.

2.2.1. Compute

The information associated with the event $e$ in the event class $Compute$ is of type $Data\times ID\times Mesg$ ternary. If an event $e$ exists that satisfies $e\in E(Compute)$ with $Compute(e)=<x,A,Mesg>$, then the event $e$ on the subject $A$ encrypts the data item $x$ using a hash function and generates the encrypted message $Mesg$. Once a responder $B$ receives the message, then $Compute(x,B,Mesg)$ also holds. In other words, $E(Compute)$ applies to both the senders and responders.

$$\left(\begin{array}{c}Compute:EClass(Data\times ID\times Mesg)\\ \exists A,B:Id.\forall e:E(Compute).\\ \exists e^{\prime }:E(Compute).Honest(A)\\ Compute(x,A,Mesg)\wedge send(Mesg)\\ \vee Compute(x,B,Mesg)\end{array}\right)$$

(9)

2.2.2. TimeGap

An honest subject $A$ exists with events $e_1$ and $e_1\in E(Send)$, and an honest subject $B$ exists with events $e_2$ and $e_2\in E(Rev)$, where $B\ne A$. The honest subject $A$ sends a message containing $t_1$, and the honest subject $B$ receives a message containing $t_1$ and records the current time $t_2$ and compares the size of the two to generate $t^{\prime }$, which is used to verify that the time interval is within a reasonable range, i.e., $TimeGap(t_1,t_2,t^{\prime })$; the formal definition of the time interval is as follows:

$$\left(\begin{array}{l}\forall A:Id.\exists e_1:E(Send)\wedge \forall B:Id.\exists e_2:E(Rev)\\ \wedge loc(e_1)=A\wedge loc(e_2)=B\wedge (e_1<e_2)\\ e_1 has t_1\wedge e_2 has t_1\wedge (t_1\parallel t_2)\Rightarrow t^{\prime }\end{array}\right)$$

(10)

2.2.3. Construct

The event class $Construct$ has an event $e$ with the $Atom\times ID\times Data$ ternary type. A number of subjects $A$ exist, in which the event $S$ is divided into at least $j$ parts, and $s$ and $s$ are indivisible. Each subject gets one of these parts $s_j$. A single subject cannot learn anything about $S$ because they only hold one of the $s_j$ and cannot derive the other points.

$$\left(\begin{array}{l}\forall A:Id.has(A,{\mathrm{s}}_j).\exists e:E(Construct):EClass(Atom\times ID\times Data).\\ \wedge e{ \mathrm{has} \mathrm{s}}_j\wedge e \mathrm{has} \mathrm{S}\wedge S\Rightarrow {(\mathrm{s}}_1\parallel s_2\parallel s_3\cdots s_j)\\ \wedge Construct(e)=(s,A,S)\end{array}\right)$$

(11)

2.2.4. Reconstruct

Event class $Reconstruct$: There are events $e$ in which there are $Atom\times ID\times Data$ ternary types. An honest subject $B$ exists that receives $s_j$ from multiple participants and reconstructs $S$. Note $s_j$ that at least $j$ are needed here to reconstruct $S$, and a lack of enough $s_j$ will cause the reconstruction to fail.

$$\left(\begin{array}{l}\forall B:Id.\exists e:EClass(Atom\times ID\times Data).\\ loc(e)=B\wedge e{ \mathrm{has} \mathrm{s}}_j\wedge {(\mathrm{s}}_1\parallel s_2\parallel s_3\cdots s_j)\Rightarrow S\\ \wedge Reconstruct(e)=(s,B,S)\end{array}\right)$$

(12)

2.2.5. Reconstruct Axioms

Reconstruction axiom ($AxiomRe$): In the event classes $Construct$ and $Reconstruct$, the event $e$ has the type $Atom\times ID\times Data$ ternary. If there is an event $e$ that satisfies $e\in E(Construct)$ and has $Construct(e)=<s,A,S>$, then the subject of the event $e$ occurs when $A$ splits the secret value $S$ into a number of interconnected sub-secrets $s$ to be distributed to the authorised participants, and $loc(e)=A$. If there is an event $e^{\prime }$ that satisfies $e^{\prime }\in E(Reonstruct)$ and has $Reconstruct(e^{\prime })=<s,A,S>$, then the authorised participants can reconstruct the secret value using the established method by sending the sub-secret $s$ to the trusted participants. The formal expression is as follows:

$$\left(\begin{array}{c}RERuler:\\ Construct,Reconstruct:\\ EClass(Atom\times ID\times Data)\\ \forall e:E(Construct).\exists e^{\prime }:\\ E(Reconstruct)(e<e^{\prime })\wedge \\ Construct(s,S)\wedge Reconstruct(s,S)\end{array}\right)$$

(13)

2.3. Proof of Agreement Process

The proof process of a protocol consists of a formal description and the derivation of security properties. The following is a simplified proof process:

• Formally describe the protocol using Logic of Events theory approach to define the sequences of initiator and responder actions and to standardise the basic sequences of the protocol. Confirm that the strong authentication property to be proved satisfies the security requirements of the protocol.
• Perform one-way proofs of the strong authentication properties. Assuming that all the participants are honest and comply with the protocol, define an instance of the basic sequence of the protocol and determine the actions and matching events on the instance. Analyse the matching events to determine if a matching session exists and if there are matching events within the matching session that require further proofs.
• Perform match event exclusion analysis. Check whether the relevant matching event matches the matching session, and if it does, perform the inside-out proof of the matching session; if it does not, perform the next round of screening proof of the matching event to confirm whether the whole matching event satisfies the weak match.
• Confirm the nature of strong authentication. Confirm that the matching session belongs to weak matching, analyse the length of the matching session during the protocol interaction, and confirm the strong matching session according to the relevant axioms.
• After the one-way proof has been successful, the two-way strong authentication nature is proved. If the proof is successful, it indicates that the protocol is secure. Throughout the proof process, if the matching event of one party fails to satisfy a weak match, this indicates that the protocol does not satisfy the strong authentication property and cannot realise two-way authentication. This makes the protocol vulnerable to masquerading identity attacks and message replay, and hence, the protocol body is not secure.

3. Protocols

3.1. Brief Description of the Protocol

In this paper, we use industrial IoT multi-factor authentication protocol as an example to verify the extended theory. The basic notations and semantics are given in

Table 2. Notations and descriptions.

Notations	Meaning of Words
$GWN$	Gateway node
$M_i$	The resultant message obtained from various atoms by hashing or heterodyne operations
$TI{D}_i$	$GWN$ generates a temporary identity for each user
$U_i$, $S{D}_j$	ith user and jth sensing device
$T{S}_i$	Current timestamp
$r_{GWN}$	a random nonce
$s_j,f_j$	$S{D}_j$’s secret parameters
$SK$	Session key between the user and sensing devices
$KE{Y}_{GWN-U_i}$	The key between the user and the gateway retrieved from the database.
$S$	Secret value utilised for secret sharing

.

The following are the specific steps of the authentication phase protocol.

First, after receiving message $\left\{TI{D}_i,M_1,M_2,T{S}_1\right\}$ from $U_i$, $GWN$ first checks the freshness of the login request and verifies the timestamp in the message. When the verification result is true, $GWN$ may retrieve the database and obtain the corresponding $I{D}_i,KE{Y}_{GWN-U_i}$. $M_{18}$ denotes the computation of $r_i*,M_3$ and checks whether $M_3$ is equal to $M_2$ to verify the authenticity of $U_i$. If the verification is successful, $GWN$ generates a random $r_{GWN}$ and timestamp. Subsequently, $GWN$ computes $M_4$, and encrypts the parameters in $M_5$ for secure transmission to each legitimate sensing device. Then, $GWN$ computes $M_6$ to help the sensing device $S{D}_j$ to authenticate $GWN$. Finally, $GWN$ sends the message $\left\{M_4,M_5,M_6,T{S}_2\right\}$.

Second, each sensing device $S{D}_j$ receives the broadcast message, $S{D}_j$ decrypts $M_5$ and obtains the relevant parameters. $S{D}_j$ verifies the identity of $GWN$ by calculating the condition $M_6=M_7$. If successful, each $S{D}_j$ sends $s_j,f_j$. Then, it calculates $M_8$ and generates the current timestamp $T{S}_3$ and returns the message $\left\{M_8,T{S}_3\right\}$ to $GWN$.

When $GWN$ receives a message from a sensing device, it verifies the timestamp, computes $s_j,f_j$, reconstructs the secret $S$, and counts $M_{11},M_{12}$. $GWN$ computes $M_{13},M_{14}$ with the help of the new timestamp and the current timestamp. Finally, $GWN$ sends the message $\left\{M_{12},M_{13},M_{14},T{S}_4\right\}$ to $U_i$ respectively, and sends the message $\left\{M_{10},M_{11}\right\}$ to those legitimate participants who helped reconstruct the secret.

When $GWN$ receives the message $\left\{M_{10},M_{11}\right\}$, each sensing device $S{D}_j$ computes $M_{15}=M_{11}$ and the session key $SK$. Finally, $GWN$ computes $M_{16}$ and sends it to the current user $U_i$ to verify the shared session key.

Finally, when $U_i$ receives the message $\left\{M_{12},M_{13},M_{14},T{S}_4\right\}$ from $GWN$, it first verifies the timestamp, and then $U_i$ decrypts $M_{12}$. $U_i$ verifies the session consistency by checking whether $r_i{}^{*}=r_i$.

The authentication process of the secure multi-factor authentication protocol for industrial IoT is shown in Figure 1.

3.2. Formal Description of Protocol Authentication

The basic sequence ordering of a secure multi-factor authentication protocol for industrial IoT using the Logic of Events was performed. The protocol description is shown in Figure 2. A formal description of the protocol interaction process is shown in Figure 3 where $U_1~U_3$ is the action generated by the user during the protocol interaction, $G_1~G_4$ is the action generated by the gateway during the protocol interaction, and $S_1~S_4$ is the action generated by the wireless sensor during the protocol interaction.

The formal analysis of the Logic of Events is used to define the authentication properties that need to be satisfied to validate the Industrial IoT Secure Multi-Factor Authentication Protocol security. The basic sequence of the secure multi-factor authentication protocol for the industrial IoT is shown in Figure 4.

Based on the basic sequence relations defined, the protocol is defined as $Protocol([U_1,U_2,U_3,G_1,G_2,G_3,G_4,S_1,S_2,S_3,S_4])$; the authentication of the protocol can be formally stated as:

$$SMA\models auth(U_3,2)\wedge SMA\models auth(S_4,3)$$

(14)

3.3. Agreement Certification Process

In the Industrial IoT Secure Multi-Factor Authentication Protocol, $GWN$ is considered fully trustworthy and is responsible for registering the users and sensing devices.

Assuming $U_i\ne GWN\ne S{D}_j$ and that they are honestly adhering to the interaction process of the Industrial IoT Multi-Factor Secure Authentication Protocol, then the thread $th{r}_1$ is an instance in the basic sequence $U_3$. If $e_0<{}_{loc}e{}_1<\dots <{}_{loc}e{}_5$ is an event on the thread $th{r}_1$, and the body of $T{S}_2,T{S}_3,r_i^{*},KE{Y}_{r^{*}-GWN},KE{Y}_{GWN-U_i},M_4,M_5,M_7$ is $U$, then the address of event $e_0, e_1, e_2,\dots ,e_5$ is also $U$. For an atomic type of message $r_i,r_i^{*},T{S}_1,T{S}_2,T{S}_4,M_1,M_2,M_{12},M_{14},M_{17}$, there is the following formula:

$$\left(\begin{array}{l}New(e_0)=<r_i>\wedge Compute(e_1)\\ =<<TI{D}_i,M_1,I{D}_{GWN}^{*},r_i,T{S}_1>,h,M_2>\wedge \\ Send(e_2)=<TI{D}_i,M_1,M_2,T{S}_2>\wedge Rcv(e_3)\\ =<M_{12},M_{14},T{S}_4>\wedge \\ Decrypt(e_4)=<<r_i^{*}>,M_{12}>\wedge Compute(e_5)\\ =<<M_{12},r_i>,M_{17}>\end{array}\right)$$

(15)

Using the axioms $AxiomS$ and $AxiomD$, it follows that there is an event $e^{\prime }$ such that:

$$e^{\prime }<e_4\wedge DEMatch(e_4,e^{\prime })\wedge loc(e^{\prime })=G\wedge loc(e^{\prime })=S$$

From this, it follows:

$$Encrypt(e^{\prime })=<<r_i^{*}>,M_{12}>$$

(16)

Since $GWN$ follows the interaction flow of the Multi-Factor Secure Authentication Protocol for the Industrial IoT, the event $e^{\prime }$ is an instance of an action belonging to one of the basic sequences of the protocol. Among the basic sequences, the sequence containing the encryption action $Encrypt()$ is $G_2,G_3,G_4,S_2,S_3,S_4$, so the sequence matching the event $e^{\prime }$ will be filtered from these sequences above.

If $e^{\prime }$ is an instance of the sequence $S_2$, then for the atomic-type messages, ${T{S}_2}^{\prime }{,T{S}_3}^{\prime },{r_i^{*}}^{\prime },{s_j}^{\prime },{k_j}^{\prime },{KE{Y}_{r^{*}-GWN}}^{\prime },{KE{Y}_{GWN-U_i}}^{\prime }$ etc., there is an event on the body $A$.

$$\left(\begin{array}{c}{e_0}^{\prime }<{{}_{loc}e{}_1}^{\prime }<{}_{loc}e{{}_2}^{\prime }<{{}_{loc}e{}_3}^{\prime }<{{}_{loc}e{}_4}^{\prime }<{{}_{loc}e{}_5}^{\prime }\wedge \\ Rcv({e_0}^{\prime })=<{M_5}^{\prime },{M_6}^{\prime },{T{S}_2}^{\prime }>\wedge Decrypt({e_1}^{\prime })\\ =<<I{D}_i,I{D}_{GWM},{r_i^{*}}^{\prime }>,KE{Y_{r^{*}-GWN}}^{\prime },{M_5}^{\prime }>\wedge \\ Compute({e_2}^{\prime })=<<I{D}_i,I{D}_{GWM},{r_i^{*}}^{\prime },{M_4}^{\prime },KE{Y_{GWN-U_i}}^{\prime },T{S_2}^{\prime }>,h,{M_7}^{\prime }>\\ \wedge Construct({e_3}^{\prime })=<<{s_j}^{\prime },{f_j}^{\prime }>,S>\\ Encrypt({e_4}^{\prime })=<<{s_j}^{\prime },{f_j}^{\prime },I{D}_{S{D}_j}>,KE{Y_{r^{*}-GWN}}^{\prime },{M_8}^{\prime }>\\ \wedge Send({e_5}^{\prime })=<{M_8}^{\prime },T{S_3}^{\prime }>\end{array}\right)$$

(17)

From the comparison between $Encrypt({e_4}^{\prime })$ and $Encrypt(e^{\prime })$, we can see that the encryption event ${e_4}^{\prime }$ is different from $e^{\prime }$, so we can exclude the possibility that $S_2$ has $e^{\prime }$ in it. Similarly, $S_3,S_4$ can also be excluded.

If $e^{\prime }$ is an instance in the sequence $G_2$, then for the atomic types of information, ${M_1}^{\prime },{M_2}^{\prime },{M_3}^{\prime },{M_4}^{\prime },{M_5}^{\prime },{M_6}^{\prime },T{S_1}^{\prime },T{S_2}^{\prime }$, etc., there is

$$\left(\begin{array}{c}Rcv\left({e_0}^{\prime }\right)=<TI{D}_i,{M_1}^{\prime },{M_2}^{\prime },T{S_2}^{\prime }>\wedge \\ Compute\left({e_1}^{\prime }\right)=\\ <<TI{D}_i,{M_1}^{\prime },I{D}_{GWN},{r_i^{*}}^{\prime },T{S_1}^{\prime }>,h,{M_3}^{\prime }>\wedge \\ New({e_2}^{\prime })=<{r_{GWN}}^{\prime }>\wedge Encrypt({e_3}^{\prime })=\\ <<I{D}_i,I{D}_{GWM},{r_i^{*}}^{\prime }>,KE{Y_{r^{*}-GWN}}^{\prime },{M_5}^{\prime }>\wedge \\ Compute({e_4}^{\prime })=\\ <<I{D}_i,I{D}_{GWM},{r_i^{*}}^{\prime },{M_4}^{\prime },KE{Y_{GWN-U_i}}^{\prime },T{S_2}^{\prime }>,h,{M_6}^{\prime }>\wedge \\ Send({e_5}^{\prime })=<{M_5}^{\prime },{M_6}^{\prime },T{S_2}^{\prime }>\end{array}\right)$$

(18)

Here, the encryption event ${e_3}^{\prime }$ is not the same as the event $e^{\prime }$, so $G_2$ is excluded. Since there is no cryptographic event in the sequence, $G_3$ and $G_3$ occur after $G_2$, and $G_3$ can be excluded.

If $e^{\prime }$ is an instance in the sequence $G_4$, then for the atomic types of information, $KE{Y_{r^{*}-GWN}}^{\prime },{r_i^{*}}^{\prime },T{S_4}^{\prime },{s_j}^{\prime },{f_j}^{\prime },{M_8}^{\prime },{M_9}^{\prime },{M_{10}}^{\prime }$, etc., and the subjects $A$, there is

$$\left(\begin{array}{c}{e_0}^{\prime }<{}_{loc}e{{}_1}^{\prime }<{}_{loc}e{{}_2}^{\prime }<{}_{loc}e{{}_3}^{\prime }<{}_{loc}e{{}_4}^{\prime }<\\ {}_{loc}e{{}_5}^{\prime }<{}_{loc}e{{}_6}^{\prime }<{}_{loc}e{{}_7}^{\prime }<{}_{loc}e{{}_8}^{\prime }<{}_{loc}e{{}_9}^{\prime }\\ <{}_{loc}e{{}_{10}}^{\prime }<{}_{loc}e{{}_{11}}^{\prime }<{}_{loc}e{{}_{12}}^{\prime }\wedge \\ Rcv\left({e_0}^{\prime }\right)=<TI{D}_i,{M_1}^{\prime },{M_2}^{\prime },T{S_2}^{\prime }>\wedge Compute\left({e_1}^{\prime }\right)\\ =<<TI{D}_i,{M_1}^{\prime },I{D}_{GWN},{r_i^{*}}^{\prime },T{S_1}^{\prime }>,h,{M_3}^{\prime }>\wedge New({e_2}^{\prime })=<{r_{GWN}}^{\prime }>\\ \wedge Encrypt({e_3}^{\prime })=<<I{D}_i,I{D}_{GWM},{r_i^{*}}^{\prime }>,KE{Y_{r^{*}-GWN}}^{\prime },{M_5}^{\prime }>\wedge \\ Compute({e_4}^{\prime })=<<I{D}_i,I{D}_{GWM},{r_i^{*}}^{\prime },{M_4}^{\prime },KE{Y_{GWN-U_i}}^{\prime },T{S_2}^{\prime }>,h,{M_6}^{\prime }>\\ \wedge Send({e_5}^{\prime })=<{M_5}^{\prime },{M_6}^{\prime },T{S_2}^{\prime }>\wedge \\ Rcv({e_6}^{\prime })=<M_8,T{S}_3>\wedge Decrypt({e_7}^{\prime })\\ =<<s_j,f_j,I{D}_{S{D}_{\mathrm{j}}}>,KE{Y_{r^{*}-GWN}}^{\prime },{M_8}^{\prime }>\wedge \mathrm{Re}construct({e_8}^{\prime })\\ =<<s_j,f_j>,S>\wedge Compute({e_9}^{\prime })=<<{M_9}^{\prime },{M_{10}}^{\prime }>,h,{M_{11}}^{\prime }>\\ \wedge Encrypt({e_{10}}^{\prime })=<<{r_i^{*}}^{\prime }>,{M_{12}}^{\prime }>\wedge Send({e_{11}}^{\prime })=<{M_{10}}^{\prime },{M_{11}}^{\prime }>\wedge \\ Send({e_{12}}^{\prime })=<{M_{12}}^{\prime },{M_{14}}^{\prime },T{S_4}^{\prime }>\end{array}\right)$$

(19)

The above equation is satisfied.

$$Encrypt(e^{\prime })=<<r_i^{*}>,M_{12}>=<<{r_i^{*}}^{\prime }>,{M_{12}}^{\prime }>=Encrypt(e_3{}^{\prime })$$

(20)

It can be shown that $e^{\prime }$ is an instance in the sequence $G_4$ with $A=U,{e_3}^{\prime }=e^{\prime },{M_{12}}^{\prime }=M_{12},{r_i^{*}}^{\prime }=r_i^{*}$, which can be obtained.

$$\left(\begin{array}{c}{e_0}^{\prime }<{}_{loc}e{{}_1}^{\prime }<{}_{loc}e{{}_2}^{\prime }<{}_{loc}e{{}_3}^{\prime }<{}_{loc}e{{}_4}^{\prime }<\\ {}_{loc}e{{}_5}^{\prime }<{}_{loc}e{{}_6}^{\prime }<{}_{loc}e{{}_7}^{\prime }<{}_{loc}e{{}_8}^{\prime }<{}_{loc}e{{}_9}^{\prime }<{}_{loc}e{{}_{10}}^{\prime }<{}_{loc}e{{}_{11}}^{\prime }<{}_{loc}e{{}_{12}}^{\prime }\wedge \\ Rcv\left({e_0}^{\prime }\right)=<TI{D}_i,M_1,M_2,T{S}_2>\wedge Compute\left({e_1}^{\prime }\right)\\ =<<TI{D}_i,M_1,I{D}_{GWN},r_i^{*},T{S}_1>,h,M_3>\wedge New({e_2}^{\prime })=<r_{GWN}>\wedge Encrypt({e_3}^{\prime })=\\ <<I{D}_i,I{D}_{GWM},r_i^{*}>,KE{Y}_{r^{*}-GWN},M_5>\wedge Compute({e_4}^{\prime })=\\ <<I{D}_i,I{D}_{GWM},r_i^{*},M_4,KE{Y}_{GWN-U_i},T{S}_2>,h,M_6>\\ \wedge Send({e_5}^{\prime })=<M_5,M_6,T{S}_2>\wedge Rcv({e_6}^{\prime })=<M_8,T{S}_3>\wedge Decrypt({e_7}^{\prime })=\\ <<{s_j}^{\prime },{f_j}^{\prime },I{D}_{S{D}_{\mathrm{j}}}>,KE{Y}_{r^{*}-GWN},M_8>\wedge \mathrm{Re}construct({e_8}^{\prime })=<<{s_j}^{\prime },{f_j}^{\prime }>,S>\wedge \\ Compute({e_9}^{\prime })=<<M_9,M_{10}>,h,M_{11}>\wedge Encrypt({e_{10}}^{\prime })=<<r_i^{*}>,M_{12}>\wedge \\ Send({e_{11}}^{\prime })=<M_{10},M_{11}>\wedge Send({e_{12}}^{\prime })=<M_{12},M_{14},T{S}_4>\end{array}\right)$$

(21)

From the axioms $AxiomD$ and $AxiomS$, it follows that the event $Encrypt()$ must exist and satisfy Eq:

$$e^{″}<{e_7}^{\prime }\wedge DEMatch({e_7}^{\prime },e^{″})\wedge loc(e^{″})=U\wedge loc(e^{″})=S$$

(22)

$GWN$ is honest and follows the protocol interaction flow. The event $e^{″}$ is an instance of one of the basic sequences based on the protocol; the sequence containing the encryption action is $Encrypt()$, in which the sequence is $G_2,G_3,G_4,S_2,S_3,S_4$, where $S_3,S_4$ has not yet occurred. Thus, it can be excluded, as ${e_7}^{\prime }$ occurs on the subject $G$, and then $G_2,G_3,G_4$ is excluded, leading to the conclusion that $e^{″}$ may be present in $S_2$.

If $e^{″}$ is an instance of $S_2$ that exists for the atoms ${M_4}^{\prime },{M_5}^{\prime },{M_6}^{\prime },{M_7}^{\prime },{M_8}^{\prime },T{S_2}^{\prime },T{S_3}^{\prime },{r_i^{*}}^{\prime }$, etc., then on subject $B$, there is

$$\left(\begin{array}{c}{e_0}^{″}<{{}_{loc}e{}_1}^{″}<{{}_{loc}e{}_2}^{″}<{{}_{loc}e{}_3}^{″}<{{}_{loc}e{}_4}^{″}<{{}_{loc}e{}_5}^{″}\wedge \\ Rcv({e_0}^{″})=<{M_5}^{\prime },{M_6}^{\prime },T{S_2}^{\prime }>)\wedge Decrypt({e_1}^{″})=\\ <<I{D}_i,I{D}_{GWM},{r_i^{*}}^{\prime }>,KE{Y_{r^{*}-GWN}}^{\prime },{M_5}^{\prime }>\wedge Compute({e_2}^{″})=\\ <<I{D}_i,I{D}_{GWM},{r_i^{*}}^{\prime },{M_4}^{\prime },{KE{Y}_{GWN-U_i}}^{\prime },{T{S}_2}^{\prime }>,h,{M_7}^{\prime }>\\ \wedge Construct({e_3}^{″})=<<{s_j}^{\prime },{f_j}^{\prime }>,S>\wedge Encrypt({e_4}^{″})=\\ <<{s_j}^{\prime },{f_j}^{\prime },I{D}_{S{D}_{\mathrm{j}}}>,{KE{Y}_{r^{*}-GWN}}^{\prime },{M_8}^{\prime }>\wedge Send({e_5}^{″})=<{M_8}^{\prime },{T{S}_3}^{\prime }>\end{array}\right)$$

(23)

Then, there is

$$\left(\begin{array}{c}{e_0}^{‴}<{{}_{loc}e{}_1}^{‴}<{{}_{loc}e{}_2}^{‴}<{{}_{loc}e{}_3}^{‴}<{{}_{loc}e{}_4}^{‴}<{{}_{loc}e{}_5}^{‴}\wedge \\ Rcv({e_0}^{‴})=<TI{D}_i,{M_1}^{\prime },{M_2}^{\prime },{T{S}_2}^{\prime }>\wedge Compute({e_1}^{‴})=\\ <<TI{D}_i,{M_1}^{\prime },I{D}_{GWN},{r_i^{*}}^{\prime },{T{S}_1}^{\prime }>,h,{M_3}^{\prime }>\\ \wedge New({e_2}^{‴})=<{r_{GWN}}^{\prime }>\wedge Encrypt({e_3}^{‴})\\ =<<I{D}_i,I{D}_{GWM},{r_i^{*}}^{\prime }>,{KE{Y}_{r^{*}-GWN}}^{\prime },{M_5}^{\prime }>\wedge Compute({e_4}^{‴})=\\ <<I{D}_i,I{D}_{GWM},{r_i^{*}}^{\prime },{M_4}^{\prime },{KE{Y}_{GWN-U_i}}^{\prime },{T{S}_2}^{\prime }>,h,{M_6}^{\prime }>\\ \wedge Send({e_5}^{‴})=<{M_5}^{\prime },{M_6}^{\prime },{T{S}_2}^{\prime }>\end{array}\right)$$

(24)

Another event $e^{‴}$ exists and satisfies Eq:

$$e^{‴}<{e_1}^{″}\wedge DEMatch({e_1}^{″},e^{‴})\wedge loc(e^{‴})=U\wedge loc(e^{‴})=G$$

Such that the expression $Encrypt(e^{‴})=<<I{D}_i,I{D}_{GWM},r_i^{*}>,KE{Y}_{r^{*}-GWN},M_5>$ holds. If the event $e^{‴}$ is an instance in the sequence $G_2$, then for the atom ${M_1}^{\prime },{M_2}^{\prime },{M_3}^{\prime },{M_4}^{\prime },{M_5}^{\prime },{M_6}^{\prime },{T{S}_2}^{\prime },{r_i^{*}}^{\prime }$, there is the event ${e_0}^{‴},{e_1}^{‴},{e_2}^{‴},{e_3}^{‴},{e_4}^{‴},{e_5}^{‴}$ for which the following equation holds:

$$\left(\begin{array}{c}{e_0}^{‴}<{{}_{loc}e{}_1}^{‴}<{{}_{loc}e{}_2}^{‴}<{{}_{loc}e{}_3}^{‴}<{{}_{loc}e{}_4}^{‴}<{{}_{loc}e{}_5}^{‴}\wedge \\ Rcv(e_0‴)=<TI{D}_i,{M_1}^{\prime },{M_2}^{\prime },{T{S}_2}^{\prime }>\wedge Compute({e_1}^{‴})=\\ <<TI{D}_i,{M_1}^{\prime },I{D}_{GWN},{r_i^{*}}^{\prime },{T{S}_1}^{\prime }>,h,{M_3}^{\prime }>\wedge \\ New({e_2}^{‴})=<{r_{GWN}}^{\prime }>\wedge Encrypt({e_3}^{‴})=\\ <<I{D}_i,I{D}_{GWM},{r_i^{*}}^{\prime }>,{KE{Y}_{r^{*}-GWN}}^{\prime },{M_5}^{\prime }>\\ \wedge Compute({e_4}^{‴})=\\ <<I{D}_i,I{D}_{GWM},{r_i^{*}}^{\prime },{M_4}^{\prime },{KE{Y}_{GWN-U_i}}^{\prime },{T{S}_2}^{\prime }>,h,{M_6}^{\prime }>\\ \wedge Send({e_5}^{‴})=<{M_5}^{\prime },{M_6}^{\prime },{T{S}_2}^{\prime }>\end{array}\right)$$

(25)

The above equation satisfies

$$\begin{array}{l}Encrypt(e^{‴})=<<I{D}_i,I{D}_{GWM},r_i^{*}>,KE{Y}_{r^{*}-GWN},M_5>=<<I{D}_i,I{D}_{GWM},{r_i^{*}}^{\prime }>,{KE{Y}_{r^{*}-GWN}}^{\prime },{M_5}^{\prime }>\\ =Encrypt({e_3}^{‴})\end{array},$$

So this can be obtained:

$$\left(\begin{array}{c}{e_0}^{‴}<{{}_{loc}e{}_1}^{‴}<{{}_{loc}e{}_2}^{‴}<{{}_{loc}e{}_3}^{‴}<{{}_{loc}e{}_4}^{‴}<{{}_{loc}e{}_5}^{‴}\wedge \\ Rcv({e_0}^{‴})=<TI{D}_i,M_1,M_2,T{S}_2>\wedge \\ Compute({e_1}^{‴})=\\ <<TI{D}_i,M_1,I{D}_{GWN},r_i^{*},T{S}_1>,h,M_3>\wedge \\ New({e_2}^{‴})=<r_{GWN}>\wedge Encrypt({e_3}^{‴})=\\ <<I{D}_i,I{D}_{GWM},r_i^{*}>,KE{Y}_{r^{*}-GWN},M_5>\wedge \\ Compute({e_4}^{‴})=\\ <<I{D}_i,I{D}_{GWM},r_i^{*},M_4,KE{Y}_{GWN-U_i},T{S}_2>,h,M_6>\\ \wedge Send({e_5}^{‴})=<M_5,M_6,T{S}_2>\end{array}\right)$$

(26)

This is obtained from $AxiomF$ with the above proof:

$$\left(\begin{array}{c}Rcv({e_0}^{\prime })=<TI{D}_i,M_1,M_2,T{S}_2>=Send(e_2)\wedge \\ Rcv({e_0}^{″})=<M_5,M_6,T{S}_2>=\\ Send({e_5}^{\prime })\wedge Send({e_5}^{″})=<M_8,T{S}_3>=Rcv({e_6}^{\prime })\wedge \\ Rcv(e_3)=<M_{12},M_{14},T{S}_4>=Send({e_{12}}^{\prime })\end{array}\right)$$

(27)

The next step in proving a strong matching dialogue is to prove $e_2<{e_0}^{\prime },{e_5}^{\prime }<{e_0}^{″},{e_5}^{″}<{e_6}^{\prime },{e_{12}}^{\prime }<e_3$. Let us start with $e_2<{e_0}^{\prime }$ as an example.

Assuming $U\ne G\ne S$ and that the subjects are honest and abide by the protocol, according to the random number axiom and the flow relation primitives, there is a send event $S$ between $e_0$ and ${e_0}^{\prime }$, releasing a random number $m$, and if $e_2<j$, then $e_2<{e_0}^{\prime }$ can be obtained, and it is necessary to exclude $e_0<{}_{loc}j<{}_{loc}e{}_2$.

If $e_0<{}_{loc}j<{}_{loc}e{}_2$, then $j$ must be a member instance of some other thread that is the subject $U$. Although the protocol may have other basic sequences releasing random numbers before releasing the random number $m$, it follows from threads and matching sessions that there is no send action between $e_0$ and $e_2$ in the thread $th{r}_1$, and then the random number $m$ will not be released before $e_2$, so $e_0<{}_{loc}j<{}_{loc}e{}_2$ can be ruled out. Similarly, ${e_5}^{\prime }<{e_0}^{″},{e_5}^{″}<{e_6}^{\prime },{e_{12}}^{\prime }<e_3$ can be proved.

3.4. Proof of Results

In summary, there are four strong matching dialogues for the thread $th{r}_1$ on the subject $U$, and $SMA\models auth(U_3,2)$ is proved.

Similarly, there are two strong matches present in the subject $U_i,GWN,S{D}_j$, and the thread $th{r}_2$ is fully interactive; $SMA\models auth(S_4,3)$ can be proved.

Thus, this proof process has been completed to prove the strong authentication property of the protocol $SMA\models auth(U_3,2)\wedge SMA\models auth(S_4,3)$. Therefore, the authentication of the Multi-Factor Secure Authentication Protocol for the Industrial IoT has been proved, and the attacker is not able to replay the attack by disguising the legitimate user, so the protocol is secure.

4. Logic of Events vs. Other Approaches

The formal analysis methods for security protocols are divided into three categories, model detection methods, modal logic methods, and theorem-proving methods, each with a different focus.

4.1. Comparison of LoET and Modal Logic

Modal logic is the most widely used formal method, including BAN logic and BAN-like logic, of which BAN-like logic contains more than ten kinds of logic methods [19]. This method is simple and direct and is very widely used. However, it has some insurmountable drawbacks; one is that the idealisation process of the protocol is very difficult, and the other is that the method lacks a mechanism for the derivation of the subject’s behaviour.

Taking BAN logic as an example, compared to the Logic of Events theoretical approach, BAN logic has to carry out a lot of idealisation, which contains the protocol’s premises, the protocol itself, the protocol goals, etc., and these actions are realised through formal descriptions [20]. BAN logic describes the initialisation assumptions of the protocol and the expected goals of the security protocol through formal descriptions, which are similar steps to the LoET theoretical approach. However, BAN logic is too dependent on initial assumptions, such as the execution environment in which it is implemented, the subjects involved in the execution of the protocol, and the keys used by the protocol. In contrast, the LoET theory deals with protocol initialisation in a more abstract way, while making reasonable assumptions about the objective environment of the protocol. BAN logic over-idealises the protocols and relies too much on the analyst’s intuition. This idealisation process may lead to problems, making the idealised protocol somewhat different from the original protocol. For example, the preconditions or contents of the protocol may be ignored or added, and the description of the protocol goals may not be accurate enough, which may lead to discrepancies between the analysis results and the original protocol design. The theory of LoET [21], on the other hand, regulates a series of axioms and inference rules using rigorous mathematical rules, which ensures the rigour of the process of proving the nature of strong authentication. BAN logic carries out step-by-step reasoning using the rules and applies rigorous logic during the reasoning process to prove the security of the protocol. However, the semantic carve-out of BAN logic is not very clear, and the proof process of this logic may not be fully convincing. Also, BAN logic does not provide a good guarantee of the practicality of protocol proofs. In contrast, the LoET theory defines clear and explicit theorem rules with a clear and unambiguous structure, which can guarantee the authenticity and reliability of protocols in the proving process and make the protocol security properties more credible.

4.2. Comparison of LoET and Model Detection

The model detection of security protocols considers the limited behaviour of the protocols and detects whether they are slow to rule some correct conditions. The method is more suitable for discovering attacks on protocols rather than proving the correctness of the protocols, for example, the process of FDR analysis is to test whether the protocols satisfy the statute or not.

The model detection methods can only analyse finite state systems, but the actual network environment may allow each subject to run multiple protocol entities at the same time, allowing the concurrent operation of an infinite number of protocol instances to inevitably lead to an infinite protocol model state space [22]. LoET, on the other hand, can simplify the processing of complex protocol objects and simplify the protocol interaction process. For example, data transmission and interaction in the physical layer, network layer, etc., and this information in the formal description of the LoET theory are not used to perform figurative processing for the message Msg to define. However, the protocol action should be clearly marked for message processing to ensure the effectiveness of the LoET theory method in the information transfer process of protocol modelling. The model detection of the biggest problem is a state space explosion problem, generally taken to limit the small system model, in the introduction of some special methods (such as symbolisation methods, etc.) for model detection. But the biggest advantage of model detection is that it can be completely automated, often effectively finding the vulnerability of security protocols, so the design and analysis of security protocols play a role in falsification. Currently, LoET relies more on manual proofs, and further research on distribution automation is needed.

4.3. Comparison of LoET and Theorem Proving

The LoET theory is a kind of theorem-proving method. The advantage of a theorem-proving method is that it can analyse protocols of an infinite size and does not limit the rounds in which the subject participates in the operation of the protocol. Its disadvantage is that the proof process cannot be fully automated and requires manual “expert” intervention, and many theorem-proving methods are incomplete, such as the type theory proof methods based on Spi algorithms that can prove the security of the protocol, but it is difficult to construct a secure protocol corresponding to the type system; when there is no constructed type system to prove that the protocol meets the security, it cannot be said that the protocol is vulnerable. To satisfy security, the protocol cannot be shown as vulnerable.

As an example, PCL is a logical method for proving the security system of cryptographic protocols. In protocol security property verification, the PCL method can be used to inscribe the security properties of some protocols, but it cannot inscribe the authentication properties of the data signature protocols. In contrast, the theorem-proving approach based on the LoET theory can perform authentication for the other security properties. The PCL approach suffers from a lack of rigour in modelling protocol interaction actions and lacks a definition of the mechanism for describing the sequence of preceding actions of a thread. The LoET theory approach defines the thread mechanism for the formal modelling of protocols and regulates the sequential thread state of events through atomic independence, which makes the modelling more standardised. The PCL approach lacks the necessary constraints and limitations on the data types of protocol information, while the LoET theory ensures that the data types of protocol information are well regulated by defining the unique type to regulate the definition of the basic elements that are unstructured and cannot be generated. The data types are adequately regulated. In particular, the PCL approach has major limitations in describing the behaviour of the Diffie–Hellman algebra and the Hash function, which the LoET theory chooses to portray when dealing with encryption actions. Taking the Hash function encryption in this paper as an example, during the message decryption verification process, the LoET theory approach generates a new Hash encryption by means of a valid message, and then proves it by comparing it with the inscribed encryption action.

In conclusion, the existing formal analysis methods for security protocols have their own advantages and disadvantages, and although the research in this area has become a hotspot, its application deserves further exploration. The main reason for this status quo is that the formal modelling and analysis of security protocols are very difficult, and the existing formal methods can often only analyse one or two security properties (generally confidentiality and authentication), while the existing security protocols tend to have more security goals; there is a lack of a unified formal model for analysing and verifying a variety of security properties under a unified framework. Therefore, mature theories or methods to study more security properties and how to analyse and verify the security properties under a unified formal framework are issues worthy of future research.

5. Discussion

This paper extends the definition of $Compurte,TimeGap,Construct,Reconstruct$ in the event class based on the existing Logic of Events theory to simplify the description of complex encryption behaviours in industrial IoT protocols. The extension of the relevant rules $AxiomRe$ based on the event class is mainly used to describe more complex encryption behaviours and encryption mechanisms in industrial IoT security protocols and to verify the causal relationship between protocol events more effectively. In this paper, we use Logic of Events and its extension theory to analyse the security of multi-factor security authentication protocols for the industrial IoT, formally analyse the interaction actions between different initiators and receivers of the three types of subjects, portray the security properties of industrial IoT security protocols, and verify the security of the protocols using an axiomatic system. The theory is applicable to the formal analysis of some industrial IoT security protocols.

The future work on LoET theory should include the following. The proof method of LoET relies more on manual proofs, and by defining the individual steps of the method, the next step is to investigate the implementation of distribution automation. The concept of step-by-step implementation is added to the security protocol verification system being constructed, thus realizing the automated proof of network security protocol authentication. LoET is still complex and cumbersome in the process of proving the security of protocols, and it is considered to simplify the process of protocol proving, improve the efficiency of proving, and make the method more popular and easy to understand. The future research direction is how to achieve the analytical proof of the other security attributes in security protocols, further improve and refine the relevant theory, and analyse more industrial IoT protocols by example.