A semantic-level ics zero-trust platform based on in-network computing

Abstract

The application discloses a semantic-level ICS zero-trust platform based on in-network computing, aiming at solving the two difficult problems of difficult deployment and guaranteeing deterministic transmission of the semantic-level ICS zero-trust mechanism. Through in-network computing technology and programmable hardware devices, semantic-level secure transmission and deterministic transmission are realized. The application mainly includes a modular processing flow and an optimized pipeline architecture, can be deployed on programmable hardware devices such as FPGAs, ensures efficient forwarding of data packets and semantic-level permission verification, effectively balances the three requirements of semantic-level protection, easy deployment and deterministic transmission, provides protection for industrial control system network security, and has a wide application prospect.

Description

Technical Field

[0001] This invention relates to the field of industrial control system security technology, and in particular to a semantic-level ICS zero-trust platform based on in-network computing, which is suitable for security protection in real industrial control environments. Background Technology

[0002] Industrial Control Systems (ICS) networks are experiencing a growing trend of IT / OT convergence. Driven by advancements in next-generation ICS technologies, such as OpenPLC and the Industrial Internet of Things (IIoT), ICS is becoming increasingly intertwined with internet infrastructure. ICS networks are being exposed from "barren" LAN environments to more complex and vulnerable network environments. This open network environment further amplifies ICS vulnerabilities, making them more susceptible to cyberattacks. Furthermore, attacks against ICS networks are often semantic, more covert than those against IT networks. Some attacks can be achieved simply by modifying a single core variable. ICS networks need to deploy semantic-level zero-trust mechanisms to eliminate all implicit prior trust and prevent untrusted requests from attackers.

[0003] Deploying semantic-level zero-trust mechanisms in ICS networks is not easy, mainly due to the following two challenges. The first is the difficulty of deployment. When deploying zero-trust mechanisms, it's crucial to minimize disruption to existing factory equipment and network infrastructure. Industrial plants are typically very cautious about upgrading existing networks and control equipment to maintain industrial production stability while minimizing costs. Many plants still rely on programmable logic controllers (PLCs) from a decade ago, which may only support outdated ICS protocols that are vulnerable to security threats. Upgrading each device to support the computing power within the network is a complex and challenging task. Zero-trust in ICS should prioritize updating a few key nodes while ensuring compatibility with legacy equipment. The second challenge is ensuring deterministic transmission with lossless performance. End-to-end latency in ICS packets must be predictable and jitter minimized to ensure the stability of industrial processes. ICS data exchange cycles are typically in the millisecond range. In some motion control scenarios, it can even be in the microsecond range. The latency and jitter requirements introduced by zero-trust mechanisms are even more stringent, needing to be much smaller than the cycle time to ensure stable production. Currently, few ICS security policies can be embedded in production networks without significantly compromising data transmission efficiency. In summary, for semantic-based ICS zero-trust mechanisms to be truly deployed in an ICS environment, they must provide both flexibility and guaranteed deterministic transmission with no performance loss. Traditional technologies struggle to meet these two requirements. However, shifting the focus to the IT field, emerging intranet computing technologies offer significant potential for resolving this contradiction. Intranet computing utilizes advanced programmable hardware, such as P4 switches, FPGAs, and programmable ASICs, to offload complex computational and processing tasks directly to network devices. Compared to CPU-based software and ASIC-based hardware, intranet computing offers flexible programmability and efficient packet processing capabilities. For example, the Tofino P4 switch, a popular programmable device model, provides sub-microsecond latency and features a flexible programmable pipeline with a specially designed architecture.

[0004] In summary, this invention introduces intranet computing technology into a semantic-level zero-trust method, providing flexibility while ensuring deterministic transmission with low latency and minimal jitter. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by combining in-network computing technology to design a semantic-level zero-trust platform with low latency, low jitter, and deployability in real ICS environments.

[0006] The objective of this invention is achieved through the following technical solution: a semantic-level ICS zero-trust platform based on in-network computing. This platform adopts a modular design, and the overall processing flow is divided into three main functional modules: a data splitting module, a key negotiation module, and a semantic verification module.

[0007] Data routing module: This module is responsible for the initial classification of data packets entering the platform. It distinguishes between "hello" packets containing key negotiation information and regular ICS protocol packets by identifying the packet content. The former is forwarded to the key negotiation module, while the latter is sent to the semantic verification module for subsequent zero-trust checks.

[0008] Key negotiation module: This module mainly processes "hello" data packets and performs key negotiation tasks. Simultaneously, it records the successfully negotiated shared key along with the corresponding host-PLC pair 5-tuple, operation permissions, and memory address permission information in a hardware device hash table.

[0009] Semantic Verification Module: This module is a core component of the platform's semantic-level zero-trust mechanism. First, it performs rapid identity verification of the five-tuple based on the host-PLC and completes encryption / decryption operations using the shared key. Then, it deeply analyzes the function code and memory address of the ICS protocol data packet, and combines this with the pre-stored operation permission and memory address permission information in the hardware device's hash table to perform dual verification of operation permissions and memory address permissions. Communication data packets can only be forwarded if all permissions are verified successfully; otherwise, they will be blocked and an alarm mechanism will be triggered.

[0010] Furthermore, the platform is deployed on hardware devices, positioned between the host cluster and the PLC cluster, serving as an intermediate communication node. To ensure the confidentiality of data packet transmission in ICS and without modifying the PLC hardware, this hardware device uses encrypted communication with the host cluster, while using plaintext communication with the PLC cluster. The host needs to have an encryption plugin installed to encrypt the original ICS protocol data packets sent by the host, extract the host-PLC pair 5-tuple, and encrypt it using the shared key corresponding to the 5-tuple.

[0011] Furthermore, the present invention also provides a method for implementing a key negotiation module, comprising the following steps:

[0012] S1: Before a host-PLC pair establishes a connection, the host with a built-in encryption plugin sends a "hello" data packet containing the public key 1 generated by the host based on the key negotiation algorithm (ECDH), the five-tuple of this host-PLC pair (source IP, destination IP, source port, destination port, protocol type), and its authorization information. The key negotiation module receives and parses this "hello" data packet, extracts the public key 1 information of the initiating host, performs key negotiation to generate a shared key, and stores it in the hardware device. Simultaneously, it sends a response "hello" data packet containing the public key 2 generated by the hardware device based on the key negotiation algorithm back to the host. The encryption plugin on the host receives and parses the response "hello" data packet, extracts the public key 2, performs key negotiation, and obtains the shared key for this host-PLC pair for subsequent encryption.

[0013] S2: The key negotiation module parses the host-PLC pair five-tuple and its permission information from the received "hello" data packet and stores it in the hardware device hash table for later use.

[0014] Furthermore, the present invention also provides a method for implementing a semantic verification module, comprising the following steps:

[0015] S1: During communication, the platform automatically decrypts the encrypted ICS protocol data packets sent by the host and encrypts the plaintext ICS protocol data packets sent by the PLC; after completing the encryption / decryption process, it performs protocol semantic parsing on the plaintext ICS protocol data packets to extract information such as function codes and memory address information;

[0016] S2: Based on the extracted function code and memory address information, perform two-layer permission verification: operation permission and memory address permission. The data packet can only be forwarded if all permissions are verified successfully; otherwise, it will be blocked, and an alarm will be issued immediately with the reason for the rejection.

[0017] Furthermore, the semantic verification module divides the semantic verification process into six independent stages: the five-tuple query stage, the encryption / decryption stage, the protocol semantic parsing stage, the memory address query stage, the permission verification stage, and the data packet processing stage. These stages are processed through a modular pipeline architecture, with each stage using independent computing resources and information being passed between stages via a data packet queue and a metadata queue.

[0018] Furthermore, in the five-tuple query stage, five-tuple information is first extracted from the received ICS protocol data packet to uniquely identify the current communication pair between the host and the PLC. Using this five-tuple as the query key, the shared key, operation permissions, and memory address permission configuration corresponding to the host-PLC pair are quickly retrieved from the hash table generated by the key negotiation module. This stage provides basic information support for subsequent encryption / decryption and permission verification.

[0019] Furthermore, in the encryption / decryption stage, after obtaining the shared key, the encryption or decryption requirement is determined according to the flow of ICS protocol data packets, and the encryption / decryption module implemented based on the Vitis high-performance computing library is called to process the data packet content to ensure the confidentiality and integrity of data transmission and prevent man-in-the-middle attacks and information leakage.

[0020] Furthermore, in the protocol semantic parsing stage, protocol semantic parsing is performed on the ICS protocol data packets to extract function codes from the application layer protocol and identify the specific operation type carried by the data packets. If it is a read / write operation, the PLC memory address accessed is further extracted and used as a key basis for permission verification.

[0021] Furthermore, in the permission verification stage, the permissions, operation permissions, and memory address permissions of the host-PLC are compared. The verification process is divided into two levels: First, operation permission judgment, to confirm whether the host-PLC has the permission to execute the current operation; second, memory address permission judgment, to confirm whether the host-PLC is authorized to access the specified memory address. Only when both judgments pass can the ICS protocol data packet be determined to be trustworthy.

[0022] Furthermore, this zero-trust platform can be deployed on programmable hardware platforms such as FPGA and ASIC, leveraging the parallel processing capabilities and low latency of the hardware to achieve efficient trust verification and meet the stringent requirements of industrial control systems for real-time performance and reliability.

[0023] Compared with the prior art, the present invention has the following significant advantages:

[0024] First, this invention innovatively introduces in-network computing, deploying security processing logic within the network. It enables in-situ processing and real-time verification of industrial control data through lightweight nodes, avoiding the transmission of all data to a centralized controller for analysis. This fundamentally reduces latency and improves response efficiency.

[0025] Second, a pipelined architecture is adopted to ensure high concurrency and low latency processing capabilities. This pipelined architecture is highly scalable and can adapt to various industrial control scenarios;

[0026] Third, the platform of this invention can complete the reception, parsing, permission judgment and response operations of data packets in microseconds, while the jitter is in the sub-microsecond level, which fully meets the stringent requirements of industrial control systems for deterministic transmission and real-time performance.

[0027] Fourth, this platform deeply analyzes industrial protocols to identify function codes and operation instructions, and combines this with memory address permissions to achieve fine-grained control. It supports dynamic judgment of whether access to a specific memory address is permitted, and whether a certain operation is allowed, thus achieving fine-grained semantic-level zero-trust access control.

[0028] Fifth, the platform of this invention does not require large-scale changes to the existing ICS network; only the transmission nodes need to be changed, making it easy to deploy. Attached Figure Description

[0029] Figure 1 This is a structural diagram of a semantic-level ICS zero-trust platform based on in-network computing provided in an embodiment of the present invention;

[0030] Figure 2 This is a structural diagram of the key negotiation module provided in an embodiment of the present invention;

[0031] Figure 3 This is a structural diagram of the semantic verification module provided in an embodiment of the present invention;

[0032] Figure 4 This is a diagram showing the results of intercepting various attacks provided in an embodiment of the present invention. Detailed Implementation

[0033] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0034] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0035] like Figure 1 As shown in the embodiment of this application, a semantic-level ICS zero-trust platform based on in-network computing is proposed. The platform adopts a modular design, and the overall processing flow is divided into three main functional modules: data splitting module, key negotiation module, and semantic verification module.

[0036] Data splitting module: This module is responsible for the initial classification of communication data packets entering the platform. It distinguishes "hello" packets containing key negotiation information from regular ICS protocol packets by identifying the packet content. The former is forwarded to the key negotiation module, while the latter is sent to the semantic verification module for subsequent zero-trust checks, thereby parallelizing the data processing flow and improving overall system efficiency.

[0037] Key negotiation module: This module mainly processes the "hello" data packet, performs key negotiation tasks, and records the successfully negotiated shared key, the corresponding host-PLC pair 5-tuple, operation permissions, and memory address permission information in the hardware device hash table.

[0038] Semantic Verification Module: This module is the core component of the platform's semantic-level zero-trust mechanism. Its core objective is to perform fine-grained permission verification on a message-by-message, operation-by-operation, and memory-by-memory-address basis for protocol data packets transmitted in the ICS. First, it performs rapid identity recognition of the five-tuple based on the host-PLC and completes encryption and decryption operations using the shared key. Then, it deeply analyzes the function code and memory address of the ICS protocol data packet, and combines the operation permission and memory address permission information pre-stored in the hardware device's hash table to perform dual verification of operation permission and memory address permission. Only when all permissions are verified successfully can the communication data packet be forwarded; otherwise, it will be blocked and an alarm mechanism will be triggered.

[0039] Furthermore, the data splitting module separates key negotiation from caching mechanisms. The key negotiation module (slow processing path) is dedicated to the "hello" handshake and key negotiation, while the semantic verification module (fast processing path) performs permission judgment and data processing based on the pre-stored shared key, greatly reducing the impact of negotiation delay on the forwarding of critical data.

[0040] Furthermore, to reduce negotiation delays, the platform adopts a fast response mechanism, which responds with a "hello" data packet immediately after receiving the host's "hello" data packet, thereby advancing the key generation and data transmission processes in parallel and significantly improving the system's response speed.

[0041] like Figure 2 As shown in the embodiments of this application, the implementation details of the key negotiation module are presented, including the following two stages:

[0042] Key generation phase: After receiving the "hello" data packet, the key negotiation module parses its content and extracts the public key information of the initiating host. Then, combining its own private key with the extracted public key, it generates a shared key for subsequent encryption and decryption based on the key negotiation algorithm (ECDH).

[0043] Information storage phase: The key negotiation module parses the five-tuple information of the host-PLC pair and its permissions from the "hello" data packet. Finally, the five-tuple of the host-PLC pair is used as the key, and the shared key and permission information are used as values, stored in the hash table of the local hardware device in key-value pairs for subsequent encryption / decryption and access control calls.

[0044] like Figure 3As shown, this application embodiment proposes implementation details of the semantic verification module. To improve processing efficiency and system scalability, the processing flow of the semantic verification module is divided into six independent stages:

[0045] Five-tuple lookup phase: First, five-tuple information is extracted from the received ICS protocol data packet to uniquely identify the current host-PLC communication pair. Using this five-tuple as the lookup key, the shared key and permission configuration corresponding to this host-PLC pair are quickly retrieved from the hash table generated by the key negotiation module. This phase provides basic information support for subsequent encryption / decryption and permission verification.

[0046] Encryption / decryption phase: After obtaining the shared key, the encryption or decryption requirement is determined according to the data packet flow (host → PLC or PLC → host), and the encryption / decryption module based on the Vitis high-performance computing library is called to process the data packet content to ensure the confidentiality and integrity of data transmission and prevent man-in-the-middle attacks and information leakage.

[0047] Protocol semantic parsing phase: After encryption / decryption, in-depth semantic parsing is performed on the data packets. This phase extracts function codes from the application layer protocol and identifies the specific operation type (such as read, write, etc.) carried by the data packets. If it is a read / write operation, the PLC memory address accessed is further extracted and used as a key basis for authorization verification;

[0048] Memory address lookup phase: Using the parsed target memory address as an index, the permission bitmap is retrieved from the memory table stored in the hardware device. This permission bitmap records the minimum permissions required to access the memory address and serves as an important component of the access control policy;

[0049] The authorization verification phase compares the host-PLC's authorized access configuration, operation permission bitmap, and memory address permission bitmap. This process has two levels: first, operation permission verification confirms whether the host-PLC has the authority to execute the current operation; second, memory address permission verification confirms whether it is authorized to access the specified memory address. Only when both verifications pass can the data packet be considered trustworthy.

[0050] Data packet processing phase: Subsequent operations are executed based on the trust assessment result. For verified trusted data packets, the platform forwards them to the corresponding PLC or host to ensure the normal operation of the control flow. For data packets that fail verification, an attack alarm mechanism is immediately triggered, and the specific reasons for rejection and related information are simultaneously displayed on the platform management interface, supporting administrators for rapid response and source tracing analysis. This processing has microsecond-level rapid response capabilities, balancing real-time performance and security.

[0051] Furthermore, the memory table is also a hash table, where the key is the memory address and the value is the minimum permission required to access that memory address.

[0052] Furthermore, each stage is deployed on independent computing resources, and the stages are coordinated and scheduled through packet queues and metadata queues to ensure the concurrency and accuracy of processing.

[0053] The key negotiation module proposed in this application is specifically implemented in the following two steps.

[0054] (1) Before a host-PLC pair establishes a connection, the host with a built-in encryption plugin sends a "hello" data packet containing the public key 1 generated by the host based on the key negotiation algorithm, the five-tuple of the host-PLC pair, and its authorization information. The key negotiation module receives and parses the "hello" data packet, extracts the public key 1 information of the initiating host, performs key negotiation to generate a shared key, and stores it in the hardware device. Each time a host-PLC pair communicates, it uses the corresponding shared key for encryption and decryption. Simultaneously, the hardware device sends a response "hello" data packet containing the public key 2 generated based on the key negotiation algorithm back to the host. The encryption plugin on the host receives and parses the response "hello" data packet, extracts the public key 2, performs key negotiation, and obtains the shared key for the host-PLC pair for subsequent encryption.

[0055] (2) The key negotiation module parses the host-PLC pair 5-tuple and its permission information from the received “hello” data packet, and stores the host-PLC pair 5-tuple, shared key and permission information in the hardware device in the form of key-value pairs.

[0056] The semantic verification module proposed in this application is implemented in the following two steps.

[0057] (1) When the platform receives an encrypted data packet sent by the host, it first decrypts it; similarly, when it receives a plaintext data packet from the PLC, the platform encrypts it. After completing the encryption / decryption process, the platform performs protocol semantic parsing on the data packet to extract semantic information such as protocol type, function code, and target memory address.

[0058] (2) After parsing the semantics of the protocol, if the data packet contains operation information (such as start / stop), operation permission verification is required. This involves comparing the current host-PLC pair's permission set with the permissions required for the operation. If the former covers the latter, the operation is considered trustworthy. If the data packet also involves memory address access, further memory address permission verification is required. This involves comparing the host-PLC pair's permissions with the permissions required to access the memory address. If the former covers the latter, the access is considered trustworthy. ICS may include multiple memory addresses, each of which must be verified. The platform only forwards the data packet to the corresponding PLC or host if both operation permission and memory address permission are trustworthy. If insufficient permissions are found, an alarm mechanism is triggered, and the specific reason for rejection is displayed.

[0059] This application's embodiments implemented a prototype system on an FPGA platform and verified the method's effectiveness, such as... Figure 4 As shown, this method achieves microsecond-level, low-jitter interception of the vast majority of attacks in ICS. Furthermore, depending on the hardware used by the network forwarding platform, this embodiment can also be extended to programmable hardware such as ASICs.

[0060] The above description is merely a preferred embodiment of the present invention. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make many possible variations and modifications to the technical solutions of the present invention using the methods and techniques disclosed above, or modify them into equivalent embodiments with equivalent changes, without departing from the scope of the technical solutions of the present invention. Therefore, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solutions of the present invention shall still fall within the protection scope of the technical solutions of the present invention.

Claims

1. A semantic level ICS zero trust platform based on in-network computing, characterized in that, The platform is deployed on a hardware device, placed between a host group and a PLC group as an intermediate communication node, and adopts encrypted communication between the hardware device and the host group and adopts plaintext communication between the hardware device and the PLC group; the host needs to install an encryption plug-in to encrypt original ICS protocol data packets sent by the host, extract a host-PLC pair five tuple therein, and encrypt the five tuple according to a corresponding shared key; the platform adopts modular design and comprises a data shunting module, a key negotiation module and a semantic verification module; The data shunting module is responsible for classifying and processing communication data packets entering the platform, distinguishing "hello" data packets containing key negotiation information from ICS protocol data packets, forwarding the former to the key negotiation module, and sending the latter to the semantic verification module; The key negotiation module is responsible for processing "hello" data packets, performing a key negotiation task, and recording a shared key negotiated successfully, a corresponding host-PLC pair five tuple, operation permission and memory address permission information in a hardware device hash table; The semantic verification module performs identity recognition based on the host-PLC pair five tuple, completes encryption and decryption operations in combination with the shared key, analyzes a function code and a memory address of the ICS protocol data packet, performs double verification of the operation permission and the memory address permission in combination with the pre-stored operation permission and memory address permission information in the hardware device hash table, and forwards the communication data packet only when all the permission verification passes, otherwise, the communication data packet is blocked and an alarm mechanism is triggered.

2. The in-network compute based semantic level ICS zero trust platform of claim 1, wherein, The implementation method of the key negotiation module comprises the following steps: S1: Before a pair of host-PLC establishes a connection, the host with the built-in encryption plug-in sends a "hello" data packet containing a public key 1 generated by the host based on a key negotiation algorithm, a host-PLC pair five tuple and permission information thereof; the key negotiation module receives and analyzes the "hello" data packet, extracts the public key 1 information of the initiating host, generates a shared key through key negotiation and stores the shared key in the hardware device, and sends a response "hello" data packet containing a public key 2 generated by the hardware device based on the key negotiation algorithm back to the host; the encryption plug-in on the host receives and analyzes the response "hello" data packet, extracts the public key 2 to perform key negotiation, and obtains the shared key of the host-PLC pair; S2: The key negotiation module analyzes the host-PLC pair five tuple and permission information thereof for establishing the connection from the received "hello" data packet, and stores the host-PLC pair five tuple and the permission information in a hardware device hash table.

3. The in-network compute based semantic level ICS zero trust platform of claim 2, wherein, After the key negotiation module analyzes the "hello" data packet, the host-PLC pair five tuple is stored in the hash table of the local hardware device in the form of a key-value pair, with the shared key and the permission information as the value.

4. The in-network compute based semantic level ICS zero trust platform of claim 1, wherein, The implementation method of the semantic verification module comprises the following steps: S1: During communication, the platform automatically decrypts the encrypted ICS protocol data packet sent by the host and encrypts the plaintext ICS protocol data packet sent by the PLC; after completing the encryption / decryption process, the plaintext ICS protocol data packet is parsed for protocol semantics to extract function code and memory address information; S2: Based on the extracted function code and memory address information, two-layer permission verification is performed: operation permission and memory address permission. Only when all permissions are verified, the data packet can be forwarded; otherwise, it will be blocked, and an alarm will be given immediately and the reason for rejection will be indicated.

5. The in-network compute based semantic level ICS zero trust platform of claim 1, wherein, The semantic verification module divides the semantic verification process into six independent stages: five-tuple query stage, encryption / decryption stage, protocol semantic analysis stage, memory address query stage, permission verification stage, and data packet processing stage. The modular pipeline architecture is used for processing, and each stage uses independent computing resources. Information is transmitted between stages through data packet queues and metadata queues.

6. The in-network compute based semantic level ICS zero trust platform of claim 5, wherein, In the five-tuple query stage, the five-tuple information is first extracted from the received ICS protocol data packet to uniquely identify the current host-PLC communication pair; the five-tuple is used as a query key to retrieve the corresponding shared key, operation permission, and memory address permission configuration for the host-PLC pair from the hash table generated by the key negotiation module.

7. The in-network compute based semantic level ICS zero trust platform of claim 5, wherein, In the encryption / decryption stage, after obtaining the shared key, the encryption or decryption requirement is determined according to the flow direction of the ICS protocol data packet, and the encryption / decryption module based on the Vitis high-performance computing library is called to process the data packet content.

8. The in-network compute based semantic level ICS zero trust platform of claim 5, wherein, In the protocol semantic analysis stage, the ICS protocol data packet is parsed for protocol semantics to extract the function code from the application layer protocol and identify the specific operation type carried by the data packet. If it is a read-write operation, the PLC memory address accessed is further extracted.

9. The in-network compute based semantic level ICS zero trust platform of claim 5, wherein, In the permission verification stage, the permissions owned by the host-PLC pair, operation permission, and memory address permission are compared; the verification process consists of two levels: first, operation permission judgment to confirm whether the host-PLC pair has the permission to execute the current operation; Second, memory address permission judgment to confirm whether the host-PLC pair is authorized to access the specified memory address; only when both judgments are passed, the ICS protocol data packet is determined to be trusted.

Images