Evaluation and Improvement of Internet Printing Protocol Based on HCPN Model Detection Method

Abstract

The Internet Printing Protocol (IPP) is a bridge between hosts and printers, and is supported by more than 98 percent of printers today. In addition to supporting local use, the IPP protocol also supports online use. Although this can expand the scope of its application, it has also introduced potential risks to user data. IPP has security components that should be able to guarantee confidentiality, integrity, and non-repudiation. In order to verify whether its security components can achieve this goal, this study modeled the 0-RTT authentication process of the IPP protocol based on Petri net theory and CPN Tools, introducing the improved Dolev–Yao adversary model to perform security evaluation on the protocol model. The result showed that the server could not resist the adversary’s replay attacks on early data. Accordingly, we proposed an improved authentication scheme that introduced a random number signature to enhance the server’s anti-replay capability. Using the same attack model to verify, the result proved that the new scheme was feasible and effective. The method used in this article could easily observe the movement of the security protocol message flow and the specific actions of each participant (including the adversary), which ensured researchers could easily locate the protocol defects and make improvements.

1. Introduction

Quocirca’s 2022 Global Print Security Analysis Report [1] showed that many organizations were struggling to meet the print security needs of today’s hybrid (office and home) work environment. Due to the COVID-19 pandemic, office printing volume declined significantly in the past years, but 44 percent of people expect this to increase in the next 12 months, while 41 percent expect home printing volume to increase. This continued reliance on printing, especially in larger organizations managing a hybrid workforce, will require more effective print security measures to protect and manage devices, documents, and networks.

The communication between the host and peripheral devices requires the support of a protocol. The most common network printing protocols are Line Printer Daemon protocol (LPD), AppSocket, and IPP. IPP is the preferred protocol because it uses two-way communication, which provides more feedback information and control options. Compared with other protocols, the main advantages of IPP were the following:

• It provides the current status of job processing (pages currently being printed) and more detailed information (such as querying completed and canceled jobs);
• The IEEE-ISTO Printer Working Group (PWG) is responsible for standardization. Using the protocol, we can strengthen the control of authentication/authorization, the encryption of transmitted data, access level, and other security-related options;
• With the latest developments of the IPP standard (“IPP Everywhere [2]”), driver-less printing is possible.

Additionally, IPP has been the basis for several printer logo certification programs, including AirPrint, IPP Everywhere, and Mopria Alliance, and is supported by over 98 percent of today’s printers [3]. Therefore, inspired by the colored Petri net theory [4,5,6] and the Dolev–Yao attack method [7,8], and based on the CPN Tools model detection tool [9], this paper focused on the formal modeling and security assessment as well as the mining protocol vulnerabilities, and we suggested a targeted security improvement scheme and applied CPN tools to verify the security of the proposed scheme.

The structure of this paper is the following: Section 1 is the introduction. Section 2 explains the basic concepts and theories involved in this paper. Section 3 analyzes the interactive message flow of the 0-RTT authentication, establishes the original model, and verifies its consistency with the original protocol performance. Section 4 introduces the improved Dolev–Yao attacker model to evaluate the security of the original protocol model and analyzes the loopholes in the authentication process according to the state-space results. Section 5 proposes an improved authentication scheme by introducing random number signatures to enhance the server’s ability to resist multiple replays and using the CPN model detection tool to verify the effectiveness of the new scheme. Section 6 provides a discussion and Section 7 provides summary and outlook for the future.

2. Preliminary Knowledge

2.1. Internet Printing Protocol

The Internet Printing Protocol (IPP) [10,11] is a dedicated protocol for communication between client devices (computers, mobile phones, tablets, etc.) and printers (or print servers). Similar to all IP-based protocols, IPP can operate locally or over the Internet. IPP uses port 631 as a working port. The typical representative of its specific implementation is CUPS (Common UNIX Printing System, which is the printing module of the Apple macOS and many Unix-like operating system distributions). Message protection design goals have included data origin authentication, privacy, integrity, and non-repudiation [12,13].

IPP is implemented using the Hypertext Transfer Protocol (HTTP), and it inherits all HTTP streaming and security features. For example, authorization can be transmitted through HTTP’s digest authentication mechanism, generic security service application program interface (GSSAPI), or any other HTTP authentication method. Encryption is provided by the TLS protocol layer, the always-on TLS using HTTPS, or the HTTP upgrade scheme [14]. Public key certificates can be used with TLS for authentication.

IPP has two schemes to realize the interaction between client and server:

• IPP scheme [15]: convert IPP-URI to HTTP-URI;
• IPPS scheme [16]: convert IPPS-URI to HTTPS-URI.

Generally speaking, the IPPS solution is superior in terms of security assurance, so this project only conducted security evaluation for this method.

The TLS protocol is the cornerstone to ensure the safe operation of the IPP protocol. Most of the current browsers and web applications that use the HTTPS protocol support the version of TLS 1.2. However, with the passage of time, more and more loopholes have been exposed, including loopholes in encryption algorithms, such as by attacking the internal state of the Rivest Cipher 4 (RC4) stream cipher [17] and loopholes in the process of code implementation, such as the authors in [18] pointed out. The Heartbleed vulnerability was a technical error introduced by the OpenSSL program. When it was exploited, it caused a memory leak from the client to the server. However, we preferred to focus on the design flaws of the protocol itself, rather than discuss the internal problems of the cryptographic algorithm and the code implementation process. For example, Lucky 13 [19] used the time difference between the servers to process messages with correct padding and incorrect padding to derive plaintext information. Logjam [20,21] used man-in-the-middle attacks to downgrade the secure connection of a server. To resolve the above problems, TLS1.3 has made major improvements on the basis of TLS1.2, such as only using the authenticated encryption with associated data (AEAD) algorithm on the record protocol layer and removing the static Rivest—Shamir—Adleman (RSA) and Diffie–Hellman (DH) key agreement at the handshake protocol layer, and removing the change password specification protocol, etc. These outstanding works have greatly improved the security of TLS1.3, but also created new problems in terms of zero round-trip time (0-RTT), fault tolerance, and forward secrecy [22]. Users hope to minimize service delays without sacrificing security. Based on this consideration, the Internet Engineering Task Force (IETF) designed the 0-RTT mechanism of TLS1.3 based on the QUIC protocol [23,24]. The 0-RTT mechanism sped up the operation of the protocol and improved the user experience. While being widely used, its security has also attracted researchers’ attention.

At present, there are three methods for researching protocol formalization: the modal logic method, the theorem-proving method, and the formalization method based on model checking. The authors of [25] used the modal logic method [26] to abstract the participating objects and state relationships involved in TLS1.3, and then they analyzed the security of the 0-RTT process through logical reasoning, but the analysis results depended on the initial logic hypothesis and chosen logical framework. The authors of [27] adopted a theorem-proving method to study the security properties of identity authentication protocol, which required a large number of mathematical operations to participate. Although the accuracy was high, it was difficult to master and use correctly. Based on the model-detection method, the authors of [28] used the formal analysis tool Scyther to automatically complete the underlying mathematical calculations and logic analysis, combined with the program output report, to find the key compromise impersonation (KCI) attack and replay the attack on 0-RTT data, which proved that the formal method based on model checking was an effective research method. However, Scyther completely encapsulated the implementation details of the adversary model, making it impossible for analysts to fully understand the details of the behavior of each participant during the operation of the protocol. In contrast to Scyther, CPN Tools can easily observe the movement of the message flow and the specific actions of each participant with the help of the colored Petri net theory, helping researchers to easily locate security flaws and formulate suggestions for improvement. Therefore, this study intended to formalize the 0-RTT authentication process of the IPP protocol by using the colored Petri net theory and CPN Tools.

2.2. The Dolev–Yao Adversary Model

In 1983, Dolev Danny and Andrew Yao proposed a mathematical model for verifying public-key cryptographic protocols [7], that is, the Dolev–Yao attacker model, which formally defined the attacker’s behavior. In the Dolev–Yao attacker model, the communication channel was completely under the control of the attacker. All messages sent to the network were sent to the attacker for processing, and any messages received from the network were processed by the attacker. The attacker had the following functions:

• Eavesdropping on all messages in the network;
• Block and intercept all messages in the network;
• Storing intercepted or self-created messages;
• Forge and send messages based on stored messages;
• Participate in the operation of the agreement as a legal agreement entity.

Dolev and Yao’s contributions were the following two points. The first point was to discuss the security properties of the protocol on the basis of assuming that the cryptographic system was “perfect”, which could help researchers to concentrate on the security flaws of the protocol design without discussing the mathematical flaws of the encryption algorithm. The second point was to propose that the attacker had stronger computing power than the real participants of the protocol: They could eavesdrop, intercept, tamper, and replay the information exchanged between legitimate participants during the operation of the protocol, and they could also encrypt, decrypt, split-and-combine original messages, and forge message content. Ram and Odelu used the Tamarin prover to analyze the security of key exchange protocol under the Dolev–Yao threat model [29], and Du and Gao also evaluated the DDS protocol security under the Dolev–Yao threat model [30].

2.3. Petri Nets

In 1962, Carl Adam Petri of the Federal Republic of Germany used a network structure to simulate a communication system for the first time in their doctoral thesis “Communication with Automata” [31]. This system model was later known as Petri net. It has been proved that the simulation ability of Petri net is equivalent to that of the Turing machine. The applications of Petri nets have been in various fields of computer science, such as circuit design, network protocol, software engineering, artificial intelligence, formal language, operating systems, parallel compilation, data management, and so on. Petri net is a combined model that can be expressed graphically, which is intuitive, easy to understand and use, and has unique advantages in describing, analyzing, and discovering concurrent phenomena. The Petri net analysis method that was developed with the help of mathematics has been used not only for static structure analysis but also for dynamic behavior analysis.

Using the classification method from concrete to abstract, Petri nets can be divided into a basic net system, a place-transition system, and an advanced net system. The basic network system focuses on the basic relationship between events and introduces the dynamic behavior of the network; the place-transition system is characterized by the flow of resources within the system; and the advanced network system dyes tokens with different personalities in different colors, reflecting both individuality (different colors) and commonality (same color). Among them, the colored net in the advanced net system has become the mainstream application model of Petri net in many application scenarios. For example, Sheng and Prescott used HCPN to model and optimize fleet spare parts inventories and disassembly repair-and-preventive maintenance [32]. Grobelna and Szcześniak used interpreted Petri nets for the modeling and analysis of autonomous control components in electrical energy systems [33]. Farooq and Idrees created formal modeling and improvements in stochastic path-routing network schemes using CPN [34]. The study in [35] considered the overall research on the security of the blockchain consensus protocol mechanism based on Petri net.

2.4. CPN Tools

CPN Tools [36] is a computer-aided design tool developed by Danish researchers for protocol modeling, analysis, and verification. CPN Tools is a set of graphical tools that support model editing, simulation, state-space analysis, and performance analysis [37]. It provides basic graphical representation, model concurrency, communication, and synchronization capabilities. Its state-space analysis and simulation tools have been used to investigate model behavior and verify protocol security properties. The ML (Markup Language) of CPN Tools is based on the standard ML programming language, which provides basic data type definitions (composite data types can be represented by product and union), and related manipulation instructions, which can create compact parameterized models. The interaction between users and CPN tools is based on directly manipulating the graphical representation of the CPN model, which is intuitive and has many industrial applications. Overall, CPN Tools is a powerful tool for the formal analysis of protocol security properties.

CPN IDE [38] is an alternative option to CPN Tools, which was recently updated and supported by the developers.However, when the author was implementing the experiment, the latest version provided on the official website was CPN Tools 4.0.1, so this study adopted it to complete the experiment.

3. Establishment of HCPN Model for IPP Authentication Process

3.1. Authentication Message Flow

The authentication and encryption module of the IPP protocol was implemented with the underlying TLS, which was divided into two modes: normal handshake and brief handshake. The brief handshake mode was also called PSK mode, and this paper focused on the 0-RTT handshake process in this mode.

Because the whole handshake process is complicated, this message model simplified partial details and only showed the key steps. In general, the PSK mode handshake process has two stages: initial handshake and subsequent handshake. In the initial handshake phase, the communication parties exchanged handshake parameters, the server completed the initial authentication, generated an authentication ticket, and sent it to the client; in the subsequent handshake stage, the client presented the ticket to the server to resume the session. On the premise that the PSK mode was enabled, the client could directly carry the early data in the first-stream “client-hello” message in the subsequent handshake phase and complete the short handshake authentication; therefore, this process was also called 0-RTT resumption process, as shown in Figure 1 below:

The specific process was described as below:

1.

Run the initialization algorithm, the client generated DHE handshake parameters and provided various elliptic curve parameters in the key_share extension for the server to choose;

2.

The server also generated DHE handshake parameters and, at the same time, selected the elliptic curve parameters supported by itself in the key_share extension and passes them to the client to complete the elliptic curve Diffie–Hellman ephemeral (ECDHE) key exchange. Then it generated a set of temporary symmetric keys, TempKey, encrypted subsequent messages (marked with curly braces). Sent a certificate-request message to request that the client should send a certificate for identity verification; sent a certificate message to provide a signature verification key; send a certificate-verify message to provide a signature verification key. Finally, performed integrity protection on the above handshake messages by calculating the message authentication code and obtaining a finished message.

3.

The client sent a certificate message to provide its own signature verification key, sent a certificate-verify message to provide a signature, and finally calculated the message authentication code with all previous handshake messages to obtain a finished message and send it to the client.

4.

After the server had verified the identity of the client, it generated an initial session key based on the TempKey and the handshake messages. The initial handshake phase was nearly complete. However, in order to implement the subsequent short handshake, a session ticket needed to be generated for the client. First, generated a pre-shared key PSK and encrypted it with the server private key S_prk to obtain the tag identity corresponding to the client identity. Then, encrypted with the initial session key (marked with square brackets) to obtain the new-session-ticket message and send it to the client. Thus, the initial handshake phase was complete.

5.

Entered the subsequent short handshake process, and the main purpose of this stage was for session resumption. The client calculated the session-binding value (binder) according to a label (identity) in the ticket information, and encapsulated it into the pre_shared_key extension of the client-hello message. At the same time, it used pre-shared-key to derive early data key (EDK) and encrypted (marked with parentheses) early data. This was the so-called 0-RTT mode, that is, the application data were sent during the first handshake. It should be noted that the pre_shared_key extension did not contain the real PSK value. In other words, the PSK value would not be transmitted in the network channel.

6.

After verifying the ticket, the server carried the pre_shared_key extension in the server-hello message to indicate that it agreed with the client to complete the handshake authentication in PSK mode. Then, it calculated the handshake message authentication code to ensure message integrity. Finally, it calculated the subsequent session key and encrypt the application data.

7.

The client replied with a finished message. Here, the finished message had the same function as the server-side finished message. It was the last message in the authentication process, marking the completion of the authentication process, and the session was completely restored.

8.

The client and the server encrypted (marked with square brackets) the application data through the subsequent session key for subsequent communication.

Using mathematical expressions showed the whole process clearly. First, the client and the server sent basic parameters to each other: key exchange parameters $g^{\alpha }$, $g^{\beta }$; random numbers $N_C$, $N_S$; cryptographic parameters offer; and mode. We defined them as variables u and v, as shown in Definitions (1) and (2).The variable offer indicated the multi-population, symmetric encryption, and hashing schemes supported by the client. The server chose one of the options provided by the offer and recorded it in the variable mode.

$$u:=g^{\alpha },N_c,offer$$

(1)

$$vs.:=g^{\beta },N_s,mode$$

(2)

After the two parties exchanged basic parameters, according to the DHE key-exchange algorithm, the client and the server independently calculated and derived a set of temporary symmetric keys $(k_{sh},k_{sm},k_{ch},k_{cm})$, as shown in Definition (3). Variables $k_{sh}$ and $k_{sm}$ were server hash key and mac key, respectively, and $k_{ch}$ and $k_{cm}$ were client hash key and mac key, respectively. The above calculations were completed internally by both parties in communication and could not be exposed to the outside world. The derivation function used was an HMAC-based key-derivation function (HKDF).

$$(k_{sh},k_{sm},k_{ch},k_{cm}):=H_1(g^{\alpha \beta },u,N_c,offer,v,N_s,mode)$$

(3)

After obtaining the temporary symmetric key, the system continued the subsequent authentication process. The server sent a certificate-request message to the client to request that the client should send a certificate for identity verification, sent a certificate message to provide a signature verification key, and sent a certificate-verify message to provide a signature. Finally, the SFinished message was obtained by calculating the message authentication code. The above messages were all hashed by the $k_{sh}$ and sent to the external network space. The calculation process is shown in Definitions (4)–(7).

$$c_1:=E(k_{sh},CertRequest)$$

(4)

$$c_2:=E(k_{sh},Cer{t}_C)$$

(5)

$$c_3:=E(k_{sh},Si{g}_S(u,N_C,offer,v,N_S,mode,c_1,c_2)$$

(6)

$$c_4:=E(k_{sh},SFin(u,N_C,offer,v,N_S,mode,c_1,c_2,c_3)$$

(7)

After receiving the server message, the client sent a certificate message to provide its own signature verification key, sent a certificate-verify message to provide a signature, and finally calculated the message authentication code with all previous handshake messages to obtain a CFinished message and sent it to the client. The above messages were all hashed by the $k_{ch}$ key and sent to the external network space. The calculation process is shown in Definitions (8)–(10).

$$c_5:=E(k_{ch},Cer{t}_C)$$

(8)

$$c_6:=E(k_{ch},Si{g}_C(u,N_C,offer,v,N_S,mode,c_1,c_2,\cdots ,c_5)$$

(9)

$$c_7:=E(k_{ch},CFin(u,N_C,offer,v,N_S,mode,c_1,c_2,\cdots ,c_6)$$

(10)

After the server verified the identity of the client, it generated an initial session key and established a secure communication channel. The calculation method of the session key is shown in Definition (11). Then, the system calculated the PSK, generated a session ticket, and sent it to the client after encryption. At this point, the initial handshake phase was complete. The calculation method of PSK was shown in Definition (12), where $N_t$ denotes a nonce ticket.

$$sesskey:=H_2(g^{\alpha \beta },u,N_C,offer,v,N_S,mode,c_1,c_2,\cdots ,c_4)$$

(11)

$$PSK:=H_3(g^{\alpha \beta },u,N_C,offer,v,N_S,mode,c_1,c_2,\cdots ,c_7,N_t)$$

(12)

After the client received the session ticket, it had all the materials needed to calculate the PSK and could independently generate PSK internally and then derive the EDK, and its calculation method is shown in Definition (13). Encrypted content was as defined in (14). Finally, the client encapsulated the early data cipher-text $c_8$ and the ticket-binding value in a client-hello message and sent it to the server.

$$EDK:=H_4(PSK,g^{\alpha \beta },u,N_C,offer)$$

(13)

$$c_8:=E_{EDK}\left(earlydata\right)$$

(14)

After the server verified the ticket, it calculated the finished message to ensure that the client message had not been tampered with by others and then encrypted and sent it back to the client, as shown in Definition (15). Finally, the subsequent session key was calculated to encrypt application data.

$$c_9:=E(k_{sh},SFin(u,N_C,offer,v,N_S,mode,c_8))$$

(15)

The client replied with a finished message, the content of which was as defined in (16).

$$c_{10}:=E(k_{ch},CFin(u,N_C,offer,v,N_S,mode,c_9))$$

(16)

3.2. 0-RTT Authentication Model

This section establishes the HCPN model of the 0-RTT resumption in PSK mode during the authentication process of the IPP. Using the CPN Tools tool, we applied the substitution transition in the top-level net to obfuscate some implementation details, defined the overall picture of the system in a broad sense, and simplified the model. The specific process of the substitution transition was controlled by the bottom sub-page implementation. The 0-RTT resumption authentication model in PSK mode included three layers, from top to bottom: the top layer, the entity sub-page layer, and the method sub-page layer. The top-level model was a brief description of the protocol as a whole; the entity layer sub-page described the main behaviors of each protocol-participating entity in the top-level model; and the method sub-page layer showed the details of the key methods of the entity layer. From coarse to fine, the three layers jointly completed the creation of the HCPN model of the IPP handshake authentication process. The experimental environment configuration is shown in the Appendix A.

3.2.1. Top-Level Model

The CPN top-level model of 0-RTT authentication in PSK mode was a simple description of the entire communication protocol, including the two parties involved, the communication network, and the messages transmitted, as shown in Figure 2. The double-lined rectangles in the figure are substitution transitions, and the ovals are message places. There were 3 transitions and 16 message places. The substitution transition Client on the left represents the client, the substitution transition Net in the middle represents the communication network, and the substitution transition Server on the right represents the server side. The top-level model simulated the three phases of 0-RTT authentication in a simplified form, including the parameter exchange phase (indicated in light blue), identity authentication phase (indicated in purple), and session resumption phase (indicated in dark blue). Figure 2 is the result of high abstraction and generalization of the protocol message flow.

3.2.2. Color Set Definition

After a comprehensive analysis of the protocol certification process, we extracted key steps to define and explain the color set in an easy-to-understand manner without changing the behavior of the original protocol. (When reading it for the first time, it is recommended to browse the general concepts. After reviewing the client model and server model, returning to this section for in-depth reading is suggested).

First, in the parameter exchange phase, the client and the server needed to exchange parameters, which provided conditions for an efficient ECDHE key-exchange process. For this purpose, the identity ID, random number NONCE, and elliptic curve group GroupList were defined. The random number increased the entropy value, which was used to increase the randomness of the later session key. The list of the elliptic curve groups contained some cryptographic options for both negotiating parties. After the session key was generated, the client and server used symmetric encryption to encrypt data, and Encryption List provided the AEAD encryption methods supported by the protocol. Similarly, HashList provided two hashing schemes for both parties to choose. The client encapsulated the curves, encryption schemes, and hash methods it supported into the parameter OFFER. According to its parameters, the server selected a group of collocations from OFFER and encapsulated them into the parameter MODE. Both parties sent MSG1 and MSG2, respectively, to complete the parameter exchange.

Secondly, in the identity authentication phase, both parties in communication generated an ephemeral symmetric key TempKey to encrypt the handshake communication data. The server sent CR (CertReq), Cert, Sign, and MAC handshake messages to complete the following functions: request the client certificate, send its own certificate, sign, and ensure the integrity of the handshake message. These 4 messages were processed with the server hash key $k_{sh}$, encrypted as $c_1,c_2,c_3,c_4$. Finally, they were packaged into MSG3 and sent to the client. Similarly, the client encapsulated its own certificate, signature, and message authentication code for all current handshake messages into MSG4 and sent it to the server. After the two parties successfully verified each other’s identities, they generated the initial session key. In PSK mode, the server generated a session resumption credential (ticket) bound to the current session, the client, and the PSK value, and encapsulated them as MSG5 and then transmitted it to the client in an encrypted channel.

Finally, in the session resumption phase, the client processed the session resumption ticket MSG5, generated a binding value (binder) associated with its own identity and PSK, and then encapsulated it with early data into MSG6 and sent it to the server to restore the session. Both MSG7 and MSG8 ensured the integrity of the handshake message.

As described, the color sets are defined in

Table 1. Color set definition for 0-RTT authentication.

Stage	Type	Colset Def.
	ID	colset ID = string with “A”, ..., “D”;
ParasExchange	NONCE	colset NONCE = int with 1, …, 3;
	Group List	colset GroupList = with secp256r1|x25519;
	EncryptionList	colset EncryptionList = with AES128GCM|AES256GCM|CHACHA20POLY1305|AES128CCM;
	HashList	colset HashList = with SHA256|SHA384;
	OFFER	colset OFFER = product GroupList*EncryptionList*HashList;
	MODE	colset MODE = product GroupList*EncryptionList*HashList;
	MSG1	colset MSG1 = product ID*NONCE*OFFER
	MSG2	colset MSG2 = product ID*NONCE*MODE
	KEY	colset KEY = int with 4, …, 8;
Authentication	TempKey	colset TempKey = product KEY*KEY*KEY*KEY;
	CR	colset CR = string;
	Cert	colset Cert = string;
	Sign	colset Sign = string;
	MAC	colset MAC = string;
	MSG3	colset MSG3 = product C1*C2*C3*C4;
	MSG4	colset MSG4 = product C5*C6*C7;
	SHASH	colset SHASH = product STR*STR*STR*STR;
	CHASH	colset CHASH = product STR*STR*STR;
	RESULT	colset RESULT = bool;
	MSG5	colset MSG5 = STR;
Resumption	EarlyData	colset EarlyData = STR;
	MSG6	colset MSG6 = product STR*STR*STR;
	MSG7	colset MSG7 = SFinished;
	MSG8	colset MSG8 = CFinished;

:

3.2.3. Middle-Level Model

The middle layer of the 0-RTT authentication in PSK mode could also be called the entity layer, which was composed of three entities: client, network channel, and server. This section describes the internal implementation details of the three separately.

As shown in Figure 3 below, the model of the client included 32 message places and 15 transitions. The client first sent its own parameters to the server to complete the ECDHE key exchange; then, it received the server certificate and signature to complete the server identity authentication, and at the same time, it provided its own certificate and signature to the server. Finally, if the server successfully verified the identity of the client, it generated relevant tickets to assist the client and optimize future sessions.

To provide more detail, in the first step, client(A) determined its own encryption parameter suite OFFER (x25519, AES128GCM, SHA256) and then attached the random number (nc), encapsulated them into MSG1, and sent it to the network channel in plain text. Note that since we did not include the calculation details of the DHE key-exchange algorithm in order to simplify the model, CID was used in MSG1 instead of the first parameter in Definition (1).

In the second step, client(A) received the server parameter MSG2 (SID, ns, mode), the server random number (ns) and the selected cipher suite (mode) and passed it to the hash-based key-derivation function HKDF to generate a temporary key (tk), which could be used in the subsequent process to generate authentication packets. Note that since we did not include the calculation details of the DHE key exchange algorithm in order to simplify the model, MSG2 uses SID to replace the first parameter in Definition (2).

In the third step, the client received the server message MSG3, which contains four hashed ciphertexts c1, c2, c3, and c4. They were obtained by encrypting 4 hash values, h1, h2, h3, and h4, with the handshake key (HK) by the server. They were obtained by encrypting the four handshake messages with the temporary symmetric key TempKey by the server. The four messages were: certificate-request, certificate, certificate-verify, and finished. The first message, certificate-request, indicated that the server needed to verify the identity of the client, requiring the client to generate a handshake authentication message MSG4 and send it to the server. The second through the fourth messages were provided to the transition VerifyS to verify the identity of the server. After the verification was passed, the client generated its own certificate, signature, handshake message, and authentication code. After they were encrypted by the temporary symmetric key TempKey in turn, they were packaged as MSG4 and sent to the communication channel.

In the fourth step, the client received the session resumption ticket MSG5, extracted the identity information identified by the server for the client, and calculated a binding value binder, which was bound to the initial session and identity. Then, it generated the pre-shared key PSK, and derive the early data key EDK to encrypt and send the early data ED. Then, it packaged the three as MSG6 and sent them to the server.

In the fifth step, the client received MSG7, which contained the server message authentication code “SFinished”. After the verification was passed, the client generated its own message authentication code “CFinished” and sent it to the server.

As shown in Figure 4, the model of the network included 16 message places and 8 transitions, which described the process of receiving and sending data packets from the client and server through the network channel. From top to bottom, the three phases of parameters exchange, identity authentication, and session resumption occurred in sequence, and a total of eight messages were delivered.

As shown in Figure 5, the model of the entity layer Server included 34 message places and 16 transitions. This model described the server receiving the messages from the network channel and processing them. It completed the whole process from establishing the initial session to session resumption.

Step 1: Received the message MSG1, obtained the client identity (CID), random number (nc), and cipher suite (offer). Selected the cipher suite mode supported by itself from the offer. For simplicity, in this model, the client only provided a set of commonly used suites (x25519, AES128GCM, SHA256), and it was assumed that the server supported this suite.

Step 2: The server generated its own identity (SID) and random number (ns), and organized it together with the (mode) to be sent as MSG2.

Step 3: The server completed part of the ECDHE exchange, used HKDF to derive temporary keys (ksh, ksm, kch, kcm), assigned values (4, 5, 6, 7), and passed them into the transition genSCiphers. The transition generated MSG3 and sends it out.

Step 4: Received MSG4 (c5, c6, c7) to authenticate the client identity (among them, the three ciphertexts c5, c6, and c7 were encrypted by the client messages certificate, certificate-verify, and finished through the temporary symmetric key TempKey). After the verification was passed, the server obtained the client public key, and the ECDHE key exchange was completed. The server generated an initial session key and encrypted and transmitted MSG5. MSG5 contained the session resumption credential ticket, whose main component was the client identity marked by the server and bound to the current initial session. This value was obtained by encrypting the pre-shared key PSK with the server private key S_prk, which avoided the transmission of the PSK plaintext in the network channel and could ensure that PSK was not leaked even if the initial session key was leaked.

Step 5: The server received MSG6 and restored the session in a simple way. The hash value binder was bound to the initial session and the ticket. After verifying that the ticket was legitimate with the private key S_prk, the server queried the pre-shared key PSK corresponding to the ticket and exclusive to client A in its own database. Then, it derived EDK to decrypt the early data and generate subsequent session keys. Finally, the generated message authentication code SFinished was encapsulated as MSG7 and sent to the client.

Step 6: Received the client message authentication code CFinished. If the verification passed, the subsequent session would be completely restored.

3.2.4. Bottom-Level Model

The bottom layer was also called the method layer, which implemented two methods: verification and hash-ciphertext generation. These two methods were key supporting steps in the client and server authentication phases. Both communication parties implemented these two methods internally and obtained four method models: genSCiphers, VerifyS, genCCiphers, and VerifyC. In chronological order, the four events occurred in sequence: the server generated identity information; the client verified the server identity; the client generated identity information; and the server verified the client identity. The specific implementation details of these four processes are described below.

genSCiphers: The server generated identity information, as shown in Figure 6. The message requesting the client certificate was stored in the place CertReq. The server certificate was stored in the place S_Cert. The hash values h1 and h2 were obtained by the two under the action of the server hash key ksh. Then, it was encrypted with the handshake key to form c1 and c2 (blue). The c1 and c2 were the raw materials for generating the server signature ss. The server signature completed the same process to obtain c3 (purple). In addition to c1, c2, and c3, the generation process of the server mac also required the participation of the server MAC key ksm. Then, we could obtain c4 (green) after hashing and encoding with ksh (server hash key) and hk (handshake key). Finally, the four hash ciphertexts were encapsulated and sent out.

VerifyS: The client verified the identity of the server, as shown in Figure 7. First, the client decrypted (c1, c2, c3, c4) to obtain the corresponding hash values (h1, h2, h3, h4, respectively), and then calculated the hash values of the four messages received: certificate-request, certificate, certificate-verify, and finished. Finally, it compared whether the results obtained in the first two steps were consistent. If they were consistent, it indicated that the result was correct and the protocol was allowed to continue (green); otherwise, the protocol execution failed (red).

genCCiphers: The client generated its own identity information, as shown in Figure 8. After verifying the identity of the server, the client received the reply to continue the protocol, generated the client certificate cc, calculated the hash value with the client hash key kch, and encrypted it to obtain c5. MSG3 contained the server identity information ciphertext (c1, c2, c3, c4), which was the raw material for client to generate signature and message authentication code. MSG3 and c5 generated client signature cs, which was encrypted by kch to obtain c6 (purple). Then MSG3, c5, and c6 were processed by kcm to obtain the client message authentication code cm, which was then encrypted to obtain c7 (green). The three hash ciphertexts were encapsulated and sent out.

VerifyC: The server received and verified the client identity. This method was almost the same as VerifyS, as shown in Figure 9.

3.3. Consistency Verification

Whether the original protocol model had accurately reflected the protocol behavior determined its effectiveness.This section provides an overview of the state-space analysis tool used to verify the functional consistency between the model and the original protocol authentication process. Our verification focused on three stages: parameter exchange, identity authentication, and session resumption. This determined whether the behavior of each entity in the model was correctly executed according to the original protocol specification.It was important to note that the attacker model had not been introduced at this time.

3.3.1. Expected Results

When analyzing the spatial state of the protocol model, researchers need to investigate its state-space nodes, main markings (main-state nodes), dead markings (dead-state nodes), and transitions, and then compare them with the expected results to judge whether the model was constructed correctly.

As shown in Figure 7 and Figure 9, when the communication parties verified each other’s identities, they first decrypted the other party’s identity information and the corresponding hash value, and then used the agreed-upon algorithm to calculate another set of hash values for the identity information. Comparing the consistency of the two sets of hash values was key to determining whether the authentication process was successful. When the verification was successful, the token “OK” was returned, and the protocol entity continued to execute the protocol (green); otherwise, “err” was returned, and the protocol entity triggered the reset transition RESET to re-execute or terminate the protocol (red); therefore, it could be predicted that transitions RESET0 and RESET1 were two dead transitions in the model.

In addition, the original authentication model had to reach the terminal and end operations after the authentication was complete, so the following could be determined: The model coverage state was full; there was no live transition in the terminal state, only one main marking and one dead marking. The main marking and dead marking, though their names might be unknown, had to be consistent and numbered equal to the terminal marking’s number.

Table 2. Expected Results.

Category	Dead Transition	Live Transition	Status	Home Marking	Dead Marking
Count	2	0	Null	1	1
Name	RESET0, RESET1	Null	Full	End-node number	End-node number

presents the expected results for the state space of the original protocol model.

3.3.2. Experiment Results

The state-space tool was the primary tool for detecting and analyzing the protocol model. We used it to analyze the behavior and security properties of the model. First, we entered the “State Space” tool of CPN Tools. Then, we initialized the “Calculate State Space” function and the “Calculate SCC Graph” function, each in turn. If the operation was successful, it indicated that a state space of the protocol model had been generated. At this point, we chose the “Save Report” function to obtain a standard state-space report of the model to be evaluated. The results are shown in

Table 3. Model State-Space Results for the Original Protocol .

Category	Statistics	Name
Nodes	443	1, …, 443
Arcs	1090	1, …, 1090
Status	Full	Null
Nodes(SCC)	443	1, …, 443
Arcs(SCC)	1090	1, …, 1090
Home Markings	1	443 *
Live Transitions	0	0
Dead Transitions	1	443 *
Dead Transitions	2	RESET0, RESET1

* An asterisk represents a terminal state node.

.

The total numbers of state-space nodes and directed arcs were the same as that of the strongly connected component graph (SCC) nodes and arcs, and the space state was completely covered, indicating that all state nodes in the security assessment model were reachable. There was only one main state node and dead state node, the name number was the same, and both were equal to the terminal state node number “443”, indicating that the original protocol model did not have loop and iterative behaviors that could cause the state to occur infinitely, and normally operated from the initial state to the terminal state. RESET0 and RESET1 were, indeed, two dead transitions in the model, and the results were exactly as expected. Next, an attacker model was introduced to verify the security properties of the protocol.

4. Security Assessment of Original Scheme

4.1. Security Assessment Model

Using the advantages of CPN visual modeling, dynamic simulation, and system state-space analysis, this section introduces the improved Dolev–Yao attacker model into the original protocol model to evaluate the security of the protocol and analyze the loopholes in the protocol. According to the Dolev–Yao attack hypothesis, the attacker could intercept all the messages of the sender, and under certain circumstances (e.g., key disclosure), decrypt, tamper, and forge the message, and then transmit it to the receiver. On this basis, we further strengthened the attacker’s ability to obtain the pre-shared key PSK, so an improved Dolev–Yao attacker model was established. At this point, the adversary could replace the Net entity in the original protocol model, take over the entire network, and form a security assessment model for the original protocol, as shown in Figure 10.

First, we conducted a preliminary analysis of all current handshake messages:

• MSG1 (CID, nc, offer) and MSG2 (SID, ns, mode) were transmitted over the network in plain text in order to complete the parameter exchange, so the security authentication function was provided by the follow-up mechanisms.
• MSG3 (c1, c2, c3, c4), MSG4 (c5, c6, c7) assisted the client and the server in verifying each other’s identity encrypted with TempKey. The key was obtained by ECDHE key exchange, and the generation process involved the participation of the private keys($\alpha ,\beta$ in Definitions (1) and (2)), of both communication parties. The improved Dolev–Yao attacker model did not have the ability to corrupt the client and server, obtain their private keys, nor decipher the two messages.
• In MSG5(ticket), the ticket was obtained by encrypting PSK with the server’s private key, which was used as a credential for subsequent session resumption and encrypted by the initial session key. The initial session key was derived from the temporary symmetric key TempKey, with a previous handshake messages. As long as the TempKey was not leaked, the security of the message could be guaranteed.
• MSG7 (SFinished) and MSG8 (CFinished) were encrypted and transmitted by the subsequent handshake key. At this time, in order to ensure forward security, another round of ECDHE key exchange was performed during the subsequent handshake-key-generation process. This process involved the private keys of both parties and could be cracked.

Therefore, considering the current attacker’s ability, the attack behavior was aimed at the handshake message MSG6 in the subsequent session resumption phase.

Figure 11 shows the model diagram of the attacking entity Adversary.

In the first step, the adversary activated the attack path. It assigned the Boolean value “true” stored in the place Active to the variable active. The normal output path (green) of the original transition “TransmitResumpt” was blocked, so it entered the attack path (red). MSG6 (binder, c8) was divided into two parts and stored in the corresponding repository. This step was possible because the binder was a string of HMAC values contained in the PSK extension of the client-hello message in plain text.

In the second step, it decrypted c8 to obtain the early data ed. C8 was the message encrypted by the client with the early data key EDK, and EDK was only uniquely determined by the pre-shared key PSK. According to the assumption of the improved Dolev–Yao attack model, the adversary could obtain the shared key PSK, so it could successfully decrypt C8.

In the third step, it enabled three types of attacks in sequence. If the replay attack was enabled, the attack vectors (RP, MD, FG) was initialized to (true, false, false). If the tampering attack was enabled, it assigned (RP, MD, FG) with (false, true, false). Similarly, if forgery attack was enabled, it assigned (RP, MD, FG) with (false, false, true).

In the fourth step, when a certain type of attack was launched, used the replay attack as an example, the opponent used the early data key EDK to encrypt the replay data RPD into the attack message atk1. combined with ticket and binder, packaged as MSG6 and sent to the server.

4.2. Original Protocol Evaluation Results

Using the same process as previously described, we used CPN Tools to obtain the state-space report of the safety assessment model. The results are shown in

Table 4. State Space of Original Protocol Security Evaluation Model.

Category	Statistics	Name
Nodes	875	1, …, 875
Arcs	2593	1, …, 2593
Status	Full	Null
Nodes(SCC)	875	1, …, 875
Arcs(SCC)	2593	1, …, 875
Home Markings	1	875 *
Live Transitions	0	0
Dead Transitions	1	875 *

* An asterisk represents a terminal state node.

.

Compared with the original protocol model, the number of state-space nodes and directed arcs in the security evaluation model increased significantly due to the introduction of the improved Dolev–Yao attacker model, which was typical. Every time a place was added, the state vector describing the protocol space increased by one dimension. CPN Tools analyzed and counted all possible combination results, resulting in a large number of space-state nodes.

The numbers of state-space nodes and directed arcs were the same as that of the strongly connected component graph (SCC) nodes and arcs. Furthermore, the space state was completely covered, indicating that all state nodes in the security assessment model were reachable.

There was only one main state node and dead state node, the name number was the same, and both were equal to the terminal state node number “875”, which showed that the evaluation model did not have loop and iterative behaviors that caused the state to occur infinitely, and could be operated normally. Next, through the simulation tool Sim that had been included with CPN Tools, we obtained the model termination state result, as shown in Figure 12.

If the replay attack was activated multiple times, each instanced would provide the termination state vector (ED, SESSIONKEY, STATUS) = (“replay_ED”, “session key”, “over”). This showed that the server could perceive the adversary’s replay attack on early data. This result was not unexpected. In order to improve the speed of the protocol operation, 0-RTT authentication did not rely on the random number Ns of the server when generating EDK, so the server was unable to prevent the adversary from replaying the early data. All other key generation processes depended on $N_s$. It was very dangerous: Suppose the client sent a query request to query the account balance in the early data. Since the response message length was related to the number of digits in the account balance, an adversary could monitor a target user’s account balance by replaying client requests multiple times. Therefore, the original protocol did not have the ability to resist the adversary’s multiple replay attacks and needed to be improved.

The other two attacks, tampering and forgery, could not be carried out smoothly because the communication parties exchanged their message authentication codes (SFinished and CFinished) at the end of the authentication. This message provided protection for the integrity of the ED. Any modification behavior would show anomalies in the subsequent inspection process, forcing the certification process to abort.

It was worth noting that the content of “replay_ED” in the previous paragraphs was exactly the same as the early data “ED”. Here, it was just an easy-to-distinguish name for the convenience of understanding and description.

5. Improved Scheme and Results

Through the above evaluation, the 0-RTT authentication process in the IPP protocol did not meet the security attribute requirements. Specifically, it could not resist replay attacks against early data in the 0-RTT authentication process. Further analysis of the behavior of the protocol entity in the session resumption process revealed that the unsafe factor was related to the following: After the server decrypted the early data, it lacked the necessary identification means to confirm whether the data were replayed by the adversary. In this section, aiming at the above-mentioned protocol loopholes, the random number signature was introduced to enhance the server’s perception and authentication ability as well as to realize the improvement of the original protocol. Finally, CPN tools was used again to analyze and verify the effectiveness of the improved scheme.

5.1. Improved Scheme

The improved scheme did not change the top-level or bottom-level models. All changes were in the middle layer, that is, the entity layer. Based on the original protocol model as shown in Figure 3 and Figure 5, the newly added or changed parts are marked in brown for easy identification.

5.1.1. Client Side

As shown in Figure 13, the behavior of the client entity did not change significantly. The only difference was that in the session resumption phase, each time the client sent a resumption request, it generated a random number, rand. Then, it signed it with its own private key to obtain the signature data signdata, as shown in Definition (17). Next, it attached it to c8 and sent it to the server. Finally, it sent it to the server as part of c8, as defined in (18). The rest were exactly the same as the standard protocol and are not repeated here.

$$signdata:=Si{g}_C\left(random\right)$$

(17)

$$c_8^{{}^{\prime }}:=E_{EDK}(earlydata,signdata)$$

(18)

5.1.2. Server Side

As shown in Figure 14, after receiving MSG6, the server began the session resumption process and decrypted the early data and signature data. Then, it used the client public key and signature data to verify whether the random number rand1 was signed by the client. It continued the execution after the verification was affirmed. The server cached the random number rand2, received in the last session recovery request every time, and compared the two. Under normal circumstances, the two would not be equal, because the client would have generated a new random number every time it sent a recovery request. In the transition “compare”, the Boolean variable ret was used to record the comparison result. If the ret value was “TRUE”, it indicated that the two numbers were not equal, and the session could be established normally. If the ret value was “FALSE”, it indicated that the same random number had been used twice, and an intermediary had replayed the session recovery request. At this time, the server would terminate the handshake.

5.2. Improved Result

After obtaining the improved scheme, the adversary model was introduced again to verify the security of the scheme. The experimental results are shown in

Table 5. State space of improved scheme.

Category	Statistics	Name
Nodes	1718	1, …, 1718
Arcs	5988	1, …, 5988
Status	Full	Null
Nodes(SCC)	1718	1, …, 1718
Arcs(SCC)	5988	1, …, 5988
Home Markings	1	1718 *
Live Transitions	0	0
Dead Transitions	1	1718 *

* An asterisk represents a terminal state node.

.

6. Discussion

Table 6. Comparison of state space before and after improvement.

Category	Before	After
Nodes	875	1718
Arcs	2593	5988
Status	Full	Full
Nodes(SCC)	875	1718
Arcs(SCC)	2593	5988
Home Markings	875 *	1718 *
Live Transitions	0	0
Dead Transitions	875 *	1718 *

* An asterisk represents a terminal state node.

shows the comparison of the results of the state space before and after the improvement. As compared to previous results, before the improvement, the number of transitions and places, as well as the number of state nodes and arcs of the improved model, had increased significantly, which was typical. The reason was explained in Section 4.2.

By comparing the definition (8) with the definition (18), we found that the improved scheme only increased the signature step of the client and the verification step of the server. There were the internal data processing steps of the communicating parties, which were not visible to the outside world, and would not affect the external handshake process of the standard protocol. For each authentication, the communication parties still followed the sequence from MSG1 to MSG8 to complete all the steps. This guaranteed the equivalence and verifiability of the improved scheme, as compared to the standard protocol.

After modeling correctly, we used the Sim tool again to observe the end-state of the model and obtained the end-state vector (ED, SESSIONKEY, STATUS) = (“replay_ED”, NULL, “Closed”), as shown in Figure 15. This showed that when the adversary had activated the replay attack and replayed the early data ED multiple times, the server detected the abnormality, did not generate the subsequent session key, and closed the session, which ensured the authentication security.

The improved scheme of introducing random number signature enhanced the server’s ability to resist multiple replay attacks, which was proved by the experimental results.

The reason for the success of this scheme was related to the following two points: First, every time the client used the 0-RTT authentication, it attached a newly generated random number rand and signed it to the early data. This ensured that the random number could only be generated by the client and was different every time. The adversary could only replay but could not tamper or forge the random number because they did not have a client-signing private key. Second, the server cached the random number in the last session resumption request and compared it with the newly decrypted random number. Once the two were equal, it indicated that the early data ED had been replayed, and the handshake should be closed immediately.

In general, the optimized protocol only added a signature to the client’s session recovery request, which was a very small cost for the processing speed of modern computers and the transmission speed of the network. The return was that it effectively enhanced the server’s ability to perceive and identify replay attacks. In addition, the added signature would not affect other messages, especially the finished message sent by the last communication parties. The change introduced by the new scheme was only the following: the variable $c_8$ in Definition (14) was replaced by $c_8^{{}^{\prime }}$ in Definition (18). This did not introduce any structural changes to the computing. It should be noted that the signature algorithm used by the optimization protocol was recommended for a fixed algorithm, so that there was no need to add the content of the negotiation parameters in the client-hello message.

The limitation of this solution was that the random number generation algorithm of the client could provide the same random number as before, with a very small probability, causing the server to misjudge a normal request as a replay attack and terminate the authentication process.

7. Conclusions

Guided by the theory of colored Petri nets and the improved Dolev–Yao attack method, this study used the model-detection tool, CPN Tools, to focus on the 0-RTT authentication process in the PSK mode of IPP. Through formal modeling and by introducing attacker models, the loophole of the original protocol was discovered. We then proposed a targeted improvement plan based on this vulnerability. Finally, the same attacker model was introduced again to analyze and verify the new scheme’s security properties. We proved that, as compared to the original protocol scheme, the improved scheme resisted replay attacks by the adversary. In the future, we will consider using a stronger adversary model to verify the protocol process, try to find vulnerabilities not found in the current adversary model, and help protocol designers avoid potential security risks in advance.