iotops P. Liu, Ed. Internet-Draft R. Yang, Ed. Intended status: Informational Pengcheng Laboratory Expires: 14 June 2026 R. Chen, Ed. China Mobile R. Fu, Ed. China Unicom Y. Zhang, Ed. Pengcheng Laboratory 11 December 2025 Modbus Serial Link Communication Security Protocol Specification draft-liu-iotops-modbus-seriallink-sec-spec-03 Abstract Currently, the industry has only standardized TLS-based security protocol for Modbus TCP communication. However, for EIA/TIA-485 multi-point systems, whether in 2-wire or 4-wire configurations, cables with a maximum baud rate of 9600 bit/s and AWG26 (or thicker) specifications can reach lengths over 1000m. For RS485 Modbus, sufficient cable diameter supports lengths over 1000m, and Category 5 cables can reach up to 600m. Despite its widespread use, Modbus serial link communication lacks standardized security mechanisms. As an application-layer industrial communication protocol, Modbus urgently requires targeted security standards for different deployment scenarios to enhance its security framework and ecosystem. For instance, in scenarios involving hardware side-channel attacks or long-distance relay and bridged networks, transmitting plaintext Modbus data over serial links risks data leakage or malicious modification by intermediaries, posing significant data and command security threats. To address this, it is critical to improve the communication security of Modbus in serial link mode by introducing encryption and authentication mechanisms. A proposed Modbus serial link security standard defines simple encryption and authentication methods to significantly enhance security while maintaining compatibility. This provides a straightforward upgrade path for existing Modbus-based devices, ensuring secure and practical applications in industrial control systems. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Liu, et al. Expires 14 June 2026 [Page 1] Internet-Draft Security Protocol for Modbus Serial Link December 2025 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 June 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terms defined in this document . . . . . . . . . . . . . . . 4 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Modbus Serial Link Communication Security Protocol Specification . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Modbus Serial Link Communication Security Service Definition . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Modbus Serial Link Security Protocol . . . . . . . . . . 7 5.2.1. System workflow . . . . . . . . . . . . . . . . . . . 8 5.2.2. Modbus Serial Link Security Protocol Based on Public Key Certificate . . . . . . . . . . . . . . . . . . . 10 5.2.3. Modbus Serial Link Security Protocol Based on Password or Pre-Shared Key . . . . . . . . . . . . . . . . . . 54 6. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 60 7. Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . 61 8. Appendix C . . . . . . . . . . . . . . . . . . . . . . . . . 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 10. Security Considerations . . . . . . . . . . . . . . . . . . . 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 Liu, et al. Expires 14 June 2026 [Page 2] Internet-Draft Security Protocol for Modbus Serial Link December 2025 11.1. Normative References . . . . . . . . . . . . . . . . . . 67 11.2. Informative References . . . . . . . . . . . . . . . . . 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 1. Introduction The Modbus protocol with serial link communication as shown in Figure 1, is widely used in industrial communication, was not originally designed with security in mind. Its lack of encryption, authentication, and data integrity mechanisms makes it vulnerable to various cyberattacks, including replay, man-in-the-middle (MITM), and unauthorized access. Currently, for any EIA/TIA-485 multi-point system, whether it is a 2-wire or 4-wire configuration, the maximum length for cables with a maximum baud rate of 9600bit/s and AWG26 (or thicker) specifications can reach over 1000m. For RS485 Modbus, a sufficiently wide cable diameter should allow for a maximum length of over 1000m, and for RS485 Modbus using Category 5 cables, the maximum length can reach 600m. Currently, there is no relevant security communication standard for the existing Modbus serial link communication method. As an industrial communication protocol at the application level, with the evolution of precision attack technology, Modbus urgently needs to provide targeted security technology standards for different deployment scenarios to continuously improve the Modbus industrial application security guarantee system and ecology. For example, in the presence of modern advanced hardware side channel attacks, especially in the case of long-distance relay serial or bridged networks, transmitting Modbus industrial control protocol data in plaintext over a fully serial link medium can easily lead to data leakage or malicious modification by intermediaries, posing serious data or instruction security risks. +-----------------------------+ | Master station (client) | +------------------+----------+ | EIA/TIA-485/232 Modbus Serial Link +-------------------+-------+-----------------+ | | | +---------+---------------+ +----+-----+ +----+-------+ |Slave station (server) 1 | | Slave... | | Slave... n | +-------------------------+ +----------+ +------------+ Figure 1: Modbus Serial Link Communication Network For Modbus TCP, significant progress has been made to address these vulnerabilities. The Modbus Security Specification introduces Transport Layer Security (TLS) to encrypt and authenticate communications. TLS 1.2 or higher is mandated, ensuring protection against eavesdropping and MITM attacks. Additionally, X.509v3 certificates enable mutual authentication between clients and Liu, et al. Expires 14 June 2026 [Page 3] Internet-Draft Security Protocol for Modbus Serial Link December 2025 servers, while role-based access control (RBAC) allows granular security configurations. The Chinese standard GB/T 41868-2022 has further expanded Modbus TCP security by adopting TLS encryption while maintaining compatibility with the original Application Data Unit (ADU) format. Modbus TCP Security uses IANA-registered port 802 for secure communication, providing a clear upgrade path for existing systems. However, the security of serial link communication (e.g., RS485-based Modbus) remains an unresolved challenge. Serial Modbus transmits data in plaintext, leaving it susceptible to interception, modification, and hardware-based side-channel attacks. There are currently no formal standards addressing security for Modbus over RS485, which is still widely used due to its simplicity and long- distance capabilities. This lack of encryption and authentication mechanisms poses risks, particularly in scenarios involving relays or bridged networks. While Modbus TCP has seen notable advancements in security through TLS-based solutions, serial Modbus communication requires urgent attention. Introducing lightweight encryption and authentication mechanisms for serial links could provide a practical way to enhance security and protect legacy systems without significant infrastructure changes. Therefore, it is urgent to improve and enhance the communication security of Modbus protocol under serial link mode, for reference by relevant institutions and organizations in various industries, in order to ensure the practical application security of various industrial control systems. With the introduction of the Modbus serial link security standard, the introduction of encryption and authentication mechanisms in the serial link communication channel of the Modbus protocol significantly improves its security, providing a relatively simple and direct upgrade path for existing devices that use Modbus extensively. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terms defined in this document Liu, et al. Expires 14 June 2026 [Page 4] Internet-Draft Security Protocol for Modbus Serial Link December 2025 1. Trust anchor: An entity that is trusted by relying parties to validate the ownership, delegation, and authenticity of network resources. It serves as a root of trust for establishing and verifying resource allocation chains across multiple infrastructure services through cryptographic mechanisms and distributed consensus. 2. Modbus device: A device that implements Modbus on a serial link and follows its technical specifications. 3. Secure authenticated channel: A logical channel established using password methods between the master and slave stations that supports authentication and encryption of data. 4. Master client: The master client is a device on the serial communication link that sends instruction request and there is usually only one such device on a serial communication link. 5. Slave server: The slave client is a device on the serial communication link that sends instruction response. Generally, there can be multiple such devices on a single serial communication link. 6. Uimsbf: Unsigned integer most significant bit first 7. Bslbf: Bit serial leftmost bit first 4. Design Goals The Modbus serial link communication security protocol specification aims to provide: 1. The Modbus serial bus security service definition, protocol specifications, system dependencies, and corresponding requirements for the Modbus serial link communication security protocol. 2. Reference application standards for institutions and organizations in the development or testing of Modbus serial communication security products 5. Modbus Serial Link Communication Security Protocol Specification Liu, et al. Expires 14 June 2026 [Page 5] Internet-Draft Security Protocol for Modbus Serial Link December 2025 5.1. Modbus Serial Link Communication Security Service Definition The Modbus application layer protocol and its standard function codes used on serial links are described in detail in the national standards Modbus Security Specification, GB/T 19582.1-2008 and GB/T 19582.2-2008. The function code field of the Modbus data unit is encoded with one byte, and the valid function code range is decimal 1-255 (with 128-255 reserved for exception response). When sending a message from the client to the server device, the function code field notifies the server of which operation to perform, where the function code '0' is invalid. In the standard Modbus Security Specification, GB/T 19582.1-2008, the following function codes and sub-codes are not included in the content of this standard. These function codes and sub codes are specially reserved in the format of function codes/sub codes, or only function codes, and all sub-codes (0-255) are reserved: 8/19, 8/21-65535, 9, 10, 13, 14, 41, 42, 90, 91, 125, 126, and 127. Please refer to Annex III of the standard GB/T 19582.1-2008. For the standard function codes defined in Modbus Security Specification, GB/T 19582.1-2008 and GB/T 19582.2-2008, this specification does not make any modifications to the function definitions. In addition, this specification does not occupy the valid business function code resources defined in the standard Modbus Security Specification, GB/T 19582.1-2008 to implement security service functions, while maintaining compatibility with the Modbus serial link protocol. this specification defines the function code "0" for the serial link secure communication service, which occupies an 8-bit byte and is used to define the content related to the Modbus serial link secure communication protocol. Among them, the original Modbus serial link protocol function codes and data fields are included as relevant parameters in the security protocol data to ensure that the corresponding business function codes and data are confidential or complete during serial link communication. The implementation of serial link secure communication defined in this specification can be achieved by adding a separate security external module or security proxy module to the master and slave devices, or directly integrating relevant security modules on the master and slave devices. The specific implementation form is not within the scope of this specification. In the secure mode of serial link communication, when using Modbus RTU transmission mode, the corresponding relationship between the original Modbus RTU frame and the Modbus secure RTU frame is shown in Figure 2, where the function code and data field of the original RTU frame are encrypted and included in protocol data field of the secure RTU frame: Liu, et al. Expires 14 June 2026 [Page 6] Internet-Draft Security Protocol for Modbus Serial Link December 2025 +-------+----------------------+------------------+------+ | Addr. | Func. code | Data | CRC | +-------+----------------------+------------------+------+ | 1B | 1B | 0-252B | 2B | +-------+----------------------+------------------+------+ | | | | | | | | +-------+------------+---------V---------V-----+------+ | | | param.|Func.code|data | | +-------+------------+-----------------|-------+------+ | Addr. | Func. code | Protocol Data | CRC | +-------+------------+-------------------------+------+ | 1B | 1B (0) | 0-252B | 2B | +-------+------------+-------------------------+------+ Figure 2: Modbus Secure RTU Message Frame In the secure mode of serial link communication, when using Modbus ASCII transmission mode, the corresponding relationship between the original Modbus ASCII frame and the Modbus secure ASCII frame is shown in Figure 3, where the function code and data field of the original ASCII frame are encrypted and included in protocol data field of the secure ASCII frame: +------------+-------+----------------------+-----------+------+----------+ | start char.| Addr. | Func. code | Data | LRC | end char.| +------------+-------+----------------------+-----------+------+----------+ | 1B | 2B | 2B | 0-504B | 2B | 2B | +------------+-------+----------------------+-----------+------+----------+ | | | | | | | | +------------+-------+------------+--------V-------+-V--+------+-----------+ | | | |param.|Func.code|data| | | +------------+-------+------------+---------------------+------+-----+-----+ | start char.| Addr. | Func. code | Data | LRC | end char. | +------------+-------+------------+---------------------+------+-----+-----+ | 1B | 2B | 2B (0) | 0-504B | 2B | 2B | +------------+-------+-----------------------+----------+------+-----+-----+ Figure 3: Modbus Secure ASCII Message Frame 5.2. Modbus Serial Link Security Protocol Liu, et al. Expires 14 June 2026 [Page 7] Internet-Draft Security Protocol for Modbus Serial Link December 2025 5.2.1. System workflow The Modbus serial link security protocol specification defined in this specification aims to protect the transmission of industrial control system protocol parameters between master/slave stations (clients/servers) through the serial bus interface using the Modbus protocol, ensuring that protocol parameters are not maliciously modified or intercepted by intermediaries. On a Modbus serial link, the master station on the serial bus acts as the client and the slave station acts as the server. The specific workflow varies depending on the security protocols used. This specification provides multiple security protocols for industry reference and implementation. The Modbus serial link security protocol based on public key certificates is mainly implemented through the following six processes, which will be described separately in the following chapters. 1. Bidirectional public key authentication between client and server. When the client and server are bound for the first time, a mutual authentication protocol needs to be executed. Successfully executing the protocol can make the client and server confident in each other's reliability, and can also share a master key between both parties for secure processing of the protocol. 2. Re-authentication of client and server. On the basis of the first binding and sharing of the master key, the mutual authentication protocol is generally not executed when booting up again, but the re authentication protocol is executed. 3. SAC secure channel establishment. After successful authentication, the system enters the process of establishing the SAC secure channel. SAC secure channel is a secure channel established by the original Modbus protocol function code and data encryption and authentication key (referred to as content key). 4. Content key establishment. On the SAC secure channel, the client and server can establish content keys for encrypting the original Modbus protocol function codes and data. 5. Protocol function code and data encryption transmission. On the basis of establishing the content key, when sending a request, the client transmits the encrypted original Modbus protocol request function code and data to the server through Modbus secure RTU or ASCII message frames. The encrypted original Modbus protocol function code and data are decrypted and further Liu, et al. Expires 14 June 2026 [Page 8] Internet-Draft Security Protocol for Modbus Serial Link December 2025 processed on the server. When sending a response, the server transmits the encrypted original Modbus protocol response function code and data to the client through Modbus secure RTU or ASCII message frames. The encrypted original Modbus protocol function code and data are decrypted and further processed on the client. 6. For Modbus broadcast protocol interaction, based on the SAC secure channel, when establishing a content key, the client directly sends the corresponding individual broadcast content key to all slave servers on the bus. The content key for Modbus communication is the same for all slave servers. When sending a broadcast request, the client uses the broadcast content key to transmit the encrypted original Modbus protocol broadcast request function code and data to the server through Modbus secure RTU or ASCII message frames. The encrypted original Modbus protocol function code and data are decrypted and further processed on the server. When sending a response, the server uses the broadcast content key to transmit the encrypted original Modbus protocol response function code and data to the client through Modbus secure RTU or ASCII message frames. The encrypted original Modbus protocol function code and data are decrypted and further processed on the client. The Modbus serial link security protocol based on passwords or pre- shared keys mainly includes the following four processes, which will be described separately in the following chapters. 1. Bidirectional authentication between client and server. When the client and server are bound for the first time, a mutual authentication protocol needs to be executed. Successfully executing the protocol can make the client and server confident in each other's reliability, and can also share a master key between both parties for secure processing of the protocol. 2. Content encryption key establishment. The client and server establish two content encryption keys based on passwords or pre shared keys to encrypt and protect the original Modbus protocol function codes and data, one for broadcasting Modbus communication and the other for separate communication between the slave and master stations. The content key used for broadcasting Modbus communication is the same for all slave servers. 3. Protocol function code and data encryption transmission. On the basis of establishing the content key, when sending a request, the client transmits the encrypted original Modbus protocol request function code and data to the server through Modbus Liu, et al. Expires 14 June 2026 [Page 9] Internet-Draft Security Protocol for Modbus Serial Link December 2025 secure RTU or ASCII message frames. The encrypted original Modbus protocol function code and data are decrypted and further processed on the server. When sending a response, the server transmits the encrypted original Modbus protocol response function code and data to the client through Modbus secure RTU or ASCII message frames. The encrypted original Modbus protocol function code and data are decrypted and further processed on the client. 4. Regarding Modbus broadcast protocol interaction. When sending a broadcast request, the client uses the broadcast content key to transmit the encrypted original Modbus protocol broadcast request function code and data to the server through Modbus secure RTU or ASCII message frames. The encrypted original Modbus protocol function code and data are decrypted and further processed on the server. When sending a response, the server uses the broadcast content key to transmit the encrypted original Modbus protocol response function code and data to the client through Modbus secure RTU or ASCII message frames. The encrypted original Modbus protocol function code and data are decrypted and further processed on the client. 5.2.2. Modbus Serial Link Security Protocol Based on Public Key Certificate 5.2.2.1. Key hierarchy structure The key management in the Modbus serial link security protocol based on public key certificates is suitable for high-value and high security factories and devices. It is divided into four levels: Credentials layer, Authentication layer, SAC secure channel layer, and Content key layer. The names, storage, and usage of the main parameters are summarized as below. 1. root certificate: Certificate of system trust root, which is non-volatile storaged and local use. 2. Brand certificate: Brand certificate of device manufacturer, which is non-volatile storaged and used for exchange. 3. Device certificate: Public key certificates for the main and slave devices under the brand, which is non-volatile storaged and used for exchange. 4. EC_p: ECC Parameters, which is non-volatile storaged and local use. Liu, et al. Expires 14 June 2026 [Page 10] Internet-Draft Security Protocol for Modbus Serial Link December 2025 5. EC_a: ECC Parameters, which is non-volatile storaged and local use. 6. EC_b: ECC Parameters, which is non-volatile storaged and local use. 7. EC_N: ECC Parameters, which is non-volatile storaged and local use. 8. EC_G: ECC Parameters, which is non-volatile storaged and local use. 9. MDP/HDP: Device Public Key, which is non-volatile storaged and exchange use. 10. MDQ/HDQ: Device private key, which is non-volatile storaged and local use. 11. DHX/DHY: The power of DH modular exponentiation operation, which is volatile storaged and local use. 12. DHPM/DHPH: The public key generated after DH modular exponentiation operation, which is volatile storaged and exchange use. 13. DHSK: DH key (master key), which is non-volatile storaged and local use. 14. AKM: Master authentication key, which is non-volatile storaged and local use. 15. AKH: Slave authentication key, which is non-volatile storaged and exchange use. 16. Ns_M/Ns_H: Random numbers used for SAC channel establishment, which is volatile storaged and exchange use. 17. SEK: SAC data encryption key, which is volatile storaged and local use. 18. SAK: SAC Data Authentication Key, which is volatile storaged and local use. 19. SIV: SAC initialization vector, which is non-volatile storaged and local use. 20. Kp: Precursor used to calculate CK key, which is volatile storaged and exchange use. Liu, et al. Expires 14 June 2026 [Page 11] Internet-Draft Security Protocol for Modbus Serial Link December 2025 21. CK/BCK: Content encryption key for Modbus protocol function code and data, which is volatile storaged and local use. 22. CIV/BCKIV: Content encryption initialization vector, which is volatile storaged and local use. The keys at the credentials layer mainly include ECC public cryptographic protocol parameters, private keys of the master client and slave server, and public key certificate chains. The public key certificate chain includes root certificates, vendor certificates, and device certificates. The device certificate includes the device's ID number, ECC public key, and other attribute information of the certificate. The key data at this level is mainly used to execute authentication protocols. After device initialization, the certificate must not be changed or replaced. It is recommended to use mature OTP memory based on eFuse or Anti-Fuse technology, one- time programmable non-volatile memory, and data that cannot be reversibly modified after writing. The definition of protection methods for these data is not within the scope of this specification. For the master client, the keys at the authentication layer are mainly DHSK and AKM; for the slave server, there are mainly two keys, namely DHSK and AKH. Among them, DHSK is a shared master key negotiated after a two-way authentication protocol, while AKM and AKH are exported by DHSK. These three keys are long-term keys that should be stored in the device's NVM and must be guaranteed not to be modified or intercepted by third parties. It is recommended to use a mature TEE environment, and the protection methods for these keys are not within the scope of this specification. The SAC secure channel layer has two keys, SAK and SEK. The former is used for message authentication based on SAC, while the latter is used for message encryption based on SAC. The SAK and SEK keys are generated through the SAC initialization protocol executed by both parties and are temporary keys shared between the client and server. It should be stored in the NVM of the device and must ensure that it cannot be modified or accessed by third parties. It is recommended to use a mature TEE environment, and the definition of protection methods for SAK and SEK keys is not within the scope of this specification. The content key layer first generates the content key CK and an initial vector CIV based on the SAC secure channel, while generating the keys BCK and BCIV required for broadcast communication. Then, the content key CK and initial vector CIV are used to encrypt and decrypt Modbus communication data using AES. The generation of CK key and vector CIV key is led by the master client, and the slave server obtains the same CK key and vector CIV through the SAC secure Liu, et al. Expires 14 June 2026 [Page 12] Internet-Draft Security Protocol for Modbus Serial Link December 2025 channel. Both are generated temporarily, and under certain conditions, the system must update the content key to provide high- strength security. Please refer to the following chapters for detailed instructions. The overall key generation and usage process is as follows: After power on start-up, the master and slave devices first perform a power on self-test. If it is normal, the master client should check if it can be re authenticated after power on; If the master client and slave server devices have been successfully bound before, re authentication is not necessary. Under the premise of successful binding, the two stages of certificate verification, DH key exchange, and authentication key verification can be skipped and directly enter the SAC channel establishment process. Otherwise, SAC authentication key generation for identity authentication must be performed first; After the SAC channel is established, the master and slave devices enter the content key establishment process. After the SAC channel and content key are established, the master and slave devices use content key encryption to protect the corresponding business protocol parameters during business operation. If for some reason, such as connection establishment failure or device busy, the protocol runs out of time and SAC or content key cannot be updated in a timely manner, corresponding errors can be prompted to device users or administrators on the industrial site. 5.2.2.2. Certificate and identity authentication mechanism Authentication based on public key certificates includes certificate verification and DH key exchange, as well as verification of intermediate authentication keys. Firstly, the authentication process of the first stage master client and slave server begins by exchanging their respective certificate chains and DH public keys. The master client must verify the certificate chain of the slave server and the checksum generated by the slave server, and similarly, the slave server must verify the certificate chain of the master client and the checksum generated by the master client. During the verification process, the slave server will extract the CLIENT ID (64 bit data) from the master client's public key certificate, and similarly, the master client will also extract the SERVER ID (64 bit data) from the slave server's public key certificate. Then, in the second stage, the data exchanged between the slave server and the master client using the authentication protocol in the first stage can obtain a long-term DH secret key and a long-term authentication key. The authentication key is obtained by calculating the DH secret key and the IDs of both parties. Both parties should store the authentication key in NVM for future Liu, et al. Expires 14 June 2026 [Page 13] Internet-Draft Security Protocol for Modbus Serial Link December 2025 calculation of SAC secure channel encryption key and content key. Afterwards, the slave server will send a request to the master client to confirm the authentication key. Upon receiving the confirmation message, the slave server must compare the received key value with the stored key value. If the two match, it can prove that the master client is legitimate. The steps of the device authentication protocol based on public key certificates are shown in Figure 4, and the message semantics and process are explained as follows: +------------+ +-------------+ |Slave server|<-------------------------------->|Master client| +------------+ +-------------+ -------------------1) ss_open_req()-------------------------> <------------------2) ss_open_cnf()-------------------------- ----------3) ss_data_req(server_dev_cert+server_brand_cert)-> <--4) ss_data_cnf(DHPH+client_dev_cert+client_brand_cert)---- ----------------5) cc_data_req(DHPM+RM)---------------------> <-----------------6) ss_data_cnf(RH)------------------------- --------------------7) ss_data_req(AKH)---------------------> <-------------------8) ss_data_cnf(AKH)---------------------- 9)locally compare AKM=AKH by slave server Figure 4: Authentication Message Exchange process 1. Send ss_open_req APDU from the slave server to the master client. 2. The master client responds with ss_open_cnf APDU. 3. Send ss_data_req APDU from the slave server to the master client. The message contains: 1) Device certificate (Server_dev_Cert) of slave server; 2) Brand certificate (Server_Brand_Cert) of slave server; 3) ID of the requested data type. 4. The master client responds with ss_data_cnf APDU. The message contains: 1) DH public key (DHPH) of master client; 2) Device certificate for master Client (Client_Dev_Cert); 3) Brand certificate (Client_Brand_Cert) of master client. 5. The slave server then sends the ss_data_req APDU. The message contains: 1) DH public key (DHPM) of slave server; 2) Verification value RM; 3) ID of the requested data type. 6. The master client responds with ss_data_cnf APDU. The message contains: 1) A verification value RH. Liu, et al. Expires 14 June 2026 [Page 14] Internet-Draft Security Protocol for Modbus Serial Link December 2025 7. The master client responds with ss_data_cnf APDU. The message contains: 1) The data type ID of the requested AKH. 8. The master client responds with ss_data_cnf APDU. The message contains a AKH, Either it is valid or it is all zero, indicating illegality. 9. The slave server compares the received AKH with the locally calculated AKM. 1) The definition of ss_open_req APDU is as follows: The slave server sends this APDU to inquire about the ID mask of the encryption system supported by the master client. The syntax is shown in Figure 5. +-----------------+----------------------+------------------+ | syntax | No. of bits | Mnemonic | +-----------------+----------------------+------------------+ |ss_open_req() { | | | | ss_open_req_tag | 24 | uimsbf | | length_field()=0| | | |} | | | +-----------------+----------------------+------------------+ Figure 5: ss_open_req APDU syntax 1. ss_open_req_tag: 0x9F 90 01. 2. length_field: The length of the APDU payload, expressed in ASN. 1 BER format. 2) The definition of ss_open_cnf APDU is as follows: The master client sends this APDU to the slave server, notifying them of the encryption system IDs supported by the slave server. The syntax is shown in Figure 6. Liu, et al. Expires 14 June 2026 [Page 15] Internet-Draft Security Protocol for Modbus Serial Link December 2025 +---------------------+----------------------+------------------+ | syntax | No. of bits | Mnemonic | +---------------------+----------------------+------------------+ |ss_open_cnf() { | | | | ss_open_cnf_tag | 24 | uimsbf | | length_field()=0 | | | | ss_system_id_bitmask| 8 | bslbf | |} | | | +---------------------+----------------------+------------------+ Figure 6: ss_open_cnf APDU syntax 1. ss_open_cnf_tag: 0x9F 90 02. 2. ss_system_id_bitmask: Each of the 8 bits indicates the encryption system version supported by a master client. The slave server can choose the highest version supported by both ends. The lowest bit indicates version 1, there is no version 0. The encrypted version defined in this section is 1. ss_system_id_bitmask lowest position 1 (indicating support for version 1). 3) The definition of ss_data_req APDU is as follows: The slave server sends an ss_data.req message to the master client to transmit protocol related data, while requesting a response from the master client. The ss_data_req APDU syntax is shown in Figure 7. ss_data_req APDU is used for data transmission that does not require authentication or encryption. Mainly used for authentication, authentication key verification, and SAC key calculation. Liu, et al. Expires 14 June 2026 [Page 16] Internet-Draft Security Protocol for Modbus Serial Link December 2025 +-------------------------------+----------------------+------------------+ | syntax | No. of bits | Mnemonic | +-------------------------------+----------------------+------------------+ |ss_data_req() { | | | | ss_data_req_tag | 24 | uimsbf | | length_field()=0 | | | | ss_system_id_bitmask | 8 | bslbf | | send_datatype_nbr | 8 | uimsbf | | for (i=0;i|Master client| +------------+ +-------------+ -------------------1) Send the certificate chain---------------> 2) Verify certificate by client locally---- 3) Generate random number DHX by client locally-- 4) Calculate DHPH by client locally--- <--------------------5) Send DHPH and certificate chain--------- ----6) Verify certificate by server locally ----7) Generate random number DHY by server locally ----8) Calculate DHPM by server locally ----9) Calculate DHSK and RMby server locally -------------------10) Send DHPM and RM------------------------> 11) Check parameters by client locally---- 12) Calculate DHSK and RH by client locally-- <----------------------13) Send RH------------------------------ --14) Check parameters and calculate AKM by server locally 15) Calculate AKH by client locally-- -------------------16) Request AKH-----------------------------> <--------------------17) Responds AKH--------------------------- --18) Compare AKM=AKH by server locally Figure 15: Calculation steps involved in the authentication process Liu, et al. Expires 14 June 2026 [Page 24] Internet-Draft Security Protocol for Modbus Serial Link December 2025 1. The slave server sends its public key certificate chain to the master client 2. The master client verifies the validity of the two received certificates from the slave servers. 3. The master client uses an appropriate PRNG to generate a random DH exponent x (DHX). 4. The master client calculates its own DH public key (DHPH). 5. The master client sends the DHPH, master client device certificate, and master client device brand certificate to the slave server. 6. The slave server verifies the validity of the two certificates received from the master client. 7. The slave server generates a random DH exponent y (DHY) using an appropriate PRNG. 8. The slave server computes its own DH public key (DHPM) . 9. The slave server calculates the verification value RM as follows: a) Firstly, use the inverse element MDQ-1 of its private key to calculate xG = E_M(MDQ-1, DHPH); b) Calculate and store DHSK= E_M(y, xG); c) Calculate RM=SM3 (xG||DHPM||DHSK||SERVER ID); Note: E.M (*, *) represents scalar multiplication on an elliptic curve, where the first parameter is an element in a finite field and the second parameter is a point on the elliptic curve. 10. The slave server sends DHPM and RM to the master client. 11. The master client verifies the received parameters as follows: a) Firstly, use the inverse element HDQ-1 of the private key to calculate yG = E_M(HDQ-1, DHPM); b) Calculate and store DHSK = E_M(x, yG); c) Calculate RM '= SM3(xG||DHPM||DHSK||SERVER_ID); d) Verify whether the received RM is consistent with the calculated RM '. Note: E.M (*, *) represents scalar multiplication on an elliptic curve, where the first parameter is an element in a finite field and the second parameter is a point on the elliptic curve. 12. The master client uses the data calculated in steps 4) and 11) to calculate the verification value RH: RH = SM3(yG||DHPH||DHSK||CLIENT_ID). Liu, et al. Expires 14 June 2026 [Page 25] Internet-Draft Security Protocol for Modbus Serial Link December 2025 13. The master client sends RH to the slave server. 14. The slave server verifies the received parameters using the data calculated in steps 7) and 9): a) Calculate RH '= SM3(yG||DHPH||DHSK||CLIENT_ID); b) Verify whether the received RH is consistent with the calculated RH '. The slave server calculates and stores the authentication key (AKM). 15. The master client calculates and stores the authentication key (AKH). 16. The slave server start to enter the second stage of the authentication process: request the current authentication key AKH from the master client through the response APDU. 17. The master client uses the corresponding APDU to send AKH to the slave server. 18. The slave server compares the received AKH with its own calculated AKM. If they are different, it will result in a system error. The DH public keys (DHPH and DHPM) are temporary data that should be cleared and deleted after the authentication protocol is completed. The DH public key is calculated as follows: DHPH＝E_M(x, MDP)，DHPM＝E_M(y, HDP) Note that in the above equation: The values x (DHX) and y (DHY) are generated by the built-in PRNG of the device. The values of x (DHX) and y (DHY) should be kept secret locally and cleared and deleted after the authentication protocol ends. In order to generate secure protocol parameters, after the master client calculates DHPH, the following checks must be performed: DHPH is neither an infinite point nor a generator G, and the value of E-M (EC-N, DHPH) is an infinite point. Similarly, after calculating DHPM from the station server, the following checks must be performed: DHPM is neither an infinite point nor a generator G, and the value of E-M (EC-N, DHPM) is an infinite point. Liu, et al. Expires 14 June 2026 [Page 26] Internet-Draft Security Protocol for Modbus Serial Link December 2025 The authentication keys (AKH and AKM) can be used in the calculation process of SAC keys and CK. The authentication key is generated when the master client and slave server are first bound and stored in NVM, which can be used for repeated authentication in the future. The calculation process is as follows: AKM = AKH = SM3(SERVER_ID||CLIENT_ID||DHSK) The relevant parameter columns are shown in Figure 16. +-----------+----------------+---------------------+ | Parameter | No. of bits | description | +-----------+----------------+---------------------+ |DHSK | 512 | The DH secret key | | | | shared during the | | | | authentication | | | | process. | +-----------+----------------+---------------------+ |CLIENT_ID | 64 | Included in public | | | | key certificate of | | | | the master client | | | | device. | +-----------+----------------+---------------------+ |SERVER_ID | 64 | Included in public | | | | key certificate of | | | | the slaver serve | | | | device. | +-----------+----------------+---------------------+ Figure 16: Parameters in Authentication Key Calculation Authentication context and re-authentication: Authentication context is a secure data object stored in NVM, and its storage format is not strictly defined in this specification. However, in the implementation of actual products, it should be given sufficient security to ensure that it is not changed by attackers. The authentication context is used to store the results of public key authentication between both parties of the device, and is used to perform the re authentication process. The information that should be included in the authentication context of the slave server and master client is shown in Figure 17. Liu, et al. Expires 14 June 2026 [Page 27] Internet-Draft Security Protocol for Modbus Serial Link December 2025 +---------------+----------------+ | Slave server |Master client | +---------------+----------------+ |CLIENT_ID |SERVER_ID | |DHSK |DHSK | |AKM |AKM | |Encryption mode|Encryption mode | +---------------+----------------+ Figure 17: Information in Authentication Context After the master client and slave server are first 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. After establishing a session, the master client and slave server can first perform an authentication key verification step to check if there is an existing binding relationship between the two devices. If there is, there is no need to perform a 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 the local authentication context. If there is inconsistency, the slave server shall attempt up to 246 more times (as the master client may have 247 authentication contexts). When there are no other available authentication contexts for the master client, the master client should send a zero value as a response to the AKH request from the slave server, and the slave server should start executing the public key authentication protocol. If the master client has the authentication context of the slave, it should first send the AKH in the context of the slave. If the AKH is inconsistent with the AKM of the slave server, the slave server should attempt to request AKH again, and the master client should send other AKHs in other authentication contexts. So, re-powering on the slave server may not necessarily execute the public key authentication protocol. But when the slave server accesses an unbound master client, or when the master client accesses an unbound slave server, the identity authentication protocol related to the public key certificate is required to be executed. 5.2.2.3. Establishing secure authentication channel Mechanism After authentication is completed, the protocol will establish a secure authentication channel (SAC), which is mainly used for content key establishment and transmission. Figure 18 is a schematic diagram of its function. Liu, et al. Expires 14 June 2026 [Page 28] Internet-Draft Security Protocol for Modbus Serial Link December 2025 +-------+ +-------+ | SAC | Update and Sync | SAC | ---Key-+ +<------------------------->+ +---Key--- |Control| 1B |Control| +-------+ +-------+ | | | | +---------------+ +---------------+ | Authentication| Secure Auth. Chan. | Authentication| ---Data-+ +<-------------------+ +---Data--- | & Encryption | | & Encryption | +---------------+ +---------------+ Figure 18: Schematic diagram of SAC function Figure 19 shows the workflow of SAC channel establishment, which is describled as follows. +------------+ +-------------+ |Slave server|<-------------------------------->|Master client| +------------+ +-------------+ -------------------1) Authentication Protocol------------------> <------------------2) Authentication Protocol------------------- 3) SAC initialization locally- --4) SAC initialization locally -------------------5) APDU requesting sync---------------------> <------------------6) Confirm sync APDU------------------------- --7) Generate data locally --8) Transmitting data locally --9) Check the status locally --10) Generate message locally ---------------------11) Send a message------------------------> <------------------12) Confirm of received messages------------- 13) Check the status locally-- 14) Processing messages locally-- Figure 19: The workflow of SAC channel establishment 1. 1),2) Authentication protocol. The slave server and master client must have successfully executed the mutual authentication protocol. 2. 3),4) SAC initialization. Both the slave server and the master client need to first perform SAC initialization to generate key data and set the initial state of SAC. Liu, et al. Expires 14 June 2026 [Page 29] Internet-Draft Security Protocol for Modbus Serial Link December 2025 3. 5),6) SAC synchronization request and confirmation. If the slave server has correctly initialized SAC, the slave server should send an APDU requesting synchronization to the master client. After the master client successfully responds, both parties can start using SAC. 4. 7)-11) Generate and send SAC messages. Generate SAC messages by adding message headers and authentication domains to the payload and encrypting them (optional). 5. 12)-14) Receive and verify SAC messages. Validate the received SAC message and proceed with further processing under the condition that the message is valid. Note: SAC can be used for bidirectional sending and receiving of messages; Figure 20 shows the SAC initialization process, which is describled as follows. +------------+ +-------------+ |Slave server|<-------------------------------->|Master client| +------------+ +-------------+ --1) SAC initialization conditions are met --2) Generate Ns_S locally ------------3) ss_data_req (Ns_M+SERVER_ID)------------------> --4) Generate Ns_H locally <------------------5) ss_data_cnf (Ns_H+CLIENT_ID)------------- --6) Export SAK and SEK, reset SAC status locally 7) Export SAK and SEK, reset SAC status--- ---------------------8) ss_sync_req()------------------------> <------------------9)confirm ss_sync_cnf()--------------------- Figure 20: The workflow of SAC channel establishment 1. When the slave server detects that the conditions are met, it initiates the SAC initialization process. 2. The slave server generates a random number Ns_S, which is used as part of the data involved in SAC key calculation. 3. The slave server sends the ss_data_req APDU to the master client, including the following parameters: 1) Ns_M; 2) SERVER_ID. 4. The master client generates a random number Ns_H, which is used as part of the data for SAC key calculation. Liu, et al. Expires 14 June 2026 [Page 30] Internet-Draft Security Protocol for Modbus Serial Link December 2025 5. After receiving the ss_data_req APDU from the slave server, the master client should respond to the slave server with the ss_data_cnf APDU, which includes the following parameters: 1) Ns_H; 2) CLIENT_ID. 6. The slave server checks whether the received CLIENT_ID matches the pre-stored one. If they match, start calculating SAK and SEK and set or reset SAC status. If they do not match, it will cause a system error. Note: The pre-stored SERVER_ID/CLIENT_ID is in the "authentication context". 7. The master client checks whether the received SERVER_ID matches the pre-stored one. If they match, start calculating SAK and SEK and set or reset SAC status. If they do not match, it will cause a system error. Note: The pre-stored SERVER_ID/CLIENT_ID is in the "authentication context". 8. The slave server sends ss_stync_req APDU to the master client to indicate that the master client SAK needs to be refreshed. When the slave server has completed initialization, it will send a synchronization request indicating that the slave server is ready to use SAC. 9. The master client sends ss_sync_cnf APDU to the slave server as a confirmation response, indicating that the master client is also ready to use SAC.Failure to respond to ss_sync_cnf messages will result in a system error. The SAC initialization protocol is initiated by the slave server and passively responded by the master client. This protocol is triggered by the following conditions: 1. Power on restart; After system start-up or restart and there is a valid AKM in NVM. 2. Certification; When there is no valid AKM in NVM, the system will enter the re authentication protocol, and after the authentication protocol is completed, trigger the SAC initialization protocol. 3. Message counter overflow. APDU definition used during SAC initialization process: The definitions of ss_open_req and ss_open_cnf APDU are the same as those in the authentication mechanism in the previous section. 1) ss_sync_req APDU Liu, et al. Expires 14 June 2026 [Page 31] Internet-Draft Security Protocol for Modbus Serial Link December 2025 Used for SAC key calculation, the slave server sends the APDU after the key calculation is completed to indicate that it is ready to use the newly calculated key. The syntax of ss_sync_req APDU is shown in Figure 21. +-----------------+----------------------+------------------+ | syntax | No. of bits | Mnemonic | +-----------------+----------------------+------------------+ |ss_sync_req() { | | | | ss_sync_req_tag | 24 | uimsbf | | length_field()=0| | | |} | | | +-----------------+----------------------+------------------+ Figure 21: ss_sync_req APDU syntax ss_sync_req_tag:0x9F 90 05. 2) ss_sync_cnf APDU This APDU is the response of the master client to the ss_sync_req APDU, indicating that the master client has completed the key calculation. The syntax of the ss_sync_cnf APDU is shown in Figure 22. +---------------------+----------------------+------------------+ | syntax | No. of bits | Mnemonic | +---------------------+----------------------+------------------+ |ss_sync_cnf() { | | | | ss_sync_cnf_tag | 24 | uimsbf | | length_field()=0 | | | | status_field | 8 | uimsbf | |} | | | +---------------------+----------------------+------------------+ Figure 22: ss_sync_cnf APDU syntax ss_sync_cnf_tag: 0x9F 90 06. status_field: This byte returns the status of the master client. Figure 23 lists possible values. Liu, et al. Expires 14 June 2026 [Page 32] Internet-Draft Security Protocol for Modbus Serial Link December 2025 +----------------------+----------------+ | status_field |value | +----------------------+----------------+ |OK |00 | |No resource |01 | |Busy |02 | |Authentication failure|03 | |Reserved |04-FF | +----------------------+----------------+ Figure 23: Possible values of status_field The APDU format of the SAC initialization protocol, which includes specific data types, is shown as below: When the slave server sends SERVER_ID and a random number, ss_data_req APDU is sent with following Parameters in Figure 24. +-------------------------------+----------------------+------------------+ | content | +-------------------------------+----------------------+------------------+ |send _datatype_nbr=2 | +-------------------------------+----------------------+------------------+ | i | datatype_id | datatype_len | +-------------------------------+----------------------+------------------+ | 0 | 2(SERVER_ID) | 64 bits | +-------------------------------+----------------------+------------------+ | 1 | 16(Ns_M) | 64 bits | +-------------------------------+----------------------+------------------+ |request_datatype_nbr=2 | +-------------------------------+----------------------+------------------+ | i | datatype_id | +-------------------------------+----------------------+------------------+ | 0 | 1(CLIENT_ID) | +-------------------------------+----------------------+------------------+ | 1 | 15(Ns_H) | +-------------------------------+----------------------+------------------+ Figure 24: ss_data_req APDU content When the master client responds with CLIENT_ID and a random number, ss_data_cnf APDU is sent with following Parameters in Figure 25. Liu, et al. Expires 14 June 2026 [Page 33] Internet-Draft Security Protocol for Modbus Serial Link December 2025 +-------------------------------+----------------------+------------------+ | content | +-------------------------------+----------------------+------------------+ |send _datatype_nbr=2 | +-------------------------------+----------------------+------------------+ | i | datatype_id | datatype_len | +-------------------------------+----------------------+------------------+ | 0 | 1(CLIENT_ID) | 64 bits | +-------------------------------+----------------------+------------------+ | 1 | 15(Ns_H) | 64 bits | +-------------------------------+----------------------+------------------+ Figure 25: ss_data_cnf APDU content Note: During the secure channel establishment phase, APDU messages will encapsulate the Modbus serial link data unit field with a success code of 0, which is much smaller than 252 bytes (the maximum data field length of a Modbus RTU frame) of APDU. One Modbus serial link message frame can complete the interaction of APDU. The operation process of the master client during SAC initialization is shown as below. 1. Master client receives “Ns_M”. 2. Master client sends “Ns_H”. 3. Master clientcalculates SAK and SEK. 4. Master client receives synchronization request. 5. Master client confirms synchronization and starts using the new SAC key The operation process of the slave server during SAC initialization is shown as below.Note: If the condition in step 6 (or step 9) is not met more than 3 times, it will result in a system error. 1. Start SAC initialization. 2. Set the SAC key update timer to 0 seconds on the slave server. 3. Slave server sends 'Ns_M'. 4. Slave server receives 'Ns_H'. 5. Slave server calculates SAK and SEK. 6. SAC key update timer is not more than 9s? If not, goto step 1). Liu, et al. Expires 14 June 2026 [Page 34] Internet-Draft Security Protocol for Modbus Serial Link December 2025 7. If yes, Slave server sends sync request. 8. Slave server received sync confirmation within 10s? 9. If not, Key update timer is not more than 10s? If not, goto step 1). 10. If yes，Wait for 1 second, goto step 7). 11. Slave server allows SAC operations. 12. Set message counter msg_counter = 1 on the slave server 13. Any messages need to be sent? If not, goto step 13). 14. If yes, msg_counter is overflow? If yes,goto step 1). 15. If not, send a message from the slave server and add msg_counter + 1, goto step 13). Calculating the authentication key SAK and encryption key SEK for SAC requires two steps: 1. Calculation of key seed Ks. 2. Export SAK and SEK. The key seed Ks has a length of 256 bits. The slave server and master client should calculate the value of the key seed, and the master client must use the following method to calculate Ks_client: Ks_client = SM3(DHSK||AKH||Ns_H||Ns_M) The slave server must calculate Ks_server using the following method: Ks_server = SM3(DHSK||AKM||Ns_H||Ns_M) Under normal circumstances, Ks_server = Ks_client, this two keys herein are named Ks, with the parameters shown in Figure 26 Liu, et al. Expires 14 June 2026 [Page 35] Internet-Draft Security Protocol for Modbus Serial Link December 2025 +----------------------+----------------+ | parameter |No. of bits | +----------------------+----------------+ |DHSK |512 | |AKH/AKM |256 | |Ns_H |64 | |Ns_M |64 | +----------------------+----------------+ Figure 26: Parameters in SAC Key Calculation The SAK and SEK exports are calculated as follows: SEK=MSB128(Ks)，SAK=LSB128(Ks) The SAC message format and semantic description are as follows: The data messages transmitted as SAC payloads should be encapsulated in SAC messages, with the encapsulation format shown in Figure 27. +---------------+--------+----------------------+----------+ | Messg. counter| Header | Payload | MAC | +---------------+--------+----------------------+----------+ +<----overhead---------->+<------Encryption (optional)---->+ Figure 27: SAC packaging payload The specific definition of SAC message syntax is shown in Figure 28. Liu, et al. Expires 14 June 2026 [Page 36] Internet-Draft Security Protocol for Modbus Serial Link December 2025 +-------------------------------+----------------------+------------------+ | syntax | No. of bits | Mnemonic | +-------------------------------+----------------------+------------------+ |message() { | | | | message_counter | 32 | uimsbf | | /* Message header start */ | | | | protocol_version | 4 | uimsbf | | authentication_cipher_flag | 3 | uimsbf | | payload_encryption_flag | 1 | bslbf | | encryption_cipher_flag | 3 | uimsbf | | reserved_for_future_use | 5 | bslbf | | length_payload | 16 | uimsbf | | /* Message header end */ | | | | /* Message body start */ | | | |if (payload_encryption_flag == | | | | MSG_FLAG_TRUE) { | | | | encrypted_payload |length_payload * 8+128| bslbf | | }elif (payload_encryption_flag| | | | == MSG_FLAG_FALSE) { | | | | payload | length_payload * 8 | bslbf | | authentication | 128 | bslbf | | } | | | | /* Message body end */ | | | |} | | | +-------------------------------+----------------------+------------------+ Figure 28: SAC message syntax Encoding and semantics of fields in SAC messages: 1. message_comounter: Data messages require a count value to identify the number of messages that have been transmitted. 2. protocol version: In this section, set to 0x0. 3. authentication_cipher_flag: This parameter specifies the algorithm that generates the authentication code, currently only 0x0 is valid, means AES-128-XCBC-MAC, other values are reserved. 4. payload_decryption-flag: This parameter indicates whether the payload is encrypted. '1' indicates encryption, '0' indicates no encryption. Devices that comply with this section are explained as "1" and other unsupported values are ignored. 5. encryption_cipher_flag: This parameter indicates the encryption algorithm, currently only 0x0 is valid, means AES-128, CBC mode, other values are reserved. Liu, et al. Expires 14 June 2026 [Page 37] Internet-Draft Security Protocol for Modbus Serial Link December 2025 6. length_payload: This parameter represents the number of bytes in the payload, including padding data but not the number of bytes in the authentication code. 7. encrypted_payload: This field consists of encrypted data, including ciphertext for message payload, padding data, and authentication code. 8. payload: This field is composed of unencrypted data. 9. authentication: This field carries the authentication code for the data, which can be encrypted according to the indication of "payload_encryption_flag". The data message submitted for SAC transmission when sending SAC messages should be processed according to the following steps: 1. Check if 'message_counter' overflows and update 'message_counter'. 2. Calculate the message authentication code. 3. If encryption is required, concatenate the authentication code and payload to encrypt the message (optional). 4. Construct SAC messages. 5. Transmitting messages. If any step of the above process fails, the message and status (such as key set, counter, etc.) should be destroyed and an error generated. The authentication code for SAC data messages is calculated as follows: authentication = MAC{SAK}(length(header_hi)||i||header_hi||payload_pi) Where: 1. MAC - The algorithm is identified by "authentication_cipher_flag"; 2. SAK - is a 128 bit SAC authentication key; Authentication code calculation is specific to the entire message, with parameters shown in Figure 29. Liu, et al. Expires 14 June 2026 [Page 38] Internet-Draft Security Protocol for Modbus Serial Link December 2025 +-----------+----------------+---------------------+ | Parameter | No. of bits | Mnemonic | +-----------+----------------+---------------------+ |length_hi | 8 | uimsbf | +-----------+----------------+---------------------+ |i | 32 | uimsbf | +-----------+----------------+---------------------+ |header_hi | length_hi * 8 | bslbf | +-----------+----------------+---------------------+ |payload_pi |length_payload*8| bslbf | +-----------+----------------+---------------------+ Figure 29: Parameters in MAC Calculation 1. i: This field is the 'message_counter' in the data message. 2. length_hi: This field is the number of bytes in the message header. 3. header_hi: This field represents the message header. 4. d) payload_pi: This domain carries the message payload. The original unencrypted payload. If SAC messages need to be encrypted, the following method should be used: encrypted_payloadi = E{SEK, SIV}(payload_pi||authentication_ai) Where: 1. E - The encryption algorithm indicated by encryption_cipher_flag; 2. SEK -128 bit encryption key; 3. SIV - a fixed constant with a value of 0xB27097DEAF305D8A94C871D89525C7A0; 4. authentication_ai - This value is the authentication code MAC. If the length of payload_pi is not an integer multiple of 128 bits, it should be padded with a "1" first, followed by several "0s" so that the padded result is an integer multiple of 128 bits. If the payload is not encrypted, it will not be filled. SAC message reception should be processed according to the following steps: Liu, et al. Expires 14 June 2026 [Page 39] Internet-Draft Security Protocol for Modbus Serial Link December 2025 1. Firstly, check if the message contains the correct "message_counter" and "protocol-version"; 2. If 'payload_encryption-flag'=1, decrypt the message payload; 3. Calculate the message authentication code and verify the integrity of the message. If any step of the above process fails, the message and status (such as the key set, counter, etc.) should be destroyed and an error should be generated. Both the slave server and the master client should maintain a message counter (message_counter) locally to identify the number of messages that have been transmitted. The initial value of this counter is 0x01 (not 0x00), and every time a SAC message is sent or received, the counter value is incremented by 1. In the current counter value state, if a message needs to be sent, assign the current value of the counter to the "message_counter" field in the SAC message being sent. After the message is sent, increment the counter value by 1. In the current counter value state, if a message is received, the value of the "message_counter" field in the received SAC message should be the same as the current value of the counter. After receiving the message, the counter value needs to be incremented by 1. The receiving device should not receive messages with incorrect counter values. Incorrect counter values will result in a 'message sequence error'. When the value of the message sending counter of the slave server overflows (reaching 232), the slave server should stop using the current SAC key and start negotiating a new SAC key. The decryption process of SAC data messages is as follows: payload_pi || authentication_ai = D{ SEK, SIV}( encrypted_payloadi) Where: 1. D - the algorithm indicated by "encryption_cipher_flag"; 2. SEK -128 bit key; 3. SIV - a fixed constant with a value of 0xB27097DEAF305D8A94C871D89525C7A0; Among them, 'authentication_ai' should be separated from 'payload_pi'. If 'payload_pi' is not an integer multiple of the 128 bit packet, then the message is obtained by padding a '1' and several '0s'. If the payload is not encrypted, there is no need to fill in any data. Liu, et al. Expires 14 June 2026 [Page 40] Internet-Draft Security Protocol for Modbus Serial Link December 2025 The SAC data message contains an authentication domain, and its verification process is as follows: authentication_ai’ = MAC{SAK}(length(header_hi)||i||header_hi||payload_pi) Where: 1. MAC - The algorithm is identified by "authentication_cipher_flag"; 2. SAK -128 bit SAC authentication key. If the calculated 'authentication_ai' is not equal to the 'authentication_ai' exported from the message, the received message must be deleted and a 'message validation error' generated. Note: The design of SAC channels can be used for various purposes, mainly for negotiating and updating content keys. The way SAC messages are encapsulated into Modbus serial link data unit fields with function code 0 in Figure 30. The packaging steps is given as follows Since SAC is mainly used to synchronize and update CK content key data in this specification, as detailed in the next chapter, one Modbus serial link data unit can be sent completely in one message. +--------------------------------------------------------+ | Any secret data (e.g. Content key object) | +--------------------------------------------------------+ | V +-------------+----------------------+---------+------+ | SAC Header | payload | padding | MAC | +-------------+----------------------+---------+------+ | | | | | | | | | | | | | | | | | | | | | V V V +--------+--------+----------+------------------+ |APDU tag|APDU tag|SAC Header|Encrypted SAC data| +--------+--------+----------+------------------+ Figure 30: SAC message encapsulation 1. The system collects data objects to form SAC payloads Liu, et al. Expires 14 June 2026 [Page 41] Internet-Draft Security Protocol for Modbus Serial Link December 2025 2. System calculates message authentication code 3. The SAC payload and authentication code are encrypted. Add SAC header, APDU tag, and APDU length field before the encrypted SAC data 5.2.2.4. Content Key Update Mechanism The process of the content key CK update protocol is shown in Figure 31, and the its description is shown as follows +------------+ +-------------+ |Slave server|<-------------------------------->|Master client| +------------+ +-------------+ --1) CK needs to be updated --2) Generate Kp locally --3) Export CIV and CK, BCIV and BCK locally ------------4) ss_sac_data_req(Kp+SERVER_ID)------------------> --5) Verify the SERVER_ID, generate Kp_client locally <----6) ss_sac_data_cnf(CLIENT_ID+Kp_client+status)------------- --7) Verify CLIENT_ID locally ---8) Export CIV and CK locally ---------------------9) ss_sac_sync_req()---------------------> <------------------10) ss_sac_sync_cnf (status)---------------- Figure 31: The CK Content Key Update Process 1. When the slave server detects the need for CK update, the slave server begins the CK update process. 2. The slave server generates a 256 bit nonce and calculates Kp=SM3 (nonce). 3. The slave server can immediately start calculating CIV and CK. 4. The slave server sends an ss_sac_data_req APDU containing the following parameters： 1) Kp； 2) SERVER_ID； 5. The master client checks that the received SERVER_ID matches the one in "authentication context". If they are consistent, the master client starts calculating CIV and CK, BCIV and BCK; If there is inconsistency, it will result in a system error. Note: The pre stored SERVER_ID/CLIENT_ID is in the "authentication context". Liu, et al. Expires 14 June 2026 [Page 42] Internet-Draft Security Protocol for Modbus Serial Link December 2025 6. The master client generates a 256 bit nonce and calculates Kp_client = SM3 (nonce). Respond to ab ss_sac_data_cnf APDU containing CLIENT_ID and Kp_client. Failure to respond to this message will result in a system error. 7. The slave server checks that the received CLIENT_ID matches the one in "authentication context". If they are consistent, the slave server starts calculating CIV and CK; If there is inconsistency, it will result in a system error. Note: The pre stored SERVER_ID/CLIENT_ID is in the "authentication context". 8. The master client calculates CIV and CK, while the slave server calculates BCIV and BCK. 9. The slave server sends an ss_sac_sync_req APDU to the master client to indicate content key updates. When the slave server completes the initialization of the encryption process, it sends a synchronization request to the master client, informing them that the slave server is ready to use the new CK and BCK. 10. The master client responds with an ss_stac_sync_cnf APDU and confirms to the slave server that the master client is also ready to use the new CK and BCK. Failure to respond to this message will result in a system error. The update of content key CK is mainly initiated by the slave server, and the master client only passively responds. This process is optional, and the content key CK update protocol is triggered by any of the following conditions: 1. After successful completion of authentication and SAC initialization. 2. Periodic triggering (maximum key lifecycle parameter). 3. The group counter has reached its upper limit. 4. Every time it restarts. APDU definition used in the content key update protocol process: 1) ss_sac_data_req APDU Liu, et al. Expires 14 June 2026 [Page 43] Internet-Draft Security Protocol for Modbus Serial Link December 2025 The slave server uses this APDU to send protocol specific data to the master client, while requesting a response. The syntax of ss_sac_data_req APDU is shown in Table 25. Unlike ss_data_req APDU, the data contained in this message is authenticated and encrypted. SAC uses the input data in Figure 32 as the payload in the SAC message. +---------------------+----------------------+------------------+ | syntax | No. of bits | Mnemonic | +---------------------+----------------------+------------------+ |ss_sac_data_req() { | | | | ss_sac_data_req_tag | 24 | uimsbf | | length_field()=0 | | | | sac_message() | | | |} | | | +---------------------+----------------------+------------------+ Figure 32: ss_stac_data_req APDU syntax ss_sac_data_req_tag: 0x9F 90 07. sac_message: The format of this message was defined in the previous section,payload_encryption-flag should be 1. The definition of the payload of SAC messages is in Figure 33. +-------------------------------+----------------------+------------------+ | syntax | No. of bits | Mnemonic | +-------------------------------+----------------------+------------------+ | ss_system_id_bitmask | 8 | bslbf | | send_datatype_nbr | 8 | uimsbf | | for (i=0;it>10? if not, goto step 1) 16. Stop receiving data, goto step 14) 17. Slave server can receive data. 18. Set the block counter to 1. 19. Key lifetime exhausted? if yes, goto step 1) 20. block counter overflow? if yes, goto step 1) else got step 19) Note: The key update timer is used to record the calculation time of the new CK. Note: The maximum key lifecycle value is controlled by the administrator configuration system and is not within the scope specified in this specification. The decrease of this value is controlled by the slave server and only decreases when encrypting or decrypting content. For ease of processing, it is generally defined by the number of messages. So when CK is not in use, this value is not updated. Note: The default upper limit of the block counter is 232, and the message may be divided into multiple block frames. The CK block counter limit is the number of processed crypto blocks since CK refresh. The number of block limit defined here is configured by the system and is not within specified in this specification. Liu, et al. Expires 14 June 2026 [Page 49] Internet-Draft Security Protocol for Modbus Serial Link December 2025 Note: The initial key lifecycle refers to the first key lifecycle after SAC initialization. The CK update operation on the master client side is shown as below, and the broadcast content key BCK can be generated along with it. 1. Waiting for the key update from the slave server. 2. Receive Kp. 3. Confirm. 4. Calculate CIV and CK, BCK and CIV. 5. Receive sync request. 6. Confirm the sync request and start using the new CK. The calculation process of content key CK and broadcast content key BCK should be completed as follows: The encryption algorithm requires CK and CIV, and the calculation of these two values requires two steps: key seed calculation and CK and CIV export. Step 1: Calculate the key seed. Kp = SM3(nonce) Step 2: Export CK and CIV. CK = MSB128(SM3(Kp||SERVER_ID)), CIV = LSB128(SM3(Kp||SERVER_ID)) Step 3: Export BCK and CIV for broadcast communication between the master client and all slave servers. BCK = MSB128(SM3(Kp_client||CLIENT_ID)), BCIV = LSB128(SM3(Kp_client||CLIENT_ID)) Where: SERVER_ID represents the ID of the slave server, while CLIENT_ID represents the ID of the master client. CIV remains unchanged throughout each key lifecycle. CIV and CK change simultaneously. The current CIV is reused at the beginning of encrypting (decrypting) each Modbus data frame. During broadcast communication, BCK and BCIV should be changed simultaneously. Generally, after power on, the BCK and BCIV of all slave servers can remain unchanged, or they can be Liu, et al. Expires 14 June 2026 [Page 50] Internet-Draft Security Protocol for Modbus Serial Link December 2025 updated by the master station through the SAC content key update protocol. The process of updating BCK protocol is shown as follows separately. 1. The master client generates a 256 bit nonce and calculates Kp_client=SM3 (nonce). 2. The master client can immediately start calculating BCIV and BCK.. 3. The master client sends an ss_sac_data_req APDU containing the following parameters to the slave server: 1) Kp_client； 2) CLIENT_ID； 4. The slave server checks the consistency between the received CLIENT_ID and the "authentication context". If they are consistent, calculate BCIV and BCK from the site server; If there is inconsistency, it will result in a system error. Note: The pre-stored SERVER_ID/CLIENT_ID is in the "authentication context". 5. The slave server responds with an ss_sac_data_cnf APDU containing the SERVER_ID. Failure to respond to messages will result in a system error. 6. The master client checks that the received SERVER ID matches the 'authentication context'. If the SERVER_ID returned by the main client is incorrect, a system error will be returned. 7. The master client sends an ss_sac_sync_deq APDU to indicate BCK updates. When the slave server completes the initialization of the encryption process, it sends a synchronization request to the master client, informing them that the slave server is ready to use the new CK and BCK. 8. The slave server responds with the ss_sac_sync_cnf APDU and confirms to the slave server that the master client is also ready to use the new CK and BCK. Failure to respond to this message will result in a system error. The APDU format of the protocol that includes specific data types during the separate update process of BCK broadcast content keys is shown in Figure 41 below: When the master client sends a CLIENT_ID and a random number to the slave server, ss_sac_data_req APDU is sent with following Parameters in Figure 41. Liu, et al. Expires 14 June 2026 [Page 51] Internet-Draft Security Protocol for Modbus Serial Link December 2025 +-------------------------------+----------------------+------------------+ | content | +-------------------------------+----------------------+------------------+ |send _datatype_nbr=2 | +-------------------------------+----------------------+------------------+ | i | datatype_id | datatype_len | +-------------------------------+----------------------+------------------+ | 0 | 2(CLIENT_ID) | 64 bits | +-------------------------------+----------------------+------------------+ | 1 | 7(Kp_client) | 256 bits | +-------------------------------+----------------------+------------------+ |request_datatype_nbr=2 | +-------------------------------+----------------------+------------------+ | i | datatype_id | +-------------------------------+----------------------+------------------+ | 0 | 1(SERVER_ID) | +-------------------------------+----------------------+------------------+ | 1 | 20(Status_field) | +-------------------------------+----------------------+------------------+ Figure 41: ss_sac_data_req APDU content When the slave server responds with the SERVER_ID and status information, ss_sac_data_cnf APDU is sent with following Parameters in Figure 42. +-------------------------------+----------------------+------------------+ | content | +-------------------------------+----------------------+------------------+ |send _datatype_nbr=2 | +-------------------------------+----------------------+------------------+ | i | datatype_id | datatype_len | +-------------------------------+----------------------+------------------+ | 0 | 1(SERVER_ID) | 64 bits | +-------------------------------+----------------------+------------------+ | 1 | 20(Status_field) | 8 bits | +-------------------------------+----------------------+------------------+ Figure 42: ss_sac_data_cnf APDU content Note: During the content key update phase, APDU messages will encapsulate the Modbus serial link data unit field with function code 0, which is much smaller than 252 bytes (the maximum data field length of a Modbus RTU frame) of APDU. One Modbus serial link message frame can complete the interaction of APDU. Liu, et al. Expires 14 June 2026 [Page 52] Internet-Draft Security Protocol for Modbus Serial Link December 2025 5.2.2.5. Content Encryption and Decryption Mechanism After the authentication channel is established and the content keys BCK and CK are synchronized, when transmitting the encrypted Modbus serial link protocol, the encrypted content includes the original Modbus serial link protocol function code and data fields. The encryption mechanism for unicast and broadcast is the same. Taking unicast communication as an example, the content encryption and decryption methods are GCM Mode of symmetric cryptography algorithm such as AES GCM and SM4 GCM. The content encryption method has the following input parameters: CIV, CK, Mode, Modbus serial link protocol function code and data. Among them, CIV and CK are secret data shared by the master client and slave server after executing the content key update protocol. CIV is the CTR in the algorithm, CK is the content key, and Mode is the encryption and decryption mode agreed upon by both parties during the first binding. Currently, only AES GCM and SM4 GCM modes are supported (mode=aes_gcm or sm4_gcm, indicated by the "encryption_capability" field in the device's public key certificate). The plaintext groups P1, P2, P3, P4, ..., Pn are 128 bit slice groups of data from the function and data fields in the original Modbus PDU, and those that are less than 128 bits long are filled with 0. 128 bit integer, with additional message taken from the first 128 bits of SM3 (“Modbus”). during decryption, C1, C2, C3, C4,..., Cn represent ciphertext, and the additional information takes the first 128 bits of SM3 ("Modbus"). The receiver should first calculate and generate a MAC' using a similar encryption mechanism, and then compare it with the received MAC value to see if they are same. If they are the same, the plaintext of the content should be decrypted. Otherwise, it should be considered that there is an abnormality in the current serial communication bus network, such as the possibility of a man in the middle attack. The encrypted Modbus security protocol data field content should be transmitted in the following APDU format, with the encapsulation method shown in Figure 43. The implementation principle of ASCII transmission mode is similar, and not repeated here: The data content of Modbus security protocol is sent through ss_data_snd APDU, and the syntax of ss_data_snd APDU is shown in Figure 44. Liu, et al. Expires 14 June 2026 [Page 53] Internet-Draft Security Protocol for Modbus Serial Link December 2025 +------------------------+----------------------+------------------+ | syntax | No. of bits | Mnemonic | +------------------------+----------------------+------------------+ | ss_data_send() { | | | | ss_data_send_tag | 24 | uimsbf | | length_field() | 8 | | | MAC | 128 | bslbf | | encrypted_fun_code_data| 8*length | bslbf | |} | | | +------------------------+----------------------+------------------+ Figure 43: ss_data_snd APDU syntax ss_open_send_tag: 0x9F 90 11. +-------+----------------------+------------------+------+ | Addr. | Func. code | Data | CRC | +-------+----------------------+------------------+------+ | 1B | 1B | 0-252B | 2B | +-------+----------------------+------------------+------+ | | | | | | | | +-------+------------+---------V---------V--------+---+ | Addr. | Func. code | protocol data. |CRC| +-------+------------+----------------------------+---+ | 1B | 1B (0) | ss_data_send_tag, |2B | | | |length, MAC(20 bytes header)| | | | |encrypted_fun_code_data | | +-------+------------+----------------------------+---+ Figure 44: Modbus encrypted content encapsulation 5.2.3. Modbus Serial Link Security Protocol Based on Password or Pre- Shared Key The key management in the Modbus serial link security protocol based on passwords or pre-shared keys relies on hardware protection. The goal of the protocol is to provide strong security on the basis of low entropy passwords, allowing master-slave devices to negotiate and obtain the same content key while resisting command or key guessing attacks. This type of protocol is suitable for use in factories and equipment with general value and security. The pre-shared key or password requires a trusted and secure execution environment protection, which shall ensure the security of user passwords or shared keys during device operation and prevent them from being stolen by malicious third parties. This model is relatively simple and can be divided into three levels: password or shared key storage level, authentication level, and content encryption level. Liu, et al. Expires 14 June 2026 [Page 54] Internet-Draft Security Protocol for Modbus Serial Link December 2025 5.2.3.1. Key hierarchy structure The password or pre-shared key storage hierarchy should include protocol public parameters, pre shared passwords or keys for the master client and slave server. The key data at this level is mainly used to execute authentication protocols. The pre-shared keys after device initialization cannot be changed or replaced, nor can they be obtained by unauthorized users. The definition of protection methods for these data is not within the scope of this specification. At the authentication level, the master client and slave server mainly verify each other's identity through cryptographic protocols based on shared passwords or keys, and generate temporary content keys CK and an initial vector CIV for use by the content encryption layer. For the generated intermediate keys or state values, there should be a trusted execution environment to ensure security. The protection methods for these intermediate keys or state values are not within the scope of this specification. In password or pre- shared key based schemes, each party in the master-slave device combines its own password or pre shared key based value and private key with the other party's public key to obtain one or more identical keys. Other (public or private) information known to both the master and slave devices can also be used as key derivation parameters to participate in content key generation. If all parties use the same password or pre shared key and the same key derivation parameters, the protocol will ensure that all parties will receive the same content key, allowing both parties to export the shared key with only the password or pre shared key. It should be ensured that without using the password or pre shared key, neither party can successfully participate in the protocol and obtain the same content key. The content encryption layer uses the content key CK and an initial vector CIV to encrypt and decrypt the media stream using AES/SM4. For the data encryption and decryption process of Modbus serial link communication protocol, there should be a trusted execution environment or hardware to ensure security. The definition of specific protection methods is not within the scope of this specification. 5.2.3.2. Authentication and Key Agreement Mechanism This specification is based on the Modbus serial link security protocol using passwords or pre shared keys, and is based on the SM2 elliptic curve public key cryptography algorithm Part 3 Key Exchange Protocol standard developed by ISO/IEC 14888-3:2018 and China National Cryptography Administration. In this specification, the private key of the master and slave devices should be derived from a shared password or key. Assuming that the password or key shared by Liu, et al. Expires 14 June 2026 [Page 55] Internet-Draft Security Protocol for Modbus Serial Link December 2025 the master/slave devices is represented as PW, the temporary private key of the device must be generated as follows: The master/slave devices first respectively select a random number r and calculate the 32-bit byte string PW_r=SM3 (PW||r). By converting it into an element under the field F_q of ECC, the private key d_A is obtained, and the public key P_A=[d_A] G=(x_A, y_A) is calculated. Assuming that the public and private key pairs of the master/slave devices are d_H/P_H, d_M/P_M, respectively. The authentication and content key negotiation mechanism is shown as below. For master client, the raw data generated and configured by the host client are (ECC system parameters, Z_H, Z_M, d_H, P_H, P_M) and a 128bit random number r_nonce is selected to generate the broadcast key and encryption/decryption mode. 1. Generate random number r_H ∈ [1, n-1]. 2. Calculate R_H=[r_H] G=(x_1, y_1). 3. Send R_H, mode to the slave server. 4. Calculate X_1=2^w+(X_1 AND(2^w-1)). 5. Calculate t_H=（d_H+X_1*r_H）Mod n. 6. Receivce R_M, S_M from the slave server, does R_M satisfy the curve equation? If not, Content key negotiation failed. 7. Calculate X_2=2^w+(x_2 AND (2^w-1)). 8. Calculate ECC pointU = [h*t_H](P_M+[X_2]R_M)=(x_u,y_u). 9. U=O? If yes, Content key negotiation failed. 10. Calculate K_H=KDF(PW||x_u||y_u||Z_H||Z_M,256). 11. Calculate S_1=SM3(0x02||PW||y_u||Hash(x_u||Z_H||Z_M||x_1||y_1||x _2||y_2||||r_B)). 12. S_1=S_M？ If not, Content key negotiation failed. 13. Calculate S_H=SM3(0x03||PW||y_u||Hash(x_u||Z_H||Z_M||x_1||y_1||x _2||y_2)||r_B), r_B=MSB128(K_H)⊕r_nonce, Sends S_H, r_B to Slave server. 14. Calculate CK=MSB128(K_H), CIV=LSB128(K_H). Liu, et al. Expires 14 June 2026 [Page 56] Internet-Draft Security Protocol for Modbus Serial Link December 2025 15. Calculate BCK=MSB128(SM3(r_nonce||PW)), BCIV=LSB128(SM3(r_nonce||PW)). For slave server, the raw data generated and configured are (elliptic curve system parameters, Z_H, Z_M, d_M, P_M, P_H). 1. Generate random number r_M ∈ [1, n-1]. 2. Calculate R_M=[r_M] G=(x_2, y_2). 3. Take X_2=2 ^ w+(x_2 AND (2 ^ w-1)). 4. Calculate t_M=(d_M+X_2 * r_M) mod n. 5. Receivce R_H, mode from the slave server, Does R_H satisfy the curve equation? If not, Content key negotiation failed. 6. Calculate X_1=2^w+(x_1 AND (2^w-1)). 7. Calculate ECC point V = [h*t_M](P_H+[X_1]R_H)=(x_v,y_v). 8. V=O？ If yes, Content key negotiation failed. 9. Calculate K_M=KDF(PW||x_v||y_v||Z_H||Z_M,256). 10. Calculate S_M=SM3(0x02||PW||y_v||Hash(x_v||Z_H||Z_M||x_1||y_1||x _2||y_2||||r_B)). 11. Sends R_M、S_B to Master client. 12. Calculate S_2=SM3(0x03||PW||y_v||Hash(x_v||Z_H||Z_M||x_1||y_1||x _2||y_2||r_B)). 13. Receive S_H, r_B from the master client,S_2=S_H？ If not, Content key negotiation failed. 14. The CK confirmation from the Master client to the slave server has been successful, Calculate CK=MSB128(K_M),CIV=LSB128(K_M), r_nonce=MSB128(K_M)⊕r_B, BCK=MSB128(SM3(r_nonce||PW)), BCIV=LSB128(SM3(r_nonce||PW)). The encryption algorithm mode is determined by an 8-bit mode and currently only supports AES GCM mode aes_gcm or SM4 GCM mode sm4_gcm. The steps of Modbus serial link security protocol based on password or pre-shared key are shown in Figure 45 and described as below: Liu, et al. Expires 14 June 2026 [Page 57] Internet-Draft Security Protocol for Modbus Serial Link December 2025 +------------+ +-------------+ |Slave server|<-------------------------------->|Master client| +------------+ +-------------+ ------------1) ss_open_req()----------------------------------> <------------2) ss_open_cnf()---------------------------------- ---------------------3) ss_data_req(R_H+mode)-----------------> <------------------4) ss_data_cnf(R_M+S_M)--------------------- ---------------------5) cc_data_req(S_H+r_B)------------------> <------------------6) ss_data_cnf()---------------------------- Figure 45: Content key negotiation message exchange based on password or pre-shared key 1. The master client sends the ss_sk_open_req APDU to the slave server. 2. The slave server responds with ss_sk_open_cnf APDU. 3. The master client sends the ss_sk_data_req APDU to the slave server. The message contains: 1) The master client selects the ECC point (R_H) as needed; 2) Encryption and decryption mode; 3) The ID of the requested data type. 4. The slave server responds with ss_sk_data_cnf APDU. The message contains: 1) The slave server selects ECC points (R_M) as needed; 2) Message authentication code (S_M) of the slave server; Failure to respond to this message may result in a system error, possibly due to the master client being unable to verify data from the slave server. 5. The master client then sends the ss_sk_data_req APDU. The message contains: 1) The message authentication code (S_H) of the master client; 2) Random number (r_B) used to generate broadcast content keys； Failure to respond to this message may result in a system error, possibly due to the slave server being unable to verify data from the master client. 6. The slave server responds with ss_sk_data_cnf APDU. The inability to respond to this message may result in a system error, possibly due to the inability of the master client to verify data from the slave server. The format definitions of ss_sk_open_req, ss_sk_open_cnf, ss_sk_data_req, and ss_sk_data_cnf APDU are the same as those of the previous ss_open_req, ss_open_cnf, ss_data_req, and ss_data_cnf APDU, respectively. But the tag types are different to distinguish different serial link content encryption mechanisms. Liu, et al. Expires 14 June 2026 [Page 58] Internet-Draft Security Protocol for Modbus Serial Link December 2025 ss_sk_open_req(tag=0x9F 90 12), ss_sk_open_cnf(tag=0x9F 90 13), ss_sk_data_req(tag=0x9F 90 14), ss_sk_data_cnf(tag=0x9F 90 15), The APDU format for protocols based on passwords or pre-shared keys that include specific data types is shown as below: When the master client sends a ECC random point, a random number, and encryption/decryption mode to the slave server, ss_sk_data_req APDU is sent with following Parameters in Figure 46. +-------------------------------+----------------------+------------------+ | content | +-------------------------------+----------------------+------------------+ |send _datatype_nbr=2 | +-------------------------------+----------------------+------------------+ | i | datatype_id | datatype_len | +-------------------------------+----------------------+------------------+ | 0 | 22(R_H) | 512 bits | +-------------------------------+----------------------+------------------+ | 1 | 24(mode) | 8 bits | +-------------------------------+----------------------+------------------+ |request_datatype_nbr=2 | +-------------------------------+----------------------+------------------+ | i | datatype_id | +-------------------------------+----------------------+------------------+ | 0 | 22(R_M) | +-------------------------------+----------------------+------------------+ | 1 | 25(S_M) | +-------------------------------+----------------------+------------------+ Figure 46: ss_sk_data_req APDU content When sending response ECC random point and authentication code from the slave server, ss_sk_data_cnf APDU is sent with following Parameters in Figure 47. +-------------------------------+----------------------+------------------+ | content | +-------------------------------+----------------------+------------------+ |send _datatype_nbr=2 | +-------------------------------+----------------------+------------------+ | i | datatype_id | datatype_len | +-------------------------------+----------------------+------------------+ | 0 | 22(R_M) | 512 bits | +-------------------------------+----------------------+------------------+ | 1 | 25(S_M) | 256 bits | +-------------------------------+----------------------+------------------+ Figure 47: ss_sk_data_cnf APDU content Liu, et al. Expires 14 June 2026 [Page 59] Internet-Draft Security Protocol for Modbus Serial Link December 2025 When the master client sends a message authentication code, ss_sk_data_req APDU is sent with following Parameters in Figure 48. +-------------------------------+----------------------+------------------+ | content | +-------------------------------+----------------------+------------------+ |send _datatype_nbr=2 | +-------------------------------+----------------------+------------------+ | i | datatype_id | datatype_len | +-------------------------------+----------------------+------------------+ | 0 | 9(S_H) | 256 bits | +-------------------------------+----------------------+------------------+ | 1 | 23(r_B) | 256 bits | +-------------------------------+----------------------+------------------+ Figure 48: ss_sk_data_req APDU content 5.2.3.3. Content Encryption and Decryption Mechanism The content encryption and decryption mechanism used in this section is the same as that in previous section. 6. Appendix A Parameter datatype id table exchanged in APDU. Table A.1 summarizes the parameters and data type ID number used in this draft recommendation. Table A.1: System parameter numbers in secure communication protocol calculation +-------------------------+--------------+-------------+ | Keywords or variables | No, of bits | datatype id | +-------------------------+--------------+-------------+ | CLIENT_ID | 64 | 1 | +-------------------------+--------------+-------------+ | SERVER_ID | 64 | 2 | +-------------------------+--------------+-------------+ | Client_Brand_Cert | variable | 3 | +-------------------------+--------------+-------------+ | Server_Brand_Cert | variable | 4 | +-------------------------+--------------+-------------+ | Reserved | -- | 5 | +-------------------------+--------------+-------------+ | Reserved | -- | 6 | +-------------------------+--------------+-------------+ | Kp | 256 | 7 | +-------------------------+--------------+-------------+ | DHPH | 512 | 8 | +-------------------------+--------------+-------------+ | DHPM | 512 | 9 | Liu, et al. Expires 14 June 2026 [Page 60] Internet-Draft Security Protocol for Modbus Serial Link December 2025 +-------------------------+--------------+-------------+ | Client_dev_Cert | variable | 10 | +-------------------------+--------------+-------------+ | Server_dev_Cert | variable | 11 | +-------------------------+--------------+-------------+ | RM(Signature_A) | 256 | 12 | +-------------------------+--------------+-------------+ | RH(Signature_B) | 256 | 13 | +-------------------------+--------------+-------------+ | auth_nonce | 256 | 14 | +-------------------------+--------------+-------------+ | Ns_H | 64 | 15 | +-------------------------+--------------+-------------+ | Ns_M | 64 | 16 | +-------------------------+--------------+-------------+ | AKH | 256 | 17 | +-------------------------+--------------+-------------+ | AKM | 256 | 18 | +-------------------------+--------------+-------------+ | Reserved | - | 19 | +-------------------------+--------------+-------------+ | status_field | 8 | 20 | +-------------------------+--------------+-------------+ | Reserved | - | 21 | +-------------------------+--------------+-------------+ | R_H/R_M | 512 | 22 | +-------------------------+--------------+-------------+ | r_B | 256 | 23 | +-------------------------+--------------+-------------+ | mode | 8 | 24 | +-------------------------+--------------+-------------+ | S_M/S_H | 256 | 25 | +-------------------------+--------------+-------------+ 7. Appendix B Pseudo-random number generator. The random numbers generated by the pseudo-random number generator PRNG in this draft recommendation are shown in Table B.1. Liu, et al. Expires 14 June 2026 [Page 61] Internet-Draft Security Protocol for Modbus Serial Link December 2025 Table B.1: Parameters for Using Pseudo Random Number Generator +-------------------------+--------------+-----------------------+ | random number | No, of bits | description | +-------------------------+--------------+-----------------------+ | DHX | 256 | DH exponent "x" | +-------------------------+--------------+-----------------------+ | DHY | 256 | DH exponent "y" | +-------------------------+--------------+-----------------------+ | Kp | 64 | Used to establish SAC | +-------------------------+--------------+-----------------------+ | Ns_H | 64 | Used to establish SAC | +-------------------------+--------------+-----------------------+ | Ns_M | 64 | Used to establish SAC | +-------------------------+--------------+-----------------------+ | r_B | 256 | Used to generate BCK | +-------------------------+--------------+-----------------------+ This draft recommendation requires the use of FIPS-140-2 and a pseudo-random number generator defined by [SCTE 41:2004], section 4.6 and An AES based pseudo-random number generator by ANSI X 9.31 1316H [ANSI X 9.31:1998]. 8. Appendix C Trust Model and Certificate Format 1) Trust Model: The Modbus serial link communication security protocol based on public key certificates adopts a tree shaped PKI structure, as shown in Figure C.1. The system has only one trust root (ROT), which issues public key certificates to industrial equipment manufacturers of different brands, and can also issue public key certificates to different business operators (factories). In addition, ROT also issues equipment certificates for different brands of industrial equipment manufacturers for their respective equipment brands. In actual operation, these brand certificates and equipment certificates can be issued by the original factory in the product at the time of leaving the factory, or they can be deployed and operated in the product by third-party agents or the most network user factory after leaving the factory. Trust Model: Liu, et al. Expires 14 June 2026 [Page 62] Internet-Draft Security Protocol for Modbus Serial Link December 2025 +------------------------------------+ | ROT | +------------------------------------+ | | | +-----V------+ +----V--------+ +-V--------+ | Brand A | | Brand B | | Operator | +------------+ +-------------+ +----------+ | | | | +------V--+ +-V------+ +----V----+ +-V---------+ | Device1 | | Device2| | Device3 | | Device4 | +---------+ +--------+ +---------+ +---------+ Figure C.1: Trust Model 1) Certificate format and content: The Modbus serial link communication security protocol based on public key certificates has three types of public key certificates: ROT root certificate, manufacturer brand certificate, and device certificate. Each device stores the root certificate of ROT, device certificate, and the corresponding manufacturer's brand certificate in its NVM. The root certificate is a self-signed certificate used to verify the manufacturer's brand and device certificate. The manufacturer's brand certificate is issued by ROT and is used to verify the equipment certificate. These three types of certificates have a unified field format, following the X.509 format. The basic and extended fields they contain are shown in Table C.1. They are distinguished by the "Certificate Type" field in the certificate. Table C.1: Certificate Fields and Structure +----------------------+----------------------+------------------+ | syntax | No. of bits | Mnemonic | +----------------------+----------------------+------------------+ |Modbus_certificate(){ | | | | modbussec_ID | 8 | bslbf | | certificate_type | 8 | bslbf | | certificate_version | 8 | bslbf | | encryption_capability| 8 | bslbf | | holder_ID | 64 | bslbf | | holder_public_key_x | 256 | uimsbf | | holder_public_key_y | 256 | uimsbf | | issuer_ID | 64 | bslbf | | signed_date | 32 | bslbf | | reserved | 64 | bslbf | | signature_c | 256 | uimsbf | | signature_d | 256 | uimsbf | |} | | | +----------------------+----------------------+------------------+ Liu, et al. Expires 14 June 2026 [Page 63] Internet-Draft Security Protocol for Modbus Serial Link December 2025 Modbussec-ID: This field represents the security system to which the certificate belongs, and this section specifies its value as 0xC2. Certificate type: This field represents the type of certificate. See Table C.2. Table C.2: Certificate Types +----------------------+-----------------------------------------+ | Certificate_type | The type of certificate represented | +----------------------+-----------------------------------------+ | 0x00 | Root certificate | | 0x01 | Operator certificate | | 0x02 | Brand certificate | | 0x03 | Device certificate | | Others | Reserved | +----------------------+-----------------------------------------+ Certificate_version: This field represents the version of the certificate, and this section specifies that the version number for all types of certificates is 0x01. Encryption_capability: This field represents the encryption modes supported by the device, and AES algorithm is used by default, as shown in Table C.3. Table C.3: Encryption and Decryption Capability +----------------------+-----------------------------------------+ |encryption_capability | description | +----------------------+-----------------------------------------+ | 0x00 | Reserved | | 0x01 | For device supporting aes_gcm | | 0x02 |For device supporting aes_gcm and sm4_gcm| | Others | Reserved | +----------------------+-----------------------------------------+ Holder_ID: This field represents the ID of the certificate holder, which is SERVHER-ID or CLIENT-ID. Holder_public_key_x: This field represents the horizontal axis value of the certificate holder's public key. Holder_public_key_y: This field represents the y-axis value of the certificate holder's public key. Issue_ID: This field represents the ID of the certificate issuer, which is the holder ID in the certificate issued by the CA that issued the certificate. Liu, et al. Expires 14 June 2026 [Page 64] Internet-Draft Security Protocol for Modbus Serial Link December 2025 Signed_time: This field represents the date of issuance of the certificate. This time is composed of the lower 16 bits of MJD time and four 4-bit BCD digits. For example, on October 13, 1993, 12:45 was encoded as "0xC0791245". Reserved: Set all fields to zero for future expansion. Signature_c: This field represents the c value of the certificate issuer's digital signature on the certificate data. Signature-d: This field represents the d value of the digital signature of the certificate issuer on the certificate data. Note: The certificate signature scheme adopts ECSSA scheme in 10.2 of IEEE 1363-2000 standard, the signature algorithm adopts ECSP-DSA algorithm in 7.2.7 of IEEE 1363-2000 standard, the message encoding method adopts EMSA1 method in 12.1.1 of IEEE 1363-2000 standard, and the hash function in the encoding method adopts SHA-256. Alternatively, the SM2 and SM3 algorithms in the ISO/IEC 14888-3:2018 standard can be used. Note: The verification algorithm corresponding to the above signature algorithm is the ECVP-DSA algorithm or SM2 and SM3 algorithms in 7.2.8 of the IEEE 1363-2000 standard. 3) Certificate holder ID In order to support different revocation granularity requirements in the future, when the certificate type is "device certificate", further definition of the holder_ID domain is required, as shown in Figure C.2. 1. Define the top 16 bits in the "holder-ID" field (64 bits) as the " device brand identifier"; 2. Define the lower 32 bits of the "holder-ID" field (64 bits) as the "device serial number"; 3. Define the middle 16 bits of the "holder-ID" field (64 bits) as the "device model identifier". +-------------------+------------------+----------------+ | brand identifier | model identifier| serial number | +-------------------+------------------+----------------+ |<----16 bits------>|<----16 bits----->|<----32 bits--->| Figure C.2: Structure of Certificate Holder ID Liu, et al. Expires 14 June 2026 [Page 65] Internet-Draft Security Protocol for Modbus Serial Link December 2025 In addition, this section requires that when the certificate type is "device certificate", the values of “device brand identifier" and "device model identifier" cannot be zero; The " device brand identifier" and "device model identifier" in the IDs of the other types of certificates are both set to zero values. 4) Elliptic curve parameters The Modbus serial link communication security protocol based on public key certificates in this document uses the elliptic curve defined in the prime field according to the SM2 standard, where: EC_p=0x8542D69E 4C044F18 E8B92435 BF6FF7DE 45728391 5C45517D 722EDB8B 08F1DFC3 EC_a=0x787968B4 FA32C3FD 2417842E 73BBFEFF 2F3C848B 6831D7E0 EC65228B 3937E498 EC_b=0x63E4C6D3 B23B0C84 9CF84241 484BFE48 F61D59A5 B16BA06E 6E12D1DA 27C5249A The order of the above curve is: EC_N=0x8542D69E 4C044F18 E8B92435 BF6FF7DD 29772063 0485628D 5AE74EE7 C32E79B7 The coordinates of the base point EC_G=(Gx, Gy) on the curve: Gx=0x421DEBD6 1B62EAB6 746434EB C3CC315E 32220B3B ADD50BDC 4C4E6C14 7FEDD43D Gy=0x0680512B CBB42C07 D47349D2 153B70C4 E5D7FDFC BFA36EA1 A85841B9 E46E09A2 9. IANA Considerations This memo includes no request to IANA. 10. Security Considerations This specification defines the reference native security protocol specification for the case with pure serial link communication, which (e.g., RS485-based Modbus) remains an unresolved challenge. Serial Modbus transmits data in plaintext, leaving it susceptible to interception, modification, and hardware-based side-channel attacks. There are currently no formal standards addressing security for Modbus over RS485, which is still widely used due to its simplicity and long-distance capabilities. Currently, for any EIA/TIA-485 multi-point system, whether it is a 2-wire or 4-wire configuration, the maximum length for cables with a maximum baud rate of 9600bit/s and AWG26 (or thicker) specifications can reach over 1000m. For RS485 Modbus, a sufficiently wide cable diameter should allow for a maximum length of over 1000m, and for RS485 Modbus using Category 5 cables, the maximum length can reach 600m. This lack of encryption Liu, et al. Expires 14 June 2026 [Page 66] Internet-Draft Security Protocol for Modbus Serial Link December 2025 and authentication mechanisms poses risks, particularly in scenarios involving relays or bridged networks. While Modbus TCP has seen notable advancements in security through TLS-based solutions, serial Modbus communication requires urgent attention. Introducing lightweight encryption and authentication mechanisms for serial links could provide a practical way to enhance security and protect legacy systems without significant infrastructure changes. Therefore, it is urgent to improve and enhance the communication security of Modbus protocol under serial link mode, for reference by relevant institutions and organizations in various industries, in order to ensure the practical application security of various industrial control systems. With the introduction of the Modbus serial link security standard, the introduction of encryption and authentication mechanisms in the serial link communication channel of the Modbus protocol significantly improves its security, providing a relatively simple and direct upgrade path for existing devices that use Modbus extensively. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [IEC62443-3-3] "System Security Requirements and Security Levels", IEC 62443, 2013. [IEC62443-4-2] "Technical Security Requirements for IACS Components", IEC 62443, 2019. Liu, et al. Expires 14 June 2026 [Page 67] Internet-Draft Security Protocol for Modbus Serial Link December 2025 [IEC62351-3] "Power Systems Management and Associated Information Exchange – Data and Communications Security – Part 3: Communication Network and System Security for Profiles Including TCP/IP", IEC 62351, 2014. [IEC62351-4] "Power Systems Management and Associated Information Exchange – Data and Communications Security – Part 4: Profiles Including MMS and Derivatives", IEC 62351, 2018. [NISTSP800-82] "Guide to Industrial Control Systems (ICS) Security", NIST SP800, 2018. [ENISA-ICS-Security-Guidelines] "Good Practices for Security of Industrial Control Systems", ENISA ICS-Security-Guidelines, 2018. Authors' Addresses Penghui Liu (editor) Pengcheng Laboratory No.2 Xingke 1 Street Shenzhen 518055 China Email: liuph@pcl.ac.cn Rongwei Yang (editor) Pengcheng Laboratory No.2 Xingke 1 Street Shenzhen 518055 China Email: yangrw@pcl.ac.cn Meiling Chen (editor) China Mobile No.32 Xuanwumen West Street Beijing 100000 China Email: chenmeiling@chinamobile.com Liu, et al. Expires 14 June 2026 [Page 68] Internet-Draft Security Protocol for Modbus Serial Link December 2025 Yu Fu (editor) China Unicom No.1 Zhonghe Street Beijing 100000 China Email: fuy186@chinaunicom.cn Weizhe Zhang (editor) Pengcheng Laboratory No.2 Xingke 1 Street Shenzhen 518055 China Email: zhangwzh@pcl.ac.cn Liu, et al. Expires 14 June 2026 [Page 69]