An Open Automated Node Hierarchical Authorization Access Control Method and System

Abstract

This application relates to the field of information technology, specifically to an open automated node hierarchical authorization access control method and system. The method includes: Step 1, generating and distributing a data access configuration detection table: generating a unique data receiving access group identifier ID2, classifying the data, associating and configuring initial local checksums for real-time monitoring and control type and alarm handling type data, associating and configuring initial encryption keys for configuration type data, generating a data access configuration detection table, and distributing it to the nodes that need to receive it; Step 2, sending nodes packaging and sending data according to data type: selecting the corresponding sending strategy to package and send the data; Step 3, receiving nodes verifying and processing the data: the receiving node, based on the unique receiving access group identifier ID2, finds the corresponding data access configuration detection table, deduces the data type based on the communication method, verifies the data and its sending sequence number, and if verification is successful, accepts and processes the data.

Description

Technical Field

[0001] This application relates to the field of information technology, specifically to an open automated node hierarchical authorization access control method and system. Background Technology

[0002] As industrial automation systems evolve towards openness, networking, and intelligence, traditional closed control architectures are gradually being replaced by open node communication modes based on universal network protocols. While this shift enhances system flexibility and interoperability, it also significantly expands the attack surface, making security threats such as unauthorized data access, tampering, or forgery increasingly prominent. Current technologies rely heavily on static permission configurations or uniform encryption strategies for access control, making it difficult to address the diverse real-time, reliability, and security requirements of different data types. Industrial field nodes exhibit vastly different computing resources, ranging from resource-constrained sensors to high-performance edge controllers. A uniform security mechanism often leads to performance bottlenecks in low-end devices or resource waste in high-end devices. Therefore, there is an urgent need to research access control methods that can dynamically adapt security policies based on data attributes, communication methods, and node capabilities. Summary of the Invention

[0003] This specification describes an open, automated node hierarchical authorization access control method and system through several embodiments.

[0004] Firstly, embodiments of this specification provide an open automated node hierarchical authorization access control method, applied to a control system including at least two nodes, wherein the nodes are measurement nodes, control nodes, or execution nodes, including:

[0005] Step 1: Generate and distribute the data access configuration detection table:

[0006] Based on the sending node attributes, application AppID, and data identifier ID1, a unique data receiving access group identifier ID2 is generated.

[0007] The data is categorized into one of the following types based on its attributes: real-time monitoring and control, configuration, or alarm handling. Real-time monitoring and control and alarm handling data are associated with and configured with initial local checksums. Configuration data is associated with and configured with initial encryption keys.

[0008] Based on the unique receiving access group identifier ID2, data structure identifier ID3, data function code ID5, read / write permission ID6, local verification code or encryption key, a data access configuration detection table is generated and distributed to all nodes that need to receive the data.

[0009] Step 2: Sending nodes package and send data according to data type:

[0010] Generate a data transmission sequence number, select the corresponding transmission strategy according to the data type and pre-configured transmission strategy, package the data and its transmission sequence number and send them. The transmission strategy records the communication method for sending data, the security mechanism for verifying data and the packaged data payload.

[0011] Step 3: Receive node verifies and processes data:

[0012] The receiving node uses the unique receive access group identifier ID2 to look up the corresponding data access configuration detection table.

[0013] The data type is determined by reverse engineering the communication method, and pre-configured verification rules are obtained based on the data type. The data and its transmission sequence number are then verified according to the data access configuration detection table and the verification rules.

[0014] Once the verification is successful, the data is accepted and processed.

[0015] Secondly, embodiments of this specification provide an open automated node hierarchical authorization access control system, including:

[0016] The configuration module generates and distributes the data access configuration detection table.

[0017] Based on the sending node attributes, application AppID, and data identifier ID1, a unique data receiving access group identifier ID2 is generated.

[0018] The data is categorized into one of the following types based on its attributes: real-time monitoring and control, configuration, or alarm handling. Real-time monitoring and control and alarm handling data are associated with and configured with initial local checksums. Configuration data is associated with and configured with initial encryption keys.

[0019] Based on the unique receiving access group identifier ID2, data structure identifier ID3, data function code ID5, read / write permission ID6, local verification code or encryption key, a data access configuration detection table is generated and distributed to all nodes that need to receive the data.

[0020] The sending module packages and sends data according to data type:

[0021] Generate a data transmission sequence number, select the corresponding transmission strategy according to the data type and pre-configured transmission strategy, package the data and its transmission sequence number and send them. The transmission strategy records the communication method for sending data, the security mechanism for verifying data and the packaged data payload.

[0022] The receiving module receives, verifies, and processes the data from the receiving nodes.

[0023] The receiving node uses the unique receive access group identifier ID2 to look up the corresponding data access configuration detection table.

[0024] The data type is determined by reverse engineering the communication method, and pre-configured verification rules are obtained based on the data type. The data and its transmission sequence number are then verified according to the data access configuration detection table and the verification rules.

[0025] Once the verification is successful, the data is accepted and processed.

[0026] Thirdly, embodiments of this specification provide an electronic device, including a processor and a memory;

[0027] The processor is connected to the memory;

[0028] The memory is used to store executable program code;

[0029] The processor runs a program corresponding to the executable program code stored in the memory to perform the method described in any of the above aspects.

[0030] Fourthly, embodiments of this specification provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the methods described in any of the above aspects.

[0031] Fifthly, embodiments of this specification provide a computer program product, including a computer program that, when executed by a processor, implements the methods described in any of the above aspects.

[0032] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following:

[0033] In several embodiments of this specification, the provided open automated node hierarchical authorization access control method and system achieve fine-grained and efficient access control decisions by uniquely receiving the access group identifier ID2 to bind data source, application and permission information, and combining it with fast hash index retrieval of the local configuration table, effectively preventing unauthorized access and illegal node access.

[0034] Data is categorized into real-time monitoring and control, configuration, and alarm handling types, and then matched with multicast, unicast, or broadcast communication methods and corresponding security mechanisms. This aligns security policies with business needs, ensuring data integrity and confidentiality while meeting the real-time and reliability requirements of different application scenarios.

[0035] By introducing a dynamic algorithm adaptation mechanism, the appropriate algorithm is automatically selected based on the computing resources of the node. This ensures cryptographic security and avoids the impact of computational overload on control performance of resource-constrained devices, thereby improving the system's compatibility and scalability.

[0036] A dynamic key / verification code update strategy based on communication relationship type was designed, which realizes automatic, synchronous, and reliable rotation of security credentials without manual intervention, thereby enhancing the system's ability to resist replay attacks and long-term key leakage risks.

[0037] Other features and advantages of various embodiments of this specification will be further revealed in the following detailed description and accompanying drawings. Attached Figure Description

[0038] To more clearly illustrate the technical solutions in the embodiments of this specification, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0039] Figure 1 This is a flowchart illustrating the hierarchical authorization access control method provided in this specification.

[0040] Figure 2 This is a diagram illustrating hierarchical authorization access control provided in this specification.

[0041] Figure 3 This is a schematic diagram of the sending strategy provided in this manual.

[0042] Figure 4 This is a schematic diagram of the hierarchical authorization access control system provided in this manual.

[0043] Figure 5 This is a schematic diagram of the electronic device provided in this manual. Detailed Implementation

[0044] The technical solutions of the embodiments of this specification will be explained and described below with reference to the accompanying drawings. However, the following embodiments are only preferred embodiments of this specification and not all of them. Other embodiments obtained by those skilled in the art based on the embodiments in the implementation methods without creative effort are all within the protection scope of this specification.

[0045] The terms "first," "second," "third," etc., in the description, claims, and accompanying drawings are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such processes, methods, products, or apparatus.

[0046] In the following description, terms such as “inner,” “outer,” “upper,” “lower,” “left,” and “right” are used only to facilitate the description of the embodiments and to simplify the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this specification.

[0047] All data involved in this application are information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0048] Before introducing the technical solutions described in this manual, the application scenarios and related technologies of the technical solutions will be introduced.

[0049] Industrial control refers to the technologies and methods used to monitor, regulate, and manage the operating status of equipment, processes, and systems during industrial production. Its core objective is to achieve safe, stable, efficient, and automated production operations. Modern industrial control systems are widely used in power, petrochemical, metallurgical, rail transportation, and intelligent manufacturing industries. A typical industrial control system usually includes the following key nodes 10: Measurement node 10, responsible for collecting on-site physical quantities (such as temperature, pressure, flow rate, position, etc.) and transmitting analog or digital signals to the upper-level system. Control node 10, such as a programmable logic controller (PLC), distributed control system, or industrial PC, is responsible for processing input data according to preset logic or algorithms and outputting control commands. Execution node 10 receives control commands and drives actuators such as valves, motors, and relays to complete specific operations. Nodes 10 are interconnected through industrial networks (such as Modbus, PROFINET, EtherCAT, OPC UA, etc.) to form a closed-loop control circuit. An industrial PC is a computer device specifically designed for industrial environments, featuring high reliability, anti-interference capabilities, wide-temperature operation, and long-term stable operation. In industrial control systems, it often plays the following roles: Host computer (HMI / SCADA server): provides human-machine interface and monitors the status of the entire production line; Edge computing node 10: runs advanced control algorithms, data analysis or AI inference; Protocol conversion gateway: connects subsystems with different communication protocols; Data acquisition and storage center: records historical parameters, alarm logs, operation records, etc.; Security control platform: deploys security functions such as access control, identity authentication, and encrypted communication.

[0050] Equipment parameters are the core objects of industrial control, mainly including: process parameters, such as temperature setpoints, pressure thresholds, and target speed values; configuration parameters, such as communication addresses, sampling periods, PID control coefficients, and alarm limits; and operating parameters, such as start / stop status, mode selection (automatic / manual), and fault reset flags. These parameters are typically controlled through: local configuration, set via the equipment panel, DIP switches, or local software; remote configuration, where an engineering workstation downloads the control logic and parameters using engineering software (such as TIAPortal or CODESYS); and online adjustment, where operators modify setpoints or operating modes in real time through the HMI interface.

[0051] With the widespread adoption of the Industrial Internet and open automation architectures, the traditional security model of "physical isolation + closed protocols" is no longer sufficient to cope with new network threats. Therefore, this specification provides a hierarchical authorization access control method for open automation nodes 10, applicable to control systems comprising at least two nodes 10, wherein the nodes 10 are measurement nodes 10, control nodes 10, or execution nodes 10. Please refer to the appendix. Figure 1 ,include:

[0052] Step 1: Generate and distribute the data access configuration detection table:

[0053] Based on the attributes of the sending node 10 that generated the data, the application AppID, and the data identifier ID1, a unique data receiving access group identifier ID2 is generated.

[0054] Please see the appendix Figure 2 The data is categorized into one of the following types based on its attributes: real-time monitoring and control, configuration, or alarm handling. Real-time monitoring and control and alarm handling data are associated with and configured with initial local checksums, while configuration data is associated with and configured with initial encryption keys.

[0055] Based on the unique receiving access group identifier ID2, data structure identifier ID3, data function code ID5, read / write permission ID6, and local verification code or encryption key, a data access configuration detection table is generated and distributed to all nodes 10 that need to receive the data.

[0056] Based on the physical address (e.g., MAC address), logical address (e.g., IP address), application AppID (for generating data), and data identifier ID1 of the sending node 10, these fields are concatenated into a byte string in byte order. Optionally, a fixed-length unique identifier, i.e., a unique receive access group identifier ID2, is generated using a hash algorithm (e.g., SHA-256 or SM3). The unique receive access group identifier ID2 ensures that each type of data is globally unique across the entire network, preventing confusion or unauthorized access caused by data with the same name generated by different devices or applications.

[0057] For example, a temperature monitoring application (AppID="TempMon_v2") runs on a PLC (IP: 192.168.10.22, MAC: 00:1A:2B:3C:4D:5E). This application periodically reports the real-time value of "Furnace Temperature Sensor 1" (data identifier ID1 = "T_Furnace_01"). These four fields are concatenated to generate ID2, ID2 = SHA256("00:1A:2B:3C:4D:5E"+"192.168.10.22"+"TempMon_v2"+ "T_Furnace_01"). For example, the unique identifier obtained is a3f8...c9d2.

[0058] All nodes 10 (such as HMI, edge analytics server) that subscribe to this furnace temperature data identify and obtain the real-time value of "furnace temperature sensor 1" through this unique access group identifier ID2.

[0059] Based on the business attributes of the data, it is divided into three categories, and corresponding security mechanisms are configured, as shown in the appendix. Figure 3 As shown.

[0060] Real-time monitoring and control type is characterized by high frequency and low latency requirements, allowing for a small amount of packet loss, such as sensor sampling values. Configuration type is characterized by critical configurations that must be transmitted completely and securely, such as control commands and system configuration commands. Alarm handling type requires ensuring that all nodes receive the information, such as in the event of an alarm.

[0061] Security credentials are configured for the three data types respectively. The real-time monitoring and control type and the alarm handling type use security credentials based on local checksums (used for integrity verification). The configuration type uses security credentials based on encryption keys (used for encryption and decryption).

[0062] Specifically, for the real-time monitoring and control example, the aforementioned "furnace temperature data" is a real-time monitoring and control data, sent every 10ms for closed-loop temperature control. A 128-bit local checksum (e.g., K_verify=0x7a3b...) is assigned to it; it is not encrypted, but HMAC(data + K_verify) is calculated as the checksum each time it is sent to prevent man-in-the-middle attacks that could lead to overheating. For the configuration-type example, the "PID control parameter update package" (e.g., proportional coefficient Kp=2.5) issued by the same PLC is a configuration-type data. An AES-256 encryption key (e.g., K_enc=0xf1e2...) is assigned to it. The data is encrypted before transmission and includes a hash value of the original plaintext. The receiver decrypts the data and compares the hash to ensure the parameters have not been tampered with. For the alarm handling example, when a gas leak is detected, the safety module broadcasts a "Level 1 Emergency Shutdown" command, which is an alarm handling type. Double verification is calculated using a local checksum: first, the data hash is calculated, then the HMAC (data + hash + checksum) is calculated, ensuring that even if the broadcast is intercepted, the shutdown command cannot be forged.

[0063] The data access configuration checklist includes: a unique receiving access group identifier ID2, a data structure identifier ID3 (describing the data format, such as "float32+uint16"), a communication protocol ID4 (such as Modbus / TCP, OPC UA PubSub), a function code ID5 (such as "read holding register" = 0x03), a read / write permission ID6 (such as "read only", "write but requires two-factor authentication"), and security credentials (verification code or encryption key).

[0064] The data access configuration detection table is generated uniformly by the configuration center and distributed to all nodes 10 (such as HMI, historical database, and security audit module) that need to receive or process the data through a secure channel (such as TLS encryption or offline USB import).

[0065] For example, the data access configuration detection table for "furnace temperature data" is shown in Table 1.

[0066] Table 1. Data Access Configuration Test Table for "Furnace Temperature Data"

[0067]

[0068] After receiving the data packet, each node 10 first uses the unique receiving access group identifier ID2 to look up the local configuration table, and then verifies it according to the credentials and rules recorded in the table to ensure that only data with "legal source, legal format and legal permissions" can be processed.

[0069] Step 2: Send data from node 10 by data type.

[0070] A data transmission sequence number is generated. Based on the data type and the pre-configured transmission strategy 21, the corresponding transmission strategy 21 is selected to package and transmit the data along with its transmission sequence number. The transmission strategy 21 records the communication method for transmitting the data, the security mechanism for verifying the data, and the packaged data payload. Each transmitted data is associated with a unique transmission sequence number, which exhibits a unique increasing trend. Therefore, it is possible to identify duplicate data transmissions and detect missed data transmissions.

[0071] The transmission process includes: (1) Selecting transmission strategy 21: Based on the specific type of data (real-time monitoring and control, configuration, or alarm handling), selecting the appropriate strategy from the preset transmission strategy 21 library. (2) Constructing the data payload: Based on the selected transmission strategy 21, combining the data payload, including necessary authentication information (such as ID2), raw data, and data used for verification (such as HMAC or HASH values). (3) Applying security measures: Performing necessary encryption processing on the data or generating verification values ​​to ensure the security and integrity of data transmission. (4) Executing data transmission: According to the selected communication method (publisher-subscriber mode, client-server mode, or global notification mode), sending the packaged data through the network.

[0072] The pre-configured sending strategy 21 also records the packet packaging method of IP packets, specifically including:

[0073] For real-time monitoring and control data, a lightweight packaging method is adopted, including: compressing data header fields, omitting redundant verification information, using UDP protocol encapsulation, and enabling timestamp marking;

[0074] For configuration data, a complete packaging method is adopted, including: adding sequence number, retransmission flag, forward error correction code, encapsulating with TCP or reliable UDP protocol, and embedding local check code and verification value in the data payload;

[0075] For alarm handling data, a multicast or broadcast compatible packaging method is adopted, including setting the destination address to a predetermined multicast address or broadcast address, and attaching a broadcast range identifier, lifecycle parameters and broadcast permission token when packaging.

[0076] The packaging method further includes: recording packaging metadata, which includes data type identifier, packaging time, source node 10 identity credentials and selected packaging rule version number, and encapsulates them as additional fields of the data payload into the IP packet.

[0077] In open automated networks, different business data have significantly different requirements for transmission efficiency, reliability, and security. Therefore, the system needs to predefine a refined IP packet packaging strategy for each type of data, determining not only the transmission protocol (UDP / TCP / multicast) but also standardizing the packet structure, metadata embedding, and security field layout. Packaging metadata, such as data type, timestamp, source identity, and rule version, is recorded as additional fields, enabling the receiving node 10 to quickly identify the data source, verify its legitimacy, and adapt the corresponding parsing logic.

[0078] Real-time measurement and control data: Lightweight packaging helps reduce latency. Applicable scenarios: High-frequency sensor sampling, motion control commands, real-time status feedback, etc.

[0079] Packaging characteristics: Compressed header: Unnecessary fields in the standard IP / UDP header (such as option fields) are omitted, or a custom simplified protocol header is used; Redundant checksums are omitted: TCP checksums and retransmission mechanisms are not used, relying on lightweight HMAC verification at the application layer; UDP encapsulation is used: Delays caused by TCP handshakes and congestion control are avoided; Timestamp marking is enabled: High-precision transmission time (such as PTP timestamp) is embedded in the payload for receiver synchronization or jitter analysis; Additional packet metadata: such as type=realtime,time=2025-11-10T14:30:00.123Z, src=PLC_01, rule_v=2.1.

[0080] For example, on a high-speed packaging production line, the servo drive receives a position reporting command (real-time measurement and control type) from the main control PLC every 5ms. The message structure is as follows: [ID2=a3f8...][Pos=125.6mm][HMAC=0x8e2c...][Meta:type=realtime, ts=1731234600123, src=PLC_MAC_00:1A:..., rule_v=2.1]. It uses UDP multicast transmission, with only necessary fields retained in the header, a total packet length of <64 bytes, and an end-to-end delay of <1ms, meeting the stringent timing requirements of motion control.

[0081] Configuration data: Packaged completely to ensure integrity and confidentiality. Applicable scenarios: Critical operations such as PLC program download, device parameter configuration, and user permission table updates.

[0082] Packaging features: Added sequence number: supports out-of-order detection and reordering; Retransmission flag: can trigger automatic retransmission when the receiver does not acknowledge; Forward error correction code (FEC): improves recovery capability in weak network environments; Use TCP or reliable UDP (such as QUIC, RUDP) encapsulation: ensures ordered and lossless delivery; Data encryption + HASH fingerprint: the payload is ciphertext, with an attached plaintext HASH for integrity verification; Embedded local checksum and verification value: used for key derivation or secondary authentication; Additional packet metadata: such as type=reliable, time=..., src=EngStation_05, rule_v=2.1.

[0083] For example, the engineer station sends new communication configuration parameters (configuration type) to the remote RTU (Remote Terminal Unit). The message structure is as follows: [ID2=b7d1...][Encrypted_Config={...}][Hash=SM3(...)][Meta:type=reliable, ts=1731234610000, src=ENG_PC_IP_192.168.5.10, rule_v=2.1].

[0084] Transmitting via TLS over TCP, the receiver first decrypts the data using its local key and then compares the hash. If packet loss occurs, the protocol stack automatically retransmits the data, ensuring that the configuration is delivered 100% accurately.

[0085] Alarm handling data: Packaged using broadcast / multicast compatibility to ensure full reachability. Applicable scenarios: emergency shutdown, fire alarm, plant-wide broadcast notification, etc.

[0086] Packaging characteristics: Destination address is set to multicast / broadcast address: such as 239.192.1.100 (private multicast) or 255.255.255.255; Additional broadcast range identifier: such as "this workshop" or "the entire factory area", used for intermediate node 10 to filter and forward; Lifetime parameter (TTL / Hop Limit): limits the broadcast propagation level to prevent storms; Broadcast permission token: only node 10 holding a valid token can process the broadcast (anti-forgery); Dual authentication mechanism: HMAC (data + HASH + checksum); Additional packet metadata: such as type=arrival, time=..., src=SafetyModule_A, rule_v=2.1.

[0087] For example, if a toxic gas leak is detected in a certain area of ​​a chemical plant, the safety module immediately broadcasts a "Level 1 Evacuation Command" (alarm handling type). The message structure is as follows: [ID2=c9e4...][Alert="Evacuate_Zone3"][Hash=SHA256(...)][HMAC=HMAC-SM3(Alert+Hash+K_verify)][Meta: type=arrival, ts=1731234620500, src=SAFETY_MAC_00:2B:..., rule_v=2.1, scope=PlantWide, ttl=5].

[0088] The message is sent via UDP broadcast. Once received, all online nodes 10 (including access control, loudspeakers, and handheld terminals) first verify the HMAC and authorization token, and then execute the linked actions (such as unlocking the escape door or playing a voice alarm).

[0089] On the other hand, another implementation also includes a dynamic HMAC algorithm adaptation strategy.

[0090] The dynamic HMAC algorithm adaptation strategy includes:

[0091] Based on the computing resources and configured data security level of node 10, select an appropriate HMAC algorithm from the predefined HMAC algorithm set and determine the checksum length;

[0092] The adapted HMAC algorithm and checksum length are stored in the secure storage space of node 10 and bound to the unique receive access group identifier ID2 of at least one data.

[0093] It also includes digital fingerprint extraction algorithm adaptation strategies.

[0094] The digital fingerprint extraction algorithm adaptation strategy includes:

[0095] Based on the computing resources and configured data security level of node 10, a suitable digital fingerprint extraction algorithm is selected from the predefined set of digital fingerprint extraction algorithms, and the length of the verification value is determined.

[0096] The adapted digital fingerprint extraction algorithm and the verification value length are stored in the secure storage space of node 10 and bound to the unique receiving access group identifier ID2 of at least one data.

[0097] The node 10 that receives the data stores the data access configuration detection table in its secure storage space.

[0098] The nodes 10 involved in the communication are of various types, including those with strictly limited resources, such as sensor nodes 10 with 8 / 16-bit MCUs (clock frequency <50 MHz, RAM <64 KB), those with limited resources, such as Cortex-M series embedded controllers (RAM128–512 KB), and those with sufficient resources, such as industrial PCs (IPCs) and edge servers (multi-core CPUs, GB-level memory).

[0099] If a strong cryptographic algorithm (such as HMAC-SHA256 or SM3) is forced to be used on all nodes 10, it will cause computational overload, response delay, or even task loss on low-end devices. Conversely, if a weak algorithm (such as CRC32) is used uniformly, it will not meet the protection requirements of high-security data (such as control commands and user credentials).

[0100] The data security level is determined by the hardware specifications (CPU architecture, clock speed, memory size) reported during device registration or by runtime load assessment; the data security level is set by the system administrator for each type of data during the configuration phase (e.g., L1=low sensitivity, L2=medium sensitivity, L3=high sensitivity).

[0101] The HMAC algorithm set is configured as shown in Table 2.

[0102] Table 2 HMAC Algorithm Set

[0103]

[0104] The selected HMAC algorithm identifier (e.g., alg_id=0x03 indicating HMAC-SM3) and checksum length (e.g., len=128) are written to the secure storage space of node 10 (e.g., HSM, TPM, or encrypted Flash partition). For example, a temperature sensor (Cortex-M0+, 64KB RAM) reports furnace temperature data (security level L2). The system assigns it HMAC-SM3 truncated to 128 bits. During transmission, it calculates: HMAC_SM3(key=K_verify, data=TempValue) → taking the first 16 bytes as the checksum. The receiver (e.g., HMI) verifies the data using the same algorithm based on its locally stored ID2 mapping table, ensuring the source is trustworthy and has not been tampered with.

[0105] Similar to HMAC, a hash algorithm is selected from a predefined set based on the resources and data security level of node 10. Recommended hash algorithms are shown in Table 3. SM3 conforms to the national cryptographic standard, BLAKE2s outperforms SHA2 on low-power devices, and SHA3 has stronger quantum resistance.

[0106] Table 3 Recommended HASH Algorithms

[0107]

[0108] The engineer station issues new control logic (security level L3, node 10 is a high-performance IPC) to the PLC. The system uses SHA3-256 to calculate the digital fingerprint of the original plaintext. After receiving the encrypted data, the PLC: decrypts it with the local key; calculates SHA3-256 on the plaintext; compares it with the fingerprint carried in the message; if they match, it loads and executes the code; otherwise, it discards the data and issues an alarm.

[0109] After receiving the data access configuration detection table issued by the configuration center, all receiving nodes 10 must store it in a protected secure storage space, including: physical isolation areas such as TrustZone security zone and HSM chip; logical encrypted storage: encrypted with the device's unique key and stored in ordinary Flash; access control: only authorized processes (such as secure communication agents) can read it, and the application layer is prohibited from directly accessing the original key or algorithm parameters.

[0110] Step 3: Receive node 10 to verify and process the data:

[0111] Receiver node 10 retrieves the corresponding data access configuration detection table based on the unique receive access group identifier ID2.

[0112] The data type is determined by reverse engineering the communication method, and pre-configured verification rules are obtained based on the data type. The data and its transmission sequence number are then verified according to the data access configuration detection table and the verification rules.

[0113] Once the verification is successful, the data is accepted and processed.

[0114] Upon receiving a data packet, receiving node 10 performs the following four steps: extracting the unique receive access group identifier ID2 (located in the packet payload header); quickly retrieving the locally stored "data access configuration detection table" using ID2; inferring the data type (configuration type / real-time monitoring and control type / alarm handling type) based on the communication method (unicast / multicast / broadcast); calling the verification rule matching the data type and combining it with the security parameters in the configuration table to complete integrity / confidentiality verification; only if the verification passes is the data handed over to the upper-layer application for processing; otherwise, it is discarded and a security log is recorded. This process is automatically completed in the receiving protocol stack or security proxy module and is transparent to the upper-layer control logic. The purpose of ID2 in the data access configuration detection table is to act as a "digital ID card" for the data, globally and uniquely binding the sending source (MAC+IP), application (AppID), and data semantics (ID1). The data type identifier can be explicitly carried in the packet (see packet metadata), but to enhance robustness, the system also supports inferring the type through underlying communication characteristics. Based on the inferred data type, the system activates the corresponding verification logic and uses the security mechanism parameters stored in the configuration table.

[0115] The verification process for real-time monitoring and control data (publisher-subscriber mode, multicast message) includes: Required parameters: local checksum (K_verify), HMAC algorithm identifier, output length; Verification steps: Extract from the message: [ID2, original data, received checksum]; Recalculate using local K_verify and pre-configured HMAC algorithm (e.g., HMAC-SM3): computed_hmac = HMAC(K_verify, original data); Truncate to a specified length (e.g., 128 bits) and compare with the received checksum; If they match, accept; otherwise, discard.

[0116] The verification process for configuration-type data (client-server mode, unicast message) includes: Required parameters: encryption key (K_enc), hash algorithm identifier, HMAC parameter (used for key derivation or secondary authentication); Verification steps: Extract: [ID2, ciphertext, plaintext HASH]; Decrypt the ciphertext using K_enc to obtain the plaintext; Calculate the digest of the plaintext using a pre-configured hash algorithm (such as SM3); Compare it with the HASH in the message; If they match, accept; otherwise, consider the data tampered with or the key mismatched.

[0117] The verification process for alarm handling data (global notification mode, broadcast message) includes: Required parameters: local checksum, HMAC algorithm, hash algorithm; Verification steps (double verification): Extract: [ID2, data, data HASH, received HMAC]; First verify data integrity: calculate local_hash = Hash(data) and compare it with the received HASH; Second verify source authenticity: calculate local_hmac = HMAC(K_verify, data + local_hash) and compare it with the received HMAC; Only when both pass is it considered a legitimate broadcast.

[0118] Verification of the transmission sequence number mainly involves checking whether the transmission sequence numbers are consecutive and whether there are any duplicates. Duplicate transmission sequence numbers indicate that the data is being retransmitted, while non-consecutive transmission sequence numbers indicate that data was missed in the middle.

[0119] Step 4: Dynamically update the local verification code and encryption key:

[0120] For data in the publish-subscriber mode and global notification mode, the current local checksum is used as the seed to generate a random number as the new local checksum. The local checksum update instruction is sent via multicast or broadcast. The receiving node 10 independently uses the current local checksum as the seed and generates a random number according to the same random number generation algorithm. If the random number is consistent with the new local checksum, the local checksum is updated and the update status is sent back.

[0121] For data in client-server communication mode, the current encryption key is used as the seed to generate a random number as the new encryption key. The digital fingerprint of the new encryption key is obtained, and the data is encrypted with the current encryption key and its digital fingerprint and then sent via unicast. The receiving node 10 decrypts the data and verifies the digital fingerprint. After that, the encryption key is updated and the updated status is sent back.

[0122] In open industrial networks, if the verification code or encryption key remains unchanged for a long period, it will face risks such as replay attacks, key leakage, and brute-force attacks. However, frequent manual key changes will interrupt services and increase the maintenance burden. This specification provides a scheme for dynamically updating local verification codes and encryption keys. The dynamic updating of local verification codes and encryption keys also includes triggering the update timing. The methods for triggering the update timing include: for real-time monitoring and control data, using time-based or event-based update timing; for configuration data, using time-based or session change-based update timing; and for alarm handling data, using static or preset periodic update timing.

[0123] Different types of data have different requirements for key freshness, so a differentiated triggering mechanism is adopted. For example, the triggering mechanism is shown in Table 4.

[0124] Table 4 Update Trigger Mechanism

[0125]

[0126] On the other hand, all nodes 10 use the same DRBG algorithm (such as the NIST SP 800-90A standard) to ensure seed-to-output reproducibility without transmitting plaintext keys. The sender only switches credentials after receiving confirmation from the receiver, preventing communication failures due to "some nodes 10 not being updated". Node 10 can retain the previous generation key for a short period (e.g., 5 minutes) to process old data sent during the update process and avoid packet loss. Each update records the time, trigger reason, and a list of participating nodes 10 for security auditing purposes.

[0127] On the other hand, this specification provides an open automated node 10 hierarchical authorization access control system; please refer to the appendix. Figure 4 ,include:

[0128] Configuration module 100 generates and distributes the data access configuration detection table:

[0129] Based on the attributes of the sending node 10 that generated the data, the application AppID, and the data identifier ID1, a unique data receiving access group identifier ID2 is generated.

[0130] The data is categorized into one of the following types based on its attributes: real-time monitoring and control, configuration, or alarm handling. Real-time monitoring and control and alarm handling data are associated with and configured with initial local checksums. Configuration data is associated with and configured with initial encryption keys.

[0131] Based on the unique receiving access group identifier ID2, data structure identifier ID3, data function code ID5, read / write permission ID6, local verification code or encryption key, a data access configuration detection table is generated and distributed to all nodes 10 that need to receive the data.

[0132] Sending module 200 and sending node 10 package and send data according to data type:

[0133] Generate a data transmission sequence number, select the corresponding transmission strategy 21 according to the data type and the pre-configured transmission strategy 21, package the data and its transmission sequence number and send them. The transmission strategy 21 records the communication method for sending data, the security mechanism for verifying data and the packaged data payload.

[0134] Receiver module 300, receiver node 10 verifies and processes the data:

[0135] Receiver node 10 retrieves the corresponding data access configuration detection table based on the unique receive access group identifier ID2.

[0136] The data type is determined by reverse engineering the communication method, and pre-configured verification rules are obtained based on the data type. The data and its transmission sequence number are then verified according to the data access configuration detection table and the verification rules.

[0137] Once the verification is successful, the data will be accepted and processed.

[0138] Update module 400 to dynamically update the local verification code and encryption key:

[0139] For data in the publish-subscriber mode and global notification mode, the current local checksum is used as the seed to generate a random number as the new local checksum. The local checksum update instruction is sent via multicast or broadcast. The receiving node 10 independently uses the current local checksum as the seed and generates a random number according to the same random number generation algorithm. If the random number is consistent with the new local checksum, the local checksum is updated and the update status is sent back.

[0140] For data in client-server communication mode, the current encryption key is used as the seed to generate a random number as the new encryption key. The digital fingerprint of the new encryption key is obtained, and the data is encrypted with the current encryption key and its digital fingerprint and then sent via unicast. The receiving node 10 decrypts the data and verifies the digital fingerprint. After that, the encryption key is updated and the updated status is sent back.

[0141] Please see Figure 5 The diagram shown is a structural schematic of an electronic device provided in an embodiment of this specification.

[0142] like Figure 5As shown, the electronic device 1100 may include: at least one processor 1101, at least one network interface 1104, a user interface 1103, a memory 1105, and at least one communication bus 1102. The communication bus 1102 can be used to connect and communicate with the various components mentioned above. The user interface 1103 may include buttons, and optionally may include standard wired or wireless interfaces. The network interface 1104 may include, but is not limited to, a Bluetooth module, an NFC module, or a Wi-Fi module. The processor 1101 may include one or more processing cores. The processor 1101 connects to various parts within the electronic device 1100 using various interfaces and lines, and performs various functions of the routing device and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 1105, and by calling data stored in the memory 1105. Optionally, the processor 1101 may be implemented using at least one hardware form of DSP, FPGA, or PLA. The processor 1101 may integrate one or more combinations of CPU, GPU, and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content that the display screen needs to show; and the modem is used for wireless communication.

[0143] It is understandable that the aforementioned modem may not be integrated into the processor 1101, but may be implemented using a separate chip.

[0144] The memory 1105 may include RAM or ROM. Optionally, the memory 1105 may include a non-transitory computer-readable medium. The memory 1105 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 1105 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 1105 may also be at least one storage device located remotely from the aforementioned processor 1101. As a computer storage medium, the memory 1105 may include an operating system, a network communication module, a user interface module, and application programs. The processor 1101 may be used to call the application programs stored in the memory 1105 and execute the methods in the above-described embodiments.

[0145] This specification also provides a computer-readable storage medium storing instructions that, when executed on a computer or processor, cause the computer or processor to perform multiple steps as described in the above embodiments. If the constituent modules of the above-described electronic device are implemented as software functional units and sold or used as independent products, they can be stored in the computer-readable storage medium.

[0146] This specification also provides a computer program product, including a computer program that, when executed by a processor, implements the multiple steps described in the above embodiments.

[0147] Where there is no conflict, the technical features in this embodiment and implementation scheme can be combined arbitrarily.

[0148] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes multiple computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center integrating multiple available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital versatile discs (DVDs)), or semiconductor media (e.g., solid-state drives (SSDs)).

[0149] When implemented through hardware or firmware, the aforementioned method flow is programmed into the hardware circuit to obtain the corresponding hardware circuit structure and achieve the corresponding function. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit, whose logic function is determined by the user programming the device. Designers can program a digital system onto a PLD themselves, eliminating the need for chip manufacturers to design and fabricate dedicated integrated circuit chips. Furthermore, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly implemented using "logic compiler" software, similar to the software compiler used in program development. The original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There is not just one HDL, but many. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of the aforementioned hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logic method flow can be easily obtained.

[0150] The embodiments described above are merely preferred embodiments of this specification and are not intended to limit the scope of this specification. Any modifications and improvements made by those skilled in the art to the technical solutions of this specification without departing from the spirit of this specification should fall within the protection scope defined by the claims of this specification.

Claims

1. An open automation node hierarchical authorization access control method applied to a control system comprising at least two nodes, the nodes being measurement nodes, control nodes or execution nodes, characterized in that, Comprise: Step one, generate and issue data access configuration detection table: According to the sending node attribute of the generated data, AppID and data identification ID1, generate the unique receiving access group identification ID2 of the data, Classify the data according to the attribute into one of the real-time measurement and control type, configuration type or alarm disposal type, associate and configure the initial local check code for the real-time measurement and control type and alarm disposal type data, and associate and configure the initial encryption key for the configuration type data, According to the unique receiving access group identification ID2, data structure identification ID3, data function code ID5, read-write permission ID6, local check code or encryption key, generate the data access configuration detection table of the data, and issue it to all nodes that need to receive the data; Step two, the sending node packs and sends data according to the data type: Generate the sending sequence number of the data, select the corresponding sending strategy according to the data type and the preconfigured sending strategy, pack and send the data and its sending sequence number, and the sending strategy records the communication mode of sending data, the security mechanism of verifying data and the data payload of packing; Step three, the receiving node verifies and processes the data: The receiving node looks up the corresponding data access configuration detection table according to the unique receiving access group identification ID2, According to the communication mode, the data type is obtained by reverse reasoning, the preconfigured verification rule is obtained according to the data type, and the data and its sending sequence number are verified according to the data access configuration detection table and the verification rule, After verification, accept and process the data.

2. The hierarchical authorization access control method of open automation nodes according to claim 1, wherein the preconfigured sending strategy comprises: For real-time measurement and control type data, configure the communication mode as publisher-subscriber mode, the sender adopts multicast mode, the security mechanism is to set the verification check value = HMAC (data + local check code), and the data payload is [unique receiving access group identification ID2, data, sending sequence number, verification check value]; For configuration type data, configure the communication mode as client-server mode, the sender adopts unicast mode, the security mechanism is to use encryption key to encrypt the transmitted data and the digital fingerprint of the data, and the data payload is [unique receiving access group identification ID2, data, sending sequence number, digital fingerprint]; For alarm disposal type data, configure the communication mode as global notification mode, the sender adopts broadcast mode, the security mechanism is to set the verification check value = HMAC (data + digital fingerprint of data + local check code), and the data payload is [unique receiving access group identification ID2, data, sending sequence number, digital fingerprint of data, verification check value].

3. The hierarchical authorization access control method of open automation nodes according to claim 2, wherein the preconfigured sending strategy further records the packing mode of IP packet, specifically comprising: For real-time measurement and control type data, adopt a lightweight packing mode, including: compressing the data header field, omitting redundant check information, using UDP protocol encapsulation, and enabling timestamp marking; ​ ​ For configuration data, the complete packaging method is adopted, including adding sequence number, retransmission identifier, forward error correction code, encapsulating by TCP or reliable UDP protocol, and embedding local check code and verification check value in data payload; For alarm handling data, the multicast or broadcast compatible packaging method is adopted, including setting the destination address as a predetermined multicast address or broadcast address, and adding broadcast range identifier, life cycle parameter and broadcast permission token during packaging.

4. The hierarchical authorization access control method of an open automation node according to claim 3, characterized in that, the packaging method further comprises recording packaging element information, including data type identifier, packaging time, source node identity certificate and selected packaging rule version number, as an additional field of the data payload, and encapsulating into an IP packet.

5. The hierarchical authorization access control method of an open automation node according to claim 2, characterized in that, it further comprises: Step 4, dynamically updating the local check code and the encryption key: For data in the publisher-subscriber mode and the global notification mode, a random number is generated as a new local check code using the current local check code as a seed, and a local check code update instruction is sent through multicast or broadcast. The receiving node independently generates a random number using the same random number generation algorithm as the seed of the current local check code, and verifies that the new local check code is consistent with the random number. If the verification is passed, the local check code is updated and the update status is returned; For data in the client-server mode, a random number is generated as a new encryption key using the current encryption key as a seed, and a digital fingerprint of the new encryption key is obtained. The current encryption key and its digital fingerprint are encrypted and sent through unicast. After decryption and verification of the digital fingerprint, the receiving node updates the encryption key and returns the update status.

6. The hierarchical authorization access control method of an open automation node according to claim 5, characterized in that, the dynamic updating of the local check code and the encryption key further comprises a trigger of the update timing, the method of triggering the update timing comprises: For real-time measurement and control data, the update timing is triggered based on time or events; For configuration data, the update timing is triggered based on time or based on session changes; For alarm handling data, the update timing is triggered statically or at a preset period.

7. The hierarchical authorization access control method of an open automation node according to claim 2, characterized in that, it further comprises a dynamic HMAC algorithm adaptation strategy, the dynamic HMAC algorithm adaptation strategy comprises: According to the computing resources of the node and the configured data security level, an adaptive HMAC algorithm is selected from a predefined set of HMAC algorithms and the check value length is determined; The adaptive HMAC algorithm and the check value length are stored in the security storage space of the node and are bound to at least one unique receiving access group identifier ID2 of the data.

8. The hierarchical authorization access control method of an open automation node according to claim 2, characterized in that, it further comprises a digital fingerprint extraction algorithm adaptation strategy, the digital fingerprint extraction algorithm adaptation strategy comprises: According to the computing resources of the node and the configured data security level, an adaptive digital fingerprint extraction algorithm is selected from a pre-defined set of digital fingerprint extraction algorithms and a check value length is determined; The adaptive digital fingerprint extraction algorithm and the check value length are stored in a secure storage space of the node and are bound to at least one unique receiving access group identifier ID2 of the data.

9. The hierarchical authorization access control method of an open automation node according to claim 1, characterized in that, The node receiving the data stores the data access configuration detection table in a secure storage space thereof.

10. An open automation node hierarchical authorization access control system, characterized in that, Comprise: The configuration module generates and issues a data access configuration detection table: According to the sending node attribute, application program AppID and data identifier ID1 of the generated data, a unique receiving access group identifier ID2 of the data is generated, The data is classified into one of the data types of real-time measurement and control type, configuration type or alarm handling type according to the attribute, the initial local check code is associated and configured for the data of real-time measurement and control type and alarm handling type, and the initial encryption key is associated and configured for the configuration type data, According to the unique receiving access group identifier ID2, data structure identifier ID3, function code ID5 of the data, read-write permission ID6, local check code or encryption key, a data access configuration detection table of the data is generated and issued to all nodes that need to receive the data; The sending module, the sending node packs and sends data according to the data type: A sending sequence number of the data is generated, according to the data type and the pre-configured sending strategy, the corresponding sending strategy is selected to pack and send the data and its sending sequence number, and the sending strategy records the communication mode of sending data, the security mechanism of verifying data and the data payload of packing; The receiving module, the receiving node verifies and processes data: The receiving node looks up and obtains the corresponding data access configuration detection table according to the unique receiving access group identifier ID2, According to the communication mode, the data type is obtained by reverse deduction, the pre-configured verification rule is obtained according to the data type, the data and its sending sequence number are verified according to the data access configuration detection table and the verification rule, After verification, the data is accepted and processed.

11. An electronic device, comprising: Comprise a processor and a memory; The processor is connected with the memory; The memory is used for storing executable program code; The processor runs the program corresponding to the executable program code by reading the executable program code stored in the memory, so as to execute the method of any one of claims 1-9.

12. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to realize the method of any one of claims 1-9.

13. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to realize the method of any one of claims 1-9.

Images