1 Introduction

In recent years, with the development of the industrial Internet, smart homes and buildings are combined with new technologies such as the Internet and cloud platforms, and household equipment and buildings are gradually becoming intelligent and networked [1, 2]. In this process, household equipment and buildings are more and more closely connected with the outside world, which makes the connection between people and household equipment and buildings more convenient and faster. But while bringing convenience to people, the security issues of these industrial Ethernet devices are becoming increasingly prominent. At present, the protocols used in buildings and smart homes are mainly to achieve reliable communication and information transmission between devices, but these generally have the problem of poor security. For example, traditional building automation protocols: BACnet, LonTalk [3], EnOcean [4], etc. They are verified that there are serious security problems and have been threatened by serious attacks such as network information tampering and virus intrusion. The emerging home and building automation is an organic combination of Ethernet technology and building and home equipment. Its high efficiency, high performance, and intelligence are hot spots in this research field.

KNXnet/IP [5], as a building automation application layer protocol, has also been researched by many scholars. However, like traditional protocols, KNXnet/IP also faces serious security issues. For example, the appli-cation port 3671 of the KNXnet/IP protocol is often scanned [6], decreasing the communication speed between devices. Some hackers send a large number of invalid requests to the KNX device server to make it unable to work normally and cause a denial of service attack [7]. Some criminals deceive the KNXnet/IP system by forg-ing IP addresses [8], thereby circumventing security defenses. These network attacks will directly affect the normal use of home and building equipment, resulting in user information leakage. Facing more and more security issues of building and home equipment automation, this article will choose the typical and commonly used building Ethernet protocol KNXnet/IP as the analysis object. Strengthening the security inside the protocol has important research significance in both industry and academia. Specifically, this paper has three contributions:

  • We use the formal analysis method-(CPN) to analyze the security of the KNXnet/IP protocol [9], and combine the model establishment and detection methods of the CPN theory to discover the security flaws of the protocol;

  • The formal modeling tool-(CPN Tools) is used to describe the communication and data transmission process of the security protocol in detail, verify the consistency of its model, add a Dolev-Yao attacker model [10] to the protocol for intrusion testing, verify and analyze the security, and identify the security vulnerabilities of the protocol;

  • A protocol improvement scheme is invoked to address the protocol’s security vulnerabilities and the improved scheme’s effectiveness is checked using an attacker model;

The writing approach of this article is as follows: The first section is mainly the introduction. In Sect. 2, related work is introduced, discussing other scholars’ research on protocol security issues, and the current mainstream formal modeling methods and tools are compared. It is explained why CPN Tools is used for modeling in this article. In Sects. 3 and 4, the original protocol is modeled, analyzed, and evaluated. An adversary model is added to test the security flaws of the original protocol, and security vulnerabilities are found. In Sect. 5, an improved scheme is proposed, and the new scheme is tested, and Analyze the security of the new solution. In Sect. 6, the article is concluded with future prospects. Section 7, The part is a description of the dissertation fund, and thanks to the reviewers and related workers.

2 Related work

With the wide application of the KNXnet/IP system, More and more scholars have conducted indepth research and analysis on the KNXnet/IP protocol. Reference [11] analyzes the security flaws of the protocol, It has been discovered that there are vulnerabilities involving improper storage of encrypted secrets using hard-coded passwords and denial-of-service (DoS) attacks (CVE-2021–37,740). and the author proposes a corresponding improvement scheme, but did not conduct security evaluation and verification of the improved schemes. Reference [12] proposes using IPV6 as a transmission medium for KNXnet/IP systems, which only focused on the feasibility and efficiency of the research objectives but did not consider the security issues that may arise with the introduction of IPV6. For example, IPv6 supports more extended headers and options, making network devices easier to scan and locate, and increasing the possibility of attackers discovering and exploiting vulnerabilities.

Reference [13] proposes a method for calculating risks in different network segments in the IP-based internet environment but did not analyze the security issues in the KNXnet/IP protocol or pro-vide a reliable solution. Reference [14] analyzes the specific interaction process of KNXnet/IP and identifies the deficiencies under three security mechanisms: IPSec, SSL/TLS [15], and VPN, but did not conduct a formal modeling analysis of the protocol interaction process or provide reliable improvement solutions. Reference [16] conducts a detailed formal analysis of the underlying interaction process of the KNXnet/IP protocol and pro-poses a reliable security solution based on cryptographic algorithms [17], but neither performs a modeling analysis of the original protocol nor security testing of the proposed solution.

In conclusion, there is currently no reliable solution to verify and improve the KNXnet/IP protocol, and a formal modeling analysis method for the protocol is lacking. Furthermore, an attacker model is needed to per-form security testing on the original and improved protocol.

This article is based on the CPN theory to perform formal modeling, analysis, and verification of the protocol. By extracting the key parts of the protocol for security testing, we found security vulnerabilities, For ex-ample, replay attacks and tampering attacks initiated by man-in-the-middle attackers. This paper will propose an improvement scheme to address the existing security vulnerabilities of the protocol. To validate the effectiveness of the proposed scheme, a security verification of the new approach is conducted. Finally, the security of the original and improved solutions is compared.

Compared to recent research, the proposed scheme in this paper offers the advantage of formal verification. By employing a new formal model checking method, the security of the protocol is analyzed while ensuring the consistency of the original model. To investigate the security vulnerabilities of the protocol, an attacker model is introduced. Targeted improvement methods are suggested to address the identified security flaws, and subsequent security verification of the new scheme is conducted.

2.1 Tools comparison

This article mainly focuses on the security mechanisms in the protocol, verifies the security of the KNXnet/IP protocol, and identifies security vulnerabilities in the protocol. Therefore, it is assumed that the communication is reliable. Then, formal modeling tools are used to model and analyze the protocol. The current main-stream formal modeling tools include Scyther [18], Tamarin [19], ProVerif [20], and CPN Tools [21].

The Scyther tool can only verify the confidentiality of the protocol, and it is not very effective in verifying other properties such as availability and integrity. In addition, the ability of Scyther in protocol verification is relatively weak, and for complex protocols or protocols that require more sophisticated analysis techniques, it cannot fully cover all security vulnerabilities. Tamarin only supports a limited range of protocol models, for example, it does not support non-deterministic state transitions, complex data structures, and computations, among others. Therefore, some complex protocols may not receive full verification in Tamarin, and the models generated by Tamarin may become very large, requiring a significant amount of memory and computational resources.ProVerif is a highly abstract tool that is typically used to verify small-scale protocols. As the protocol becomes more complex, it may not be able to handle all cases correctly. The verification time of ProVerif is influenced by the size and complexity of the protocol, so verifying large-scale protocols may take a long time.

CPN Tools is a tool for modeling, simulating, and analyzing Colored Petri Nets (CPN). It supports various models, including static and dynamic models, and can be easily modified and extended. It has an intuitive user interface that helps users create, edit, and analyze CPN models. Users can directly edit Petri nets through the graphical interface, or use advanced features to define Petri nets. It supports multiple analysis techniques, including simulation analysis, performance analysis, model checking, and state space analysis, making it con-venient for users to perform comprehensive analyses on models. It enables hierarchical modeling and analysis of complex protocols for verifying security mechanisms. Users can define the necessary data types through the ML language to detect the protocol’s confidentiality, integrity, and availability and identify potential vulnerabilities. However, CPN Tools uses a specialized Petri net drawing language (ML), so users need to have a certain Petri net foundation to use the tool for modeling and analysis. Therefore, the learning curve is steep and may require some time and effort to learn and become proficient with the tool.

Compared to the three automated protocol security verification tools mentioned above, CPN Tools has several advantages in the manual analysis of protocols. Additionally, the high degree of freedom in the CPN modeling process is also one of its strengths. The state space is entirely controlled by the modeler, and different modeling and analysis methods can be implemented for different protocols. This is why CPN Tools is usually more effective than automated protocol verification tools in protocol verification. Therefore, this paper uses the CPN Tools to simulate the protocol.

3 KNXnet/IP protocol modeling

3.1 KNXnet/IP protocol message flow

KNXnet/IP protocol identity authentication is divided into two stages: certificate configuration initialization stage and key set distribution stage. The former is conducted in a secure physical environment, which is not the focus of this article. This stage provides necessary primitives for subsequent key distribution stages.

The Keyset distribution stage: This stage begins to authenticate the devices to be added to the KNXnet/IP system. At this time, the devices have three security primitives: the public key of the CA (that is, the public key of the installed ETS), the public /private key pair in the device itself, and its certificate proving the authenticity of the public key.

The protocol authentication process is as follows Fig. 1:

Fig. 1
figure 1

Authentication in the keySet distribution phase

Protocol message flow:

  1. 1.

    Firstly, The KNXnet/IP client sends an MSG1 message to the server, which contains the client’s random number Nc and the certificate CertC, and the message is signed with the client’s private key SKC.

  2. 2.

    Upon receiving the message, the KNXnet/IP server verifies the signature and client certificate. If both are valid, the identity of the client is considered legal. The server then promptly signs with its own private key, generating a signed MSG3 message to respond to the request message MSG1. The response message includes the random number Nc from the MSG1 message and the server’s Ns. The use of Nc serves to verify the legitimacy of the MSG3 response as originating from a valid server.

  3. 3.

    After receiving the response message MSG3, the client verifies the signature and certificate. If both are valid, the identity of the server has been proven legal, ensuring mutual entity authentication. Then, the client sends a signed key_req message to request the key set from the server. This message contains a new random number N3 and the server’s previous random number Ns. The random number Ns links the key_req message with the MSG3 message to prove the legitimacy of the KNXnet/IP client device.

  4. 4.

    The server responds to the client’s request with a key_resp message, which contains the random number N3 and the key set KS itself. The response message is signed with the server’s private key and encrypted with the KNXnet/IP client’s public key.

  5. 5.

    After receiving the response, the client decrypts it with its own private key to obtain the signed message and then uses the previously obtained server public key to verify the signature to obtain the keyset KS.

3.2 Formal modeling process

To accurately depict the network communication process and reduce the complexity of the model, the protocol model is divided into three layers: top, middle, and bottom. This article utilizes CPN Tools to model the KNXnet/IP protocol from top to bottom. During the modeling process, ellipses represent place, rectangles represent transition, and double rectangles refer to substitution transitions, which describes protocol messages in greater detail. Before modeling, data types that meet the needs of the modeling process are defined using the ML language. CPN Tools color sets expressions are then used to accurately depict the underlying logic of the protocol. The descriptions of the required symbols are shown in Table 1. The key color sets in this article are defined in the following Table 2:

Table 1 Symbols and definitions
Table 2 The model’s color sets the definition

The CPN model represents a pair of communicating entities: a sender and a receiver. Two entities are connected by a network channel-NET, which represents the channel of communication and data transmission. The model captures static features, such as the protocol state, through the distribution of tokens of the place. Dy-namic features, including state changes, are described using rules and token flows that facilitate transitions. Within the context of the CPN modeling, considering the first message MSG1 as an example, the KNXnet/IP protocol can be formally defined using the following nine-tuple:

$$\begin{aligned} KNXnet/IP = (\Sigma , P, T, A, N, C, G, E, I) \end{aligned}$$
  • $$\begin{aligned} Color set \Sigma = colset NONCE = with Nc|Ns|N3; \end{aligned}$$

    colset CertC = STRING;

    Closet KEY=with PKC|SKC|PKS|SKS|KS;

  • Place set P = Nc, Certc, hello, skc, Shello,msg1;

  • Transition set T = config, sign,msg1;

  • Directed arc set A = Nc\(\rightarrow \)config; Certc\(\rightarrow \)config; skc\(\rightarrow \)sign; config\(\rightarrow \)hello;hello\(\rightarrow \)sign;signShello;

    Shello\(\rightarrow \)msg1;msg1\(\rightarrow \)msg1;

  • Node function N = Nc\(\rightarrow \)config: (Nc,config); certc\(\rightarrow \)config: (certc,config);config\(\rightarrow \)hello: (con-fig,hello);skc\(\rightarrow \)sign: (skc,sign);

  • hello\(\rightarrow \)sign: (hello,sign);sign\(\rightarrow \)Shello:(sign,Shello); Shello\(\rightarrow \)msg1:

    (Shello,msg1);msg1\(\rightarrow \)msg1:(msg1,msg1)

  • Alert function G = NULL;

  • Color function C= Nc:NONCE; certc:CertC; SKC:KEY; msg1:MSG1;

  • Initialization function I = Nc:Nc; certc:CertC;

    SKC:KEY;Shello,msg1,msg1:NULL.

Figure 2 depicts the top-level model of the KNXnet/IP protocol, which comprises eight places and three transi-tions. The client sends the first request message MSG1 to the transition NET via the msg1 place, which is then forwarded to the server via the msg2 place. The server verifies the signature and certificate, and if they are valid, responds through the msg3 place by sending the MSG3 response message to the transition NET. Upon receiving the message from the transition NET, the client verifies the signature and certificate. If the message meets the expectations, it confirms the legality of the server’s identity and initiates a key_req request. The server decrypts the signature using the PKC saved during system initialization, responds to the request, and sends the key_resp message to the client. Upon receiving the key_resp message, the client decrypts it using its own private key SKC, verifies the signature using PKS, and obtains the key set KeySet for the client device.

Fig. 2
figure 2

The top-level CPN model of KNXnet/IP protocol

Figure 3 illustrates the communication process of the middle-level model, which includes four transitions and eight places. msg1 and key_req’ indicate the request message sent by the client, while msg4 and key_res’ indicate the response message received by the client from the server. msg2 and key_req indicate the reception of the request message by the server from the client, whereas msg3 and key_res represent the server’s response to the client’s request. MSG1, MSG3, key_req, and key_resp represent the network transmission channels of four specific messages.

Fig. 3
figure 3

Internal CPN model of Substitution transition NET

Figure 4 illustrates the internal model of the KNXnet/IP client substitution transition and provides a detailed overview of the protocol’s internal interaction process. Firstly, the transition config combines Nc and Certc to generate a request message called hello, which is sent to the transition sign. The transition sign uses the client private key SKC to sign the hello message, then generates a MSG1 message and stores it in the Shello and msg1 places. Then send the MSG1 message to the MSG1 channel in the network channel NET through the msg1 place of the client. The transition NET sends the message to the receiver through the msg2 place. The msg4 place receives the MSG3 message sent by the server via the network channel MSG3 in the transition NET, and then the transition Demsg3 verifies the signature through the decryption function DecryptionSK() to obtain PKS and cnn. At this point, the signature information from the server has been verified, and the certs are bound to certs’ through the place certs’, and then compared to the certificate from the sender through the transition comparison. If the certificate meets the expectations, a random number of Ns is sent to the Ns place. The transition ComNc compares Nc’ and Nc, and if they meet the expectations, the transition GETN3 sends an N3 to NSN3. Ns and N3 together form the nn message, which is sent to sign1, and then signed by SKC.

They are combined to form the request message key_req and sent to the receiver via the key_req port place. Finally, after the key_res’ place receives the Key_resp message from the server response, it forwards the received message to the transition DesrySign, Key_resp message is decrypted through the DecryptionSK() decryption function. Meanwhile, the Sign message obtained by verifying the signature in the transition DecrySign is sent to the gsign place, and it is then sent to the transition Decrysign, which is decrypted through public key PKS. The ketset place then obtains the KS through the GetKeySet transition.

Fig. 4
figure 4

Internal cpn model substitution transition KNXnet/IP client

Figure 5 depicts the internal model of the substitution transition KNXnet/IP Server. The transition MSG2 sends the received message MSG1 to the transition Dehello, which verifies the signature using the decryption function DecryptionSK(). The resulting message is sent to the transition hello, which extracts the client certificate Certc, modifies it to Cert’, compares Certc and Cert’, and if they match, generates a random number Nc and sends it to the place nc. The transition nn combines Nc and Ns into a message NN and sends it to the transition Coord_avail. The message CNN is then created by combining the obtained Certs with the message NN, and finally, Signing the CNN with the key SKS to generate a message MSG3, and use MSG3 to respond to the client. The place Key_req’ receives the request message from the client and sends it to the transition Verify. The transition Verify verifies the signature using DecryptionSK() and then sends the resulting message to the transition GetN3 through the place nsn3. The transition Key_resp then retrieves the N3 from GetN3, combines it with KS into a message KN, and sends it to the transition Sign. The transition sign signs message KN with private key SKS of the server and then sends it to the place Sign. The Transition encrySign uses the client public key PKC to encrypt the signed message and then sends the encrypted message Key_resp to place key_res, which responds to the client’s request.

Fig. 5
figure 5

Internal cpn model substitution transition KNXnet/IP server

3.3 Original KNXnet/IP protocol consistency verification

After the original modeling of the protocol is completed, Using the state space tool in CPN Tools to generate a state space report, we can clearly understand the running result of all models from the report. Before conduct-ing the analysis, protocol outcomes are often predicted based on protocol standards. We expect only one dead node and no loops in the model. After analyzing the results of the state space report in Table 3, we can see that the nodes and arcs of the state space match the results of strongly connected nodes and arcs. This indicates that there are no loops in the built model, and the dead node is 1, which means that all requests are executed as expected. The correctness of the initial model is crucial to subsequent protocol modeling research.

Table 3 protocol original model state space report

4 Protocol security assessment model

4.1 Dolev-Yao attacker model

The Dolev-Yao attacker model [22] is a security analysis model that focuses on the security of network protocol. When analyzing network protocol, it assumes the existence of a powerful attacker, the Dolev-Yao attacker, who can influence the entire communication process as an attacker. This attacker has unlimited computing power and resources and can intercept, modify, and replay network messages, allowing them to destroy and attack any transmitted message.

This attack model was originally proposed by Dolev and Yao in 1983 and has become an important foundation for modern security protocol design. The advantage of this method is that it avoids analyzing the complexity of algorithms and can directly explore the security performance of the protocol itself.

The attacker’s abilities include:

  1. 1.

    Intercepting, modifying, and replaying network messages: The Dolev-Yao attacker can intercept net-work messages and modify or inject malicious data to achieve the goal of the attack.

  2. 2.

    Having unlimited computing resources: The Dolev-Yao attacker can use any computer resources to compromise the security of the network protocol.

  3. 3.

    Cracking encryption algorithms: The Dolev-Yao attacker can crack the encryption algorithms used in transmitted data because they have unlimited computing power.

  4. 4.

    Analyzing the integrity of the protocol: The Dolev-Yao attacker can analyze the integrity of the net-work protocol to understand how the protocol operates and use this information to launch attacks.

  5. 5.

    Simulating network environments: The Dolev-Yao attacker can simulate various scenarios and situations in the network environment and conduct attacks and tests in the simulated environment.

The Dolev-Yao attacker model provides a theoretical framework that enables security researchers to predict and evaluate the security of network protocols. It can be used to analyze security vulnerabilities and design defects in network protocols, guiding the improvement and optimization of protocols. Furthermore, the Dolev-Yao attack model is consistent with the layered modeling idea of CPN tools, In line with the research purpose of this paper. In the next section, we will use the attack capability of the attacker model to model and analyze the security of the protocol.

4.2 Modeling based on Dolev-Yao attacker model

According to the Dolev-Yao adversary model, we introduce man-in-the-middle attacks at the network transport layer. As shown in Fig. 6, places and transitions shown in red represent a simulated replay attack. When the protocol transmits data for the first time, place p0 and transition T0 intercept it, and store it in place P1. The msg transition simulates a replay attack by sending the message “hello” to place P3 through transitions p2 and T1. Transition T2 decomposes the received message, and the decomposed data is stored in Q1 and Q2. The SP is used to limit the number of cycles, and P4 stores information that cannot be decrypted from transition T3. The attacker follows strict rules during this process. Next, the attacker sends the attack data to transition T5 for synthesis and stores the modified MSG1 in place MSG1 through transition T6. Finally, the modified MSG1 is sent to the network channel through transition T7. The arc expression marked in purple in the figure and the “Tamper” data message stored in the warehouse simulates a tampering attack, with the attacker launching a tampering and forgery attack through the Tamperattack transition. The blue part of the figure simulates a spoofing attack, including the Shello transition, Scoord_vlaid transition, key_req transition, and key_resp transition.

Fig. 6
figure 6

Identity authentication result

Fig. 7
figure 7

The NET layer CPN model including the attacker

4.3 Original KNXnet/IP protocol security analysis

After adding the Dolev-Yao attacker model to the network layer for CPN modeling, Run the state space report generation tool in CPN Tools, you will see the state space report shown in Table 4. REY-ATK stands for the replay attack, TAR-ATK stands for the tampering attack, and SPF-ATK stands for the spoofing attack. It can be seen that the number of state space nodes and arcs, as well as the number of strongly connected nodes and arcs, are consistent, indicating that there are no loops in the model, which meets the modeling expectations. At the same time, the number of dead nodes changed from 1 to 4, indicating that there are security vulnerabilities in the original protocol.

By writing ML and using the listdeadsymbols() function, it is possible to determine the serial numbers of all dead nodes. The introduction of tampering attacks led to the reset operation of the message from the participant, so, the generation of two dead markings. The other two dead markings are caused by the replay attack, where an attacker steals a legitimate message and fakes it to block a legitimate message from a client or server. The number of spoofing attacks is 1, indicating that the protocol has been completed, the nonce in the original protocol effectively blocks spoofing messages, therefore, there is no spoofing attack in the original protocol, which is in line with the actual situation of the agreement.

Finally, using the NodeDescriptor() function to print out 781 node data indicates that the status is protocol termination status, indicating that the identity verification is over, as shown in Fig. 7.

Table 4 Comparison of Original protocol status space report including attacker model

5 New scheme of KNXnet/IP protocol

5.1 Protocol improvement scheme

After evaluating the security of the original protocol using the attacker model, we discovered that while the original protocol can effectively defend against spoofing attacks [23], it is vulnerable to tampering [24] and replaying attacks [25]. Therefore, we have introduced timestamp [26] and hash methods into the protocol to enhance its security mechanism [27]. In the new scheme, all messages that are sent or responded will be timestamped at any stage of authentication and data transfer, and an upper threshold will be set. Furthermore, when the client and server perform mutual authentication, the hash of both parties will be compared, and The consistency of both hashes will prove the legality of their identity, then subsequent data interaction will proceed.

Through the security evaluation model, we found that the new scheme can effectively resist tampering and replay attacks, and it has integrity, confidentiality, and freshness, meeting the requirements of security proper-ties in cryptography.

Fig. 8
figure 8

Model of the new scheme message flow

As shown in Fig. 8, the improved message flow diagram is as follows:

  1. 1.

    The client first sends an MSG1 message to the server, which contains the client’s random number Nc, hash, timestamp, and CertC, and the request message is signed with the client’s private key SKC.

  2. 2.

    The KNXnet/IP server receives the MSG1 message and verifies the signature and client certificate. meanwhile, It also compares the hash. If the signature, hash, and certificate are all valid, the identity of the client has been proven legal. The server then immediately responds to the MSG1 request message with a signed MSG3. The MSG3 contains the random number Nc and Ns, the server’s hash, and a timestamp.

  3. 3.

    After receiving the valid response message MSG3, the client verifies the signature, hash, and certs to en-sure the legitimacy of the server’s identity. The identity authentication of mutual entities is thus completed. The client can then request the keyset to the server by sending a signed key_req message with a timestamp, and the message includes the nonce N3 and Ns, the Ns links the key_req message with the MSG3 message to prove the legitimacy of the KNXnet/IP client device.

  4. 4.

    The server responds with a key_resp message, which contains a timestamp, the random number N3, and the keyset KS. The message is signed with the server’s private key and encrypted with the KNXnet/IP client’s public key, ensuring confidentiality and authenticity.

  5. 5.

    After receiving the response key_resp message, the client decrypts it with its private key to obtain a signed message with a timestamp. Then, it uses the previously obtained server public key to verify the signature and obtain the keyset KS.

5.2 New scheme model of KNXnet/IP protocol

To address the discovered security vulnerabilities of the protocol, the original protocol has been strengthened with the new scheme, which was verified by CPN modeling.

Figure 9 shows the internal model of the new scheme KNXnet/IP client. Based on the model of the original client, a place Initial time representing the timestamp and a place Hash representing the HASH is added and connected to the transition config to form the initial request packet hello. With the introduction of timestamping, every split or reassembly of a message during transmission adds to both operation and transmission time. To limit the time of operation and transmission of each message, a time threshold is added. Once the time threshold is exceeded, it means that the message is destroyed or lost.

The detailed process is as follows: The detailed process is as follows: the transition sign uses SKC to sign the message hello to form a request message MSG1, including the newly added timestamp and hash, and sends it to the output port place MSG1 through place Shello and transition MSG1, which the receiver receives through the network NET. The places msg4 and key-res’ are used to receive the response message, decompose the message through the transition CNN, and then verify whether the timestamp is timed out and whether the hash is valid. If it is as expected, the cnn will connect the place Timestamp with the transition NSN3 to form a key_req request message. If the message times out, it will be discarded and retransmitted. If the hash is inconsistent, the authentication will fail, and the MSG3 will be discarded. On the contrary, when the client obtains the Key_resp with the keyset KS through the transition GetKeySet, it indicates that the protocol operation has been completed.

Fig. 9
figure 9

Internal CPN model of new scheme subtransition KNXnet/IP client

Figure 10 depicts the modified internal model of the KNXnet/IP server. The received message is first stored in place msg2. Transition ReHello checks whether the time has exceeded the threshold, and then sends the received hash to the transition compare-hash for verification. If the verification fails, it means that the identity of the sender and the MSG1 are illegal, the message is discarded and retransmitted, and the identity is re-verified. If the verification is successful, the result is sent to the transition coord_avail, which combines the place TimeStamp with a timestamp to form a response message cnn, which is signed with SKS and sent to the requester via the output place msg3. When the place key_req’ receives the key_Req with a timestamp, it checks whether the time has expired. If it has not timed out, the operation and running time will be increased through the place TimeStamp. Then, the transition key_resp forms a TKN message with a keyset, the TKN message is signed using SKS by the transition sign and encrypted using PKC by the transition encryptSign. Finally, the Key_Resp is sent to the requester through the output place key_Res.

Fig. 10
figure 10

Internal CPN model of new scheme subtransition KNXnet/IP server

5.3 CPN model validation

CPN model verification provides Branch Time Logic Formula to describe and verify the nature of the system by introducing ASK-CTL, To ensure that the system meets the expected behavior requirements. If it meets the expectation, it will returns true, otherwise, it returns false. We define an ASK-CTL state formula–myASKCTLformula to detect whether the key_res’ position in the NET page is in the normal termination state, that is, the state node is dead or a normal termination node. As shown in Fig. 11, the result returns true, indicating that the verification result is as expected and the model is correct.

Fig. 11
figure 11

ASK-CTL formula and its verification results

5.4 New scheme security assessment model

In the new security evaluation model,timestamp [26] and hash [28] are included in the message delivery process and utilized the same Dolev-Yao attack model to attack the improved scheme.

As shown in Fig. 12, the red-marked part simulates a replay attack, the purple-marked part simulates a tampering attack, and the blue-marked part simulates a spoofing attack. Since the attacker will spend a certain amount of time when tampering with the message, the time spent on the message msg1 delivered to the ReyATK transition after a series of operations in the red part is bound to be different from the time spent on the normal delivery of the message. Thus, Adding timestamps to the original protocol can effectively prevent replay attacks after message tampering.

Fig. 12
figure 12

NET layer improved security assessment model including same attacker

5.5 New scheme protocol security analysis

The safety evaluation of the new scheme model was performed and compared with the original scheme.

Table 5 presents the state space data of the three attack models before and after the improvement. We can find that The increase in the number of nodes and arcs for the three attack models can be attributed to the inclusion of timestamp and hash consistency comparison during data transmission and identity authentication process.

The table data indicates that the number of dead nodes in REY-ATK has been reduced from 2 to 1, indicating that the improved scheme can effectively resist replay attacks. In addition, by writing a query function to query 992 nodes, Fig. 13 shows that this is the termination state of the protocol, which is consistent with the expected result. The DeadMarkings() function is used to determine whether the mark of the specified node is dead, that is, whether the binding element is enabled. If true is returned, it means there are no enabled binding elements and Indicates that each part of the protocol has been run, which is the protocol termination state. The NodeDescriptor() function is used to print the actual status of the node.

Compared to the original protocol,According to the CPN theory to analyze the obtained data. In the tampering attack test, the possibility of a TAR-ATK attack has been significantly reduced from 3.5%Footnote 1of the original protocol model to 1.6%Footnote 2of the new solution model, indicating that the probability of tampering attacks has been greatly reduced. the new scheme can further strength-en the security mechanism of the protocol. The number of dead marks of the SPF-ATK is 1 before and after improvement, indicating that the original security mechanism of the protocol can effectively resist spoofing attacks.

Table 5 The state space report of NET layer including new attacker model
Fig. 13
figure 13

Protocol termination status query under replay attack

In Table 6, Comparison of the overall state space analysis results between the original attacker model and the new scheme. It can be seen that the number of nodes and arcs in the improved state space has significantly increased due to the introduction of timestamp and hash comparison. The total number of dead nodes has decreased from 4 to 2, and the ratio of nodes has decreased from 0.512%Footnote 3 in the original attacker model to 0.078% in the new scheme, resulting in a performance improvement of 0.434% (0.512% - 0.078%). This shows that the improved scheme is effective and can effectively resist most man-in-the-middle attacks.

Table 6 State space comparison between the original and the new scheme security assessment model

6 Summary and outlook

This paper focuses on analyzing the security mechanism in the KNXnet/IP protocol during the identity authentication and message transmission process. The communication protocol interaction process is studied, using the CPN Tools tool to model the interaction process of the protocol in detail. An adversary model is Then introduced to evaluate the security of the KNXnet/IP protocol model. It was found that the KNXnet/IP protocol has Security flaws in replay attacks and tampering attacks. To address these security vulnerabilities, the paper proposes a reinforcement scheme that this paper proposes to add timestamps and hash to the original protocol to improve the original protocol. The effectiveness of the proposed scheme is verified using CPN Tools and the same adversary model. The results show that the new reinforcement scheme effectively prevents the existing security attacks. However, only three attack methods are used in this paper to test the security mechanism of the protocol. Future research should consider other attack methods while enhancing the protocol’s security.