Industrial data transmission method, device, medium and product

Abstract

Embodiments of the present application provide an industrial data transmission method, device, medium and product. The method comprises: performing type identification and importance evaluation on an original industrial data stream, dividing data levels and attaching labels; calling a differentiated encryption strategy according to the labels; adding a meta information field to the data packet header; performing identity authentication, dynamic authorization and access token management based on the LAAS-IoT permission management architecture; implementing three-level key generation, distribution and update; encapsulating and transmitting according to the target industrial protocol; continuously recording security logs and verifying data integrity at the receiving end. The method is used to achieve the effect of ensuring the safety of core industrial data while solving the problems of real-time degradation caused by full-strength encryption, static permissions being difficult to adapt to dynamic business scenarios, and keys lacking hierarchical isolation, and maintaining the low-latency response capability of the control system to the maximum extent.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to an industrial data transmission method, device, medium and product. Background Technology

[0002] As a core infrastructure for smart manufacturing, the Industrial Internet of Things (IIoT) enables deep interconnection between field devices, control systems, and cloud platforms. In distributed industrial networks, sensors, controllers, and actuators continuously generate massive data streams. These data carry critical information such as equipment status, process parameters, and control commands, and their transmission security is directly related to the stable operation of the production system.

[0003] Current industrial data transmission solutions primarily employ unified encryption strategies and static access control mechanisms. At the encryption level, existing solutions typically apply the same level of encryption to all data; at the access control level, they mostly use role-based access control or static access control lists for authentication, with the server responsible for all authentication and permission determination.

[0004] However, industrial sites have strict requirements for real-time performance, and uniform high-strength encryption will significantly increase computational overhead and transmission latency, seriously affecting the real-time performance of industrial closed-loop control; at the same time, static permission management mechanisms are difficult to adapt to the dynamically changing business scenarios in industrial sites. Summary of the Invention

[0005] This application provides an industrial data transmission method, device, storage medium, and product that ensures industrial data security while also considering system real-time performance and management flexibility. It solves the problems of real-time degradation caused by full-volume high-strength encryption and the difficulty of adapting static permissions to dynamic business scenarios in the prior art.

[0006] In a first aspect, embodiments of this application provide an industrial data transmission method, which is deployed in a distributed network environment consisting of industrial edge nodes, local control servers, and a cloud-based collaborative platform, and includes:

[0007] Acquire raw industrial data streams, which include multiple industrial data streams;

[0008] Each industrial data is identified by its data type, and the data type identification results, the target address corresponding to each industrial data, and the target industrial protocol are determined.

[0009] Based on the data type identification results, the security level corresponding to each industrial data is determined, resulting in multiple data packets carrying security level labels;

[0010] For each data packet, the encryption algorithm corresponding to the security level is invoked to encrypt it, resulting in an encrypted data packet;

[0011] Encapsulate each encrypted data packet according to the target industrial protocol format to obtain the industrial data stream to be transmitted;

[0012] The industrial data stream to be transmitted is transmitted to the target resource server corresponding to the target address.

[0013] In one possible implementation, based on the data type identification result, the security level corresponding to each industrial data is determined, resulting in multiple data packets carrying security level tags, including:

[0014] The industrial data and the corresponding data type identification results are sequentially input into the weighted decision tree model to obtain the importance score of each industrial data.

[0015] Based on importance scores and preset thresholds, industrial data is divided into at least three security levels;

[0016] Add corresponding security level labels to each industrial data, resulting in multiple data packets carrying security level labels.

[0017] In one possible implementation, for each data packet, an encryption algorithm corresponding to the security level is invoked for encryption processing to obtain an encrypted data packet, including:

[0018] When the security level label indicates that the data packet is Level 1 data, the first preset encryption algorithm is invoked to perform full-field encryption on the data packet based on the Level 1 key, resulting in an encrypted data packet.

[0019] When the security level label indicates that the data packet is level 2 data, the second preset encryption algorithm is invoked to perform full-field encryption on the data packet based on the level 2 key, resulting in an encrypted data packet.

[0020] When the security level label indicates that the data packet is level 3 data, the third preset encryption algorithm is invoked, and triple DES enhanced mode encryption is performed based on the level 3 key to obtain the encrypted data packet;

[0021] The level 2 key is generated from the level 1 key using a key derivation function, and the level 3 key is generated from the level 2 key using a key derivation function.

[0022] In one possible implementation, before invoking a first preset encryption algorithm to perform full-field encryption on the data packet based on the primary key, the method further includes:

[0023] Determine whether the lightweight encrypted path triggering conditions are met;

[0024] When the conditions are met, lightweight encryption is performed on the key fields in the data packet based on the first-level key to obtain the encrypted data packet;

[0025] If the conditions are not met, full-field encryption is performed on the data packet based on the primary key to obtain an encrypted data packet.

[0026] In one possible implementation, for each data packet, an encryption algorithm corresponding to the security level is invoked for encryption processing. After obtaining the encrypted data packet, the method further includes:

[0027] Add data level information and random encryption information to the header of the encrypted data packet; the data level information is used to identify the data level, and the random encryption information is used to identify whether the encrypted data packet was obtained using lightweight encryption.

[0028] Calculate the hash value of the industrial data corresponding to the encrypted data packet;

[0029] The hash value is appended to the end of the encrypted data packet; the hash value is used by the target device for integrity verification.

[0030] Secondly, embodiments of this application provide an industrial data transmission method, including:

[0031] The system receives data requests from clients, which carry access tokens and target device identifiers. The access token is generated by the local control server and synchronized to the resource server when the verification conditions are met. The verification conditions include: the legitimacy of the local control server's identity is verified by the global root server, the legitimacy of the client's user identity is verified by the local control server, and the legitimacy of the permission request content of the data request is determined by the permission policy library.

[0032] Verify the access token;

[0033] After successful verification, in response to the data request, industrial data corresponding to the target device identifier is returned to the client.

[0034] In one possible implementation, the validity of the access token signature is verified to confirm that the issuer is a legitimate local control server.

[0035] Check if the timestamp of the access token is within a valid window;

[0036] Verify that the target device identifier in the access token matches the device identifier of the resource server;

[0037] Parse the permission description in the access token to determine whether the requested data security level and operation type are within the authorized scope.

[0038] Thirdly, embodiments of this application provide an industrial data transmission device, the device comprising:

[0039] The acquisition module is used to acquire raw industrial data streams, which include multiple industrial data.

[0040] The identification module is used to identify the data types of each industrial data, determine the data type identification results, the target address and target industrial protocol corresponding to each industrial data;

[0041] The determination module is used to determine the security level corresponding to each industrial data based on the data type identification result, and obtain multiple data packets carrying security level labels;

[0042] The encryption module is used to encrypt each data packet by calling the encryption algorithm corresponding to the security level, thereby obtaining an encrypted data packet.

[0043] The encapsulation module is used to encapsulate each encrypted data packet according to the target industrial protocol format to obtain the industrial data stream to be transmitted.

[0044] The transmission module transmits the industrial data stream to be transmitted to the target device corresponding to the target address.

[0045] In one possible implementation, the determining module is specifically used for:

[0046] The industrial data and the corresponding data type identification results are sequentially input into the weighted decision tree model to obtain the importance score of each industrial data.

[0047] Based on importance scores and preset thresholds, industrial data is divided into at least three security levels;

[0048] Add corresponding security level labels to each industrial data, resulting in multiple data packets carrying security level labels.

[0049] In one possible implementation, the encryption module is specifically used for:

[0050] When the security level label indicates that the data packet is Level 1 data, the first preset encryption algorithm is invoked to perform full-field encryption on the data packet based on the Level 1 key, resulting in an encrypted data packet.

[0051] When the security level label indicates that the data packet is level 2 data, the second preset encryption algorithm is invoked to perform full-field encryption on the data packet based on the level 2 key, resulting in an encrypted data packet.

[0052] When the security level label indicates that the data packet is level 3 data, the third preset encryption algorithm is invoked, and triple DES enhanced mode encryption is performed based on the level 3 key to obtain the encrypted data packet;

[0053] The level 2 key is generated from the level 1 key using a key derivation function, and the level 3 key is generated from the level 2 key using a key derivation function.

[0054] In one possible implementation, the encryption module is also used for:

[0055] Determine whether the lightweight encrypted path triggering conditions are met;

[0056] When the conditions are met, lightweight encryption is performed on the key fields in the data packet based on the first-level key to obtain the encrypted data packet;

[0057] If the conditions are not met, full-field encryption is performed on the data packet based on the primary key to obtain an encrypted data packet.

[0058] In one possible implementation, the encapsulation module is also used for:

[0059] Add data level information and random encryption information to the header of the encrypted data packet; the data level information is used to identify the data level, and the random encryption information is used to identify whether the encrypted data packet was obtained using lightweight encryption.

[0060] Calculate the hash value of the industrial data corresponding to the encrypted data packet;

[0061] The hash value is appended to the end of the encrypted data packet; the hash value is used by the target device for integrity verification.

[0062] Fourthly, embodiments of this application provide an industrial data transmission device, comprising:

[0063] The receiving module is used to receive data requests from clients. The data requests carry an access token and a target device identifier. The access token is generated by the local control server and synchronized to the resource server when the verification conditions are met. The verification conditions include: the identity of the local control server is verified by the global root server, the identity of the client user is verified by the local control server, and the legality of the permission request content of the data request is determined by the permission policy library.

[0064] The verification module is used to verify the access token;

[0065] The response module is used to respond to data requests after successful verification and return industrial data corresponding to the target device identifier to the client.

[0066] In one feasible implementation, the verification module can specifically be used for:

[0067] Verify the validity of the access token signature and confirm that the issuer is a legitimate local control server;

[0068] Check if the timestamp of the access token is within a valid window;

[0069] Verify that the target device identifier in the access token matches the device identifier of the resource server;

[0070] Parse the permission description in the access token to determine whether the requested data security level and operation type are within the authorized scope.

[0071] The industrial data transmission device provided in this embodiment can be used to execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0072] Fifthly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0073] The memory stores the instructions that the computer executes;

[0074] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above, or to perform the second aspect and / or various possible implementations of the second aspect as described above.

[0075] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect, or to implement the second aspect and / or various possible implementations of the second aspect.

[0076] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect, or implements the second aspect and / or various possible implementations of the second aspect.

[0077] The industrial data transmission method, electronic device, storage medium, and program product provided in this application identify the type and assess the importance of each piece of industrial data in the acquired raw industrial data stream, classify different industrial data into corresponding security levels and attach security level labels, then call the matching differentiated encryption algorithm for encryption processing according to the security level labels, and finally encapsulate and transmit the data to the corresponding target resource server according to the target industrial protocol format. This enables the dynamic allocation of encryption resources based on the actual importance of the data, avoiding the waste of computing power and transmission delay caused by using uniform high-strength encryption for all data. It achieves the effect of effectively reducing system computing overhead and end-to-end transmission latency while ensuring the security of core industrial data, and improving the real-time performance and overall efficiency of industrial data transmission. Attached Figure Description

[0078] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0079] Figure 1 A schematic diagram of the overall system architecture of an industrial data transmission method provided in this application;

[0080] Figure 2 Flowchart of the industrial data transmission method provided in this application Figure 1 ;

[0081] Figure 3 Flowchart of the industrial data transmission method provided in this application Figure 2 ;

[0082] Figure 4 Schematic diagram of the industrial data transmission device provided in this application Figure 1 ;

[0083] Figure 5 Schematic diagram of the industrial data transmission device provided in this application Figure 2 ;

[0084] Figure 6 A schematic diagram of the structure of the electronic device provided in this application.

[0085] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0086] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0087] First, let me explain the terms used in this application:

[0088] Data classification refers to a processing mechanism that identifies the type and assesses the importance of raw industrial data streams based on a pre-defined business impact model, divides the data into Level 1 (core data), Level 2 (ordinary data), and Level 3 (redundant data), and attaches structured tags to the header of the data packets.

[0089] LAAS-IoT Access Control: This refers to a two-layer trust architecture consisting of a Global Root Server (GRS) and a Local Control Server (LCS). Based on the Attribute-Based Access Control (ABAC) model, it dynamically evaluates user identity, resource attributes, and environmental context to generate and issue access tokens (AccTokens) with valid time windows, thus realizing a management mechanism for on-demand allocation and real-time changes of permissions.

[0090] Bernoulli random encryption refers to a randomized encryption mechanism that, when performing full-field encryption with Advanced Encryption Standard (AES)-256 on Level 1 data, triggers a lightweight encryption path with a probability parameter α. This process is only applied to the critical opcode and target address fields, while the remaining fields are transmitted in plaintext. Furthermore, α is dynamically adjusted by the security situation awareness unit based on the network security risk score.

[0091] Three-level key management refers to a hierarchical key system in which the first-level key is generated by GRS within the Hardware Security Module (HSM) and distributed through a secure channel, the second-level key is generated by LCS based on the first-level key through a Key Derivation Function (KDF), and the third-level key is derived locally by each resource server based on the second-level key. Each level of key has an independent lifecycle and an isolated storage area.

[0092] In modern industrial systems such as smart manufacturing, smart energy, or smart warehousing, existing technologies employ high-complexity algorithms such as AES-256 for full-scale, high-strength encryption of all transmitted data and implement static permission management based on role-based access control or access control list models. However, these technologies suffer from several problems: excessive computational overhead leading to degraded system real-time performance; rigid permission configurations that are difficult to adapt to dynamic business scenarios; and a lack of hierarchical isolation for shared keys across different security levels.

[0093] Figure 1 This is a schematic diagram of the overall system architecture of the industrial data transmission method provided in this application. Figure 1As shown, the industrial data transmission method provided in this application can be deployed in a distributed network environment consisting of an industrial edge node, a local control server (LCS), and a cloud-based collaborative platform (GRS). The industrial edge node is interconnected with the local control server (LCS) and the resource server (RS) via fieldbus or industrial Ethernet; the LCS is deployed within the factory's local area network, isolated from the Internet by a firewall, and establishes a secure channel with the global root server (GRS) in the cloud-based collaborative platform; the terminal requests industrial data from the resource server through an access token, forming a secure communication system with a three-tiered defense depth from the end to the edge to the cloud.

[0094] Industrial edge nodes can be devices deployed in the factory workshop, such as welding robots, sensors, and PLCs (Programmable Logic Controllers). Terminals can be engineer PCs or applications (APPs) set on the terminal devices.

[0095] In this embodiment, the industrial edge node is configured at the data source exit and has a built-in industrial data type recognition engine. This engine, based on a pre-trained rule base and a lightweight syntax parser, automatically identifies and parses at least ten mainstream industrial data formats, including but not limited to equipment start / stop commands, process parameter adjustment commands, safety alarm signals, temperature sensor readings, humidity monitoring values, pressure feedback data, equipment operation logs, historical statistical records, equipment status snapshots, and fault diagnostic codes. The recognition process first parses the protocol header of the data packets, extracting the source address, destination address, function code, and data length fields; then, it matches the data to a predefined data semantic category based on the function code mapping table; finally, it combines contextual information (such as the current operating mode of the equipment and historical operation sequences) to complete accurate classification.

[0096] Specifically, industrial edge nodes are used to acquire raw industrial data streams, identify the type and assess the importance of the industrial data to determine the security level, call the encryption algorithm corresponding to the security level for differentiated encryption processing, encapsulate the data according to the target industrial protocol format, and transmit it to the target resource server (RS). Based on a pre-defined business impact model, industrial edge nodes categorize input data into three levels: Level 1 (core data), Level 2 (ordinary data), and Level 3 (redundant data). According to the level label, corresponding encryption algorithms are invoked for differentiated processing. Level 1 data uses AES-256 in Cipher Block Chaining (CBC) mode for full-field encryption or a lightweight path triggering Bernoulli random encryption. Level 2 data uses AES-128 in Electronic Codebook (ECB) mode for full-field encryption. Level 3 data uses Triple Data Encryption Standard (DES) enhanced mode for basic encryption. After encryption, a two-byte metadata field is appended to the header of the data packet, and a SHA-256 hash value calculated based on the original plaintext is appended to the end of the data packet. Finally, the encrypted data is encapsulated and forwarded according to the target industrial protocol format.

[0097] The Local Control Server (LCS) and Global Root Server (GRS) are used to build a two-layer trust architecture for LAAS-IoT, enabling authentication, dynamic authorization, and hierarchical key management. The Global Root Server (GRS), acting as the global trust anchor, stores the digital certificates of all legitimate Local Control Servers (LCS), verifies the legitimacy of the LCS's identity, and generates a Level 1 key within the Hardware Security Module (HSM) conforming to the FIPS 140-2 Level 3 standard. This key is then synchronized to the Local Control Server (LCS) and the Core Resource Server (RS) via a secure channel. The Local Control Server (LCS) is deployed on the factory's local network and undertakes the core functions of user authentication, permission policy enforcement, and access token (AccToken) generation. After verifying the client user's identity, it determines the legitimacy of the request based on the pre-configured permission policy library, generates an access token (AccToken) containing the permission scope, validity period window, digital signature, and key index, and synchronously distributes it to the client application and resource servers (RS). At the same time, it generates a secondary key based on the primary key through a Key Derivation Function (KDF) and synchronizes it to the ordinary resource servers (RS). Permission change operations are triggered in real time by the Local Control Server (LCS), and the new token and key are synchronized across the entire network within ten seconds. The validity period of temporary permissions can be configured to any integer value between one minute and seven days, and it will automatically expire after the expiration. In case of emergency, a specified access token (AccToken) can be remotely forcibly revoked, and the revocation command takes effect within five seconds.

[0098] The industrial data transmission method provided in this application solves the technical problems of existing technologies, such as difficulty in balancing security and real-time performance, insufficient adaptability of static permissions, and lack of hierarchical isolation in key management, by performing semantic awareness and importance assessment on the original industrial data stream and implementing differentiated encryption strategies, constructing a LAAS-IoT two-layer permission architecture to realize dynamic token authorization and fine-grained access control, and implementing strictly isolated three-level key lifecycle management.

[0099] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0100] Figure 2 Flowchart of the industrial data transmission method provided in this application Figure 1 ,like Figure 2 As shown, the method provided in this embodiment can be specifically derived from... Figure 1 The industrial edge node shown executes the method, specifically, which includes:

[0101] S201. Obtain the raw industrial data stream, which includes multiple industrial data.

[0102] Raw industrial data refers to the collection of data generated in real time or collected periodically by various industrial equipment deployed in factory workshops, used to reflect the production operation status or control equipment actions. Raw industrial data can be obtained through various means, such as sensors (e.g., temperature, pressure, humidity sensors) collecting environmental or process parameters, PLCs reading equipment operating status or executing control logic, actuators (e.g., welding robots, CNC machine tools) reporting position commands or feedback data, and industrial gateways aggregating data from various fieldbuses or industrial Ethernet networks for unified output.

[0103] S202. Identify the data types of each industrial data, and determine the data type identification results, the target address and target industrial protocol corresponding to each industrial data.

[0104] Data type refers to the classification and identification of industrial data at the business semantic level, reflecting the functional positioning and safety sensitivity of the data in the production control system. Based on different data types, industrial data can be divided into equipment start / stop commands, process parameter adjustment commands, safety alarm signals, temperature sensor readings, humidity monitoring values, pressure feedback data, equipment operation logs, historical statistical records, equipment status snapshots, and fault diagnostic codes, etc. For example, equipment start / stop commands belong to control data that directly affects equipment operation, temperature sensor readings belong to monitoring data that reflects environmental conditions, and equipment operation logs belong to audit data used for post-event analysis.

[0105] In this embodiment, the industrial edge node has a built-in industrial data type recognition engine. This engine automatically identifies and parses industrial data types based on a pre-trained rule base and a lightweight syntax parser. The recognition process first parses the protocol header of the data packet to extract the source address, destination address, function code, and data length fields; then, it matches the data to a predefined data semantic category according to the function code mapping table; finally, it combines contextual information, such as the current operating mode of the device and historical operation sequences, to complete the accurate classification.

[0106] The destination address refers to the network identifier of the receiving end to which the industrial data ultimately needs to be transmitted, usually specified directly by the destination device identifier field in the packet header. When collecting raw industrial data at industrial edge nodes, each data entry already carries destination address information pre-configured by upper-layer applications or control systems. For example, the destination address of a welding robot position command is the IP address and device number of the central PLC, while the destination address of a temperature sensor reading is the IP address of the condition monitoring server. Industrial edge nodes directly extract and record the destination address corresponding to the industrial data by parsing the destination address field in the packet protocol header.

[0107] The target industrial protocol refers to the industrial communication protocol format supported by the target resource server (RS), which is determined by the industrial edge node by querying a locally pre-configured protocol mapping table based on the target address. The protocol mapping table maintains the correspondence between target device identifiers and target industrial protocols. For example, a target device identifier of "PLC-001" corresponds to the Modbus / TCP protocol, and a target device identifier of "SCADA-01" corresponds to the OPC UA protocol. After determining the target address, the industrial edge node queries the protocol mapping table to obtain the target industrial protocol supported by the target resource server (RS), which serves as the basis for subsequent encapsulation and encryption of data packets. If no corresponding entry exists in the protocol mapping table, the industrial edge node uses the default industrial protocol format for encapsulation and appends a protocol negotiation request flag to the data packet, which is then adaptively parsed by the receiving end.

[0108] S203. Based on the data type identification results, determine the security level corresponding to each industrial data, and obtain multiple data packets carrying security level labels.

[0109] Data type identification results refer to the classification and identification information output by the data type identification engine built into the industrial edge node after parsing the protocol header, mapping the function code, and performing contextual analysis on each piece of industrial data in the raw industrial data stream. This includes the data semantic category, the data source device identifier, the data generation timestamp, and the preliminarily determined business function attribute. This result provides the basic input for subsequent importance assessment and security level classification. For example, the data semantic category could be equipment start / stop commands, process parameter adjustment commands, safety alarm signals, or temperature sensor readings. Business function attributes could be, for example, control, monitoring, or auditing.

[0110] Specifically, when identifying the data types of various industrial data, the industrial data and the corresponding data type identification results can be input into a weighted decision tree model in sequence to obtain the importance score of each industrial data. Based on the importance score and a preset threshold, the industrial data is divided into at least three security levels. A corresponding security level label is added to each industrial data to obtain multiple data packets carrying security level labels.

[0111] In this embodiment, after data type identification is completed, a business impact assessment model is invoked to quantify the importance of each data record. This model employs a weighted decision tree structure, and its input features may include: whether the data directly participates in closed-loop control logic, whether it is associated with personal or equipment safety thresholds, whether it contains sensitive parameters that can be reversibly derived from process formulations, and the hazard level of similar data in historical leakage events.

[0112] For example, if the model outputs a continuous score between 0 and 1, the system sets two fixed thresholds: T1 = 0.75 and T2 = 0.4. A score ≥ T1 is classified as Level 1 data, between T2 and T1 as Level 2 data, and below T2 as Level 3 data. The classification result is appended to the header of the original data packet as a two-byte structured tag. The high byte indicates the data level; for example, a high byte of 0x01 indicates Level 1, 0x02 indicates Level 2, and 0x03 indicates Level 3. The low byte is reserved for future expansion. Through this step, the system achieves accurate quantification and automated classification of the importance of industrial data.

[0113] It should be noted that the specific value of the threshold can be set according to actual needs, and this embodiment does not limit it.

[0114] S204. For each data packet, call the encryption algorithm corresponding to the security level to encrypt it, and obtain the encrypted data packet.

[0115] In this embodiment, the security level is divided into three levels, and data packets of different levels are encrypted using different encryption algorithms.

[0116] In S204-1, the security level of the data packet is first determined. Specifically, the security level of the data packet can be determined based on the security level label.

[0117] For example, when the high byte of the tag is 0x01, the data packet is determined to be level 1 data; when the high byte of the tag is 0x02, the data packet is determined to be level 2 data; and when the high byte of the tag is 0x03, the data packet is determined to be level 3 data.

[0118] In S204-2, when the security level label indicates that the data packet is Level 1 data, the first preset encryption algorithm is invoked to perform full-field encryption on the data packet based on the Level 1 key, resulting in an encrypted data packet. The first preset encryption algorithm can be, for example, the AES-256-CBC algorithm.

[0119] In practical applications, before performing full-field encryption on the data packet based on the first-level key, it can be determined whether the lightweight encryption path triggering condition is met. If it is met, lightweight encryption is performed on the key fields in the data packet based on the first-level key to obtain an encrypted data packet; if it is not met, full-field encryption is performed on the data packet based on the first-level key to obtain an encrypted data packet.

[0120] For example, if the high byte of the tag is 0x01, the first step is to determine whether the Bernoulli random encryption mechanism is enabled. This mechanism is driven by an independent random number generator, which generates a uniformly distributed random number r in the interval [0,1) before processing each first-level data packet. If r < α, the lightweight encryption path is entered; otherwise, standard full-field encryption is performed. The probability parameter α is initially set to 0.3, and its dynamic adjustment is controlled by the security situation awareness unit deployed in the LCS. This unit periodically receives the number of attack alarms from the Intrusion Detection System (IDS), the entropy change index output by the traffic anomaly analysis module, and the industry risk level pushed by the external threat intelligence platform, and calculates the current network security risk score S. When S > 0.8, α is increased to 0.5; when S < 0.3, α is decreased to 0.2; otherwise, the current value is maintained. This adjustment instruction is sent to the hierarchical encryption modules of all edge nodes in the form of encrypted messages through the security control bus, with an update delay of no more than 200 milliseconds.

[0121] In the standard full-field encryption path, the primary data is encrypted using the AES-256 algorithm in CBC (Cipher-blockchaining) mode. The encryption key is filled with the primary key provided by the hierarchical key management module, and the initialization vector (IV) is a 128-bit random number, generated independently for each encryption and appended to the ciphertext. In the lightweight encryption path, only the critical opcodes in the instruction (usually located in bytes 3 to 6 of the data body) and the target device address (usually located in bytes 1 to 2) are encrypted using AES-256-CBC; the remaining fields remain in plaintext. The encrypted fields are replaced in their original positions, and the IV is also appended to the entire data packet header.

[0122] In S204-3, when the security level label indicates that the data packet is level 2 data, the second preset encryption algorithm is invoked to perform full-field encryption on the data packet based on the level 2 key, resulting in an encrypted data packet.

[0123] For example, for Level 2 data (with the tag's high byte being 0x02), the AES-128 algorithm can be invoked to perform full-field encryption on the entire data body using the Level 2 key in ECB (Electronic Codebook) mode. Although ECB mode does not possess the diffusion characteristics of CBC, it is engineering-applicable in Level 2 data scenarios with high real-time requirements due to its lack of IV dependency and constant encryption / decryption latency.

[0124] In S204-4, when the security level label indicates that the data packet is level 3 data, the third preset encryption algorithm is invoked, and triple DES enhanced mode encryption is performed based on the level 3 key to obtain the encrypted data packet.

[0125] For example, for Level 3 data (tag high byte is 0x03), triple DES enhanced mode is used for basic encryption. Specifically, two independent 56-bit DES keys K1 and K2 are used to process data blocks in an "encrypt-decrypt-encrypt" (EDE) sequence. Where P is the plaintext block and C is the ciphertext block. Keys K1 and K2 are derived from a three-level key. Through this step, the system dynamically allocates encryption resources based on the actual importance of the data, avoiding the waste of computing power and transmission delays caused by applying uniform high-strength encryption to all data.

[0126] The level 2 key is generated from the level 1 key using a key derivation function, and the level 3 key is generated from the level 2 key using a key derivation function.

[0127] It should also be noted that this embodiment also involves a hierarchical key management module implementing three-level key lifecycle management.

[0128] For example, the Level 1 key is generated by GRS within the Hardware Security Module (HSM) conforming to the FIPS 140-2 Level 3 standard, encapsulated using the Chinese national cryptographic algorithm SM4 or AES-256, and synchronized only to the LCS and core resource servers through a secure channel, with a generation period capped at 7 days. The Level 2 key is generated by the LCS based on the Level 1 key using a Key Derivation Function (KDF), specifically employing the HKDF-SHA256 algorithm. The derived Level 2 key is 128 bits long and synchronized to ordinary resource servers, with a generation period capped at 14 days. The Level 3 key is further derived by each resource server based on the locally held Level 2 key, stored only in the device's local secure storage area (such as a TPM chip or secure enclave), and not transmitted over the network, with a generation period capped at 30 days. All keys undergo an update process 72 hours before reaching the end of their lifecycle. After the retention period expires, the old key undergoes three random data overwrites and is completely erased from memory and persistent storage.

[0129] It is understood that the above-mentioned parameters such as key generation algorithm, derivation algorithm, key length, generation cycle and update advance time can be set according to actual needs, and this embodiment does not impose specific limitations on them.

[0130] S205. Encapsulate each encrypted data packet according to the target industrial protocol format to obtain the industrial data stream to be transmitted.

[0131] In this embodiment, the data transmission module in the industrial edge node receives the encrypted data packets and adapts and encapsulates them according to the target industrial protocol format supported by the target receiver, encapsulating each encrypted data packet into an industrial data stream to be transmitted. The target industrial protocol format is specified by the target industrial protocol determined in step S202, ensuring that the encapsulated data can be correctly parsed and received by the target resource server (RS).

[0132] In one possible implementation, the data transmission module has a built-in protocol conversion engine that supports the adaptation and conversion of more than ten industrial protocols, including Modbus / TCP, OPC UA, EtherCAT, Profinet, CANopen, S7, BACnet / IP, MQTT-SN, CoAP, and IEC 61850. The industrial protocols listed herein are merely illustrative and do not constitute a limitation on the scope of applicable protocols in this embodiment. Other existing and subsequently added industrial protocols in the art are also applicable to this embodiment.

[0133] During the encapsulation process, the data transmission module embeds the aforementioned two-byte encrypted metadata field into the extended header or user-defined field of the target protocol. For example, in Modbus / TCP, this field is inserted into the reserved bytes after the MBAP header and before the function code; in OPC UA, it is written as an extended attribute of DataSetMessage; and in MQTT-SN, it is placed in the optional field area after the Topic ID field. The protocol conversion and field insertion operations are performed by the hardware acceleration unit, and the additional processing latency introduced is measured to be no more than 1 millisecond. Through this step, the system ensures that encrypted data can be transmitted compatible with mainstream communication protocols without changing the existing industrial equipment hardware architecture, while minimizing the impact of protocol conversion on system real-time performance.

[0134] S206. Transmit the industrial data stream to be transmitted to the target resource server corresponding to the target address.

[0135] In this embodiment of the application, the encrypted industrial data stream is transmitted to the target resource server (RS) via an industrial Ethernet or a dedicated secure channel.

[0136] The industrial data transmission method provided in this application solves the technical problems in the prior art, such as the degradation of system real-time performance caused by full-volume high-strength encryption, the inability of static permission models to adapt to dynamic business scenarios, and the security risks caused by the lack of hierarchical isolation in key management mechanisms. It achieves the beneficial effects of effectively reducing system computing overhead and end-to-end transmission latency, improving the flexibility of permission management and the security isolation of keys, while ensuring the security of core industrial data.

[0137] Furthermore, in order to achieve rapid identification and integrity protection of encrypted data packets during data transmission, in Figure 2 Based on the previous embodiment, in this embodiment, when encapsulating the encrypted data packet, data level information and random encryption information can also be added to the header of the encrypted data packet.

[0138] Among them, data level information is used to identify the data level, random encryption information is used to identify whether the encrypted data packet is obtained by lightweight encryption; calculate the hash value of the industrial data corresponding to the encrypted data packet; add the hash value to the end of the encrypted data packet; the hash value is used for integrity verification by the target device.

[0139] In this embodiment, after all encryption operations are completed, the hierarchical encryption module appends a two-byte metadata field to the header of the data packet: the first byte is a multiplexing data level identifier (0x01, 0x02, and 0x03 correspond to level one, level two, and level three, respectively), and the second byte is set to 0x01 to indicate that random encryption is enabled, and 0x00 to indicate that it is not enabled. This metadata field does not participate in the encryption process and is used by the receiving end for decryption scheduling.

[0140] The integrity protection phase then begins. The hierarchical encryption module calculates a SHA-256 hash value based on the original plaintext data (i.e., the data body before encryption) and appends this 256-bit digest to the end of the encrypted data packet. This hash value is not used in the encryption process and is used by the receiving end to verify data integrity after decryption. If the receiving end recalculates the hash and compares it with the appended value, the data packet is discarded.

[0141] For example, for a Level 1 data device start / stop command, after AES-256 encryption, a metadata field [0x01, 0x01] (indicating Level 1 data with random encryption enabled) is appended to the data packet header, and a 32-byte SHA-256 hash value is appended to the end. The receiving resource server (RS) parses the header metadata, identifies the data packet as Level 1 data using lightweight encryption, decrypts it using the corresponding Level 1 key, recalculates the plaintext hash value, and compares it with the appended value. If they match, the command is executed; otherwise, it is discarded and an exception is logged.

[0142] Through this step, the system achieves rapid level identification and lightweight encryption status indication of encrypted data packets. At the same time, hash value verification ensures the integrity of data during transmission, preventing data from being tampered with or damaged and entering downstream control processes, thereby improving the reliability and security of industrial data transmission.

[0143] Figure 3 Flowchart of the industrial data transmission method provided in this application Figure 2 ,like Figure 3 As shown, the method provided in this embodiment can be specifically executed by a resource server. Specifically, the method includes:

[0144] S301: Receive a data request from the client, which carries an access token and a target device identifier.

[0145] In this embodiment, the resource server (RS) is deployed on the factory's local network or in the cloud and is responsible for responding to data access requests from clients. The client initiates a data request through the client application (APP), which must carry an access token (AccToken) generated by the local control server (LCS) and synchronized to the resource server, as well as a target device identifier (Device ID) that clearly identifies the target data resource.

[0146] The access token is generated by the local control server and synchronized to the resource server when the verification conditions are met. The verification conditions include: the identity of the local control server is verified by the Global Root Server (GRS), the identity of the client user is verified by the local control server, and the legality of the permission request content of the data request is determined by the permission policy library.

[0147] The Local Control Server (LCS) and the Global Root Server (GRS) deployed in the cloud form a two-layer trust architecture. The GRS stores the X.509 digital certificates of all registered LCSs. The certificates are issued by a trusted CA and contain the LCS's public key, organization identifier, and validity period. When LCS starts up, it initiates a two-way TLS handshake with the GRS. After the GRS verifies the validity of the LCS certificate chain, a secure channel is established.

[0148] Specifically, when a user requests access to specific industrial data through a client application (APP), the APP first submits an LCS authentication request to the GRS. After verifying the validity of the LCS certificate, the GRS returns a confirmation response. The APP then submits identity credentials to the LCS, including the user's account, biometrics, or dynamic password, along with specific permission request details, such as the target resource device ID, required data level, operation type, and expected validity period. After verifying the user's identity, the LCS determines the legitimacy of the request based on a pre-defined permission policy library. If the request is legitimate, an access token (AccToken) is generated.

[0149] For example, the access token (AccToken) can be in JSON Web Token (JWT) format, containing the issuer identifier, principal account, target device identifier, validity period window, unique token identifier, and permission description; the permission description includes the highest security level allowed and the set of allowed operation types. The AccToken is signed using the LCS's private key using ES256 to generate a JWS (JSON Web Signature). The LCS synchronously distributes the AccToken to the APP and the target RS through a secure channel. Upon receiving the AccToken from the APP, the RS verifies its signature validity, timestamp freshness, and permission granularity matching; it only responds to the data request if all verifications pass.

[0150] It should be noted that the format, signature algorithm, and specific field content of the access token can be set according to actual needs, and this embodiment does not impose specific limitations on them.

[0151] Specifically, the issuer identifier corresponds to the iss field, which identifies the local control server that generated the access token; the principal account corresponds to the sub field, which identifies the client user who initiated the request; the target device identifier corresponds to the aud field, which limits the target resource server to which the token is applied; the effective time window is defined by the nbf and exp fields; the unique token identifier corresponds to the jti field, which facilitates auditing and emergency revocation; and the permission description corresponds to the perms field, where the highest security level allowed for access limits the upper limit of the data level that the client can request, and the set of allowed operation types explicitly limits read, write, or other specific operation permissions.

[0152] AccToken uses LCS's private key to perform ES256 signing and generate JWS (JSON Web Signature). LCS then distributes AccToken synchronously to the APP and the target RS through a secure channel.

[0153] S302. Verify the access token.

[0154] In this embodiment of the application, after receiving a data request, the resource server performs the following verification process on the access token:

[0155] S3021. Verify the validity of the access token signature and confirm that the issuer is a legitimate local control server.

[0156] The resource server parses the JSON Web Signature (JWS) structure of the access token and verifies the ES256 signature using a pre-stored local control server public key. If the signature verification passes, it confirms that the token was issued by a legitimate LCS and has not been tampered with or forged; if the verification fails, the request is rejected directly and a security event is logged.

[0157] S3022. Check if the timestamp of the access token is within a valid window.

[0158] The resource server parses the effective timestamp (nbf) and expiration timestamp (exp) from the access token and compares them with the local UTC clock. The token is considered valid only if the current time is greater than or equal to nbf and less than or equal to exp. Furthermore, the resource server maintains a sliding window cache, recording the unique token ID (jti) and incrementing sequence number (nonce) of the most recent 1000 valid tokens. Tokens with duplicate sequence numbers or timestamps deviating from the local clock by more than 5 seconds are rejected to prevent replay attacks.

[0159] S3023. Verify whether the target device identifier in the access token matches the device identifier of the resource server.

[0160] The resource server parses the audience field (aud) in the access token and performs an exact match verification against its own device identifier. If the match is successful, the token is confirmed to have been issued for this resource server, preventing the token from being redirected to other unauthorized devices; if the match fails, the request is rejected.

[0161] S3024. Parse the permission description in the access token and determine whether the requested data security level and operation type are within the authorized scope.

[0162] The resource server parses the permission description object (perms) from the access token, extracting the highest allowed data level (data_level) and the set of allowed operation types (ops). It then compares the client's requested data security level and operation type with the above authorization range: authorization is granted only if the requested data level does not exceed data_level and the operation type is included in the ops set. For example, if the data_level in perms is level two and the ops only contain "Read", then the client's request to access level one data or perform a "Write" operation will be denied.

[0163] S303. After successful verification, in response to the data request, return the industrial data corresponding to the target device identifier to the client.

[0164] In this embodiment, when all four verifications—signature validity, timestamp freshness, device identifier matching, and permission granularity matching—pass, the resource server responds to the data request. First, it selects the corresponding decryption key (Level 1, Level 2, or Level 3 key) based on the data level label to decrypt the encrypted data packet. Then, it recalculates the SHA-256 hash value based on the original plaintext and compares it with the hash value appended to the end of the data packet to verify data integrity. After successful verification, the data is parsed according to the target industrial protocol format and returned to the client. If any verification fails, the request is rejected and an exception event is logged.

[0165] The industrial data transmission method provided in this application solves the technical problems of existing static permission models lacking dynamic verification mechanisms and unauthorized access behaviors being difficult to detect and block in a timely manner by performing multiple verifications on the access token on the resource server side, including signature validity, timestamp freshness, device identifier matching, and permission granularity matching, and responding to data requests only after all verifications are passed. This achieves the beneficial effects of refined dynamic control and real-time security protection for industrial data access.

[0166] The industrial data transmission method provided in this application solves the technical problems in the prior art, such as the degradation of system real-time performance caused by full-volume high-strength encryption, the inability of static permission models to adapt to dynamic business scenarios, and the security risks caused by the lack of hierarchical isolation in key management mechanisms. It achieves the beneficial effects of effectively reducing system computing overhead and end-to-end transmission latency, improving the flexibility of permission management and the security isolation of keys, while ensuring the security of core industrial data.

[0167] Figure 4 A schematic diagram of the structure of the industrial data transmission device provided in this application is shown below. Figure 4 As shown, the industrial data transmission device 40 provided in this embodiment includes:

[0168] The acquisition module 401 is used to acquire the raw industrial data stream, which includes multiple industrial data.

[0169] The identification module 402 is used to identify the data types of each industrial data, and determine the data type identification results, the target address and target industrial protocol corresponding to each industrial data.

[0170] The determination module 403 is used to determine the security level corresponding to each industrial data according to the data type identification result, and obtain multiple data packets carrying security level tags.

[0171] Encryption module 404 is used to call the encryption algorithm corresponding to the security level for each data packet to encrypt it, so as to obtain an encrypted data packet.

[0172] The encapsulation module 405 is used to encapsulate each encrypted data packet according to the target industrial protocol format to obtain the industrial data stream to be transmitted.

[0173] The transmission module 406 is used to transmit the industrial data stream to be transmitted to the target resource server corresponding to the target address.

[0174] In one possible implementation, the determining module 403 is specifically used to: sequentially input industrial data and the corresponding data type identification results into a weighted decision tree model to obtain an importance score corresponding to each industrial data; divide the industrial data into at least three security levels according to the importance score and a preset threshold; add a corresponding security level label to each industrial data to obtain multiple data packets carrying security level labels.

[0175] In one possible implementation, the encryption module 404 is specifically used to: when the security level label indicates that the data packet is level 1 data, call a first preset encryption algorithm to perform full-field encryption on the data packet based on the level 1 key to obtain an encrypted data packet; when the security level label indicates that the data packet is level 2 data, call a second preset encryption algorithm to perform full-field encryption on the data packet based on the level 2 key to obtain an encrypted data packet; when the security level label indicates that the data packet is level 3 data, call a third preset encryption algorithm to perform triple DES enhanced mode encryption based on the level 3 key to obtain an encrypted data packet; wherein, the level 2 key is generated based on the level 1 key through a key derivation function, and the level 3 key is generated based on the level 2 key through a key derivation function.

[0176] In one possible implementation, the encryption module 404 is further configured to: determine whether the lightweight encryption path triggering condition is met; if it is met, perform lightweight encryption on the key fields in the data packet based on the first-level key to obtain an encrypted data packet; if it is not met, perform full-field encryption on the data packet based on the first-level key to obtain an encrypted data packet.

[0177] In one possible implementation, the encapsulation module 405 is further configured to: add data level information and random encryption information to the header of the encrypted data packet; wherein the data level information is used to identify the data level, and the random encryption information is used to identify whether the encrypted data packet is obtained using lightweight encryption; calculate the hash value of the industrial data corresponding to the encrypted data packet; add the hash value to the end of the encrypted data packet; and use the hash value for the target device to perform integrity verification.

[0178] The industrial data transmission device provided in this embodiment can be used to execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0179] Figure 5 Schematic diagram of the industrial data transmission device provided in this embodiment Figure 2 .like Figure 5 As shown, the device 50 provided in this embodiment may include:

[0180] The receiving module 501 is used to receive data requests from clients. The data requests carry an access token and a target device identifier. The access token is generated by the local control server and synchronized to the resource server when the verification conditions are met. The verification conditions include: the identity of the local control server is verified by the global root server, the identity of the client is verified by the local control server, and the legality of the permission request content of the data request is determined by the permission policy library.

[0181] Verification module 502 is used to verify the access token.

[0182] The response module 503 is used to respond to the data request after the verification is passed and return the industrial data corresponding to the target device identifier to the client.

[0183] In one feasible implementation, the verification module 502 can be specifically used to: verify the signature validity of the access token and confirm that the issuer is a legitimate local control server; check whether the timestamp of the access token is within the valid window; verify whether the target device identifier in the access token matches the device identifier of the resource server; parse the permission description in the access token and determine whether the data security level and operation type of the request are within the authorized scope.

[0184] The industrial data transmission device provided in this embodiment can be used to execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0185] Figure 6 A schematic diagram of the structure of the electronic device provided in this application. Figure 6 As shown, the electronic device 60 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the device 60 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

[0186] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to perform the above-described method.

[0187] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0188] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0189] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0190] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0191] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0192] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0193] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0194] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0195] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0196] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0197] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0198] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0199] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0200] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. An industrial data transmission method, characterized in that, The method includes: Acquire raw industrial data streams, which include multiple industrial data streams; Each of the industrial data is identified by data type, and the data type identification result, the target address and target industrial protocol corresponding to each of the industrial data are determined. The industrial data and the corresponding data type identification results are sequentially input into a weighted decision tree model to obtain the importance score corresponding to each industrial data. Based on the importance score and preset threshold, the industrial data is divided into at least three security levels; Add corresponding security level tags to each of the aforementioned industrial data to obtain multiple data packets carrying security level tags; For each data packet, an encryption algorithm corresponding to the security level is invoked for encryption processing to obtain an encrypted data packet; Encapsulate each of the encrypted data packets according to the target industrial protocol format to obtain the industrial data stream to be transmitted; The industrial data stream to be transmitted is transmitted to the target resource server corresponding to the target address.

2. The method according to claim 1, characterized in that, For each data packet, the encryption algorithm corresponding to the security level is invoked for encryption processing to obtain an encrypted data packet, including: When the security level label indicates that the data packet is level 1 data, the first preset encryption algorithm is invoked to perform full-field encryption on the data packet based on the level 1 key to obtain the encrypted data packet; When the security level label indicates that the data packet is level 2 data, the second preset encryption algorithm is invoked to perform full-field encryption on the data packet based on the level 2 key, thereby obtaining the encrypted data packet; When the security level label indicates that the data packet is level three data, the third preset encryption algorithm is invoked, and triple DES enhanced mode encryption is performed based on the level three key to obtain the encrypted data packet; The secondary key is generated based on the primary key using a key derivation function, and the tertiary key is generated based on the secondary key using the same key derivation function.

3. The method according to claim 2, characterized in that, Before invoking the first preset encryption algorithm to perform full-field encryption on the data packet based on the primary key to obtain the encrypted data packet, the method further includes: Determine whether the lightweight encrypted path triggering conditions are met; When the conditions are met, lightweight encryption is performed on the key fields in the data packet based on the first-level key to obtain the encrypted data packet; If the conditions are not met, full-field encryption is performed on the data packet based on the first-level key to obtain the encrypted data packet.

4. The method according to claim 3, characterized in that, After encrypting each data packet using an encryption algorithm corresponding to the security level to obtain an encrypted data packet, the method further includes: Data level information and random encryption information are added to the header of the encrypted data packet; wherein, the data level information is used to identify the data level, and the random encryption information is used to identify whether the encrypted data packet is obtained using lightweight encryption; Calculate the hash value of the industrial data corresponding to the encrypted data packet; The hash value is appended to the end of the encrypted data packet; the hash value is used by the target device for integrity verification.

5. An industrial data transmission method, characterized in that, The method includes: The system receives a data request from a client, the data request carrying an access token and a target device identifier; wherein, the access token is generated by the local control server and synchronized to the resource server when verification conditions are met, the verification conditions include: the identity of the local control server is verified by the global root server, the identity of the client is verified by the local control server, and the permission request content of the data request is determined by the permission policy library. Verify the access token; After successful verification, in response to the data request, industrial data corresponding to the target device identifier is returned to the client.

6. The method according to claim 5, characterized in that, The verification of the access token includes: Verify the validity of the access token signature and confirm that the issuer is a legitimate local control server; Check if the timestamp of the access token is within a valid window; Verify whether the target device identifier in the access token matches the device identifier of the resource server; The permission description in the access token is parsed to determine whether the data security level and operation type of the request are within the authorized scope.

7. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

9. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-6.

Images