Modbus serial link secure communication method, device and equipment

Abstract

The invention relates to the technical field of link communication, and discloses a Modbus serial link safety communication method, device and equipment, and the method comprises the steps: receiving a first certificate chain of slave station equipment, verifying a slave station brand certificate in the first certificate chain according to a first root certificate, and when the verification result is that the slave station brand certificate in the first certificate chain passes, carrying out the verification of the slave station brand certificate based on the slave station equipment certificate in the first certificate chain; generating a master key and a corresponding encapsulation key ciphertext; sending the encapsulation key ciphertext, the encryption and decryption mode of the master station equipment and the second certificate chain to slave station equipment, so that the slave station equipment verifies the second certificate chain, and decrypts the encapsulation key ciphertext based on a private key of the slave station equipment to obtain a master key; and encrypting the protocol data unit based on the master key, and sending the encrypted protocol data unit to the slave station equipment. A two-way verification mechanism based on a certificate chain is introduced into a Modbus serial link, a security sublayer can be embedded on the premise of not changing an original frame structure and a communication process, the security of the Modbus serial link is improved, and the cost is low.

Description

Modbus serial link secure communication methods, devices and equipment Technical Field

[0001] This application relates to the field of link communication technology, and in particular to a Modbus serial link secure communication method, apparatus and device. Background Technology

[0002] Regarding serial communication, in the presence of hardware side-channel attacks, especially in the case of remote serial or bridging connections, the transmission of Modbus industrial control protocol via serial media can easily lead to data leakage or modification, posing a serious security risk. Summary of the Invention

[0003] The main objective of this application is to provide a secure communication method, apparatus, and device for Modbus serial links, aiming to solve the technical problem that existing Modbus industrial control protocols transmitted via serial media are prone to data leakage or modification, posing serious security risks.

[0004] To achieve the above objectives, this application proposes a Modbus serial link secure communication method applied to a master station device, the method comprising:

[0005] The system receives a first certificate chain sent by a slave device and verifies the slave brand certificate in the first certificate chain based on the first certificate to obtain a verification result. When the verification result is successful, a master key and a corresponding encapsulation key ciphertext are generated based on the slave device certificate in the first certificate chain. The encapsulation key ciphertext, the encryption / decryption mode of the master device, and the second certificate chain are sent to the slave device so that the slave device can verify the second certificate chain. After successful verification, the encapsulation key ciphertext is decrypted based on the private key of the slave device to obtain the master key. A content encryption key and an initial value for a counter are generated based on the master key. The protocol data unit to be sent is encrypted according to the content encryption key and the initial value for the counter, and the encrypted protocol data unit is sent to the slave device.

[0006] Optionally, the step of verifying the slave brand certificate in the first certificate chain based on the first root certificate to obtain a verification result includes: verifying the validity of the first digital signature of the slave brand certificate based on the first root certificate, wherein the first digital signature is generated by the root certificate authority using a post-quantum digital signature private key; after the slave brand certificate passes verification, extracting the post-quantum digital signature public key from the slave brand certificate; and verifying the validity of the second digital signature of the slave device certificate based on the post-quantum digital signature public key to obtain a verification result.

[0007] Optionally, before generating the content encryption key based on the master key, the method further includes: extracting a first device identifier of the slave device from the slave device certificate and reading a second device identifier of the master device from local storage; generating a first authentication key based on the master key, the first device identifier, and the second device identifier; associating the first authentication key with the identity identifier of the slave device and storing it in a local authentication context; and sending the first authentication key in response to an authentication key request sent by the slave device, so that the slave device compares the first authentication key with the second authentication key.

[0008] Optionally, generating the content encryption key based on the master key includes: when the master key is a unicast master key, concatenating the unicast master key and the first device identifier of the slave device to obtain a first key derivation input sequence; inputting the first key derivation input sequence into a cryptographic hash function, and determining the content encryption key and the initial value of the counter corresponding to the unicast master key according to the output first continuous bit sequence; when the master key is a broadcast master key, concatenating the broadcast master key and the second device identifier of the master device to obtain a second key derivation input sequence; inputting the second key derivation input sequence into the cryptographic hash function, and determining the content encryption key and the initial value of the counter corresponding to the broadcast master key according to the output second continuous bit sequence.

[0009] Optionally, after generating a content encryption key based on the master key, encrypting the protocol data unit to be sent according to the content encryption key, and sending the encrypted protocol data unit to the slave device, the method further includes: in response to a communication link establishment event with the slave device, querying the authentication context storage area to see if there is a valid authentication context record associated with the first device identifier of the slave device, the valid authentication context record containing the master key and the first authentication key; if the valid authentication context record exists, generating the content encryption key based on the master key in the valid authentication context record; reading the first authentication key from the valid authentication context record, and sending a fast reconnection request frame containing the first authentication key to the slave device, so that the slave device performs key comparison.

[0010] Furthermore, to achieve the above objectives, this application also proposes a Modbus serial link secure communication method applied to a slave device. The method includes: sending a first certificate chain to a master device, the first certificate chain including a slave brand certificate and a slave device certificate, the slave device certificate containing a post-quantum key encapsulation public key, and the slave device locally including a post-quantum key encapsulation private key corresponding to the post-quantum key encapsulation public key; receiving encapsulation key ciphertext, encryption / decryption mode, and a second certificate chain sent by the master device; verifying the master brand certificate in the second certificate chain based on the second certificate to obtain a second verification result; when the second verification result is successful, decrypting the encapsulation key ciphertext based on the encryption / decryption mode and the post-quantum key encapsulation private key to obtain a master key; generating a content encryption key and an initial counter value based on the master key; receiving encrypted protocol data units sent by the master device, and decrypting the encrypted protocol data units according to the content encryption key and the initial counter value to obtain protocol data units.

[0011] Optionally, before generating the content encryption key and the initial value of the counter based on the master key, the method further includes: extracting the second device identifier of the master station device from the second certificate chain, and generating a second authentication key based on the master key and the second device identifier; sending an authentication key request to the master station device, and receiving the first authentication key returned by the master station device; comparing the first authentication key with the second authentication key to obtain a comparison result.

[0012] Furthermore, to achieve the above objectives, this application also proposes a Modbus serial link secure communication device applied to a master station device. The device includes: a certificate verification module, used to receive a first certificate chain sent by a slave device, and verify the slave brand certificate in the first certificate chain according to the first certificate to obtain a verification result; a ciphertext generation module, used to generate a master key and a corresponding encapsulation key ciphertext based on the slave device certificate in the first certificate chain when the verification result is successful; a key sending module, used to send the encapsulation key ciphertext, the encryption / decryption mode of the master device, and the second certificate chain to the slave device, so that the slave device can verify the second certificate chain, and after successful verification, decrypt the encapsulation key ciphertext based on the private key of the slave device to obtain the master key; and a data encryption module, used to generate a content encryption key and a counter initial value based on the master key, and encrypt the protocol data unit to be sent according to the content encryption key and the counter initial value, and send the encrypted protocol data unit to the slave device.

[0013] Furthermore, to achieve the above objectives, this application also proposes a Modbus serial link secure communication device applied to a slave device. The device includes: a certificate sending module for sending a first certificate chain to a master device, the first certificate chain including a slave brand certificate and a slave device certificate, the slave device certificate containing a post-quantum key encapsulation public key, and the slave device's local storage including a post-quantum key encapsulation private key corresponding to the post-quantum key encapsulation public key; a key receiving module for receiving the encapsulated key ciphertext, encryption / decryption mode, and second certificate chain sent by the master device; a certificate verification module for verifying the master brand certificate in the second certificate chain based on the second certificate to obtain a second verification result; a ciphertext decryption module for decrypting the encapsulated key ciphertext based on the encryption / decryption mode and the post-quantum key encapsulation private key when the second verification result is successful, to obtain a master key; a key generation module for generating a content encryption key and an initial counter value based on the master key; and a data decryption module for receiving encrypted protocol data units sent by the master device and decrypting the encrypted protocol data units according to the content encryption key and the initial counter value to obtain protocol data units.

[0014] In addition, to achieve the above objectives, this application also proposes a Modbus serial link secure communication device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the Modbus serial link secure communication method as described above.

[0015] This application introduces a certificate-chain-based bidirectional verification mechanism into the Modbus serial link. After successful verification, a master key and encapsulated key ciphertext are generated based on the slave device certificate. Then, the content encryption key and the initial value of the counter are derived to encrypt the protocol data unit. Without changing the original frame structure and communication process, a security sublayer is embedded, which significantly improves its security and has a low cost. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 is a flowchart illustrating the first embodiment of the Modbus serial link secure communication method applied to a master station device according to this application; Figure 2 is a structural diagram illustrating the trust model according to this application; Figure 3 is a structural diagram illustrating the certificate holder ID according to this application; Figure 4 is a schematic diagram illustrating the encrypted encapsulation of the Modbus secure RUT message according to this application; Figure 5 is a flowchart illustrating the authentication and key negotiation message exchange based on post-quantum certificates according to this application; Figure 6 is a flowchart illustrating the second embodiment of the Modbus serial link secure communication method applied to a master station device according to this application; Figure 7 is a flowchart illustrating the first embodiment of the Modbus serial link secure communication method applied to a slave station device according to this application; Figure 8 is a flowchart illustrating the calculation process of the authentication process based on post-quantum certificates according to this application; Figure 9 is a schematic diagram illustrating the module structure of the Modbus serial link secure communication device applied to a master station device according to an embodiment of this application; Figure 10 is a schematic diagram illustrating the module structure of the Modbus serial link secure communication device applied to a slave station device according to an embodiment of this application; Figure 11 is a schematic diagram illustrating the device structure of the hardware operating environment involved in the Modbus serial link secure communication method according to an embodiment of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] This application provides a Modbus serial link security protocol based on post-quantum hybrid signature public key certificates. The main idea is to achieve secure data transmission and protection by adding a closely related security sub-protocol on the basis of the original Modbus protocol. This added protocol needs to be adapted to low power consumption and low transmission rate conditions, and while enhancing security, it ensures a small amount of additional security overhead and low cost.

[0023] Based on this, this application provides a Modbus serial link secure communication method applied to a master station device. Referring to Figure 1, Figure 1 is a flowchart illustrating the first embodiment of the Modbus serial link secure communication method applied to a master station device according to this application.

[0024] In this embodiment, the method includes: step S10, receiving a first certificate chain sent by a slave device, and verifying the slave brand certificate in the first certificate chain according to the first certificate to obtain a verification result.

[0025] It should be noted that the master station device refers to the control unit in the industrial control network that has scheduling, monitoring, and data acquisition functions, such as a programmable logic controller, remote terminal unit, industrial gateway, or industrial control host computer. It establishes a Modbus serial link connection with one or more slave devices through a serial communication interface. The first certificate chain is a set of digital credentials submitted by the slave device to the master station device to prove its identity and legitimacy. It usually contains two levels of public key certificates: the slave brand certificate and the slave device certificate. The slave brand certificate is issued by the root certificate authority and is used to prove the legitimacy of the brand identity of the manufacturer to which the slave device belongs. The first root certificate is a trust anchor point pre-installed locally on the master station device to verify the starting point of the certificate chain. Its corresponding private key is strictly protected by the root certificate authority.

[0026] Understandably, the slave brand certificate and slave device certificate in the first certificate chain follow the X.509 standard format extension. The slave device certificate embeds a unique identifier for the slave device and a post-quantum key encapsulation public key, such as an ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) public key; the slave brand certificate embeds a post-quantum digital signature public key, such as an ML-DSA (Module-Lattice-Based Digital Signature Standard) public key. Upon receiving the first certificate chain, the master device performs a step-by-step verification of the certificate chain based on the first certificate stored locally, to confirm the authenticity of the slave device's identity, the integrity of the certificate issuance chain, and whether the certificate itself is valid and has not been revoked.

[0027] Specifically, as an optional implementation, when the master station device receives the first certificate chain, it first parses the application protocol data unit in the Modbus serial link message frame and extracts the slave brand certificate and slave device certificate encapsulated in the ss_data_req message from the data unit. The master station device calls the local hardware security engine or cryptographic algorithm library to load the pre-set first root certificate and extracts the public key information of the root certificate authority from the first certificate; subsequently, it verifies the digital signature field of the slave brand certificate based on the root public key. If the digital signature of the slave brand certificate is verified to be consistent with the signature behavior of the root certificate private key, and the extended fields such as certificate validity period and key usage conform to the preset policy, then the slave brand certificate is determined to have passed verification.

[0028] In another optional implementation, the transmission of the first certificate chain can employ a fragmentation mechanism to accommodate the maximum 252-byte data field length constraint of Modbus RTU (Remote Terminal Unit) frames. When the encoded length of the slave brand certificate or slave device certificate exceeds the single-frame carrying capacity, the slave device splits the certificate into multiple consecutive Modbus message frames and sends them sequentially, setting the same session identifier and fragment sequence number in the application layer protocol header of each frame. The master device caches the received certificate fragments according to the session identifier, and after all fragments have been received, it performs fragment reassembly to restore the complete encoded certificate object, and then initiates the certificate chain verification process.

[0029] Optionally, the verification of slave brand certificates by the master station device includes not only digital signature validity checks, but also certificate issuer identity matching checks, certificate revocation status checks, and certificate policy extension consistency checks. The master station device can have a pre-configured certificate revocation list or support an online certificate status protocol, and actively query the current revocation status of the slave brand certificate during the verification process. If the certificate has been revoked or its issuer is not in the master station device's trusted certificate authority list, the verification result is directly determined as unsuccessful, and the current security session establishment process is terminated. Optionally, an audit log is recorded or an authentication failure alarm is reported to the operations and maintenance system.

[0030] Understandably, if the first certificate chain sent by the slave device is missing the slave brand certificate or slave device certificate, or if certificate format parsing fails, the digital signature algorithm is not supported by the master device, the certificate has expired, or the certificate chain is incomplete and cannot be traced back to the first certificate, the master device will determine the current verification result as unsuccessful. In this case, the master device can choose to fall back to the traditional unencrypted Modbus communication mode, directly disconnect, or return an authentication rejection message with a specific error code to the slave device. The specific behavior depends on the local security policy configuration of the master device.

[0031] In this embodiment, the key management in the Modbus serial link security protocol based on post-quantum hybrid signature PKI (Public Key Infrastructure) public key certificates is suitable for future use in high-value, high-security factory equipment environments, allowing for a smooth transition with existing standards. It is divided into three layers: certificate storage layer, authentication and key negotiation layer, and content encryption / decryption layer. For the master and slave devices, MK_DK and MK_PRIK are the primary private keys for both. MK_DK is mainly used for key encapsulation, while MK_PRIK is the primary private key for the signing process and must be guaranteed not to be modified or spied on by third parties. It is recommended to use a mature TEE (trusted execution environment).

[0032] The keys at the certificate storage layer mainly include ECC (Error Correcting Code) and post-quantum algorithm public cryptography protocol parameters, the private keys of the master client and slave server, and the public key certificate chain. The public key certificate chain includes the root certificate, vendor certificate, and device certificate. The device certificate includes the device ID, ECC public key, post-quantum algorithm public key, and other certificate attribute information. The key data at this layer is mainly used to execute the authentication protocol. After device initialization, the certificate must not be changed or replaced. It is recommended to use mature fuse- or antifuse-based memory, one-time programmable non-volatile memory, where data cannot be irreversibly modified after being written. The methods for protecting this data are not emphasized in this embodiment.

[0033] In practical implementation, a standardized post-quantum digital signature algorithm can be embedded into the traditional PKI system, enabling the certificate verification process to possess dual security guarantees from both traditional cryptography and post-quantum cryptography. Even if the traditional signature algorithm is cracked in a quantum computing environment, attackers still cannot forge device certificates signed with post-quantum private keys. In this case, step S10 may include: verifying the validity of the first digital signature of the slave brand certificate based on the first root certificate, wherein the first digital signature is generated by the root certificate authority using a post-quantum digital signature private key; after the slave brand certificate passes verification, extracting the post-quantum digital signature public key from the slave brand certificate; and verifying the validity of the second digital signature of the slave device certificate based on the post-quantum digital signature public key to obtain the verification result.

[0034] It's important to note that the slave device certificate is a three-tiered certificate issued by the brand certificate holder (i.e., the device manufacturer) using the post-quantum digital signature private key corresponding to their brand certificate. This certificate proves the identity of the specific slave device and carries its post-quantum key encapsulated public key. The first digital signature is the digital signature field appended to the slave brand certificate, calculated by the root certificate authority using its ML-DSA private key on the certificate body information (including certificate holder name, public key, validity period, extensions, etc.). The second digital signature is the digital signature field appended to the slave device certificate, calculated by the device manufacturer using the ML-DSA private key corresponding to their brand certificate on the device certificate body information. The master device verifies the authenticity of the digital signatures at each level of the certificate, thereby ensuring the trustworthiness of the slave device certificate and the ownership of its public key.

[0035] Specifically, as an optional implementation, after obtaining the complete slave brand certificate and slave device certificate, the master station device first calls the post-quantum signature verification interface in its local cryptographic algorithm library. The master station device extracts the ML-DSA public key of the root certificate authority from the pre-set first root certificate and uses this public key, the subject information of the slave brand certificate, and the first digital signature at the end of the certificate as input parameters to execute the ML-DSA signature verification algorithm. If the verification algorithm outputs "valid," it indicates that the slave brand certificate was indeed issued by a trusted root certificate authority, and the certificate content has not been tampered with during transmission; if the verification outputs "invalid," the master station device immediately terminates the verification process and determines the current verification result as unsuccessful, while optionally recording the system log.

[0036] In another optional implementation, after verifying the slave device's brand certificate, the master device parses the device manufacturer's post-quantum digital signature public key (i.e., ML-DSA public key) from the certificate's extended fields or main public key information field. This public key is encoded using the SubjectPublicKeyInfo structure, where the algorithm identifier is explicitly specified as id-ML-DSA-44 (or other NIST security level parameters). The master device then extracts the main information of the slave device certificate and its second digital signature at the end, using the parsed manufacturer's ML-DSA public key as the verification key, and calls the post-quantum signature verification interface again. If the verification passes, the master device is certain that the current slave device certificate was legally issued by the device manufacturer corresponding to the brand certificate, and that the post-quantum key encapsulated public key embedded in the slave device certificate truly belongs to the slave device. The master device then marks the verification result as "passed" and proceeds to the subsequent key generation process.

[0037] In one example, referring to Figure 2, which is a schematic diagram of the trust model of this application, the trust model structure based on post-quantum hybrid signature PKI public key certificates is the same as the tree structure of the traditional ECC PKI method. The authentication process of the master station client and the slave station server begins with the exchange of their respective certificate chains rooted in ROT. The difference is that ROT will have two independent certificates generated by ECC algorithm and post-quantum algorithm respectively. The top layer is the ROT root, under which are brand certificates, including brand A, brand B, and operators (factories), etc. Each brand certificate corresponds to a device certificate. For example, under brand A, master station device 1 and master station device 2 are deployed, and under brand B, slave station device 1 and slave station device 2 are deployed. The master and slave station devices under each brand can communicate and interact through Modbus serial links. The operator (factory) is directly associated with ROT as an independent level.

[0038] The brand certificate contains the signature public keys required for ECC algorithms such as SM2 and post-quantum signature algorithms such as ML-DSA. This means it contains two public keys, which can be stored concatenated in the `SubjectPublicKeyInfo` field, with the `AlgorithmIdentifier` defined as `SM2-with-SM3+ML-DSA`. Alternatively, they can be stored separately in the `SubjectPublicKeyInfo` field and the `Extensions` field. The extension fields contain `Key Usage: Digital Signature`, `id-oqs-public-key: ML-DSA Public Key`, and `id-oqs-algorithm: ML-DSA`. Furthermore, the brand certificate also contains the corresponding signatures generated from the two ROT certificates, combined in a single signature format in the certificate's `Signature` field (i.e., containing two signatures). The specific storage format is not mandatory in this embodiment.

[0039] The device certificate contains the public key required for the ECC algorithm and the public key required for post-quantum key encapsulation algorithms such as ML-KEM, as well as signatures generated by the corresponding brand certificate using the private keys of the ECC and ML-DSA algorithms, which are combined in a single combined signature format in the Signature field of the certificate (i.e., the first digital signature and the second digital signature). The specific storage format is not mandatory in this document.

[0040] Optionally, when verifying the second digital signature of the slave device's certificate, the master device further checks whether the certificate type field (certificate_type) in the slave device certificate is 0x03 (device certificate), and whether the encoding format of the certificate holder identifier conforms to the three-level structure specification of "brand identifier-device model identifier-device serial number" shown in the figure. If the certificate type does not match or the holder identifier format is abnormal, even if the digital signature verification passes, the master device can still determine that the certificate is invalid based on the local security policy to prevent attackers from bypassing identity verification by using a certificate with a compliant format but abnormal semantics. In addition, the master device can simultaneously support a hybrid verification mode in which traditional ECC signature and post-quantum signature coexist, and detect the existence of the id-oqs-algorithm identifier in the certificate extension field; if it exists, the post-quantum signature verification process is executed first, and the process only falls back to traditional signature verification when the post-quantum signature verification resource is unavailable.

[0041] Understandably, if the first digital signature verification of the slave brand certificate fails, or if the slave brand certificate passes verification but its embedded post-quantum digital signature public key format is incorrect or the algorithm is not supported, or if the second digital signature verification of the slave device certificate fails, the master device will determine the verification result as unsuccessful. In this case, the master device can choose to refuse to establish a secure session with the current slave device, disconnect the physical connection, or fall back to the traditional unencrypted Modbus communication mode and issue an alarm, according to the preset communication security policy. For abnormal situations such as incomplete certificate chains (e.g., missing slave brand certificate), expired certificate, or revoked certificate, the master device will also determine the verification result as unsuccessful and return an authentication failure message with a specific error reason code to the slave device. The error code can be mapped to the value range of the reserved status field (status_field).

[0042] In one example, referring to Figure 3, which is a schematic diagram of the structure of the certificate holder ID in this application. To support different revocation granularity requirements in the future, when the certificate type is "device certificate", the holder_ID field needs to be further defined as follows: 1. Define the high 16 bits of the "holder_ID" field (64 bits) as "brand identifier"; 2. Define the low 32 bits of the "holder_ID" field (64 bits) as "device serial number"; 3. Define the middle 16 bits of the "holder_ID" field (64 bits) as "device model identifier".

[0043] In addition, in this embodiment, when the certificate type is a device certificate, the values ​​of the brand identifier and the model identifier cannot be zero; while the brand identifier and the model identifier in the ID of other types of certificates are all zero.

[0044] Step S20: When the verification result is passed, a master key and the corresponding encapsulation key ciphertext are generated based on the slave device certificate in the first certificate chain.

[0045] It should be noted that the master key is the symmetric key root material generated by the master station device through the execution of the key encapsulation algorithm. Its bit length is 256 bits, and it is used for subsequent derived content encryption keys, counter initial values, and authentication keys. It can include unicast master keys and broadcast master keys. The encapsulated key ciphertext refers to the ciphertext data output by the master station device when executing the key encapsulation algorithm, which corresponds one-to-one with the master key. This ciphertext can only be recovered by the slave station device holding the corresponding post-quantum key encapsulation private key through the decapsulation operation to recover the same master key.

[0046] Understandably, after the master device confirms the slave device's certificate verification, it parses the slave device's ML-KEM public key from the certificate's extended fields or the subject public key information field. This public key follows the SubjectPublicKeyInfo structure, and the algorithm identifier field can take the value id-ML-KEM-768 (or other security level parameters). The public key material length is 1184 × 8 bits. The master device calls the post-quantum key encapsulation interface in its local hardware security engine or cryptographic algorithm library, using the parsed ML-KEM public key as input, and executes the ML-KEM.Encaps encapsulation primitive. Internally, the encapsulation primitive calls a quantum-resistant random number generator conforming to the NIST FIPS.203 standard to generate a 256-bit symmetric key material as the master key, and simultaneously generates an 8704-bit encapsulation ciphertext corresponding to this master key. This encapsulation ciphertext is constructed in KEM_C (unicast) or KEM_BC (broadcast) format and temporarily stored in the master device's session buffer for subsequent transmission.

[0047] Specifically, as an optional implementation, when generating the master key required for unicast communication, the master device extracts the ML-KEM public key from the verified slave device certificate and performs an encapsulation operation by calling the ML-KEM.Encaps algorithm. The output of this encapsulation operation consists of two parts: the first part is a 256-bit master key (KEMSK), used for point-to-point encrypted communication between the current master device and the specific slave device; the second part is an 8704-bit first encapsulation key ciphertext (KEM_C). The master device associates the generated master key with the slave device's first device identifier in the session context and marks the key's lifecycle status as "pending confirmation" until the slave device completes subsequent authentication key comparison and confirmation.

[0048] In another optional implementation, when generating the master key required for broadcast communication, the master station device also uses the ML-KEM public key from the slave device certificate, but independently performs another ML-KEM.Encaps encapsulation operation. This encapsulation operation generates a 256-bit broadcast master key (KEMSK_B) and an 8704-bit second encapsulation key ciphertext (KEM_BC). The broadcast master key is used to encrypt broadcast messages between the master station device and multiple slave devices. All slave devices that have been bound to the master station should be able to decapsulate KEM_BC based on their respective ML-KEM private keys and recover the same broadcast master key. The master station device stores the broadcast master key associated with its own second device identifier and reuses this key to establish broadcast encryption channels with multiple slave devices, without needing to generate broadcast key material independently for each slave device.

[0049] It should be understood that during the process of generating the master key and encapsulating the key ciphertext, the output bit sequence of the random number generator of the master station equipment should have sufficient entropy density and unpredictability to meet the strict security requirements of the post-quantum key encapsulation algorithm for random input.

[0050] Step S30: Send the encapsulated key ciphertext, the encryption / decryption mode of the master device, and the second certificate chain to the slave device so that the slave device can verify the second certificate chain. After successful verification, the slave device decrypts the encapsulated key ciphertext based on its private key to obtain the master key.

[0051] It should be noted that the encryption / decryption mode of the master device refers to the identifier of the symmetric cryptographic algorithm supported by the master device for subsequent content encryption. For example, 0x04 indicates support for the Zu Chongzhi Stream Cipher (ZUC), 0x01 indicates support for the AES-GCM algorithm, and 0x02 indicates support for the SM4-GCM algorithm. The mode information is encoded through an 8-bit mode field and declared in the encryption_capability field of the certificate. The second certificate chain is a set of digital credentials submitted by the master device to the slave device to prove its identity and legitimacy. It includes the master device brand certificate and the master device certificate, and its format is symmetrical to the first certificate chain. The master device certificate contains the master device's post-quantum key encapsulated public key, and the master device brand certificate contains the master device manufacturer's post-quantum digital signature public key.

[0052] Understandably, the master device's second certificate chain is encapsulated in a response protocol data unit and sent to the slave device via a Modbus serial link. The APDU (Application Protocol Data Unit) of the response protocol data unit is of type ss_data_cnf. Its syntax includes the send_datatype_nbr field (with a value of 5, indicating that this transmission contains 5 data type items), and five data fields arranged in sequence: KEM_C (datatype_id=26), KEM_BC (datatype_id=27), mode (datatype_id=24), Client_Dev_Cert (datatype_id=10), and Client_Brand_Cert (datatype_id=3). When assembling the APDU, the master device strictly follows the above field order and adds a corresponding datatype_len subfield before each field to indicate the actual bit length of that field, facilitating boundary alignment and buffer pre-allocation during slave device parsing.

[0053] It should be understood that in the second certificate chain sent by the master station device, both the master station brand certificate and the master station device certificate adopt the X.509 standard format and follow the same post-quantum hybrid signature extension specification as the first certificate chain. The SubjectPublicKeyInfo field of the master station brand certificate contains the ML-DSA public key of the master station device manufacturer, and its extended field optionally carries the id-oqs-public-key identifier; the SubjectPublicKeyInfo field of the master station device certificate contains the ML-KEM public key local to the master station device, which, together with the ML-KEM private key held in the master station device's local secure storage area, forms an asymmetric key pair. When assembling the second certificate chain, the master station device should ensure that the issuing chain relationship between the brand certificate and the device certificate is correct, that is, the issuer name (issuer_ID) of the master station device certificate must be completely consistent with the holder name (holder_ID) of the master station brand certificate, and the issuer of the master station brand certificate must be the same certificate authority trusted by the master station device.

[0054] Understandably, the slave device can authenticate the master device based on the received second certificate chain and decapsulate the ciphertext using its own post-quantum key encapsulation private key, thereby recovering a master key completely identical to that of the master device. To achieve this, the master device implicitly conveys the following security contract to the slave device when sending the response APDU: First, the slave device should use its locally pre-installed second root certificate as the trust anchor to verify the first digital signature of the master device's brand certificate and the second digital signature of the master device's certificate; Second, the slave device should use its post-quantum key encapsulation private key (MK_DK) corresponding to its certificate to perform the ML-KEM.Decaps decapsulation algorithm on KEM_C to obtain a 256-bit unicast master key; Third, if the response APDU also contains a KEM_BC field, the slave device should decapsulate the ciphertext using the same private key to obtain the broadcast master key.

[0055] Step S40: Generate a content encryption key and an initial value for a counter based on the master key, encrypt the protocol data unit to be sent according to the content encryption key and the initial value for the counter, and send the encrypted protocol data unit to the slave device.

[0056] It should be noted that the content encryption key is a symmetric key material generated by a key derivation function based on a shared master key between the master and slave devices. It is used to protect the confidentiality of the function code field and data field in the Modbus protocol data unit. The content encryption key has a bit length of 128 bits, compatible with the key input specifications of symmetric encryption algorithms such as Zu Chongzhi stream cipher, AES-GCM, or SM4-GCM. The counter initial value is a 128-bit initialization vector derived in pair with the content encryption key. It is used to assign the initial state of the counter in stream cipher encryption algorithms or as the initial vector input in block cipher algorithms. The core function of the counter initial value is to break encryption determinism, ensuring that the same plaintext encrypted with the same master key outputs different ciphertexts, effectively resisting replay attacks and traffic analysis attacks. The protocol data unit to be sent refers to the original Modbus application layer protocol data unit to be sent by the master device. It is composed of a function code field (1 byte) and a data field (0 to 252 bytes) concatenated sequentially, excluding address fields, checksums, and other serial link transmission auxiliary fields.

[0057] In one example, referring to Figure 4, which is a schematic diagram of the encrypted encapsulation of the Modbus secure RTU message of this application, the original Modbus RTU message consists of a 1-byte address, a 1-byte function code, 0-252 bytes of data, and a 2-byte (low byte first, high byte last) CRC checksum. The secure Modbus RTU message is a security extension based on the original message. Its address field is still 1 byte, the function code field is fixed at 0, and a new protocol data segment is added. This protocol data segment contains a fixed 20-byte header parameter (including s_src_addr, s_dst_addr, s_len, NAC, etc.) and the original function code and data encapsulated within it (length 0-231 bytes). Finally, it is still terminated with a 2-byte (low byte first, high byte last) CRC checksum. This encapsulation method realizes the security enhancement of Modbus serial link communication.

[0058] It should be understood that when sending, APDU messages are encapsulated into Modbus serial link data unit fields with function number 0. For APDUs larger than 252 bytes (the maximum data field length of a Modbus RTU frame), they can be sent in two Modbus serial link message frames. Since the sending operation is strictly serial and has a sequence, the upper-layer application can concatenate two or more segmented APDUs according to the protocol tag (ss_data_send_tag) and length_field() fields.

[0059] Understandably, when the master device receives the authentication confirmation information (i.e., a successful authentication key comparison message) from the slave device, it confirms that a secure association has been established with the slave device. At this point, the master device already holds the master key (KEMSK) and the slave device's first device identifier (SERVER_ID) in its session context. The master device calls a local cryptographic hash function (such as the SM3 algorithm, outputting 256 bits) to construct the first key derivation input sequence: the master key and the slave device's first device identifier are concatenated byte-wise, with the concatenation order agreed to be the master key's high address first and the device identifier's low address last, forming a total input sequence of 320 bits. This input sequence is then input into the SM3 hash function to obtain a 256-bit hash output value. The master device takes the high 128 bits of this hash output value as the content encryption key (CK) and the low 128 bits as the counter initial value (CIV). This derivation method ensures that the content encryption key and the counter initial value are strongly bound to the device identity of the communication peer, so that different slave devices will derive different session key materials even if they share the same master key.

[0060] Specifically, after the master station device completes the derivation of the content encryption key and the initial value of the counter, it enters the protocol data unit encryption stage. The master station device obtains the original Modbus protocol data unit to be sent from the industrial control application layer. This data unit consists of a 1-byte function code and an N-byte data field (0≤N≤252, constrained by the maximum length of the Modbus RTU frame data field). The master station device concatenates the function code field and the data field sequentially to form a plaintext message stream with a length of N+1 bytes. If the length of the plaintext message stream is not an integer multiple of 128 bits (16 bytes), the master station device fills the end with 0x00 bits according to the padding rules agreed upon in this protocol until the total bit length is an integer multiple of 128 bits; the padded message stream is denoted as M, and its bit length is denoted as MPLEN.

[0061] Understandably, the master device selects the corresponding encryption algorithm based on the determined encryption / decryption mode field (mode) to perform the encryption operation. For the decryption process on the slave device side, as a symmetrical reverse operation, after receiving the encrypted Modbus message frame, the slave device reassembles the APDU using the same session identifier and fragmentation mechanism. The slave device extracts the MAC and encrypted data stream from the reassembled ss_data_send structure, and based on the content encryption key CK and the initial counter value CIV derived and stored in the session context, calls the same decryption algorithm as the master device to perform the decryption operation, recovering the padded plaintext message stream. The slave device removes the padding bits according to the Modbus protocol specification, restoring the 1-byte function code and N-byte data field, and submits this original protocol data unit to the upper-layer industrial control application for processing.

[0062] In practical implementation, a lightweight symmetric authentication credential can be established outside the complete public key certificate authentication process. This allows the master and slave devices to quickly verify their identities in subsequent communication sessions based on the authentication key after the initial binding, ensuring the legitimacy of the master client. Before step S40, the process may include: extracting the first device identifier of the slave device from the slave device certificate and reading the second device identifier of the master device from local storage; generating a first authentication key based on the master key, the first device identifier, and the second device identifier; associating the first authentication key with the identity identifier of the slave device and storing it in the local authentication context; and sending the first authentication key in response to an authentication key request sent by the slave device, so that the slave device can compare the first authentication key with the second authentication key.

[0063] It should be noted that the first device identifier is a 64-bit unique identification code carried in the holder_ID field of the slave device certificate. Its encoding structure follows a three-level specification of "brand identifier - device model identifier - device serial number". The high 16 bits are the brand identifier of the slave device manufacturer, the middle 16 bits are the device model identifier, and the low 32 bits are the factory serial number of the slave device. The first device identifier is written by the device manufacturer when the slave device certificate is issued and is solidified by the brand certificate signature, possessing global uniqueness and anti-counterfeiting properties. The second device identifier is a 64-bit unique identification code carried in the holder_ID field of the master device certificate. Its encoding rules are the same as the first device identifier, and it is used to uniquely identify the identity of the master device.

[0064] It is understandable that the first authentication key refers to the 256-bit symmetric key material generated by the master station device based on the shared master key and the device identifiers of both parties after the master station device completes the initial two-way authentication and master key negotiation based on the post-quantum certificate with the slave station device. This key is used to prove the legitimacy of its identity to the slave station device during the subsequent fast reconnection phase. The second authentication key refers to the symmetric key material independently generated by the slave station device based on the same master key and the device identifiers of both parties, with the same value as the first authentication key. The authentication context refers to the data object maintained in the local non-volatile storage area of ​​the master station device, used to record the security association information of the bound slave station devices. Its core content includes at least the slave station device's first device identifier, shared master key, first authentication key, and the negotiated encryption / decryption mode.

[0065] Specifically, after successfully generating the master key (KEMSK) and obtaining the first device identifier (SERVER_ID) from the slave device's certificate, the master device immediately initiates the authentication key derivation process. The master device reads the second device identifier (CLIENT_ID) carried by its own device certificate from its local non-volatile secure storage area. The master device constructs the authentication key derivation input sequence: following the concatenation order agreed upon in this protocol, the master key (256 bits), the first device identifier (64 bits), and the second device identifier (64 bits) are concatenated sequentially to form a total 384-bit input data block. This input data block is then input into a cryptographic hash function, and the complete 256-bit hash output value is determined as the first authentication key (AKH), ​​which is temporarily stored in the current session context.

[0066] It should be understood that after successfully verifying the master device's certificate chain, decapsulating the KEM_C to recover the master key, and deriving the second authentication key (AKM), the slave device proactively sends an ss_data_req APDU to the master device, with its request_datatype_nbr field set to 1 and its datatype_id field set to 17 (AKH), ​​requesting the master device to provide the first authentication key for the current session. Upon receiving this authentication key request frame, the master device parses the slave device's identity information from the request APDU, determines the first device identifier corresponding to the current communication peer, and sends it to the slave device.

[0067] In the specific implementation, the master station device and multiple slave devices can share the same broadcast master key. Each slave device derives the same broadcast content encryption key based on the master station identifier, ensuring that broadcast messages can be correctly decrypted by all slaves. Meanwhile, the key derivation for unicast communication introduces the peer slave identifier, naturally isolating the session keys between different slaves and the master station. This satisfies the differentiated security requirements of broadcast delivery and point-to-point control in industrial control without increasing additional key negotiation overhead. The step of generating the content encryption key and the initial value of the counter based on the master key includes: when the master key is a unicast master key, concatenating the unicast master key and the first device identifier of the slave device to obtain a first key derivation input sequence; inputting the first key derivation input sequence into a cryptographic hash function, and determining the content encryption key and the initial value of the counter corresponding to the unicast master key according to the first consecutive bit sequence output; when the master key is a broadcast master key, concatenating the broadcast master key and the second device identifier of the master device to obtain a second key derivation input sequence; inputting the second key derivation input sequence into the cryptographic hash function, and determining the content encryption key and the initial value of the counter corresponding to the broadcast master key according to the second consecutive bit sequence output.

[0068] It should be noted that the unicast master key is the first symmetric key root material KEMSK generated by the master device based on the post-quantum key encapsulation public key within the slave device's certificate and by executing the ML-KEM.Encaps algorithm. This key is used only for point-to-point encrypted communication between the master device and a specific slave device, and its lifecycle is bound to the secure session and is not shared between different slave devices. The broadcast master key refers to the second symmetric key root material KEMSK_B independently generated by the master device in the same encapsulation operation. This key is used for encryption protection when the master device simultaneously sends broadcast messages to multiple slave devices. All slave devices that have completed their initial binding with the master device must decapsulate the KEM_BC ciphertext based on their respective ML-KEM private keys and recover the exact same broadcast master key.

[0069] It should be noted that the first device identifier, SERVER_ID, is a 64-bit unique identifier extracted from the holder_ID field of the slave device certificate, and the second device identifier, CLIENT_ID, is a 64-bit unique identifier extracted from the holder_ID field of the master device certificate. The key derivation input sequence refers to the binary data block used to input the cryptographic hash function, formed by concatenating the master key and device identifier according to the byte order agreed upon in this protocol. The content encryption key refers to the high 128-bit continuous sequence truncated from the hash output value, and the counter initial value refers to the low 128-bit continuous sequence truncated from the same hash output value.

[0070] Understandably, after successfully receiving the authentication confirmation information returned by the slave device and confirming the establishment of the security association, the master station device immediately enters the key derivation phase. The master station device first determines the type of the communication channel to be established: if the destination address of the Modbus message to be sent is a unicast address (i.e., neither 0x00 nor a broadcast address), then the communication will use a unicast master key derivation path; if the destination address is a broadcast address (0x00), then the communication will use a broadcast master key derivation path. Based on the determination result, the master station device extracts the corresponding master key and device identifier from the session context and strictly follows the following two mutually isolated derivation paths to generate key materials.

[0071] Specifically, as an optional implementation, when the master station device determines that the current communication is a unicast scenario, the master station device reads the unicast master key KEMSK (256 bits) and the slave device's first device identifier SERVER_ID (64 bits) from the current session context. Following the concatenation order of "master key first, identifier last" as specified in this protocol, the master station device prioritizes the high-address bytes of KEMSK, followed by the low-address bytes of SERVER_ID, forming a total of 320 bits of the first key derivation input sequence. The master station device calls its local cryptographic hash engine, inputs the first key derivation input sequence into the SM3 algorithm, and obtains a 256-bit first hash output value after 64 rounds of iterative compression. The master station device counts downwards from the highest bit (255 bits) of this hash output value, extracting the high 128 bits as the unicast content encryption key (CK) and the low 128 bits as the unicast counter initial value (CIV). The master station device writes CK and CIV into the encrypted channel control block of the current session context.

[0072] When the master station determines that the current communication is a broadcast scenario, it reads the broadcast master key KEMSK_B (256 bits) and its own second device identifier CLIENT_ID (64 bits) from the broadcast session context. The master station concatenates the broadcast master key and the second device identifier in the same concatenated order (master key first, identifier last) to form a 320-bit second key derivation input sequence. This sequence is then input into the SM3 hash function to obtain a 256-bit second hash output value. The master station takes the high 128 bits of this hash output value as the broadcast content encryption key (BCK) and the low 128 bits as the initial value of the broadcast counter (BCIV). The master station stores the BCK and BCIV in the broadcast session context. This context is not associated with any specific slave device but is shared by all bound slave devices as a globally unique broadcast encryption channel control block for the master station.

[0073] In one example, referring to Figure 5, which is a flowchart illustrating the authentication and key negotiation message exchange process based on post-quantum certificates in this application, the authentication process between the master client and the slave server begins with the exchange of their respective certificate chains rooted at ROT. The master client must verify the slave server's certificate chain, and similarly, the slave server must verify the master client's certificate chain. During the verification process, the slave server extracts the CLIENT_ID (64 bits of data) from the master client's public key certificate, and the master client also extracts the SERVER_ID (64 bits of data) from the slave server's public key certificate. The verification priority for certificate chains with hybrid signatures is as follows: if the ECC parameters are non-compliant, such as non-compliant key length, or if the post-quantum algorithm is forced, then it should be processed according to the post-quantum mechanism; if the post-quantum related parameters are also non-compliant, then the current certificate chain of the device should be considered non-compliant.

[0074] In the first phase, the slave server and master client based on the post-quantum algorithm must perform a key encapsulation and exchange mechanism using device certificates to obtain a long-term secret master key KEMSK and a long-term authentication key (this authentication key can reduce the public key authentication operation in the first phase when the master and slave devices are powered on and re-authenticated). Subsequently, both parties should generate temporary content encryption keys based on KEMSK. Both parties should store and keep the master key KEMSK and authentication key confidential for use in the derivation of encryption keys for subsequent Modbus protocol data communication.

[0075] In the second phase, the slave server sends a request to the master client to confirm the authentication key. After receiving the confirmation, the slave server must compare the received key value with the stored key value. If the two match, it can be proven that the master client is legitimate.

[0076] Specifically, the slave server sends `ss_open_req()` to the master client, the master client responds with `ss_open_cnf()`, and the slave server sends `ss_data_req` to the master client. This message contains the slave server's device certificate `Server_Dev_Cert`, the brand certificate `Server_Brand_Cert` issued to the manufacturer of the slave server device, and the ID of the requested data type. The master client responds with `ss_data_cnf`, which contains the master client's key-encapsulated message ciphertext `KEM_C`, the master client's key-encapsulated message ciphertext `KEM_BC`, the encryption / decryption mode `mode`, the master client's device certificate `Client_Dev_Cert`, and the brand certificate `Client_Brand_Cert` issued to the manufacturer of the master client device. Failure to respond to this message will result in a system error, possibly because the master client cannot verify the data from the slave server. The slave server then sends `ss_data_req` to the master client. This message contains the data type ID of the requested AKH. The master client responds with `ss_data_cnf APDU`. The message contains AKH (either valid or all zeros, indicating invalidity; failure to respond to this message will result in a system error). The slave server compares the received AKH with its locally calculated AKM; a discrepancy will result in a system error.

[0077] In this embodiment, a certificate-chain-based bidirectional verification mechanism is introduced into the Modbus serial link. After successful verification, a master key and encapsulation key ciphertext are generated based on the slave device certificate. Then, the content encryption key and the initial value of the counter are derived to encrypt the protocol data unit. A security sublayer is embedded without changing the original frame structure and communication process, which significantly improves its security and has a low cost.

[0078] Referring to Figure 6, which is a flowchart illustrating the second embodiment of the Modbus serial link secure communication method applied to a master station device according to this application, based on the first embodiment described above, a second embodiment of the Modbus serial link secure communication method applied to a master station device according to this application is proposed.

[0079] In the second embodiment, after step S40, the method further includes: step S401, in response to the communication link establishment event with the slave device, querying the authentication context storage area to see if there is a valid authentication context record associated with the first device identifier of the slave device, the valid authentication context record containing the master key and the first authentication key.

[0080] Step S402: If the valid authentication context record exists, the content encryption key is generated based on the master key in the valid authentication context record.

[0081] Step S403: Read the first authentication key from the valid authentication context record and send a fast reconnection request frame containing the first authentication key to the slave device so that the slave device performs key comparison.

[0082] It should be noted that a communication link establishment event refers to an event in which the master device detects that the Modbus serial physical link between itself and the slave device has recovered from a disconnected state to a connected state, or that the Modbus TCP session has transitioned from a CLOSED state to an ESTABLISHED state. Specifically, this can manifest as a connection state change that can be captured by the master device's operating system and communication protocol stack, such as the carrier detection signal on the RS-485 bus being valid, the DPA slave receiving a power-on reset frame, the completion of a TCP three-way handshake, or the establishment of a UDP binding. A valid authentication context record refers to a secure data structure maintained in the master device's non-volatile memory area, uniquely associated with the first device identifier of a specific slave device. This record is written by the previous authentication key derivation process and must contain at least the following indispensable fields: slave device first device identifier (64 bits), master key KEMSK (256 bits), first authentication key AKH (256 bits), encryption / decryption mode mode (8 bits), context creation timestamp (32 bits), recent access timestamp (32 bits), and validity flag (8 bits, 0x01 for valid, 0x00 for invalid). The Fast Reconnection Request Frame (APDU) is a special APDU that the master device actively sends to the slave device when it detects a link establishment event and has a valid authentication context record locally. This APDU does not wait for the slave device to initiate an authentication key request, but actively pushes the first authentication key before the slave device sends any application layer request. It aims to compress the complete public key certificate authentication process into a single symmetric key comparison operation, achieving millisecond-level session recovery.

[0083] Understandably, after completing encrypted communication with a slave device and normally closing the session, the master device does not immediately clear the authentication context record corresponding to that slave device. Instead, the master device keeps the validity flag of the record at 0x01 and updates the most recent access timestamp to the current system time. When the slave device disconnects and is powered on again due to power fluctuations, bus plugging / unplugging, watchdog reset, or maintenance, the master device detects a communication link establishment event at the physical layer or data link layer. The master device first captures the slave device identity information associated with the link establishment event. For Modbus RTU serial links, the identity information comes from the slave device's address field (1 byte, value range 1~247). The master device maintains an address-device identifier mapping table internally, dynamically mapping the slave device's address field to the 64-bit first device identifier extracted from the certificate. For Modbus TCP links, the identity information comes from the TCP connection quadruple (source IP, source port, destination IP, destination port) and TLS session ticket. The master device associates this information with the first device identifier through the session recovery mechanism. The master device immediately queries the authentication context store using the first device identifier as an index.

[0084] Specifically, as an optional implementation, when the master station device detects a power-on reset of the Modbus RTU slave device, it typically first receives a Modbus exception response frame or an empty frame sent by the slave device. Instead of waiting for application layer instructions, the master station device proactively initiates a fast reconnection process. The master station device uses the slave device's address field (e.g., 0x05) as input to query the address-identifier mapping cache. If the cache is hit and the mapping is still valid, the corresponding 64-bit first device identifier is obtained. The master station device uses this identifier as the key to perform a hash lookup in the authentication context storage area. If the lookup is successful and the validity flag of the context record is 0x01, the master station device directly reads the master key KEMSK (256 bits) and the first authentication key AKH (256 bits) from the record. The master station device immediately executes the key derivation process defined in step S40 based on KEMSK: concatenating KEMSK and the slave device's first device identifier into the SM3 hash function to generate the unicast content encryption key CK and the initial counter value CIV, and loading CK and CIV into the current session's encrypted channel control block. At the same time, the master station equipment constructs a fast reconnection request frame.

[0085] It should be understood that the APDU format of the Fast Reconnection Request frame is highly consistent with the APDU format of the ss_data_cnf response AKH. However, to distinguish it from the ordinary authentication key response, this embodiment introduces a special frame type identifier in the Modbus application layer protocol header. As a preferred implementation, the master device sets the function code field of the Modbus PDU to 0x7E and encapsulates the following in the data field: transaction identifier (2 bytes, incrementing), slave device first device identifier (8 bytes, used for secondary confirmation on the slave side), first authentication key AKH (32 bytes), and integrity check value (4 bytes, CRC32 calculated based on AKH and session identifier). The master device encapsulates the APDU in a Modbus RTU frame or Modbus TCP packet and sends it to the slave device preferentially through the serial interface or network protocol stack, ensuring that the slave device completes fast identity verification before processing other service frames.

[0086] In another optional implementation, the master station device employs a different processing strategy for the fast reconnection mechanism in broadcast communication scenarios. Since the broadcast master key KEMSK_B and the broadcast content encryption key BCK are shared by all slave devices, the master station device does not need to maintain a separate broadcast authentication context for each individual slave device. When a slave device completes a fast reconnection and successfully resumes unicast encrypted communication, the master station device encrypts and sends the currently valid broadcast master key encapsulated in ciphertext KEM_BC (or its lightweight derived credential) to the slave device through the unicast encrypted channel. After decrypting to obtain KEM_BC, the slave device uses its own ML-KEM private key to decapsulate and recover the broadcast master key KEMSK_B, and derives BCK and BCIV based on KEMSK_B and the master station device identifier. This design ensures that newly connected or reconnected slave devices can quickly synchronize the master station's current broadcast key state without needing to maintain a persistent authentication context record for broadcast services, significantly reducing the non-volatile storage overhead of the master station device.

[0087] In this embodiment, the master and slave devices that have completed the initial binding completely avoid public key certificate verification and post-quantum key encapsulation operations in subsequent connections, thus avoiding the frequent authentication faced by low-power serial devices, which would result in excessive overhead.

[0088] Based on the above embodiments, this application provides a Modbus serial link secure communication method applied to a slave device. Referring to Figure 7, Figure 7 is a flowchart illustrating the first embodiment of the Modbus serial link secure communication method applied to a slave device according to this application.

[0089] In this embodiment, the method includes: step S01, sending a first certificate chain to the master station device, the first certificate chain including a slave station brand certificate and a slave station device certificate, the slave station device certificate containing a post-quantum key encapsulation public key, and the slave station device locally including a post-quantum key encapsulation private key corresponding to the post-quantum key encapsulation public key.

[0090] Understandably, once the slave device completes its power-on initialization and establishes a Modbus serial physical link with the master device, it enters the secure session negotiation state. The slave device first checks if it has a valid authentication context record associated with the current master device stored locally. If a valid record exists, the slave device can directly initiate a fast reconnection request without executing the complete first certificate chain sending process. If no valid record exists, or if the master device does not respond to the fast reconnection request after a timeout, the slave device initiates the complete public key certificate authentication process and sends the first certificate chain to the master device.

[0091] Specifically, as an optional implementation, the slave device reads the slave brand certificate and slave device certificate from the local file system or certificate store. The slave device sequentially encapsulates these two certificates in an ss_data_req Application Protocol Data Unit (APDU) according to the Modbus security protocol specification. The APDU type is identified as ss_data_req, where the send_datatype_nbr field is set to 2 (indicating that this transmission contains two data type items). The first data type item has a datatype_id value of 11 (Server_Dev_Cert), and datatype_len is the actual bit length of the slave device certificate (e.g., 1280 bits). The data field carries the complete slave device certificate. The second data type item has a datatype_id value of 4 (Server_Brand_Cert), and datatype_len is the actual bit length of the slave brand certificate (e.g., 1280 bits). The data field carries the complete slave brand certificate. In addition, the APDU also contains a request_datatype_nbr field with a value of 5, which is used to request the master device to return 5 data type items (KEM_C, KEM_BC, mode, Client_Dev_Cert, Client_Brand_Cert).

[0092] Step S02: Receive the encapsulation key ciphertext, encryption / decryption mode, and second certificate chain sent by the master station device.

[0093] Step S03: Verify the main site brand certificate in the second certificate chain based on the second root certificate to obtain the second verification result.

[0094] It should be noted that the second root certificate refers to the self-signed root certificate that is pre-installed on the slave device at the factory and used to build the trust anchor of the public key infrastructure. Its function is completely symmetrical to the first root certificate on the master device side.

[0095] Specifically, as an optional implementation, the slave device verifies the validity of the first digital signature of the master station's brand certificate based on the second root certificate. The slave device extracts the root certificate authority's post-quantum digital signature public key (ML-DSA public key) from the SubjectPublicKeyInfo field of the second root certificate. The algorithm identifier of this public key is either id-ML-DSA-44 or id-ML-DSA-65, the specific value depending on the root certificate authority's key strength policy. The slave device extracts the signature value to be verified from the master station's brand certificate: for certificates using post-quantum hybrid signatures, the Signature field contains the joint encoding of the traditional ECC signature (signature_c, signature_d) and the post-quantum signature (signature_σ); the slave device first locates the post-quantum signature subfield and parses the complete ML-DSA signature value according to the ASN.1 serialization rules. The slave device calls the local post-quantum signature verification interface, taking the root certificate public key, the tbsCertificate (the body of the certificate to be signed) encoding of the master station's brand certificate, and the extracted post-quantum signature value as input parameters, and executes the ML-DSA.Verify algorithm. If the signature verification algorithm outputs a valid result, it indicates that the main station brand certificate was indeed issued by a trusted root certificate authority and that the certificate content has not been tampered with during transmission. If the output is invalid, the slave device immediately terminates the verification process, sets the second verification result to fail, and returns error code 0x94 (invalid signature of the main station brand certificate) to the main station device.

[0096] Understandably, the slave device also needs to verify whether the key usage extension of the master station's brand certificate contains the digital signature (digitalSignature) attribute. According to the protocol requirements, the public key in the brand certificate must be used to verify the digital signature of the lower-level device's certificate; therefore, the digitalSignature attribute must be set in the key usage extension. If this extension is missing or the corresponding bit is not set, the slave device should consider the certificate to be of non-compliant use and refuse verification. Furthermore, for brand certificates that support post-quantum hybrid signatures, the slave device also needs to check whether the extension field contains the id-oqs-public-key identifier and verify whether the post-quantum signature public key carried in this extension field is consistent with the post-quantum public key encoded in the certificate body's public key information field. If the consistency check fails, the slave device determines that the certificate format is abnormal, and the verification result is "failed."

[0097] Step S04: When the second verification result is passed, the encapsulated key ciphertext is decrypted based on the encryption / decryption mode and the post-quantum key encapsulation private key to obtain the master key.

[0098] It should be noted that after the slave device confirms the master device's brand certificate verification is successful, the following key data is temporarily stored in the current session context: the first encapsulation key ciphertext KEM_C, the second encapsulation key ciphertext KEM_BC, the encryption / decryption mode field (mode); the subsequent quantum key encapsulation private key MK_DK, and the master device manufacturer identifier extracted from the master device's brand certificate, etc. The slave device immediately initiates the key decapsulation process.

[0099] Specifically, as an optional implementation, the slave device first processes the first encapsulated key ciphertext KEM_C to recover the unicast master key. The slave device reads the complete KEM_C ciphertext (8704 bits) from the session buffer, calls the post-quantum key decapsulation interface in the local hardware security engine or cryptographic algorithm library, and executes the ML-KEM.Decaps decapsulation primitive as input parameters, using the slave device's private key MK_DK and the KEM_C ciphertext. After successful decapsulation, the slave device obtains the 256-bit unicast master key KEMSK and writes it to the key storage area of ​​the current session context, marking it as "authenticated".

[0100] In another optional implementation, if the master device's response message contains the second encapsulated key ciphertext KEM_BC, the slave device, after completing the decapsulation of KEM_C and obtaining the unicast master key, will perform the decapsulation operation of KEM_BC at an opportune time. The slave device reuses the same post-quantum key encapsulated private key MK_DK, uses the KEM_BC ciphertext as input, and calls the ML-KEM.Decaps algorithm again to obtain the 256-bit broadcast master key KEMSK_B. The slave device stores the broadcast master key in the broadcast session context, which is not strongly bound to any specific master device identity, but is associated with the master device's second device identifier (CLIENT_ID). It is worth noting that the slave device is not required to complete the decapsulation of the broadcast master key before the unicast channel is established; as a performance optimization strategy, the slave device can delay the processing of KEM_BC—after the unicast secure channel is established, it can asynchronously perform the broadcast key decapsulation using the idle computing cycle of the unicast channel, thereby avoiding blocking the critical control command interaction between the master device and the current slave device.

[0101] Step S05: Generate a content encryption key and an initial value for the counter based on the master key.

[0102] In the specific implementation process, in order to enable the master and slave devices to independently calculate the authentication key based on the shared master key and complete the implicit comparison through one-way transmission, a quantum-resistant bidirectional implicit authentication is achieved without introducing additional random number interaction. Before step S05, the method further includes: extracting the second device identifier of the master device from the second certificate chain, and generating a second authentication key based on the master key and the second device identifier; sending an authentication key request to the master device and receiving the first authentication key returned by the master device; comparing the first authentication key with the second authentication key to obtain a comparison result.

[0103] It should be noted that the second authentication key refers to the 256-bit symmetric key material (AKM) generated by the slave device after successfully decapsulating and obtaining the master key KEMSK, based on the master key, the master device's second device identifier, and the slave device's own first device identifier, through a cryptographic hash function. This key is used to compare bit-by-bit with the first authentication key (AKH) returned by the master device to verify whether the master device holds the same shared master key and the correct peer device identifier, thereby confirming the legitimacy of the master device. The authentication key request refers to the APDU initiated by the slave device to the master device after completing the generation of the second authentication key, used to request the first authentication key from the master device; the request_datatype_nbr field of this APDU has a value of 1, and the datatype_id field has a value of 17 (AKH). The first authentication key refers to the 256-bit authentication key (AKH) generated by the master device based on the same master key, the slave device's first device identifier, and the master device's second device identifier. This key is carried by the ss_data_cnf APDU and returned to the slave device.

[0104] Specifically, as an optional implementation, the slave device, while generating the second authentication key, simultaneously associates this key with the master device's second device identifier and stores it in its local non-volatile authentication context storage area. The slave device maintains one authentication context record for each master device it is bound to. The index key of this record is the master device's second device identifier (64 bits), and the record content includes at least: a unicast master key KEMSK (256 bits), a second authentication key AKM (256 bits), an encryption / decryption mode (8 bits), and a context validity flag (8 bits, initialized to 0x01 to indicate validity). The slave device's authentication context storage area capacity design includes: each slave device should support at least one authentication context record; for highly available slave devices supporting multi-master polling or master redundancy switching, their authentication context storage area should be expanded to support at least three records, and the record lifecycle should be managed using the Least Recently Used (LRU) algorithm. The slave device employs tamper-proof storage technology similar to that used by the master device to protect the authentication context area. For hardware platforms with TEE or secure elements, the authentication context record should be encrypted and stored in an isolated secure domain.

[0105] Understandably, after receiving the ss_data_cnf returned by the master device, the slave device first verifies whether the send_datatype_nbr field of the APDU is 1, whether the datatype_id field is 17 (AKH), ​​and whether the datatype_len field is 256 bits. If the format verification passes, the slave device extracts the 256-bit first authentication key AKH from the data field. The slave device then compares the received AKH bit by bit with the locally generated second authentication key AKM. As a preferred implementation, the slave device XORs AKH and AKM in 32-bit chunks, sums the XOR results of each chunk, and finally checks whether the sum is zero; no conditional branch jumps are performed throughout the process, and the same CPU cycles are consumed regardless of the comparison result. If the bit-by-bit comparison result is completely consistent, the slave device confirms that the master device's identity is legitimate, and that the master key KEMSK, the slave device's first device identifier, and the master device's second device identifier are all completely consistent with the corresponding data on the slave device side. The slave device marks the current session state as authenticated, keeps the validity flag in the authentication context record at 0x01, and updates the most recent access timestamp.

[0106] Step S06: Receive the encrypted protocol data unit sent by the master station device, and decrypt the encrypted protocol data unit according to the content encryption key and the initial value of the counter to obtain the protocol data unit.

[0107] Understandably, after successfully deriving the content encryption key CK and the initial counter value CIV, and completing two-way authentication with the master device, the slave device enters the encrypted communication ready state. The slave device continuously listens to the Modbus serial link, receiving message frames reported by the physical layer through interrupt service routines or polling, and performing CRC checks and slave address field matching on each frame. When the address field matches the slave device's own address or is a broadcast address (0x00), the slave device delivers the frame payload to the Modbus application layer protocol parsing module. The parsing module first checks the function code field in the frame. According to the protocol, the Modbus frame function code carrying encrypted application data units is fixed at 0x00 (indicating that the frame carries secure protocol data); if the function code is not 0x00, the slave device processes the frame as a traditional unencrypted Modbus frame or discards it according to its local security policy. The slave device then reads the 24-bit ss_data_send_tag ​​from the beginning of the data field and compares it with the protocol constant 0x9F9011. If the tag matches, the current frame is determined to be an encrypted data frame, and the decryption process in step S06 is initiated. If the tag does not match, the slave device treats the frame as an illegal format and discards it, and optionally returns an exception response code.

[0108] In broadcast communication scenarios, upon receiving an encrypted Modbus message frame with a destination address of 0x00, the slave device automatically reads the broadcast content encryption key BCK and the initial value of the broadcast counter BCIV from the broadcast session context. It then performs decryption and integrity verification using the exact same algorithm as unicast decryption. The slave device does not need to distinguish between unicast and broadcast messages. The decryption algorithm relies solely on the key material and the initial counter value, and the broadcast address frame naturally triggers the slave device to invoke the broadcast key context. This design allows the slave device to process all encrypted messages using a unified code path, requiring only the selection of different key session control blocks based on the destination address branch during the key lookup phase.

[0109] In one example, referring to Figure 8, which is a schematic diagram of the computational flow of the authentication process based on post-quantum certificates in this application, the slave server sends its public key certificate chain to the master client using an appropriate APDU. The master client verifies the validity of the two slave server certificates received. The master client generates two 32-byte random numbers using an appropriate PRNG, calculates and obtains a master key KEMSK and a broadcast master key KEMSK_B, along with their corresponding encapsulated key ciphertexts KEM_C and KEM_BC, respectively, using the ML-KEM.Encaps algorithm. The master client sends the encapsulated key ciphertexts KEM_C and KEM_BC, the encryption / decryption mode mode, and the master client device certificate and the brand certificate of the master client device manufacturer to the slave server. The slave server verifies the validity of the two certificates received. The slave server checks the parameters, calculates the 32-byte master key KEMSK and broadcast master key KEMSK_B using KEM_C and the ML-KEM.Decaps algorithm in NIST.FIPS.203, and calculates and stores the authentication key (AKM). The master client calculates and stores the authentication key (AKH).

[0110] The slave server initiates the second phase of the authentication process: it requests the current authentication key AKH from the master client by sending a response APDU. The slave server then sends the AKH to the master client using the appropriate APDU. The slave server compares the received AKH with its own calculated AKM; if they differ, a system error will occur.

[0111] The authentication keys (AKH and AKM) are calculated so that they can be used in subsequent authentication processes. These keys are generated when the master client and slave server are first bound, stored in the NVM, and can be used for repeated authentication. The calculation process is as follows:

[0112] The derivation of CK and CIV is calculated as follows:

[0113]

[0114] Finally, BCK and CIV are derived. The broadcast master key KEMSK_B is used for broadcast communication between the master client and all slave servers. The calculation process is as follows:

[0115]

[0116] The authentication context is stored in NVM. Its storage format is not mandatory in this embodiment, but in actual product implementations, it should be given sufficient security to ensure it cannot be altered by attackers. The authentication context is used to store the result of public key authentication between the two devices and is used to perform the re-authentication process.

[0117] After the master client and slave server are initially bound, the device should associate the DHSK and authentication key negotiated during the public key authentication process with an authentication context. The master client should support at least 247 authentication contexts, and the slave server should support at least 1 authentication context.

[0118] After establishing a session, the master client and slave server can first perform an authentication key verification step to check if an existing binding relationship exists between the two devices. If so, there is no need to execute the public key authentication protocol. If the slave server has a valid authentication context, it should request the master client to send an AKH and then check if the received AKH matches the AKM in its local authentication context. If they do not match, the slave server can try up to 246 more times (because the master client may have 247 authentication contexts). When the master client has no other available authentication contexts, it should send an all-zero value as a response to the slave server's AKH request, at which point the slave server should begin executing the public key authentication protocol. If the master client has the slave's authentication context, it should first send the AKH from that slave's context. If this AKH does not match the slave server's AKM, the slave server should retry requesting the AKH, at which point the master client will send other AKHs from other authentication contexts. Therefore, powering back on the slave server does not necessarily mean that the public key authentication protocol will be executed. However, when a slave server connects to a master client that has not been bound before, or when a master client connects to a slave server that it has not bound before, the authentication protocol related to the public key certificate must be executed.

[0119] In this embodiment, the slave device can automatically complete two-way authentication and session key negotiation with the master station through a pre-set root certificate and device private key without having a complex certificate management interface. The slave device does not need to maintain a complete certificate revocation list or clock synchronization mechanism to independently verify the validity of the master station's certificate chain, which greatly reduces the hardware resource requirements and implementation complexity of the slave device.

[0120] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the Modbus serial link secure communication method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0121] This application also provides a Modbus serial link secure communication device applied to a master station device. Referring to Figure 9, the device includes: a certificate verification module 10, used to receive a first certificate chain sent by a slave device, and verify the slave brand certificate in the first certificate chain according to the first certificate to obtain a verification result; a ciphertext generation module 20, used to generate a master key and a corresponding encapsulation key ciphertext based on the slave device certificate in the first certificate chain when the verification result is passed; a key sending module 30, used to send the encapsulation key ciphertext, the encryption / decryption mode of the master station device, and the second certificate chain to the slave device so that the slave device can verify the second certificate chain, and after the verification is passed, decrypt the encapsulation key ciphertext based on the private key of the slave device to obtain the master key; and a data encryption module 40, used to generate a content encryption key and a counter initial value based on the master key, and encrypt the protocol data unit to be sent according to the content encryption key and the counter initial value, and send the encrypted protocol data unit to the slave device.

[0122] The Modbus serial link secure communication device provided in this application, employing the Modbus serial link secure communication method in the above embodiments, can solve the technical problem that data leakage or modification is easily caused when transmitting Modbus industrial control protocols through serial port media, posing serious security risks. Compared with the prior art, the beneficial effects of the Modbus serial link secure communication device provided in this application are the same as those of the Modbus serial link secure communication method provided in the above embodiments, and other technical features in the Modbus serial link secure communication device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0123] This application also provides a Modbus serial link secure communication device for slave devices. Referring to Figure 10, the device includes: a certificate sending module 01, used to send a first certificate chain to a master device, the first certificate chain including a slave brand certificate and a slave device certificate, the slave device certificate containing a post-quantum key encapsulation public key, and the slave device's local storage including a post-quantum key encapsulation private key corresponding to the post-quantum key encapsulation public key; a key receiving module 02, used to receive the encapsulated key ciphertext, encryption / decryption mode, and second certificate chain sent by the master device; and a certificate verification module 03, used to verify the second root certificate. The system verifies the main station brand certificate in the second certificate chain to obtain a second verification result; the ciphertext decryption module 04 is used to decrypt the encapsulated key ciphertext based on the encryption / decryption mode and the post-quantum key encapsulation private key when the second verification result is passed, to obtain the master key; the key generation module 05 is used to generate a content encryption key and an initial value for the counter based on the master key; the data decryption module 06 is used to receive the encrypted protocol data unit sent by the main station device, and decrypt the encrypted protocol data unit according to the content encryption key and the initial value for the counter to obtain the protocol data unit.

[0124] The Modbus serial link secure communication device provided in this application, employing the Modbus serial link secure communication method in the above embodiments, can solve the technical problem that data leakage or modification is easily caused when transmitting Modbus industrial control protocols through serial port media, posing serious security risks. Compared with the prior art, the beneficial effects of the Modbus serial link secure communication device provided in this application are the same as those of the Modbus serial link secure communication method provided in the above embodiments, and other technical features in the Modbus serial link secure communication device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0125] This application provides a Modbus serial link secure communication device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the Modbus serial link secure communication method in the first embodiment described above.

[0126] Referring now to Figure 11, a schematic diagram of a Modbus serial link secure communication device suitable for implementing embodiments of this application is shown. The Modbus serial link secure communication device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. The Modbus serial link secure communication device shown in Figure 11 is merely an example and should not impose any limitations on the functionality and scope of use of embodiments of this application.

[0127] As shown in Figure 11, the Modbus serial link secure communication device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory 1002 or a program loaded from storage device 1003 into random access memory 1004. Random access memory 1004 also stores various programs and data required for the operation of the Modbus serial link secure communication device. The processing unit 1001, read-only memory 1002, and random access memory 1004 are interconnected via bus 1005. Input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to input / output interface 1006: input devices 1007 including, for example, touch screens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the Modbus serial link secure communication device to communicate wirelessly or wiredly with other devices to exchange data. While various systems of Modbus serial link secure communication devices are shown in the figures, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0128] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0129] The Modbus serial link secure communication device provided in this application, employing the Modbus serial link secure communication method described in the above embodiments, can solve the technical problem that data leakage or modification is easily caused when transmitting Modbus industrial control protocols through serial port media, posing serious security risks. Compared with the prior art, the beneficial effects of the Modbus serial link secure communication device provided in this application are the same as those of the Modbus serial link secure communication method provided in the above embodiments, and other technical features of this Modbus serial link secure communication device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0130] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0131] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0132] The above description is only a part of the embodiments of this application and does not limit the scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

Claims

1. A Modbus serial link secure communication method, characterized in that, The method, applied to a master station device, includes: receiving a first certificate chain sent by a slave station device, and verifying the slave station brand certificate in the first certificate chain according to the first certificate to obtain a verification result; when the verification result is successful, generating a master key and a corresponding encapsulation key ciphertext based on the slave station device certificate in the first certificate chain; sending the encapsulation key ciphertext, the encryption / decryption mode of the master station device, and the second certificate chain to the slave station device so that the slave station device can verify the second certificate chain, and after successful verification, decrypting the encapsulation key ciphertext based on the private key of the slave station device to obtain the master key; generating a content encryption key and an initial value for a counter based on the master key, encrypting the protocol data unit to be sent according to the content encryption key and the initial value for the counter, and sending the encrypted protocol data unit to the slave station device.

2. The Modbus serial link secure communication method as described in claim 1, characterized in that, The step of verifying the slave brand certificate in the first certificate chain based on the first root certificate to obtain a verification result includes: verifying the validity of the first digital signature of the slave brand certificate based on the first root certificate, wherein the first digital signature is generated by the root certificate authority using a post-quantum digital signature private key; after the slave brand certificate passes verification, extracting the post-quantum digital signature public key from the slave brand certificate; and verifying the validity of the second digital signature of the slave device certificate based on the post-quantum digital signature public key to obtain a verification result.

3. The Modbus serial link secure communication method as described in claim 1, characterized in that, Before generating the content encryption key and the initial value of the counter based on the master key, the method further includes: extracting the first device identifier of the slave device from the slave device certificate, and reading the second device identifier of the master device from local storage; generating a first authentication key based on the master key, the first device identifier, and the second device identifier; associating the first authentication key with the identity identifier of the slave device and storing it in the local authentication context; and sending the first authentication key in response to the authentication key request sent by the slave device, so that the slave device compares the first authentication key with the second authentication key.

4. The Modbus serial link secure communication method as described in claim 3, characterized in that, The step of generating the content encryption key and the initial value of the counter based on the master key includes: when the master key is a unicast master key, concatenating the unicast master key and the first device identifier of the slave device to obtain a first key derivation input sequence; inputting the first key derivation input sequence into a cryptographic hash function, and determining the content encryption key and the initial value of the counter corresponding to the unicast master key according to the first consecutive bit sequence output; when the master key is a broadcast master key, concatenating the broadcast master key and the second device identifier of the master device to obtain a second key derivation input sequence; inputting the second key derivation input sequence into the cryptographic hash function, and determining the content encryption key and the initial value of the counter corresponding to the broadcast master key according to the second consecutive bit sequence output.

5. The Modbus serial link secure communication method as described in claim 1, characterized in that, After generating a content encryption key based on the master key, encrypting the protocol data unit to be sent according to the content encryption key, and sending the encrypted protocol data unit to the slave device, the method further includes: responding to a communication link establishment event with the slave device, querying the authentication context storage area to see if there is a valid authentication context record associated with the first device identifier of the slave device, the valid authentication context record containing the master key and the first authentication key; if the valid authentication context record exists, generating the content encryption key based on the master key in the valid authentication context record; reading the first authentication key from the valid authentication context record, and sending a fast reconnection request frame containing the first authentication key to the slave device, so that the slave device performs key comparison.

6. A Modbus serial link secure communication method, characterized in that, The method, applied to a slave device, includes: sending a first certificate chain to a master device, the first certificate chain including a slave brand certificate and a slave device certificate, the slave device certificate containing a post-quantum key encapsulation public key, and the slave device locally including a post-quantum key encapsulation private key corresponding to the post-quantum key encapsulation public key; receiving encapsulation key ciphertext, encryption / decryption mode, and a second certificate chain sent by the master device; verifying the master brand certificate in the second certificate chain based on the second certificate to obtain a second verification result; when the second verification result is successful, decrypting the encapsulation key ciphertext based on the encryption / decryption mode and the post-quantum key encapsulation private key to obtain a master key; generating a content encryption key and an initial value for a counter based on the master key; receiving encrypted protocol data units sent by the master device, and decrypting the encrypted protocol data units according to the content encryption key and the initial value for the counter to obtain protocol data units.

7. The Modbus serial link secure communication method as described in claim 6, characterized in that, Before generating the content encryption key and the initial value of the counter based on the master key, the method further includes: extracting the second device identifier of the master station device from the second certificate chain, and generating a second authentication key based on the master key and the second device identifier; sending an authentication key request to the master station device, and receiving the first authentication key returned by the master station device; comparing the first authentication key with the second authentication key to obtain a comparison result.

8. A Modbus serial link secure communication device, characterized in that, The device, applied to a master station device, includes: a certificate verification module for receiving a first certificate chain sent by a slave station device and verifying the slave station brand certificate in the first certificate chain according to the first certificate to obtain a verification result; a ciphertext generation module for generating a master key and a corresponding encapsulation key ciphertext based on the slave station device certificate in the first certificate chain when the verification result is successful; a key sending module for sending the encapsulation key ciphertext, the encryption / decryption mode of the master station device, and the second certificate chain to the slave station device so that the slave station device can verify the second certificate chain, and after successful verification, decrypt the encapsulation key ciphertext based on the private key of the slave station device to obtain the master key; and a data encryption module for generating a content encryption key and a counter initial value based on the master key, encrypting the protocol data unit to be sent according to the content encryption key and the counter initial value, and sending the encrypted protocol data unit to the slave station device.

9. A Modbus serial link secure communication device, characterized in that, The device, applied to a slave device, comprises: a certificate sending module for sending a first certificate chain to a master device, the first certificate chain including a slave brand certificate and a slave device certificate, the slave device certificate containing a post-quantum key encapsulation public key, and the slave device locally including a post-quantum key encapsulation private key corresponding to the post-quantum key encapsulation public key; a key receiving module for receiving encapsulated key ciphertext, encryption / decryption mode, and a second certificate chain sent by the master device; a certificate verification module for verifying the master brand certificate in the second certificate chain based on the second certificate to obtain a second verification result; a ciphertext decryption module for decrypting the encapsulated key ciphertext based on the encryption / decryption mode and the post-quantum key encapsulation private key when the second verification result is successful, to obtain a master key; a key generation module for generating a content encryption key and an initial value for a counter based on the master key; and a data decryption module for receiving encrypted protocol data units sent by the master device and decrypting the encrypted protocol data units according to the content encryption key and the initial value for the counter to obtain protocol data units.

10. A Modbus serial link secure communication device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the Modbus serial link secure communication method as claimed in any one of claims 1 to 7.

Images