An electronic archive storage method and system
By splitting and encrypting highway electronic archive data fragments in a heterogeneous server cluster and setting up a filtering gateway at the core storage pool entrance, the problems of low storage efficiency and security risks in existing technologies are solved, achieving efficient and secure archive storage.
Patent Information
- Application Number
- CN202511416181.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-30
- Publication Date
- 2026-01-13
- Estimated Expiration
- 2045-09-30
AI Technical Summary
Existing technologies for storing electronic records of highways are prone to failure due to environmental incompatibility or external hacking, posing security risks and resulting in low storage efficiency.
By creating a core storage pool in a heterogeneous server cluster, electronic archives are split into data fragments and independent encryption keys are generated. The encrypted data fragments are stored in a distributed manner, and a filtering gateway is set at the core storage pool entrance to filter access requests in real time.
It improves the confidentiality and storage efficiency of electronic records, effectively prevents external cracking and unauthorized access, and ensures the safety and integrity of the records.
Smart Images

Figure CN120910925B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of archival storage technology, and in particular to an electronic archival storage method and system. Background Technology
[0002] With the advancement of science and technology and the rapid development of productivity, my country is simultaneously and vigorously developing the construction of expressways. Specifically, in order to facilitate management, corresponding electronic archives for expressways have been developed. These electronic archives can cover key information such as project proposals, design drawings, and inspection reports, and are an important part of transportation construction management.
[0003] The existing electronic records of highways face multiple information security threats, such as the risk of network attacks and virus infection, the risk of data tampering, and the risk of storage system vulnerabilities. Therefore, it is necessary to store the electronic records of highways securely and effectively.
[0004] Furthermore, in the process of storing electronic records for highways, existing technologies mostly use conventional encryption software for encryption before storing them in the corresponding database. However, this storage method is prone to failure due to environmental incompatibility or external cracking, and it cannot effectively control the source of the records, thus posing certain security risks and reducing the storage efficiency of electronic records. Summary of the Invention
[0005] Based on this, the purpose of this invention is to provide an electronic record storage method and system to solve the problem that the storage of electronic records for highways in the prior art is prone to failure due to environmental incompatibility or external hacking, resulting in security risks.
[0006] The first aspect of the present invention proposes:
[0007] An electronic record storage method, wherein the method includes:
[0008] The corresponding core storage pool is created in real time based on several heterogeneous server clusters, and the original electronic files input by users are received in real time.
[0009] Based on the content correlation in the original electronic file, the original electronic file is divided into several data segments, and an independent encryption key adapted to each data segment is generated in real time to generate the corresponding encrypted data segment in real time.
[0010] Each encrypted data fragment is distributed and stored within several heterogeneous server clusters, and a corresponding filtering gateway is set at the access point of the core storage pool.
[0011] The filtering gateway performs real-time filtering on the received access requests to complete the storage of the original electronic files.
[0012] The beneficial effects of this invention are as follows: by creating a core storage pool in real time, preparations can be made for subsequent storage. Based on this, the original electronic files input by the user can be received in real time. Specifically, in order to improve the confidentiality performance, the current original electronic files are divided into several data segments, and an independent encryption key is added to each data segment. Based on this, each encrypted data segment is finally stored in the corresponding heterogeneous server cluster. Furthermore, the access requests input by the user can be filtered in real time through a pre-configured filtering gateway, thereby achieving secondary confidentiality of the electronic files, eliminating security risks of the electronic files, and correspondingly improving the confidentiality performance and storage efficiency of the electronic files.
[0013] Furthermore, the step of dividing the original electronic file into several data segments based on the content correlation in the original electronic file includes:
[0014] The original electronic archives are subjected to structured scanning to identify metadata fields containing related information, and a metadata index table adapted to the metadata fields is established.
[0015] Based on the association relationships recorded in the metadata index table, calculate the association metric value between any two information units in the metadata index table;
[0016] According to the correlation metric values from high to low, each information unit is sequentially aggregated into a data segment, wherein the cumulative correlation of the information units in each data segment is not less than a preset threshold.
[0017] Furthermore, the step of calculating the correlation metric between any two information units in the metadata index table based on the correlation relationships recorded in the metadata index table includes:
[0018] Extract the timestamp field of any two information units in the metadata index table, calculate the corresponding time difference based on the timestamp field, and convert the time difference into a time correlation coefficient. The smaller the time difference, the larger the time correlation coefficient.
[0019] Identify the subject identifier field contained in any two information units. If the subject identifiers are completely identical, assign a first subject coefficient; if they are partially identical, assign a second subject coefficient; if they are completely different, assign a zero value.
[0020] The time correlation coefficient and the main coefficient are superimposed and calculated according to a preset weight ratio to calculate the correlation quantification value between any two information units in real time.
[0021] Furthermore, the step of generating an independent encryption key adapted to each data fragment in real time to generate the corresponding encrypted data fragment in real time includes:
[0022] Extract a 256-byte content fragment from each data segment as the base material for key generation, and simultaneously record the starting offset address of the content fragment in the data segment;
[0023] A hash operation is performed on the key generation base material to obtain a 512-bit hash value, and the first 256 bits are used as the initial key and the last 256 bits are used as the key verification code.
[0024] The initial key and the starting offset address of the data segment are XORed bitwise to generate the independent encryption key, and the data segment is encrypted using the independent encryption key to generate the encrypted data segment.
[0025] Furthermore, the step of performing a bitwise XOR operation between the initial key and the starting offset address of the data segment to generate the corresponding independent encryption key includes:
[0026] The starting offset address is converted into a hexadecimal string, and the string is converted into a binary sequence, where each hexadecimal character corresponds to 4 binary bits;
[0027] Perform a bitwise XOR operation on the binary sequence and the string to generate the corresponding XOR result sequence;
[0028] The XOR result sequence is divided into 32 subsequences in groups of 8 bits, and parity check bits are inserted into each subsequence and then reassembled to generate the corresponding independent encryption key.
[0029] Furthermore, the step of performing real-time filtering processing on the received access requests through the filtering gateway to complete the storage of the original electronic files includes:
[0030] Extract the timestamp field and the requester's digital signature from the access request, convert the timestamp field to a Unix timestamp value, and perform an XOR operation with the first 32 bits of the requester's digital signature to generate a verification value;
[0031] The system queries the preset time window parameters in the filtering gateway and determines whether the difference between the current system time and the request timestamp is within the window range, while also verifying the validity of the requester's digital signature.
[0032] For access requests that pass time verification and signature verification, the operation instruction code contained therein is parsed and compared with the preset set of legal instruction codes in the core storage pool. Only when the instruction code matches is the access request allowed to pass and the corresponding operation executed.
[0033] Furthermore, the step of parsing the operation instruction code contained in the access request that has passed time verification and signature verification includes:
[0034] Extract a 16-byte instruction marker segment from the protocol header of the access request, and split the instruction marker segment into two 8-byte fields based on odd and even bits;
[0035] Perform a hash operation on each of the two byte segments to generate two 16-byte hash values, and concatenate the first 8 bytes of the former hash value with the last 8 bytes of the latter hash value to form an instruction signature.
[0036] The instruction signature is converted into a 64-bit decimal value and matched with a preset instruction code mapping table in the core storage pool to extract the corresponding operation instruction code from the instruction code mapping table.
[0037] The second aspect of the present invention proposes:
[0038] An electronic record storage system, wherein the system comprises:
[0039] The creation module is used to create corresponding core storage pools in real time based on several heterogeneous server clusters, and to receive raw electronic files input by users in real time.
[0040] The splitting module is used to split the original electronic file into several data segments according to the content correlation in the original electronic file, and generate an independent encryption key that matches each data segment in real time, so as to generate the corresponding encrypted data segment in real time.
[0041] The storage module is used to distribute and store each encrypted data fragment within several heterogeneous server clusters, and to set a corresponding filtering gateway at the access entry of the core storage pool.
[0042] The filtering module is used to perform real-time filtering processing on the access requests received in real time through the filtering gateway, so as to complete the storage of the original electronic files accordingly.
[0043] Furthermore, the splitting module is specifically used for:
[0044] The original electronic archives are subjected to structured scanning to identify metadata fields containing related information, and a metadata index table adapted to the metadata fields is established.
[0045] Based on the association relationships recorded in the metadata index table, calculate the association metric value between any two information units in the metadata index table;
[0046] According to the correlation metric values from high to low, each information unit is sequentially aggregated into a data segment, wherein the cumulative correlation of the information units in each data segment is not less than a preset threshold.
[0047] Furthermore, the splitting module is specifically used for:
[0048] Extract the timestamp field of any two information units in the metadata index table, calculate the corresponding time difference based on the timestamp field, and convert the time difference into a time correlation coefficient. The smaller the time difference, the larger the time correlation coefficient.
[0049] Identify the subject identifier field contained in any two information units. If the subject identifiers are completely identical, assign a first subject coefficient; if they are partially identical, assign a second subject coefficient; if they are completely different, assign a zero value.
[0050] The time correlation coefficient and the main coefficient are superimposed and calculated according to a preset weight ratio to calculate the correlation quantification value between any two information units in real time.
[0051] Furthermore, the splitting module is specifically used for:
[0052] Extract a 256-byte content fragment from each data segment as the base material for key generation, and simultaneously record the starting offset address of the content fragment in the data segment;
[0053] A hash operation is performed on the key generation base material to obtain a 512-bit hash value, and the first 256 bits are used as the initial key and the last 256 bits are used as the key verification code.
[0054] The initial key and the starting offset address of the data segment are XORed bitwise to generate the independent encryption key, and the data segment is encrypted using the independent encryption key to generate the encrypted data segment.
[0055] Furthermore, the splitting module is specifically used for:
[0056] The starting offset address is converted into a hexadecimal string, and the string is converted into a binary sequence, where each hexadecimal character corresponds to 4 binary bits;
[0057] Perform a bitwise XOR operation on the binary sequence and the string to generate the corresponding XOR result sequence;
[0058] The XOR result sequence is divided into 32 subsequences in groups of 8 bits, and parity check bits are inserted into each subsequence and then reassembled to generate the corresponding independent encryption key.
[0059] Furthermore, the filtering module is specifically used for:
[0060] Extract the timestamp field and the requester's digital signature from the access request, convert the timestamp field to a Unix timestamp value, and perform an XOR operation with the first 32 bits of the requester's digital signature to generate a verification value;
[0061] The system queries the preset time window parameters in the filtering gateway and determines whether the difference between the current system time and the request timestamp is within the window range, while also verifying the validity of the requester's digital signature.
[0062] For access requests that pass time verification and signature verification, the operation instruction code contained therein is parsed and compared with the preset set of legal instruction codes in the core storage pool. Only when the instruction code matches is the access request allowed to pass and the corresponding operation executed.
[0063] Furthermore, the filtering module is specifically used for:
[0064] Extract a 16-byte instruction marker segment from the protocol header of the access request, and split the instruction marker segment into two 8-byte fields based on odd and even bits;
[0065] Perform a hash operation on each of the two byte segments to generate two 16-byte hash values, and concatenate the first 8 bytes of the former hash value with the last 8 bytes of the latter hash value to form an instruction signature.
[0066] The instruction signature is converted into a 64-bit decimal value and matched with a preset instruction code mapping table in the core storage pool to extract the corresponding operation instruction code from the instruction code mapping table.
[0067] The third aspect of the present invention proposes:
[0068] A computer includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the electronic record storage method as described above.
[0069] The fourth aspect of the present invention proposes:
[0070] A readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the electronic record storage method as described above.
[0071] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description
[0072] Figure 1 A flowchart of the electronic archive storage method provided in the first embodiment of the present invention;
[0073] Figure 2 This is a structural block diagram of an electronic archive storage system provided in the third embodiment of the present invention.
[0074] The following detailed description, in conjunction with the accompanying drawings, will further illustrate the present invention. Detailed Implementation
[0075] To facilitate understanding of the present invention, a more complete description will be given below with reference to the accompanying drawings. Several embodiments of the invention are illustrated in the drawings. However, the invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete.
[0076] It should be noted that when a component is said to be "fixed to" another component, it can be directly on the other component or there may be an intervening component. When a component is said to be "connected to" another component, it can be directly connected to the other component or there may be an intervening component. The terms "vertical," "horizontal," "left," "right," and similar expressions used in this document are for illustrative purposes only.
[0077] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.
[0078] Please see Figure 1 The figure shows an electronic archive storage method provided in the first embodiment of the present invention. The electronic archive storage method provided in this embodiment can greatly improve the confidentiality performance of electronic archives and correspondingly improve the storage efficiency of electronic archives.
[0079] Specifically, this embodiment provides:
[0080] An electronic record storage method, characterized in that the method includes:
[0081] Step S10: Create corresponding core storage pools in real time based on several heterogeneous server clusters, and receive the original electronic files input by the user in real time.
[0082] It should be noted that the heterogeneous server cluster provided by this invention refers to a cluster composed of servers with different hardware architectures (such as x86, ARM), operating systems (such as Linux, Windows Server), or storage protocols (such as iSCSI, NFS). By real-time monitoring of the storage capacity, read / write speed, and load status of each server in the cluster, available storage resources are integrated into a "core storage pool," enabling unified scheduling and elastic scaling of storage resources (for example, when a server is overloaded, data is automatically migrated to a less overloaded node). Based on this, when a user uploads original electronic files through a client (such as a web browser or desktop application), the system first performs format verification on the files (such as verifying the integrity of PDF, DOCX, etc., to prevent corrupted files from entering the storage process), and then temporarily stores the files in a cache area, awaiting subsequent splitting and encryption processing. It should be pointed out that the heterogeneous cluster design can reduce the risk of single point of failure (if one type of server goes down due to hardware compatibility issues, other types of servers can continue to provide services), and the core storage pool lays the foundation for subsequent distributed data storage, avoiding capacity bottlenecks or security risks caused by centralized data storage. The above methods lay the foundation for subsequent encryption, facilitating subsequent processing.
[0083] Step S20: Based on the content correlation in the original electronic file, the original electronic file is divided into several data segments, and an independent encryption key adapted to each data segment is generated in real time to generate the corresponding encrypted data segment in real time.
[0084] It should be noted that the content correlation provided by this invention can be understood as the logical correlation of data within the archive (e.g., in a contract archive, "Party A Information," "Clause Text," and "Signature Page" are correlated due to business logic; in a "Financial Statement," "Revenue Data" and "Cost Data" are correlated due to statistical dimensions). During the splitting process, these correlation dimensions must first be identified, and then the archive is divided into several independent and logically complete data fragments. Based on this, an independent encryption key is generated for each data fragment, rather than using a unified key, which avoids the risk of "a single key leak leading to the leakage of the entire archive," meeting the secure storage requirements of electronic archives (especially those involving privacy or confidentiality). This method allows the whole to be divided into several individual parts for subsequent processing.
[0085] Step S30: Distribute and store each encrypted data fragment in several groups of heterogeneous server clusters, and set a corresponding filtering gateway at the access entry of the core storage pool.
[0086] It should be noted that encrypted data fragments are distributed to a heterogeneous server cluster according to preset rules (such as "each fragment is stored on at least 3 servers with different architectures"). Disaster recovery is achieved through "data sharding + multi-node backup" (for example, if one server node fails, the complete fragment can be recovered from other nodes). Simultaneously, the system records the storage location index of each fragment (such as server IP and storage path) for quick location during subsequent retrieval. It is also important to point out that the filtering gateway provided by this invention is a "security protection layer" deployed at the core storage pool access point, combining authentication, request filtering, and anomaly interception functions. Essentially, it performs preliminary screening of external access requests through preset rules (such as a legitimate IP whitelist and request frequency thresholds) to prevent illegal requests (such as malicious attacks and unauthorized reading) from entering the storage pool. This method effectively improves the confidentiality of electronic records, avoids the risk of external cracking, and facilitates subsequent processing.
[0087] Step S40: The received access requests are filtered in real time through the filtering gateway to complete the storage of the original electronic files.
[0088] It should be noted that when an access request (such as reading, modifying, or deleting a file) reaches the filtering gateway, the gateway first performs multi-dimensional verification of the request (such as the requester's identity, operation permissions, and the legality of the request content). Only requests that pass the verification can trigger subsequent operations. For example, if a requester does not have file modification permissions, the gateway will directly reject the request and log it. It should also be pointed out that the storage provided by this invention does not only refer to storing data fragments on the server, but also includes three stages: "index recording" (storing fragment locations and associations), "security verification" (confirming that all fragments are encrypted correctly and backed up completely), and "status update" (marking the file as "accessible"), ensuring that the file can be retrieved securely and completely later. This method significantly improves the confidentiality of electronic files, correspondingly increasing their storage efficiency.
[0089] Second Embodiment
[0090] Furthermore, the step of dividing the original electronic file into several data segments based on the content correlation in the original electronic file includes:
[0091] The original electronic archives are subjected to structured scanning to identify metadata fields containing related information, and a metadata index table adapted to the metadata fields is established.
[0092] Based on the association relationships recorded in the metadata index table, calculate the association metric value between any two information units in the metadata index table;
[0093] According to the correlation metric values from high to low, each information unit is sequentially aggregated into a data segment, wherein the cumulative correlation of the information units in each data segment is not less than a preset threshold.
[0094] It's important to note that differentiated scanning methods are used for different types of electronic archives: for example, for structured archives (such as Excel spreadsheets and database files), metadata such as table headers, field names, and data types are directly extracted; for unstructured archives (such as PDF documents and images), text content is extracted using OCR (Optical Character Recognition), and then key metadata such as "title," "author," and "date" are identified (e.g., in a PDF contract, "contract number" and "signing date" are metadata fields). Based on this, the identified metadata fields are recorded in the format of "archive ID - field name - field value - location information" (e.g., archive ID is "DOC20250828001," field name is "Party A Name," field value is "XX Company," and location information is "page 3, paragraph 2"), forming a metadata index table. This table is equivalent to a "catalog" for the archives, providing a data foundation for subsequent correlation calculations. It should be noted that the information unit provided in this invention is the smallest logical unit in the metadata index table. For example, "Party A's Name" and "Party A's Address" can be considered as two related information units, and "Contract Amount" and "Payment Method" can also be considered as a group of related units. Based on this, by quantifying the degree of correlation, it can be determined which information units should be classified into the same data segment (e.g., units with high correlation should be kept together to avoid logical breakage after splitting). For example, the correlation between "Party A's Name" and "Party A's Address" is much higher than that between "Party A's Name" and "Party B's Payment Method," and they should be classified into different segments. On this basis, information units are sorted from high to low according to the correlation quantification value, and then classified into segments in turn, until the cumulative correlation of all information units in the segment reaches a preset threshold (e.g., if the threshold is set to 0.8, and the cumulative correlation of the first 3 units is 0.75, a 4th unit needs to be added to make the sum reach 0.82 before stopping aggregation). It's important to note that the preset threshold needs to balance "fragment integrity" and "storage flexibility." Specifically, a threshold that's too high (e.g., 0.9) will result in excessively large fragments, reducing the security of distributed storage; a threshold that's too low (e.g., 0.6) will lead to too many fragments, increasing the complexity of index management. The threshold is typically adjusted based on the file type. For example, legal documents, due to their high logical rigor requirements, can have a threshold set to 0.85, while ordinary office documents can have a threshold set to 0.7. Based on this, after aggregation, the system will perform a "logical integrity check" on each fragment (e.g., checking whether the fragment contains key metadata to avoid incomplete fragments such as "only the client's name but no address"), ensuring that each fragment can independently reflect a complete logical module of the original file. This method effectively completes the splitting of electronic files, facilitating subsequent processing.
[0095] Furthermore, the step of calculating the correlation metric between any two information units in the metadata index table based on the correlation relationships recorded in the metadata index table includes:
[0096] Extract the timestamp field of any two information units in the metadata index table, calculate the corresponding time difference based on the timestamp field, and convert the time difference into a time correlation coefficient. The smaller the time difference, the larger the time correlation coefficient.
[0097] Identify the subject identifier field contained in any two information units. If the subject identifiers are completely identical, assign a first subject coefficient; if they are partially identical, assign a second subject coefficient; if they are completely different, assign a zero value.
[0098] The time correlation coefficient and the main coefficient are superimposed and calculated according to a preset weight ratio to calculate the correlation quantification value between any two information units in real time.
[0099] It should be noted that the timestamp field of the information unit provided by this invention includes "creation time", "modification time", and "related event time". For example, in a contract file, the modification time of "Party A's name" is "2025-08-28 10:00", and the modification time of "Party A's address" is "2025-08-28 10:05". The timestamps of the two can be used to calculate the correlation. Based on this, the difference between the timestamps of the two information units is first calculated (e.g., the difference is 5 minutes in the example above), and then the difference is converted into a time correlation coefficient using a preset formula. For example, the "exponential decay formula" is used: Time correlation coefficient = e^(-k×Δt), where k is the decay coefficient (e.g., k=0.1), and Δt is the time difference (unit: minutes). If Δt=5, then the time correlation coefficient = e^(-0.1×5)≈0.606; if Δt=1, then the coefficient ≈0.905. This formula ensures that "the closer the time, the higher the correlation," which aligns with the actual business principle that "information modified within the same time period is usually more correlated." Based on this, the present invention will perform subsequent judgment processing. Specifically, the subject identifier field provided by the present invention is a key field used to distinguish the subject to which information belongs. For example, "Party A Name" and "Party B Name" in contract files, and "Department Number" and "Employee ID" in financial files. When the subject identifiers of two information units are completely identical (e.g., "Party A Name = XX Company" and "Party A Address = XX Street"), it indicates that they belong to the same subject and have a very strong correlation, so a value of 1.0 is assigned accordingly. Conversely, when the subject identifiers are partially identical (e.g., "Party A Name = XX Group Headquarters" and "Party A Name = XX Group Branch," indicating a subordinate relationship between the subjects), the correlation is moderate, so a value of 0.5 is assigned accordingly. Furthermore, when the subject identifiers are completely inconsistent (e.g., "Party A Name = XX Company" and "Party B Name = YY Company"), the correlation is extremely weak, so a value of 0 is assigned. Based on this, the weights of the time correlation coefficient and the subject coefficient are set according to business needs. For example, for "time-sensitive files" (such as press releases and real-time reports), the time weight is set to 0.6 and the subject weight is set to 0.4; for "files with priority in subject correlation" (such as contracts and personnel files), the subject weight is set to 0.7 and the time weight is set to 0.3. This method provides a quantitative basis for subsequent file splitting, facilitating subsequent processing.
[0100] Furthermore, the step of generating an independent encryption key adapted to each data fragment in real time to generate the corresponding encrypted data fragment in real time includes:
[0101] Extract a 256-byte content fragment from each data segment as the base material for key generation, and simultaneously record the starting offset address of the content fragment in the data segment;
[0102] A hash operation is performed on the key generation base material to obtain a 512-bit hash value, and the first 256 bits are used as the initial key and the last 256 bits are used as the key verification code.
[0103] The initial key and the starting offset address of the data segment are XORed bitwise to generate the independent encryption key, and the data segment is encrypted using the independent encryption key to generate the encrypted data segment.
[0104] It's important to note that extracting a consecutive 256-byte content segment from each data fragment, rather than randomly, ensures consistency in the extracted material for the same data fragment each time (random extraction could lead to unstable key generation). The 256-byte length is chosen because it contains sufficient fragment characteristics (avoiding the possibility of different fragments generating the same key due to excessively short material) without increasing the computational burden due to excessively long material. The starting offset address refers to the starting position of the 256-byte content segment within the data fragment (e.g., if the total length of the data fragment is 1024 bytes, and the extracted 256 bytes start from byte 128, then the starting offset address is 128). Recording this address allows for the integration of this "address information" into the key during subsequent key generation, further enhancing key uniqueness (even if two fragments have the same 256-byte content, different starting offset addresses will result in different final keys). Therefore, the SHA-512 hash algorithm (which generates a 512-bit hash value) is typically used. This algorithm has "collision resistance" (it is difficult to find two different inputs that generate the same hash value) and "irreversibility" (it is impossible to deduce the original input from the hash value), ensuring the security of the underlying materials. Furthermore, the first 256 bits of the 512-bit hash value are used as the initial key (used for subsequent encryption of data segments), and the last 256 bits are used as the key verification code (used for subsequent key verification, such as verifying whether the verification code matches the original value during decryption to prevent key tampering). For example, if the 512-bit hash value is "ABCDEFG... (512 bits in total)," then the first 256 bits "ABC... (256 bits)" are the initial key, and the last 256 bits "DEFG... (256 bits)" are the verification code. Based on this, leveraging the XOR operation's property of "0 for the same, 1 for different," the initial key is XORed with the starting offset address. This incorporates "address information" into the key, strongly binding the key to the storage location of the data segment. Therefore, even if the initial key is leaked, the final encryption key cannot be recovered without the starting offset address. Furthermore, the AES-256 algorithm (matched with a 256-bit independent encryption key) is typically used to encrypt the data segment. This algorithm is symmetric encryption (using the same key for encryption and decryption), offering fast encryption speed and suitability for encrypting large amounts of data. After encryption, the system verifies the key integrity using a key verification code (e.g., checking if the key has been tampered with during encryption) and also verifies the integrity of the encrypted data segment (e.g., calculating the MD5 value of the segment, recording this value during storage, and recalculating and comparing it during retrieval to ensure the segment is not corrupted). These methods effectively encrypt the data, facilitating subsequent processing.
[0105] Furthermore, the step of performing a bitwise XOR operation between the initial key and the starting offset address of the data segment to generate the corresponding independent encryption key includes:
[0106] The starting offset address is converted into a hexadecimal string, and the string is converted into a binary sequence, where each hexadecimal character corresponds to 4 binary bits;
[0107] Perform a bitwise XOR operation on the binary sequence and the string to generate the corresponding XOR result sequence;
[0108] The XOR result sequence is divided into 32 subsequences in groups of 8 bits, and parity check bits are inserted into each subsequence and then reassembled to generate the corresponding independent encryption key.
[0109] It's important to note that the starting offset address is typically stored as a decimal value (e.g., 128), which is first converted to a hexadecimal string (e.g., 128 becomes "80"). Hexadecimal is chosen because each bit corresponds to 4 binary digits, facilitating subsequent binary sequence processing, and hexadecimal representation is more concise (reducing character length compared to binary). The hexadecimal string is then converted to a binary sequence according to the rule "1 hexadecimal bit = 4 binary digits". For example, the hexadecimal "80" is converted to the binary "10000000" (8 bits); if the hexadecimal string is "1A3", it is converted to "000110100011" (12 bits, padded with leading zeros if less than a multiple of 4 to ensure each hexadecimal bit corresponds to 4 binary digits). Based on this, the two binary sequences are aligned bit-by-bit, and an XOR operation is performed bit-by-bit. For example, the starting offset address in binary is "10000000", and the ASCII binary representation of the hexadecimal character "8" is "00111000". The XOR result is "10111000". This step merges the "numerical information of the address" with the "character encoding information of the address", further enhancing the uniqueness of the key. The XOR result sequence is divided into 32 subsequences in groups of 8 bits each (since the independent encryption key requires 256 bits, 32 groups × 8 bits = 256 bits). If the length of the XOR result sequence is less than 256 bits, it is padded with trailing zeros; if it exceeds 256 bits, the first 256 bits are truncated (ensuring the final key length is fixed at 256 bits, compatible with the AES-256 encryption algorithm). Based on this, for each 8-bit subsequence, the number of "1"s is calculated: if the number is odd, one "1" is inserted as a check bit (making the total number even); if the number is even, one "0" is inserted as a check bit. For example, the subsequence "10111000" contains 4 "1"s (an even number). After inserting "0"s, it becomes the 9-bit "101110000". The purpose of inserting parity bits is to detect bit errors during key transmission or storage (such as a bit changing from "1" to "0"; the parity of the number of "1"s can be detected during verification). Finally, the 32 subsequences with parity bits inserted (each 9 bits) are concatenated to form the final 288-bit independent encryption key. This method effectively encrypts each data segment, facilitating subsequent processing.
[0110] Furthermore, the step of performing real-time filtering processing on the received access requests through the filtering gateway to complete the storage of the original electronic files includes:
[0111] Extract the timestamp field and the requester's digital signature from the access request, convert the timestamp field to a Unix timestamp value, and perform an XOR operation with the first 32 bits of the requester's digital signature to generate a verification value;
[0112] The system queries the preset time window parameters in the filtering gateway and determines whether the difference between the current system time and the request timestamp is within the window range, while also verifying the validity of the requester's digital signature.
[0113] For access requests that pass time verification and signature verification, the operation instruction code contained therein is parsed and compared with the preset set of legal instruction codes in the core storage pool. Only when the instruction code matches is the access request allowed to pass and the corresponding operation executed.
[0114] It's important to note that two key pieces of information are extracted from the access request: a timestamp field (e.g., "2025-08-28T10:00:00"), which is then converted to a Unix timestamp in real time (e.g., 1724805600, accurate to the second). Additionally, the requester's digital signature (e.g., a 256-bit signature generated based on the requester's private key) is simultaneously obtained. The first 32 bits (4 bytes) are taken, and the Unix timestamp (integer) is converted to 32 bits of binary. This 32 bits are then XORed with the first 32 bits of the signature to generate a 32-bit verification value. This value serves as an auxiliary basis for subsequent time verification to prevent timestamp tampering. Correspondingly, the filtering gateway uses a preset time window parameter (e.g., ±5 minutes) to calculate the difference between "current system time - request timestamp." If the difference is within the window, the time verification passes (to prevent replay attacks, i.e., attackers reusing expired requests). For example, if the current timestamp is 1724805900 and the request timestamp is 1724805600, the difference is 300 seconds (5 minutes), which meets the window requirement. The digital signature is decrypted using the requester's public key and compared with the hash value of the request content. Specifically, if they match, the signature is valid (confirming the requester's identity is legitimate and the content has not been tampered with). Conversely, if they do not match, the request is rejected and an exception log is recorded (potentially a forged request). It should be noted that the instruction code is the "operation type identifier" of the access request (e.g., "0x01" represents read, "0x02" represents modify). The core storage pool presets a set of valid instruction codes (e.g., only allowing 0x01, 0x02, and 0x03), and prohibits high-risk instructions (e.g., 0xFF represents batch deletion). Based on this, for requests that pass the first two checks, their operation instruction codes are parsed and compared with the valid code set. Specifically, if they match, access is allowed; if they do not match, access is blocked. This effectively filters each user's access requests for subsequent processing.
[0115] Furthermore, the step of parsing the operation instruction code contained in the access request that has passed time verification and signature verification includes:
[0116] Extract a 16-byte instruction marker segment from the protocol header of the access request, and split the instruction marker segment into two 8-byte fields based on odd and even bits;
[0117] Perform a hash operation on each of the two byte segments to generate two 16-byte hash values, and concatenate the first 8 bytes of the former hash value with the last 8 bytes of the latter hash value to form an instruction signature.
[0118] The instruction signature is converted into a 64-bit decimal value and matched with a preset instruction code mapping table in the core storage pool to extract the corresponding operation instruction code from the instruction code mapping table.
[0119] It should be noted that the 16-byte instruction marker segment is located in the protocol header of the access request (such as a custom header field in an HTTP request, or a specific offset position in a TCP packet) and is used to uniquely identify the operation type. Based on this, the data is split according to the parity of the byte positions. Specifically, odd-numbered bytes form the first 8-byte field, and even-numbered bytes form the second 8-byte field. A hash operation is performed on each of the two 8-byte fields, and the first 16 bytes are taken as the result. The first 8 bytes of the first hash value and the last 8 bytes of the second hash value are concatenated to form a 16-byte instruction signature. The 16-byte instruction signature is converted into a 64-bit decimal value. If the signature has a corresponding entry in the mapping table, the operation instruction code is extracted; otherwise, it is determined to be an illegal instruction, and the request is rejected. This method can significantly improve the confidentiality of electronic records and correspondingly improve their storage efficiency.
[0120] Please see Figure 2 The third embodiment of the present invention provides:
[0121] An electronic record storage system, wherein the system comprises:
[0122] The creation module is used to create corresponding core storage pools in real time based on several heterogeneous server clusters, and to receive raw electronic files input by users in real time.
[0123] The splitting module is used to split the original electronic file into several data segments according to the content correlation in the original electronic file, and generate an independent encryption key that matches each data segment in real time, so as to generate the corresponding encrypted data segment in real time.
[0124] The storage module is used to distribute and store each encrypted data fragment within several heterogeneous server clusters, and to set a corresponding filtering gateway at the access entry of the core storage pool.
[0125] The filtering module is used to perform real-time filtering processing on the access requests received in real time through the filtering gateway, so as to complete the storage of the original electronic files accordingly.
[0126] Furthermore, the splitting module is specifically used for:
[0127] The original electronic archives are subjected to structured scanning to identify metadata fields containing related information, and a metadata index table adapted to the metadata fields is established.
[0128] Based on the association relationships recorded in the metadata index table, calculate the association metric value between any two information units in the metadata index table;
[0129] According to the correlation metric values from high to low, each information unit is sequentially aggregated into a data segment, wherein the cumulative correlation of the information units in each data segment is not less than a preset threshold.
[0130] Furthermore, the splitting module is specifically used for:
[0131] Extract the timestamp field of any two information units in the metadata index table, calculate the corresponding time difference based on the timestamp field, and convert the time difference into a time correlation coefficient. The smaller the time difference, the larger the time correlation coefficient.
[0132] Identify the subject identifier field contained in any two information units. If the subject identifiers are completely identical, assign a first subject coefficient; if they are partially identical, assign a second subject coefficient; if they are completely different, assign a zero value.
[0133] The time correlation coefficient and the main coefficient are superimposed and calculated according to a preset weight ratio to calculate the correlation quantification value between any two information units in real time.
[0134] Furthermore, the splitting module is specifically used for:
[0135] Extract a 256-byte content fragment from each data segment as the base material for key generation, and simultaneously record the starting offset address of the content fragment in the data segment;
[0136] A hash operation is performed on the key generation base material to obtain a 512-bit hash value, and the first 256 bits are used as the initial key and the last 256 bits are used as the key verification code.
[0137] The initial key and the starting offset address of the data segment are XORed bitwise to generate the independent encryption key, and the data segment is encrypted using the independent encryption key to generate the encrypted data segment.
[0138] Furthermore, the splitting module is specifically used for:
[0139] The starting offset address is converted into a hexadecimal string, and the string is converted into a binary sequence, where each hexadecimal character corresponds to 4 binary bits;
[0140] Perform a bitwise XOR operation on the binary sequence and the string to generate the corresponding XOR result sequence;
[0141] The XOR result sequence is divided into 32 subsequences in groups of 8 bits, and parity check bits are inserted into each subsequence and then reassembled to generate the corresponding independent encryption key.
[0142] Furthermore, the filtering module is specifically used for:
[0143] Extract the timestamp field and the requester's digital signature from the access request, convert the timestamp field to a Unix timestamp value, and perform an XOR operation with the first 32 bits of the requester's digital signature to generate a verification value;
[0144] The system queries the preset time window parameters in the filtering gateway and determines whether the difference between the current system time and the request timestamp is within the window range, while also verifying the validity of the requester's digital signature.
[0145] For access requests that pass time verification and signature verification, the operation instruction code contained therein is parsed and compared with the preset set of legal instruction codes in the core storage pool. Only when the instruction code matches is the access request allowed to pass and the corresponding operation executed.
[0146] Furthermore, the filtering module is specifically used for:
[0147] Extract a 16-byte instruction marker segment from the protocol header of the access request, and split the instruction marker segment into two 8-byte fields based on odd and even bits;
[0148] Perform a hash operation on each of the two byte segments to generate two 16-byte hash values, and concatenate the first 8 bytes of the former hash value with the last 8 bytes of the latter hash value to form an instruction signature.
[0149] The instruction signature is converted into a 64-bit decimal value and matched with a preset instruction code mapping table in the core storage pool to extract the corresponding operation instruction code from the instruction code mapping table.
[0150] The fourth embodiment of the present invention provides a computer, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the electronic document storage method as described above.
[0151] The fifth embodiment of the present invention provides a readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the electronic record storage method as described above.
[0152] In summary, the electronic record storage method and system provided by the above embodiments of the present invention can significantly improve the confidentiality performance of electronic records and correspondingly improve the storage efficiency of electronic records.
[0153] It should be noted that the above modules can be functional modules or program modules, and can be implemented through software or hardware. For modules implemented through hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination.
[0154] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-including system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.
[0155] More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.
[0156] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.
[0157] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.
[0158] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the appended claims.
Claims
1. An electronic archive storage method, characterized by, The method comprises: According to several groups of heterogeneous server clusters, real-time core storage pools are created, and real-time user input original electronic archives are received; According to the content correlation in the original electronic archives, the original electronic archives are correspondingly split into several data segments, and independent encryption keys adapted to each data segment are generated in real time to generate corresponding encrypted data segments in real time; Each encrypted data segment is stored in several groups of the internal heterogeneous server clusters, and a corresponding filtering gateway is set at the access entrance of the core storage pool; Through the filtering gateway, real-time filtering processing is performed on the real-time received access request to correspondingly complete the storage of the original electronic archives; The step of splitting the original electronic archives into several data segments according to the content correlation in the original electronic archives comprises: Structural scanning is performed on the original electronic archives to identify metadata fields containing correlation information, and a metadata index table adapted to the metadata fields is established; Based on the correlation relationship recorded in the metadata index table, the correlation quantization value between any two information units in the metadata index table is calculated; According to the order from high to low of the correlation quantization value, each information unit is aggregated into the data segment in turn, wherein the cumulative correlation sum of the information units in each data segment is not less than a preset threshold; The step of calculating the correlation quantization value between any two information units in the metadata index table based on the correlation relationship recorded in the metadata index table comprises: Extract the timestamp field of any two information units in the metadata index table, and calculate the corresponding time difference value according to the timestamp field, and convert the time difference value into a time correlation coefficient, wherein the smaller the time difference value is, the larger the time correlation coefficient is; Identify the subject identifier field contained in any two information units, wherein if the subject identifier is completely consistent, a first subject coefficient is given, if it is partially consistent, a second subject coefficient is given, and if it is completely inconsistent, a zero value is given; The time correlation coefficient and the subject coefficient are superimposed and calculated according to a preset weight ratio to calculate the correlation quantization value between any two information units in real time.
2. The electronic archival storage method of claim 1, wherein: The step of generating an independent encryption key adapted to each data segment in real time to generate a corresponding encrypted data segment comprises: Extracting a continuous 256-byte content segment from each data segment as a key generation base material, and recording the starting offset address of the content segment in the data segment at the same time; Performing a hash operation on the key generation base material to obtain a 512-bit hash value, and taking the first 256 bits as an initial key and the last 256 bits as a key verification code; The initial key and the starting offset address of the data segment are XORed bit by bit to correspondingly generate the independent encryption key, and the data segment is encrypted by the independent encryption key to correspondingly generate the encrypted data segment.
3. The electronic archival storage method of claim 2, wherein: The step of performing XOR operation between the initial key and the start offset address of the data segment includes: Converting the start offset address into a hexadecimal string, and converting the string into a binary sequence, wherein each hexadecimal character corresponds to 4-bit binary number; Performing XOR operation between the binary sequence and the string to generate a corresponding XOR result sequence; Dividing the XOR result sequence into 32 subsequences by 8 bits each, and reassembling each subsequence by inserting parity check bit to generate the independent encryption key.
4. The electronic archival storage method of claim 1, wherein: The step of performing real-time filtering processing on the access request received in real time through the filter gateway to complete the storage of the original electronic file includes: Extracting the timestamp field and requester digital signature in the access request, and converting the timestamp field into Unix timestamp value, and performing XOR operation between the first 32 bits of the requester digital signature to generate verification value; Querying the preset time window parameter in the filter gateway, and judging whether the difference between the current system time and the request timestamp is within the window range, and verifying the validity of the requester digital signature; For the access request that passes the time verification and signature verification, parsing the operation instruction code contained therein, and comparing it with the preset legal instruction code set in the core storage pool, and only when the instruction code matches, the access request is allowed to pass and the corresponding operation is executed.
5. The electronic archival storage method of claim 4, wherein: The step of parsing the operation instruction code contained in the access request that passes the time verification and signature verification includes: Extracting a 16-byte instruction mark segment from the protocol header of the access request, and splitting the instruction mark segment into two 8-byte fields according to odd and even bits; Performing hash operation on the two byte subsegments respectively to generate two 16-byte hash values, and taking the first 8 bytes of the former hash value and the last 8 bytes of the latter hash value to form an instruction feature code; Converting the instruction feature code into a 64-bit decimal number, and matching it with the preset instruction code mapping table in the core storage pool to extract the operation instruction code in the instruction code mapping table.
6. An electronic archive storage system characterized by The system for implementing the electronic file storage method according to any one of claims 1 to 5 includes: A creation module for creating a corresponding core storage pool in real time according to a plurality of groups of heterogeneous server clusters, and receiving an original electronic file input by a user in real time; A splitting module for splitting the original electronic file into a plurality of data segments according to the content correlation in the original electronic file, and generating an independent encryption key adapted to each data segment in real time to generate a corresponding encrypted data segment; A storage module for storing each encrypted data segment in the internal of a plurality of groups of heterogeneous server clusters, and setting a corresponding filter gateway at the access entrance of the core storage pool; A filtering module for performing real-time filtering processing on the access request received in real time through the filter gateway to complete the storage of the original electronic file.
7. A computer comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor implements the electronic archive storage method as claimed in any one of claims 1 to 5 when executing the computer program.
8. A readable storage medium, having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the electronic archive storage method as claimed in any one of claims 1 to 5.
Citation Information
Patent Citations
Health data encryption storage method and device, equipment and storage medium
CN120582779A