Management system based on data security

Abstract

The invention relates to the technical field of network security, and discloses a management system based on data security, the system comprises a key generation module, a data encryption module, a data block generation module, a data verification module and a data storage module, and the method comprises the following steps: triggering an updating mechanism of a dynamic key based on a production event type to obtain a current encryption key; encrypting the original production data by using the current encryption key to obtain encrypted data of the original production data; dividing the encrypted data into data blocks, and adding timestamps and equipment identifiers to the data blocks to obtain to-be-verified data primitives of the original production data; performing consensus verification on the to-be-verified data primitives to obtain a verified data block set of the original production data; performing aggregation processing on the data block set passing verification to obtain a complete ciphertext data set of the original production data, and storing the complete ciphertext data set to the block chain network; according to the invention, the safety of production management data can be improved.

Description

Technical Field

[0001] The present invention relates to the technical field of network security, and in particular to a management system based on data security. Background Art

[0002] In the field of production management data processing, existing technologies have significant shortcomings in data security. Key management mechanisms lack dynamic adaptability, often using fixed keys or periodic updates. These mechanisms are unable to adjust encryption strategies in real time based on changes in production event types. This results in keys being easily cracked after long-term use, exposing raw production data to the risk of leakage. Furthermore, the data encryption process lacks structured processing, and encrypted data blocks lack unique identification and verification mechanisms, making it difficult to trace data sources and determine whether they have been tampered with. Consequently, data integrity and authenticity cannot be effectively guaranteed.

[0003] Furthermore, existing technologies suffer from both efficiency and security flaws in data verification and storage. Data verification often relies on a single node or simple rule-based verification, lacking a consensus verification mechanism based on node trustworthiness. This makes it susceptible to interference from abnormal nodes, leading to distorted verification results. Furthermore, data storage often utilizes centralized databases, which present a single point of failure risk. Furthermore, there is a lack of standardized aggregation and distributed storage design for verified data, resulting in weak data storage resistance and difficulty meeting the stringent requirements for data security and traceability in production management. Summary of the Invention

[0004] The present invention provides a management system based on data security to solve the problems raised in the above background technology.

[0005] To achieve the above-mentioned object, the present invention provides a data security management system, characterized in that the system includes a key generation module, a data encryption module, a data block generation module, a data verification module and a data storage module, wherein:

[0006] The key generation module is used to trigger the dynamic key update mechanism based on the production event type to obtain the current encryption key of the production management platform;

[0007] The data encryption module is configured to encrypt the original production data of the production management platform using the current encryption key to obtain encrypted data of the original production data;

[0008] The data block generation module is configured to divide the encrypted data into data blocks and append timestamps and device identifiers to the data blocks to obtain the data primitives to be verified of the original production data;

[0009] The data verification module is used to perform consensus verification on the data primitives to be verified to obtain a set of verified data blocks of the original production data;

[0010] The data storage module is used to aggregate the verified data block set to obtain a complete ciphertext data set of the original production data, and store the complete ciphertext data set in the blockchain network.

[0011] In a preferred embodiment, when the key generation module executes the dynamic key update mechanism triggered based on the production event type to obtain the current encryption key of the production management platform, it is specifically used to:

[0012] Generate an initial key factor based on a preset key seed parameter;

[0013] Constructing a dynamic key sequence of the production management platform based on the production event type occurring in the production management platform and the initial key factor;

[0014] The current encryption key of the production management platform is selected from the dynamic key sequence.

[0015] In a preferred embodiment, when the key generation module constructs the dynamic key sequence of the production management platform based on the production event type occurring in the production management platform and the initial key factor, it is specifically used to:

[0016] Parsing the event characteristic value of the production event type;

[0017] Combining and encoding the event characteristic value and the occurrence time of the production event type to obtain a time-type sequence of the production event type;

[0018] Mapping the time-type sequence and the hash value of the initial key factor into a message authentication code of the production management platform;

[0019] Using the latest unused key in the message authentication code as the current encryption key of the production management platform;

[0020] In a trusted execution environment, a historical key in the message authentication code is destroyed.

[0021] In a preferred embodiment, when the data encryption module encrypts the original production data of the production management platform using the current encryption key to obtain encrypted data of the original production data, it is specifically used to:

[0022] Structurally reorganizing the original production data in the production management platform according to the formatted data specification to obtain standardized data blocks;

[0023] Using the current encryption key to perform key grouping on the standardized data block to obtain an initial encrypted data block of the original production data;

[0024] An integrity check code is added to the initial encrypted data block to obtain encrypted data of the original production data.

[0025] In a preferred embodiment, when the data encryption module performs key grouping on the standardized data block using the current encryption key to obtain the initial encrypted data block of the original production data, it is specifically configured to:

[0026] inputting the standardized data block into a counter mode encryption engine;

[0027] A round function is iterated through the counter mode encryption engine, wherein the round function is as follows:

[0028] C i =E k (P i ⊕CTR i )

[0029] Where C i is the ciphertext of the i-th standardized data block, E k is the current encryption key, P i is the i-th standardized data block, ⊕ is the XOR operation, CTR i is the counter mode vector;

[0030] The ciphertexts are aggregated to obtain an initial encrypted data block of the original production data.

[0031] In a preferred embodiment, when the data block generation module divides the encrypted data into data blocks and adds timestamps and device identifiers to the data blocks to obtain the data primitives to be verified of the original production data, it is specifically configured to:

[0032] Cutting the encrypted data into data segments of equal length to obtain initial data blocks of the original production data;

[0033] Extracting the physical address code and current timing service time of the production management platform to obtain the equipment-time composite identifier of the production management platform;

[0034] Adding the device-time composite identifier to the initial data block to obtain a basic verification data block of the original production data;

[0035] The data integrity characteristic value of the basic verification data block is embedded into the header of the corresponding basic verification data block to obtain the data primitive to be verified of the original production data.

[0036] In a preferred embodiment, the data verification module performs consensus verification on the data primitives to be verified to obtain a set of verified data blocks of the original production data, specifically for:

[0037] When the verification node of the production management platform broadcasts the data primitive to be verified, triggering a verification request of the verification node;

[0038] Receive the data integrity certificate and timestamp compliance certificate returned by the verification node;

[0039] The data integrity proof and the timestamp compliance proof are aggregated to obtain a set of verified data blocks of the original production data.

[0040] In a preferred embodiment, when the data verification module receives the data integrity certificate and timestamp compliance certificate returned by the verification node, it is specifically configured to:

[0041] Extracting the accuracy and response delay scores from the historical records of the verification node;

[0042] fusing the accuracy rate and the response delay score into a credibility coefficient, and normalizing the credibility coefficient into a dynamic weight factor;

[0043] Consensus verification is performed on the data primitive to be verified based on the dynamic weight factor, the data integrity proof, and the timestamp compliance proof to obtain a verification result of the data primitive to be verified, wherein the calculation formula of the verification result is as follows:

[0044]

[0045] Where V is the verification result, σ is the Sigmoid activation function, n is the total number of verification nodes, j is the serial number of the verification node, and w j is the dynamic weight factor of the jth node, I j The quantized value for the data integrity proof of the jth node, T j Quantize the timestamp compliance proof value of the jth node;

[0046] When the verification result is greater than the verification threshold, the data element to be verified is determined to have passed the verification.

[0047] In a preferred embodiment, when the data storage module aggregates the verified data block set to obtain a complete ciphertext data set of the original production data, it is specifically configured to:

[0048] Arranging the data blocks in the verified data block set in order of timestamps to obtain a time series data sequence of the original production data;

[0049] performing redundancy elimination processing on the time series data sequence;

[0050] An aggregate check code is added to the time series data sequence after redundancy elimination processing to obtain a complete ciphertext data set of the original production data.

[0051] In a preferred embodiment, when the data storage module stores the complete ciphertext data set in the blockchain network, it is specifically used to:

[0052] Constructing the complete ciphertext data set into a Merkle tree structure and generating a root hash value;

[0053] A new blockchain block header for the original production data based on the creation of the root hash value and timestamp of the Merkle tree structure;

[0054] Writing the new blockchain block header into the blockchain main chain to obtain the blockchain node network of the original production data;

[0055] The complete ciphertext data set is distributed and stored in the blockchain node network.

[0056] Compared with the prior art, the present invention has the following beneficial effects:

[0057] 1. The data security management system provided by this invention generates encryption keys adapted to the current production scenario by triggering a dynamic key update mechanism based on production event types, improving the timeliness and pertinence of data encryption from the source. Furthermore, after encrypting raw production data using the current encryption key, combined with data block segmentation and the addition of timestamps and device identifiers, it enables refined data management and unique traceability, effectively enhancing the security of production data during the encryption and preprocessing stages.

[0058] 2. This invention verifies data primitives through a consensus verification mechanism, ensuring the integrity and compliance of data blocks. The design of aggregating and storing verified data blocks in a blockchain network further safeguards the storage security of complete ciphertext datasets, leveraging the blockchain's tamper-proof and distributed storage characteristics. Furthermore, the coordinated integration of key generation, data encryption, verification, and storage creates a comprehensive security protection system, significantly improving the overall security of production management data during transmission, processing, and storage. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 A system architecture diagram of a data security management system provided by one embodiment of the present invention;

[0060] The purpose, features and advantages of the present invention will be further described with reference to the accompanying drawings and in conjunction with the embodiments. DETAILED DESCRIPTION

[0061] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments belong to some embodiments of the present invention, but not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0062] The terms used in the embodiments of the present invention are for the purpose of describing specific embodiments only and are not intended to limit the present invention. The singular forms "said" and "the" used in the embodiments of the present invention and the appended claims are also intended to include plural forms, unless the context clearly indicates otherwise, and "a plurality" generally includes at least two.

[0063] As used herein, the words “if” or “when” may be interpreted as “at the time of” or “when” or “in response to determining” or “in response to detecting,” depending on the context. Similarly, the phrases “if it is determined” or “if (stated condition or event) is detected” may be interpreted as “when it is determined” or “in response to the determination” or “when detecting (stated condition or event)” or “in response to detecting (stated condition or event),” depending on the context.

[0064] In addition, the step sequence in the following method embodiments is only an example and not a strict limitation.

[0065] In fact, the server-side device deployed by the data security-based management system may be composed of one or more devices. The above-mentioned data security-based management system can be implemented as: business instances, virtual machines, and hardware devices. For example, the data security-based management system can be implemented as a business instance deployed on one or more devices in the cloud node. In simple terms, the data security-based management system can be understood as a software deployed on the cloud node, which is used to provide a data security-based management system for each user terminal. Alternatively, the data security-based management system can also be implemented as a virtual machine deployed on one or more devices in the cloud node. The virtual machine is installed with application software for managing each user terminal. Alternatively, the data security-based management system can also be implemented as a server-side composed of many hardware devices of the same or different types, and one or more hardware devices are set to provide a data security-based management system for each user terminal.

[0066] In terms of implementation, the data security management system and the user end are mutually compatible. Specifically, if the data security management system is an application installed on a cloud service platform, the user end is the client that establishes a communication connection with the application. Alternatively, if the data security management system is implemented as a website, the user end is implemented as a webpage. Alternatively, if the data security management system is implemented as a cloud service platform, the user end is implemented as a mini-program within an instant messaging application.

[0067] like Figure 1 FIG. 1 is a system architecture diagram of a data security management system provided by an embodiment of the present invention.

[0068] The data security-based management system 100 of the present invention can be set in a cloud server. In terms of implementation, it can be used as one or more service devices, or as an application installed on the cloud (such as a server or server cluster of a mobile service operator), or it can be developed as a website. According to the functions implemented, the data security-based management system 100 may include a key generation module 101, a data encryption module 102, a data block generation module 103, a data verification module 104 and a data storage module 105. The module of the present invention can also be referred to as a unit, which refers to a series of computer program segments that can be executed by an electronic device processor and can perform fixed functions, which are stored in the memory of the electronic device.

[0069] In an embodiment of the present invention, in a management system based on data security, each of the above modules can be implemented independently and called with other modules. The call here can be understood as a module that can connect to multiple modules of another type and provide corresponding services to the multiple modules connected to it. In the management system based on data security provided by an embodiment of the present invention, the scope of application of the management system architecture based on data security can be adjusted by adding modules and directly calling them without modifying the program code, thereby realizing cluster-based horizontal expansion, so as to achieve the purpose of quickly and flexibly expanding the management system based on data security. In actual applications, the above modules can be set in the same device or different devices, or they can be set in virtual devices, such as service instances in cloud servers.

[0070] The following describes the various components and specific workflows of the data security management system in conjunction with specific embodiments:

[0071] The key generation module 101 is used to trigger the dynamic key update mechanism based on the production event type to obtain the current encryption key of the production management platform;

[0072] When the key generation module executes the dynamic key update mechanism triggered based on the production event type to obtain the current encryption key of the production management platform, it is specifically used to:

[0073] Generate an initial key factor based on a preset key seed parameter;

[0074] Constructing a dynamic key sequence of the production management platform based on the production event type occurring in the production management platform and the initial key factor;

[0075] The current encryption key of the production management platform is selected from the dynamic key sequence.

[0076] When the key generation module constructs a dynamic key sequence of the production management platform based on the production event type occurring in the production management platform and the initial key factor, the key generation module is specifically used to:

[0077] Parsing the event characteristic value of the production event type;

[0078] Combining and encoding the event characteristic value and the occurrence time of the production event type to obtain a time-type sequence of the production event type;

[0079] Mapping the time-type sequence and the hash value of the initial key factor into a message authentication code of the production management platform;

[0080] Using the latest unused key in the message authentication code as the current encryption key of the production management platform;

[0081] In a trusted execution environment, a historical key in the message authentication code is destroyed.

[0082] Specifically, the preset key seed parameters include a fixed character sequence pre-set by the production management platform, the unique code of the enterprise to which the platform belongs, and the character format corresponding to the time the platform was first started. These parameters are stored in a dedicated secure storage module when the platform is deployed. When generating the initial key factor, these preset key seed parameters are extracted from the secure storage module and concatenated in the order of "fixed character sequence + enterprise unique code + first start time character" to obtain a string of combined characters. Each character in the combined character string is then converted into its corresponding two-digit hexadecimal form. All the converted hexadecimal characters are then arranged consecutively to form a string that is the initial key factor.

[0083] Furthermore, the production management platform monitors production events that occur during the production process in real time. Production event types include normal equipment operation, raw material replenishment, equipment failure, product quality inspection qualification, production task completion, etc. Each event type corresponds to a pre-set unique identification character (.

[0084] Furthermore, when a production event is monitored, the platform immediately records the type and occurrence time of the event, and retrieves the initial key factor from the secure storage module; the unique identification character corresponding to the event type, the year, month, day, hour, minute, and second characters of the event occurrence time, and the initial key factor are spliced ​​in the order of "initial key factor + event type identification character + event time character" to form a new key fragment; as production events continue to occur, a new key fragment is generated in the above manner for each new production event, and all generated key fragments are arranged in sequence according to the order of the events. The formed ordered key fragment set is the dynamic key sequence of the production management platform.

[0085] Furthermore, the key selection rule is pre-set in the production management platform as "based on the current system time, select the last key fragment generated within the last 30 minutes in the dynamic key sequence."

[0086] Furthermore, when the encryption key needs to be used, the platform first obtains the current system time, then queries the event occurrence time corresponding to all key fragments in the dynamic key sequence, filters out the key fragments whose event occurrence time is within 30 minutes before the current system time, and selects the key fragment with the latest event occurrence time from these fragments. This fragment is the current encryption key of the production management platform.

[0087] Specifically, the event characteristic value of a production event type is information that represents the core attributes of that type of event. For example, the characteristics of an equipment failure event include the faulty equipment number, fault code, and fault level, and the characteristics of a raw material replenishment event include the raw material type, replenishment quantity, and replenishment batch. When parsing the event characteristic value, the characteristic information corresponding to the production event type is first extracted from the event recording module of the production management platform. Each characteristic information is converted into a fixed-length character. These characters are then concatenated in the order of "equipment / raw material identifier + core parameters + auxiliary parameters". The resulting string is the event characteristic value of the production event type.

[0088] Furthermore, the occurrence time of a production event type is recorded in the digital form of "year, month, day, hour, minute, and second" (e.g., 14:30:25 on July 22, 2025, is recorded as "20250722143025"). When encoding the event characteristic value and the occurrence time, the encoding rule is first determined as "event characteristic value first, occurrence time second, and the two are directly connected"; the parsed event characteristic value and the occurrence time digital string corresponding to the event type are concatenated according to this rule to obtain a mixed string; the length of the string is then checked. If the length is less than 64 characters, "0" is added to the end of the string until the length is 64 characters. If the length exceeds 64 characters, the first 64 characters are truncated. The processed string is the time-type sequence of the production event type.

[0089] Furthermore, the hash value of the initial key factor is a character string with a fixed length of 32 characters obtained by hashing the initial key factor (the hashing process is: dividing the character string of the initial key factor into groups of 8 characters, performing cyclic replacement processing on each group of characters, and finally integrating it into a fixed character string of 32 characters).

[0090] Furthermore, when mapping the time-type sequence and the hash value of the initial key factor into a message authentication code, the mapping rule is first determined to be "the time-type sequence and the hash value are spliced ​​alternately by position", that is, the first character of the time-type sequence is spliced ​​with the first character of the hash value, and then the second character of the time-type sequence is spliced ​​with the second character of the hash value, until the 64-character time-type sequence and the 32-character hash value are all spliced ​​together to form a 96-character string; then the string is divided into groups of 24 characters each, and a total of 4 groups of substrings are obtained. The set composed of these 4 groups of substrings arranged in sequence is the message authentication code of the production management platform.

[0091] Furthermore, in the production management platform's message authentication code, each substring is generated with its generation time recorded and marked as "used" after use. To use the latest unused key in the message authentication code as the current encryption key, all substrings, along with their generation times and usage status, are retrieved from the message authentication code's storage unit. Substrings marked as "unused" are then filtered out, and their generation times are compared. The substring with the latest generation time is selected, and this substring becomes the production management platform's current encryption key.

[0092] Furthermore, the trusted execution environment is a secure computing area in the production management platform that is independent of the main operating system. It has a dedicated processor and memory and is only accessible by pre-set security instructions. When destroying historical keys in a message authentication code in a trusted execution environment, the historical keys are first identified as substrings in the message authentication code that are marked as "used" and generated more than 72 hours ago. The storage addresses of these historical keys in memory are retrieved through the secure interface of the trusted execution environment, and a fixed invalid character "00000000" (8 characters in total) is written to each storage address, overwriting the original key content. The relevant records of these historical keys are then deleted from the environment's key status record table, and the corresponding storage addresses are marked as "overwriteable", completing the destruction of the historical keys.

[0093] In general, this mechanism allows encryption keys to be dynamically adjusted as the type of production events changes, avoiding the security risks that may arise from the long-term use of fixed keys.

[0094] In general, by associating production event types with key generation, the keys can be more adaptable to different scenarios. The keys corresponding to each type of production event can more accurately match the data encryption requirements in that scenario, thereby improving the encryption protection of original production data from the key level.

[0095] In general, it builds a dynamic key sequence based on the initial key factor generated by the preset key seed parameters and combines the characteristic values ​​and occurrence time of the production event to ensure the standardization and uniqueness of the key generation.

[0096] In general, destroying historical keys in a trusted execution environment reduces the risk of key leakage, further ensures the security of current encryption keys, and provides reliable key support for subsequent data encryption links.

[0097] The data encryption module 102 is configured to encrypt the original production data of the production management platform using the current encryption key to obtain encrypted data of the original production data;

[0098] In an embodiment of the present invention, when the data encryption module encrypts the original production data of the production management platform using the current encryption key to obtain encrypted data of the original production data, it is specifically used to:

[0099] Structurally reorganizing the original production data in the production management platform according to the formatted data specification to obtain standardized data blocks;

[0100] Using the current encryption key to perform key grouping on the standardized data block to obtain an initial encrypted data block of the original production data;

[0101] An integrity check code is added to the initial encrypted data block to obtain encrypted data of the original production data.

[0102] When the data encryption module performs key grouping on the standardized data block using the current encryption key to obtain the initial encrypted data block of the original production data, the data encryption module is specifically configured to:

[0103] inputting the standardized data block into a counter mode encryption engine;

[0104] A round function is iterated through the counter mode encryption engine, wherein the round function is as follows:

[0105] C i =E k (P i ⊕CTR i )

[0106] Where C iis the ciphertext of the i-th standardized data block, E k is the current encryption key, P i is the i-th standardized data block, ⊕ is the XOR operation, CTR i is the counter mode vector;

[0107] The ciphertexts are aggregated to obtain an initial encrypted data block of the original production data.

[0108] Specifically, the formatted data specification is a predefined structured data template within the production management platform, containing information such as data type, field order, and field length. When reorganizing raw production data according to this specification, data items such as equipment operating parameters, production process indicators, and quality inspection results are first extracted from the raw data. Each data item is then converted to a standard format according to the specification (e.g., dates are uniformly formatted as "YYYYMMDD," with numeric data retained to two decimal places). These data items are then arranged according to the field order specified in the specification. Missing data items are padded with preset default values, and data items exceeding the length limit are truncated to the first N digits (N is the field length defined by the specification). Finally, a data type identifier and version number are added to the data block header. The resulting data set that conforms to the standard structure is called a standardized data block. For example, the date "2025-07-22" in the raw data is converted to "20250722," the equipment temperature "23.567°C" is converted to "23.57" with two decimal places, and missing raw material batch numbers are padded with "0000."

[0109] Furthermore, the current encryption key is a string of fixed length 24 characters. When using this key to group the standardized data blocks, the standardized data blocks are first divided into data sub-blocks of 8 characters each. Any sub-blocks with less than 8 characters are padded to the right with "0" to 8 characters. A key replacement operation is performed on each data sub-block. Specifically, the first character of the sub-block is replaced with the first character of the current encryption key, the second character of the sub-block is replaced with the seventh character of the key, the third character of the sub-block is replaced with the thirteenth character of the key, and so on, completing the replacement according to a fixed position mapping relationship. After all data sub-blocks are replaced, they are concatenated in their original order. The resulting new data block is the initial encrypted data block of the original production data. For example, the data sub-block "ABCDEFGH" is replaced with the key "123456789012345678901234" to become "18547290".

[0110] Furthermore, the integrity check code is generated by performing a specific operation on the initial encrypted data block. When adding the integrity check code, the initial encrypted data block is first divided into groups of 6 characters, and each group of characters is XORed (the characters are converted to ASCII code values ​​and then XORed) to obtain a new character value; the XORed characters of all groups are sequentially concatenated to form a check string of length M (M is the number of groups); the check string is added to the end of the initial encrypted data block, and a fixed identification character "#CHK" is appended to the check string. The resulting data set containing the initial encrypted data block and the integrity check information is the encrypted data of the original production data. For example, if the initial encrypted data block is "ABCDEF123456", after grouping, "ABCDEF" is XORed to obtain "X", and "123456" is XORed to obtain "Y", and the final encrypted data is "ABCDEF123456XY#CHK".

[0111] Specifically, a standardized data block is a data set reorganized according to the formatted data specification and has a fixed data structure and length. When a standardized data block is input into the counter mode encryption engine, the current encryption key and initial counter value are first obtained from the secure storage area. The initial counter value is a fixed-length numeric string. The standardized data block is divided into data units of 8 characters each, and the tail units with less than 8 characters are padded with "0" on the right. A unique counter value is assigned to each data unit, and the counter value increases sequentially from the initial counter value (for example, if the initial value is "00000001", the counter values ​​of subsequent units are "00000002" and "00000003" respectively). The data unit and the corresponding counter value are combined into the form of "data unit + counter value" to form a data group to be encrypted, which is then input into the processing queue of the counter mode encryption engine in sequence.

[0112] Furthermore, after receiving the data group to be encrypted, the counter mode encryption engine processes each data group through round function iteration. The round function iteration process is as follows: first, the counter value and the current encryption key are replaced by a character operation, that is, the first character of the counter value is replaced by the third character of the key, the second character is replaced by the seventh character of the key, and so on, and the replacement is completed according to a fixed position mapping relationship; the replaced string is circularly shifted, and the first four characters are moved to the end; the shifted string is then XORed with the original counter value (the characters are converted to ASCII code values ​​and then XORed) to obtain an intermediate value; the intermediate value is XORed with the data unit character by character, and the result is the ciphertext unit after one round of iteration; the above round function operation is repeated for each ciphertext unit three times, and the encryption key used each time is adjusted according to a fixed rule (for example, the first six characters of the key are moved to the end each time), and finally the ciphertext unit after three rounds of iteration is obtained.

[0113] Furthermore, when aggregating ciphertext, all ciphertext units after iterative processing of the round function are concatenated in sequence according to the order of the original data units to form a continuous ciphertext string; an initial counter value and an iteration round number identifier (such as "R03" indicates 3 rounds of iteration) are added to the head of the ciphertext string, and a fixed end identifier "#END" is added to the tail; an integrity check is performed on the ciphertext string after the identifier is added to ensure that all ciphertext units are correctly concatenated and the identifiers are complete. The final data block obtained after the check is correct is the initial encrypted data block of the original production data.

[0114] Specifically, C i is the ciphertext generated after the encryption of the i-th standardized data block, which comes from the result of the XOR operation of the i-th standardized data block and the corresponding counter pattern vector, and then encrypted with the current encryption key; E k It is the current encryption key, which is stored in the secure key storage area of ​​the production management platform. It is generated by the preset key seed parameters and updated regularly. i is the i-th standardized data block, which is obtained from the original production data of the production management platform after structured reorganization. The length of each data block is fixed to 8 characters; ⊕ is the exclusive OR operation, which performs the exclusive OR operation on the ASCII code values ​​of two characters to obtain a new ASCII code value, which is then converted into the corresponding character; CTR i It is a counter pattern vector, which is generated by combining the initial counter value and the data block number. The initial counter value is a fixed 16-bit digital string. The data block number starts at 0 and increases incrementally. The combination is the first 8 bits of the initial counter value and the last 8 bits of the data block number.

[0115] Furthermore, the meaning of the formula is to perform an XOR operation on the i-th standardized data block and the corresponding counter pattern vector to obtain an intermediate value, and then use the current encryption key to encrypt and convert the intermediate value to finally generate the i-th ciphertext; this encryption method converts the encryption of the data block into the encryption of the counter value. The counter value increases sequentially and is unique, so that the same data block will generate different ciphertexts at different positions, thereby enhancing the security of the encryption; through the dual operations of XOR operation and key encryption, the original data is converted into ciphertext, realizing the confidentiality protection of the data and ensuring the security of the data during transmission and storage.

[0116] Furthermore, as the data block sequence number i increases, the counter pattern vector CTR i The value of CTR increases by 1 each time. i Even if the adjacent data block P i The same, the intermediate value after XOR operation will be different, thus generating different ciphertext C i; current encryption key E k In a round of encryption process, but will be updated in different rounds or different time periods, the same data block will generate different ciphertext after updating; in the whole encryption process, the change trend of ciphertext C i is directly related to the exclusive or result of data block P i and counter mode vector CTR i , and the increment of CTR i guarantees the randomness and uniqueness of the ciphertext, so that the encryption result has good diffusion and confusion.

[0117] In general, the current encryption key is dynamically generated based on the production event type, and the encryption is carried out on this basis, which can make the encryption process of the original production data closely related to the production scene, so that the encryption result has scene specificity, effectively improving the adaptability of the encrypted data to the production environment, and building targeted security protection for the original production data from the encryption link.

[0118] In general, in the encryption process, the original production data is first structured and reorganized according to the formatted data specification to obtain standardized data blocks, and then encrypted by the counter mode encryption engine and added with an integrity check code, which not only ensures the standardization and consistency of the encryption operation, but also can quickly identify whether the encrypted data has been tampered with through the integrity check code, ensuring the integrity of the encrypted data and providing a safe and reliable encrypted data basis for subsequent data block processing and storage.

[0119] The data block generation module 103 is configured to divide the encrypted data into data blocks, and attach a timestamp and a device identifier to the data blocks to obtain the to-be-verified data element of the original production data;

[0120] In the embodiment of the application, when the data block generation module divides the encrypted data into data blocks, and attaches a timestamp and a device identifier to the data blocks to obtain the to-be-verified data element of the original production data, it is specifically used for:

[0121] Cutting the encrypted data into equal-length data segments to obtain the initial data block of the original production data;

[0122] Extracting the physical address code and the current time service time of the production management platform to obtain the device-time composite identifier of the production management platform;

[0123] Attaching the device-time composite identifier to the initial data block to obtain the basic verification data block of the original production data;

[0124] Embedding the data integrity feature value of the basic verification data block into the header corresponding to the basic verification data block to obtain the to-be-verified data element of the original production data.

[0125] Specifically, the encrypted data is a continuous string containing the initial encrypted data block and the integrity check code. When the encrypted data is cut into equal-length data segments, the fixed length of each data segment is first determined to be 64 characters. Starting from the beginning of the encrypted data, each group of 64 characters is cut. If the last data segment is less than 64 characters, “0” is added to the right side to 64 characters. Each cut data segment is assigned a unique segment number, which is incremented from 0. The combination of “segment number + data segment content” is formed. All combinations are arranged in order according to the number. The resulting set of equal-length data segments is the initial data block of the original production data.

[0126] Further, the physical address code of the production management platform is the MAC address of the device network card, which consists of 12 hexadecimal characters. The current time service is the precise time obtained from the national time service center, in the format of “YYYYMMDDHHMMSS”. When extracting the device-time composite identifier, the MAC address is first read from the network configuration information of the device and converted into a continuous 12-bit string (such as “00-1B-77-41-56-9A” converted into “001B7741569A”). Then, the current time is obtained from the time service through the network interface, and the year, month, day, hour, minute, and second parts are extracted to form a 14-bit time string. The MAC address string and the time string are concatenated in the order of “MAC address + time” to form a 26-bit composite string, which is the device-time composite identifier of the production management platform.

[0127] Further, when the initial data block is attached with the device-time composite identifier, the device-time composite identifier is first converted into a fixed-length string of 32 characters (if less than 32 bits, “F” is added to the right side). Each initial data block uses the same device-time composite identifier. The 32-bit device-time composite identifier string is added to the tail of each initial data block to form a new data block structure of “initial data block content + device-time composite identifier”. After the addition is completed, the length of the new data block is checked to ensure that the total length of each data block is 96 characters (initial data block 64 bits + device-time composite identifier 32 bits). After the check is correct, the resulting set of data blocks is the basic verification data block of the original production data.

[0128] Furthermore, the data integrity characteristic value of the basic verification data block is generated by performing a specific operation on the data block content (including the initial data block and the device-time composite identifier). When embedding the integrity characteristic value, the basic verification data block is first divided into groups of 8 characters. Each group of characters is cyclically shifted (moving the first two characters to the end). The shifted groups of characters are then concatenated in sequence to obtain a new string. Characters in the new string are replaced by replacing even-numbered characters with characters whose ASCII code value is increased by 1, forming a 16-bit characteristic string. This 16-bit characteristic string is added to the header of the basic verification data block, and a fixed identifier "#CHK" is appended to the characteristic string, forming a new structure of "#CHK + characteristic string + basic verification data block content". After the addition is completed, the data block is formatted to ensure that it meets the format requirements of "#CHK + 16-bit characteristic string + 96-bit data content". After passing the check, the obtained data blocks are the data primitives to be verified of the original production data.

[0129] In general, segmenting encrypted data into blocks allows for granular data segmentation, preventing the risk of data loss due to a single failure during transmission or processing. It also provides a modular foundation for subsequent data verification and storage, enhancing data processing flexibility. The addition of device identifiers precisely links the data to the production equipment it corresponds to, allowing data to be traced back to its specific source, ensuring traceability at the source level.

[0130] In general, the addition of a timestamp gives the data block a clear time attribute. Combined with the device identifier to form a device-time composite identifier, it can effectively distinguish production data generated at different times and by different devices, avoiding data confusion.

[0131] In general, embedding the data integrity characteristic value into the data block header to form the data primitive to be verified provides a key basis for subsequent consensus verification, ensuring that the verification process can be accurately verified based on the characteristics of the data itself, and laying the foundation for data integrity and authenticity verification.

[0132] The data verification module 104 is configured to perform consensus verification on the data primitives to be verified, and obtain a set of verified data blocks of the original production data;

[0133] In an embodiment of the present invention, the data verification module performs consensus verification on the data primitives to be verified to obtain a set of verified data blocks of the original production data, specifically for:

[0134] When the verification node of the production management platform broadcasts the data primitive to be verified, triggering a verification request of the verification node;

[0135] receive the data integrity proof and the timestamp compliance proof returned by the verification node;

[0136] aggregate the data integrity proof and the timestamp compliance proof to obtain a verified data block set of the original production data.

[0137] When the data verification module receives the data integrity proof and the timestamp compliance proof returned by the verification node, it is specifically used for:

[0138] extracting the accuracy and response delay scores in the historical record of the verification node;

[0139] fusing the accuracy and the response delay score into a credibility coefficient, and normalizing the credibility coefficient into a dynamic weight factor;

[0140] performing consensus verification on the to-be-verified data element based on the dynamic weight factor, the data integrity proof, and the timestamp compliance proof to obtain a verification result of the to-be-verified data element, wherein the calculation formula of the verification result is as follows:

[0141]

[0142] In the formula, V is the verification result, sigma is a Sigmoid activation function, n is the total number of the verification nodes, j is the serial number of the verification node, w j is the dynamic weight factor of the jth node, I j is the data integrity proof quantization value of the jth node, T j is the timestamp compliance proof quantization value of the jth node.

[0143] When the verification result is greater than a verification threshold, it is determined that the to-be-verified data element is verified.

[0144] Specifically, the verification node of the production management platform broadcasts the to-be-verified data element through a special communication network between nodes, and adds the identification number (composed of 8 digits) and the broadcast time (in the format of “HHMMSS”) of the node itself in the head of the data element when broadcasting. When the verification node detects that the to-be-verified data element sent by itself has been successfully sent to the communication network (i.e., receiving the “sending success” confirmation signal of the network feedback), it immediately triggers the verification request of itself; the verification request contains the unique identification (composed of the serial number and the device-time composite identification when the data element is generated) of the to-be-verified data element, the identification number of the verification node, and the request initiation time, and is stored in the verification task queue of the node after being generated, waiting for subsequent processing.

[0145] Furthermore, after generating a verification request, the verification node verifies the data primitives in the queue to be verified: the data integrity proof is generated by checking whether the integrity characteristic value of the data primitive header to be verified is consistent with the recalculated characteristic value. During the recalculation, the steps of "extracting the content of the basic verification data block → grouping by every 8 characters → circular shift → character replacement" are followed. If the two characteristic values ​​are exactly the same, a text proof of "integrity verification passed" is generated, and the calculation time is attached. The timestamp compliance proof is generated by checking whether the time portion of the device-time composite identifier in the data primitive to be verified is within the range of ±5 minutes of the current system time (the current system time is obtained from the platform timing module). If it is within the range, a text proof of "timestamp compliance" is generated, and the inspection time is attached. The receiving module of the production management platform receives the two certificates returned by the verification node through an encrypted communication channel (using the current encryption key for data transmission encryption). After receiving the certificates, the certificates are associated with the corresponding unique identifier of the data primitive to be verified and stored in the verification result database.

[0146] Furthermore, when aggregating data integrity proof and timestamp compliance proof, first retrieve the two proofs corresponding to the same data primitive to be verified from the verification result database, and check whether the status of both is "passed" (that is, the integrity proof shows "integrity verification passed" and the timestamp proof shows "timestamp compliance"); for the data primitive to be verified that passes the check, extract the basic verification data block it contains, and add a "verification passed" status identifier to the header of the data block (composed of "PASS" and the verification completion time, such as "PASS202507221530"); arrange all the basic verification data blocks that have passed the verification in sequence according to the serial number of the original data block (the segment serial number assigned when the initial data block is generated) to form an ordered data block combination. This combination is the verification passed data block set of the original production data.

[0147] Specifically, the historical records of the verification node are stored in the node behavior database of the production management platform. Each record contains five fields: verification time, verification object identifier, judgment result (marked as "correct" or "wrong"), request reception time, and return result time. Only records from the past 30 days are retained (records older than 30 days are automatically deleted). When extracting the accuracy rate, all records of the node in the past 30 days are filtered from the database, and the number of records with the "judgment result" field as "correct" is counted. Then, the number is divided by the total number of records of the node in the past 30 days (number of correct records + number of wrong records). The value obtained is rounded to two decimal places, which is the accuracy rate (for example, there were 200 verifications in the past 30 days, of which 178 were correct, and the accuracy rate is 178 ÷ 200 = 0.89). When extracting the response delay score, first calculate the response delay of each record (result return time minus request reception time, in seconds) and then convert it into a score based on the preset standard: response delay ≤ 1 second corresponds to 100 points, 1 second < response delay ≤ 3 seconds corresponds to 80 points, 3 seconds < response delay ≤ 5 seconds corresponds to 60 points, and response delay > 5 seconds corresponds to 40 points. The score of all records in the node in the past 30 days is summed up and divided by the total number of records. The average value obtained, rounded to one decimal place, is the response delay score (for example, the total score of 200 records is 16,500 points, and the response delay score is 16,500 ÷ 200 = 82.5 points).

[0148] Furthermore, when the accuracy rate and response delay score are combined into a credibility coefficient, a fixed ratio is used for calculation: credibility coefficient = accuracy rate × 60% + response delay score × 40% (this ratio is determined based on the preset rule that "accuracy has a greater impact on verification reliability"), and the calculation result is rounded to two decimal places (for example, if the accuracy rate is 0.89 and the response delay score is 82.5 points, the credibility coefficient = 0.89 × 60 + 82.5 × 0.4 = 53.4 + 33 = 86.40). When normalizing the dynamic weight factor, the credibility coefficient is divided by 100 (because the maximum value of the credibility coefficient is 100), and the resulting value is rounded to three decimal places, with a range strictly controlled between 0 and 1 (for example, 86.40 ÷ 100 = 0.864). This value is the dynamic weight factor and is synchronously stored in the node weight cache.

[0149] Furthermore, when consensus verification is performed based on the dynamic weight factor, data integrity proof, and timestamp compliance proof, the quantitative values ​​of the two proofs are first determined: when the data integrity proof passes (the integrity characteristic value of the data primitive to be verified is consistent with the recalculated result), it is quantified as 100 points, and when it fails (the characteristic value is inconsistent), it is quantified as 0 points; when the timestamp compliance proof passes (the timestamp of the data primitive to be verified is within the current system time ±5 minutes, and the format complies with "YYYYMMDDHHMMSS"), it is quantified as 100 points, and when it fails (out of the time range or the format is wrong), it is quantified as 0 points. The verification result is then calculated according to a fixed formula: Verification result = dynamic weight factor × (quantized value of data integrity proof × 70% + quantitative value of timestamp compliance proof × 30%) (the ratio of 70% and 30% is based on the rule setting of "data integrity is more important than time compliance"), and the result is rounded to two decimal places (for example, dynamic weight factor 0.864, data integrity proof 100 points, timestamp compliance proof 100 points, verification result = 0.864 × (100 × 0.7 + 100 × 0.3) = 0.864 × 100 = 86.40).

[0150] Furthermore, the verification threshold is a fixed value of 80 points set by the production management platform during system initialization (this value is determined through 1,000 simulation verification tests and can cover 99% of normal data verification scenarios). It is stored in the verification rule configuration file and cannot be modified at will. When the verification result of the data element to be verified is greater than 80 points (for example, the verification result is 86.40 points>80 points), the system immediately records the identification, verification time and "pass" status of the data element in the verification result log, and triggers the subsequent data storage process; at the same time, the verification result is synchronized to the platform's consensus result dashboard for administrators to view.

[0151] Specifically, V is the verification result of the data primitive to be verified, which comes from the comprehensive calculation of the dynamic weight factors of all verification nodes, the quantitative value of the data integrity proof, and the quantitative value of the timestamp compliance proof; σ is the Sigmoid activation function, which converts the calculation result into a value between 0 and 1. The specific operation is achieved through a specific numerical conversion rule (mapping the input value to the 0-1 interval, the larger the value, the closer to 1, and the smaller the value, the closer to 0); n is the total number of verification nodes, which is pre-configured by the production management platform and stored in the node management module. For example, if the platform sets 5 verification nodes, n is 5; j is the serial number of the verification node, which is assigned in sequence starting from 1 according to the order in which the nodes are connected to the platform, and each node corresponds to a unique serial number; w j is the dynamic weight factor of the jth node, which is obtained by fusing and normalizing the accuracy and response delay scores in the node's history records; I j is the data integrity proof quantization value of the jth node, which is 1 when the node determines that the integrity check of the data primitive to be verified passes, and 0 when it fails; Tj It is the quantitative value of the timestamp compliance proof of the j-th node. It is 1 when the node determines that the timestamp of the data primitive to be verified meets the preset rules, and 0 when it fails.

[0152] Furthermore, the meaning of the formula is to calculate the final verification result of the data primitive to be verified by comprehensively analyzing the judgment results of all verification nodes. First, the dynamic weight factor of each node is multiplied by the sum of the quantitative value of the data integrity proof and the quantitative value of the timestamp compliance proof given by the node, and then the product results of all nodes are added together. The resulting sum is converted into a value between 0 and 1 through the Sigmoid activation function. This value is the verification result; the dynamic weight factor reflects the credibility of the node. The higher the weight of the node, the greater the impact on the final result. The quantitative values ​​of data integrity and timestamp compliance directly reflect the node's judgment on the data. The combination of the two realizes verification based on node consensus, which takes into account both the compliance of the data itself and the credibility of the node.

[0153] Furthermore, when more verification nodes determine the data integrity and timestamp compliance (i.e. j and T j The number of nodes with a value of 1 increases), and the dynamic weight factors of these nodes w j When it is larger, the sum of the products of all nodes will increase, and the verification result V after the Sigmoid activation function conversion will be close to 1; when most nodes determine that the data is non-compliant (I j and T j When there are many nodes with a value of 0) or when high-weight nodes are judged as non-compliant, the sum of products will decrease and the verification result V will approach 0. When the total number of verification nodes n is fixed, the influence of a single node is determined by its dynamic weight factor. Nodes with high weights have a more obvious pulling effect on the results, while nodes with low weights have a weaker influence. Overall, the verification results will change with the judgment trend of the majority of high-weight nodes.

[0154] In general, the consensus verification mechanism verifies data primitives through multiple verification nodes, which can effectively filter out data blocks with integrity defects or timestamp anomalies.

[0155] In general, the verification process combines the node's accuracy and response delay score to generate a dynamic weight factor, and quantitative verification is performed based on this factor and data integrity and timestamp compliance proof, ensuring the objectivity and reliability of the verification results, and providing a high-quality data foundation for subsequent storage from the data validity level.

[0156] In general, the results of consensus verification directly form a set of verified data blocks. The data blocks in this set have undergone multi-dimensional verification, and their integrity, compliance and authenticity are fully guaranteed.

[0157] In general, this verification method avoids the risks of omissions or misjudgments that may exist in single-node verification. At the same time, it clarifies the verification standards through quantitative formulas, improves the standardization and operability of the verification process, and provides key support for the subsequent aggregation, storage and safe use of production data.

[0158] The data storage module 105 is used to aggregate the verified data block set to obtain a complete ciphertext data set of the original production data, and store the complete ciphertext data set in the blockchain network.

[0159] In an embodiment of the present invention, when the data storage module aggregates the set of verified data blocks to obtain a complete ciphertext data set of the original production data, it is specifically configured to:

[0160] Arranging the data blocks in the verified data block set in order of timestamps to obtain a time series data sequence of the original production data;

[0161] performing redundancy elimination processing on the time series data sequence;

[0162] An aggregate check code is added to the time series data sequence after redundancy elimination processing to obtain a complete ciphertext data set of the original production data.

[0163] When the data storage module stores the complete ciphertext data set in the blockchain network, it is specifically used to:

[0164] Constructing the complete ciphertext data set into a Merkle tree structure and generating a root hash value;

[0165] A new blockchain block header for the original production data based on the creation of the root hash value and timestamp of the Merkle tree structure;

[0166] Writing the new blockchain block header into the blockchain main chain to obtain the blockchain node network of the original production data;

[0167] The complete ciphertext data set is distributed and stored in the blockchain node network.

[0168] Specifically, it is verified that each data block in the data block set has been attached with a device-time composite identifier when it was generated. This identifier contains the timestamp corresponding to the current timing service time (in the format of "YYYYMMDDHHMMSS"). When arranging these data blocks in timestamp order, first extract the timestamp string from the device-time composite identifier of each data block and convert it into a comparable digital form (such as "20250722103000" is converted to the number "20250722103000"); then arrange the timestamp numbers of all data blocks in ascending order, and rearrange the corresponding data blocks in the same order; after the arrangement is completed, add a sequence number to each data block (starting from 1 and increasing), forming a structured sequence of "sequence number + timestamp + data block content", which is the time series data sequence of the original production data.

[0169] Furthermore, redundant data in a time series data sequence refers to data blocks with exactly the same content and timestamps less than 5 minutes apart (same content means that the core data in the data blocks, excluding the timestamps, are completely identical). When performing redundancy elimination on a time series data sequence, the core data content and timestamps of adjacent data blocks are compared pairwise. If the core content of two data blocks is identical and the time stamp difference is less than 5 minutes (e.g., the first timestamp is "20250722103000" and the second is "20250722103300", with a time stamp difference of 3), the data blocks are determined to be redundant data. The data block with the earlier timestamp is retained, and the one with the later timestamp is deleted. The above comparison and deletion operations are repeated for the entire time series data sequence until no more data blocks that meet the redundancy criteria exist in the sequence. The resulting sequence is the time series data sequence after redundancy elimination.

[0170] Furthermore, the aggregate check code is generated by the core content of all data blocks in the time series data sequence after redundancy elimination. When generating, the core content of all data blocks is first spliced ​​into a continuous string in sequence; starting from the starting position of the string, every 16 characters are divided into a group, and each group of characters is cyclically shifted (the first 4 characters of each group are moved to the end), and then all the shifted characters are re-spliced; the first 32 characters of the spliced ​​string are taken as the aggregate check code; the aggregate check code is added to the end of the time series data sequence after redundancy elimination, and the identifier "#AGGCHK" is added before the aggregate check code; after the addition is completed, check whether the sequence structure is "time series data block (sorted by timestamp) + #AGGCHK + aggregate check code". After confirmation, the sequence is the complete ciphertext data set of the original production data.

[0171] Specifically, the complete ciphertext data set consists of multiple data blocks, each of which is a fixed-length string that has been encrypted and verified. When constructing the complete ciphertext data set into a Merkle tree structure, all data blocks are first numbered in sequence, with each data block serving as a leaf node of the Merkle tree. The data blocks of each leaf node are hashed (each character in the data block is converted to an ASCII code value, accumulated in sequence, and converted into a 32-bit hexadecimal string) to obtain the hash value of each leaf node. The hash values ​​of the leaf nodes are merged in groups of two, and each group of two hash values ​​is concatenated and hashed again to obtain the hash value of the parent node. If the number of leaf nodes is odd, the last hash value is concatenated with itself to calculate the hash value of the parent node. The above process of merging and calculating hashes is repeated, and the hash values ​​of nodes at higher levels are generated layer by layer until a unique top-level hash value is obtained. This top-level hash value is the root hash value of the Merkle tree structure.

[0172] Furthermore, the root hash value of the Merkle tree structure is a 32-bit hexadecimal string obtained by the above-mentioned layer-by-layer merging calculation, and the timestamp is the precise time obtained from the timing service when the current block is generated, in the format of "YYYYMMDDHHMMSS". When generating a new blockchain block header for the original production data, first determine the components of the block header, including the root hash value, timestamp, hash value of the previous block (extracted from the last block of the blockchain main chain), and block number (previous block number plus 1); concatenate this information in the order of "previous block hash value + root hash value + timestamp + block number" to form a string of fixed length; perform an integrity check on the string (check whether the splicing of each part is complete and whether the length meets the preset standard). The string obtained after the check is passed is the new blockchain block header for the original production data.

[0173] Furthermore, the blockchain main chain is a chain structure formed by sequentially connecting generated blocks, with each block containing a block header and a corresponding data index. When writing a new blockchain block header to the blockchain main chain, the block header of the last block is first obtained from the main chain to verify whether the hash value of the previous block in the new block header is consistent with the hash value of the block header. Once verified, the new block header is added to the end of the main chain, forming an association relationship with the previous block, where the "previous block hash value points to the new block header." After the main chain is updated, the new block header information is broadcast to all nodes in the blockchain network. After receiving it, each node verifies and stores the block header, forming a blockchain node network containing the new block, i.e., the blockchain node network of the original production data.

[0174] Furthermore, the complete ciphertext dataset has been divided into multiple data blocks, and each node in the blockchain node network has a unique node identifier and storage capacity information. When distributing the complete ciphertext dataset in the blockchain node network, the data blocks are first allocated according to the number of nodes and the number of data blocks, following the principle of "even distribution + redundant backup" (for example, 10 data blocks are allocated to 5 nodes, each node stores 2 data blocks, and each data block is additionally backed up to 1 other node); the allocated data blocks are sent to the corresponding nodes through the inter-node communication protocol. After receiving the data blocks, the nodes verify the integrity of the data blocks (comparing the data block hash value with the preset value); after verification, the nodes store the data blocks in a local encrypted storage area and record the storage location of the data blocks and the corresponding node identifier; after all data blocks are stored, the nodes in the network synchronize the storage information to ensure that any node can obtain the data blocks stored by other nodes through query, thus realizing the distributed storage of the complete ciphertext dataset.

[0175] In general, aggregation processing can integrate scattered valid data blocks by sorting verified data blocks by timestamp and eliminating redundancy, restore the complete logical structure of the original production data, and remove redundant information to optimize data storage efficiency.

[0176] In general, adding the aggregation check code further ensures the integrity and completeness of the complete ciphertext data set after aggregation, avoids data loss or tampering during the aggregation process, and provides a complete and reliable foundation for subsequent data calls and tracing.

[0177] In general, when storing a complete ciphertext dataset on a blockchain network, a Merkle tree is constructed to generate a root hash value and create a new blockchain block header. This is then distributed across the blockchain node network. Leveraging the blockchain's immutability and distributed accounting, this prevents data from being illegally modified or deleted. Furthermore, this distributed storage model avoids the single point of failure risk inherent in centralized storage, improves data storage's resilience to attacks, and provides long-term security for production management data from the final storage stage.

[0178] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0179] The embodiments of the present application can acquire and process relevant data based on network security technology. Network security is the theory, method, technology, and application system for using digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to achieve optimal results.

[0180] Finally, it should be noted that the above examples are merely intended to illustrate the technical solutions of the present application and not to limit the present application. Although the present application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application can be modified or equivalently replaced without departing from the spirit and scope of the technical solutions of the present application.

Claims

1. A data security-based management system, characterized in that: The system includes a key generation module, a data encryption module, a data block generation module, a data verification module and a data storage module, wherein: The key generation module is used to trigger the dynamic key update mechanism based on the production event type to obtain the current encryption key of the production management platform; The data encryption module is configured to encrypt the original production data of the production management platform using the current encryption key to obtain encrypted data of the original production data; The data block generation module is configured to divide the encrypted data into data blocks and append timestamps and device identifiers to the data blocks to obtain the data primitives to be verified of the original production data; The data verification module is used to perform consensus verification on the data primitives to be verified to obtain a set of verified data blocks of the original production data; The data storage module is used to aggregate the verified data block set to obtain a complete ciphertext data set of the original production data, and store the complete ciphertext data set in the blockchain network.

2. The data security management system according to claim 1, wherein: When the key generation module executes the dynamic key update mechanism triggered based on the production event type to obtain the current encryption key of the production management platform, it is specifically used to: Generate an initial key factor based on a preset key seed parameter; Constructing a dynamic key sequence of the production management platform based on the production event type occurring in the production management platform and the initial key factor; The current encryption key of the production management platform is selected from the dynamic key sequence.

3. The data security management system according to claim 2, characterized in that: When the key generation module constructs a dynamic key sequence of the production management platform based on the production event type occurring in the production management platform and the initial key factor, the key generation module is specifically used to: Parsing the event characteristic value of the production event type; Combining and encoding the event characteristic value and the occurrence time of the production event type to obtain a time-type sequence of the production event type; Mapping the time-type sequence and the hash value of the initial key factor into a message authentication code of the production management platform; Using the latest unused key in the message authentication code as the current encryption key of the production management platform; In a trusted execution environment, a historical key in the message authentication code is destroyed.

4. The data security management system according to claim 1, wherein: When the data encryption module encrypts the original production data of the production management platform using the current encryption key to obtain encrypted data of the original production data, it is specifically used to: Structurally reorganizing the original production data in the production management platform according to the formatted data specification to obtain standardized data blocks; Using the current encryption key to perform key grouping on the standardized data block to obtain an initial encrypted data block of the original production data; An integrity check code is added to the initial encrypted data block to obtain encrypted data of the original production data.

5. The data security management system according to claim 4, characterized in that: When the data encryption module performs key grouping on the standardized data block using the current encryption key to obtain the initial encrypted data block of the original production data, the data encryption module is specifically configured to: inputting the standardized data block into a counter mode encryption engine; A round function is iterated through the counter mode encryption engine, wherein the round function is as follows: C i =E k (P i ⊕CTR i ) Where C i is the ciphertext of the i-th standardized data block, E k is the current encryption key, P i is the i-th standardized data block, ⊕ is the XOR operation, CTR i is the counter mode vector; The ciphertexts are aggregated to obtain an initial encrypted data block of the original production data.

6. The data security management system according to claim 1, wherein: When the data block generation module executes the steps of dividing the encrypted data into data blocks and adding a timestamp and a device identifier to the data blocks to obtain the data primitives to be verified of the original production data, the module is specifically configured to: Cutting the encrypted data into data segments of equal length to obtain initial data blocks of the original production data; Extracting the physical address code and current timing service time of the production management platform to obtain the equipment-time composite identifier of the production management platform; Adding the device-time composite identifier to the initial data block to obtain a basic verification data block of the original production data; The data integrity characteristic value of the basic verification data block is embedded into the header of the corresponding basic verification data block to obtain the data primitive to be verified of the original production data.

7. The data security management system according to claim 1, wherein: When the data verification module performs consensus verification on the data primitives to be verified and obtains a set of verified data blocks of the original production data, it is specifically used to: When the verification node of the production management platform broadcasts the data primitive to be verified, triggering a verification request of the verification node; Receive the data integrity certificate and timestamp compliance certificate returned by the verification node; The data integrity proof and the timestamp compliance proof are aggregated to obtain a set of verified data blocks of the original production data.

8. The data security management system according to claim 7, wherein: When executing the data integrity certificate and timestamp compliance certificate returned by the verification node, the data verification module is specifically used to: Extracting the accuracy and response delay scores from the historical records of the verification node; fusing the accuracy rate and the response delay score into a credibility coefficient, and normalizing the credibility coefficient into a dynamic weight factor; Consensus verification is performed on the data primitive to be verified based on the dynamic weight factor, the data integrity proof, and the timestamp compliance proof to obtain a verification result of the data primitive to be verified, wherein the calculation formula of the verification result is as follows: Where V is the verification result, σ is the Sigmoid activation function, n is the total number of verification nodes, j is the serial number of the verification node, and w j is the dynamic weight factor of the jth node, I j The quantized value for the data integrity proof of the jth node, T j Quantize the timestamp compliance proof value of the jth node; When the verification result is greater than the verification threshold, the data element to be verified is determined to have passed the verification.

9. The data security management system according to claim 1, wherein: When the data storage module aggregates the verified data block set to obtain a complete ciphertext data set of the original production data, it is specifically configured to: Arranging the data blocks in the verified data block set in order of timestamps to obtain a time series data sequence of the original production data; performing redundancy elimination processing on the time series data sequence; An aggregate check code is added to the time series data sequence after redundancy elimination processing to obtain a complete ciphertext data set of the original production data.

10. The data security management system according to claim 1, wherein: When the data storage module stores the complete ciphertext data set in the blockchain network, it is specifically used to: Constructing the complete ciphertext data set into a Merkle tree structure and generating a root hash value; A new blockchain block header for the original production data based on the creation of the root hash value and timestamp of the Merkle tree structure; Writing the new blockchain block header into the blockchain main chain to obtain the blockchain node network of the original production data; The complete ciphertext data set is distributed and stored in the blockchain node network.

Images