| Internet-Draft | Security Protocol for Modbus Serial Link | December 2025 |
| Liu, et al. | Expires 14 June 2026 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
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 (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.¶
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 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.¶
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.¶
The Modbus serial link communication security protocol specification aims to provide:¶
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:¶
+-------+----------------------+------------------+------+
| 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¶
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.¶
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.¶
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.¶
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 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.¶
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 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) 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¶
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.¶
+---------------------+----------------------+------------------+
| 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¶
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.¶
+-------------------------------+----------------------+------------------+
| 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<send_datatype_nbr; | | |
| i++) {| | |
| datatype_id | 8 | uimsbf |
| datatype_length | 16 | uimsbf |
| data_type | 8*datatype_length | bslbf |
| } | | |
| request_datatype_nbr | 8 | uimsbf |
| for (i=0; | | |
| i<request_datatype_nbr; | | |
| i++){| | |
| datatype_id | 8 | uimsbf |
| } | | |
|} | | |
+-------------------------------+----------------------+------------------+
Figure 7: ss_data_req APDU syntax¶
4) The definition of ss_data_cnf APDU is as follows:¶
The master client sends an ss_data_cnf message to transmit protocol related data to the slave server. The ss_data_cnf APDU syntax is shown in Figure 8. ss_data_cnf APDU is used for data that does not require authentication or encryption, mainly for authentication, authentication key verification, and SAC key calculation. For data that requires authentication or encryption, use ss_sac_data_cnf APDU.¶
+-------------------------------+----------------------+------------------+
| syntax | No. of bits | Mnemonic |
+-------------------------------+----------------------+------------------+
|ss_data_cnf() { | | |
| ss_data_cnf_tag | 24 | uimsbf |
| length_field()=0 | | |
| ss_system_id_bitmask | 8 | bslbf |
| send_datatype_nbr | 8 | uimsbf |
| for (i=0;i<send_datatype_nbr; | | |
| i++) {| | |
| datatype_id | 8 | uimsbf |
| datatype_length | 16 | uimsbf |
| data_type | 8*datatype_length | bslbf |
| } | | |
+-------------------------------+----------------------+------------------+
Figure 8: ss_data_cnf APDU syntax¶
The protocol APDU format that includes specific data types in the authentication protocol is shown as follows:¶
When sending public key certificate chain from the slave server to the master client, ss_data_req APDU is sent with following Parameters in Figure 9.¶
+-------------------------------+----------------------+------------------+ | content | +-------------------------------+----------------------+------------------+ |send _datatype_nbr=2 | +-------------------------------+----------------------+------------------+ | i | datatype_id | datatype_len | +-------------------------------+----------------------+------------------+ | 0 | 11(Server_Dev_Cert) | 1280 bits | +-------------------------------+----------------------+------------------+ | 1 | 4(Server_Brand_Cert) | 1280 bits | +-------------------------------+----------------------+------------------+ |request_datatype_nbr=3 | +-------------------------------+----------------------+------------------+ | i | datatype_id | +-------------------------------+----------------------+------------------+ | 0 | 8 (DHPH) | +-------------------------------+----------------------+------------------+ | 1 | 10 (Client_Dev_Cert) | +-------------------------------+----------------------+------------------+ | 2 | 3 (Client_Brand_Cert) | +-------------------------------+----------------------+------------------+ Figure 9: ss_data_req APDU content¶
When the master client sends DHPH and two public key certificates, ss_data_cnf APDU is sent with following Parameters in Figure 10.¶
+-------------------------------+----------------------+------------------+ | content | +-------------------------------+----------------------+------------------+ |send _datatype_nbr=3 | +-------------------------------+----------------------+------------------+ | i | datatype_id | datatype_len | +-------------------------------+----------------------+------------------+ | 0 | 8(DHPH) | 512 bits | +-------------------------------+----------------------+------------------+ | 1 | 10(Client_Dev_Cert) | 1280 bits | +-------------------------------+----------------------+------------------+ | 2 | 3(Client_Brand_Cert) | 1280 bits | +-------------------------------+----------------------+------------------+ Figure 10: ss_data_cnf APDU content¶
When sending DHPM and checksum RM from the slave server, ss_data_req APDU is sent with following Parameters in Figure 11.¶
+-------------------------------+----------------------+------------------+ | content | +-------------------------------+----------------------+------------------+ |send _datatype_nbr=4 | +-------------------------------+----------------------+------------------+ | i | datatype_id | datatype_len | +-------------------------------+----------------------+------------------+ | 0 | 9(DHPM) | 512 bits | +-------------------------------+----------------------+------------------+ | 1 | 12(RM) | 256 bits | +-------------------------------+----------------------+------------------+ | 2 | 11(Server_Dev_Cert) | 1280 bits | +-------------------------------+----------------------+------------------+ | 3 | 4(Server_Brand_Cert) | 1280 bits | +-------------------------------+----------------------+------------------+ |request_datatype_nbr=1 | +-------------------------------+----------------------+------------------+ | i | datatype_id | +-------------------------------+----------------------+------------------+ | 0 | 20 (status_field) | +-------------------------------+----------------------+------------------+ Figure 11: ss_data_req APDU content¶
When the master client sends the verification value RH, ss_data_cnf APDU is sent with following Parameters in Figure 12.¶
+-------------------------------+----------------------+------------------+ | content | +-------------------------------+----------------------+------------------+ |send _datatype_nbr=1 | +-------------------------------+----------------------+------------------+ | i | datatype_id | datatype_len | +-------------------------------+----------------------+------------------+ | 0 | 13(RH) | 256 bits | +-------------------------------+----------------------+------------------+ Figure 12: ss_data_cnf APDU content¶
When requesting AKH from the slave server to the master client, ss_data_req APDU is sent with following Parameters in Figure 13.¶
+-------------------------------+----------------------+------------------+ | content | +-------------------------------+----------------------+------------------+ |send _datatype_nbr=1 | +-------------------------------+----------------------+------------------+ | i | datatype_id | +-------------------------------+----------------------+------------------+ | 0 | 17(AKH) | +-------------------------------+----------------------+------------------+ Figure 13: ss_data_req APDU content¶
When the master client sends AKH, ss_data_cnf APDU is sent with following Parameters in Figure 14.¶
+-------------------------------+----------------------+------------------+ | content | +-------------------------------+----------------------+------------------+ |send _datatype_nbr=1 | +-------------------------------+----------------------+------------------+ | i | datatype_id | datatype_len | +-------------------------------+----------------------+------------------+ | 0 | 17(AKH) | 256 bits | +-------------------------------+----------------------+------------------+ Figure 14: ss_data_cnf APDU content¶
Note: During the certificate authentication phase, APDU messages will encapsulate the Modbus serial link data unit field with a success number of 0. For APDUs larger than 252 bytes (the maximum data field length of Modbus RTU frames), such as ss_data_req APDUs, which exchange certificates with approximately 422 bytes, they can be divided into two Modbus serial link message frames for transmission. Since the transmission operation is strictly serial and has a sequence, the upper layer application can concatenate two or more segmented APDUs based on the tag (ss_data_cnf_tag) and length_field () fields of the protocol.¶
The authentication process of the slave server is briefly described as follows:¶
The authentication process of the master client is briefly described as follows:¶
Note: The slave server can repeatedly send requests to AKH until the master client responds.¶
The calculations involved in the certificate based authentication process are shown in Figure 15, and describled as below.¶
+------------+ +-------------+
|Slave server|<-------------------------------->|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¶
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.¶
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.¶
+---------------+----------------+ | 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.¶
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.¶
+-------+ +-------+
| 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¶
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¶
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:¶
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¶
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.¶
+----------------------+----------------+ | 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.¶
+-------------------------------+----------------------+------------------+ | 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.¶
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.¶
Calculating the authentication key SAK and encryption key SEK for SAC requires two steps:¶
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¶
+----------------------+----------------+ | 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.¶
+-------------------------------+----------------------+------------------+
| 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:¶
The data message submitted for SAC transmission when sending SAC messages should be processed according to the following steps:¶
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:¶
Authentication code calculation is specific to the entire message, with parameters shown in Figure 29.¶
+-----------+----------------+---------------------+ | 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¶
If SAC messages need to be encrypted, the following method should be used:¶
encrypted_payloadi = E{SEK, SIV}(payload_pi||authentication_ai)¶
Where:¶
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:¶
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:¶
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.¶
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:¶
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¶
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¶
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:¶
APDU definition used in the content key update protocol process:¶
1) ss_sac_data_req APDU¶
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;i<send_datatype_nbr; | | |
| i++) {| | |
| datatype_id | 8 | uimsbf |
| datatype_length | 16 | uimsbf |
| data_type | 8*datatype_length | bslbf |
| } | | |
| request_datatype_nbr | 8 | uimsbf |
| for (i=0; | | |
| i<request_datatype_nbr; | | |
| i++){| | |
| datatype_id | 8 | uimsbf |
| } | | |
|} | | |
+-------------------------------+----------------------+------------------+
Figure 33: ss_sac_data_req Payload syntax¶
ss_system_id_bitmask: Same as above.¶
send_datatype_nbr: This message contains the number of data categories.¶
datatype_id: See Annex III.¶
datatype_length: The byte length of the data in the form of a data type.¶
data_type: The specific data represented by datatype_id.¶
request_datatype_nbr: The number of data categories that the primary client should include in its response.¶
datatype_id: See Annex III.¶
2) ss_sac_data_cnf APDU¶
When data needs to be authenticated and encrypted, the master client should use this APDU to send protocol specific data to the slave server. The syntax of ss_sac_data_cnf APDU is shown in Figure 34. The input data in SAC encapsulation in Figure 35 is used as the payload in the SAC message.¶
+---------------------+----------------------+------------------+
| syntax | No. of bits | Mnemonic |
+---------------------+----------------------+------------------+
|ss_sac_data_cnf() { | | |
| ss_sac_data_cnf_tag | 24 | uimsbf |
| length_field()=0 | | |
| sac_message() | | |
|} | | |
+---------------------+----------------------+------------------+
Figure 34: ss_sac_data_cnf APDU syntax¶
+-------------------------------+----------------------+------------------+
| syntax | No. of bits | Mnemonic |
+-------------------------------+----------------------+------------------+
| ss_system_id_bitmask | 8 | bslbf |
| send_datatype_nbr | 8 | uimsbf |
| for (i=0;i<send_datatype_nbr; | | |
| i++) {| | |
| datatype_id | 8 | uimsbf |
| datatype_length | 16 | uimsbf |
| data_type | 8*datatype_length | bslbf |
| } | | |
+-------------------------------+----------------------+------------------+
Figure 35: ss_sac_data_cnf Payload syntax¶
ss_system_id_bitmask: Same as above.¶
send_datatype_nbr: This message contains the number of data categories.¶
datatype_id: See Annex III.¶
datatype_length: The byte length of the data in the form of a data type.¶
data_type: The specific data represented by datatype_id.¶
3) ss_sac_sync_req APDU¶
This APDU is used in the CK calculation process. The slave server sends this message to indicate that it has completed the new CK calculation. The syntax of ss_sac_sync_req APDU is shown in Figure 36.¶
+---------------------+----------------------+------------------+
| syntax | No. of bits | Mnemonic |
+---------------------+----------------------+------------------+
|ss_sac_sync_req() { | | |
| ss_sac_sync_req_tag | 24 | uimsbf |
| length_field()=0 | | |
| sac_message() | | |
|} | | |
+---------------------+----------------------+------------------+
Figure 36: ss_stac_sync_req APDU syntax¶
ss_sac_sync_req_tag: 0x9F 90 09.¶
sac_message: Same as above.payload_encryption_flag should be 1.The payload of the SAC message here is empty.¶
4) ss_sac_sync_cnf APDU¶
This APDU is used in the CK calculation process. The master client responds with this message to the ss_sac_sync_req APDU message sent from the slave server. The syntax of the ss_sac_sync_cnf APDU is shown in Figure 37.¶
+---------------------+----------------------+------------------+
| syntax | No. of bits | Mnemonic |
+---------------------+----------------------+------------------+
| ss_sac_sync_cnf() { | | |
| ss_sac_sync_cnf_tag | 24 | uimsbf |
| length_field()=0 | | |
| sac_message() | | |
|} | | |
+---------------------+----------------------+------------------+
Figure 37: ss_sac_sync_cnf APDU syntax¶
ss_sac_sync_req_tag: 0x9F 90 10.¶
sac_message: Same as above.payload_encryption_flag should be 1.The payload of this SAC message is a state domain. All possible values in the state domain are listed in Figure 38.¶
+----------------------+----------------+ | status_field |value | +----------------------+----------------+ |OK |00 | |No resource |01 | |Master client busy |02 | |Not required |03 | |Reserved |04-FF | +----------------------+----------------+ Figure 38: State Fields in ss_sac_sync_cnf¶
When sending SERVER_ID and a random number from the slave server, ss_sac_data_req APDU is sent with following Parameters in Figure 39.¶
+-------------------------------+----------------------+------------------+ | content | +-------------------------------+----------------------+------------------+ |send _datatype_nbr=2 | +-------------------------------+----------------------+------------------+ | i | datatype_id | datatype_len | +-------------------------------+----------------------+------------------+ | 0 | 2(SERVER_ID) | 64 bits | +-------------------------------+----------------------+------------------+ | 1 | 7(Kp) | 256 bits | +-------------------------------+----------------------+------------------+ |request_datatype_nbr=2 | +-------------------------------+----------------------+------------------+ | i | datatype_id | +-------------------------------+----------------------+------------------+ | 0 | 1(CLIENT_ID) | +-------------------------------+----------------------+------------------+ | 1 | 20(Status_field) | +-------------------------------+----------------------+------------------+ Figure 39: ss_sac_data_req APDU content¶
When the master client responds with CLIENT_ID and status information, ss_sac_data_cnf APDU is sent with following Parameters in Figure 40.¶
+-------------------------------+----------------------+------------------+ | content | +-------------------------------+----------------------+------------------+ |send _datatype_nbr=3 | +-------------------------------+----------------------+------------------+ | i | datatype_id | datatype_len | +-------------------------------+----------------------+------------------+ | 0 | 2(SERVER_ID) | 64 bits | +-------------------------------+----------------------+------------------+ | 1 | 7(Kp_client) | 256 bits | +-------------------------------+----------------------+------------------+ | 2 | 20(Status_field) | 8 bits | +-------------------------------+----------------------+------------------+ Figure 40: ss_sac_data_cnf APDU content¶
The CK update operation on the slave server side is shown as below, and the broadcast content key BCK can be generated along with it.¶
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.¶
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.¶
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 updated by the master station through the SAC content key update protocol. The process of updating BCK protocol is shown as follows separately.¶
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.¶
+-------------------------------+----------------------+------------------+ | 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.¶
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.¶
+------------------------+----------------------+------------------+
| 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¶
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.¶
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.¶
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 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.¶
For slave server, the raw data generated and configured are (elliptic curve system parameters, Z_H, Z_M, d_M, P_M, P_H).¶
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:¶
+------------+ +-------------+ |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¶
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. 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¶
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¶
The content encryption and decryption mechanism used in this section is the same as that in previous section.¶
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 | +-------------------------+--------------+-------------+ | 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 | +-------------------------+--------------+-------------+¶
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.¶
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].¶
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:¶
+------------------------------------+
| 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 |
|} | | |
+----------------------+----------------------+------------------+
¶
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.¶
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.¶
+-------------------+------------------+----------------+ | brand identifier | model identifier| serial number | +-------------------+------------------+----------------+ |<----16 bits------>|<----16 bits----->|<----32 bits--->| Figure C.2: Structure of Certificate Holder ID¶
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¶
This memo includes no request to IANA.¶
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 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.¶