Research on the Security of NC-Link Numerical Control Equipment Protocol Based on Colored Petri Net

Abstract

The NC-Link protocol, as an integrated communication protocol in the Computerized Numerical Control (CNC) machine tool industry, has drawn significant attention regarding its security since its inception. Although there have been studies proposing improvements to address security issues related to key management and message transmission, systematic security analysis of the protocol remains relatively weak. To better investigate and enhance the security of the NC-Link protocol, our research introduces a formal modeling and analysis method based on Colored Petri Nets (CPN). By establishing a CPN model of the protocol, we analyze the security issues present during communication and propose improvement measures for verification and analysis. First, we developed a CPN model for the NC-Link protocol and verified the model’s feasibility through simulation analysis. Subsequently, we introduced an attacker model to analyze the protocol’s authentication interaction process, revealing security issues, such as authentication vulnerabilities and key management flaws. Finally, we proposed an improved scheme addressing these issues and conducted a security validation and cost analysis of this scheme. The results show that the improved protocol reduces the computational overhead by 75% during the connection and interaction phases. This indicates that the improved protocol can achieve interactions at a faster speed while maintaining higher security and reliability. The implementation of this scheme provides new reference ideas for related research.

1. Introduction

As the manufacturing industry continues to evolve, CNC equipment has gradually become an indispensable part of the modern industry. However, as machine tool control systems have become increasingly intelligent and networked, security issues have become more pronounced, presenting new challenges for the security of CNC machine tool control systems [1]. The communication protocol for CNC machine tools serves as the foundation for controlling and monitoring these machines, directly affecting production efficiency and product quality in the manufacturing sector [2]. Therefore, research on the security of CNC machine tool protocols is of significant practical importance and has far-reaching social implications. The NC-Link protocol, an important communication protocol widely used in CNC machine tool control systems, not only impacts the performance and stability of these systems, but is also directly related to production efficiency and product quality in the manufacturing industry. However, the NC-Link protocol currently faces several security issues such as data eavesdropping, tampering, and forgery [3]. The streamlined design of the NC-Link protocol, while enhancing its usability, has also introduced numerous security vulnerabilities [4]. These issues could lead to attacks on machine tool systems, affecting production efficiency and product quality in the manufacturing sector and potentially causing significant economic losses and personal harm. Although there has been extensive research on secure communication protocols in industrial environments, there is still relatively little literature on protocols that effectively integrate dynamic key exchange and advanced authentication techniques tailored to the specific needs of industrial systems, particularly concerning the security and interoperability of heterogeneous CNC machine protocols. This urgency makes the study of protocol security an immediate concern. Among the various methods for analyzing protocol security, formal analysis methods have demonstrated outstanding performance [5]. By introducing the Dolev-Yao attacker model [6], effective security analysis of the protocol can be achieved. In order to enhance the security of the NC-Link protocol and enable more effective analysis and validation, this study employs a Colored Petri Net (CPN) model for formal modeling and analysis. It investigates the security issues that arise during a protocol’s application by integrating the protocol’s characteristics with existing authentication solutions to analyze and improve its authentication and key management mechanisms. This approach effectively enhances the security of the NC-Link protocol and provides practical support and theoretical guidance for its security research. The research begins by introducing the characteristics of the NC-Link protocol and the current state of research. It then details the communication mechanism, data transmission process, and security issues associated with the NC-Link protocol. Next, the design principles and implementation process of the CPN-based verification model for the NC-Link protocol are presented. Following this, an analysis of the protocol’s security is conducted, and improvement proposals are made for the identified issues. Finally, the feasibility and effectiveness of the improvement proposals are validated through experiments, along with an analysis of the protocol’s computational overhead. The contributions of this research are as follows:

• A formal analysis model for the security of the NC-Link protocol was established based on Colored Petri Nets (CPN), providing an in-depth analysis of the existing security issues and proposing corresponding security solutions.
• By integrating the characteristics of the NC-Link protocol with existing authentication solutions, improved security mechanisms have been proposed to address issues in the protocol’s authentication and key management mechanisms, thereby enhancing the overall security of the NC-Link protocol.
• The feasibility and effectiveness of the improvement proposals were validated through experimental modeling, and an analysis of the protocol overhead was conducted, offering practical support and theoretical guidance for security research on the NC-Link protocol.

2. Related Research

The NC-Link protocol specifies the message format, protocol control, message interaction, and transmission rules for communication between the CNC system and the machine tool controller. However, there may be some security issues during the transmission of the NC-Link protocol, where attackers can employ methods such as man-in-the-middle attacks, tampering attacks, and replay attacks to gain control of the machine tool or disrupt its normal operation. The following sections will introduce the research content related to this topic from three perspectives: the security of the NC-Link protocol, the CPN-based formal analysis method, and the Dolev-Yao attacker model.

With the continuous development of smart manufacturing technologies, various highly compatible communication protocols have been proposed, including MTConnect [7], OPC Unified Architecture (OPC UA) [8], and umati [9]. Internet access and mobile communication technologies have developed very rapidly and have enabled users to access useful services. This accessibility provides convenience to users but simultaneously makes them vulnerable to malicious attacks [10]. Especially in recent years, China has also introduced the NC-Link protocol in order to enable CNC technology to reach international standards faster [11], which serves as the interconnection interface specification for CNC machine tools in smart factories. As more equipment adopts the NC-Link protocol, a significant amount of data is generated, leading to an increasing scale of data. This inevitably results in a series of security risks during data transmission, storage, and usage. Currently, research related to the security of the NC-Link protocol is still relatively limited. Reference [12] addresses issues related to the low efficiency of data collection, incomplete structures, and inconsistent formats in CNC equipment by proposing a modeling method for CNC equipment information based on knowledge graphs. Reference [13] highlights the lack of protective security mechanisms in the protocol, which can lead to security risks such as data theft, tampering, and unauthorized access. It proposes an access control algorithm based on symmetric homomorphic encryption and establishes a secure communication system based on this algorithm, further enhancing the security and granularity of the access control scheme. Reference [14] focuses on the characteristics of open CNC production lines and network security issues, proposing a security and trust protection framework based on Trusted Computing 3.0, and the concept of defense in depth, utilizing trusted NC-Link proxies/adapters to achieve reliable connections for heterogeneous devices on the production line. Although these studies have proposed solutions for improving the security of the NC-Link protocol, a detailed approach in terms of protocol analysis is still lacking.

Currently, there are two main types of methods for analyzing protocol security: formal analysis methods and attack detection methods (non-formal methods) [15]. For the formal analysis of security protocols, there are primarily two aspects: those based on computation complexity and those based on symbolic representation. The protocol formalization method based on computation complexity represents the protocol’s interaction behaviors as mathematical models, studying the transformation states of these models through logical deduction and subsequently conducting formal analysis based on the model’s state transitions [16]. In contrast, the symbolic formal security analysis method uses an attacker model as its foundation, abstracting all the normal and attack behaviors of the protocol into symbolic descriptions. It combines symbols representing behaviors into attack sequences and abstracts all cryptographic primitives into “black boxes”, enabling the formal verification of the protocol’s security properties under the assumption of perfect cryptographic algorithms [17]. Among the symbolic formal security analysis methods, model checking is the most widely used. This method employs state search tools and standard meta-languages to check various properties of the protocol, transforming the protocol’s message flow into formal description languages supported by these tools, and analyzing the protocol using automated detection tools. Commonly used model-checking techniques include finite state machines [18] and Petri nets [19]. Reference [20] proposed a modular model-checking method based on the SPIN model-checking tool, which decomposes a specified abstract model into several modules and performs model checking on these relatively low-complexity modules as a substitute for checking the original model. Reference [21] introduced a model-checking method for verifying multi-agent interaction strategies, automatically validating the model, and analyzing various errors in the interaction strategy based on counterexamples generated by the model checker. Reference [22] utilized the probabilistic model-checking tool PRISM to model and verify the security of semi-quantum cryptographic protocols, thereby improving the speed and efficiency of the verification process. Reference [23] enhanced the formal modeling method for security protocols based on CPN, validating and extracting attack paths, and proposed a waiting synchronization method for different processes at various levels of the CPN model, effectively controlling the size of the model’s state space.

In the formal analysis of security protocols, analysis techniques based on model checking and theorem proving are almost all built upon the Dolev-Yao model. The Dolev-Yao model, first proposed by Dolev and Yao in 1983, serves as a hypothetical model for the formal analysis of security protocols and is divided into two parts: the cryptographic system model and the attacker model [24]. The cryptographic system model treats cryptographic primitives as black boxes and assumes that all utilized cryptographic primitives and algorithms are perfect. This means that analysis methods based on the Dolev-Yao model cannot conduct cryptanalysis; however, it is significant in that it separates the security protocol itself from the employed cryptographic system, thereby reducing the difficulty of analyzing and verifying protocol security [25]. Reference [26] proposed an efficient vehicle identity authentication and key transmission scheme based on the Dolev-Yao attack model. The protocol was formally assessed using a model-checking method that combines Colored Petri Nets (CPN) with the Dolev-Yao attacker model, demonstrating that the proposed scheme effectively withstands three types of man-in-the-middle attacks. Reference [27] utilized a modeling approach based on CPN theory to model the service-oriented middleware (SOME/IP) protocol for vehicle Ethernet and conducted formal verification and analysis of the security protocol using the Dolev-Yao attacker model-checking method. The verification revealed vulnerabilities to replay, tampering, and impersonation attacks in the protocol.

Although numerous related studies have been conducted on the security of the NC-Link protocol, there is still a lack of formal analysis methods to evaluate its security performance and address existing security issues. The formal analysis method that combines CPN theory with the Dolev-Yao attacker model has shown good performance in protocol security analysis. This paper conducts formal modeling of the NC-Link protocol based on CPN theory and introduces the Dolev-Yao attacker model to extract key elements of the protocol for security testing, analyzing the inherent security issues. Compared to other research proposals, the solution presented in this paper possesses the property of formal verification. This new formal model-checking method not only verifies the consistency of the original model but also analyzes the protocol’s security and proposes targeted improvement methods.

3. Formal Analysis of NC-Link Protocol

3.1. NC-Link Protocol Interaction Process

The structural design of the NC-Link protocol consists of four main layers: the CNC equipment layer, the adapter layer, the proxy layer, and the application layer. The CNC equipment layer includes various CNC machine tools and other CNC devices, which are responsible for executing actual manufacturing tasks and communicating with the upper layers through adapters. The adapter layer is responsible for data conversion and communication between the CNC equipment layer and the proxy layer. The proxy layer manages and coordinates multiple adapters; collects, processes, and transmits device data to the application layer; and distributes commands from the application layer to the corresponding adapters. The four-layer structure of the NC-Link protocol achieves efficient and reliable communication and collaboration between CNC devices and industrial applications through a clear hierarchical design. The structural design of the NC-Link protocol is illustrated in Figure 1.

Figure 1. Structural design of the NC-Link protocol.

Before receiving information, the NC-Link adapter needs to subscribe to the relevant topics from the NC-Link proxy. After this, the application system can publish messages on that topic, allowing the NC-Link adapter to receive messages from the application system. If the upper-layer application system wants to receive return results from the NC-Link adapter, it must also subscribe to relevant topics in advance. The bidirectional transmission mechanism of the NC-Link protocol is illustrated in Figure 2.

Figure 2. Bidirectional transmission mechanism of the NC-Link protocol.

The authentication process of the NC-Link protocol is as follows: First, the terminal sends a registration instruction to the proxy. The proxy decrypts the user identity information in the registration instruction, checks whether a terminal identifier exists, and approves it. Next, the proxy generates a Rivest Shamir Adleman (RSA) key pair for the terminal and returns the encrypted RSA private key as the access certificate. Subsequently, the terminal re-encrypts the received access certificate and sends the re-encrypted access certificate back to the proxy as a connection request. The proxy decrypts the connection request and checks whether it corresponds to the access certificate generated for this session; then, the proxy returns the decrypted access certificate (terminal RSA private key). Finally, the terminal successfully connects and conducts data exchange based on the access certificate. The authentication process of the NC-Link protocol is illustrated in Figure 3.

Figure 3. Authentication process of the NC-Link protocol.

The data exchange process of the NC-Link protocol is as follows: During the sending process, the sender dynamically generates an Advanced Encryption Standard (AES) key and encrypts the AES key using the receiver’s RSA public key. After receiving the data, the receiver first uses its RSA private key to decrypt the AES key and then uses the AES key to decrypt the data. The data exchange process of the NC-Link protocol is illustrated in Figure 4.

Figure 4. Data exchange process of the NC-Link protocol.

3.2. Message Model of the NC-Link Protocol

The message communication of the NC-Link protocol is divided into the authentication phase, connection phase, and interaction phase. The steps are detailed below.

3.2.1. Authentication Phase

Step 1: The client generates registration information (REMSG). The client uses a pre-shared symmetric key (SPSK) to encrypt the client ID and registration information.

$$Encrypt data={Enc}_{SPSK}({ID}_{client}||REMSG)$$

(1)

Here, ${Enc}_{SPSK}()$ represents the symmetric encryption operation using the key SPSK. ${ID}_{client}$ represents the client ID. After encryption, the client sends the encrypted data to the server.

Client → Server: ${Enc}_{SPSK}({ID}_{client}||REMSG)$.

Step 2: After receiving the encrypted data, the server decrypts it using the shared key SPSK.

$${Decrypt data=Dec}_{SPSK}({Enc}_{SPSK}({ID}_{client}\left|\right|REMSG))$$

(2)

Here, ${Dec}_{SPSK}()$ indicates the decryption operation performed using the key SPSK.

Step 3: After decryption, the server verifies whether the ${ID}_{client}$ is legitimate. If the ${ID}_{client}$ is valid, the server generates an RSA key pair (SRK, PRK) for the client. The server encrypts the client’s private key PRK as an access certificate using the shared key SPSK.

$$Encrypt certificate={Enc}_{\mathrm{S}\mathrm{P}\mathrm{S}\mathrm{K}}(PRK)$$

(3)

Step 4: The server sends an encrypted access certificate to the client.

Server → Client: ${Enc}_{SPSK}(PRK)$.

3.2.2. Connection Phase

Step 1: After receiving the encrypted access certificate, the client decrypts it using the shared key SPSK.

$$Decrypt certificate={Dec}_{SPSK}({Enc}_{SPSK}(PRK))$$

(4)

Step 2: The client encrypts the access certificate PRK using its private key PRK and sends the encrypted certificate to the server.

$$Encrypt certificate={Enc}_{\mathrm{P}\mathrm{R}\mathrm{K}}\left(PRK\right)$$

(5)

Client → Server: ${Enc}_{PRK}(PRK)$.

Step 3: After receiving the encrypted certificate, the server decrypts it using the private key PRK.

$$Decrypt certificate={Dec}_{PRK}({Enc}_{PRK}(PRK))$$

(6)

The server then compares the received certificate to the previously sent access certificate. If they match, the verification is considered to be successful. After successful verification, the server sends an encrypted certificate to the client.

Server → Client: ${Enc}_{PRK}(PRK)$.

Step 4: After the client receives the encrypted certificate returned by the server, it decrypts and verifies whether it matches the sent certificate. If they match, the connection is considered to be successful.

3.2.3. Interaction Phase

Step 1: The sender generates a symmetric encryption key (KEY) and the interaction data, and then encrypts the interaction data using KEY.

$$Encrypt data={Enc}_{KEY}( Interactive Data)$$

(7)

The sender encrypts the interaction key (KEY) using the client private key (PRK).

$$Encrypt key={Enc }_{PRK}(KEY)$$

(8)

Step 2: The sender transmits the encrypted data along with the encrypted key to the receiver.

Sender → Receiver: $({Enc}_{PRK} (KEY)\parallel {Enc}_{KEY}(Interactive Data)$

Step 3: Upon receiving the interaction request, the receiver decrypts the key using the private key PRK.

$$KEY={Dec}_{PRK}({Enc}_{PRK}(KEY))$$

(9)

The receiver uses the decrypted key KEY to decrypt the interaction data.

$$Interactive data={Dec}_{KEY} ({Enc}_{KEY}(Interactive data))$$

(10)

Step 4: The sender and receiver can use the key KEY for encrypted data interaction.

The message flow model of the NC-Link protocol is shown in Figure 5.

Figure 5. Message flow model of the NC-Link protocol.

3.3. CPN Modeling of the NC-Link Protocol

The CPN model of the NC-Link protocol is defined in Equation (11).

$$CPN=(\Sigma ,P,T,A,N,C,G,E,I)$$

(11)

In this context, the color set (Σ) defines the main data types within the protocol, including the user identity (ID), RSA keys, and access certificates. The places (P) represent the various states during different phases, ranging from the terminal sending the registration request to successful connection and data exchange. The transitions (T) denote the key operations in the protocol that drive the state transitions. The arcs (A) connect the places and transitions, illustrating how data flows through the process. The node function (N) further clarifies the specific interactions between each place and transition. The color function (C) ensures the correctness of data types within the places, while the guard function (G) defines conditions such as authentication and validity checks for the encryption certificates. Arc expression (E) specifies how data are transmitted along the arcs, and initialization function (I) sets the initial state of the protocol.

Define the color set of the NC-Link protocol model. Independent data items, such as identity ID and keys, are defined as enumerated class color sets. Composite data that connect and facilitate interaction messages are defined as product (tuple) class color sets. An encrypted ciphertext is defined as a separate data item of the product class color set of keys and plaintext that can only be decrypted into plaintext form by entities possessing the corresponding key data items. Some defined color sets are combined to form a union color set. In the interaction, ID, REMSG, SPSK, PRK, COMSG, and KEY serve as six atomic pieces of information, while all other interaction information is constructed based on these atomic elements. ID represents the client identity information, REMSG denotes the registration request information, SPSK is the shared key intended for use, PRK is the RSA private key generated by the server for the client, COMSG is the interaction information, and KEY is the AES key generated by the client. The specific definitions of the color sets are shown in Table 1.

Table 1. Definition of color sets in the NC-Link protocol.

Key Elements	Color Set Definition	Explain
ID	colset ID = INT	Client identity ID
REMSG	colset REMSG = STRING	Registration information
SPSK	colset SPSK = STRING	Pre-shared key
PRK	colset PRK = STRING	Client RSA private key
COMSG	colset COMSG = STRING	Interaction information
KEY	colset KEY = STRING	AES key generated by the client
REGMSG	colset REGMSG = product ID*REMSG	Registration request packet
ENCREGMSG	colset ENCREGMSG = product SPSK*REGMSG	Encryption of identity ID and registration information
ENCPRK1	colset ENCPRK1 = product SPSK*PRK	SPSK encrypts PRK
ENCPRK2	colset ENCPRK2 = product PRK*PRK	PRK encrypted certificate
ENCCOMSG	colset ENCCOMSG = product KEY* COMSG	Interaction data packet
ENCKEY	colset ENCKEY = product PRK*KEY	PRK encrypts KEY
CONMSG	colset CONMSG = product ENCCOMSG*ENCKEY	Interaction request packet

3.4. Top-Level Model of the NC-Link Protocol

The top-level model of the NC-Link protocol consists of 7 transitions and 16 places. The transition “Regision” represents the client sending a registration request and receiving a registration reply from the server. The “Regisited” transition indicates that the server receives the client’s registration request and replies. The “Connection” transition signifies the client’s request to connect to the server after successful registration and the reception of the server’s reply. The “Connected” transition represents the server receiving and responding to the client’s connection request. The “Alternation” transition indicates the client initiating an interaction request to the server and receiving a response. The “Alternated” transition shows the server receiving the client’s request and sending a reply to the client. The “Net” transition represents the information transmission network. After the “Regision” sends the registration request, it receives the request, generates a key for the client, and replies. The key is then sent to “Connected” for verifying the client’s connection request. Upon successful registration, “Regisition” sends the certificate to “Connection” for initiating the connection request to the server. After “Connected” receives the link request, it uses the key to decrypt and verify the certificate. Upon successful verification, it replies to the client and sends the key to “Alternated” for data interaction. Once the connection is successful, it sends the certificate to “Alternation” to initiate the interaction request. After “Alternated” receives the interaction request, it decrypts using the key and sends a reply to the client. The top-level model of the NC-Link protocol is shown in Figure 6.

Figure 6. Top-level model of the NC-Link protocol.

3.5. Bottom-Level Model of the NC-Link Protocol

The “Regision” transition simulates the process of the client sending a registration request to the server. First, the client generates the registration request information based on its ID and registration details using the transition “com_REGMSG”. The client then encrypts this registration request information using the pre-shared key SPSK through the transition “enc_REGMG” before sending it out via the output place “seENCREGMSG”. Upon receiving the server’s reply, the place “ReENCPRK1” utilizes the pre-shared key SPSK to decrypt the reply and obtain the certificate PRK. The certificate is then sent to the output place “reg” through the transition “send_PRK”. The internal model of the transition “Regision” is illustrated in Figure 7.

Figure 7. Internal model of the substitution transition Regision.

The “Regisited” transition simulates the process of the client sending a registration request and receiving a registration reply from the server. After receiving the client’s registration request through the input place “ReENCREGMSG”, the server uses the transition “Rencmsg” to decrypt the registration request information with the pre-shared key SPSK. It then verifies the client’s ID using “Com_ID” to determine its validity. Based on the client’s registration information, the server generates an RSA key pair for the client, sending the client’s private key PRK to the transition “ENCPRK”. The transition “ENCPRK” then outputs the client’s private key to the output place “Clreg”, while the PRK, encrypted with the pre-shared key SPSK, is sent to the output place “SeENCPRK1”. The internal model of the transition “Regisited” is illustrated in Figure 8.

Figure 8. Internal model of the substitution transition Regisited.

The “Connection” transition simulates the process of the client sending a connection request and receiving a connection response from the server. After successful registration, the client receives the registration certificate through the input place “Reg” and uses the transition “Regsuccess” to store the successful registration information along with the certificate PRK. The client then encrypts the certificate using the pre-shared key SPSK with the transition “EncPRK” and sends it to the output place “seENCPRK2”. When the input place “ReCONNECT” receives the server’s connection response message, it uses the transition “Connect” to store the connection success message and the transition “Send_PRK” to send the decrypted certificate to the output place “Con”. The internal model of the transition “Connection” is illustrated in Figure 9.

Figure 9. Internal model of the substitution transition Connection.

The “Connected” transition simulates the server receiving and responding to the client’s connection request. The server receives the client’s RSA private key PRK through the input place “cleg” and the connection request sent by the client via the input place “reENCPRK2”. The transition “Regsuccess” uses the client’s private key PRK to decrypt the received registration certificate. The transition “EncPRK” verifies whether the client’s certificate is correct; if it is, the connection success information is stored, and the certificate is encrypted with the client’s private key PRK before being sent to the output place “SeCONNECT”. If the received certificate is incorrect, the connection failure information is stored. If the client successfully connects, the transition “Sen_PRK” sends the client’s connection certificate to the output place “Clcon”. The internal model of the transition “Connected” is illustrated in Figure 10.

Figure 10. Internal model of the substitution transition Connected.

The “Alternation” transition simulates the client initiating an interaction request to the server and receiving the server’s response after successfully connecting. Once connected, the client obtains the access certificate through the input place “Con” and generates the interaction key KEY. The transition “ENCCOMSG” encrypts the client’s interaction information using the interaction key KEY, while the transition “ENCKEY” encrypts the client’s interaction key KEY with the client’s private key PRK. The transition “COMMSG” combines the encrypted interaction information with the client’s interaction key and sends it to the output place “ReCONMSG”. The input place “ReENCCOMSG” receives the interaction information returned by the server, which is then decrypted using the interaction key KEY through the transition “RENCrECOMSG”. The internal model of the transition “Alternation” is illustrated in Figure 11.

Figure 11. Internal model of the substitution transition Alternation.

The “Alternated” transition simulates the server receiving the client’s request and sending a reply to the client. After the input place “ReCONMSG” receives the client’s interaction request, the transition “ReCONMSG” splits the interaction key and the protective information. The transition “ENKEY” uses the public key PRK received from the input place “Clcon” to decrypt the interaction key. The transition “ENCCOMSG” then decrypts the interaction information using the decrypted interaction key KEY. Finally, the transition “ENCRECOMSG” encrypts the interaction information returned by the server using the interaction key KEY and sends it to the output place “SeENCCOMSG”. The internal model of the transition “Alternated” is illustrated in Figure 12.

Figure 12. Internal model of the substitution transition Alternated.

The “Net” transition simulates the information transmission network, which is used to forward communication information between the client and the server. The internal model of the transition “Net” is illustrated in Figure 13.

Figure 13. Internal model of the substitution transition net.

3.6. Verification of the CPN Model for the NC-Link Protocol

The results of the NC-Link protocol model analysis using state-space tools are presented in Table 2. From the state-space analysis results in Table 2, it can be concluded that the numbers of state-space nodes, directed arcs, strongly connected nodes, and strongly connected components in the NC-Link protocol model are all the same, indicating that there are no state cycles in the model. The number of dead nodes is unique, and the number of dead transitions is zero, suggesting that the model executes according to the protocol interaction flow with exactly one terminal state.

Table 2. State-space of the NC-Link protocol CPN model.

Type	Number
State-Space Nodes	59
Directed Arcs	90
Strongly Connected Nodes	59
Strongly Connected Arcs	90
Dead Nodes	1
Dead Transitions	0

The interaction states of each step after protocol execution are shown in Figure 14. Tokens indicating success are generated at the registration success location, connection success location, and interaction authentication location. This indicates that the model’s execution results match the expected outcomes of the protocol interactions.

Figure 14. Interaction state query of protocol execution.

4. Security Analysis of the Protocol

4.1. Attacker Model for the NC-Link Protocol

In the NC-Link protocol model, an attacker model is introduced in the network transmission layer. To avoid state-space explosion issues resulting from the introduction of the attacker model, a series of optimizations are performed on the model. Information unrelated to the attack is removed, and the maximum number of attack reconstructions is limited. Functions and arc expressions are added to control the number of dead transitions and dead nodes, and session keys are incorporated to improve the model’s resistance to key leakage attacks. The attacker model for the NC-Link protocol is illustrated in Figure 15. In the figure, the blue section represents replay attacks. When the value of “Reattack” is set to “true”, the attacker executes a replay attack, during which messages are stored in places P12 and P13 and then sent to the output place for replay via transitions T13 and T14. The green section indicates the tampering attacks. Due to the existence of a pre-shared key for devices, the device information and ID are encrypted, preventing the attacker from directly tampering with them; thus, tampering attacks in the model occur after key leakage attacks. During the registration phase of the NC-Link protocol, although an RSA key is generated after registration, all devices share the same pre-shared key, making the key particularly susceptible to leakage. The red section of the attacker model represents key leakage attacks. Once the attacker obtains the pre-shared key, they can not only decrypt the client’s device registration information but also intercept the device’s RSA private key, which provides the attacker with many avenues to exploit the protocol. In the model, when “Diattack” is set to “true”, the attacker executes a tampering attack, and when “Keattack” is set to “true”, the attacker performs a key leakage attack.

Figure 15. Attacker model of the NC-Link protocol.

4.2. Verification Result Analysis

In the NC-Link protocol model, the attacker employs different methods to attack the protocol, including replay attacks, tampering attacks, key leakage attacks, and combined key leakage and tampering attacks. The state spaces of the model under different attacks are shown in Table 3.

Table 3. Comparison of state paces of the NC-Link protocol model under different attacks.

Type	Tampering Attack	Replay Attack	Key Leakage	Key Leakage and Tampering	All Attacks
State-Space Nodes	16	62	107	323	347
Directed Arcs	22	94	203	822	880
Strongly Connected Nodes	16	62	107	323	347
Strongly Connected Arcs	22	94	203	822	880
Dead Nodes	1	1	1	1	1
Dead Transitions	34	12	6	1	0

Through the state-space analysis report, it can be observed that without key leakage, the attacker is unable to execute tampering attacks. The results of dead transitions in the state-space analysis report are shown in Figure 16a,b. From Figure 16a, it is evident that the model stops before the parties establish an interaction. Further investigation reveals in Figure 16b that after the client sends the encrypted registration information, it is tampered with by the attacker, resulting in the server’s failure to decrypt the registration information with the key, and consequently, a registration failure. The state-space report results when the attacker only performs a replay attack are shown in Figure 16c. The results indicate that all dead transitions arise from untriggered attacks. Inspecting the client message reception location reveals two tokens, indicating that the attacker successfully launched an attack on the protocol. When the attacker obtains the pre-shared key and conducts a key leakage attack, the state-space report results are displayed in Figure 16d. The results show that all dead transitions arise from untriggered attacks. Checking the attacker’s knowledge location, which stores the correctly decrypted interaction information, confirms that the attacker has successfully executed a key leakage attack. After acquiring the key, the attacker initiates a tampering attack during the protocol authentication phase. The state-space report results are illustrated in Figure 16e, showing that an inactive transition is related to the attacker’s failure to perform a replay attack. Upon inspecting the server registration information location, it was found to contain tampered information, indicating that the attacker successfully executed a tampering attack. When the attacker simultaneously conducts three types of attacks, the state-space report results are presented in Figure 16f. At this point, the number of dead nodes is 1 and the number of dead transitions is 0, confirming that the attacker successfully launched an attack on the protocol.

Figure 16. (a–f) Query results of state space analysis reports under different attacks.

Based on the analysis above, the NC-Link protocol’s message format is characterized by simplicity, good extensibility, and ease of understanding and implementation. However, it also has significant security issues. Attackers can intercept transmitted messages to carry out tampering or replay attacks. The message acknowledgment mechanism in the NC-Link protocol employs a simple confirmation or denial approach using message IDs to implement this mechanism. This acknowledgment system does not guarantee message security and requires additional security measures to prevent attackers from intercepting, tampering with, or replaying messages sent by the NC program. Furthermore, the key generation method in the NC-Link protocol is overly simplistic, making it vulnerable to key theft attacks. A more secure key exchange method and robust key update mechanism are necessary to mitigate the risk of key leakage on time.

5. NC-Link Protocol Security Improvements and Verification

5.1. NC-Link Protocol Security Improvements

In response to the issues identified in the NC-Link protocol, this study proposes an improved key generation and exchange scheme that incorporates timestamps to counter replay attacks. The improved protocol includes an authentication connection phase and a request interaction phase. In the authentication connection phase, a pre-shared key mechanism is not used; instead, the client generates an RSA key pair based on the device information and achieves key exchange with the server through zero-knowledge authentication. The details of the improved scheme are as follows:

5.1.1. Authentication Connection Phase

Step 1: The client selects two large prime numbers p and q (where p and q belong to a set of large primes) and calculates the modulus n.

$$n=p\times q$$

(12)

Calculate Euler’s function $\varphi (n)$.

$$\varphi (n)=(p-1)\times (q-1)$$

(13)

The client selects a private key exponent d (such that 1 < d < ϕ(n) and d is coprime to $\varphi (n)$), and then calculates the public key exponent s.

$$s=g^d mod n$$

(14)

where g is the generator calculated based on the client’s ID, satisfying the condition that for any $d\in \{\mathrm{1,2},\dots ,p-1\}$, there exists an integer k such that the Equation (15) holds.

$$g^k\equiv d mod n$$

(15)

The client generates the RSA key pair: the public key (${PRK}_{(n,s)}$) is used for encryption, and the private key (${SRK}_{(n,d)}$) is used for decryption.

Step 2: The client randomly selects a number r and computes the commitment value x.

$$x=s^{r}mod n,r\in \{\mathrm{1,2},\dots ,n-1\}$$

(16)

The client generates authentication information based on the commitment value x and signs it using a private key (SRK).

$$Signature data={Sign}_{SRK}(x||EMSG)$$

(17)

Here, ${Sign}_{SRK}()$represents using SRK for signature. The client sends the public key (PRK) and the signed authentication information to the server.

Client → Server: ${Sign}_{SRK}(x||EMSG)$.

Step 3: After receiving the authentication information, the server uses the client’s public key (PRK) to verify the signature. If the verification is successful, the server checks whether the ${ID}_{client}$ is valid. If valid, the server generates a connection key (KEY) and selects a random challenge value e∈{0,1}. The server encrypts e and KEY using the client’s public key (PRK) and sends it to the client.

Server → Client: ${Enc}_{PRK}(e||KEY)$.

Step 4: Upon receiving the encrypted information, the client decrypts it to obtain e and KEY. Then, the response value y is calculated based on the challenge e and Equation (18).

$$y=r+e\times d mod(n-1)$$

(18)

The client encrypts y using the connection key (KEY) and sends it to the server.

Client → Server: ${Enc}_{KEY}(y)$.

Step 5: The server decrypts the response value y.

$$\mathrm{y}={Dec}_{KEY} ({Enc}_{KEY}(y))$$

(19)

Verify whether y is correct based on Equation (20).

$$g^y mod\hspace{0.17em}\hspace{0.17em}n=x\times s^e mod\hspace{0.17em}\hspace{0.17em}n$$

(20)

If the verification is successful, the server confirms the client’s identity and sends the connection key, encrypted as a certificate using KEY, back to the client. The client then decrypts this to confirm that the connection is successful.

5.1.2. Request Interaction Phase

Step 1: The sender dynamically generates an interaction key (KEY2) and an interaction request message. The interaction key (KEY2) is encrypted using the connection key (KEY), and the interaction request information is encrypted with the interaction key (KEY2) along with a timestamp before being sent to the receiver.

Client → Server: ${Enc}_{KEY2}(Signature data),{Enc}_{KEY}(KEY2)$

Step 2: Upon receiving the request, the server checks the validity of the timestamp and decrypts the interaction information and the interaction key (KEY2) using the connection key (KEY). The server then uses KEY2 to decrypt the interaction information. The receiver encrypts the reply information with KEY2 and sends it back to the sender.

Server → Client: ${Enc}_{KEY2}(Signature data)$

Step 3: The client receives the reply information, decrypts it using KEY2, and continues the interaction. All subsequent communication is encrypted using the dynamically generated interaction key (KEY2) to ensure the security of the communication.

The message flow model of the improved NC-Link protocol is illustrated in Figure 17.

Figure 17. Improved message flow model of the NC-Link protocol.

5.2. CPN Model of the Improved NC-Link Protocol

The top-level model of the improved NC-Link protocol consists of five transitions and 16 places. The “Regision and Connection” transitions represent client identity authentication and connection initiation. The “Regisited and Connected” transitions signify server identity verification and connection establishment. The “Alternation” transition indicates the client’s request for interaction, while the “Alternated” transition represents the established connection between the server and the client. The “Net” transition symbolizes the information transmission network. The top-level model of the improved NC-Link protocol is illustrated in Figure 18.

Figure 18. Improved top-level model of the NC-Link protocol.

The alternative transitions “Regision and Connection” simulate the process of the client generating an RSA key pair and sending and receiving identity authentication information and connection requests to the server. The internal model of the alternative transitions “Regision andConnection” is illustrated in Figure 19.

Figure 19. Internal model of the substitute transition Regision and Connection.

The alternative transitions, “Regisited and Connected”, simulate the process of the server receiving and verifying the client’s authentication information and connection requests, as well as sending replies. The internal model of the alternative transitions “Regisited and Connected” is illustrated in Figure 20. In Figure 19 and Figure 20, the client randomly generates an RSA key and computes the interaction information X using the transition “IDSID”. The client then signs the interaction information X with the RSA private key and sends the RSA public key along with the signed X to the output place “SePRKSIDX” for transmission to the server. The server retrieves the information through the input place “RePRKSIDX”, where it uses the RSA public key to verify the signature of X and generates the connection key (KEY). Simultaneously, the client generates a random challenge value, e. The transition “ReKEYE” encrypts the challenge value e and the connection key (KEY) using the RSA public key (PRK) and sends the encrypted data through the output place “SeENCKEYE”. Upon receiving this data through the input place “ReENCKEY”, the client uses the transition “RENCMSG” to decrypt the challenge value and the connection key (KEY).The transition “GETY” calculates the challenge response y based on the challenge value e, and the transition “ENCKEY” encrypts the challenge response y with the connection key (KEY) before sending it through the output place “SeENCY”. The server retrieves the challenge response y through the input place “ReENCY” and uses the connection key (KEY) to decrypt it. The transition “SEKEY” checks the correctness of the challenge response y. If correct, the connection key (KEY) is used as a certificate, which is then encrypted and returned to the client through the output place “SeCONNECT”. Upon receiving the certificate through the input place “ReCONNECT”, the client confirms that the connection with the server has been successfully established.

Figure 20. Internal model of the substitute transition Regisited and Connected.

The transition “Alternation” simulates the process of the client initiating an interaction request to the server and receiving a response after establishing a connection. The internal model of the transition “Alternation” is illustrated in Figure 21.

Figure 21. Internal model of the substitute transition alternation.

The transition “Alternated” simulates the process of the server receiving the client’s request and sending a reply to the client. The internal model of the transition “Alternated” is illustrated in Figure 22.

Figure 22. Internal model of the substitute transition alternated.

In Figure 21 and Figure 22, the client obtains the connection key (KEY) from the input place “Con” and dynamically generates the interaction key (KEY2). The transition “ENCCOMSG” encrypts the interaction information using the interaction key (KEY2), while the transition “ENCKEY” encrypts the interaction key (KEY2) using the connection key (KEY). The encrypted information is then sent to the server through the output place “SeCONMSG”. The server receives the encrypted information via the input place “ReCONMSG”. The transition “ENCKEY” decrypts the interaction key (KEY2) using the connection key (KEY), and the transition “ENCCOMSG” decrypts the interaction information using (KEY2). The transition “ENCRECONMSG” encrypts the reply information using the interaction key (KEY2) and sends it to the client through the output place “SeENCCONMSG”. The client retrieves the reply information via the input place “ReENCCONMSG”, and the transition “RENCReCOMSG” uses the interaction key (KEY2) to decrypt the reply information, establishing the interaction between both parties.

The state-space analysis of the improved model is presented in Table 4. From the analysis of the state-space results, it can be concluded that in the improved model, the number of state-space nodes, directed arcs, strongly connected nodes, and strongly connected arcs are all the same, indicating that the model does not have state cycles. There is a unique number of dead nodes, and the number of dead transitions is zero, which suggests that the model executes according to the protocol interaction flow, resulting in exactly one termination state.

Table 4. State-space of the improved protocol CPN model.

Type	Number
State-Space Nodes	43
Directed Arcs	58
Strongly Connected Nodes	43
Strongly Connected Arcs	58
Dead Nodes	1
Dead Transitions	0

5.3. Security Analysis of the Improved Protocol

In the improved NC-Link protocol model, an attacker model is introduced at the network transport layer. The NC-Link protocol attacker model is illustrated in Figure 23. The blue section indicates replay attacks, the green section represents tampering attacks, and the red section denotes key leakage attacks. In the model, when the value of Reattack is set to “true”, the attacker performs a replay attack; when Diattack is set to “true”, a tampering attack is conducted; and when Keattack is set to “true”, a key leakage attack occurs.

Figure 23. Improved NC-Link protocol attacker model.

In the improved NC-Link protocol model, replay attacks, tampering attacks, key leakage attacks, and combined key leakage and tampering attacks are introduced. The state space of the model under different attacks is shown in Table 5.

Table 5. Comparison of state space under different attacks in the improved protocol model.

Type	Tampering Attack	Replay Attack	Key Leakage	Key Leakage and Tampering	All Attacks
State-Space Nodes	34	45	20	34	34
Directed Arcs	61	64	28	61	61
Strongly Connected Nodes	34	45	20	34	34
Strongly Connected Arcs	61	64	28	61	61
Dead Nodes	1	1	1	1	1
Dead Transitions	22	9	22	22	22

The state-space analysis report indicates that under various attack scenarios, the attacker cannot successfully execute any attacks on the protocol. When an attacker attempts a tampering attack, the tampered information cannot validate the signature, resulting in all transitions after RESIGX becoming dead transitions. Additionally, due to the inclusion of timestamps in the information, tampering attacks fail, as evidenced by the presence of an “err tim” token in the TIMOUT place. When an attacker conducts a key leakage attack, the generation of a new key for each authentication means that any old keys held by the attacker cannot validate the signature information. The analysis of the state-space report shows that the improved protocol effectively resists various attacks while also mitigating the key leakage risks present in the original protocol’s key generation and management. A comparison of the security performance between the improved protocol and the original protocol is presented in Table 6.

Table 6. Comparison of security performance between the improved protocol and the original protocol.

Comparison Items	Tampering Attack	Replay Attack	Key Leakage	Key Leakage and Tampering
Original Protocol	✓	✗	✗	✗
Improved Protocol	✓	✓	✓	✓

In the table, “✓” indicates that the protocol can withstand the specified type of attack, while “✗” indicates that it cannot. Comparing the two, it is clear that the improved protocol offers a higher security performance than the original protocol, addressing the issues related to key management that arose from the original protocol’s use of a pre-shared key authentication scheme.

5.4. Comparison of Overheads in the Improved Protocol

The overhead of the NC-Link protocol mainly involves communication overhead, computational overhead, and implementation costs. First, the time complexity and space complexity of the improved protocol method will be analyzed separately. The time complexity of RSA encryption is $O(k^3)$, where k is the key size of RSA. During encryption, exponentiation is performed using a public key; therefore, the complexity is cubic. The time complexity of RSA decryption is also $O(k^3)$; however, because the private key is larger, decryption is usually slower than encryption. Like encryption, decryption also involves exponentiation. The space complexity of RSA mainly depends on the key storage. For RSA-2048, the space complexity is $O(k)$, where k is the key size. The ciphertext size is the same as the key size; therefore, the data after RSA encryption or decryption typically occupy $O(k)$ storage space. The signing process involves encrypting the hash value using a private key. Hashing the data using functions like SHA-256 generally has a time complexity of $O(n)$, where n is the byte length of the data. Signing the hash value with the private key in RSA has a time complexity of $O(k^3)$, where k is the key size. The verification process also requires hashing the received data, with a time complexity of $O(n)$. The time complexity of verifying the signature using the public key is $O(k^3)$. The size of RSA signatures and verifications is proportional to the key size. For RSA-2048, the signature size is typically 256 bytes (2048 bits). Therefore, the space complexity is $O(k)$. The time complexity of AES encryption is $O(n)$, where n is the byte length of the data. The time complexity of AES decryption is similar to that of AES encryption and is also $O(n)$. The space complexity of AES encryption and decryption is $O(n)$, where n is the byte size of the encrypted data. AES generally has a smaller space complexity compared to RSA because its key length is shorter (128 bits or 256 bits), and the encryption/decryption process is symmetric. The time complexity of zero-knowledge authentication is $O(k^3)$, similar to RSA, mainly due to the number-theoretic exponentiation. The space complexity, because it is related to RSA, is also $O(k)$, where k is the key size. The time complexity and space complexity of the improved protocol method are shown in Table 7.

Table 7. Time complexity and space complexity of the improved protocol method.

Protocol/Method	Time Complexity	Space Complexity	Parameter Description
RSA Encryption	$O(k^3)$	$O(k)$	where k is the key size
RSA Decryption	$O(k^3)$	$O(k)$	where k is the key size
RSA Signing	$O(k^3)$ + $O(n)$	$O(k)$	where n is the byte length of the data
RSA Signature Verification	$O(k^3)$ + $O(n)$	$O(k)$	where n is the byte length of the data
AES Encryption	$O(n)$	$O(n)$	where n is the byte size of the encrypted data
AES Decryption	$O(n)$	$O(n)$	where n is the byte size of the encrypted data
Zero-Knowledge Authentication	$O(k^3)$	$O(k)$	where k is the key size

We will compare the overhead of RSA and AES in terms of key generation and encryption/decryption. In key generation, RSA involves selecting two large prime numbers, p and q, calculating the modulus n, computing the Euler function ϕ(n), and performing modular inversion to calculate the private key exponent d. In contrast, AES only requires generating a key from a high-entropy source and does not involve complex mathematical operations, resulting in a very low key generation overhead, typically taking only a few microseconds. For encryption, the time taken for RSA encryption depends on the size of the public key exponent, e. For example, with RSA-2048, encrypting 128 bits of plaintext usually takes several milliseconds. In comparison, AES-256, with 14 rounds of encryption, can typically complete the same length of ciphertext in less than a microsecond on a CPU. Regarding decryption, RSA decryption is generally slower than encryption because the private key exponent d is usually a large number. For a 2048-bit RSA, decrypting 128 bits of ciphertext may take several tens of milliseconds. In contrast, the AES decryption time is equivalent to the encryption time, which is usually completed within a few microseconds.

Implemented on an Intel Core i5 CPU with a clock speed of 1.1 GHz, using Python and the Crypto library for simulation, Table 8 shows the average computation times for encrypting 128-bit plaintext for two different encryption methods and RSA signing.

Table 8. Average computation times for the two encryption methods and RSA Signing.

Method	Key Generation	Encryption/Signing	Decryption/Verification
RSA Encryption	3.756 s	0.005 s	0.231 s
AES Encryption	0.97 μs	<0.01 μs	<0.01 μs
RSA Signing	3.756 s	0.005 s	0.237 s

The calculation results indicate that the protocol’s computational overhead mainly consists of RSA key generation, decryption, and verification, while the average AES key generation time is only 0.97 μs, with both encryption and decryption times being less than 0.01 μs. The improved scheme integrates the zero-knowledge proof process during key exchange with RSA key generation, and its additional overhead primarily arises from verification. The calculation time for the verification function run using a Python program is shown in Table 9, where p and q are two large 1024-bit prime numbers.

Table 9. Computational verhead of zero-knowledge proof process.

Verification Function	Computational Overhead
$n=p\times q$	2.92 s
$x=s^{r}mod n,r\in \{\mathrm{1,2},\dots ,n-1\}$	<0.01 μs
$g^y mod\hspace{0.17em}\hspace{0.17em}n=x\times s^e mod\hspace{0.17em}\hspace{0.17em}n$	<0.01 μs
$y=r+e\times d mod(n-1)$	<0.01 μs

From the calculation results, it can be concluded that the computational overhead for zero-knowledge authentication originates primarily from the generation of the commitment value. In the improved scheme, the commitment value is generated based on RSA key data, and the computational overhead for its verification is less than 0.01 μs.

Let Trg denote the RSA key generation overhead, Trc the RSA encryption overhead, Trd the RSA decryption overhead, Trs the RSA signing overhead, Tri the RSA signature verification overhead, and Tag the AES key generation overhead. The overheads for AES encryption, AES decryption, and zero-knowledge verification, all being less than 0.01 μs, are denoted as Tμs. The overhead calculations for the original and improved protocol schemes at different stages are shown in Table 10.

Table 10. Cost calculation for different stages of the original and improved protocol schemes.

Stage	Registration	Connection	Interaction
Original Scheme	Trg + 3 Tμs	Tμs + 2 Trc + 2 Trd	Tag + Trc + Trd + 2 Tμs
Improved Scheme	Trg + Trs + Tri + Tag + Trc	Trd + 6 Tμs	Tag + 4 Tμs

In the calculation process, any overhead below 0.01 μs is uniformly recorded as 0.01 μs. By organizing the overhead formulas for each stage in the table, the computational overheads for different schemes can be derived. Comparing the computational overhead of various schemes yields the results shown in Figure 24.

Figure 24. Comparison of overhead for different schemes.

By comparing the computational overheads of the different schemes, it can be observed that the improved protocol has a lower computational overhead compared to the original protocol. Notably, the overhead during the interaction phase shows a significant reduction, allowing devices to achieve faster interactions after completing registration and connection. This also facilitates an increased frequency of updating the interaction keys during the interaction phase, further enhancing the security of the protocol.

6. Conclusions

This article primarily focuses on the security issues of the NC-Link machine tool protocol, employing a formal modeling approach based on Colored Petri Nets (CPN). By establishing a CPN model and incorporating the Dolev-Yao attacker model, the security of the NC-Link protocol is formally analyzed. The analysis reveals vulnerabilities in identity authentication and key management, rendering the NC-Link protocol weak against attacks such as data eavesdropping, tampering, and forgery. In response to these issues, we propose an improved scheme that combines zero-knowledge proofs with key exchange, optimizing both the authentication and key management mechanisms. The experimental results demonstrate that the improved scheme reduces computational overhead while enhancing security. A 75% reduction in computational overhead during the connection and interaction phases is more conducive to increasing the frequency of updating the interaction keys during the interaction phase, making the improved scheme more secure and reliable. This research not only provides a practical solution for enhancing the security of the NC-Link protocol but also opens new avenues for the study of communication protocol security in the CNC machine tool industry. Future research could further explore other potential security issues based on this study and integrate advanced security technologies into the NC-Link protocol to strengthen its resilience against attacks in complex network environments.