Semantic-level ICS zero-trust platform based on intra-network computing

Abstract

The invention discloses a semantic-level ICS zero-trust platform based on intra-network calculation, and aims to solve two problems that a semantic-level ICS zero-trust mechanism is difficult to deploy and deterministic transmission is difficult to guarantee. Semantic-level secure transmission and deterministic transmission are realized through an in-network computing technology and programmable hardware equipment. The method mainly comprises the steps of designing a modular processing flow and optimizing a pipelined architecture, can be deployed in programmable hardware equipment such as an FPGA (Field Programmable Gate Array) and the like, ensures efficient forwarding and semantic-level permission verification of a data packet, effectively considers three requirements of semantic-level protection, easy deployment and deterministic transmission, provides guarantee for network security of an industrial control system, and has a wide application prospect. Wide application prospects are realized.

Description

Technical Field

[0001] The present 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 Art

[0002] Industrial control system (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, ICS are becoming increasingly intertwined with internet infrastructure. ICS networks are being exposed from "barren" local area network environments to more complex and dangerous network environments. This open network environment further amplifies ICS vulnerabilities, exposing them to a higher risk of cyberattacks. Furthermore, attacks against ICS networks are often semantic in nature and more subtle than those targeting IT networks. Some attacks can be carried out by simply 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, primarily due to the following two challenges. The first is deployment difficulty. When deploying zero trust mechanisms, disruption to existing factory equipment and network infrastructure should be minimized. Industrial plants are often very cautious about upgrading existing networks and control equipment to maintain stable production while minimizing costs. Many plants still rely on decade-old programmable logic controllers (PLCs), which may only support outdated ICS protocols that are vulnerable to security threats. Upgrading every device to support in-network computing capabilities is a complex and challenging task. Zero trust in ICS should prioritize upgrading a few key nodes while ensuring compatibility with legacy devices. The second challenge is ensuring deterministic transmission with lossless performance. The end-to-end latency of ICS data packets must be predictable and have minimal jitter to ensure stable 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. Zero trust mechanisms impose even stricter latency and jitter requirements, requiring them to be significantly smaller than the cycle time to ensure stable production. Currently, few ICS security policies can be embedded into production networks without significantly compromising data transmission efficiency. In summary, for semantic-based ICS zero-trust mechanisms to be truly deployed in ICS environments, they must provide flexibility and deterministic transmission with guaranteed performance. Traditional technologies struggle to meet these two requirements. However, shifting the focus to the IT sector, emerging in-network computing technologies offer tremendous potential for resolving this contradiction. In-network computing leverages 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, in-network computing offers flexible programmability and efficient packet processing capabilities. For example, the Tofino P4 switch, a popular programmable device model, offers sub-microsecond latency and a flexible programmable pipeline with a specially designed architecture.

[0004] In summary, the present invention introduces in-network computing technology into the semantic-level zero-trust approach, ensuring deterministic transmission with low latency and low jitter while providing flexibility. Summary of the Invention

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

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

[0007] Data Diversion Module: This module is responsible for preliminary classification of incoming data packets. It identifies the packet content and distinguishes "hello" packets containing key negotiation information from regular ICS protocol packets. The former are forwarded to the key negotiation module, while the latter are sent to the semantic verification module for subsequent zero-trust checks.

[0008] Key negotiation module: This module processes the "hello" data packet and performs key negotiation. It also records the negotiated shared key, the corresponding host-PLC pair quintuple, operation permissions, and memory address permissions in the hardware device hash table.

[0009] Semantic Verification Module: This module is the core component of the platform's semantic-level zero-trust mechanism. First, it rapidly identifies the five-tuple based on the host-PLC interface and uses a shared key to perform encryption and decryption. It then deeply analyzes the function code and memory address of the ICS protocol packet. Combined with the pre-stored operation permissions and memory address permission information in the hardware device hash table, it performs dual verification of both operation permissions and memory address permissions. Communication packets are forwarded only if all permissions are verified. Otherwise, they are blocked and an alarm mechanism is triggered.

[0010] Furthermore, the platform is deployed on a hardware device, placed between the host cluster and the PLC cluster, acting as an intermediate communication node. To ensure the confidentiality of ICS data packet transmission without hardware modifications to the PLCs, this hardware device uses encrypted communication with the host cluster and plaintext communication with the PLC cluster. The host must install an encryption plug-in to encrypt the original ICS protocol data packets sent by the host, extract the host-PLC pair quintuple, and encrypt it using the shared key corresponding to the quintuple.

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

[0012] S1: Before a host-PLC pair establishes a connection, the host with a built-in encryption plug-in will send a "hello" data packet containing the public key 1 generated by the host based on the key negotiation algorithm (ECDH), the five-tuple of the host-PLC pair (source IP, destination IP, source port, destination port, protocol type), and its permission information. After receiving the "hello" data packet, the key negotiation module parses it, 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. At the same time, 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; after receiving the response "hello" data packet, the encryption plug-in on the host parses it, extracts the public key 2 for key negotiation, and obtains the shared key of the host-PLC pair for subsequent encryption use;

[0013] S2: The key agreement module parses the host-PLC pair quintuple and its permission information from the received "hello" data packet, and stores it in the hardware device hash table for subsequent reference.

[0014] Furthermore, the present invention also provides a method for implementing the 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, the platform performs protocol semantic analysis on the plaintext ICS protocol data packets to extract information such as function codes and memory addresses.

[0016] S2: Based on the extracted function code and memory address information, a double-layer permission check is performed: operation permission and memory address permission. The data packet can be forwarded only when all permissions are verified. Otherwise, it will be blocked, and an alarm will be issued immediately with the reason for rejection indicated.

[0017] Furthermore, the semantic verification module divides the semantic verification process into six independent stages, namely, the five-tuple query stage, the encryption / decryption stage, the protocol semantic analysis stage, the memory address query stage, the permission verification stage and the data packet processing stage. It is processed through a modular pipeline architecture. Each stage uses independent computing resources, and information is transmitted between stages through data packet queues and metadata queues.

[0018] Furthermore, in the five-tuple query phase, five-tuple information is first extracted from the received ICS protocol data packet to uniquely identify the current host and PLC communication pair. 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 phase provides basic information support for subsequent encryption / decryption and permission verification.

[0019] Furthermore, during the encryption / decryption phase, after obtaining the shared key, the encryption or decryption requirements are determined based on the flow direction of the ICS protocol data packet, and the encryption / decryption module implemented based on the Vitis high-performance computing library is called to process the data packet content, ensuring the confidentiality and integrity of data transmission and preventing man-in-the-middle attacks and information leakage.

[0020] Furthermore, during the protocol semantic parsing phase, the ICS protocol data packet is subjected to protocol semantic parsing, the function code is extracted from the application layer protocol, and the specific operation type carried by the data packet is identified. If it is a read or write operation, the PLC memory address accessed is further extracted and used as the key basis for permission verification.

[0021] Furthermore, during the permission verification phase, the permissions, operation permissions, and memory address permissions of the host-PLC pair are compared. The verification process is divided into two levels: first, operation permission determination, confirming whether the host-PLC pair has the permission to perform the current operation; second, memory address permission determination, confirming whether the host-PLC pair is authorized to access the specified memory address. Only when both determinations are passed can the ICS protocol data packet be determined to be authentic.

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

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

[0024] First, the present invention innovatively introduces in-network computing, deploys security processing logic inside the network, and realizes on-site processing and instant verification of industrial control data through lightweight nodes, avoiding the transmission of all data to a centralized controller for analysis, fundamentally reducing latency and improving response efficiency.

[0025] Second, the pipeline architecture ensures high concurrency and low-latency processing capabilities. This pipeline architecture is highly scalable and can adapt to various industrial control scenarios.

[0026] Third, the platform can complete data packet reception, parsing, permission determination, and response operations in microseconds, with sub-microsecond jitter, fully meeting the stringent requirements of industrial control systems for deterministic transmission and real-time performance.

[0027] Fourth, the platform deeply analyzes industrial protocols, identifies function codes and operation instructions, and implements fine-grained control in combination with memory address permissions. It supports dynamic judgment of "whether a user has the right to access a certain memory address or whether a certain operation is allowed," thus achieving fine-grained semantic-level zero-trust access control.

[0028] Fifth, the platform of the present invention does not require large-scale changes to the existing ICS network, only the transmission nodes need to be changed, and is easy to deploy. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0032] Figure 4 This is a result diagram of intercepting various attacks provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0033] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the specific embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0034] In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art may make similar generalizations without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

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

[0036] Data Diversion Module: This module is responsible for preliminary classification of incoming communication packets. It identifies packet content and distinguishes "hello" packets containing key negotiation information from standard ICS protocol packets. The former are forwarded to the key negotiation module, while the latter are sent to the semantic verification module for subsequent zero-trust checks. This enables parallelization of data processing and improves overall system efficiency.

[0037] Key negotiation module: This module mainly processes "hello" data packets and performs key negotiation tasks. At the same time, it records the shared key after successful negotiation and the corresponding host-PLC pair five-tuple, operation permissions and memory address permission information in the hardware device hash table.

[0038] Semantic Verification Module: This module is the core part of this platform to implement the semantic-level zero-trust mechanism. Its core goal is to perform fine-grained permission verification on each protocol data packet transmitted in the ICS, one by one, one by one operation, and one by one memory address. First, the five-tuple is quickly identified based on the host-PLC, and encryption and decryption operations are completed in combination with the shared key. Then, the function code and memory address of the ICS protocol data packet are deeply analyzed, and combined with the pre-stored operation permission and memory address permission information in the hardware device hash table, a double verification of the operation permission and memory address permission is performed. Only when all permission verifications are passed can the communication data packet be forwarded; otherwise, it will be blocked and the alarm mechanism will be triggered.

[0039] Furthermore, the data diversion module separates the key negotiation and 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 critical data forwarding.

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

[0041] like Figure 2 As shown, the implementation details of the key agreement module proposed in this embodiment of the application include the following two stages:

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

[0043] Information storage: The key agreement module parses the "hello" packet to extract the host-PLC pair's five-tuple information and its associated permissions. Ultimately, the host-PLC pair's five-tuple is used as the key, along with the shared key and permissions information as the value. These key-value pairs are stored in a hash table on the local hardware device for subsequent encryption / decryption and access control calls.

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

[0045] Quintuple Query Phase: First, a quintuple is extracted from the received ICS protocol data packet to uniquely identify the current host-PLC communication pair. Using this quintuple as the query 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 requirements are determined based on the data packet flow direction (host→PLC or PLC→host). 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.

[0047] Protocol semantic analysis phase: After encryption / decryption, the data packet is subjected to in-depth semantic analysis. This phase extracts the function code from the application layer protocol and identifies the specific operation type (e.g., read, write, etc.) carried by the data packet. If it is a read / write operation, the PLC memory address accessed is further extracted as a key basis for permission verification.

[0048] Memory address query phase: Using the resolved target memory address as an index, the permission bitmap is searched from the memory table stored by the hardware device. This permission bitmap records the minimum permissions required to access the memory address and is an important part of the access control policy.

[0049] Permission verification phase: Compare the host-PLC pair's permission configuration, operation permission bitmap, and memory address permission bitmap. This judgment process is divided into two levels: first, operation permission judgment, confirming whether the host-PLC pair has the permission to perform the current operation; second, memory address permission judgment, confirming whether it is authorized to access the specified memory address. Only when both judgments are passed can the data packet be determined to be credible;

[0050] Packet processing: Subsequent actions are executed based on the trust judgment results. For trusted packets that pass verification, the platform forwards them to the corresponding PLC or host computer to ensure the normal operation of the control process. For packets that fail verification, an attack alert mechanism is immediately triggered, and the specific rejection reason and related information are displayed simultaneously on the platform management interface, enabling administrators to quickly respond and conduct source tracing analysis. This processing has a microsecond-level response capability, balancing real-time and security.

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

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

[0053] The key negotiation module proposed in the embodiment of the present 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 plug-in will send 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 permission information. After receiving the "hello" data packet, the key negotiation module parses it, 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. When each pair of hosts communicates with the PLC, the corresponding shared key is used for encryption and decryption. At the same time, 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. After receiving the response "hello" data packet, the encryption plug-in on the host parses it, extracts the public key 2 for key negotiation, and obtains the shared key of the host-PLC pair for subsequent encryption.

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

[0056] The semantic verification module proposed in the embodiment of the present application is specifically implemented in the following two steps.

[0057] (1) When the platform receives an encrypted data packet from 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 analysis on the data packet to extract semantic information such as the protocol type, function code, and target memory address.

[0058] (2) After parsing the semantics of the protocol, if it is determined that the data packet contains operation information (such as start and stop, etc.), operation permission verification is required, that is, the permission set of the current host-PLC pair is compared with the permission required for the operation. If the former can cover the latter, the operation is determined to be credible. If the data packet also involves memory address access, memory address permission verification is required, that is, the permission of the host-PLC pair is compared with the permission required to access the memory address. If the former can cover the latter, the access is determined to be credible. The ICS may include multiple memory addresses, each of which must be verified. Only when both the operation permission and the memory address permission are credible will the platform forward the data packet to the corresponding PLC or host. If there is insufficient permission, the alarm mechanism will be triggered and the specific reason for the rejection will be prompted.

[0059] The present invention implements a prototype system on an FPGA platform and verifies the effectiveness of the method. Figure 4 As shown, the interception of most attacks in ICS is achieved with microsecond-level and low jitter. In addition, depending on the hardware devices used in the network forwarding platform, the embodiments of the present application can also be extended and deployed on programmable hardware such as ASIC.

[0060] The above description is only a preferred embodiment of the present invention. Although the present invention has been disclosed as a preferred embodiment, it is not intended to limit the present invention. Any person skilled in the art can use the above disclosed methods and technical contents to make many possible changes and modifications to the technical solution of the present invention without departing from the scope of the technical solution of the present invention, or modify it into an equivalent embodiment with equivalent changes. Therefore, any simple modification, equivalent change and modification made to the above embodiment based on the technical essence of the present invention without departing from the content of the technical solution of the present invention still falls within the scope of protection of the technical solution of the present invention.

Claims

1. A semantic-level ICS zero-trust platform based on in-network computing, characterized by: It adopts a modular design, including data diversion module, key negotiation module and semantic verification module; Data diversion module: This module is responsible for classifying incoming communication data packets, distinguishing "hello" packets containing key negotiation information from regular ICS protocol packets. The former are forwarded to the key negotiation module, while the latter are sent to the semantic verification module. Key negotiation module: responsible for processing "hello" data packets, performing key negotiation tasks, and recording the successfully negotiated shared key, the corresponding host-PLC pair quintuple, operation permissions, and memory address permission information in the hardware device hash table; Semantic Verification Module: This module identifies the quintuple based on the host-PLC interface and uses a shared key to perform encryption and decryption operations. It then parses the function code and memory address of the ICS protocol data packet. It then performs dual verification of both the operation permissions and memory address permissions, combined with the pre-stored operation permissions and memory address permission information in the hardware device hash table. Communication data packets can only be forwarded if all permissions are verified. Otherwise, they will be blocked and an alarm mechanism will be triggered.

2. The semantic-level ICS zero-trust platform based on in-network computing according to claim 1, characterized in that: The platform is deployed on a hardware device and placed between the host group and the PLC group, serving as an intermediate communication node. Encrypted communication is used between the hardware device and the host group, while plain text communication is used between the hardware device and the PLC group. The host needs to install an encryption plug-in to encrypt the original ICS protocol data packet sent by the host, extract the host-PLC pair quintuple, and encrypt it according to the shared key corresponding to the quintuple.

3. The semantic-level ICS zero-trust platform based on in-network computing according to claim 1, characterized in that: The implementation method of the key negotiation module includes the following steps: S1: Before a host-PLC pair establishes a connection, the host with a built-in encryption plug-in sends a "hello" packet containing the public key 1 generated by the host based on the key negotiation algorithm, the host-PLC pair's five-tuple, and its permission information. After receiving the "hello" packet, the key negotiation module parses it, extracts the initiating host's public key 1, performs key negotiation to generate a shared key, and stores it in the hardware device. At the same time, it sends a response "hello" packet containing the public key 2 generated by the hardware device based on the key negotiation algorithm back to the host. After receiving the response "hello" packet, the encryption plug-in on the host parses it, extracts the public key 2, performs key negotiation, and obtains the shared key of the host-PLC pair. S2: The key agreement module parses the received "hello" data packet to obtain the host-PLC pair quintuple and its permission information for the established connection, and stores it in the hardware device hash table.

4. The semantic-level ICS zero-trust platform based on in-network computing according to claim 3, characterized in that: After parsing the "hello" data packet, the key negotiation module uses the host-PLC pair quintuple as the key and the shared key and permission information as the value, and stores them in the hash table of the local hardware device in the form of key-value pairs.

5. The semantic-level ICS zero-trust platform based on in-network computing according to claim 1, characterized in that: The implementation method of the semantic verification module comprises the following steps: 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, the platform performs protocol semantic analysis on the plaintext ICS protocol data packets to extract function codes and memory address information. S2: Based on the extracted function code and memory address information, a double-layer permission check is performed: operation permission and memory address permission. The data packet can be forwarded only when all permissions are verified. Otherwise, it will be blocked, and an alarm will be issued immediately with the reason for rejection indicated.

6. The semantic-level ICS zero-trust platform based on in-network computing according to claim 1, characterized in that: The semantic verification module divides the semantic verification process into six independent stages, namely the five-tuple query stage, encryption / decryption stage, protocol semantic analysis stage, memory address query stage, permission verification stage and data packet processing stage. It is processed through a modular pipeline architecture. Each stage uses independent computing resources, and information is transmitted between stages through data packet queues and metadata queues.

7. The semantic-level ICS zero-trust platform based on in-network computing according to claim 6, characterized in that: In the five-tuple query phase, a five-tuple is first extracted from the received ICS protocol data packet to uniquely identify the current host-PLC communication pair. This five-tuple is then used as a query key to retrieve the shared key, operation permissions, and memory address permission configuration corresponding to the host-PLC pair from a hash table generated by the key negotiation module.

8. The semantic-level ICS zero-trust platform based on in-network computing according to claim 6, characterized in that: In the encryption / decryption stage, after obtaining the shared key, the encryption or decryption requirements are determined according to the flow direction of the ICS protocol data packet, and the encryption / decryption module implemented based on the Vitis high-performance computing library is called to process the data packet content.

9. The semantic-level ICS zero-trust platform based on in-network computing according to claim 6, characterized in that: During the protocol semantic parsing phase, the ICS protocol data packet is subjected to protocol semantic parsing, the function code is extracted from the application layer protocol, and the specific operation type carried by the data packet is identified. If it is a read or write operation, the PLC memory address accessed is further extracted.

10. The semantic-level ICS zero-trust platform based on in-network computing according to claim 6, characterized in that: During the permission verification phase, the permissions, operation permissions, and memory address permissions of the host-PLC pair are compared. The verification process is divided into two levels: first, operation permission determination, to confirm whether the host-PLC pair has the permission to perform the current operation; Second, the memory address permission check confirms whether the host-PLC pair is authorized to access the specified memory address. Only when both checks are passed can the ICS protocol data packet be determined to be credible.

Images