PLC safety monitoring method and device based on TrustZone

Abstract

The invention provides a PLC safety monitoring method and device based on TrustZone. The method comprises the steps that data of an I / O port during REE operation are collected; determining a next state according to the currently collected data and the recorded current state of the TEE, and recording the next state as a new current state of the TEE under the condition that the next state is different from the current state of the TEE; acquiring the current state and the previous state of the REE corresponding to the data of the input / output port in the REE; comparing the conversion process from the current state of the TEE to the next state with the conversion process from the previous state to the current state of the REE; and if the comparison is inconsistent, the inconsistent conversion process and the related data in the REE are matched in a security policy, various abnormal conditions and corresponding processing measures are preset in the security policy, a matched target processing measure is obtained, and the target processing measure is output and executed. And the correctness and the real-time performance of attack resistance of the PLC are improved.

Description

Technical Field

[0001] This application relates to the field of industrial control technology, and in particular to a TrustZone-based PLC safety monitoring method, a TrustZone-based PLC safety monitoring device, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] With the deep integration of industrial automation and information technology, Industrial Control Systems (ICS) have been widely applied in critical national infrastructure sectors such as energy, transportation, and water conservancy. ICS achieve interconnection and interoperability through information technologies such as Ethernet, Transmission Control Protocol (TCP) / Internet Protocol (IP). While improving production efficiency and management flexibility, ICS also face increasingly severe cybersecurity threats.

[0003] Currently, the security of industrial control systems (ICS) primarily relies on traditional information technology (IT) security measures such as network-level firewalls and intrusion detection systems. Taking firewalls as an example, an industrial firewall with deep packet inspection capabilities for ICS protocols is deployed between the ICS network and the enterprise information network. This firewall, based on a whitelist policy, only allows predefined legitimate ICS protocol commands and data packets to pass through, while blocking all unauthorized access and abnormal traffic that does not conform to the specifications.

[0004] However, in industrial control scenarios, sensor data acquisition and control command issuance are typically completed within milliseconds or even microseconds. The process of a firewall parsing, matching, and determining rules for each data packet can easily cause control command transmission timeouts. Furthermore, under high-traffic conditions or network storms, firewalls may become overloaded and drop legitimate control packets, leading to delayed or lost control command responses, ultimately reducing the real-time performance and accuracy of security protection in the industrial control system. Summary of the Invention

[0005] The purpose of this application is to provide a TrustZone-based PLC safety monitoring method, a TrustZone-based PLC safety monitoring device, a computer device, a computer-readable storage medium, and a computer program product, so as to improve the real-time performance and the accuracy of safety protection of industrial control systems.

[0006] To address the aforementioned technical problems, this application provides the following technical solutions: The first aspect of this application provides a PLC safety monitoring method based on TrustZone. The method is applied to the Trusted Execution Environment (TEE) in a Programmable Logic Controller (PLC). The PLC also includes a Rich Execution Environment (REE). The TEE and REE are physically isolated and operate independently. The method includes: collecting data from the input / output (I / O) ports of the REE during operation; determining the next state based on the currently collected data and the recorded current state of the TEE, and recording the next state as the new current state of the TEE if it differs from the current state of the TEE; obtaining the current state of the REE corresponding to the data from the input / output ports and its previous state; comparing the transition process from the current state of the TEE to the next state with the transition process between the previous state and the current state of the REE; if the comparison is inconsistent, matching the inconsistent transition process and its related data in the REE with a safety policy, where the safety policy pre-sets various abnormal situations and their corresponding handling measures, obtaining the matching target handling measures, outputting and executing the target handling measures; if the comparison is consistent, ending the monitoring.

[0007] Compared to existing technologies, the TrustZone-based PLC safety monitoring method provided in the first aspect of this application independently constructs and maintains a state transition model corresponding to the REE control logic within the TrustZone architecture's TEE. It then compares the state transition processes derived internally by the TEE with the actual state transition processes reported by the REE in real time, thereby achieving dual verification and anomaly detection of the PLC's runtime control logic integrity. This not only identifies inconsistencies in state transitions caused by malicious tampering, sensor data forgery, or communication hijacking, but also, combined with a pre-set security policy library, quickly matches abnormal patterns and triggers targeted response measures. Ultimately, this significantly improves the PLC's ability to resist covert attacks and ensure the correctness and real-time performance of control logic behavior in complex industrial control environments.

[0008] In other embodiments provided in this application, determining the next state based on the currently collected data and the current state of the TEE in the records includes: finding the target node corresponding to the current state of the TEE in the state transition graph; finding the target edge connected to the target node and matching the currently collected data in the state transition graph; and determining the state corresponding to the next node reached from the target node along the target edge as the next state; wherein, the state transition graph includes multiple nodes and directed edges connecting the nodes, the nodes are used to represent the state, and the edges are used to represent the conditions that trigger the state transition.

[0009] By formalizing the PLC control logic into a state transition graph with conditional edges and using a graph traversal algorithm for state derivation, the ability to perform real-time and accurate state monitoring and anomaly identification for complex, multi-branch industrial control processes is significantly improved.

[0010] In other embodiments provided in this application, before collecting data from the input / output ports of the REE during operation, the method further includes: generating a process data group based on the PLC control program. The process data group includes a state set, an input set, an output set, an update function, and an initial state. The update function is generated based on the input set and the output set and is used to indicate the control logic of the PLC. Taking the initial state as the starting node, the method searches for the first logic related to the initial state in the update function, takes the input and output information in the first logic as directed edges, and takes the state in the first logic as the first node. Starting from the first node, the method searches for the second logic related to the state corresponding to the first node in the update function, takes the input and output information in the second logic as directed edges, and takes the state in the second logic as the second node, until the node contains the final state, thus obtaining a state transition diagram.

[0011] By automatically parsing the logic structure (Automata) of the PLC control program and generating a state transition diagram that the machine can process, the universality, adaptability, accuracy, and automation of the monitoring system for different PLC applications are significantly improved.

[0012] In other embodiments provided in this application, before collecting data from the input / output ports of the REE during runtime, the method further includes: identifying all input / output ports of the REE; determining the target input / output ports of interest from all input / output ports; generating a checklist of the target input / output ports and adding the checklist to the security policy; collecting data from the input / output ports of the REE during runtime, including: collecting data from the target input / output ports of the REE during runtime.

[0013] By dynamically identifying and filtering key I / O ports that are strongly associated with the control logic for focused monitoring, the targeting and efficiency of monitoring are significantly improved, while reducing system overhead and real-time interference caused by redundant data acquisition.

[0014] In other embodiments provided in this application, the security policy also includes various abnormal levels corresponding to abnormal situations. Abnormal situations include unchanged state, inconsistent data between collected data and REE report data, simultaneous existence of unchanged state and inconsistent data between collected data and REE report data, and program tampering. The corresponding abnormal levels increase sequentially. The inconsistent conversion process and its related data in the REE are matched in the security policy, including: matching the inconsistent conversion process and its related data in the REE in the security policy starting from the lowest level of abnormal situation, and ending the matching after a successful match.

[0015] By prioritizing and matching different anomalies in an orderly manner, the efficiency and accuracy of anomaly diagnosis and security policy execution are significantly improved, avoiding false alarms and over-response.

[0016] In other embodiments provided in this application, obtaining the current state of the REE and its previous state corresponding to the data of the input / output ports in the REE includes: obtaining the current state of the REE and its previous state corresponding to the data of the input / output ports in the REE within a certain duration.

[0017] By setting a duration window to acquire status data, the ability to capture brief, intermittent anomalies or attacks (such as pulse interference) and the reliability of monitoring are significantly improved.

[0018] In other embodiments provided in this application, the TEE connects to the target server via a secure encrypted channel, and the target server connects to the target browser; outputting and executing target processing measures includes: transmitting the target processing measures to the target server via the secure encrypted channel, so that the target server sends the target processing measures to the target browser; the method further includes: receiving modification instructions based on security policies via the secure encrypted channel; if the modification instructions are remote control instructions, performing multiple verifications on the modification instructions; if the verification passes, modifying the security policy based on the modification instructions.

[0019] By establishing an end-to-end encrypted remote management channel and implementing a multi-factor authentication mechanism, the convenience and operational security of remotely and securely configuring and updating PLC safety policies have been significantly improved.

[0020] In other embodiments provided in this application, collecting data from the input / output ports of the REE during runtime includes: collecting data from the input / output ports of the REE during runtime according to a preset period; and generating a change event when the currently collected data is different from the previously collected data, the change event being used to indicate the generation of the next state.

[0021] By combining periodic data collection with a change event triggering mechanism, the real-time response efficiency of monitoring is significantly improved, and unnecessary system computation and communication overhead during periods of stable data is reduced.

[0022] The second aspect of this application provides a PLC safety monitoring device based on TrustZone. The device is applied to the Trusted Execution Environment (TEE) in a programmable logic controller (PLC). The PLC also includes a Normal Execution Environment (REE). The TEE and REE are physically isolated and operate independently. The device includes: an I / O request execution module for collecting data from the input / output ports of the REE during operation; a status detection module for determining the next state based on the currently collected data and the recorded current state of the TEE, and recording the next state as the new current state of the TEE if it differs from the current state of the TEE; the status detection module is also used to obtain the current state of the REE corresponding to the data from the input / output ports in the REE and its previous state; a scheduling trigger module for comparing the transition process from the current state of the TEE to the next state with the transition process between the previous state and the current state of the REE; an execution module for matching the inconsistent transition process and its related data in the REE within a safety policy if the comparison is inconsistent. The safety policy pre-sets various abnormal situations and their corresponding handling measures, obtains the matching target handling measures, outputs and executes the target handling measures; the execution module is also used to terminate the monitoring if the comparison is consistent.

[0023] A third aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method of the first aspect.

[0024] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of the first aspect.

[0025] The fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of the first aspect.

[0026] The TrustZone-based PLC safety monitoring device provided in the second aspect of this application, the computer equipment provided in the third aspect, the computer-readable storage medium provided in the fourth aspect, and the computer program product provided in the fifth aspect have the same or similar beneficial effects as the TrustZone-based PLC safety monitoring method provided in the first aspect. Attached Figure Description

[0027] The above and other objects, features, and advantages of exemplary embodiments of this application will become readily understood by reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of this application are illustrated by way of example and not limitation, with the same or corresponding reference numerals denoteing the same or corresponding parts, wherein: Figure 1 This is a schematic diagram of the application scenario architecture of the PLC safety monitoring method based on TrustZone in the embodiments of this application; Figure 2 This is a flowchart illustrating the PLC safety monitoring method based on TrustZone in the embodiments of this application. Figure 1 ; Figure 3 This is a flowchart illustrating the PLC safety monitoring method based on TrustZone in the embodiments of this application. Figure 2 ; Figure 4 This is a schematic diagram of the structure of the PLC safety monitoring device based on TrustZone in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of the computer device in the embodiments of this application. Detailed Implementation

[0028] Exemplary embodiments of this application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0029] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains.

[0030] Current security measures for industrial control systems (such as industrial firewalls) introduce additional latency and drop legitimate packets under high load due to deep packet inspection at the network layer, making it difficult to balance the contradiction between real-time control requirements and precise security protection.

[0031] The root of these technical problems lies in the structural contradiction between traditional IT security methods and the inherent characteristics of Industrial Control Systems (ICS). Specifically, firewalls and other devices deployed at the network boundary cannot directly protect the core control logic and data running inside terminal devices such as PLCs. Once an attack penetrates the network defenses, it can easily penetrate the system. Furthermore, industrial control scenarios have stringent requirements for determinism and low latency, while security mechanisms based on deep packet inspection inevitably introduce uncontrollable processing delays, which can easily become performance bottlenecks, especially during traffic surges. Finally, traditional methods focus on network traffic and protocol compliance, lacking the ability to perceive and verify fine-grained behaviors such as PLC internal state transitions and the consistency of control command sequence logic, making it difficult to detect covert attacks targeting the control logic itself.

[0032] In view of this, embodiments of this application provide a PLC safety monitoring method based on TrustZone, a PLC safety monitoring device based on TrustZone, a computer device, a computer-readable storage medium, and a computer program product. Based on the hardware isolation provided by the TrustZone architecture, an independent state monitoring and verification loop is constructed within the TEE, running parallel to the main PLC control loop in the REE. This loop actively collects I / O data from the REE, derives the expected state transition sequence within the TEE based on a predefined control logic model, and simultaneously obtains the actual state transition sequence reported by the REE, comparing the two in real time. If an inconsistency is detected, it indicates an anomaly in the control logic execution. The system then performs pattern matching according to a preset security policy library and executes corresponding handling measures, thereby achieving real-time, proactive, and precise protection of the integrity of the PLC's runtime control logic.

[0033] It should be noted that the user data, data acquisition, and / or use involved in the embodiments of this application strictly comply with the laws, regulations, and industry standards of relevant countries and regions. The collection and acquisition of data involved in the embodiments of this application are all done in advance by actively prompting or prominently displaying information to inform users and obtaining authorization, or by obtaining full authorization from all parties. The processing, manipulation, forwarding, and use of data involved in the embodiments of this application are all carried out on the premise that the user or relevant party is fully informed and authorized. In implementing the various embodiments of this application, the types of data or information, scope of use, and usage scenarios that may be involved are informed to users or relevant parties and authorization is obtained through appropriate means. The specific methods of notification and authorization may vary according to the actual situation, and this application is not limited in this regard. The processing of personal information involved in the embodiments of this application is carried out under the premise of having a legal basis (such as obtaining the consent of the personal information subject or being necessary for the performance of a contract), and is only processed within the prescribed or agreed scope. Sensitive personal information such as biometric information, medical and health information, financial account information, and precise location information involved in the embodiments of this application are all processed under the premise of having a specific purpose and sufficient necessity, and with the separate authorization and consent of the user or relevant party. In some embodiments of this application, if the user or related party refuses to process personal information other than the information necessary for the basic functions, it will not affect the use of the basic functions of the embodiments of this application.

[0034] First, the application scenarios of the PLC safety monitoring method based on TrustZone provided in the embodiments of this application will be described.

[0035] Figure 1 This is a schematic diagram of the application scenario architecture of the PLC safety monitoring method based on TrustZone in the embodiments of this application. See [link / reference]. Figure 1 As shown, the architecture may include an industrial programmable logic controller (PLC) device employing ARM TrustZone technology.

[0036] At the hardware level, it is divided into two physically isolated and independently operating execution environments. The first is the Normal Execution Environment (REE), which is the traditional PLC runtime environment, including control logic programs, operating system, I / O drivers, etc. It is responsible for executing normal industrial scanning cycles (such as reading sensor inputs, executing control algorithms, and driving actuator outputs). The second is the Trusted Execution Environment (TEE), a lightweight, highly secure execution environment with higher hardware security privileges. It can proactively and covertly monitor the I / O activity and memory status of the REE, and independently run a set of security monitoring logic within the TEE to verify and protect the integrity and correctness of the control logic within the REE.

[0037] The TEE contains at least five major modules.

[0038] The Status Monitoring module (Monitor) is responsible for building and maintaining a mirror model within the TEE that reflects the operational status of the PLC control logic in the REE. In the offline phase, it parses the issued control logic program, formalizing it into a process data set (Automata), i.e., generating a state transition diagram consisting of states, inputs, outputs, and transition functions, and recording the mapping relationships of the physical I / O ports bound to this logic. In the online phase, it actively collects data changes from key I / O ports in the REE through the system module (I / O Trapper). Based on the collected data and the pre-generated state transition diagram, it derives and updates the current control state of the system (TEE current state). It also provides a status query interface for the Trigger and Enforcer modules.

[0039] The Trigger module is responsible for analyzing state changes and deciding when and what type of safety response to trigger. Specifically, it periodically or on an event-based basis accesses the Monitor module to obtain the latest control status. It compares the current status with historical states to determine if the control logic has undergone unexpected or abnormal transitions. If the state change is abnormal, it analyzes its severity and, based on the security policy, decides which(s) of the Enforcer's safety processes (such as alarms, logging, and blocking) to activate. It is responsible for managing the priority and scheduling of these safety tasks to ensure that critical responses are executed in a timely manner.

[0040] The Enforcer module is responsible for implementing specific safety actions and providing external interfaces. Specifically, it executes predefined safety response measures based on instructions from the Trigger module. Examples include generating safety event logs, sending alarms to the host computer via a safety channel, or triggering a system safety state (such as shutdown) in extreme situations. It also provides a remote management interface. Through remote nodes such as HMIs, operators can securely connect to the Enforcer module to obtain PLC operating status logs and safety event reports, and dynamically update the safety policy library (such as adjusting the legal rules for state transitions and modifying abnormal response thresholds).

[0041] The I / O request execution module (I / O Trapper) is responsible for capturing all I / O operations entering and leaving the REE. Specifically, it leverages the hardware features of TrustZone to monitor and intercept REE access requests to specific memory-mapped I / O regions. The captured raw I / O data is then initially encapsulated. Through a secure internal interface, the encapsulated I / O data is provided in real-time to the Monitor module as its primary data source for status assessment.

[0042] The Memory Tracing (MEM) module is responsible for ensuring the integrity of the PLC control program itself. Specifically, it utilizes TrustZone's memory protection mechanism to measure the integrity of the control logic binary code (code domain) and critical data areas stored in REE memory. It periodically or trigger-based checks are performed on these critical memory areas to prevent malicious tampering, using methods such as hash value calculation or digital signature verification. If unauthorized modification of code or critical static data is detected, it immediately reports to the Trigger or Enforcer module, triggering the highest level of security response.

[0043] These five modules constitute a complete defense-in-depth system. The I / O Trapper and MEM Tracer provide data acquisition and code protection at the system and data levels. The Monitor performs state modeling based on the acquired data. The Trigger analyzes and makes decisions based on the model output. The Enforcer ultimately executes the response action. The five modules work together to form a proactive security monitoring loop within a hardware-isolated TEE, which can effectively deal with advanced threats such as logical tampering and data forgery.

[0044] Next, the TrustZone-based PLC safety monitoring method provided in the embodiments of this application will be described in detail.

[0045] Figure 2 This is a flowchart illustrating the PLC safety monitoring method based on TrustZone in the embodiments of this application. Figure 1 See Figure 2 As shown, the method may include: S21: Collect data from the input / output ports of the REE during operation.

[0046] When the REE is running, the PLC performs standard industrial control tasks. The REE, through its I / O drivers, synchronously or asynchronously reads external field signals (such as temperature, pressure, and switch status) from physical sensors and digital input modules, and stores them in the Process-Image Input Table (PIIT). During PLC operation, the user-written control program is executed sequentially, performing logical operations and numerical calculations based on the input values ​​in the PIIT, and updating internal variables and the Process-Image Output Table (PIOT). The final results in the PIOT are then written to physical actuators, relays, analog output modules, etc., to control the actions of field devices.

[0047] The data collected by the input / output ports during REE operation refers to the digital signal values ​​in the process image area (PIIT and PIOT) of the REE that are directly related to the PLC control logic and can be monitored by the TEE safety module. For example, the on / off status data of a switch or sensor (such as a proximity switch or photoelectric sensor), port: %IX0.0 (bit 0 of input byte 0), data: 1, indicates that the emergency stop button connected to the PLC's digital input channel 0 is not pressed.

[0048] During the actual data collection, the I / O request execution module located at the TEE system layer utilizes the TrustZone hardware's access control capabilities for memory and system bus access. It captures REE's read and write operations on I / O-mapped memory in the process image area through silent monitoring or controlled bypass. This module then transmits the target address and data content of these operations to the Monitor module at the TEE application layer in real time via a secure internal channel. This enables the TEE to proactively, seamlessly, and with low overhead collect I / O data from the REE runtime.

[0049] S22: Determine the next state based on the currently collected data and the current state of the TEE recorded, and if the next state is different from the current state of the TEE, record the next state as the new current state of the TEE.

[0050] Specifically, the pre-built control state transition diagram (Automata) within the TEE can be used. The collected current I / O data from the REE can be used as input, combined with the previous reliable state maintained by the TEE (the current TEE state). By querying the corresponding transition function in the state transition diagram, the next correct state that the PLC control logic should enter in the current scan cycle can be logically deduced. If the deduced next state differs from the recorded current TEE state, it means that the control logic has undergone a legitimate state transition according to the model. In this case, the deduction result needs to be updated to the new current state to keep the internal state model of the TEE synchronized with the expected control flow.

[0051] For example, suppose a motor start-stop control process has a state transition diagram defined within the TEE as: Stop (S0) -- [Start button pressed and no fault] --> Run (S1) -- [Stop button pressed or fault] --> Stop (S0). The current TEE-recorded state is S0 (Stop). If, during the current monitoring cycle, the I / O Trapper module collects data of 1 (pressed) for the input port corresponding to the "start button" in the REE, and 0 (no fault) for the "fault signal" input port, the Monitor module, based on this data, searches for an edge in the state transition diagram starting from node S0 that matches the condition "start = 1 and fault = 0," and this edge points to node S1. Therefore, the derived "next state" is S1 (Run). Since S1 is different from the currently recorded S0, the Monitor module updates the current TEE state to S1, thus synchronizing the expected state transition of the control logic "the motor should be started" within the TEE.

[0052] When determining the next state, logical judgment can also be based on rules. The legal behaviors of the control logic are pre-abstracted into a security rule base consisting of IF-THEN conditional statements. Each rule explicitly specifies the allowed next state or output action under a specific input combination and the current state. At runtime, the Monitor module takes the currently collected I / O data and the current state of the TEE as input and iterates through the rule base for pattern matching. If all the preconditions of a rule are met, the conclusion of that rule (i.e., the specified next state) is used as the derivation result.

[0053] S23: Obtain the current state of the REE and its previous state corresponding to the data of the input / output ports in the REE.

[0054] In practice, the Monitor module can start with the currently collected REE I / O data and search for the state corresponding to the node that matches the data in the state transition graph. This state is then identified as the current state of the REE. The previous state of the REE is obtained by querying the historical state recorded by the Monitor module itself in the previous monitoring period.

[0055] Alternatively, a lightweight monitoring thread can be embedded in the REE's PLC runtime environment. This thread proactively pushes key status variables of the current control flow (such as step number and master control step flag) to the TEE via the TrustZone Secure Call (SMC) interface. Alternatively, the TEE can define a structured status query interface through a secure shared memory area, and the REE writes its own status to this area at the end of each scan cycle, thus achieving status retrieval.

[0056] S24: Compare the transition process from the current state of TEE to the next state with the transition process from the previous state to the current state of REE.

[0057] For example, suppose the state transition rule for a motor control process is: Stop (S0) can only transition to Run (S1) upon receiving a "Start=1 and no fault" signal. The TEE, based on the currently collected I / O data (Start=0, Fault=0) and its recorded previous state (S0), derives the next state as S0 (Stay Stop), meaning the TEE transition is S0→S0. However, if the Monitor module, based on the same I / O data, derives the current REE state as S1 (Run), while its historical records show the previous REE state as S0, then the REE reports the transition as S0→S1. In this case, the two transition processes are inconsistent.

[0058] For another example, for the same motor control process, the state transition rules remain unchanged. The TEE, based on the currently collected I / O data (start=1, fault=0) and its recorded previous state (S0), derives the next state as S1 (running), meaning the TEE transition process is S0→S1. Simultaneously, the Monitor module, based on the same I / O data, derives the current REE state as S1, and its historical REE previous state is S0, meaning the REE report transition process is also S0→S1. In this case, the expected state transition sequence derived internally by the TEE is completely consistent with the actual state transition sequence derived from the REE I / O data.

[0059] S25: If the comparison is inconsistent, the inconsistent conversion process and its related data in the REE will be matched in the security policy. The security policy has various abnormal situations and their corresponding handling measures preset, and the matching target handling measures will be obtained, output and executed.

[0060] Inconsistency means that the actual execution behavior of the PLC control logic has deviated from the expected behavior defined by the TEE internal safety model, indicating potential safety violations or anomalies, and thus requiring safety protection.

[0061] The safety policies here are a set of rules pre-defined within the TEE (Tracking Equipment) to define anomaly patterns, assess risk levels, and specify response actions. Each policy can include trigger conditions (anomaly characteristics), severity rating, and response instructions. For example: Policy A (Low-level Alarm): Trigger Condition: The state remains unchanged, but critical I / O data continues to fluctuate beyond the noise threshold. Response: Log the event and mark it as "sensor signal interference," without interrupting control. Policy B (Medium-level Interruption): Trigger Condition: The state transition derived by the TEE is inconsistent with the state transition reported by the REE (Remote Refrigeration Equipment) on the critical control path (e.g., S0→S1 vs S0→S0). Response: Trigger a safety alarm to the host computer and lock the current output to maintain the system in a safe state.

[0062] When a discrepancy occurs, the Enforcer module first receives a call from the Trigger module, providing a description of the inconsistent conversion process and a snapshot of the relevant I / O data. Next, the Enforcer performs pattern matching in its local security policy library, prioritizing policies (from low to high) and comparing the incoming anomaly characteristics with the trigger conditions of each policy until a matching policy is found. Then, the Enforcer executes the corresponding handling measures. If logging is required, the data is written to the TEE secure storage area. If an alarm is triggered, the HMI is notified via a secure channel. If output is locked or the system is shut down, security instructions are written to specific control registers of the REE via the I / O Trapper module, or the TEE kernel's security control primitives are called directly.

[0063] S26: If the comparison is consistent, then the monitoring will end.

[0064] Consistency means that during this monitoring period, the expected control behavior derived from the TEE internal state transition model is completely consistent with the control behavior derived from the actual I / O data of the REE. This indicates that the execution of the PLC control logic has not detected any identifiable abnormalities or tampering, and the system is within the expected safe state range.

[0065] Next, the system will perform the following actions: The current monitoring process will conclude normally. The Monitor module in the TEE will update its status history and continue monitoring I / O data changes at a preset cycle, awaiting the next monitoring trigger. Simultaneously, the PLC main control loop in the REE will continue to run without interference, ensuring the real-time performance of the industrial control process remains unaffected. The entire system will remain in normal monitoring mode until the next status change event or monitoring cycle is triggered.

[0066] As described above, the TrustZone-based PLC security monitoring method provided in this application independently constructs and maintains a state transition model corresponding to the REE control logic within the TrustZone architecture's TEE. It then compares the state transition process derived internally by the TEE with the actual state transition process reported by the REE in real time, thereby achieving dual verification and anomaly detection of the PLC's runtime control logic integrity. This not only identifies inconsistencies in state transitions caused by malicious tampering, sensor data forgery, or communication hijacking, but also, combined with a preset security policy library, quickly matches abnormal patterns and triggers targeted handling measures. Ultimately, this significantly improves the PLC's ability to resist covert attacks and ensure the correctness and real-time performance of control logic behavior in complex industrial control environments.

[0067] Furthermore, as a response to Figure 2 In a refinement and extension of the method shown, this application also provides a PLC safety monitoring method based on TrustZone.

[0068] Figure 3 This is a flowchart illustrating the PLC safety monitoring method based on TrustZone in the embodiments of this application. Figure 2 See Figure 3 As shown, the method may include: S31: Generate a state transition diagram based on process data groups.

[0069] In order to transform the complex PLC control logic into a formal model that can be automatically parsed and monitored by the machine, the key elements (state, input, output, and transition relationship) of the control program source code are extracted and reconstructed into a conditional finite state automaton, thereby generating the basic data structure for state deduction and comparison within the TEE—the state transition diagram.

[0070] Specifically, step S31 above may include: S311: The PLC-based control program generates a flow data group, which includes a state set, an input set, an output set, an update function, and an initial state. The update function is generated based on the input and output sets and is used to indicate the PLC's control logic.

[0071] A process data set is a mathematical representation of a finite state automaton used to precisely describe the logical behavior of a PLC control program. It includes five core elements: Set of States (S): The set of all discrete, meaningful stable phases or modes that the PLC control logic may be in during operation.

[0072] Input set (I): The set of all external signals or internal conditions that can cause a change in the control state.

[0073] Output set (O): The set of control commands issued by the PLC to external actuators or internal variables under a specific state, or when a state transition occurs.

[0074] The transition function (f) is a mapping rule that determines which next state the system will transition to and what output will be produced given the current state and the current input. It is the core of the control logic.

[0075] Initial State (s_init, Initial State): The initial logic state of the PLC control system after startup or reset, before receiving any valid input.

[0076] Taking single-motor start / stop and overload protection control as an example, the process data group includes: 1. State set S S = {Stopped, Running, Faulted} 2. Input set I I = {Start button, Stop button, Overload signal} Each input is a Boolean value: The start button is ∈ {0,1} (0 = not pressed, 1 = pressed). Stop button ∈ {0,1} Overload signal ∈ {0,1} (0=normal, 1=overload) 3. Output set O O = {Motor drive} The output is a Boolean value: Motor drive ∈ {0,1} (0 = power off, 1 = power on) 4. Initial state s init s init =Stop 5. Update function f (represented in the form of "current state + input → next state + output")

[0077] S312: Take the initial state as the starting node, find the first logic related to the initial state in the update function, take the input and output information in the first logic as directed edges, and take the state in the first logic as the first node.

[0078] S313: Starting from the first node, find the second logic related to the state corresponding to the first node in the update function, take the input and output information in the second logic as directed edges, and take the state in the second logic as the second node, until the node contains the final state, and obtain the state transition graph.

[0079] The initial state refers to the starting control state defined in the process data group, and it is the only entry point for constructing the state transition diagram.

[0080] A node represents a control state defined in a process data group and is the specific carrier of the state in the diagram.

[0081] A directed edge is a directed line segment connecting two nodes. It represents the conditions and actions for state transitions. The label on the edge contains the input conditions required to trigger the transition and the output action generated during the transition.

[0082] The first logic / second logic refers to the state transition rules defined in the update function, that is, the complete mapping relationship of "current state + input → next state + output", which is the rule basis for generating nodes and directed edges.

[0083] The final state refers to the state derived from the update function that no longer undergoes a legal transition under certain conditions (it may be a normal termination state or an absorption / error state).

[0084] During the transformation process, taking the click control flow data group mentioned above as an example, the initial state "Stop" is used as the starting node. The update function searches for all rules with "Stop" as the current state. A unique valid rule is found: (Stop, (1,0,0)) → (Run, 1). Based on this, a directed edge is created starting from the "Stop" node, labeled with the input conditions start=1, stop=0, overload=0, and the output action motor drive=1. This edge points to the newly created "Run" node.

[0085] Given the "Running" node as the current state, find the update functions: Rule (Running, (0,1,0)) → (Stop, 0): Creates an edge from "Running" to "Stop", labeled "Stop = 1", and outputs "Motor Drive = 0". Rule (Running, (0,0,1)) → (Stop, 0): Creates another edge from "Running" to "Stop", labeled "Overload = 1", and outputs "Motor Drive = 0". Rule (Running, (0,0,0)) → (Running, 1): Creates a self-loop edge from "Running" to itself, labeled with all inputs as 0, and outputs "Motor Drive = 1".

[0086] The "Stop" node already exists, and all its outgoing edges (only one to "Run") have been processed. According to the update function, the "Fault" state is in an absorbing state (remaining faulty and outputting 0 under any input). Create a "Fault" node and create a self-loop edge pointing to itself, labeled "Any Input," with an output of 0. This node can be derived from "Run" under overload conditions.

[0087] The state transition graph is complete when all rules corresponding to all states in the update function have been processed and no new states are generated. The final result is a state transition graph containing three nodes: "Stop," "Run," and "Failure," as well as several directed edges with condition labels.

[0088] S32: Label the target input / output ports and generate a checklist for the target input / output ports.

[0089] In order to significantly reduce the overhead of safety monitoring on the real-time performance of the PLC system while ensuring the effectiveness of monitoring, all I / O ports of the REE are intelligently filtered, and only key ports directly related to the core control logic are locked for data collection. This generates a high-priority monitoring list and incorporates it into the safety policy, thereby achieving accurate and efficient safety monitoring.

[0090] Specifically, step S32 above may include: S321: Identifies all input / output ports of the REE.

[0091] By parsing the memory mapping layout and symbol table information of the Process Image Input Table (PIIT) and Process Image Output Table (PIOT) during PLC runtime in the REE, or by scanning the I / O device tree and driver registry in the REE operating system, a list of addresses and types of all configured physical and logical I / O ports can be obtained.

[0092] S322: Identify the target input / output ports of interest from all input / output ports.

[0093] The key input / output ports to focus on are I / O ports that are directly related to the safety-critical functions or core business processes of the PLC control logic. Changes in the data on these ports directly affect control state transitions or reflect the system's safety boundary conditions.

[0094] For example, suppose in a reactor temperature control system, the target input ports include: analog input from a temperature sensor (e.g., %IW100) and digital input from an emergency stop button (e.g., %IX0.0). Target output ports include: digital output from heater control (e.g., %QX0.5) and analog output from a cooling water valve (e.g., %QW200). Less critical target input / output ports may include status indicator outputs (e.g., %QX1.2) or auxiliary sensor inputs (e.g., ambient humidity).

[0095] S323: Generate a checklist for the target input / output ports and add the checklist to the security policy.

[0096] The checklist may include: a unique identifier for each target input / output port (such as a memory address or logical variable name), data type (Boolean, integer, floating point, etc.), the range of values ​​or set of states under normal operating conditions, the sampling period, and the relationship with specific nodes or edges in the state transition diagram.

[0097] During the actual generation process, the Monitor module, in the offline phase, automatically extracts the I / O variables that all transition conditions (directed edges) in the graph depend on by parsing the control program and the constructed state transition graph. Combined with manually preset safety-critical annotations, it generates a structured list of monitoring points.

[0098] Adding checklists to security policies can transform abstract monitoring key points into specific monitoring tasks with clear execution parameters that can be directly invoked by various security modules within the TEE (especially I / O Trapper and Monitor), thereby achieving standardized, configurable, and precise monitoring of security-critical I / O behaviors.

[0099] S33: Collect data from the target input / output ports of the REE during runtime according to a preset cycle; and, if the currently collected data is different from the data collected in the previous period, generate a change event, which is used to indicate the generation of the next state.

[0100] In actual operation, the I / O Trapper module within the TEE acts as a system-level monitoring agent, actively reading data snapshots of the target ports listed in the checklist in the REE memory at fixed millisecond intervals (e.g., 10ms, synchronized with the PLC scan cycle or an integer multiple thereof). For example, in a motor control scenario, it continuously reads the values ​​of the "Start Button" input (%IX0.0) and the "Fault Signal" input (%IX0.1). If, in a certain cycle, it detects that the "Start Button" changes from 0 to 1, while the "Fault Signal" remains at 0, the I / O Trapper immediately generates a change event. This event carries the port identifier and the new data and is transmitted to the Monitor module through a secure channel.

[0101] This combination enables timely and accurate responses to critical state changes while ensuring real-time monitoring and low overhead, thus efficiently balancing the coverage of continuous monitoring and the sensitivity of event triggering in resource-constrained embedded environments.

[0102] S34: Based on the state transition diagram, determine the next state according to the currently collected data and the current state of the TEE in the records, and if the next state is different from the current state of the TEE, record the next state as the new current state of the TEE.

[0103] The state transition graph includes multiple nodes and directed edges connecting the nodes. Nodes represent states, and edges represent the conditions that trigger state transitions.

[0104] Specifically, step S34 above may include: S341: Find the target node corresponding to the current state of the TEE in the state transition graph.

[0105] S341: Find the target edge in the state transition graph that matches the currently collected data and is connected to the target node.

[0106] S343: Determine the state of the next node reached from the target node along the target edge as the next state.

[0107] When determining the next state, for example, suppose the state transition diagram of a liquid level control system contains three nodes: low liquid level (S0), normal (S1), and high liquid level (S2). The directed edges originating from S1 include: transitioning to S2 when "inlet valve opening > 50% and liquid level continues to rise," transitioning to S0 when "outlet valve opening > 50% and liquid level continues to fall," and otherwise remaining in S1. If the current state recorded by the TEE is S1 (normal), and the data collected in this cycle is "inlet valve opening = 60%, liquid level change rate = +2cm / s," then the Monitor module first locates the target node S1 in the diagram. Next, it searches for all edges originating from S1 and matches them with the current data, finding that the condition "inlet valve opening > 50% and liquid level continues to rise" is fully satisfied, thus determining the target edge as the edge pointing to S2. Finally, it follows this edge to reach the next node S2, thus determining the next state as high liquid level (S2).

[0108] Next, in the presence of brief interference or asynchronous attacks (such as pulse signal injection), a single sampling may result in misjudgment or missed detection. In order to ensure the stability and anti-interference of state acquisition, multiple sampling and state determination can be performed within a set continuous observation window to obtain a more representative current state of the REE and its previous state.

[0109] S35: During the duration, obtain the current state of the REE and its previous state corresponding to the data of the input / output ports in the REE.

[0110] Duration refers to the length of a pre-defined time window used to observe and collect REE I / O data to determine its steady state.

[0111] When determining the duration, one can use the inertial time constant of the PLC control logic, which is the shortest time required for a significant state change in the controlled physical process (such as temperature rise or motor acceleration), to ensure that the window can capture the actual state transition. Alternatively, one can use the system's maximum allowable detection delay, which is the upper limit of the tolerable lag between the occurrence of an anomaly and the safety response, and must be set within real-time constraints. For example, for a fast protection loop with a response requirement of 100 milliseconds, the duration might be set to 20-30 milliseconds (containing 3-5 scan cycles) to balance anti-interference capability and detection timeliness.

[0112] When comparing over a period of time, if there is a slight delay in the REE status report, the system will use a sliding window comparison mechanism to align the continuous state sequence derived by TEE with the state sequence reported by REE within the time window and perform fault tolerance matching. This allows the REE status to appear with a delay within a reasonable delay threshold (such as 1-2 sampling periods), but if it exceeds the threshold or the logical order is inconsistent, it will be judged as inconsistent.

[0113] S36: Compare the transition process from the current state of TEE to the next state with the transition process from the previous state to the current state of REE.

[0114] S37: If the comparison is inconsistent, the inconsistent conversion process and its related data in the REE will be matched in the security policy to obtain the matching target processing measures.

[0115] To achieve accuracy and efficiency in security responses under complex and abnormal scenarios, and to avoid triggering multiple conflicting strategies or over-responding due to a single anomaly, a hierarchical and categorized anomaly handling mechanism can be established. The mechanism should be executed on the first match according to the order of priority from low to high, ensuring that the system can respond to security events in the most appropriate and timely manner.

[0116] Specifically, the security policy also includes various abnormal situations and their corresponding abnormal levels. Abnormal situations include unchanged state, inconsistent data between collected data and REE report data, simultaneous occurrence of unchanged state and inconsistent data between collected data and REE report data, and program tampering. The corresponding abnormal levels increase in that order.

[0117] "Unchanged status" means that within the preset monitoring period, the status derived by the TEE from I / O data remains unchanged. However, this phenomenon may be normal (e.g., system standby) or abnormal (e.g., sensor jamming, control logic infinite loop). This is the lowest level.

[0118] Inconsistency between collected data and REE reported data refers to a difference between the raw I / O values ​​collected by the TEE through the I / O Trapper and the values ​​reported by the REE itself through its internal variables or externally (such as data in communication messages). This suggests potential data tampering, communication hijacking, or internal data corruption within the REE. The severity level is slightly higher.

[0119] The coexistence of unchanged state and inconsistencies between the collected data and the REE-reported data refers to the combined effect of the two aforementioned situations. For example, external sensor feedback (TEE acquisition) may show changes, but the REE's internal state variables remain unchanged, and the data reported by the REE also retains the old values. This strongly suggests that the REE's runtime environment or control logic has been systematically affected, potentially involving more complex attacks. This is a high-level threat.

[0120] Program tampering occurs when the MEM Tracer module detects a failure to verify the hash value / signature of the PLC control program's code area or critical static data area. This is the most serious anomaly, indicating that an attacker has successfully implanted malicious code or tampered with core logic, compromising system integrity. It is the highest level of severity.

[0121] Step S37 above may include: matching inconsistent conversion processes and their related data in the REE in the security policy starting from the lowest level of anomalies, and ending the matching after a successful match.

[0122] The relevant data in the REE for inconsistent transitions refers to the raw data and context information captured from the REE runtime environment when the TEE detects an inconsistent state transition, which is directly related to the current exception event. Examples include: the original I / O register snapshot value corresponding to the occurrence of the exception transition (e.g., %IW100=27648), the status of relevant variables in the REE internal process image table (e.g., the corresponding bit in PIIT), and the reported values ​​related to that I / O point in the REE's external communication messages (e.g., MODBUS TCP response frames) within that cycle.

[0123] During the matching process, the execution module first extracts the characteristics of the inconsistent conversion process and the related I / O data context. Then, starting from the lowest anomaly level in the security policy library (e.g., unchanged state), it compares the current anomaly characteristics with the trigger conditions of all policies at that level. If a match is successful (e.g., the state has indeed not changed and the normal waiting period has been exceeded), the corresponding handling measures for that level are immediately executed (e.g., logging), and the matching process for subsequent higher levels is terminated. If a match fails, it automatically escalates to the next higher level (e.g., inconsistent data) and repeats the above comparison until a successful match and response are achieved at a certain level. This first-match-and-termination mechanism ensures timely response and prevents the same anomaly event from being repeated or handled in conflict.

[0124] For example, if the motor control logic consistently reports "running" status with no I / O changes for 10 consecutive scan cycles, the low-level "status stagnation" strategy is applied, and only the operation log is recorded. If the TEE collects a level sensor value of 75%, while the REE reports 70% to SCADA, exceeding the 5% tolerance, the medium-level "data inconsistency" strategy is applied, triggering a local alarm. If the REE continuously reports the valve status as "closed" and reports 0% of the data, but the TEE collects a valve feedback signal that is consistently "open," both conditions are met, and the high-level "suspected deep spoofing" strategy is applied, immediately locking the valve control output. If the MEM Tracer detects that the hash value of the main control program code segment does not match the securely stored baseline value, the highest-level "code integrity violation" strategy is directly applied, executing an emergency shutdown and encrypting and uploading a complete event snapshot.

[0125] In industrial scenarios requiring remote operation and maintenance or centralized monitoring, in order to achieve unified and dynamic security management of distributed PLC devices, an end-to-end encrypted communication link can be established within the TEE, and instruction-level identity authentication and operation verification can be implemented. This allows authorized personnel to securely receive alarms, query status, or update protection rules through a browser interface.

[0126] Specifically, the TEE uses a secure encrypted channel to connect to the target server, and the target server connects to the target browser.

[0127] The secure encrypted channel here utilizes the TEE's built-in cryptographic coprocessor and secure storage area to negotiate and maintain session keys between the TEE and the remote target server. All transmitted data (such as alarm messages and policy update commands) is encrypted (e.g., AES-GCM) and protected for integrity (e.g., HMAC). Simultaneously, both ends of the channel use two-way certificate authentication (the TEE holds a unique device credential, and the server holds an operations and maintenance center certificate) to ensure identity trustworthiness. This channel is independent of the REE's network stack; even if the REE is compromised, attackers cannot eavesdrop on or tamper with data within the channel, thus ensuring the security of remote management operations.

[0128] S38: Transmit the target processing measures to the target server through a secure encrypted channel, so that the target server sends the target processing measures to the target browser.

[0129] After the target handling measures (such as alarm information, status reports, or suggested actions) are pushed to the target browser via the target server, authorized operators log in to the industrial safety operation and maintenance interface on the browser through authentication. The system will display the received handling measures and related contextual data (such as abnormal transition processes, affected I / O points, and timestamps) in a visual format (such as pop-up alarm boxes, updated status panels, and generated event lists). Personnel can use this to assess the level of the safety incident, perform further diagnostics (such as retrieving historical trends and comparing equipment logs), and ultimately decide on subsequent actions through the same interface. For example: confirming and archiving low-level alarms, manually issuing remote control commands (such as resetting the equipment or switching to backup logic), or adjusting the safety rules of the PLC according to the policy template (such as modifying the status transition threshold or updating the I / O monitoring list). The modification commands will be sent again to the Enforcer module in the TEE through a secure encrypted channel to take effect.

[0130] S39: Receive modification instructions based on security policies through a secure encrypted channel; if the modification instructions are remote control instructions, perform multiple verifications on the modification instructions; if the verification passes, modify the security policies based on the modification instructions.

[0131] After receiving a remote modification command through a secure encrypted channel, the Enforcer module first parses the Request Code (RST) in the command. If RST > 1, it is determined to be a remote control command, and a multi-factor authentication process is initiated. The first layer verifies the validity of the command's digital signature and source certificate; the second layer verifies whether the command serial number is protected against replay attacks; and the third layer verifies whether the operation permissions match the predefined roles (e.g., only security administrators can modify policies). If all verifications pass, Enforcer further analyzes the RST value. If RST > 2, it is determined to be a policy change request, and the local security policy set and state trigger mapping table are updated according to the command payload. If RST < 2 but greater than 1, it is determined to be an information access request, and the current status or log is returned. The entire process is completed within the TEE, ensuring the authorization and security of policy modifications.

[0132] When parsing the received request code (RST), if the Enforcer module finds that RST ≤ 1, it immediately determines that the instruction is not a remote control instruction, but rather originates from a local call from another module within the TEE (such as the Trigger module). For example, when RST=0 or RST=1, Enforcer directly identifies it as a security process trigger request initiated by the Trigger module based on local state changes. It then skips all remote verification steps, directly loads the corresponding security process task based on the RST value, and feeds back the task progress information to the Trigger module for scheduling.

[0133] If a remote control command (RST>1) fails at any stage of the multi-factor authentication (e.g., invalid signature, expired certificate, insufficient permissions, or duplicate serial number), the Enforcer module will immediately refuse to execute the command and automatically perform the following security actions. First, it will generate a high-security log event, recording the details of the authentication failure (including the failed stage, the command source, and a timestamp). Second, it will send an authentication failure alert to the target server via a secure encrypted channel, indicating that the remote management end may be attempting unauthorized access. Finally, Enforcer will maintain the existing policy or temporarily increase the local protection level (e.g., enter enhanced monitoring mode) according to the preset default security policy, and may refuse subsequent commands from the same source for a cooling-off period until manual intervention is required.

[0134] S310: If the comparison is consistent, then end this monitoring.

[0135] This concludes the description of the TrustZone-based PLC safety monitoring method provided in this application.

[0136] Based on the same inventive concept, this application also provides a PLC safety monitoring device based on TrustZone.

[0137] This device is used in the Trusted Execution Environment (TEE) of a programmable logic controller (PLC). The PLC also includes a general execution environment (REE). The TEE and REE are physically isolated and operate independently.

[0138] Figure 4 This is a schematic diagram of the structure of the PLC safety monitoring device based on TrustZone in the embodiments of this application. See also Figure 4 As shown, the device may include: I / O request execution module 41 is used to collect data from the input / output ports during REE runtime.

[0139] The status detection module 42 is used to determine the next state based on the currently collected data and the current state of the TEE recorded, and if the next state is different from the current state of the TEE, the next state is recorded as the new current state of the TEE.

[0140] The status detection module 43 is also used to obtain the current status of the REE and its previous status corresponding to the data of the input / output ports in the REE.

[0141] The scheduling trigger module 43 is used to compare the transition process from the current state of TEE to the next state with the transition process from the previous state to the current state of REE.

[0142] Execution module 44 is used to match the inconsistent conversion process and its related data in the REE in the security policy if the comparison is inconsistent. The security policy has various abnormal situations and their corresponding handling measures preset, obtains the matching target handling measures, outputs and executes the target handling measures.

[0143] Execution module 44 is also used to end the monitoring if the comparison is consistent.

[0144] Furthermore, the state detection module 42 is also used to find the target node corresponding to the current state of the TEE in the state transition graph; to find the target edge that matches the currently collected data and is connected to the target node in the state transition graph; and to determine the state of the next node reached from the target node along the target edge as the next state; wherein, the state transition graph includes multiple nodes and directed edges connecting the nodes, the nodes are used to represent the state, and the edges are used to represent the conditions that trigger the state transition.

[0145] Furthermore, the state detection module 42 is also used to generate a process data group based on the PLC control program. The process data group includes a state set, an input set, an output set, an update function, and an initial state. The update function is generated based on the input set and the output set and is used to indicate the control logic of the PLC. Taking the initial state as the starting node, the update function searches for the first logic related to the initial state, uses the input and output information in the first logic as directed edges, and uses the state in the first logic as the first node. Starting from the first node, the update function searches for the second logic related to the state corresponding to the first node, uses the input and output information in the second logic as directed edges, and uses the state in the second logic as the second node, until the node contains the final state, thus obtaining the state transition diagram.

[0146] Furthermore, the I / O request execution module 41 is also used to identify all input / output ports of the REE.

[0147] The status detection module 42 is also used to identify key target input / output ports from all input / output ports; generate a checklist of target input / output ports; and add the checklist to the security policy.

[0148] I / O request execution module 41 is specifically used to collect data from the target input / output ports during REE runtime.

[0149] Furthermore, the security policy also includes various abnormal situations and their corresponding abnormal levels. Abnormal situations include unchanged state, inconsistent data between collected data and REE report data, simultaneous occurrence of unchanged state and inconsistent data between collected data and REE report data, and program tampering. The corresponding abnormal levels increase in that order.

[0150] Execution module 44 is specifically used to match the inconsistent conversion process and its related data in the REE in the security policy starting from the lowest level of anomaly. After a successful match, the matching ends.

[0151] Furthermore, the state detection module 43 is specifically used to acquire the current state of the REE and its previous state corresponding to the data of the input / output ports in the REE during the duration.

[0152] Furthermore, the TEE uses a secure encrypted channel to connect to the target server, and the target server connects to the target browser.

[0153] The execution module 44 is specifically used to transmit the target processing measures to the target server through a secure encrypted channel, so that the target server sends the target processing measures to the target browser; receive modification instructions based on security policies through the secure encrypted channel; if the modification instruction is a remote control instruction, perform multiple verifications on the modification instruction; if the verification passes, modify the security policy based on the modification instruction.

[0154] Furthermore, the I / O request execution module 41 is specifically used to collect data from the input / output ports of the REE during operation according to a preset period; and, if the currently collected data is different from the data collected in the previous period, to generate a change event, which is used to indicate the generation of the next state.

[0155] It should be noted that the description of the above device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0156] Based on the same inventive concept, this application also provides a computer device.

[0157] Figure 5This is a schematic diagram of the structure of the computer device in an embodiment of this application. See also... Figure 5 As shown, the computer device may include: a memory 51, a processor 52, and a computer program stored on the memory 51, wherein the processor 52 executes the computer program to implement the methods described in the foregoing embodiments.

[0158] It should be noted that the description of the above computer device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the computer device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0159] Based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the methods described in the foregoing embodiments.

[0160] It should be noted that the description of the above computer-readable storage medium embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the computer-readable storage medium embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0161] Based on the same inventive concept, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the methods described in the foregoing embodiments.

[0162] It should be noted that the descriptions of the above computer program product embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the computer program product embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0163] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A PLC safety monitoring method based on TrustZone, characterized in that, The method is applied to a Trusted Execution Environment (TEE) in a programmable logic controller (PLC). The PLC also includes a Free Execution Environment (REE). The TEE is physically isolated from and operates independently of the REE. The method includes: Collect data from the input / output ports of the REE during operation; The next state is determined based on the currently collected data and the current state of the TEE recorded. If the next state is different from the current state of the TEE, the next state is recorded as the new current state of the TEE. Obtain the current state and previous state of the REE corresponding to the data of the input / output port in the REE; The transition process from the current state of the TEE to the next state is compared with the transition process from the previous state to the current state of the REE. If the comparison is inconsistent, the inconsistent conversion process and its related data in the REE will be matched in the security policy. The security policy has various abnormal situations and their corresponding handling measures preset to obtain the matching target handling measures, output and execute the target handling measures. If the comparison is consistent, the monitoring will end.

2. The method according to claim 1, characterized in that, The step of determining the next state based on the currently collected data and the current state of the TEE in the records includes: Find the target node corresponding to the current state of the TEE in the state transition graph; In the state transition graph, find the target edge that matches the currently collected data and is connected to the target node; The state corresponding to the next node reached from the target node along the target edge is determined as the next state; wherein, the state transition graph includes multiple nodes and directed edges connecting the nodes, the nodes are used to represent the state, and the edges are used to represent the conditions that trigger the state transition.

3. The method according to claim 2, characterized in that, Before collecting data from the input / output ports of the REE during runtime, the method further includes: The control program of the PLC generates a process data set, which includes a state set, an input set, an output set, an update function, and an initial state. The update function is generated based on the input set and the output set and is used to indicate the control logic of the PLC. Using the initial state as the starting node, the first logic related to the initial state is searched in the update function, and the input and output information in the first logic are used as directed edges, and the state in the first logic is used as the first node. Starting from the first node, the update function searches for the second logic related to the state corresponding to the first node, uses the input and output information in the second logic as directed edges, and uses the state in the second logic as the second node, until the node contains the final state, thus obtaining the state transition graph.

4. The method according to any one of claims 1 to 3, characterized in that, Before collecting data from the input / output ports of the REE during runtime, the method further includes: Identify all input / output ports of the REE; Identify the target input / output ports of primary interest from all of the input / output ports; Generate a checklist for the target input / output port and add the checklist to the security policy; The data collected from the input / output ports of the REE during operation includes: Data from the target input / output ports is collected during the operation of the REE.

5. The method according to any one of claims 1 to 3, characterized in that, The security policy also includes anomaly levels corresponding to various abnormal situations. The abnormal situations include unchanged state, inconsistent data between collected data and REE report data, simultaneous existence of unchanged state and inconsistent data between collected data and REE report data, and program tampering. The corresponding anomaly levels increase in sequence. The process of matching the inconsistent conversion process and its related data in the REE within the security policy includes: The inconsistent conversion process and its related data in the REE are matched in the security policy starting from the lowest level of anomaly. The matching ends after a successful match.

6. The method according to any one of claims 1 to 3, characterized in that, The step of obtaining the current state and previous state of the REE corresponding to the data of the input / output port in the REE includes: During the duration, obtain the current state of the REE and its previous state corresponding to the data of the input / output port in the REE.

7. The method according to any one of claims 1 to 3, characterized in that, The TEE connects to the target server via a secure encrypted channel, and the target server connects to the target browser. The output and execution of the target processing measures include: The target processing measures are transmitted to the target server through the secure encrypted channel, so that the target server sends the target processing measures to the target browser; The method further includes: Receive modification instructions based on the security policy through the secure encrypted channel; If the modification instruction is a remote control instruction, then the modification instruction shall be subject to multiple verifications; If the verification passes, the security policy is modified based on the modification instructions.

8. The method according to any one of claims 1 to 3, characterized in that, The data collected from the input / output ports of the REE during operation includes: Data from the input / output ports of the REE during runtime is collected according to a preset period; and, if the currently collected data differs from the previously collected data, a change event is generated, the change event being used to indicate the generation of the next state.

9. A PLC safety monitoring device based on TrustZone, characterized in that, The device is applied to the Trusted Execution Environment (TEE) in a programmable logic controller (PLC). The PLC also includes a general execution environment (REE). The TEE is physically isolated from and operates independently of the REE. The device includes: The I / O request execution module is used to collect data from the input / output ports of the REE during runtime; The status detection module is used to determine the next state based on the currently collected data and the current state of the TEE in the records, and if the next state is different from the current state of the TEE, the next state is recorded as the new current state of the TEE. The status detection module is also used to obtain the current status of the REE and its previous status corresponding to the data of the input / output port in the REE; The scheduling triggering module is used to compare the transition process from the current state of the TEE to the next state with the transition process from the previous state to the current state of the REE. The execution module is used to match the inconsistent conversion process and its related data in the REE in the security policy if the comparison is inconsistent. The security policy has various abnormal situations and their corresponding handling measures preset, obtains the matching target handling measures, outputs and executes the target handling measures. The execution module is also used to end the monitoring if the comparison is consistent.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

Images