Content area
In modern industrial control systems (ICSs), communication protocols such as Modbus TCP remain widely used due to their simplicity, interoperability, and real-time performance. However, these communication protocols (e.g., Modbus TCP) were originally designed without security considerations, lacking essential features such as encryption, integrity protection, and authentication. This exposes ICS deployments to severe security threats, including eavesdropping, command injection, and replay attacks, especially when operating over unsecured networks. To address these critical vulnerabilities while preserving the lightweight nature of the protocol, we propose a Modbus TCP security enhancement scheme that integrates ASCON, an NIST-standardized authenticated encryption algorithm, with the CBOR Object Signing and Encryption (COSE) framework. Our design embeds COSE_Encrypt0 structures into Modbus application data, enabling end-to-end confidentiality, integrity, and replay protection without altering the protocol’s semantics or timing behavior. We implement the proposed scheme in C and evaluate it in a simulated embedded environment representative of typical ICS devices. Experimental results show that the solution incurs minimal computational and memory overhead, while providing robust cryptographic guarantees. This work demonstrates a practical pathway for retrofitting legacy ICS protocols with modern lightweight cryptography, enhancing system resilience without compromising compatibility or performance.
Full text
1. Introduction
Industrial control systems (ICSs) and supervisory control and data acquisition (SCADA) networks rely heavily on communication protocols such as Modbus [1], Distributed Network Protocol 3 (DNP3) [2], EtherNet/IP [3], and Powerlink [4] to connect programmable logic controllers (PLCs), sensors, and Human–Machine Interfaces (HMIs). Although widely adopted in critical infrastructure and industrial automation systems, these industrial communication protocols were originally designed to meet the demands of reliability and real-time responsiveness, with little or no consideration for security. As a result, they commonly suffer from inherent security weaknesses such as the lack of authentication, encryption, and integrity checks.
Modbus TCP [5], the most prevalent variant of Modbus used in Ethernet-based industrial environments, transmits all payloads in plaintext and lacks identity verification mechanisms. This makes it susceptible to a wide range of attacks including eavesdropping, unauthorized command injection, replay attacks, and data manipulation.
To address these shortcomings, several security extensions have been proposed, such as wrapping industrial protocols within VPN tunnels, applying Transport Layer Security (TLS), or embedding cryptographic primitives like AES-GCM or SM4 [6,7,8]. However, these solutions often introduce significant overhead in terms of computational complexity, memory usage, or latency, and may require hardware or system stack modifications that hinder deployment on embedded devices or legacy field equipment.
To reconcile the tension between security and real-time constraints in industrial protocols, this paper presents a lightweight security enhancement scheme for Modbus TCP, one of the most widely used and representative protocols in industrial control systems. Our approach is based on two emerging standards: (1) ASCON, a NIST-standardized lightweight authenticated encryption algorithm optimized for constrained devices [9], and (2) COSE_Encrypt0, a concise and structured cryptographic message format specified by the IETF for securing CBOR-encoded payloads [10].
Unlike traditional approaches that rely on heavyweight frameworks like TLS, our scheme integrates security mechanisms directly at the Modbus application layer using COSE_Encrypt0. By encapsulating Modbus function codes and parameters into COSE structures, we achieve end-to-end confidentiality, integrity, and replay protection without breaking compatibility with the existing Modbus message format or requiring changes to lower protocol layers.
To validate our design, we implement the protocol in a simulated embedded environment for performance evaluation and conduct comprehensive experiments to measure its performance overhead and memory footprint. We also compare our approach with six state-of-the-art schemes, which demonstrate the efficiency and advantages of our lightweight approach. The contributions of this paper are as follows: We propose a novel secure Modbus TCP protocol that integrates the lightweight cipher ASCON-128 with the standardized COSE_Encrypt0 format. The scheme provides mutual authentication, identity binding, and forward secrecy while maintaining Modbus compatibility. We perform a detailed security analysis of the proposed protocol, demonstrating resistance to key threats such as message manipulation, eavesdropping, and replay attacks. We implement and evaluate the scheme on an embedded platform and perform performance comparisons with state-of-the-art baselines including SM3/SM4-based designs. Experimental results show that our solution offers strong security with minimal computational and bandwidth overhead, especially excelling in server-side decryption performance.
2. Related Work
As a legacy protocol widely adopted in industrial control systems (ICSs), Modbus was originally designed without any built-in security mechanisms, such as authentication, encryption, or replay protection. This inherent vulnerability has made Modbus a frequent target of cyberattacks in critical infrastructure environments. A wide range of efforts have been made to retrofit security into Modbus communications.
Early cryptographic solutions primarily focused on integrating classical cryptographic primitives. Fovino et al. [11] proposed a scheme combining SHA-2 for data integrity, Rivest–Shamir–Adleman (RSA) for authentication, and timestamps for non-repudiation and replay protection. However, the use of RSA introduced significant computational overhead, limiting its practicality in resource-constrained industrial devices. Hayes et al. [12] introduced Modbus-Sec, which leveraged Stream Control Transmission Protocol (SCTP) and message authentication codes (MACs) to resist denial-of-service and man-in-the-middle attacks. Despite these strengths, the scheme relied on a single symmetric key, rendering it susceptible to unauthorized command injection and replay attacks. To further strengthen the security of Modbus, Shahzad et al. [6] proposed a hybrid encryption framework that incorporated additional security fields into Modbus packets. Their approach used Advanced Encryption Standard (AES) for data encryption and RSA for signing and encrypting the AES key. While this dual-layer design enhanced confidentiality and authenticity, it was computationally intensive due to RSA, making it ill-suited for embedded environments.
Some researchers turned to structural-level protections to mitigate performance concerns. Shang et al. [13] proposed a Modbus-aware industrial firewall utilizing a whitelist mechanism to block unauthorized traffic. Pricop et al. [14] explored embedding authentication data into the TCP header options of Modbus TCP, but did not provide a concrete authentication protocol. Xuan et al. [7] introduced the Modbus-S framework to improve identity authentication and data confidentiality, but it lacked detailed cryptographic implementation. Chochutoula et al. [15] proposed a solution based on elliptic curve cryptography (ECC), offering strong authentication and confidentiality while maintaining moderate performance costs.
Yi et al. [16] combined SM4 and SM3 to provide confidentiality and integrity with pre-shared keys and timestamp-based replay protection. However, transmitting timestamps and nonces in plaintext weakened the replay resistance of their solution. Lin et al. [17] employed AES and SHA-256 to enhance data protection, but did not address authentication. Other studies incorporated SM2, SM3, and SM4 in combination, but relied on certificate infrastructures and large key sizes, which are impractical for lightweight deployment. Liu et al. [8] presented a comprehensive SM-based security framework for Modbus, covering identity authentication, key agreement, and data protection, achieving compliance with national standards while addressing several practical constraints. Katulic et al. [18] proposed a novel Modbus TCP authentication scheme based on lightweight MACs, designed specifically for industrial control systems. Similarly, Zhang et al. [19] developed a ZUC- and SM3-based security mechanism for Modbus/TCP, enabling ultra-low-latency cryptographic protection for constrained devices, covering authentication, integrity, confidentiality, and anti-replay functionality.
In summary, existing security enhancement schemes often rely on heavyweight cryptographic primitives and complex protocol interactions, leading to considerable computational and management overhead, especially in resource-constrained environments. Additionally, most approaches lack flexibility, preventing users from tailoring security properties such as integrity, confidentiality, and authentication based on application requirements. To address these limitations, our work proposes a lightweight, modular, and message-level secure solution based on ASCON and the COSE framework, offering customizable security while maintaining compatibility with both Modbus TCP and serial variants.
3. Background
3.1. Modbus TCP Protocol
Modbus [1] is a serial communication protocol originally introduced by Modicon in 1979 for use with programmable logic controllers (PLCs). Its simplicity, openness, and ease of implementation have made it one of the most widely adopted communication protocols in industrial control systems (ICSs) and supervisory control and data acquisition (SCADA) environments. Over time, the protocol has been extended from its original serial-based formats to Ethernet-based Modbus TCP to support modern network infrastructures [5].
As shown in Figure 1, the Modbus TCP message structure consists of two main parts: the Modbus Application Protocol (MBAP) header and the Protocol Data Unit (PDU). Together, these constitute the Application Data Unit (ADU). The MBAP header is 7 bytes long and contains the following fields: (1) The Transaction Identifier used to match responses with requests and prevent message confusion during concurrent transactions. (2) The Protocol Identifier set to “0x0000” for Modbus TCP, identifying the protocol type. (3) The Length field specifies the length of the remaining bytes in the message, including the Unit Identifier, Function Code, and Data. (4) The Unit Identifier is used to address a specific remote server or a serially connected Modbus device in bridging scenarios. The PDU includes the following: (1) The Function Code indicates the type of operation requested by the client, and there are eight common types of function codes used for read and write operations on secondary device data. (2) The Data field contains the parameters associated with the function code, such as register addresses or values to be written.
This modular message structure enables Modbus to be easily parsed and extended, but also exposes a fundamental vulnerability: all fields, including the function code and data payload, are transmitted in plaintext, with no native mechanisms for authentication, encryption, or message integrity. As a result, Modbus TCP is inherently vulnerable to a wide range of attacks, including message spoofing, tampering, replay, and eavesdropping. These limitations highlight the pressing need for efficient and backward-compatible security enhancements that can integrate with existing Modbus message structures while introducing robust cryptographic protections.
3.2. ASCON Algorithm
ASCON is a family of lightweight authenticated encryption and hashing algorithms designed to offer strong security and high efficiency in resource-constrained environments [9]. It was selected as the finalist and the official standard of the NIST Lightweight Cryptography (LWC) competition, making it a leading choice for embedded systems, IoT devices, and industrial control systems (ICSs), where performance, energy consumption, and code size are key considerations. The ASCON suite includes authenticated encryption with associated data (AEAD) and hashing functions. Among them, ASCON-128 (AEAD) and ASCON-Hash are officially recommended for general-purpose use. Both share a common permutation-based sponge construction with a 320-bit internal state, offering consistency and compactness in implementation. The complete round-based descriptions, padding strategies, and permutation formulas of ASCON-128 and ASCON-Hash are provided in Appendix A. In our protocol, we adopt ASCON-MAC for message authentication, which is built upon the ASCON-Hash function using a sponge-based construction. Specifically, ASCON-MAC behaves similarly to HMAC but is optimized for lightweight environments by leveraging the same underlying permutation as ASCON-128 and ASCON-Hash. ASCON-MAC uses a keyed variant of ASCON-Hash, where the pre-shared key is injected into the initial state and then absorbed together with the message. This design ensures message integrity and authenticity with significantly reduced implementation overhead compared to traditional HMAC-SHA2, while offering comparable security guarantees.
3.2.1. ASCON-128
ASCON-128 follows an Encrypt-then-MAC paradigm and supports both confidentiality and integrity. The algorithm consists of four stages: Initialization: The internal state is initialized using the secret key, nonce, and a predefined constant. Associated Data Processing: Metadata (e.g., headers) is absorbed into the state for integrity protection. Plaintext Processing: The message is encrypted block-by-block, and ciphertext is generated along with an authentication tag. Finalization: A 128-bit authentication tag is computed from the final state and appended to the ciphertext.
ASCON-128 achieves authentication using its permutation structure rather than a separate MAC construction. This integrated approach differs from traditional HMAC, which uses Merkle–Damgard-based hash functions like SHA-2. ASCON’s sponge-based design ensures resistance to forgery and side-channel attacks while being efficient on constrained platforms.
3.2.2. ASCON-Hash
ASCON-Hash is a standalone hash function in the ASCON suite that uses the same internal structure as ASCON-128. It supports variable-length output and provides resistance to collision and preimage attacks. ASCON-Hash is used in our protocol for session key derivation, ensuring domain separation and consistency with the encryption scheme.
3.3. CBOR Object Signing and Encryption
The CBOR Object Signing and Encryption (COSE) framework [20] defines a compact cryptographic message format for protecting CBOR-encoded data [21]. COSE is particularly well-suited for constrained environments such as industrial control systems, embedded devices, and IoT networks due to its compactness, flexibility, and support for modern cryptographic algorithms. For example, unlike JSON-based JOSE (used in web environments), CBOR encoding reduces transmission size and avoids the need for complex string parsing, enabling faster encoding/decoding and lower RAM usage. Empirical evaluations [22] show that COSE outperforms JOSE in terms of average overhead and scalability with a more stable performance as payload size increases. In addition, COSE is being adopted by emerging IoT and IIoT standards (e.g., IETF SUIT [23], FIDO IoT [24]) due to its strong support for modern cryptographic primitives and its compatibility with constrained network protocols like CoAP or DTLS. These features collectively ensure compatibility with existing and future lightweight industrial communication stacks, supporting both security and interoperability requirements.
Among the different types of COSE message, COSE_Encrypt0 provides authenticated encryption with a single recipient using a symmetric key. A COSE_Encrypt0 structure is a CBOR array of three elements: Protected header (bstr): A CBOR-encoded map containing integrity-protected parameters, such as the algorithm identifier (e.g., ASCON). Unprotected header (map): Parameters not covered by the authentication tag, such as nonce (IV), sequence number, or issuer. Ciphertext (bstr): The encrypted payload, including the authentication tag produced by the AEAD encryption algorithm.
In our work, we adopt the COSE_Encrypt0 structure to encapsulate and protect Modbus messages at the application layer. This structure provides confidentiality through authenticated encryption, ensures integrity and authenticity by cryptographically binding both headers and payload in a single AEAD operation, and maintains low communication and processing overhead due to the compactness of the CBOR-based encoding format, which avoids the verbosity of JSON or XML.
4. Design of the Security-Enhanced Modbus Scheme
In this section, we present the design of the lightweight enhancement scheme for Modbus TCP communications. We begin with an overview of the protocol architecture, followed by detailed descriptions of each phase, including initialization and secure communication. We give the notation appearing in this paper in Table 1.
Figure 2 presents the overall architecture of our protocol. The design consists of two primary phases: Initialization Phase: The client and server perform mutual authentication and derive a fresh session key using a pre-shared identity key and independently generated nonces. This process ensures forward secrecy and does not rely on certificate-based infrastructure. In real-world deployments, the secure distribution and management of the pre-shared key remains a significant challenge. For instance, in industrial control systems, common solutions include manual key injection during device commissioning, using secure bootstrap protocols such as IETF BRSKI [25], or leveraging trusted third-party provisioning servers with physical access constraints. While our model assumes that is securely pre-established and kept secret, we note that our protocol can be integrated with existing secure key distribution frameworks (e.g., TPM-based hardware roots of trust or practices) without requiring major modifications. Secure Communication Phase: Modbus messages are encrypted and authenticated using the ASCON algorithm, and encapsulated within a COSE_Encrypt0 structure. The receiver verifies the message authenticity and decrypts the payload using the established session key before processing the Modbus PDU.
4.1. Initialization Phase
This phase establishes a secure session context between the client and the server using a pre-shared identity key that is securely provisioned out of band and ephemeral random nonces. Each party has a unique identity: the client is denoted by and the server is denoted by . The specific steps of authentication and key negotiation are described as follows: Client Authentication Request The client generates a 128-bit cryptographically secure nonce and constructs a message authentication code over its identity and the nonce using the ASCON-MAC algorithm, which is built on top of the sponge-based ASCON-Hash function:
The authentication request message is formed as
This message ensures freshness and integrity, and proves knowledge of the pre-shared key.
Server Challenge and Response
Upon receiving , the server verifies using the shared key . If successful, the server generates its own nonce , and computes
It then sends the response message:
This step confirms possession of the shared key and binds both nonces to the session.
Client Verification and Key Derivation The client verifies using . Upon successful verification, both parties derive a 128-bit session key using the ASCON-Hash function:
This key is then used to encrypt and authenticate subsequent Modbus messages.
4.2. Secure Communication Phase
After session establishment, each Modbus message is encrypted using ASCON-128 and encoded in a COSE_Encrypt0 structure, ensuring message confidentiality, integrity, and replay protection.
4.2.1. Message Structure
As shown in Figure 3, a secure Modbus packet consists of the original Modbus MBAP header and a COSE_Encrypt0 object that encapsulates the protected Modbus PDU. The COSE_Encrypt0 structure is a CBOR array containing three elements: Protected Header (bstr): A CBOR-encoded map containing cryptographic parameters such as the encryption algorithm identifier (e.g., Unprotected Header (map): A plaintext map including session metadata such as the initialization vector , issuer identifier , and a sequence number . Although not encrypted, these fields are authenticated as associated data. Ciphertext (bstr): The encrypted Modbus PDU concatenated with a 128-bit authentication tag produced by the ASCON-128 AEAD function.
The entire COSE_Encrypt0 array is appended to the standard Modbus MBAP header, maintaining compatibility with existing Modbus parsers.
4.2.2. Communication Phase
After establishing a shared session key during the initialization phase, the Modbus client and the Modbus server proceed with secure communication using authenticated encryption with associated data. Each Modbus message is encrypted using the ASCON-128 algorithm and encapsulated in the COSE_Encrypt0 structure.
Client-Side Message Construction
To construct a secure Modbus message, the client first prepares the plaintext Modbus PDU, denoted as M. It then generates a 128-bit cryptographically secure random nonce , an issuer identifier , and a monotonically increasing sequence number to ensure freshness and ordering.
The protected header is constructed as a -encoded map containing cryptographic parameters:
The unprotected header is a plaintext map that includes metadata required for session identification:
The associated data for the AEAD operation is formed by concatenating the protected and unprotected headers:
Using the established session key , the client encrypts the message and generates the authentication tag using ASCON-128 AEAD:
The ciphertext field is constructed by appending the tag to the encrypted payload:
Finally, the complete Modbus message is assembled by combining the original header and the structure:
where the object is composed ofServer-Side Message Verification
Upon receiving a secure Modbus packet, the server begins by parsing the standard MBAP header and extracting the COSE_Encrypt0 structure. The structure consists of the protected header , unprotected header , and the ciphertext field .
From the unprotected header, the server retrieves the session-related metadata, including the issuer identifier , the initialization vector , and the sequence number . The protected header is CBOR-decoded and verified to ensure that the correct algorithm (e.g., ASCON-128) is specified.
The associated data for decryption is then reconstructed by combining the protected and unprotected headers:
The field is split into the encrypted payload and the authentication :
The server retrieves the session key corresponding to the session identifier , and performs decryption and authentication using the ASCON-128 AEAD algorithm:
If the authentication tag is valid, the message is accepted and the decrypted Modbus PDU M is processed. If the tag verification fails, the message is discarded to prevent unauthorized access or tampering.
5. Security Analysis
In this section, we present a comprehensive security and privacy analysis of the proposed authenticated and encrypted Modbus protocol. We formally define the adversarial capabilities under the Dolev–Yao threat model and provide cryptographic proofs for key security properties. Additionally, we validate the correctness of our security claims through formal verification using ProVerif (Version 2.05) [26].
5.1. Security Assumptions
We adopt the Dolev–Yao adversarial model to formalize the threat environment under which the proposed protocol operates. In this model, the adversary is considered a probabilistic polynomial-time (PPT) entity with the following capabilities, grouped into three main categories relevant to cryptographic protocol analysis: Network control capabilities: The adversary has full control over the communication channel between the Modbus client and the server. can intercept, block, replay, reorder, delay, or modify any transmitted messages. This grants the ability to mount man-in-the-middle (MITM) attacks and message tampering. Active protocol interaction: The adversary may impersonate a client or server without access to their long-term secrets. can initiate concurrent sessions, interleave or reflect messages between sessions, and craft arbitrary protocol-compliant or malformed messages in an attempt to deceive the other party. However, cannot forge authentication tags or decrypt ciphertexts without access to the appropriate keys. Passive cryptographic analysis: can observe all public parameters, exchanged ciphertexts, nonces, and identifiers. Nevertheless, the adversary cannot break the underlying cryptographic primitives, such as HMAC or authenticated encryption with associated data (AEAD), which are assumed to be secure under standard assumptions. That is, cryptographic primitives behave ideally (e.g., HMAC is UF-CMA-secure, encryption schemes provide IND-CCA security), and no side-channel leakage occurs.
Despite these capabilities, the adversary is assumed to be computationally bounded and therefore cannot break cryptographic primitives. Specifically, cannot recover the pre-shared key or the derived session key unless it is explicitly leaked, such as key compromise through side-channel attacks, weak storage protections, or inadvertent transmission via unsecured channels. While our protocol assumes secure key provisioning prior to deployment, we acknowledge that, in practice, key leakage is a real threat. To address this, the scheme supports periodic rekeying and session key regeneration through fresh nonces during each session establishment. Additionally, the damage of long-term key exposure is limited by the use of ephemeral session keys, which are never reused and are not stored persistently. It is also assumed that cannot forge valid MACs or authentication tags without the corresponding secret keys. The cryptographic algorithms used—namely ASCON-128 for encryption and ASCON-Hash for key derivation—are assumed to be secure, providing resistance against cryptanalytic attacks such as forgery, collision, and differential analysis. Notably, ASCON-128 was selected by the NIST Lightweight Cryptography standardization process, and has been shown to offer strong security with low computational overhead in constrained environments such as embedded systems and industrial control networks [27,28,29,30]. This makes it particularly suitable for Modbus-based IIoT applications. Additionally, all nonces used in the protocol, including and , are assumed to be generated using a cryptographically secure pseudorandom number generator and are unpredictable to the adversary.
The security goals of the adversary include compromising the confidentiality of Modbus payloads, forging or modifying protocol messages without detection, impersonating legitimate clients or servers, replaying previously captured valid messages, and attempting to recover long-term or session-specific keys. Under these assumptions, we demonstrate in the subsequent analysis that our protocol achieves mutual authentication, confidentiality, integrity, and replay protection even in the presence of an active adversary with full network control.
5.2. Initialization Phase Security Analysis
Mutual Authentication: Under the assumption that HMAC is existentially unforgeable under chosen-message attacks (UF-CMA), and the nonces and are chosen uniformly at random and never reused, the mutual authentication protocol ensures the following: A Modbus server can verify that it is communicating with the legitimate Modbus client who knows the pre-shared key . A Modbus client can verify that it is communicating with the legitimate Modbus server who knows .
We prove mutual authentication from both directions. (i). Server authenticates client: Given that the pre-shared key is only known to legitimate participants, and assuming the HMAC construction based on ASCON_MAC is secure against existential forgery under chosen-message attacks (UF-CMA), an adversary cannot forge a valid MAC on a fresh pair . Additionally, since the nonce is randomly generated per session and never reused, the server can reject any replayed or pre-computed . Upon receiving a valid , the server is assured that the request originated from a party who knows , thus authenticating the client. (ii). Client authenticates server: Upon receiving , the client verifies the using the pre-shared key. As before, if is unknown to the adversary, then constructing a valid is computationally infeasible under UF-CMA. Moreover, because the MAC binds to the original client-generated , the client can confirm that the server has received and processed its request, thereby preventing reflection or de-synchronization attacks. The freshness of also ensures replay resistance.
□
Conclusion. Since both authentication steps rely on cryptographically secure HMACs over unique session nonces and secret key material, and these cannot be forged or reused by an adversary under the stated assumptions, the protocol guarantees mutual authentication between the client and server. Therefore, an adversary controlling the communication channel cannot impersonate either party or interfere undetectably in the handshake process.
Formal Verification Result: We encoded the mutual authentication logic using ProVerif by defining the events
Session Key Secrecy: Assuming the hash function used in the session key derivation function is modeled as a random oracle, and that the pre-shared key is kept secret, the session key SK is indistinguishable from a random value to any probabilistic polynomial-time (PPT) adversary who does not possess , even with full control over the network.
We prove that the session key established between the Modbus client and server remains secret from any adversary under the standard Dolev–Yao threat model, augmented with the assumption that the hash function behaves as a random oracle.
The session key is derived from the shared key and two freshly generated, uniformly random nonces and . These nonces are included in the plaintext authentication messages exchanged during the initialization phase.
An adversary who does not know cannot forge valid or predict future nonces, and thus cannot insert itself into the key derivation process. Moreover, since the nonces are never reused, each session produces a unique key, even if the same is reused.
The key derivation function is modeled in the random oracle setting, meaning that unless is known, the input to the hash function is computationally hidden from the adversary. Consequently, the adversary cannot distinguish the resulting from a uniformly random 128-bit string.
Suppose by contradiction that an adversary can distinguish from a random string with non-negligible advantage. Then, must have queried the random oracle on the correct tuple , which requires knowledge of . However, without forging a valid MAC (which is infeasible under the UF-CMA assumption of HMAC), cannot learn whether a guessed key is correct. Thus, we reach a contradiction. □
Conclusion: Under the assumptions that the hash function used in session key derivation is modeled as a random oracle, the HMAC construction is existentially unforgeable under chosen-message attacks (UF-CMA), the nonces and are freshly generated and never reused, and the pre-shared key remains secret and known only to the legitimate client and server, we conclude that no probabilistic polynomial-time (PPT) adversary can compute or distinguish the derived session key from a random value. Consequently, the session key secrecy property is preserved against active and passive adversaries under the Dolev–Yao model.
Formal Verification Result: We modeled the secrecy of the session key
5.3. Secure Communication Phase Security Analysis
Once the session key has been securely established, the Modbus client begins transmitting encrypted application-layer messages using the authenticated encryption algorithm ASCON-128, encapsulated within a COSE_Encrypt0 structure. In this section, we analyze the confidentiality, integrity, and authenticity guarantees of this message transmission stage.
Message Confidentiality: Under the assumption that the ASCON-128 authenticated encryption scheme is IND-CCA-secure, and the session key SK remains secret, the secure Modbus transmission phase guarantees the confidentiality of the Modbus payload against any PPT adversary.
We assume a Dolev–Yao adversary who has full control over the communication channel: they can intercept, replay, modify, inject, or block any message exchanged between the client and server. However, the adversary does not know the session key , which is derived securely during the initialization phase as proven previously.
In the secure transmission phase, the Modbus client encrypts the plaintext payload M using the ASCON-128 authenticated encryption algorithm. The encryption input includes the plaintext message M, the session key , and optional associated data such as the protected header and unprotected header. The ASCON scheme outputs the encrypted message and an authentication tag , which are combined and encoded into the ciphertext field of the COSE_Encrypt0 structure.
Given that ASCON-128 is IND-CCA-secure, any adversary who does not possess the correct session key cannot distinguish between the encryption of two chosen messages nor decrypt any message encrypted under that key. Moreover, attempts to tamper with the ciphertext will be detected due to the built-in authentication tag, and the message will be rejected upon decryption. □
Conclusion: Under the assumptions that ASCON-128 provides IND-CCA security, and that the session key is known only to the legitimate Modbus client and server, it follows that the ciphertext exchanged during the secure transmission phase leaks no information about the underlying Modbus payload to any PPT adversary. Therefore, the confidentiality of the Modbus message is preserved. Formal Verification Result: ProVerif confirmed the correspondence between the encrypted message output by the client and the ciphertext accepted by the server. Specifically, the query returned
Message Integrity and Authenticity: Under the assumption that ASCON-128 is an authenticated encryption scheme with integrity of ciphertexts (INT-CTXT), and the session key is known only to the legitimate participants, any modification of the ciphertext or forgery of a valid message by an adversary will be detected and rejected with overwhelming probability.
We consider a Dolev–Yao adversary who has full access to the communication channel and can intercept, inject, replay, or modify messages. However, the adversary does not know the session key , which was securely established during the initialization phase and proven to remain secret.
In the secure communication phase, the Modbus client encrypts each payload using the ASCON-128 authenticated encryption scheme. Upon receiving a message, the Modbus server uses the shared session key and corresponding nonce to attempt decryption. The decryption function verifies the tag internally. If any part of the ciphertext or associated data has been altered, or if the ciphertext was not generated by someone possessing , the decryption will fail and the message will be rejected.
The INT-CTXT property of ASCON-128 ensures that it is computationally infeasible for any PPT adversary to generate a valid ciphertext–tag pair without knowing . This directly provides strong guarantees for message integrity. In addition, since only the legitimate sender can compute a valid tag over the message and associated context, successful verification at the receiver implies that the message originated from the party who shares —thereby establishing authenticity.
Moreover, because the tag computation includes associated data (such as protected headers), even tampering with protocol metadata or session context will result in decryption failure, ensuring contextual integrity as well. □
Conclusion: Given that ASCON-128 is INT-CTXT-secure, and that is known only to the legitimate parties, we conclude that the integrity and authenticity of the transmitted messages are guaranteed. Any attempt by an adversary to modify or forge messages will result in authentication failure and message rejection.
Formal Verification Result: The same correspondence assertion between message sent and message accepted also ensures message authenticity and integrity. ProVerif confirmed that no forged ciphertext can be accepted unless it was sent by an authenticated party.
Replay Protection: Under the assumption that iv and sequence numbers are never reused within the same session and are strictly monotonic across messages for each sender identity, the protocol guarantees replay protection in the secure transmission phase.
In each session, the Modbus client includes a unique iv and a strictly increasing sequence number in the unprotected header of each COSE_Encrypt0 message. The issuer identifier specifies the identity of the message originator, allowing the server to isolate and track sequence numbers on a per-client basis.
On the server side, for each known , a per-client state is maintained, recording the latest accepted sequence number or a sliding replay window. Upon receiving a new message, the server performs the following checks: (i) whether the value for the given has already been processed, or (ii) whether it is smaller than the expected next sequence number. If either case holds, the message is rejected as a replay.
Furthermore, because the , , and are bound to the authenticated ciphertext via the authenticated encryption scheme ASCON-128 (typically as associated data), any alteration or reuse results in authentication tag failure. This ensures that replayed ciphertext, even if bit-wise-identical, is detected based on prior sequence use or contextual mismatch during tag verification. An adversary operating under the Dolev–Yao model, capable of intercepting and resending prior messages, cannot bypass these defenses without also forging a valid tag under a new context. Given the security of ASCON-128 under the INT-CTXT and nonce-respecting assumptions, such forgeries are computationally infeasible. □
Conclusion: By embedding unique nonces and strictly increasing sequence numbers tied to the sender identity, and by enforcing per-sender replay validation and authenticated decryption, the protocol achieves strong replay protection. This guarantee holds against any PPT adversary in the Dolev–Yao model, provided that nonces and sequence numbers are used correctly and without reuse. Our current design assumes strictly increasing sequence numbers to protect against replay attacks. However, in practical environments, devices may experience unexpected reboots or desynchronization due to power loss, and networks may exhibit delays or packet reordering. To address these issues, sequence number windows (e.g., sliding window protocols) can be employed to tolerate minor reordering, and devices can securely persist their counters across reboots using non-volatile memory or secure elements. Alternatively, incorporating lightweight challenge–response mechanisms or timestamps can enhance robustness against such threats in unstable network conditions.
6. Experiments and Evaluation
In this section, we evaluate the performance and security effectiveness of the proposed secure Modbus protocol. The evaluation aims to answer the following key questions: RQ1. Does the proposed protocol introduce acceptable computational and communication overhead under constrained industrial device settings? RQ2. How does our design compare with existing lightweight secure Modbus enhancements in terms of efficiency and security guarantees?
6.1. Implementation and Experimental Setup
We implemented the proposed secure Modbus protocol entirely in C, using the ASCON-128 authenticated encryption algorithm and a lightweight CBOR encoder to support the COSE_Encrypt0 message structure. The cryptographic core is based on the official reference implementation of ASCON, released by its original designers. (
The experimental platform is a bare-metal embedded system based on an ARM Cortex-M4 microcontroller running at 120 MHz with 256 KB of RAM. All code was compiled using GCC 10.3. To obtain accurate performance data, we used the processor’s built-in Data Watchpoint and Trace (DWT) cycle counter, which enables fine-grained timing measurements without additional instrumentation.
We also performed packet-level trace analysis using Wireshark to visually inspect the difference between traditional Modbus TCP communication and our secure COSE-ASCON scheme.
6.2. Wireshark Packet-Level Trace
To complement our implementation, we performed packet-level inspection using Wireshark to visually demonstrate the security benefits of the proposed Modbus+ASCON scheme, as shown in Figure 7.
Figure 7a illustrates a traditional Modbus TCP message captured during a typical operation of the 0x03 function code. The entire message is transmitted in plaintext. As a result, passive adversaries can easily infer the control logic and operational details from intercepted packets. Moreover, without any cryptographic protection, such packets are vulnerable to tampering and replay attacks by active adversaries.
In contrast, Figure 7b shows a packet protected using our COSE-ASCON scheme. The Modbus payload is fully encrypted and encapsulated in a COSE_Encrypt0 structure. The protected header contains the algorithm identifier, while the unprotected header includes the sequence number, issuer ID (
6.3. Security Feature Comparison
6.3.1. Comparison with Existing Secure Modbus Schemes
To demonstrate the effectiveness of our proposed scheme, we compare it with representative Modbus TCP security enhancement approaches, as shown in Table 2.
Schemes such as [6,7] adopt AES for data confidentiality and RSA-based digital signatures for identity authentication. While these designs achieve basic security goals, their reliance on heavyweight public key operations and the absence of structured replay protection mechanisms limit their applicability in constrained environments. For instance, ref. [7] introduces synchronization identifiers to resist replay attacks, but such mechanisms remain vulnerable to manipulation due to lack of cryptographic binding.
The approach in [31] employs TLS directly atop Modbus TCP. Although this delivers robust end-to-end security through well-established cryptographic protocols, it incurs significant complexity in certificate management and demands a full TLS stack, which is often infeasible for lightweight industrial devices.
Schemes like [17] introduce timestamps to detect replays, but transmit them in plaintext, leaving them susceptible to tampering. Similarly, ref. [16] relies on the SM3 hash function to provide data integrity and identity verification, but lacks strong replay protection. The design in [8] enhances this by incorporating random nonces and timestamps to improve freshness and authenticity, but again transmits these elements unencrypted, which weakens their effectiveness in adversarial environments.
In contrast, our scheme integrates authenticated encryption using the ASCON-128 algorithm within the COSE_Encrypt0 structure. Critical metadata such as sequence numbers, nonces (
Furthermore, our scheme supports lightweight key update capabilities across sessions without requiring certificate-based infrastructures or TLS stack dependencies. Using a standardized COSE-based format and lightweight authenticated encryption, our solution offers a well-balanced combination of strong security, minimal overhead, and high interoperability, making it particularly well suited for deployment in resource-constrained industrial Modbus environments.
6.3.2. Comparison with Industrial Security Standards
Several standardization efforts have been developed to enhance the security of industrial communication protocols, notably IEC 62351 [32] and DNP3-SA [33]. As shown in Table 3, these standards offer valuable security guarantees but may not be optimized for highly constrained industrial environments, particularly in legacy or resource-limited deployments such as those using Modbus. IEC 62351 is a comprehensive security framework designed for power system protocols, including IEC 60870-5-104 [34] and IEC 61850 [35]. It integrates existing transport-layer security protocols such as TLS and IPsec to provide encryption, authentication, and secure key exchange. While it ensures strong security properties, its dependence on X.509 certificate infrastructures, public key cryptography (e.g., Diffie–Hellman key exchange), and full TLS/IPsec stacks introduces considerable complexity, computational burden, and memory footprint. As a result, IEC 62351 is often impractical for deployment on microcontroller-class Modbus devices with strict resource and latency constraints.
DNP3-SA is a lightweight security extension for the Distributed Network Protocol version 3 (DNP3), widely used in SCADA systems [36]. It employs symmetric key cryptography with message authentication codes (MACs) and sequence numbers to ensure message authenticity and freshness. However, DNP3-SA does not provide confidentiality, leaving sensitive data vulnerable to eavesdropping or manipulation over untrusted networks.
In contrast, our scheme is specifically tailored for lightweight industrial protocols like Modbus that lack native security features. It incorporates authenticated encryption using the NIST-standardized ASCON algorithm and employs COSE/CBOR encapsulation to ensure structured, compact, and interoperable message formats. Unlike DNP3-SA, our scheme provides full message confidentiality in addition to integrity and replay protection. Compared to IEC 62351, it achieves significantly lower overhead by avoiding certificate management and heavy transport-layer protocols. These characteristics make our solution especially suitable for resource-constrained IIoT devices that require minimal memory, fast processing, and compatibility with legacy fieldbus architectures.
6.4. Performance Evaluation
6.4.1. Latency and Runtime Overhead
We selected the Modbus security enhancement based on SM3 and SM4 [8] as a baseline for comparison, as it currently represents one of the most efficient lightweight solutions in terms of runtime performance among TLS-free secure Modbus implementations. Its use of domestic cryptographic primitives and minimal protocol overhead makes it particularly suitable for deployment in industrial control systems with strict resource constraints and real-time requirements.
Table 4 presents a detailed comparison of runtime performance between our proposed scheme and the scheme that utilizes SM3 for hashing and SM4 for symmetric encryption. The metrics include the time cost of key exchange and payload encryption/decryption on both the client and server sides, as well as the final Modbus PDU size.
From the client-side perspective, our scheme incurs a higher computational overhead. Specifically, the key exchange takes approximately 769 s in our design, compared to 491 s for the SM-based baseline. The encryption operation shows a more significant difference: 66.44 s for COSE-ASCON versus only 55 s for SM3/SM4. This increase is primarily due to the additional COSE structure, and the overhead of AEAD computation in software. Despite this, the overhead remains within acceptable bounds for Modbus applications, which typically operate with low message frequency and real-time margins in milliseconds.
On the server side, our scheme demonstrates a clear advantage. Key exchange is faster (274 s vs. 436 s), and decryption performance is dramatically better (4.8 s vs. 369 s). This confirms the efficiency of ASCON for authenticated decryption in software environments and shows that the proposed scheme is especially suitable for server-side deployment in resource-constrained industrial nodes.
In terms of message size, the final Modbus PDU size increases slightly from 28 bytes to 31 bytes due to the inclusion of COSE headers and authentication tags. The 3-byte overhead is minimal and does not significantly impact network bandwidth in typical Modbus deployments.
To further validate the lightweight nature of our scheme, we estimate the memory and energy efficiency based on our implementation results, as shown in Table 5. We conducted our evaluation using the official ASCON reference implementation [37] and the GmSSL cryptographic library [38], both compiled and executed in a simulated Linux environment. The results show that the ASCON-based implementation requires approximately 276 bytes of RAM and 2.5 KB of ROM, significantly outperforming the SM3/SM4 combination, which occupies a larger memory footprint due to internal buffers and S-box lookup tables. These findings confirm that our COSE+ASCON design is highly suitable for constrained IIoT environments with strict memory and code size limitations.
6.4.2. Cryptographic Computation Analysis
We further abstract the computation complexity of each scheme in terms of cryptographic operations in Table 6. Our design uses two hash invocations (ASCON-Hash) and a single ASCON-128 per message, while others may require additional MACs or separate encryption and hashing stages. RSA-based designs incur significant costs due to key size and signing overhead, and TLS encapsulates multiple layers of handshake and cipher negotiation.
Our scheme introduces two hash operations (one for HMAC in handshake; one for session key derivation) and a single invocation of the ASCON AEAD function per message. Compared with the SM3/SM4-based design, which requires multiple symmetric operations per message, our scheme reduces the number of cipher operations while retaining equivalent or stronger security properties.
In particular, although ASCON is a lightweight cipher, it combines both encryption and authentication in one pass, simplifying the design and reducing state management overhead. From the receiver’s perspective, the decryption side benefits from ASCON’s efficiency, resulting in faster processing as observed in our implementation.
Moreover, schemes relying on RSA incur significantly higher computational overhead due to expensive public key operations, which are unsuitable for constrained devices. TLS-based solutions, while secure and mature, bundle multiple layers of cryptographic operations, leading to opaque and relatively heavy computation.
The computation model confirms that our ASCON-based approach strikes a practical balance between performance and security. It reduces the number of cryptographic operations compared to some existing SM4-based designs, while offering modern authenticated encryption semantics and compatibility with lightweight industrial deployments.
7. Conclusions
In this paper, we present a lightweight security enhancement scheme for the Modbus TCP protocol that combines the ASCON-128 authenticated encryption algorithm with the standardized COSE_Encrypt0 message format. Our protocol provides mutual authentication, nonce-based session key derivation, and robust replay protection without altering Modbus semantics or relying on TLS. Experimental results on both embedded and Linux testbeds demonstrate that, despite modest additional overhead from CBOR encoding and AEAD processing, our scheme outperforms SM3/SM4-based approaches in server-side decryption efficiency and delivers stronger guarantees of identity binding and integrity. The modular, standards-compliant design makes it practical for deployment in resource-constrained industrial environments. Future work will focus on hardware acceleration and formal verification to further enhance performance and assurance.
Conceptualization, X.L. and J.L.; methodology, J.L.; software, Y.Z.; validation, Z.F. and X.L.; writing—original draft preparation, Z.F.; writing—review and editing, J.L. All authors have read and agreed to the published version of the manuscript.
The original contributions presented in this study are included in the article material. Further inquiries can be directed to the corresponding author.
Author Xiang Le, Ji Li and Zhaohong Fan was employed by the company Ningbo HollySys Information Security Research Institute Co., Ltd. The remaining authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.
The following abbreviations are used in this manuscript:
| IIoT | Industrial Internet of Things |
| PDU | Protocol Data Unit |
| COSE | CBOR Object Signing and Encryption |
| CBOR | Concise Binary Object Representation |
| AES | Advanced Encryption Standard |
| RSA | Rivest–Shamir–Adleman |
| HMAC | Hash-based Message Authentication Code |
| MAC | Message Authentication Code |
| AEAD | Authenticated Encryption with Associated Data |
| TLS | Transport Layer Security |
| IV | Initialization Vector |
| RAM | Random Access Memory |
| SM4 | Chinese Standard Block Cipher Algorithm |
| SM3 | Chinese Standard Hash Algorithm |
| NIST | National Institute of Standards and Technology |
| IKE | Internet Key Exchange |
| IPsec | Internet Protocol Security |
| DH | Diffie–Hellman |
| DNP3-SA | Distributed Network Protocol 3—Secure Authentication |
| IEC | International Electrotechnical Commission |
Footnotes
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.
Figure 1 The structure of the Modbus TCP application data unit.
Figure 2 Overview of secure Modbus protocol design.
Figure 3 The structure of COSE-based Modbus TCP application data unit.
Figure 4 Formal verification result of mutual authentication using ProVerif.
Figure 5 Formal verification result of session key secrecy using ProVerif.
Figure 6 Formal verification result of message confidentiality using ProVerif.
Figure 7 Wireshark packet captures: (a) plaintext Modbus communication, (b) encrypted Modbus using our proposed scheme.
Summary of notations.
| Notation | Description |
|---|---|
| | Identity of the client |
| | Identity of the server |
| | Session key shared between client and server |
| | Nonce generated by client |
| | Nonce generated by server |
| | Monotonically increasing sequence number |
| | Initialization vector used in AEAD encryption |
| M | Plaintext Modbus payload |
| | Encrypted Modbus payload |
| | Authentication tag generated by AEAD |
| | Message authentication code |
| | Associated authenticated data |
| ASCON_Encrypt | Authenticated encryption using ASCON-128 |
| ASCON_Decrypt | Authenticated decryption using ASCON-128 |
Comparison of security features across secure Modbus enhancements.
| Scheme | Conf. | Int./Replay | ID Binding | Std. Format | TLS-Free | Key Update |
|---|---|---|---|---|---|---|
| Modbus + SHA-2/AES | ✓ | ✓ | ✗ | ✗ | ✓ | ✗ |
| Modbus + MD5/RSA | ✓ | ✓ | ✗ | ✗ | ✓ | ✗ |
| Modbus over TLS | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ |
| Modbus + SHA256/AES | ✓ | ✓ | ✗ | ✗ | ✓ | ✗ |
| Modbus + SM3/SM4 | ✓ | ✓ | ✗ | ✗ | ✓ | ✗ |
| Modbus + SM enhanced | ✓ | ✓ | ✗ | ✗ | ✗ | ✓ |
| Our Scheme | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Conf.: confidentiality; Int./Replay: integrity and replay protection; ID Binding: binding of device identity in authentication; Std. Format: use of standardized data format (e.g., COSE); TLS-Free: does not rely on TLS/PKI infrastructure; Key Update: support for per-message or session key derivation.
Comparison with existing industrial security standards.
| Aspect | IEC 62351 | DNP3-SA | Our Scheme |
|---|---|---|---|
| Scope | Power system comm. | DNP3-based SCADA | Modbus IIoT systems |
| Protocol Layer | Transport | Application | Application |
| Cryptographic Features | TLS/IPsec | MAC-only | AEAD |
| Handshake Complexity | High (certs, DH) | Low | Low (no certs) |
| Resource Overhead | High | Low | Low |
| Encryption Algorithm | AES/TLS suite | None (MAC only) | ASCON-128 |
| Suitable for Constrained Devices | ✗ | ✓ | ✓ |
Performance comparison between our scheme and SM3/SM4-based baseline.
| Operation | Our Scheme ( | SM3/SM4 Baseline ( |
|---|---|---|
| Client Key Exchange | 769.00 | 491.46 |
| Client Encrypt | 66.44 | 54.86 |
| Server Key Exchange | 274.67 | 436.48 |
| Server Decrypt | 4.80 | 368.90 |
| Modbus PDU Size | 31 bytes | 28 bytes |
Memory usage comparison between SM3/SM4 and ASCON schemes.
| Scheme | RAM (Bytes) | ROM (KB) |
|---|---|---|
| SM3/SM4 | 480 | 5.2 |
| Our Scheme | 376 | 2.3 |
Comparison of computation overhead with related schemes.
| Schemes | Sender | Receiver |
|---|---|---|
| Modbus with SHA-2/AES [ | | |
| Mpdbus with MD5/RSA [ | | |
| Modbus over TLS [ | TLS | TLS |
| Modbus with SM3 [ | | |
| Modbus with SHA256/AES [ | | |
| Modbus with SM3/SM4 [ | | |
| Our Scheme | | |
H denotes a cryptographic hash function (e.g., SHA-256 or SM3);
Appendix A. Detailed ASCON-128 and ASCON-Hash Formulas
Appendix A.1. ASCON-128
ASCON-128 follows the Encrypt-then-MAC structure and operates in the following phases: Initialization: Assuming the 128-bit secret key K, 128-bit nonce N, and the In the initialization of ASCON-128, Processing Associated Data: ASCON processes associated data A in blocks of r bits by first appending a single bit 1 followed by the smallest number of 0 bits necessary to make the length of A a multiple of r. For each block Here, Processing Plaintext/Ciphertext: ASCON processes the plaintext P in blocks of r bits. The padding process appends a single 1 and the smallest number of 0 to the plaintext P such that the length of the padded plaintext is a multiple of r bits. The resulting padded plaintext is split into t blocks of r bits, Encryption. In each iteration, The last ciphertext block Decryption. In each iteration except the last one, the plaintext block Finally, the truncated cipher block is processed: Finalization: Calculate the tag T which consists of the last 128 bits of the state
Appendix A.2. ASCON-Hash
ASCON-Hash also uses a sponge construction with the same 320-bit internal state and consists of the following: Initialization: The 320-bit initial state of ASCON-Hash is defined by a constant IV that specifies the algorithm parameters in a similar format as for ASCON-128, followed by the maximal output length of Absorbing Message: ASCON-Hash processes the message M in blocks of r bits. The padding process is the same as for the plaintext of ASCON-128. Each block Squeezing: The hash output is extracted from the state in r-bit blocks The last output block
1. Thomas, G. Introduction to the modbus protocol. Extension; 2008; 9, pp. 1-4.
2.
3. Brooks, P. Ethernet/IP-industrial protocol. Proceedings of the ETFA 2001—8th International Conference on Emerging Technologies and Factory Automation; Antibes-Juan les Pins, France, 15–18 October 2001; Proceedings (Cat. No. 01TH8597) IEEE: Piscataway, NJ, USA, 2001; Volume 2, pp. 505-514.
4. Ethernet POWERLINK Standardization Group (EPSG). Ethernet Powerlink. Available online: https://www.ethernet-powerlink.org/ (accessed on 11 September 2025).
5. Swales, A. Open modbus/tcp specification. Schneider Electr.; 1999; 29, 19.
6. Shahzad, A.; Lee, M.; Lee, Y.K.; Kim, S.; Xiong, N.; Choi, J.Y.; Cho, Y. Real time MODBUS transmissions and cryptography security designs and enhancements of protocol sensitive information. Symmetry; 2015; 7, pp. 1176-1210. [DOI: https://dx.doi.org/10.3390/sym7031176]
7. Luo, X.; Li, Y. Research and implementation of Modbus TCP security enhancement protocol. J. Phys. Conf. Ser.; 2019; 1213, 052058.
8. Liu, Z.; Liang, T.; Wang, W.; Sun, R.; Li, S. Design and Implementation of a Lightweight Security-Enhanced Scheme for Modbus TCP Protocol. Secur. Commun. Netw.; 2023; 2023, 5486566. [DOI: https://dx.doi.org/10.1155/2023/5486566]
9. Dobraunig, C.; Eichlseder, M.; Mendel, F.; Schläffer, M. Ascon v1. 2: Lightweight authenticated encryption and hashing. J. Cryptol.; 2021; 34, pp. 1-42. [DOI: https://dx.doi.org/10.1007/s00145-021-09398-9]
10. Schaad, J. RFC 9052: CBOR Object Signing and Encryption (COSE): Structures and Process. 2022; Available online: https://datatracker.ietf.org/doc/rfc9052/ (accessed on 11 September 2025).
11. Fovino, I.N.; Carcano, A.; Masera, M.; Trombetta, A. Design and implementation of a secure modbus protocol. Proceedings of the Critical Infrastructure Protection III: Third Annual IFIP WG 11.10 International Conference on Critical Infrastructure Protection; Hanover, NH, USA, 23–25 March 2009; Revised Selected Papers 3 Springer: Berlin/Heidelberg, Germany, 2009; pp. 83-96.
12. Hayes, G.; El-Khatib, K. Securing modbus transactions using hash-based message authentication codes and stream transmission control protocol. Proceedings of the 2013 Third International Conference on Communications and Information Technology (ICCIT); Beirut, Lebanon, 19–21 June 2013; IEEE: Piscataway, NJ, USA, 2013; pp. 179-184. [DOI: https://dx.doi.org/10.1109/ICCITechnology.2013.6579545]
13. Shang, W.; Qiao, Q.; Wan, M.; Zeng, P. Design and Implementation of Industrial Firewall for Modbus/TCP. J. Comput.; 2016; 11, pp. 432-438. [DOI: https://dx.doi.org/10.17706/jcp.11.5.432-438]
14. Pricop, E.; Fattahi, J.; Parashiv, N.; Zamfir, F.; Ghayoula, E. Method for authentication of sensors connected on modbus tcp. Proceedings of the 2017 4th International Conference on Control, Decision and Information Technologies (CoDIT); Barcelona, Spain, 5–7 April 2017; IEEE: Piscataway, NJ, USA, 2017; pp. 0679-0683. [DOI: https://dx.doi.org/10.1109/CoDIT.2017.8102673]
15. Chochtoula, D.; Ilias, A.; Stamatiou, Y.C.; Makris, C. Integrating elliptic curve cryptography with the Modbus TCP SCADA communication protocol. Future Internet; 2022; 14, 232. [DOI: https://dx.doi.org/10.3390/fi14080232]
16. Yi, F.; Zhang, L.; Yang, S.; Zhao, D. A security-enhanced Modbus TCP protocol and authorized access mechanism. Proceedings of the 2021 IEEE Sixth International Conference on Data Science in Cyberspace (DSC); Shenzhen, China, 9–11 October 2021; IEEE: Piscataway, NJ, USA, 2021; pp. 61-67.
17. Lin, Y.C.; Lin, C.F.; Chen, K.H. Security enhancement of industrial modbus message transmission with proxy approach. Proceedings of the 2021 IEEE 3rd Eurasia Conference on IoT, Communication and Engineering (ECICE); Yunlin, Taiwan, 29–31 October 2021; IEEE: Piscataway, NJ, USA, 2021; pp. 90-95.
18. Katulić, F.; Sumina, D.; Groš, S.; Erceg, I. Protecting Modbus/TCP-Based Industrial Automation and Control Systems Using Message Authentication Codes. IEEE Access; 2023; 11, pp. 47007-47023. [DOI: https://dx.doi.org/10.1109/ACCESS.2023.3275443]
19. Zhang, D.; Gao, Y.; Pan, Q.; Yang, C. Ultra-Low Latency Security Hardening of Modbus/TCP Protocol Based on ZUC Cryptographic Algorithm. Proceedings of the 2024 IEEE 12th International Conference on Information, Communication and Networks (ICICN); Guilin, China, 21–24 August 2024; pp. 25-30. [DOI: https://dx.doi.org/10.1109/ICICN62625.2024.10761885]
20. Schaad, J. CBOR Object Signing and Encryption (COSE), RFC 9052; Internet Engineering Task Force (IETF), RFC Editor: Fremont, CA, USA, 2022.
21. Bormann, C.; Hoffman, P. Concise Binary Object Representation (CBOR), RFC 8949; Internet Engineering Task Force (IETF), RFC Editor: Fremont, CA, USA, 2020.
22. Esposito, M.; Sciarroni, M.M.; Fava, T.; Belli, A.; Palma, L.; Storti, E.; Pierleoni, P. Experimental Evaluation of End-to-End Security Protocols for the Internet of Everything. Proceedings of the 2024 IEEE 8th Forum on Research and Technologies for Society and Industry Innovation (RTSI); Milano, Italy, 18–20 September 2024; pp. 13-18. [DOI: https://dx.doi.org/10.1109/RTSI61910.2024.10761793]
23. Morabito, R.; Jimenez, J. IETF Protocol Suite for the Internet of Things: Overview and Recent Advancements. IEEE Commun. Stand. Mag.; 2020; 4, pp. 41-49. [DOI: https://dx.doi.org/10.1109/MCOMSTD.001.1900014]
24. Cooper, G. FIDO IoT Spec. Technical Report, FIDO Alliance. 2020; Available online: https://fidoalliance.org/specs/fidoiot/FIDO-IoT-spec-v1.0-wd-20200730.html (accessed on 11 September 2025).
25. Eckert, M.P.M.R.T.; Behringer, M.; Watsen, K. Bootstrapping Remote Secure Key Infrastructure (BRSKI). 2021; Technical Report, RFC 8995 Available online: https://datatracker.ietf.org/doc/html/rfc8995 (accessed on 11 September 2025).
26. Blanchet, B.; Smyth, B.; Cheval, V.; Sylvestre, M. ProVerif 2.00: Automatic cryptographic protocol verifier, user manual and tutorial. Version; 2018; 16, pp. 5-16.
27. Ellsworth, E.; Boztayev, D.; Shah, P.; Quinn, L.; Aslan, S. Implementation of the Ascon Encryption Algorithm for Secure Industrial IoT Networks. Proceedings of the 2025 International Conference on Computer, Information and Telecommunication Systems (CITS); Colmar, France, 16–18 July 2025; IEEE: Piscataway, NJ, USA, 2025; pp. 1-7. [DOI: https://dx.doi.org/10.1109/CITS65975.2025.11099482]
28. Koppuravuri, A.; Pasupuleti, H.; Gvk, S.; Bapat, J. A high throughput ASCON architecture for secure edge iot devices. Proceedings of the 2024 37th International Conference on VLSI Design and 2024 23rd International Conference on Embedded Systems (VLSID); Kolkata, India, 6–10 January 2024; IEEE: Piscataway, NJ, USA, 2024; pp. 486-491. [DOI: https://dx.doi.org/10.1109/VLSID60093.2024.00087]
29. Kaur, J.; Cintas Canto, A.; Mozaffari Kermani, M.; Azarderakhsh, R. A Survey on the Implementations, Attacks, and Countermeasures of the NIST Lightweight Cryptography Standard: ASCON. Acm Comput. Surv.; 2025; 58, pp. 1-16. [DOI: https://dx.doi.org/10.1145/3744640]
30. Raj, K.; Bodapati, S. Fpga based light weight encryption of medical data for iomt devices using ascon cipher. Proceedings of the 2022 IEEE International Symposium on Smart Electronic Systems (iSES); Warangal, India, 18–22 December 2022; IEEE: Piscataway, NJ, USA, 2022; pp. 196-201.
31. Wang, J.; Liu, M.; Xu, A.; Hu, B.; Han, X.; Zhou, X. Research and implementation of secure industrial communication protocols. Proceedings of the 2020 IEEE International Conference on Artificial Intelligence and Information Systems (ICAIIS); Dalian, China, 20–22 March 2020; IEEE: Piscataway, NJ, USA, 2020; pp. 314-317. [DOI: https://dx.doi.org/10.1109/ICAIIS49377.2020.9194854]
32.
33.
34.
35.
36. Gilchrist, G. Secure authentication for DNP3. Proceedings of the 2008 IEEE Power and Energy Society General Meeting-Conversion and Delivery of Electrical Energy in the 21st Century; Pittsburgh, PA, USA, 20–24 July 2008; IEEE: Piscataway, NJ, USA, 2008; pp. 1-3.
37. Ascon Project Team. Reference, Highly Optimized, Masked C and ASM Implementations of Ascon. Available online: https://github.com/ascon/ascon-c (accessed on 11 September 2025).
38. Guanzhi Team. GmSSL. Available online: https://github.com/guanzhi/GmSSL (accessed on 11 September 2025).
© 2025 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/). Notwithstanding the ProQuest Terms and Conditions, you may use this content in accordance with the terms of the License.