Secured Real-Time Machine Communication Protocol

Abstract

In this paper, we introduce the Secured Real-Time Machine Communication Protocol (SRMCP), a novel industrial communication protocol designed to address the increasing demand for security and performance in Industry 4.0 environments. SRMCP integrates post-quantum cryptographic techniques, including the Kyber Key Encapsulation Mechanism (Kyber-KEM) and AES-GCM encryption, to ensure robust protection against both current and future cryptographic threats. We also present an innovative “Port Hopping” mechanism inspired by frequency hopping, enhancing security by distributing communication across multiple channels. Comparative performance analysis was conducted with widely-used protocols such as ModBus and the OPC UA, focusing on key metrics such as connection, reading, and writing times across local and remote networks. Results demonstrate that SRMCP outperforms ModBus in reading and writing operations while offering enhanced security, although it has a higher connection time due to its dual-layer encryption. The OPC UA, while secure, lags significantly in performance, making it less suitable for real-time applications. The findings suggest that SRMCP is a viable solution for secure and efficient machine communication in modern industrial settings, particularly where quantum-safe security is a concern.

1. Introduction

Industrial communication protocols are fundamental to ensuring the reliable and efficient transfer of data in industrial networks. These protocols are designed to operate across different layers of the TCP/IP model, with each layer contributing unique features that collectively shape the functionality, performance, and security of industrial communication systems. From the physical layer to the application layer, these protocols underpin critical operations in manufacturing, process automation, and resource management. However, their inherent features and limitations often pose challenges when adapting to the increasing complexity and demands of modern industrial environments.

With the advent of Industry 4.0, characterized by the integration of IoT devices, massive datasets, real-time analytics, and artificial intelligence-driven decision-making, traditional communication protocols often struggle to meet the stringent requirements for performance, scalability, and security [1]. The interconnected nature of Industry 4.0 systems exposes networks to new vulnerabilities, such as cyber attacks, unauthorized access, and data breaches, necessitating the development of communication protocols that are not only efficient but also resilient against these threats. Moreover, the increasing adoption of post-quantum technologies introduces additional requirements for cryptographic robustness to ensure long-term security in the face of advancing quantum computing capabilities [2].

To address these challenges, we introduce a novel industrial communication protocol named the Secure Real-Time Machine Communication Protocol (SRMCP). SRMCP is a cross-layer protocol that spans from the data-link layer to the application layer, integrating advanced security measures while maintaining the performance requirements of industrial applications. The security architecture of SRMCP incorporates widely accepted cryptographic techniques, including asymmetric and symmetric encryption standards. For example, the Diffie–Hellman Key Exchange Agreement (DH-KEA) [3] and the Kyber Key Encapsulation Mechanism (Kyber-KEM) [4] are utilized for secure key exchange, while the Advanced Encryption Standard in Galois Counter Mode (AES-GCM) provides robust encryption suitable for post-quantum environments [5].

In addition to its robust cryptographic framework, SRMCP introduces an innovative mechanism called “Port Hopping”. Inspired by Frequency Hopping Spread Spectrum (FHSS) techniques [6], which distribute signals across multiple frequency channels to enhance security and reliability, “Port Hopping” disperses data transmission across a wide range of TCP/IP sockets. This approach not only disguises traffic patterns but also makes it exceedingly difficult for adversaries employing Deep Packet Inspection (DPI) or machine learning algorithms to identify or compromise the communication stream. The protocol ensures seamless reassembly of data on the client side, thereby preserving transaction integrity while significantly enhancing resilience against traffic analysis attacks.

In summary, the proposed SRMCP protocol brings the following contributions:

1.

Design of SRMCP: A novel industrial communication protocol that integrates post-quantum cryptographic techniques such as the Kyber Key Encapsulation Mechanism (Kyber-KEM) and AES-GCM encryption, providing robust security against emerging quantum computing threats.

2.

Introduction of Port Hopping: Inspired by frequency hopping in wireless communications, this mechanism significantly enhances security by distributing communication across multiple TCP/IP sockets, obfuscating traffic patterns, and mitigating risks from advanced traffic analysis techniques.

3.

Real-Time Transaction Mechanism: A robust transaction mechanism ensures compliance with IEC 61131 standards for real-time systems, as well as addressing challenges such as resource management and memory leak prevention.

4.

Implementation in Go: The protocol has been implemented in the Go programming language, leveraging its concurrency capabilities to optimize performance. The implementation is publicly available to foster further research and development.

5.

Comprehensive Evaluation: A detailed performance evaluation compares SRMCP with widely used protocols such as Modbus and the OPC UA across different scenarios, including local loopback, local networks, and remote networks via a VPN. The results demonstrate SRMCP’s superior performance in reading and writing operations while maintaining strong security guarantees.

The rest of the paper is organized as follows: Section 2 reviews the major existing industrial communication protocols. Section 3 details the design of the SRMCP protocol. Section 5 describes the implementation and evaluation methods, while Section 6 presents the testing results and analysis. Finally, Section 7 provides the conclusion and outlines future research directions.

2. Existing Protocols

2.1. Application Layer Protocols

Modbus TCP is an extension of the Modbus protocol that uses TCP/IP for communication

Table 1. Advantages and disadvantages of existing industrial communication protocols.

Protocol	Year Developed	TCP/IP Layer	Advantages	Disadvantages
Modbus TCP	1999	Application	Simple, and widely supported	Limited security, non-ideal for large data transfer
OPC UA	2006	Application	Enhanced security and open standards	Complex implementation, high computational cost
PROFINET	2003	Transport	Support real-time and high speed	proprietary and higher cost
EtherCAT	2003	Data Link	low cost, reliable and high efficiency	non-ideal for real-time, potential interoperability issues
CAN Bus	1983	Data Link	Highly reliable, efficient for short messages	Limited data transfer rate, not suitable for large-scale networks

. It operates at the application layer of the TCP/IP model. The protocol is simple to implement and widely supported, making it easy to integrate with a variety of devices and systems [7]. It is suitable for communication over Ethernet networks, facilitating remote monitoring and control [7]. While Modbus TCP can utilize TLS sockets for encryption and authentication, it remains vulnerable to certain types of cyber-attacks, such as replay attacks, denial of service attacks, and unauthorized device access with forged certificates [8]. These vulnerabilities stem from the protocol’s lack of native mechanisms to validate message integrity and prevent session hijacking. Furthermore, Modbus TCP is not ideal for large and complex data transfers due to its simplicity [7].

The OPC Unified Architecture (OPC UA) is a machine-to-machine communication protocol for industrial automation developed by the OPC Foundation. It operates at the application layer. The OPC UA is platform-independent and ensures interoperability across various systems and devices [9]. It provides robust security features, including encryption, authentication, and auditing, to protect data integrity and confidentiality [10]. However, the complexity of implementation due to its comprehensive feature set [9] and higher computational resource requirements can be a constraint for systems with limited processing power [11].

2.2. Transport Layer Protocols

PROFINET is an industrial Ethernet protocol developed by Siemens designed to address the diverse needs of industrial automation. It primarily operates at the transport and application layers of the TCP/IP model for non-real-time communication, where it employs Transport Layer Security (TLS) for encryption. While PROFINET supports user authentication and authorization, these features are typically provided through associated proprietary software suites rather than being natively integrated into the protocol itself [12]. For real-time communication, including real-time (RT) and isochronous real-time (IRT) operations, PROFINET bypasses the transport layer and functions directly at layer 2 (data link layer) of the OSI model. This design ensures low-latency, high-speed data transfer necessary for time-critical industrial applications, but it also means that no encryption is supported at layer 2, leaving real-time communication potentially exposed to security risks such as eavesdropping or tampering [12]. Although PROFINET is an open technology and does not require license fees, its implementation often incurs significant costs. These arise from the purchase of third-party software development kits (SDKs), specialized hardware components like managed switches, and industrial-grade network interfaces. Such requirements make PROFINET relatively expensive for deployment, particularly in cost-sensitive environments [13]. Furthermore, the protocol’s inherent complexity, especially in configuring its real-time features and diagnostic capabilities, demands specialized expertise for installation and maintenance, contributing to increased operational costs [14].

2.3. Network Layer Protocols

EtherNet/IP (Ethernet Industrial Protocol) is an application layer protocol that uses standard Ethernet and TCP/IP for industrial automation applications. EtherNet/IP facilitates easy integration with existing network infrastructure by using standard Ethernet [15]. It supports both real-time and non-real-time communication, providing flexibility for various industrial applications [15]. However, bandwidth limitations for high-frequency real-time data can affect performance in some scenarios [16], and the need for robust network infrastructure to avoid collisions and delays increases the complexity and cost of deployment [17].

2.4. Data Link Layer Protocols

EtherCAT (Ethernet for Control Automation Technology) is a high-performance Ethernet-based fieldbus system that operates at the transport layer. EtherCAT is known for its extremely low latency and jitter, providing precise and deterministic communication [18]. It is highly efficient and has low hardware costs, often utilizing standard Ethernet components and requiring minimal additional hardware due to its innovative processing of Ethernet frames [18]. However, EtherCAT has limited support for real-time communication, which can be a limitation in some applications [19]. Additionally, vendor-specific implementations can lead to interoperability issues, requiring careful management to ensure seamless operation in multi-vendor environments [20].

The Controller Area Network (CAN) protocol is widely used in automotive and industrial applications. It operates at the data link layer of the TCP/IP model. CAN is highly reliable and robust in noisy environments, making it ideal for industrial and automotive applications [21]. It is efficient for short messages, providing quick and reliable communication for control signals [21]. However, CAN has a limited data transfer rate, which can be a constraint for applications requiring high data throughput [22], and it is not suitable for large-scale networks without additional infrastructure, limiting its scalability [23].

3. Methodology-SRMCP Protocol Design

In this section, we present the design and test methods of SRMCP. We make the following assumptions in order to demonstrate SRMCP:

1.

Both the client and server have their own private x509 key and certificates assigned by the same trusted certificate authority. Key and certificate creation are beyond the scope of SRMCP.

2.

Both the client and server are capable of TCP/IP stack and opening IP sockets with Transport Layer Security (TLS). The implementation of TCP/IP stack and sockets is beyond the scope of SRMCP.

3.

Proper routing configuration exists to allow the client and server to reach each other. Routing and switching are beyond the scope of SRMCP.

3.1. Phase and Communication Procedure

Similar to OPC UA, SRMCP has multiple phases for establishing secured communication between the client and server, as shown in Figure 1.

3.1.1. “Discovery” Phase

The first phase, “Discovery”, is a variation of the standard TLS handshake. The server will close the connection immediately if the client certificate is not from a trusted certificate authority. Thus, the server remains silent for any untrusted client to prevent any probing.

3.1.2. “Hand Shake” Phase

The “Handshake” phase begins when the client successfully establishes a TLS connection with the server. The following steps outline the information exchange process:

1.

Step 1: The client generates public and private keys based on the Kypber algorithm. Then, the public key is packed and sent to the server.

2.

Step 2: The server unpacks the public key from the client. Then, the server encapsulates a shared key with the client’s public key and sends it back to the client as a cipher.

3.

Step 3: The client decapsulates the cipher with its private key and extracts the shared key.

4.

Step 4: The client and server use the shared key with AES-GCM encryption for all future communications.

The “handshake” phase implements the Kyber-KEM described in [4]. Compared to DH-KEA, where the cryptography is based on a discrete logarithm problem that can be solved efficiently by Shor’s algorithm [24], the cryptography in Kyber-KEM is based on the Learning With Errors (LWE) problem. The LWE problem involves finding a secret vector given a series of linear equations with noise, which is hard even for quantum computers due to the difficulty of lattice problems [25].

AES-GCM is considered relatively quantum-safe compared to the encryption scheme DH-KEA due to its basis in symmetric key cryptography, which quantum computers cannot break as easily. While Grover’s algorithm provides a quadratic speedup, reducing the effective key length, a 256-bit AES key would still require $2^{128}$ operations to break, which remains computationally infeasible. Additionally, AES-GCM provides authentication alongside encryption, enhancing security.

Testing and evaluations of post-quantum cryptographic algorithms, including AES-GCM and Kypber KEM, have been integrated into various cryptographic libraries, such as the wolfSSL library [2], in collaboration with the Open Quantum Safe project. These evaluations are part of ongoing efforts by organizations like the National Institute of Standards and Technology (NIST) [26] to ensure the robustness of cryptographic methods against quantum threats. For example, performance and security evaluations on FPGA platforms have demonstrated the feasibility and strength of AES-GCM in post-quantum scenarios [27].

3.1.3. Data Link Phase

The “Data Link Phase” facilitates the creation of the Data Link (DL). All messages exchanged during this phase are encrypted with the shared key using the AES-GCM algorithm. The procedures are as follows:

1.

Step 1: The client sends a Data Link Request (DL-Req) to the server, requesting the server to open a new TLS listener for a specified duration.

2.

Step 2: The server opens a new TLS listener on a random port number with its x509 certificate. The port number is then sent to the client via a Data Link Response (DL-Res).

3.

Step 3: The client attempts to establish a TLS connection to the server using the provided port number. If the client does not connect to the new TLS listener within the specified time indicated in Step 1, the server closes the TLS listener. Otherwise, the server closes the TLS listener once the client has successfully established the connection as a DL.

4.

Step 4: The client repeats Step 1 multiple times to create several DLs.

3.1.4. Communication Phase

The “Communication Phase” facilitates data exchange between the client and server through two operations: read and write. The data on the server are organized as nodes, which will be described in later sections.

1.

Read: The read operation starts with the client sending a read request to the server with a node ID indicating the target node. The server then replies with the current value of the node.

2.

Write: The write operation starts with the client sending a write request to the server with a node ID and a new value. The server updates the node value and sends the current value back to the client for verification.

All messages during this phase are encrypted with the shared key using the AES-GCM algorithm. Additionally, port hopping is performed for each operation. On the client side, request messages are sent through one of the DLs, chosen randomly. A transaction object is created in the client’s memory for each operation, which includes a unique ID, a timeout timer, and pre-allocated memory space for storing message segments. The unique ID is included in the header of the request message. The detailed message structure will be explained in later sections.

The server breaks the response into multiple segments after encryption, each with a header containing the unique ID and the segment sequence. The server simultaneously sends each segment through a randomly chosen DL. Due to the inherent randomness of networks, each segment arrives at the client in a natural and genuinely random order. Once all segments are received by the client, the client reassembles the response from segments based on their index. Then, the client decrypts the response. If the operation is completed before the timeout timer of the corresponding transaction, the client marks the transaction as successful. Otherwise, the transaction is considered a timeout, and a new request must be made. The transaction procedures are illustrated in Figure 2.

Through the use of transactions and port hopping, the client ensures real-time communication where all responses must be received within a fixed time. Additionally, traffic between the client and server is scattered randomly across multiple TLS connections. The segments of multiple ongoing responses could be received by the client in any order, making it difficult even for AI to capture traffic features, as AI cannot learn from randomness [28]. This also dramatically increases the difficulty of breaching the AES-GCM encryption because the cipher needs to be reassembled from a random order protected by the encrypted header. It leads to a paradox that for attempting the breach of AES-GCM based on ciphers, the AES-GCM must be breached first to obtain the cipher. Additionally, the port hopping mechanism offloads the communication overhead due to message disassembly and assembly by asynchronously utilizing multiple TLS connections, effectively creating independent queues, concurrent transmission, and message handling. This improves performance over protocols that rely on a single port [29].

3.1.5. “Termination” Phase

The “Termination” phase only occurs when the client intends to terminate the communication with the server. This phase starts with the client closing the connections of both the control channel and data links. Then, the server will terminate all processes associated with the client’s connections.

3.2. Message Structure

The message structure of SRMCP is illustrated in Figure 3, which includes three parts:

1.

Pre-Header: This contains a list of 8 bytes, in which the first 4 bytes represent an unsigned integer indicating the length of the header, and the last 4 bytes represent an unsigned integer indicating the length of the body.

2.

Header: This contains fields including the message type, the unique ID of the sender, the timestamp, and the unique ID of the corresponding transaction. Optionally, the header also includes the segment index and the number of segments if port hopping is engaged.

3.

Body: This contains the actual payload, whose content depends on the message type indicated inside the header.

The pre-header is encrypted by TLS asymmetric encryption only since it only contains information related to the length of the header and body. It is designed to allow both the server and client to allocate just enough memory space as a buffer for messages to improve performance and prevent memory overflow. The fields of the header allow the server to verify the client ID and source to prevent cross-origin resource-sharing attacks and allow the client to associate the message with the transaction. Both the pre-header and header are designed to contain only the necessary information, while the body is to be extended as much as possible. Both the header and the body are encrypted with the shared secret exchanged via Kypber KEM.

The fields of the message body depend on the message type indicated by the header as follows:

1.

Handshake: The message body from the client side includes the Kyber public key. The message body from the server side includes the encapsulated shared secret as cipher text. Both are in raw bytes encrypted by TLS.

2.

Discovery: The message body from the client side is empty. The message body from the server side includes a list of nodes. The list of nodes is encoded in JSON format rather than raw bytes.

3.

Read: The message body from the client side contains a list of the IDs and a list of the names of the nodes to be read. The server will return one read response per node, in which the body contains the ID and the name of the node, as well as the value.

4.

Write: The message body from the client side includes the ID and name of the node, as well as the value to be written. The message body from the server side contains the same fields. Both message bodies are encoded in JSON format.

SRMCP adopts JSON encoding for the header and the body, which contains both the field name and value instead of value only. This allows the received information to be checked with a predefined schema to eliminate any unwanted or malicious data. Additionally, it supports a highly extendable message body without limiting data to a fixed location in the array of bytes. Hence, future extensions or arbitrary data structures could be more easily implemented. The SRMCP message does not include a checksum field because the AES-GCM can authenticate the message’s integrity. Hence, additional checksum serves no purpose but only decreases the performance.

3.3. Primary Data Structure-Node

The primary data structure of SRMCP is defined as the node, which contains the following mandatory fields:

1.

ID: A unique identifier per node.

2.

Name: A human-friendly name that is also used to identify the node. The name should be short and abstract but can be identical for multiple nodes.

3.

Type: A field that indicates the type of data stored in this node.

4.

Parents: A list of other nodes to which this node is linked.

5.

Children: A list of other nodes that are linked with this node.

6.

Value: The value of the data stored in this node.

7.

Description: A short description of the node, which is optional.

8.

Read: A callable serves as the interface to update the node’s value from the hardware interface or client for other communication protocols.

9.

Write: A callable serves as the interface to push the node’s value to the hardware interface or through the client for other communication protocols.

The ID of the node is used as the index for storing the node on both the client side and the server side. The relationships between nodes are recorded via the parent and child fields, but the nodes will be stored as a one-dimensional array. The value field can be a simple native type such as integer or float numbers, or a complex data type that has its own fields. This is possible because JSON encoding is used for the message body when transmitting the value of nodes. The “Read” and “Write” fields are fined to allow the node data structure to be compatible with hardware interfaces or other communication protocols.

4. Vulnerability Analysis

This section analyzes the security vulnerabilities addressed by the proposed SRMCP protocol and evaluates its robustness against widely recognized attack models. It further highlights how SRMCP mitigates these threats and compares its security features to PROFINET Security and OPC UA.

4.1. Attacker Model

The attacker is assumed to possess the following capabilities:

1.

Eavesdropping: The ability to monitor network traffic to capture sensitive data, including authentication tokens and transmitted messages.

2.

Man-in-the-Middle (MitM) Attacks: The ability to intercept, modify, or inject packets, potentially disrupting or manipulating communication between the client and server.

3.

Replay Attacks: The capability to reuse previously captured valid packets to disrupt system operations or gain unauthorized access.

4.

Traffic Analysis: The ability to infer sensitive data or communication patterns using statistical analysis or machine learning on observed traffic.

5.

Data Injection/Tampering Attacks: The attacker injects malicious data or modifies legitimate data within the communication stream to disrupt operations or compromise system integrity.

6.

Post-Quantum Attacks: Access to quantum computing resources capable of breaking classical cryptographic schemes.

4.2. Security Measures in SRMCP

SRMCP employs advanced security mechanisms designed to counter these threats:

• Port Hopping: Inspired by frequency hopping, SRMCP dynamically distributes communication across multiple TCP/IP sockets as encrypted, out-of-order segments. This mechanism obfuscates traffic patterns and mitigates threats from traffic analysis, MitM attacks, and eavesdropping.
• Data Integrity and Authentication: SRMCP uses Transport Layer Security (TLS) and AES-GCM to ensure data authentication and integrity. Any tampered or injected data fails both the TLS integrity check and the AES-GCM decryption integrity verification, effectively thwarting data injection and tampering attacks.
• Replay Attack Prevention: SRMCP employs unique transaction identifiers and strict timeout mechanisms to detect and reject replayed packets.
• Post-Quantum Cryptography: The use of the Kyber Key Encapsulation Mechanism (Kyber-KEM) for secure key exchange and AES-GCM for data encryption provides robust, quantum-resistant protection against future quantum attacks.

4.3. Comparison with PROFINET Security

PROFINET Security, while effective for non-real-time tasks through TLS-based encryption and access control, lacks encryption for real-time (RT and IRT) communication, as it relies on layer 2 protocols. This limitation exposes real-time operations to vulnerabilities such as eavesdropping, MitM attacks, traffic analysis, and data tampering. In contrast, SRMCP provides end-to-end cryptographic protection across all communication phases, ensuring secure real-time operations without compromising performance.

4.4. Comparison with the OPC UA

The OPC UA is renowned for its robust security features, such as built-in encryption, authentication, and user access controls. However, it exhibits several limitations:

• Performance Impact: The OPC UA’s extensive security measures, including certificate management and user authentication, introduce significant computational overhead, making it unsuitable for real-time applications. In contrast, SRMCP focuses exclusively on ensuring secure communication and delegating user authentication and authorization responsibilities to application-level software. Furthermore, SRMCP employs concurrent transmission mechanisms to offset computational overhead, maintaining high performance and ensuring low-latency communication.
• Not Quantum-Safe: The OPC UA relies on traditional cryptographic methods, such as the Diffie–Hellman key exchange, which are vulnerable to future quantum attacks. SRMCP overcomes this limitation by incorporating a post-quantum cryptographic technique, the Kyber Key Encapsulation Mechanism (Kyber-KEM), ensuring robust security even against adversaries equipped with quantum computing capabilities.
• Complexity: The OPC UA’s extensive feature set increases its implementation and maintenance complexity, often resulting in a higher risk of misconfiguration and associated vulnerabilities. SRMCP simplifies deployment by minimizing configuration requirements, relying only on pre-established client and server certificates. Additionally, it offers a programmable interface for seamless integration with diverse data structures and IO functions, enhancing flexibility and usability.

5. Implementation and Evaluation

The SRMCP is implemented in the Go programming language, with the repository available at the SRMCP Go Repository (https://github.com/ulfaric/srmcp, accessed on 5 December 2024). The Go programming language was chosen for its flexibility in creating concurrent subroutines, which SRMCP heavily depends on for transaction handling and concurrent messaging.

Compared to other protocols in terms of security, SRMCP stands out due to its use of Kyber KEM (implemented via Cloudflare CIRCL) (https://github.com/cloudflare/circl, accessed on 5 December 2024) and the combination of symmetric and asymmetric encryption. Since other protocols do not incorporate any quantum-safe encryption methods, the evaluation of SRMCP focuses on performance, particularly the overhead that multi-layer encryption may cause in bursts of short operations, such as reading a single node/register. ModBus and the OPC UA are chosen as competitors since the former is widely adopted and offers the most simple communication procedures and packet structure but does not support built-in encryption; the latter is gaining popularity and supports encryption but utilizes complex communication procedures and packet structure. Consequently, a Modbus client is implemented in Go, and an OPC UA client is implemented with the Python-based open-source library “asyncua”. A server is created to run Modbus, the OPC UA, and SRMCP simultaneously, with a series of Modbus registers pre-defined and then converted to nodes in OPC UA and SRMCP. With the clients, a series of operations are performed, including initializing the connection with the server and reading/writing operations. The completion time of each operation is collected in milliseconds. The server is placed in three scenarios:

1.

Local Placement: The server operates as a container on the same physical host where the clients reside. In this scenario, communication between the client and server occurs through the local loopback interface, which introduces minimal latency. This setup allows for precise measurement of the computational delay associated with each protocol.

2.

Local Network Placement: The server is hosted on a separate physical machine within the same local network. This configuration is typical in air-gapped OT networks, where security and isolation from external networks are prioritized. This scenario is used to test whether SRMCP can achieve acceptable performance with generic hardware in an OT network environment.

3.

VPN over an Internet Placement-Remote Network: The server is hosted on a separate physical machine located on a remote network, both geographically and logically distant. Connectivity to this remote network is established via a VPN over the Internet. This scenario is common in Industry 4.0 environments, where sensor readings may be streamed to cloud platforms or remote operations are performed. This scenario is to test if the performance difference between the three protocols will be diluted due to the dynamic nature of internet traffic.

6. Results and Analysis

6.1. Local Placement

Figure 4 presents the results of measuring the time required for a client to connect to the server 100 times using the local loopback address. For ModBus, the connection time ranges from 1.89 ms to 4.79 ms, with an average of 2.72 ms. SRMCP, however, takes much longer, with connection times ranging from 5.20 ms to 8.50 ms and an average of 5.71 ms. This increased time is expected, as ModBus does not involve a TLS handshake, while SRMCP performs both a TLS handshake and a Kyber Key Encapsulation Mechanism (KEM) handshake, adding to the connection overhead.

The OPC UA exhibits the worst performance due to its highly complex connection procedures, which involve multiple steps before the client is ready for read or write operations. These steps include discovering the server and selecting the endpoint, establishing a secure channel through security policy negotiation, certificate exchange, and asymmetric encryption handshake. Following this, the client creates and activates a session, which includes user authentication, security token exchange, and validation of read/write permissions. The session also initializes any required subscriptions, ensuring that client–server communication is secure and ready for operations. However, integrating user authentication within the communication protocol increases complexity and latency unnecessarily; user authentication is generally better managed at the application layer, separate from the core communication functions.

Figure 5 shows the testing results for the client reading multiple variables from the server over the local loopback interface. Although SRMCP involves a dual layer of encryption, its “Port Hopping” mechanism allows data to be segmented and transferred simultaneously over multiple connections, with each segment processed in independent queues. Additionally, with RMCP’s efficient implementation of JSON serialization, the transmission time is significantly reduced. As a result, SRMCP achieves the best performance with an average read operation time of 1.22 ms, outperforming even the simpler ModBus protocol, which has an average read operation time of 1.92 ms.

In contrast, the OPC UA exhibits the worst performance, with an average read operation time of 15.69 ms. This is primarily due to its complex serialization methods and the multi-step read procedures that introduce significant overhead. The OPC UA requires establishing a secure channel, creating and activating a session, validating user permissions, and processing detailed read requests with extensive metadata and security checks. These layers of security and operational checks, while ensuring data integrity and security, result in much higher latency compared to the more streamlined approaches of SRMCP that rely on well-adopted TLS protocol and JSON schema validation for data integrity and type validation.

Figure 6 shows the testing results for the client writing a variable to the server over the local loopback address. Similar to the read operation results, SRMCP outperformed the other two protocols due to its “Port Hopping” mechanism, where each data packet is divided into smaller segments and transmitted simultaneously over multiple TLS connections. It achieved an average write operation time of 0.81 ms. Modbus followed with an average writing time of 1.99 ms, benefiting from its simplicity and minimal overhead. However, Modbus transmits data packets sequentially over a single TLS connection, which limits its performance compared to SRMCP. In contrast, the OPC UA exhibited the worst performance, with an average write operation time of 15.63 ms. This is due to its complex write procedures, which include conducting a custom asymmetric encryption key handshake, establishing sessions and channels, and performing client authentication and data type verification before the server writes the data sent by the client.

6.2. Local Network Placement

As presented in Figure 7, Figure 8 and Figure 9, the test results for connecting, reading, and writing operations in a local network are comparable to those executed on the local loopback interface. ModBus outperforms SRMCP in connection time due to its simplicity, with an average connection time of 3.83 ms compared to SRMCP’s 7.78 ms. However, SRMCP shows a slight advantage in both reading multiple variables and writing a single variable, with an average reading time of 0.22 ms and writing time of 0.32 ms faster than ModBus. Despite these differences, both ModBus and SRMCP can complete read and write operations in under 2 ms, making them well-suited for the 20 ms cycle typical of fast tasks on most PLCs. In contrast, the OPC UA exhibits the poorest performance, with an average connection time of 33.35 ms, a reading time of 18.42 ms, and a writing time of 18.49 ms. These values render the OPC UA unsuitable for fast tasks on most PLCs, potentially hindering the adoption of the IEC 61499 standard, which requires horizontal PLC communication during scheduled tasks.

6.3. Remote Network

Figure 10 illustrates the test results for a client connecting to a server located in a remote network via VPN over the Internet. Among the three protocols tested, ModBus, being the simplest, demonstrates the best performance, with an average connection time of 19.49 ms. SRMCP follows, with an average connection time of 50.49 ms, despite executing both the TLS handshake and the Kyber KEM. When compared to local network results, the remote network introduced a delay of 16.77 ms for ModBus and 40.86 ms for SRMCP, a 243% difference in terms of increased delay. This difference aligns with SRMCP performing two handshake procedures, whereas ModBus over TCP requires only one. The OPC UA exhibited the worst performance, with an average connection time of 129.57 ms. The remote network added a delay of 103.96 ms due to its complex procedures, which require multiple round trips to complete.

Figure 11 depicts the time required for the client to read values from a remote server via VPN over the Internet. ModBus averages 52.87 ms per read operation, benefiting from its straightforward protocol with minimal packet overhead, making it efficient for basic data retrieval tasks. In contrast, the OPC UA requires an average of 95.62 ms per read, with a peak time of 253.05 ms. SRMCP, however, outperforms both protocols, with an average read operation time of 30.32 ms, due to its “Port Hopping” mechanism.

Figure 12 presents the time required for the client to write a single variable to a server located on a remote network. ModBus exhibits the second-best performance with an average write operation time of 19.49 ms, attributed to its simplicity. Although ModBus confirms write operations by sending a response, it does not include the written value, limiting the client’s ability to verify the data integrity directly. SRMCP, despite involving a dual layer of encryption and including the written value in the server’s confirmation response, still outperforms ModBus with an average write operation time of 24.73 ms due to its simultaneous data transmission approach. In contrast, the OPC UA has the worst performance due to its heavy overhead, with an average write operation time of 92.52 ms and a maximum of 194.79 ms, which is more than twice the maximum write time of SRMCP at 70.20 ms.

7. Conclusions

In this paper, we presented the Secure Real-Time Machine Communication Protocol (SRMCP), a novel industrial communication protocol tailored to the stringent demands of Industry 4.0. By integrating advanced cryptographic techniques such as Kyber-KEM and AES-GCM, SRMCP ensures quantum-safe encryption, addressing both current and emerging security threats. The innovative “Port Hopping” mechanism enhances security further by obfuscating data transmission patterns, making traffic analysis and pattern recognition exceedingly difficult. Additionally, SRMCP’s unique transaction mechanism ensures compliance with real-time standards like IEC 61131, while effectively managing system resources to prevent routine or memory leaks.

Our experimental evaluation demonstrates that SRMCP outperforms widely used protocols such as Modbus and the OPC UA in key performance metrics, particularly in read and write operations, while maintaining robust security. Although SRMCP introduces some overhead in connection time due to its dual-layer encryption and advanced security features, it achieves a balanced trade-off between performance and security, making it well-suited for modern industrial applications requiring secure, efficient, and scalable communication.

Future work will focus on optimizing SRMCP’s implementation to further reduce computational overhead and enhance scalability in large-scale deployments. Additionally, efforts will be directed toward developing seamless interfaces for integration with existing industrial systems and exploring their application in other domains, such as smart grids and healthcare.