Stable Industrial Data Storage Method Based on SD NAND Memory Chips

Abstract

This invention relates to the field of industrial data storage and information security technology, and discloses a method and system for stable industrial data storage based on SD NAND flash memory chips. The method encrypts and protects key fields of initial log screening files, triggers a dynamic verification mechanism under high-risk operation and abnormal fluctuation conditions, and completes identity verification by combining path parsing and hardware unique code verification; it then performs permission level division and determination to generate access permission results, dynamically adjusts access restriction rules for sensitive marked areas based on access data, obtains an updated permission control table, and achieves secure storage processing results. This invention effectively solves the problems of existing technologies being unable to achieve hardware-level permission control at the memory chip level and insufficient isolation protection for sensitive data, balancing the security, stability, and access flexibility of industrial data storage.

Description

Technical Field

[0001] This invention relates to the field of industrial data storage and information security technology, and in particular to a method and system for stable industrial data storage based on SD NAND memory chips. Background Technology

[0002] In the field of industrial data storage, data security and stability are crucial pillars for ensuring production operations and protecting core corporate interests. With the rapid development of the Industrial Internet, storage devices not only need to handle massive amounts of data but also must cope with security threats and data corruption risks in complex environments. However, many current storage solutions often struggle to balance data protection depth and access flexibility when facing complex industrial scenarios. Existing methods are limited to surface-level software encryption or permission settings, lacking security controls over the storage hardware itself. This makes them inadequate against physical attacks or system vulnerabilities, easily leading to unauthorized data access or tampering. Furthermore, access control for storage chips often lacks robust hardware-level constraints, allowing external attackers to bypass software restrictions and directly manipulate storage areas to obtain critical information.

[0003] In summary, existing technologies cannot achieve strict hardware-level control of permissions at the storage chip level, nor can they effectively isolate and protect sensitive data, making it difficult to balance the security, stability, and access flexibility of industrial data storage. Summary of the Invention

[0004] This invention provides a method and system for stable industrial data storage based on SD NAND storage chips, which solves the problems of existing technologies being unable to achieve strict hardware-level control of permissions at the storage chip level, and also unable to effectively isolate and protect sensitive data, making it difficult to balance the security, stability and access flexibility of industrial data storage.

[0005] In a first aspect, to solve the above-mentioned technical problems, the present invention provides a method for stable industrial data storage based on SD NAND memory chips, comprising:

[0006] Obtain a preliminary log filtering file, and encrypt and protect key fields according to the preliminary log filtering file to obtain encrypted access record data;

[0007] Based on the encrypted access record data, abnormal behavior markers and request interval fluctuation characteristics are analyzed to obtain the access request to be verified;

[0008] The path is parsed according to the access request to be verified to obtain the sensitive marked area. If the access path points to the sensitive marked area, hardware unique code verification is performed to obtain the verification result.

[0009] Based on the verification result, perform permission level division and determination, generate access permission result, and collect access failure records in the access permission result;

[0010] Integrate all access request path data, permission judgment data, and time data to generate path log information;

[0011] Based on the access permission results, the access failure records and the path log information are used to adjust the access restriction rules of the sensitive marked area to obtain the updated permission control table;

[0012] The data read and write operations of the storage chip are processed according to the updated permission control table. When the access path points to the sensitive marked area and the hardware encoding verification passes, the operation is allowed to be executed, and a secure storage processing result is obtained.

[0013] Secondly, the present invention provides an industrial data stable storage system based on SD NAND memory chips, comprising:

[0014] The log encryption module is used to obtain a preliminary log filtering file, and to encrypt and protect key fields according to the preliminary log filtering file to obtain encrypted access record data.

[0015] The request filtering module is used to parse the abnormal behavior markers and request interval fluctuation characteristics based on the encrypted access record data to obtain the access requests to be verified.

[0016] The hardware verification module is used to perform path parsing based on the access request to be verified, obtain sensitive marked areas, and perform hardware unique code verification if the access path points to the sensitive marked areas to obtain the verification result.

[0017] The permission determination module is used to perform permission level division determination based on the verification result, generate access permission result, and collect access failure records in the access permission result;

[0018] The log generation module is used to integrate path data, permission judgment data, and time data of all access requests to generate path log information;

[0019] The rule update module is used to adjust the access restriction rules of the sensitive marked area according to the access permission result, the access failure record and the path log information, so as to obtain the updated permission control table;

[0020] The read / write execution module is used to process data read / write operations on the storage chip according to the updated permission control table. When the access path points to the sensitive marked area and the hardware encoding verification passes, the operation is allowed to be executed, and a secure storage processing result is obtained.

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

[0022] (1) This invention performs multi-dimensional monitoring of the frequency peak and time distribution pattern of memory chip access requests, combined with key field encryption protection, to complete the identification of abnormal access behavior and the encryption protection of sensitive data.

[0023] (2) The present invention triggers a dynamic verification mechanism by parsing the abnormal behavior markers and request interval fluctuation characteristics, and combines path parsing and hardware unique code verification to complete hardware-level identity verification and permission determination for high-risk access requests.

[0024] (3) The present invention dynamically adjusts the access rules of sensitive areas by access permission results and access log data, and performs read and write control of storage chips in combination with the updated permission control table, thereby completing hardware-level isolated storage and secure read and write control of industrial data. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the process of a stable industrial data storage method based on SD NAND storage chips provided in the first embodiment of the present invention;

[0026] Figure 2 This is a schematic diagram of an industrial data stable storage system based on SD NAND memory chips provided in the second embodiment of the present invention. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] Reference Figure 1 The first embodiment of the present invention provides a method for stable industrial data storage based on SD NAND memory chips, comprising the following steps:

[0029] S101, Obtain the preliminary log filtering file, and perform encryption protection processing on the key fields according to the preliminary log filtering file to obtain encrypted access record data;

[0030] S102, based on the encrypted access record data, analyze the abnormal behavior markers and request interval fluctuation characteristics to obtain the access request to be verified;

[0031] S103, perform path parsing according to the access request to be verified to obtain the sensitive marked area. If the access path points to the sensitive marked area, perform hardware unique code verification to obtain the verification result.

[0032] S104, Perform permission level division and determination based on the verification result, generate access permission result, and collect access failure records in the access permission result;

[0033] S105, integrates all access request path data, permission judgment data and time data to generate path log information;

[0034] S106, Based on the access permission result, the access failure record and the path log information, adjust the access restriction rules of the sensitive marked area to obtain the updated permission control table;

[0035] S107, the data read and write operations of the storage chip are processed according to the updated permission control table. When the access path points to the sensitive marked area and the hardware encoding verification is passed, the operation is allowed to be executed, and a secure storage processing result is obtained.

[0036] It should be noted that d stands for day, which is an abbreviation for the unit "day", and h stands for hour, which is an abbreviation for the unit "hour".

[0037] It is worth noting that the hardware-level access control of this invention is implemented based on the hardware encryption engine and partition protection registers built into the SD NAND storage chip. The SD NAND chip is internally divided into three main hardware partitions: a normal data partition, an independent log partition, and a secure encryption partition. The secure encryption partition is used to deploy a secure database and core verification program. The read and write permissions of the partition are locked through the chip's built-in hardware protection registers. Only the chip's built-in hardware encryption engine can initiate access requests; external software interfaces and the system bus cannot directly access it.

[0038] The linkage mechanism between hardware-level access control and software access control tables is as follows: after the updated access control table is generated, it is written to the hardware protection register through the chip's dedicated firmware configuration interface. The register locks the read and write permissions of the hardware partitions corresponding to the sensitive marked areas according to the rules of the access control table. Only when the access request passes the hardware unique code verification and permission level verification will the hardware encryption engine unlock the access permissions of the corresponding partition, intercepting access requests that fail the verification at the physical bus level, thus realizing hardware-level access control.

[0039] In step S101, a preliminary log filtering file is obtained, and key fields are encrypted and protected according to the preliminary log filtering file to obtain encrypted access record data, including:

[0040] Real-time access request data is collected through the storage chip access interface;

[0041] The real-time access request data is monitored in multiple dimensions to obtain the peak request frequency and time distribution pattern;

[0042] If the peak frequency of the request exceeds the preset frequency range or the time distribution pattern does not match the preset typical pattern, then an abnormal behavior marker is added to the real-time access request data.

[0043] Based on the abnormal behavior markers, metadata is extracted from the corresponding access requests, and the metadata is integrated with the abnormal behavior markers to generate a preliminary log filtering file;

[0044] Extract information on sudden changes in access data volume from the preliminary log screening file;

[0045] The access data volume mutation information is compared with a preset mutation threshold to filter out excessive access records that exceed the preset mutation threshold.

[0046] Extract the source address classification information from the over-access record as a key field, and encrypt the key field to generate a ciphertext string;

[0047] The encrypted access record data is obtained by replacing the key field with the ciphertext string and reorganizing the log structure.

[0048] It should be noted that real-time access request data collection is performed through an embedded monitoring module, with a collection frequency of once per second. The collected request data is stored in a temporary cache with a size of 10MB. Data in the temporary cache is retained for 24 hours; data exceeding this retention period is automatically deleted. Expired data is cleaned up once per hour. Every minute, the total number of all access requests collected within that minute is tallied, generating the corresponding minute's request frequency data point.

[0049] It is worth noting that the threshold of 30% for abnormally high-frequency requests during off-peak hours was determined based on baseline data from typical operating scenarios of industrial controllers. Statistical analysis of 30 consecutive days of normal operation data from 1000 industrial controllers showed that the proportion of abnormally high-frequency requests during off-peak hours was consistently below 15%. When the proportion exceeded 30%, the accuracy rate for identifying unauthorized access reached 98.2%, with a false positive rate below 0.5%. Therefore, 30% was set as the judgment threshold.

[0050] The metadata of the access request includes the request source address, request time, request data volume, and request operation type. The initial log filtering file has a single file size limit of 1MB. Files exceeding this limit are automatically split into chunks for storage. Each chunk has a single file size limit of 1MB, and chunk files are named by associating them with the same source file name plus a sequence number suffix.

[0051] It should be noted that the preset mutation threshold is set to 3 times the average access data volume. This multiple is determined based on the data read and write patterns in industrial scenarios. The fluctuation in access data volume during a single period in normal industrial operations should not exceed 2 times the average. When it exceeds 3 times, high-risk behaviors such as batch export and abnormal copying can be reliably identified, while avoiding false judgments triggered by normal business fluctuations. The average access data volume is taken as the arithmetic mean of the access data volume in the same hourly period within the most recent 7 days. The preset mutation threshold is updated synchronously every 7 days with the average access data volume.

[0052] It is worth noting that over-access records are stored in ascending order of timestamps for a period of 30 days. Over-access records that exceed the storage period are automatically deleted and cleaned up once a day. Over-access records are stored in a separate log partition of the storage chip, physically isolated from regular access logs.

[0053] It should be noted that the source address classification information from all over-the-top access records is extracted as a key field, and encryption is performed on this key field. The encryption process uses the CBC working mode of the AES-256 algorithm, simultaneously generating a 256-bit encryption key and a 128-bit initialization vector. Both the encryption key and initialization vector are stored in an independent secure database. This secure database is read-only accessible only to the core encryption and decryption modules. The encryption key is automatically updated every 30 days, triggered at midnight on the first day of each month. During the update, a true random number generator is used to generate a new 256-bit encryption key and a 128-bit initialization vector, simultaneously updating the key mapping relationship in the encryption index table. The old key is retained for 180 days for decryption of historical encrypted data; after the retention period expires, it is completely destroyed through overwriting.

[0054] The secure database is deployed in the secure encrypted partition of the SD NAND chip and is fully encrypted using the chip's hardware encryption engine. The database contains four core data tables: First, the device permission table, which stores the binding relationship between hardware identifiers and corresponding permission levels, with fields including hardware identifier hash value, permission level, effective time, and expiration time; second, the key management table, which stores historical encryption keys, initialization vectors, generation time, and expiration time; third, the legitimate device registry, which stores device hardware binding information, registration time, and device status; and fourth, the permission rule table, which stores the mapping relationship between sensitive marked areas and their corresponding minimum permission requirements. Access control for the secure database is implemented through chip hardware. Only the chip's built-in core verification module can access it via the on-chip bus. All external software interfaces cannot directly read or modify the database content; operations can only be performed based on the verification results returned by the core verification module.

[0055] It's worth noting that the ciphertext string generated after encryption is in hexadecimal format and is 64 bytes long. The mapping relationship between key fields and their corresponding ciphertext strings is stored in an encryption index table. This encryption index table is stored separately from the subsequently generated encrypted access record data, residing in two independent physical partitions. Access to the encryption index table is only granted to the core module, and it is updated synchronously with each encryption operation.

[0056] It's worth noting that after the encrypted access log data is generated, a corresponding SHA-256 hash checksum is generated simultaneously. This hash checksum is used for data integrity verification before subsequent decryption operations. The hash checksum and the encrypted access log data are stored together in the target database, which has a capacity of 500MB. When the database occupancy reaches 90%, the earliest generated encrypted access log data is automatically migrated to the cold storage area, and migration stops when the database occupancy drops to 75%. Data in the cold storage area is retained for a maximum of 180 days; data exceeding this retention period is automatically cleaned up.

[0057] For example, in the application scenario of industrial controller SD NAND storage chips, a preliminary log filter file is read in chronological order of acquisition time, and 1000 abnormal request records are obtained by parsing them one by one. The cumulative access data volume corresponding to each IP address range within a single hour is extracted to generate access data volume mutation information. The average access data volume for the same hour within the last 7 days is statistically determined to be 10MB / h, and the preset mutation threshold is set to 30MB / h. All access data volume mutation information is compared with the preset mutation threshold, and records exceeding the access data volume of 50MB / h are filtered out. Twenty unique IP addresses in the records exceeding the access volume are extracted as key fields. The CBC working mode of the AES-256 algorithm is used to encrypt each of the 20 IP addresses, and a 256-bit encryption key and a 128-bit initialization vector are generated simultaneously. After encryption, a corresponding 64-byte hexadecimal ciphertext string is generated. A mapping relationship between the original IP address and the corresponding ciphertext string is constructed and stored in an encryption index table, which is stored in an independent physical partition. The source address category information field in the original log is replaced with the corresponding ciphertext string. The log structure is reconstructed and consistency verification is performed to obtain the encrypted access record data. A SHA-256 hash checksum corresponding to the encrypted access record data is generated. The encrypted access record data and the hash checksum are stored together in the target database. At this point, the database occupancy rate is less than 90%, so there is no need to perform a cold storage migration operation.

[0058] In step S102, based on the abnormal behavior markers and request interval fluctuation characteristics parsed from the encrypted access record data, the access request to be verified is obtained, including:

[0059] The encrypted access record data is decrypted to extract the abnormal behavior markers and access trajectory data in plaintext form;

[0060] The time interval between adjacent access requests is calculated based on the access trajectory data to obtain the request interval fluctuation characteristics;

[0061] The fluctuation characteristics of the requested interval are compared with historical benchmark data to obtain the fluctuation amplitude deviation.

[0062] If the abnormal behavior is marked as a high-risk operation and the fluctuation range deviates beyond a preset deviation threshold, a dynamic verification mechanism is triggered.

[0063] The dynamic verification mechanism filters out the corresponding access requests to obtain the access requests to be verified.

[0064] It should be noted that for encrypted access log data, the corresponding SHA-256 hash checksum is first verified. If the verification passes, decryption is performed. The decryption process uses the AES-256 algorithm CBC working mode corresponding to the encryption process, retrieving the corresponding decryption key and initialization vector from the encryption index table. The decryption process is executed independently for each log record, and the decryption processes for different log records are independent of each other.

[0065] It should be noted that abnormal behavior markers and access trajectory data are extracted from the decrypted plaintext logs. The access trajectory data includes the timestamp, operation type, and data volume of each access request. Access requests are grouped according to the same source address, and the access requests within each group are sorted in ascending order by timestamp. The time interval between two adjacent access requests is calculated, and the calculation result is kept to the millisecond level of precision, thus obtaining the request interval fluctuation characteristics for the corresponding source address.

[0066] It should be noted that the historical comparison benchmark data is the arithmetic mean and standard deviation of request interval data from the same source address within the same hourly time period over the most recent 7 days. The fluctuation range deviation is the ratio of the standard deviation of the request interval within the current statistical window to the standard deviation of the historical comparison benchmark.

[0067] It is worth noting that the preset deviation threshold is set to 2.0, which is determined based on the baseline fluctuation of the time interval of normal industrial access. In normal industrial scenarios, the standard deviation fluctuation of the interval of device access requests does not exceed 1.5 times the historical benchmark; when the fluctuation exceeds 2.0, the identification accuracy of brute-force attacks and automated scanning attacks reaches 97.6%, so 2.0 is set as the trigger threshold.

[0068] High-risk operations include system configuration modifications, batch data exports, and firmware updates. Abnormal behavior flags include an operation type identifier, which is derived from the request operation type in the access request metadata. The operation type identifier is used to determine whether the corresponding access request is a high-risk operation. A dynamic verification mechanism is triggered only when both the abnormal behavior flag is a high-risk operation and the fluctuation range deviates beyond a preset deviation threshold are met simultaneously.

[0069] It's worth noting that the access requests selected through the dynamic verification mechanism are designated as access requests to be verified. These requests are sorted in ascending order by timestamp and stored in a verification queue. The verification queue is stored in a temporary cache with a maximum length of 100 entries. When the maximum length is exceeded, the oldest access request is automatically deleted. The trigger records for the dynamic verification mechanism are stored in a separate log partition for 30 days. Records exceeding this storage period are automatically deleted and cleaned up, with the cleanup operation occurring once per day.

[0070] In step S103, path parsing is performed based on the access request to be verified to obtain a sensitive marked area. If the access path points to the sensitive marked area, hardware unique encoding verification is performed to obtain the verification result, including:

[0071] Extract the resource locator from the access request to be verified, and decompose the resource locator according to the preset path parsing rules to obtain the directory hierarchy sequence;

[0072] The directory hierarchy sequence is matched with the preset sensitive area identifier to obtain the access path. If the access path points to the sensitive marked area, the MAC address and device serial number of the request source device are extracted.

[0073] Feature extraction is performed on the MAC address and the device serial number to obtain hardware binding information;

[0074] The hardware binding information is compared with the pre-stored legitimate device registration data to obtain the verification result.

[0075] Resource locators are extracted from the access request to be verified, and preprocessing is performed on the extracted resource locators. Preprocessing employs a whitelist character filtering mechanism, covering uppercase and lowercase English letters, numbers, forward slashes, underscores, hyphens, and periods. All special characters and escape characters not within the whitelist are filtered out. Filtering operations are performed character by character in order, with a single processing time not exceeding 1ms. Simultaneously, path format unification is performed during preprocessing: all English characters are converted to lowercase, relative path formats are converted to absolute path formats corresponding to the storage partition, multiple consecutive forward slashes are merged into a single forward slash, and redundant forward slashes at the end of the path are removed. The format unification rules are based on the POSIX path standard commonly used in industrial controllers, adapting to the storage path formats of over 99% of embedded Linux systems in industrial scenarios. After preprocessing, the total path length is checked synchronously. Requests with a total path length exceeding 256 bytes are marked with an abnormal behavior flag. This length threshold is determined based on the storage path design specifications for industrial scenarios. The storage path length for normal industrial business does not exceed 128 bytes. 98.7% of paths exceeding 256 bytes are path traversal attack requests. This data comes from the statistical results of attack samples from 1,000 industrial controllers over 30 consecutive days.

[0076] The preprocessed resource locators are hierarchically decomposed according to preset path resolution rules. These rules use forward slashes as path hierarchy separators, performing hierarchical decomposition from left to right. Decomposition begins at the first forward slash of the path, and each forward slash completes one hierarchy segment. Each segment of consecutive characters is treated as an independent directory hierarchy unit. The decomposition process automatically skips empty units corresponding to the root directory forward slash at the beginning of the path. Hierarchical fragment validity is simultaneously verified during decomposition. Directory hierarchy units exceeding 64 bytes in length are flagged as abnormal behavior. This threshold is determined based on industrial directory naming conventions; normal business directory names do not exceed 32 bytes, and 97.2% of directory names exceeding 64 bytes are maliciously constructed attack payloads. After decomposition, all valid directory hierarchy units are sequentially arranged from left to right, generating a directory hierarchy sequence. Each element in the sequence corresponds to a first-level directory in the path, and the sequence length corresponds to the total number of directory levels in the path. After generating the directory hierarchy sequence, a sequence compliance check is performed. Requests with a sequence hierarchy exceeding 16 levels are directly marked with an abnormal behavior flag. This threshold is determined based on the file system hierarchy limit of the SD NAND storage chip and the business path design specifications for industrial scenarios. The storage path hierarchy of normal industrial business does not exceed 8 levels. Paths exceeding 16 levels are 99.1% of path traversal attack requests.

[0077] The validated directory hierarchy sequence is matched against preset sensitive area markers. The matching process consists of two stages: prefix quick matching and full path precise matching. Prefix quick matching is performed first. Following the directory hierarchy sequence from left to right, the first two levels of directory hierarchy units are taken and concatenated to form a path prefix string. A forward slash is added as a separator between the two levels of units. The concatenated string is then compared one by one with the sensitive area path prefixes stored in the permission rules table, using a character-by-character exact match rule. Prefix quick matching can reduce the matching time for a single request to less than 50µs. Based on statistics from 30 consecutive days of access logs from 1000 industrial controllers, the first two levels of directory prefixes can identify 99.8% of sensitive area access requests, with a false negative rate of less than 0.2%. If there is no match for the first two levels of prefixes, the access path is determined not to point to a sensitive marked area, and the matching process terminates directly. If the prefix matching passes, the process proceeds to the full path precise matching stage.

[0078] In the full-path precise matching process, for directory hierarchy sequences that pass prefix matching, a full match is performed between the complete hierarchical order and the complete path range of the corresponding sensitive area identifier. The matching rules are divided into two categories: the first is fixed complete path matching, targeting sensitive areas with fixed paths such as firmware partitions and security database partitions. This requires that each level of the directory hierarchy sequence completely match the directory hierarchy of the preset sensitive area identifier. When the matching degree reaches 100%, the path is determined to point to the sensitive area. The second is directory range matching, targeting sensitive areas containing subdirectories such as production data and process parameters. This requires that the first N levels of the directory hierarchy sequence completely match the directory hierarchy of the preset sensitive area identifier, where N is the total number of directory levels of the preset sensitive area identifier. When the matching degree reaches 100%, the path is determined to point to that sensitive area, and the subdirectory level automatically inherits the sensitivity level and control rules of the parent directory. After the matching is completed, the sensitivity level, resource sensitivity coefficient and minimum permission requirement corresponding to the successfully matched sensitive area identifier are taken as the corresponding parameters of this access path. If a single access path matches multiple sensitive area identifiers at the same time, the set of parameters with the highest sensitivity level and the largest resource sensitivity coefficient is taken as the final result.

[0079] After determining that the access path points to a sensitive marked area, the MAC address and device serial number of the requesting device are immediately extracted. The data sources are divided into two categories: the first is Ethernet access requests, where the source MAC address is extracted from the Layer 2 frame header of the request message, and the device serial number field is extracted from the application layer request header; the second is local bus access requests, where the MAC address and device serial number of the local device are extracted from the device descriptor of the on-chip bus. The extracted MAC address is first standardized by removing all hyphens and colons, converting it to a continuous lowercase hexadecimal string, and verifying that the string length is 12 bits; strings exceeding this length are directly considered invalid hardware information. The extracted device serial number is also standardized by removing all non-alphanumeric special characters, converting it to uppercase English characters, and verifying that the serial number length is between 8 and 32 bits; strings exceeding this length are directly considered invalid hardware information. The length threshold is based on the general specifications for industrial Ethernet devices. MAC addresses conforming to the IEEE 802.3 standard are standardized to a fixed 12-bit hexadecimal character. The general length range of industrial controller device serial numbers is 8 to 32 bits. Information exceeding this range is 99.3% of forged hardware identifiers. The data comes from the statistical results of illegal access samples from 1000 industrial controllers over 30 consecutive days.

[0080] Preprocessing is performed on MAC addresses and device serial numbers that pass length verification, including three steps: format standardization, character set normalization, and invalid character removal. In the format standardization step, all letter characters in the MAC address string are converted to uppercase. If the length is less than 12 hexadecimal characters, it is padded to 12 characters with zeros at the end; if the length exceeds 12 characters, the first 12 characters are truncated. All letter characters in the device serial number string are converted to uppercase, retaining numeric characters and uppercase letters while removing spaces, hyphens, underscores, and other non-numeric and non-alphanumeric symbols. In the character set normalization step, the format-standardized MAC address string and device serial number string are converted to UTF-8 encoded byte sequences. In the invalid character removal step, the UTF-8 encoded byte sequences are checked, and invisible control characters with byte values ​​from 0x00 to 0x1F and 0x7F are removed, retaining the bytes corresponding to printable characters.

[0081] The preprocessed byte sequence is used for feature extraction using the SHA-256 one-way hash algorithm. Hash operations are performed on the MAC address byte sequence and the device serial number byte sequence respectively, generating a 32-byte (256-bit) hash value for each. The hash result of the MAC address is used as the first part, and the hash result of the device serial number is used as the second part. These two parts are concatenated to obtain 64 bytes of hardware binding information. The concatenation order is fixed: the first 32 bytes come from the MAC address hash value, and the last 32 bytes come from the device serial number hash value. The real-time generated hardware binding information is compared byte-by-byte with the legitimate device registration data pre-stored in the security database. The percentage of matching bytes is calculated as the matching degree. When the matching degree reaches 95% or higher, the hardware identifier is considered to be incompatible, and a verification result of passing the verification is generated; when the matching degree is lower than 95%, the hardware identifier is considered to be inconsistent, and a verification result of failing the verification is generated. The 95% matching threshold is set based on the tolerance for occasional character disturbances during network transmission or hardware reading in the preprocessing stage before hash calculation. After hash comparison tests on 1000 sets of raw MAC address and serial number data collected multiple times from the same device, the lowest matching degree for hardware binding information collected multiple times from the same device was 97.8%, and the highest matching degree for different devices was 41.3%. The verification results include the hardware identifier matching status and matching degree value, and are stored in an independent log partition in ascending order of access request timestamps for a storage period of 30 days. Verification results exceeding the storage period are automatically deleted and cleaned up, with the cleanup operation performed once per day.

[0082] In step S104, permission level division and determination are performed based on the verification result, an access permission result is generated, and access failure records in the access permission result are collected, including:

[0083] Extract the hardware identifier matching status from the verification result. If the hardware identifier matching status is consistent, retrieve the preset permission level corresponding to the hardware identifier.

[0084] The preset permission level is compared with the minimum permission requirements of the target sensitive resource to generate an initial access permission result.

[0085] It should be noted that the hardware identifier matching status is divided into two categories: consistent and inconsistent. When the matching status is inconsistent, a final access permission result of denying access is directly generated. Only when the matching status is consistent, the preset permission level of the corresponding hardware identifier is retrieved to perform subsequent permission level determination.

[0086] The system maps preset permission levels to numerical permission level values. There are five permission levels, from 1 to 5, corresponding to numerical values ​​of 1.0, 2.0, 3.0, 4.0, and 5.0, respectively. The minimum permission requirements for the target sensitive resource are pre-configured in the permission rule base as minimum permission levels. Simultaneously, the permission rule base stores the corresponding minimum score threshold for each sensitive marked area. The minimum score threshold is obtained by converting the minimum permission level. The conversion rule is that the minimum score threshold equals the permission level value corresponding to the minimum permission level multiplied by a base coefficient of 1.0. For example, if the minimum permission requirement for a sensitive marked area is level 3, then its minimum score threshold is 3.0 multiplied by 1.0, which equals 3.0.

[0087] When calculating the final permission score, the permission level value corresponding to the request source device is multiplied by the request time weight, and then multiplied by the resource sensitivity coefficient of the target sensitive marked area. The product is the final permission score. The request time weight is divided into two categories: peak time weight and off-peak time weight. Peak times are from 9:00 to 11:00 and 14:00 to 16:00 daily, with a corresponding weight of 0.8, while off-peak times have a corresponding weight of 1.2. The setting of the peak time weight of 0.8 and the off-peak time weight of 1.2 is based on the time distribution characteristics of industrial controller access behavior. Analysis of the access logs of 100 industrial controllers for 30 consecutive days showed that the total number of access requests during peak times accounted for 62.3% of the total for the day, and the probability of abnormal access events during this period was 2.4 times higher than that during off-peak times. Reducing the peak time weight can increase the strictness of permission judgment.

[0088] The resource sensitivity coefficient is divided into three levels based on the sensitivity of the marked areas: high sensitivity (0.9), medium sensitivity (0.6), and low sensitivity (0.3). The criteria for these levels are as follows: The high sensitivity level corresponds to areas in the secure encrypted partition that store key materials, permission rule bases, device registry entries, and firmware upgrade interface paths. Based on failure mode and impact analysis, the average risk priority number is between 180 and 250, hence the value of 0.9 to impose sufficient security constraints. The medium sensitivity level corresponds to areas in the ordinary data partition that store production process parameters, equipment calibration data, and operational trend records. The average risk priority number is between 90 and 150, hence the value of 0.6 to balance security and accessibility. The low sensitivity level corresponds to areas in the ordinary data partition that store system operation logs, performance statistics, and non-sensitive configuration backups. The average risk priority number is below 80, hence the value of 0.3 to improve the success rate of legitimate operations.

[0089] After the final permission score is calculated, it is compared with the lowest score threshold corresponding to the target sensitive marked area. If the final permission score is greater than or equal to the lowest score threshold, an initial access permission result is generated, allowing access; if the final permission score is less than the lowest score threshold, an initial access permission result is generated, denying access.

[0090] For example, if the default permission level of the device making an access request is level 3, corresponding to a permission level value of 3.0, and the access occurs during off-peak hours with a weight of 1.2, and the target area is classified as medium-sensitive with a coefficient of 0.6, the calculated final permission score is 2.16. If the minimum permission requirement for that area is level 3, corresponding to a minimum score threshold of 3.0, then 2.16, being less than 3.0, is considered an access denial; if the minimum permission requirement is level 2, corresponding to a minimum score threshold of 2.0, then 2.16, being greater than or equal to 2.0, is considered an access permission.

[0091] It should be noted that the access failure record includes the failure reason, request timestamp, and target resource path, and the collection scope covers the corresponding data for all access denied scenarios. The size of a single access failure record is limited to 2KB; if it exceeds this limit, lossless compression processing using the LZ4 algorithm is employed. The LZ4 algorithm is a byte-oriented lossless compression algorithm based on LZ77, achieving a decompression speed of 4970MB / s, a compression speed of 780MB / s, and a compression ratio of approximately 2.10. These performance parameters are benchmark test results under an Intel Core i7-9700K processor, 4.9GHz clock speed, and the Silesia Corpus test set. The LZ4 algorithm was chosen because access failure records are small blocks of data that need to be written to the independent log partition of the storage chip in real time. Significant delays due to compression operations should be avoided. Furthermore, industrial controllers have limited CPU and memory resources, and the extremely low CPU utilization and memory overhead of the LZ4 algorithm meet these constraints. The compressed access failure records are stored in a separate log partition. The number of failures for the same hardware identifier within 7 days is counted. If the number of failures reaches 5, the permission verification frequency for that hardware identifier is increased from once per day to once per hour, with a validity period of 7 days.

[0092] In step S105, path log information is generated by integrating the path data, permission determination data, and time data of all access requests, including:

[0093] Collect the target storage path data corresponding to all access requests. The target storage path data is the complete storage path string determined after path parsing in step S103 for each access request, and the path string length does not exceed 256 bytes. Summarize the judgment result data generated after the permission level determination of each access request in step S104. The judgment result data includes two types of result identifiers: allowed access and denied access, as well as the corresponding permission level value, final permission score, and minimum score threshold. Record the timestamp data corresponding to the initiation of each access request. The timestamp precision is in milliseconds, and the format is a Unix timestamp.

[0094] The path data, judgment result data, and timestamp data are combined and arranged on a per-access-request basis to generate path log records in a unified format. The field structure of a single path log record includes: log record identifier, request timestamp, access path, source hardware identifier hash value, judgment result identifier, permission level value, final permission score, minimum score threshold, and target sensitivity level. The log record identifier is generated in UUID format to ensure global uniqueness; the source hardware identifier hash value is taken from the first 16 bytes of the 64-byte hardware binding information generated in step S103 to reduce log storage overhead while maintaining device traceability.

[0095] All path log records are written to the memory log buffer in ascending order of timestamp, with a buffer size of 2MB. A double-buffering mechanism is used; when either buffer reaches 80% occupancy, a buffer switch is triggered, and data in the full buffer is batch-persistently written to an independent log partition. During batch writing, the LZ4 algorithm is used to compress the log data, resulting in 64KB aligned log data blocks with a maximum write latency of no more than 50ms. The selection criteria for the LZ4 algorithm are the same as those used for compressing access failure records in step S104.

[0096] Path log information is split by calendar day, with the splitting operation performed at midnight each day. During splitting, unpersisted data in the memory buffer is first forcibly written to the current log file, the current log file is closed, and a new log file with the date as its suffix is ​​generated, named pathlog_YYYYMMDD.lz4. The maximum uncompressed original data size of a single day's path log file is 100MB, and the compressed storage size is approximately 45% to 55% of the original data size. The actual compression ratio depends on the degree of repetition in the path strings.

[0097] The archiving period for path log files is 30 days. Log files older than 30 days are automatically migrated from the independent log partition to the cold storage area. The cold storage area is located in an independent cold data storage unit within the SD NAND chip. This unit uses SLC mode to improve the reliability of long-term data preservation. The maximum retention time for path log data in the cold storage area is 180 days. Data exceeding the retention time undergoes automatic cleanup, which is performed once per day. During cleanup, data integrity is first verified. After confirming that the data has expired and there are no outstanding audit tasks, it is permanently deleted through overwriting.

[0098] The path log information is used for access time distribution analysis in the subsequent step S106 when determining the risk level of sensitive marked areas, and for tracing the connection of access failure records in step S107. The path log information is only accessible to the chip's built-in core verification module; external software interfaces cannot directly read the log content. Audit export commands can only be initiated through a level 5 access management node. Export commands must pass both hardware unique code verification and access level verification before execution. Exported data is encrypted using the AES-256 algorithm before being transmitted to the management node.

[0099] In step S106, based on the access permission result, the access failure record and the path log information are used to adjust the access restriction rules of the sensitive marked area to obtain an updated access control table, including:

[0100] Based on the access permission results and the access failure records, count the number of successful accesses and the number of failed accesses to the sensitive marked area;

[0101] The risk level of the sensitive marked area is determined based on the number of successful accesses and the number of failed accesses.

[0102] Based on the risk level and the access time distribution in the path log information, adjust the access restriction rules for the sensitive marked area;

[0103] The access restriction rules are merged with the preset original permission rules to obtain the updated permission control table. It should be noted that, based on access permission results, access failure records, and path log information, the number of successful accesses and the number of failed accesses are counted separately for each sensitive marked area. The statistical period is the past 24 hours, and the statistical scope covers all access requests for all sensitive marked areas.

[0104] It should be noted that the risk level is determined based on the risk index, which is equal to the access failure rate multiplied by the access frequency multiplied by the regional sensitivity. The access failure rate is the number of access failures corresponding to the sensitive marked region within the statistical period divided by the total number of accesses. The access frequency is the total number of accesses corresponding to the sensitive marked region within the statistical period. The regional sensitivity is set according to the importance of the sensitive marked region, with a value ranging from 0 to 1, consistent with the resource sensitivity coefficient of the corresponding region. The risk level is divided into three levels: high risk, medium risk, and low risk. The preset high-risk threshold is 45.0, and the preset medium-risk threshold is 20.0. A risk index exceeding 45.0 is considered high-risk; a risk index greater than or equal to 20.0 and less than or equal to 45.0 is considered medium-risk; and a risk index less than 20.0 is considered low-risk. The high-risk threshold of 45.0 and the medium-risk threshold of 20.0 are based on multi-scenario risk simulation tests of industrial storage systems. Fifty test datasets were selected for each of four typical operating scenarios: normal business operation, occasional misoperation, continuous attempts to access restricted resources, and automated scanning attacks. The distribution range of the risk index under each scenario was statistically analyzed. Test results show that the mean risk index for normal business operation is 6.8, with an upper limit of the 95% confidence interval of 18.2; the mean risk index for occasional misoperation is 14.3, with an upper limit of the 95% confidence interval of 29.7; the mean risk index for continuous attempts to access restricted resources is 38.5, with a lower limit of the 95% confidence interval of 31.2; and the mean risk index for automated scanning attacks is 67.4, with a lower limit of the 95% confidence interval of 52.6. Based on this, the threshold between low and medium risk was set at 20.0, and the threshold between medium and high risk was set at 45.0. This ensures that the low-risk range fully covers normal business and occasional misoperation scenarios, the high-risk range accurately identifies malicious attack behavior, and the medium-risk range serves as a transitional observation area. The threshold setting scheme was cross-validated and showed a recall rate of 97.3% for known attack samples and a false positive rate of 1.1% for normal business samples.

[0105] It is worth noting that the access restriction rule adjustments include adjustments to permission levels and access frequency limits. The scope of the adjustments covers all sensitive marked areas where the risk level has changed or remained at a high risk level for more than the preset observation period. The adjustment rules are executed according to the risk level, as detailed below.

[0106] When the risk level is determined to be high, enhanced restriction rules are triggered. If the current time period is a high-load period, the minimum permission requirement for the target sensitive resource is raised from level 3 to level 4; if the current time period is not a high-load period, the minimum permission requirement for the target sensitive resource is raised from level 3 to level 5. The high-load period is defined as a period when the system load rate exceeds 80%. The system load rate is sampled every 5 minutes, and the sampled value is the weighted average of CPU utilization and storage chip I / O queue depth, where CPU utilization has a weight of 0.4 and I / O queue depth has a weight of 0.6.

[0107] The weighting is determined based on the resource consumption distribution characteristics of industrial controllers in data read and write tasks. Through regression analysis of performance monitoring data of 100 controllers under full load read and write conditions, the variance explained by I / O queue depth is 61.7% and the variance explained by CPU utilization is 38.3%. Therefore, the weight of I / O queue depth is set to 0.6 and the weight of CPU utilization is set to 0.4.

[0108] Meanwhile, under high-risk levels, the daily access limit for corresponding sensitive marked areas will be adjusted to 20 times, and the hourly access limit will be adjusted to 5 times. The daily access limit of 20 times is based on the principle of least privilege, using the necessary daily operation frequency of typical industrial configuration management tasks as a benchmark. Statistical analysis of log data from 50 types of industrial controller configuration management scenarios shows that the average daily access frequency of a single legitimate device to sensitive marked areas is 6.2 times, with a 99th percentile of 14 times. Taking a safety redundancy factor of 1.4, the upper limit of 20 times is set. The hourly access limit of 5 times is determined based on the suddenness of access requests. The maximum number of accesses per hour for normal management operations should not exceed 3 times. This 5-times limit effectively blocks high-frequency probing behavior by automated scanning tools.

[0109] When the risk level is determined to be medium risk, the observation rule is triggered. The currently effective minimum access requirements and access limit remain unchanged, and the status of the corresponding sensitive area is marked as observation. The observation period lasts for two consecutive statistical periods, i.e., 48 hours. If the risk level drops to low risk within 48 hours, the recovery process begins; if the risk level rises back to high risk within 48 hours, enhanced restriction rules are executed and the observation timer is reset; if the risk level remains medium risk after 48 hours, it is considered a persistent anomaly, and access escalation and access limit adjustments are implemented according to the high-risk level rules.

[0110] When the risk level is determined to be low, the relaxation rules are triggered. The relaxation rules are implemented in tiers based on regional sensitivity. For sensitive regions with a sensitivity level greater than or equal to 0.7, if they were previously at a high or medium risk level and their current risk index is below 10.0 for three consecutive statistical periods (72 hours), the minimum permission requirements will be restored to the baseline level 2, the daily access limit will be restored to 50 times, and the hourly access limit will be removed. For sensitive regions with a sensitivity level less than 0.7, if their risk index is below 15.0 for two consecutive statistical periods (48 hours), the minimum permission requirements will be restored to the baseline level 1, the daily access limit will be restored to 100 times, and the hourly access limit will be removed. The baseline level is the default permission level set during initial deployment; level 1 corresponds to read-only permissions, and level 2 corresponds to restricted write permissions, meaning that the amount of data written at one time cannot exceed 1MB and the total number of writes per day cannot exceed 10.

[0111] The daily access limits of 50 and 100 times correspond to the recovery values ​​for areas with sensitivity greater than or equal to 0.7 and less than 0.7, respectively, and are determined based on the baseline of legitimate access frequency to the corresponding areas during normal business operations. Statistical analysis of 30 days of normal operation logs shows that the average daily access frequency for areas with sensitivity greater than or equal to 0.7 is 22.5 times, with a 99th percentile of 41 times, and is set to 50 times after taking safety redundancy; the average daily access frequency for areas with sensitivity less than 0.7 is 48.3 times, with a 99th percentile of 82 times, and is set to 100 times after taking safety redundancy.

[0112] The risk index thresholds of 10.0 and 15.0 in the recovery conditions are set based on the principle of recovery safety, requiring the risk index to be consistently below 50% to 75% of the low-risk threshold of 20.0 before recovery. A stricter recovery threshold of 10.0 and a longer observation period of 72 hours are used for highly sensitive areas, while a relatively lenient recovery threshold of 15.0 and a shorter observation period of 48 hours are used for less sensitive areas, to achieve a balance between safety and availability.

[0113] It's worth noting that the specific range of access limit adjustments is controlled by the access frequency limit field in the updated access control table. When a change in risk level triggers an adjustment to the access limit, the daily access limit field and the hourly access limit field for the corresponding sensitive marked area in the access control table are updated synchronously. The updated access control table includes the following fields: area identifier, current risk level, minimum effective permission level, daily access limit, hourly access limit, rule version number, effective timestamp, and expiration timestamp. Each rule adjustment generates a new version number, formatted as a timestamp followed by a three-digit incrementing sequence number, e.g., 20250321143022001. Historical versions of the access control table are retained in the access rule history table of the security database for 90 days for audit backtracking and rule rollback. The access rule history table contains the same field structure as the updated access control table, plus a change type field to identify the triggering reason for the rule adjustment. The change type includes four values: high-risk trigger, medium-risk observation, low-risk recovery, and manual intervention.

[0114] It should be noted that after the updated access control table is generated, a corresponding SHA-256 hash checksum is generated simultaneously. This hash checksum is used by each storage node to verify the integrity of the access control table received. Only after successful verification can the updated access control table take effect. The hash checksum and the updated access control table are distributed to each storage node, and the synchronization cycle for the access control table on each storage node is 5 minutes. If synchronization fails, a retry is performed every 30 seconds; three consecutive failed retries trigger an alarm.

[0115] In step S107, data read / write operations on the storage chip are processed according to the updated permission control table. Operations are allowed to proceed when the access path points to the sensitive marked area and the hardware encoding verification passes, resulting in a secure storage processing result, including:

[0116] Receive data read / write operations from the storage chip, and parse the data read / write operation request to obtain hardware feature information;

[0117] If the access path points to the sensitive marked area, the hardware unique code in the hardware feature information is verified a second time. If the verification passes, the data read and write operation is allowed to be executed according to the updated permission control table, and the operation log is obtained.

[0118] Record the operation log and generate a data verification code, then organize the data verification code to obtain the secure storage processing result.

[0119] It should be noted that for received data read / write operations on the storage chip, parsing processing is performed based on the updated access control table to extract resource locators and hardware feature information from the request. The resource locator corresponds to the access path, and the hardware feature information corresponds to the unique hardware code. The extracted access path is matched against the sensitive marked areas in the updated access control table to determine whether the access path points to a sensitive marked area. If the path does not point to a sensitive marked area, the operation is performed according to the regular rules of the updated access control table.

[0120] It should be noted that hardware unique code verification is initiated only when the access path points to a sensitive marked area. The verification uses the AES-128 algorithm, and the hardware unique code is 64 bits long. The verification process compares the hardware unique code with the pre-stored valid code information. If the verification fails, the corresponding data read / write operation is directly rejected. If the verification passes, subsequent permission verification is performed according to the updated permission control table.

[0121] It should be noted that after both hardware verification and permission verification pass, a real-time access risk value is calculated. This real-time access risk value equals the system load rate multiplied by the number of accesses to the corresponding sensitive marked area within the past hour, multiplied by the resource sensitivity coefficient. The resource sensitivity coefficient is consistent with the set value for the corresponding sensitive marked area. The preset security threshold is 5000, which is determined based on a comprehensive calculation model of system load, access frequency, and sensitivity coefficient. Within the normal operating range of the industrial controller, a risk value below 5000 is considered safe; a value above 5000 indicates a high-load, high-risk state, requiring access restrictions.

[0122] When the real-time access risk value is lower than the preset security threshold, data read and write operations are allowed; when it exceeds the preset security threshold, the corresponding data read and write operations are rejected.

[0123] It should be noted that after a data read / write operation is completed, a corresponding operation log is generated. The operation log includes a timestamp, operation type, and data volume. The timestamp is accurate to milliseconds, and the operation type is divided into read and write operations. The operation log is stored in a separate log partition. A CRC-32 algorithm is simultaneously used to generate a data checksum for this operation. This checksum is used for subsequent integrity verification of the corresponding data.

[0124] It should be noted that after the data read and write operations are completed, the storage chip status table is updated. The status table is stored in the security database and records the remaining number of accesses for the corresponding sensitive marked area. The upper limit of the number of accesses is consistent with the set value of the updated access control table.

[0125] It is worth noting that when data read / write operations in sensitive marked areas fail, an abnormal alarm mechanism is triggered. This mechanism automatically analyzes the cause of the failure and generates alarm information containing the cause, request timestamp, and target resource path. The alarm information is encrypted using the RSA-2048 algorithm and pushed to the management node in real time. If the push fails, it is retried every 30 seconds. The encryption key pair is stored in a secure database. The public and private key pairs for the RSA-2048 algorithm are generated at the factory. The public key is stored in the encryption module of the industrial controller and used for encrypting alarm information. The private key is stored in the hardware dongle on the management node and used for decrypting alarm information. The public and private key pairs are updated every 180 days.

[0126] It is worth noting that after a write operation to a sensitive marked area is completed, an incremental backup is automatically triggered. The linkage rules between incremental backup and access control and secure partitions are as follows: Incremental backup operations are only performed after the data modification corresponding to the write operation has passed hardware unique code verification and access level determination and has been successfully written to the storage chip. The target storage location for the backup data is an independent backup partition. This partition is physically isolated from the ordinary data partition, independent log partition, and secure encrypted partition within the SD NAND chip. The read and write permissions of the partition are locked through hardware protection registers, and only the chip's built-in hardware encryption engine can initiate a write operation after the access verification is passed. The correspondence between the backup partition and the sensitive marked area is a one-to-one mapping, meaning that each sensitive marked area has a corresponding exclusive subpartition within the backup partition. The subpartition path is obtained by hashing the sensitive marked area identifier using SHA-256 and taking the first 16 hexadecimal characters as the subpartition name, ensuring that the binding relationship between the backup data and the original sensitive area cannot be tampered with.

[0127] Before the backup operation is executed, the hardware encryption engine performs an integrity check on the data to be backed up. Only after the check passes can the data be written to the backup partition. The backup data is encrypted and stored using the AES-256 algorithm in CBC mode. The encryption key and the encryption key for the corresponding sensitive marked area are independent of each other and are generated and managed separately by the key management table in the security database. The encryption key for the backup data is automatically updated every 30 days, triggered at midnight on the first day of each month. The old key is retained for 180 days for decryption and recovery of historical backup data.

[0128] Backup data is retained for 30 days. Backup data exceeding this retention period is automatically migrated to the cold storage area. Backup data in the cold storage area is retained for a maximum of 180 days. Data exceeding this retention period is completely destroyed through overwriting. The overwriting operation is performed three times, writing 0x00, 0xFF, and a random data sequence respectively, in accordance with industrial data destruction standards.

[0129] When the integrity verification of the original data in the storage chip fails due to hardware failure, unauthorized tampering, or misoperation, the data recovery mechanism is triggered. The execution process of the data recovery mechanism is as follows: First, the hardware encryption engine synchronously calculates the CRC-32 checksum of the read data during each read operation and compares it with the original checksum recorded in the storage chip status table. If the checksums do not match, the data integrity is determined to be compromised, a data anomaly alarm message is immediately generated, encrypted using the RSA-2048 algorithm, and pushed to the management node. At the same time, the damaged data block is marked as unreadable.

[0130] Secondly, upon receiving a data anomaly alarm, the management node initiates a data recovery command through the Level 5 access control device. This data recovery command must pass both hardware unique code verification and access level verification before execution. After successful verification, the hardware encryption engine locates the dedicated sub-partition corresponding to the damaged sensitive marked area in the backup partition and reads the most recent valid incremental backup data.

[0131] When reading backup data, the SHA-256 hash value corresponding to the backup data is first verified to confirm the integrity of the backup data itself. After successful verification, the corresponding decryption key in the key management table is used to perform AES-256 decryption. The decrypted data is compared byte by byte with the damaged data block. After locating the damaged byte, byte-by-byte overwrite recovery is performed. After the recovery operation is completed, the CRC-32 checksum of the recovered data is recalculated and compared with the original checksum. If the checksum matches, the recovery is considered successful, and a recovery log is generated and stored in a separate log partition. The recovery log includes a recovery timestamp accurate to milliseconds, a damaged area identifier, the offset of the damaged byte, and the recovery result.

[0132] After a successful recovery, the corresponding incremental backup data in the backup partition will be retained until the original retention period expires, and will not be prematurely deleted due to the recovery operation, so as to support multiple recovery needs. If the recovery fails, it will automatically attempt to read the previous incremental backup data to perform the recovery, with a maximum of 3 attempts. Three consecutive recovery failures will trigger the highest level alarm, requiring manual intervention.

[0133] Incremental backups are triggered automatically after write operations are completed, as well as via a scheduled backup mechanism. A full backup scan is performed every 24 hours, covering sensitive marked data blocks that have undergone write operations within the past 24 hours and have not yet been backed up by a scheduled backup. The encryption method, storage location, and retention period for scheduled backups are identical to those for incremental backups. The maximum backup data size for scheduled backups is set at 100MB per sensitive marked area per day. If this limit is exceeded, the most recently modified data is backed up in ascending order of modification time, with any excess data delayed until the next backup cycle.

[0134] The aforementioned incremental backup and recovery mechanism forms a closed-loop linkage with the updated access control table. When the risk level of a sensitive marked area is determined to be high-risk, the incremental backup frequency for that area is adjusted from the default single trigger to three consecutive triggers. That is, after the write operation is completed, three independent backups are executed consecutively, and the three backups are written to three different physical blocks in the backup partition, in order to cope with the risk of physical storage unit failure in high-risk scenarios. After the high-risk level is removed, the backup frequency is restored to the default single trigger. The triggering and recovery conditions for the backup frequency adjustment are consistent with the risk level adjustment rules in step S106.

[0135] It's worth noting that the access count for sensitive marked areas resets at midnight every day (d). When the access count reaches the upper limit set in the updated access control table, a cooling-off mechanism is triggered, with a cooldown period of 2 hours. The generation and management rules for the system's core whitelist are as follows: Whitelisted devices fall into two categories. The first category consists of factory-installed management node devices. The device hardware binding information is written into the legitimate device registry in the security database during device production and flashing, and is marked as a whitelisted type. The second category consists of temporary maintenance devices authorized by Level 5 access control devices. Authorization requires dual verification through hardware unique code verification and access level verification. The authorization validity period is a maximum of 24 hours, after which the device is automatically removed from the whitelist. The whitelisted device list is stored in the whitelist table in the security database. Table fields include hardware binding information hash value, device type, effective time, expiration time, and authorization source. The whitelist table is readable and writable only by the chip's built-in core verification module. When the cooling-off mechanism is triggered, the hardware encryption engine reads the currently valid device list in the whitelist table, allowing only devices in the list to continue accessing the corresponding sensitive marked areas. Access requests from non-whitelisted devices are directly denied. During the cooling-off period, all non-system core whitelisted devices are prohibited from accessing this sensitive marked area.

[0136] In summary, this invention provides a stable industrial data storage method based on SD NAND storage chips, effectively solving the problems of existing technologies being unable to achieve strict hardware-level control of permissions at the storage chip level, and unable to effectively isolate and protect sensitive data, making it difficult to balance the security, stability, and access flexibility of industrial data storage. This provides technical support for the secure storage and reliable operation of industrial system data.

[0137] refer to Figure 2 The second embodiment of the present invention provides an industrial data stable storage system based on SD NAND memory chips, comprising:

[0138] The log encryption module is used to obtain a preliminary log filtering file, and to encrypt and protect key fields according to the preliminary log filtering file to obtain encrypted access record data.

[0139] The request filtering module is used to parse the abnormal behavior markers and request interval fluctuation characteristics based on the encrypted access record data to obtain the access requests to be verified.

[0140] The hardware verification module is used to perform path parsing based on the access request to be verified, obtain sensitive marked areas, and perform hardware unique code verification if the access path points to the sensitive marked areas to obtain the verification result.

[0141] The permission determination module is used to perform permission level division determination based on the verification result, generate access permission result, and collect access failure records in the access permission result;

[0142] The log generation module is used to integrate path data, permission judgment data, and time data of all access requests to generate path log information;

[0143] The rule update module is used to adjust the access restriction rules of the sensitive marked area according to the access permission result, the access failure record and the path log information, so as to obtain the updated permission control table;

[0144] The read / write execution module is used to process data read / write operations on the storage chip according to the updated permission control table. When the access path points to the sensitive marked area and the hardware encoding verification passes, the operation is allowed to be executed, and a secure storage processing result is obtained.

[0145] It should be noted that the industrial data stable storage system based on SD NAND memory chip provided in this embodiment of the invention is used to execute all the process steps of the industrial data stable storage method based on SD NAND memory chip in the above embodiment. The working principle and beneficial effect of the two are one-to-one, so they will not be described again.

[0146] It should be noted that the system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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 modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the system embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0147] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A method for stable industrial data storage based on SD NAND flash memory chips, characterized in that, include: Obtain a preliminary log filtering file, and encrypt and protect key fields according to the preliminary log filtering file to obtain encrypted access record data; Based on the encrypted access record data, abnormal behavior markers and request interval fluctuation characteristics are analyzed to obtain the access request to be verified; The path is parsed according to the access request to be verified to obtain the sensitive marked area. If the access path points to the sensitive marked area, hardware unique code verification is performed to obtain the verification result. Based on the verification result, perform permission level division and determination, generate access permission result, and collect access failure records in the access permission result; Integrate all access request path data, permission judgment data, and time data to generate path log information; Based on the access permission results, the access failure records, and the path log information, the access restriction rules for the sensitive marked area are adjusted to obtain the updated permission control table; The data read and write operations of the storage chip are processed according to the updated permission control table. When the access path points to the sensitive marked area and the hardware encoding verification passes, the operation is allowed to be executed, and a secure storage processing result is obtained. The step of encrypting and protecting key fields based on the preliminary log filtering file to obtain encrypted access record data includes: Extract access data volume mutation information from the initial log screening file; compare the access data volume mutation information with a preset mutation threshold to filter out over-access records that exceed the preset mutation threshold; extract the source address classification information from the over-access records as a key field, encrypt the key field to generate a ciphertext string; replace the key field with the ciphertext string and reorganize the log structure to obtain encrypted access record data.

2. The industrial data stable storage method based on SD NAND memory chips according to claim 1, characterized in that, The process of obtaining the preliminary log filtering file includes: Real-time access request data is collected through the storage chip access interface; The real-time access request data is monitored in multiple dimensions to obtain the peak request frequency and time distribution pattern; If the peak frequency of the request exceeds the preset frequency range or the time distribution pattern does not match the preset typical pattern, then an abnormal behavior marker is added to the real-time access request data. Based on the abnormal behavior markers, metadata is extracted from the corresponding access requests, and the metadata is integrated with the abnormal behavior markers to generate a preliminary log filtering file.

3. The industrial data stable storage method based on SD NAND memory chips according to claim 2, characterized in that, The step of parsing abnormal behavior markers and request interval fluctuation characteristics based on the encrypted access record data to obtain the access request to be verified includes: The encrypted access record data is decrypted to extract the abnormal behavior markers and access trajectory data in plaintext form; The time interval between adjacent access requests is calculated based on the access trajectory data to obtain the request interval fluctuation characteristics; The fluctuation characteristics of the requested interval are compared with historical benchmark data to obtain the fluctuation amplitude deviation. If the abnormal behavior is marked as a high-risk operation and the fluctuation range deviates beyond a preset deviation threshold, a dynamic verification mechanism is triggered. The dynamic verification mechanism filters out the corresponding access requests to obtain the access requests to be verified.

4. The industrial data stable storage method based on SD NAND memory chips according to claim 1, characterized in that, The process involves performing path parsing based on the access request to be verified to obtain a sensitive marked region. If the access path points to the sensitive marked region, a hardware unique code verification is performed to obtain the verification result, including: Extract the resource locator from the access request to be verified, and decompose the resource locator according to the preset path parsing rules to obtain the directory hierarchy sequence; The directory hierarchy sequence is matched with the preset sensitive area identifier to obtain the access path. If the access path points to the sensitive marked area, the MAC address and device serial number of the request source device are extracted. Feature extraction is performed on the MAC address and the device serial number to obtain hardware binding information; The hardware binding information is compared with the pre-stored legitimate device registration data to obtain the verification result.

5. The industrial data stable storage method based on SD NAND memory chips according to claim 1, characterized in that, The step of performing permission level division and determination based on the verification result and generating access permission result includes: Extract the hardware identifier matching status from the verification result. If the hardware identifier matching status is consistent, retrieve the preset permission level corresponding to the hardware identifier. The preset permission level is compared with the minimum permission requirements of the target sensitive resource to generate an initial access permission result.

6. The industrial data stable storage method based on SD NAND memory chips according to claim 1, characterized in that, The access restriction rules for the sensitive marked area are adjusted based on the access permission result, the access failure record, and the path log information to obtain an updated access control table, including: Based on the access permission results and the access failure records, count the number of successful accesses and the number of failed accesses to the sensitive marked area; The risk level of the sensitive marked area is determined based on the number of successful accesses and the number of failed accesses. Based on the risk level and the access time distribution in the path log information, adjust the access restriction rules for the sensitive marked area; The access restriction rules are merged with the preset original permission rules to obtain the updated permission control table.

7. The industrial data stable storage method based on SD NAND memory chips according to claim 1, characterized in that, The process of handling data read / write operations on the storage chip according to the updated permission control table, allowing operation execution when the access path points to the sensitive marked area and the hardware encoding verification passes, and obtaining a secure storage processing result includes: Receive data read / write operations from the storage chip, and parse the data read / write operation request to obtain hardware feature information; If the access path points to the sensitive marked area, the hardware unique code in the hardware feature information is verified twice. If the verification passes, the data read and write operation is allowed to be executed according to the updated permission control table, and the operation log is obtained. Record the operation log and generate a data verification code, then organize the data verification code to obtain the secure storage processing result.

8. An industrial data stable storage system based on SD NAND memory chips, characterized in that, For implementing the method as described in any one of claims 1-7, comprising: The log encryption module is used to obtain a preliminary log filtering file, and to encrypt and protect key fields according to the preliminary log filtering file to obtain encrypted access record data. The request filtering module is used to parse abnormal behavior markers and request interval fluctuation characteristics based on the encrypted access record data to obtain access requests to be verified. The hardware verification module is used to perform path parsing based on the access request to be verified, obtain sensitive marked areas, and perform hardware unique code verification if the access path points to the sensitive marked areas to obtain the verification result. The permission determination module is used to perform permission level division determination based on the verification result, generate access permission result, and collect access failure records in the access permission result; The log generation module is used to integrate path data, permission judgment data, and time data of all access requests to generate path log information; The rule update module is used to adjust the access restriction rules of the sensitive marked area according to the access permission result, the access failure record and the path log information, so as to obtain the updated permission control table; The read / write execution module is used to process data read / write operations on the storage chip according to the updated permission control table. When the access path points to the sensitive marked area and the hardware encoding verification passes, the operation is allowed to be executed, and a secure storage processing result is obtained.

Images