Data management methods, devices and electronic equipment

Abstract

This disclosure provides a data management method, apparatus, and electronic device. One specific embodiment of the method includes: a data provider encrypting preset data segments to obtain an encrypted data sequence, and then performing secondary encryption on the encrypted data sequence to obtain ciphertext data, generating a first transfer record associated with the current address; sending the data hash value, ciphertext data, and the first transfer record to a data transfer end; a data receiver, after receiving the data hash value and ciphertext data from the data transfer end, decrypting the ciphertext data to obtain a restored encrypted data sequence, and verifying the validity of the restored encrypted data sequence; retrieving the first transfer record and a second transfer record from the data transfer end, and verifying the validity of the first and second transfer records; and, when both the restored encrypted data sequence, the first transfer record, and the second transfer record are verified to be valid, distributing the ciphertext data for storage. This embodiment can securely and effectively encrypt and store data.

Description

Technical Field

[0001] The embodiments of this application relate to the field of data processing technology, and more particularly to a data management method, apparatus, and electronic device. Background Technology

[0002] In the relevant data management methods, there are problems with insufficient data security. On the one hand, centralized storage is usually adopted in data storage and management. In centralized data management, once the central server is compromised, it may lead to large-scale data leakage or tampering. Furthermore, there is a lack of effective anti-tampering mechanisms in centralized data management.

[0003] On the other hand, in a distributed data management approach, data often needs to be transferred during use. That is, data needs to be transmitted and stored according to demand. However, data may be maliciously modified during transmission and storage. In related distributed data management, the transfer process lacks transparency and traceability. That is, it is difficult to effectively track the source and destination of data, making it difficult to promptly detect leaks or tampering during the data transfer process through tracing. Summary of the Invention

[0004] In view of this, embodiments of the present disclosure provide data management methods, apparatus, and electronic devices.

[0005] In a first aspect, embodiments of this disclosure provide a data management method applied to a data management system, the data management system including a data provider, a data receiver, a data storage provider, and at least one data transfer provider;

[0006] The method includes:

[0007] The data provider encrypts the preset data segments to obtain an encrypted data sequence;

[0008] The data provider determines the data hash value of the encrypted data sequence;

[0009] The data provider performs a second encryption on the encrypted data sequence to obtain ciphertext data;

[0010] The data provider uses the data hash value to generate a first transfer record associated with the current address of the data provider, and stores it in the data storage terminal;

[0011] The data provider sends the data hash value and the encrypted data to the data transfer end;

[0012] The data transfer terminal uses the data hash value to generate a second transfer record associated with the current address of the data transfer terminal, and stores it in the data storage terminal;

[0013] The data transfer end sends the data hash value and the ciphertext data to the next data transfer end or the data receiving end;

[0014] The data receiving end decrypts the ciphertext data to obtain the restored encrypted data sequence;

[0015] The data receiving end determines the restored hash value of the restored encrypted data sequence;

[0016] The data receiving end verifies whether the restored hash value is consistent with the data hash value;

[0017] In response to verifying that the restored hash value is consistent with the data hash value, the data receiving end retrieves the first flow record and the second flow record from the data storage end, and determines the restored root hash of each of the first flow record and the second flow record;

[0018] The data receiving end verifies whether each restored root hash is consistent with the data hash value;

[0019] In response to verifying that each restore root hash is consistent with the data hash value, the data receiving end performs distributed storage of the ciphertext data.

[0020] In some optional implementations, the data provider encrypts preset data segments to obtain an encrypted data sequence, including:

[0021] The data provider divides the preset data into multiple data blocks and the preset private key into a corresponding number of sub-private keys;

[0022] The data provider uses each sub-private key to perform asymmetric encryption on each data block, resulting in multiple encrypted data blocks;

[0023] The data provider combines the encrypted data blocks into an encrypted data sequence.

[0024] In some alternative implementations, the data provider determines the data hash value of the encrypted data sequence, including:

[0025] The data provider calculates the hash value of each encrypted data block in the encrypted data sequence;

[0026] The data provider merges the hash values ​​of each data block to obtain the data hash value.

[0027] In some optional implementations, the data provider performs secondary encryption on the encrypted data sequence to obtain ciphertext data, including:

[0028] The data provider generates the symmetric key;

[0029] The data provider uses a majority of symmetric keys to symmetrically encrypt the encrypted data sequence.

[0030] In some alternative implementations, the encrypted data is stored in a distributed manner, including:

[0031] The data receiving end uses a pre-trained encrypted data analysis model to perform data analysis on the encrypted data and obtain the data analysis results;

[0032] The data receiving end uses a pre-trained data flow analysis model to perform data flow analysis on all flow records and obtain the flow analysis results.

[0033] The data receiving end uses a pre-trained resource allocation model to generate a resource allocation strategy based on encrypted data, data analysis results, and flow analysis results. The resource allocation strategy is used to guide the storage of encrypted data.

[0034] The data receiving end divides the encrypted data into multiple data fragments and performs distributed storage on each data fragment according to the resource allocation strategy.

[0035] Secondly, embodiments of this disclosure provide a data management device, which includes: a data providing module, a data transfer module, and a data receiving module;

[0036] The data providing module is configured to encrypt preset data segments through the data providing end to obtain an encrypted data sequence, determine the data hash value of the encrypted data sequence, perform secondary encryption on the encrypted data sequence to obtain ciphertext data, generate a first transfer record associated with the current address of the data providing end using the data hash value, and store it in the data storage end, send the data hash value and ciphertext data to the data transfer end, generate a second transfer record associated with the current address of the data transfer end using the data hash value, and store it in the data storage end;

[0037] The data transfer module is configured to send the data hash value and encrypted data to the next data transfer end or data receiving end.

[0038] The data receiving module is configured to decrypt the encrypted data to obtain the restored encrypted data sequence, determine the restored hash value of the restored encrypted data sequence, verify whether the restored hash value is consistent with the data hash value, and in response to verifying that the restored hash value is consistent with the data hash value, retrieve the first and second transfer records from the data storage terminal, determine the restored root hash of each of the first and second transfer records, verify whether each restored root hash is consistent with the data hash value, and in response to verifying that each restored root hash is consistent with the data hash value, perform distributed storage of the encrypted data.

[0039] In some alternative implementations, the data providing module is further configured to:

[0040] The preset data is divided into multiple data blocks by the data provider, and the preset private key is divided into a corresponding number of sub-private keys;

[0041] The data provider uses each sub-private key to perform asymmetric encryption on each data block to obtain multiple encrypted data blocks.

[0042] The data provider combines the encrypted data blocks into an encrypted data sequence.

[0043] In some alternative implementations, the data providing module is further configured to:

[0044] The data provider calculates the hash value of each encrypted data block in the encrypted data sequence;

[0045] The data provider merges the hash values ​​of each data block to obtain the data hash value.

[0046] In some alternative implementations, the data providing module is further configured to:

[0047] A symmetric key is generated through the data provider.

[0048] The data provider uses a majority of symmetric keys to symmetrically encrypt the encrypted data sequence.

[0049] In some optional implementations, the data receiving module is further configured to:

[0050] The encrypted data is analyzed by using a pre-trained encrypted data analysis model at the data receiving end to obtain the data analysis results.

[0051] The data receiver uses a pre-trained data flow analysis model to perform data flow analysis on all flow records and obtain the flow analysis results.

[0052] The data receiving end uses a pre-trained resource allocation model to generate a resource allocation strategy based on encrypted data, data analysis results, and flow analysis results. The resource allocation strategy is used to guide the storage of encrypted data.

[0053] The encrypted data is divided into multiple data fragments by the data receiving end, and each data fragment is distributed and stored according to the resource allocation strategy.

[0054] Thirdly, embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, which, when executed by the one or more processors, cause the one or more processors to implement the method described in any implementation of the first aspect.

[0055] Fourthly, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by one or more processors, implements the method as described in any implementation of the first aspect.

[0056] Fifthly, embodiments of this disclosure provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the method described in any of the implementations of the first aspect.

[0057] To address the issue of data leakage during data transfer, the data management method, apparatus, and electronic device provided in this disclosure perform segmented asymmetric encryption on preset data at the data provider end to generate a data hash value, and then perform secondary encryption using a symmetric key to form hybrid encryption, which significantly improves the security of encrypted data during transmission and storage. After decryption, the data receiver verifies the validity of the restored encrypted data sequence by using the received data hash value, thereby effectively preventing data tampering and leakage.

[0058] Furthermore, the data receiving end analyzes the flow process of encrypted data through a data flow analysis model, thereby effectively identifying potential risks and the data flow end or data provider that may pose a risk.

[0059] Furthermore, by using the generated restoration hash value, the data receiver can compare the received data hash value with the restoration hash value and verify whether they are consistent. Based on this, the first stage of local pre-verification of the restored encrypted data sequence can be completed. It can also use the first flow record stored at the data storage end by the data provider and the second flow record stored at the data storage end by the data transfer end to realize the next stage of blockchain verification. Through a phased and multi-level tiered data verification mechanism, the verification efficiency is guaranteed by local verification, reducing the cost of direct verification on the blockchain network. At the same time, the immutability of the blockchain network significantly enhances the data receiver's ability to verify the validity of the restored encrypted data sequence.

[0060] Furthermore, distributed storage effectively improves the utilization efficiency and reliability of storage resources. Attached Figure Description

[0061] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings. The drawings are for illustrative purposes only and are not intended to limit the invention. In the drawings:

[0062] Figure 1This is an exemplary system architecture diagram to which one embodiment of this disclosure may be applied;

[0063] Figure 2 A flowchart of one embodiment of the data management method according to this disclosure;

[0064] Figure 3 This is an exploded flowchart of another embodiment of phased verification performed on the data receiving end according to this disclosure;

[0065] Figure 4 This is a flowchart illustrating the decomposition of the encrypted data into distributed storage according to step 213 of this disclosure;

[0066] Figure 5 This is a schematic diagram of the structure of a data management device according to an embodiment of the present disclosure;

[0067] Figure 6 A schematic diagram of the structure of a computer system suitable for implementing embodiments of the present disclosure. Detailed Implementation

[0068] The present disclosure will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0069] As described in the background section, existing data management solutions are still insufficient to meet the needs of practical work.

[0070] In the course of implementing this application, the applicant discovered that data that requires strict management, such as financial data, may be maliciously modified during transmission and storage, and that tracing and verifying the originality and authenticity of financial data is also very important.

[0071] The applicant also found that the main problem with the relevant data management solutions is that when these solutions are applied to the management of financial data, there is usually a lack of effective anti-tampering mechanisms for the financial data, and it is also difficult to effectively track the flow of financial data.

[0072] On the one hand, relevant data management solutions often adopt a centralized storage model. However, this centralized storage model can pose security risks to data. Specifically, in a centralized storage model, if the central server storing financial data is compromised, it can lead to large-scale leakage or tampering of financial data, resulting in huge economic losses and reputational damage.

[0073] In view of this, the data management method proposed in the embodiments of this application performs hybrid encryption by segmented encryption and secondary encryption at the data provider end, which makes the confidentiality of the encrypted ciphertext data stronger. After transmitting the data hash value and ciphertext data obtained in the encryption process to the data receiver end at the same time, the data receiver end can use the data hash value to verify whether the restored encrypted data sequence or ciphertext data has been tampered with after decryption once.

[0074] On the other hand, centralized storage makes it difficult to trace financial data. Specifically, in centralized storage, the flow of financial data lacks transparency and traceability, making it difficult to effectively track the source and destination of financial data, which is not conducive to the auditing and supervision of financial data.

[0075] In view of this, the data management method proposed in this application stores the flow records of both the data provider and each data transfer end in the data storage end of the blockchain network. After the data receiver obtains each flow record from the data storage end, it can trace and locate whether the data provider and / or any data transfer end has been tampered with through each flow record, and realize the transparency and traceability of financial data.

[0076] On the other hand, the relevant data management solutions have low storage efficiency. Specifically, the centralized storage model is difficult to achieve efficient data sharding and distributed storage, resulting in low storage resource utilization and difficulty in coping with the challenge of rapid growth in financial data volume.

[0077] In view of this, the data management method proposed in the embodiments of this application, when storing encrypted data at the data receiving end, divides the encrypted data into multiple data fragments, thereby distributing and storing each data fragment in the blockchain network.

[0078] When applied to the management of financial data, related data management solutions also have other problems, such as poor real-time performance. Specifically, these solutions are inefficient when processing large amounts of financial data, failing to meet the needs of modern enterprises for real-time data analysis and leading to delayed decision-making.

[0079] Furthermore, the relevant data management solutions lack intelligent analysis. Specifically, when managing financial data, these solutions mainly rely on manual analysis and simple statistical methods, lacking the ability to deeply mine and intelligently analyze complex financial data, making it difficult to extract the potential value from the financial data.

[0080] In view of this, the data management method proposed in the embodiments of this application analyzes the encrypted data through an encrypted data analysis model before storing the encrypted data, and analyzes each flow record through a data flow analysis model, thereby realizing intelligent analysis of financial data and effectively improving the efficiency of processing large amounts of financial data.

[0081] It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other. This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0082] Figure 1 An exemplary system architecture 100 is shown, to which embodiments of the data management methods, apparatus, and electronic devices of this disclosure can be applied.

[0083] like Figure 1 As shown, the system architecture 100 may include a data provider 101, one or more data transfer terminals 102, a data receiver 103, and a blockchain network 104.

[0084] Among them, a communication link is established between the data provider 101, each data transfer end 102 and the data receiver 103. The communication link can include various connection types, such as wired, wireless communication links or fiber optic cables, etc.

[0085] Blockchain Network 104 includes consortium blockchains, public blockchains, and AntChain. Each consortium blockchain, public blockchain, and AntChain contains multiple nodes, and each node can be used to store financial data or encrypted financial data.

[0086] In blockchain network 104, one or more nodes of each chain can also form a data receiving end to store relevant records of encrypted financial data during the circulation process.

[0087] In some examples, users can interact with the data provider 101, various data transfer terminals 102, and data receiver 103 to receive or send financial data, etc. Various communication client applications can be installed on the data provider 101, various data transfer terminals 102, and data receiver 103, such as data processing applications, data encryption applications, natural language processing applications, large model applications, speech recognition applications, short video social applications, audio and video conferencing applications, web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0088] The data provider 101, each data transfer terminal 102, and the data receiver 103 can be hardware or software. When the data provider 101, each data transfer terminal 102, and the data receiver 103 are hardware, they can be various electronic devices with sound acquisition devices (e.g., microphones), video acquisition devices (e.g., cameras), and displays, including but not limited to smartphones, tablets, e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III), MP4 players (Moving Picture Experts Group Audio Layer IV), laptops, and desktop computers, etc., and can also be servers with data processing and data encryption / decryption functions.

[0089] When the data provider 101, each data transfer terminal 102, and the data receiver 103 are software, they can be installed on the devices or servers listed above. They can be implemented as multiple software programs or software modules (e.g., to provide task management related services), or as a single software program or software module. No specific limitations are made here.

[0090] In some cases, the data management method provided in this disclosure can be jointly executed by the data provider 101 and the data receiver 103. For example, the step of "encrypting the preset data in segments to obtain an encrypted data sequence" can be executed by the data provider 101, and the steps of "decrypting the ciphertext data to obtain the restored encrypted data sequence" can be executed by the data receiver 103. Alternatively, the data management method provided in this disclosure can also be jointly executed by the data provider 101, one or more data transfer terminals 102, and the data receiver 103. For example, the step of "encrypting the preset data in segments to obtain an encrypted data sequence" can be executed by the data provider 101, and after encryption, the ciphertext data is forwarded to the data receiver 103 through the data transfer terminal 102, and the data receiver 103 executes the steps of "decrypting the ciphertext data to obtain the restored encrypted data sequence". This disclosure does not limit this.

[0091] It should be understood that Figure 1 The number of data providers 101, data transfer terminals 102, data receivers 103, and blockchain network 104 in this diagram is merely illustrative. Depending on implementation needs, there can be any number of data providers 101, data transfer terminals 102, data receivers 103, and blockchain network 104.

[0092] Continue to refer to Figure 2The diagram illustrates a flow 200 of an embodiment of the data management method of this disclosure, which is applied to... Figure 1 The data management system shown, as previously described, includes a data provider and a data receiver, wherein the data provider and the data receiver are connected in communication and each is connected in communication with a blockchain network.

[0093] The data management method includes the following steps 201 to 204:

[0094] Step 201: The data provider encrypts the preset data in segments to obtain an encrypted data sequence.

[0095] The preset data can be data with encryption requirements, such as financial data like transaction records; the financial data can be data reflecting the company's financial status and operating results, such as the company's basic financial data and analysis data of various indicators.

[0096] Basic financial data can be, for example, financial ledger data and report data that are statistically calculated and registered based on actual corporate operating financial information; including report data such as balance sheet data, income statement data, and cash flow statement data.

[0097] The data for analyzing various indicators can include: data calculated through mathematical models or corresponding formulas, such as performance evaluation data for various departments of an enterprise, financial management data for analyzing various indicators of an enterprise, and decision analysis data for investment decisions, etc.

[0098] In this step, for Figure 1 Any terminal device in China, when it has preset data that needs to be encrypted and distributed, can be used as a data provider. This data provider can encrypt the preset data in segments to obtain an encrypted data sequence.

[0099] Among them, the encryption method of segmented encryption can be, for example, asymmetric encryption. The data provider can use the SM2 / SM9 national cryptographic algorithm or the ECC algorithm (Elliptic Curve Cryptography) to generate an asymmetric encryption key pair, and publish the public key of the asymmetric encryption key pair to the data receiver. In the case of data transfer terminals in the data management system, the public key of the asymmetric encryption key pair is also published to each data transfer terminal.

[0100] Specifically, the data provider can use a 256-bit asymmetric encryption key pair, whose key lifecycle follows the ISO / IEC 27001 standard and is automatically rotated every 72 hours. Encryption is accelerated by integrating the Intel AES-NI instruction set (Intel Advanced Encryption Standard New Instructions), thereby achieving a throughput of 12GB / s.

[0101] Furthermore, the data provider can divide the preset data into multiple data blocks to be encrypted, and divide the private key of the generated asymmetric encryption key pair into a corresponding number of sub-private keys.

[0102] For example, a single 1KB transaction record can be divided into two data blocks, and based on this, the generated private key can be divided into two sub-private keys.

[0103] Based on this, different sub-private keys can be used to perform asymmetric encryption on each data block, and each encrypted data block can be used as an encrypted data block.

[0104] Furthermore, after combining the various encrypted data blocks, they can be used as an encrypted data sequence after encrypting the preset data.

[0105] Step 202: The data provider determines the data hash value of the encrypted data sequence.

[0106] Based on the encrypted data sequence obtained in step 201 above, the data provider can further generate a corresponding data hash value for the encrypted data sequence, so that the data receiver can perform tamper verification based on the data hash value.

[0107] Specifically, since the encrypted data sequence is composed of multiple encrypted data blocks, the data provider can use a hash algorithm to calculate the hash value of each encrypted data block in the encrypted data sequence and use it as the data block hash value. Then, the hash values ​​of each data block are hashed and merged to obtain the data hash value of the encrypted data sequence.

[0108] In some specific examples, the data provider may use, for example, the SHA-3 algorithm (Secure Hash Algorithm 3) to determine the 256-bit real-time data block hash value of each encrypted data block.

[0109] Furthermore, the data provider uses a Merkle tree structure to perform one or more hash merging operations on the hash values ​​of each data block to generate the root hash, i.e., the data hash value. Since the data block hash value is calculated in real time using the SHA-3 algorithm, this data hash value is also a real-time value.

[0110] Step 203: The data provider performs secondary encryption on the encrypted data sequence to obtain ciphertext data.

[0111] Based on the encrypted data sequence determined in step 201 above, the data provider can perform secondary encryption on the encrypted data sequence using symmetric encryption.

[0112] Specifically, the data provider can generate a symmetric key and publish it to the data receiver; in the case of a data management system with data transfer terminals, the data provider will also publish the symmetric key to each data transfer terminal.

[0113] Therefore, the data provider can use a symmetric key to perform secondary encryption on the encrypted data sequence.

[0114] In some specific examples, the data provider can use the ECDHE key exchange algorithm (Elliptic Curve Diffie-Hellman Ephemeral key exchange algorithm) to generate and publish temporary symmetric keys, thereby generating temporary or real-time symmetric keys.

[0115] Furthermore, the data provider can perform secondary encryption on the encrypted data sequence based on the generated symmetric key, thereby achieving mixed encryption of the preset data and obtaining ciphertext data.

[0116] In some cases, segmented encryption and double encryption can both be performed in the form of homomorphic encryption, which allows the data receiving end to perform data analysis on the encrypted data without having to completely decrypt it.

[0117] As can be seen, the above-mentioned hybrid encryption solves the contradiction between efficiency and security in the encryption process. The ECDHE key exchange algorithm has higher security, while reducing key length and lower computational overhead. That is, the ECDHE key exchange algorithm has higher computational efficiency, making it suitable for resource-constrained devices. Furthermore, even if the private key of the asymmetric key pair is leaked, the previous data content cannot be decrypted.

[0118] The aforementioned data management system also includes a data storage terminal, which can be composed of one or more nodes in the blockchain network. This data storage terminal can be used to store the flow records of encrypted data and data hash values ​​between the data provider and / or various data transfer terminals, thereby enabling the data receiver to perform a step-by-step validity verification of the encrypted data sequence based on the flow records stored in the data storage terminal and the data hash values.

[0119] Specifically, please refer to Figure 2Step 204: The data provider uses the data hash value to generate a first transfer record associated with the current address of the data provider and stores it in the data storage terminal.

[0120] The current address of the data provider can be generated according to address generation rules. For example, the data provider can use the UUIDv7 standard (Universally Unique Identifier Version 7 standard) to generate the 128-bit first real-time transfer address of the data provider.

[0121] Based on this, the data provider can use the data hash value generated in the aforementioned step 202 to generate a first transfer record associated with the first real-time transfer address.

[0122] Specifically, the first real-time transfer address generated by the data provider can contain a 48-bit timestamp, an 80-bit random number, and a 16-bit version information, such as 7f57d0e0-3d3a-7f57-8e3a-3d3a7f57d0e0. The data provider can use a dynamic hash chain of a Merkle DAG (Merkle Directed Acyclic Graph) structure to generate a first transfer record associated with the first real-time transfer address by combining the above data hash value.

[0123] Since the first transfer address of the data provider is generated in real time, the first transfer record generated by the data provider is also generated in real time.

[0124] Furthermore, the data provider can store the generated first circulation record to the data storage terminal in the blockchain network.

[0125] The data management system also includes at least one data transfer terminal. This data storage terminal can be used to store the transfer records of encrypted data and data hash values ​​between the data provider and the data receiver, or between the data provider, various data transfer terminals, and the data receiver. Thus, the data receiver can perform a step-by-step validity verification of the encrypted data sequence based on the transfer records stored in the data storage terminal and the data hash values. Each data transfer terminal forwards the encrypted data and data hash values ​​sent by the data provider to the data receiver or other data transfer terminals.

[0126] Specifically, please refer to Figure 2 In a blockchain network with a data storage terminal and at least one data transfer terminal, after the encrypted data column is encrypted a second time at the data provider end to obtain ciphertext data, it can be executed. Figure 2 In step 205 shown, the data provider sends the data hash value and ciphertext data to the data transfer end.

[0127] Based on the data hash value determined by the data provider in step 202 and the ciphertext data obtained by the data provider through secondary encryption in step 203, the data provider can send the data hash value and ciphertext data to the data transfer end according to the preset transmission path.

[0128] Step 206: The data transfer end uses the data hash value to generate a second transfer record associated with the current address of the data transfer end, and stores it in the data storage end.

[0129] When the data provider sends the data hash value and encrypted data to the data transfer end, the data transfer end can generate a second transfer record associated with its current address and store the second transfer record in the data storage end when it receives the data hash value and encrypted data.

[0130] Specifically, the current address of the data transfer end can be generated according to the address generation rules. For example, the data provider end can use the same UUIDv7 standard as the aforementioned implementation to generate the 128-bit second real-time transfer address of the data provider end.

[0131] Based on this, the data transfer end can use the received data hash value to generate a second transfer record associated with the second real-time transfer address.

[0132] Since the second transfer address of the data transfer terminal is generated in real time, the second transfer record generated by the data transfer terminal is also generated in real time.

[0133] Furthermore, the data transfer end can also store the generated second transfer record to the data storage end in the blockchain network.

[0134] Step 207: The data transfer end sends the data hash value and encrypted data to the next data transfer end or data receiving end.

[0135] Based on the data hash value and encrypted data received by the data transfer end in step 206 above, it can be sent to the data receiving end or to the next data transfer end according to the preset transmission path.

[0136] When the data hash value and ciphertext data are transmitted to any data transfer terminal, the currently receiving data transfer terminal generates a corresponding second transfer record and stores it in the data storage terminal.

[0137] Therefore, a data chain can be formed at the data storage end to track the transmission and flow of data hash values ​​and ciphertext data, thereby enabling effective traceability of the transmission and flow of data hash values ​​and ciphertext data.

[0138] Step 208: The data receiving end decrypts the ciphertext data to obtain the restored encrypted data sequence.

[0139] When the data hash value and ciphertext data are transmitted to the data receiving end through the data transfer end, after the data receiving end receives the data hash value and ciphertext data, it can use the symmetric key issued by the data provider to decrypt the ciphertext data. Thus, the ciphertext data can be verified by the data hash value, that is, to verify whether the ciphertext data has been tampered with.

[0140] Step 209: The data receiving end determines the restored hash value of the restored encrypted data sequence.

[0141] In this step, based on the restored encrypted data sequence obtained in step 208, the data receiving end can first determine each restored encrypted data block in the restored encrypted data sequence, and then the data receiving end can use the same SHA-3 algorithm as in step 202 to determine the corresponding restored data block hash value of each encrypted data block.

[0142] Furthermore, the data receiving end can adopt the same Merkle tree structure as in step 202, and perform the same number of hash merging operations on the hash values ​​of each data block as in step 202 to generate a restored hash value.

[0143] Step 210: The data receiving end verifies whether the restored hash value is consistent with the data hash value.

[0144] Based on the restored hash value generated in step 209 above, the data receiving end can compare the received data hash value with the restored hash value and verify whether the two are consistent. In this way, the first stage of local pre-verification of the restored encrypted data sequence can be completed.

[0145] Step 211: In response to verifying that the restored hash value is consistent with the data hash value, the data receiving end retrieves the first transfer record and the second transfer record from the data storage end, and determines the restored root hash of each of the first transfer record and the second transfer record.

[0146] Based on the verification result of the data receiving end in step 210 above, if the data receiving end verifies that the received data hash value is inconsistent with the restored hash value, the data receiving end can consider that the restored encrypted data sequence has not passed the local pre-verification, and therefore, the restored encrypted data sequence is invalid. Accordingly, the data receiving end can delete the restored encrypted data sequence.

[0147] If the data receiver verifies that the received data hash value is consistent with the restored hash value, the data receiver can consider that the restored encrypted data sequence has passed the local pre-verification. Based on this, the data receiver can obtain the first transfer record stored by the data provider at the data storage terminal and the second transfer record stored by the data transfer terminal at the data storage terminal, and use the first transfer record and the second transfer record to perform the next stage of blockchain verification.

[0148] Specifically, based on the first and second circulation records obtained by the data receiving end, the data receiving end can use a pre-built smart contract in the blockchain network to determine the Merkle root hash of each of the first and second circulation records, that is, the restored hash root of each of the first and second circulation records.

[0149] Step 212: The data receiver verifies whether each restore root hash is consistent with the data hash value.

[0150] Based on the restored hash root of the first circulation record and the restored hash root of the second circulation record determined by the data receiving end in step 211 above, the data receiving end can compare whether the restored hash root of the first circulation record and the restored hash root of the second circulation record are consistent with the received data hash value, thereby determining whether the blockchain verification of this stage has been passed.

[0151] Step 213: In response to verifying that each restore root hash is consistent with the data hash value, the data receiver performs distributed storage of the ciphertext data.

[0152] Based on the comparison results in step 212 above, if the comparison between the restored root hash and the data hash value of any flow record is inconsistent, the data receiving end can determine that the flow data chain containing the first flow record and the second flow record has not passed the blockchain verification at this stage. That is, there are flow records in each flow record that have not passed the blockchain verification at this stage, and it is considered that the tampering verification of the restored encrypted data sequence has failed. Accordingly, the data receiving end can delete the restored encrypted real-time data block sequence.

[0153] If the comparison between the first and second transfer records and the data hash value is consistent, the data receiving end can determine that the transfer data chain containing the first and second transfer records has passed the blockchain verification at this stage, and consider the tampering verification of the restored encrypted data sequence to be passed, and determine that the restored encrypted data sequence is valid.

[0154] Furthermore, if the data receiving end verifies that the restored encrypted data sequence is valid, the data receiving end can divide the ciphertext data into multiple data fragments, and accordingly, allocate corresponding storage resources to each data fragment.

[0155] Based on this, the encrypted data can be distributed and stored in different storage locations according to the allocated storage resources, thus achieving distributed storage.

[0156] Based on this, the data provider sends the data hash value and ciphertext data to the data transfer end. The data transfer end generates a second transfer record associated with its current address and stores it in the data storage end. It then forwards the data to the next data transfer end or data receiving end, thus forming a data transfer chain containing the first and second transfer records in the data storage end. After decrypting the ciphertext data and completing local pre-verification, the data receiving end retrieves all transfer records from the data storage end, determines their respective root hashes, and verifies whether each root hash matches the data hash value.

[0157] This method ensures the transparency and traceability of the data flow process by having the data provider generate a flow record during the transmission of encrypted data. The data receiver verifies the consistency of all restoring root hashes in the transmission data chain, thus achieving strict authentication of the encrypted data from provision to receipt. This effectively prevents potential intermediate tampering when multiple data transmission ends are involved, providing a reliable guarantee for the final distributed storage of encrypted data.

[0158] In the absence of a data storage terminal and a data transfer terminal in the data management system, after performing step 203 above, the data provider can use the data hash value to generate a first transfer record associated with the current address of the data provider, and send the first transfer record, the data hash value, and the encrypted data directly to the data receiver.

[0159] Based on the obtained data hash value and ciphertext data, the data provider can send the data hash value and ciphertext data to the data receiver.

[0160] It can be seen that the data provider performs encryption and distribution operations on the relevant data to be encrypted and distributed.

[0161] In one example, based on the encryption and distribution operations performed by the data provider on the preset data to be encrypted and distributed, after the data provider sends the data hash value and ciphertext data to the data receiver, the data receiver can receive the data hash value and ciphertext data.

[0162] After receiving the data hash value and ciphertext data at the data receiving end, before storing and managing the ciphertext data at the data receiving end, the symmetric key issued by the data provider can be used to decrypt the ciphertext data. Thus, the ciphertext data can be verified by using the data hash value, that is, to verify whether the ciphertext data has been tampered with.

[0163] Specifically, the data receiving end can decrypt the ciphertext data based on the symmetric key published by the data providing end, thereby obtaining the restored encrypted data sequence.

[0164] Furthermore, the data receiver uses the data hash value to verify whether the restored encrypted data sequence is valid.

[0165] Based on the determined restored encrypted data sequence, the data receiving end also needs to verify whether the restored encrypted data sequence is valid, thereby verifying whether the ciphertext data has been tampered with.

[0166] Specifically, the data receiving end can determine each restored encrypted data block in the restored encrypted data sequence, and then the data receiving end can use the same SHA-3 algorithm as in step 202 to determine the corresponding restored data block hash value of each encrypted data block.

[0167] Furthermore, the data receiving end can adopt the same Merkle tree structure as in step 202, and perform the same number of hash merging operations on the hash values ​​of each data block as in step 202 to generate the restored hash value of the restored encrypted data sequence.

[0168] Based on this, the data receiving end can compare the received data hash value with the restored hash value and verify whether the two are consistent. If the received data hash value is consistent with the restored hash value, it can be determined that the restored encrypted data sequence is valid and that the received ciphertext data has not been tampered with.

[0169] If the received data hash value is inconsistent with the restored hash value, it can be determined that the restored encrypted data sequence is invalid, and it is considered that the received ciphertext data may have been tampered with. Based on this, the restored encrypted data sequence can be deleted.

[0170] Furthermore, based on the aforementioned verification results, if the data receiving end verifies that the restored encrypted data sequence is valid, then the data receiving end can store the received ciphertext data. In this case, the data receiving end can store and manage the ciphertext data in a distributed storage manner.

[0171] Specifically, the data receiving end can divide the encrypted data into multiple data fragments, and accordingly, allocate corresponding storage resources to each data fragment.

[0172] Based on this, the encrypted data can be distributed and stored in different storage locations according to the allocated storage resources, thus achieving distributed storage.

[0173] Based on this, the data provider performs segmented asymmetric encryption on the preset data and generates a data hash value, and then performs secondary encryption using a symmetric key to form hybrid encryption, which significantly improves the security of ciphertext data during transmission and storage; the data receiver verifies the validity of the restored encrypted data sequence by using the received data hash value after decryption, thereby effectively preventing data tampering and leakage.

[0174] Furthermore, by fragmenting the encrypted data, the distributed storage of the encrypted data effectively improves the utilization efficiency and reliability of storage resources.

[0175] In another example, where the data management system does not include a data storage terminal and a data transfer terminal, after the data provider performs encryption and distribution operations on the relevant data to be encrypted and distributed, and before the encrypted data is distributed for storage, the following can be performed: Figure 3 The process shown is as follows: Figure 3 This illustration shows a breakdown process 300 for a phased verification process performed by the data receiver of this disclosure. The breakdown process 300 includes steps 301 to 305:

[0176] Step 301: The data receiving end determines the restored hash value of the restored encrypted data sequence.

[0177] In this step, based on the restored encrypted data sequence obtained in step 205, the data receiving end can first determine each restored encrypted data block in the restored encrypted data sequence, and then the data receiving end can use the same SHA-3 algorithm as in step 202 to determine the corresponding restored data block hash value of each encrypted data block.

[0178] Furthermore, the data receiving end can adopt the same Merkle tree structure as in step 202, and perform the same number of hash merging operations on the hash values ​​of each data block as in step 202 to generate a restored hash value.

[0179] Step 302: The data receiving end verifies whether the restored hash value is consistent with the data hash value.

[0180] Based on the restored hash value generated in step 301 above, the data receiving end can compare the received data hash value with the restored hash value and verify whether the two are consistent. In this way, the first stage of local pre-verification of the restored encrypted data sequence can be completed.

[0181] Step 303: In response to verifying that the restored hash value is consistent with the data hash value, the data receiving end retrieves the first transfer record from the data storage end and determines the restored root hash of the first transfer record.

[0182] Based on the verification result of the data receiving end in step 302 above, if the data receiving end verifies that the received data hash value is inconsistent with the restored hash value, the data receiving end can consider that the restored encrypted data sequence has not passed the local pre-verification, and therefore, the restored encrypted data sequence is invalid. Accordingly, the data receiving end can delete the restored encrypted data sequence.

[0183] If the data receiver verifies that the received data hash value is consistent with the restored hash value, the data receiver can consider that the restored encrypted data sequence has passed the local pre-verification. Based on this, the data receiver can obtain the first flow record stored by the data provider at the data storage end and use the first flow record for the next stage of blockchain verification.

[0184] Specifically, based on the first flow record obtained by the data receiver, the data receiver can use a pre-built smart contract in the blockchain network to determine the Merkle root hash in the first flow record of the Merkle DAG structure, that is, to restore the hash root.

[0185] Step 304: The data receiving end verifies whether the restored root hash and the data hash value are consistent.

[0186] Based on the restored hash root determined by the data receiver in step 303 above, the data receiver can compare whether the restored hash root is consistent with the received data hash value, thereby determining whether the blockchain verification at this stage has been passed.

[0187] Step 305: The data receiver responds to the verification that the restored root hash and the data hash value are consistent, and determines that the restored encrypted data sequence is valid.

[0188] Based on the comparison results in step 304 above, if the comparison is inconsistent, the data receiving end can determine that the first transfer record has not passed the blockchain verification at this stage, and consider that the tampering verification of the restored encrypted data sequence has failed. Accordingly, the data receiving end can delete the restored encrypted real-time data block sequence.

[0189] If the comparison is consistent, the data receiving end can determine that the first transfer record has passed the blockchain verification at this stage, and consider the tampering verification of the restored encrypted data sequence to be passed, and determine that the restored encrypted data sequence is valid.

[0190] In some examples, where the data provider pre-adds a real-time digital signature to the encrypted data sequence, the data receiver can perform signature verification on the real-time digital signature of the restored encrypted data sequence after local pre-verification and before blockchain verification. If the restored encrypted data sequence passes the signature verification, the next stage of blockchain verification will then be performed, thus completing the three-stage verification mechanism.

[0191] In this scenario, if the restored encrypted data sequence fails signature verification, the data provider may not need to proceed with the next stage of blockchain verification and may delete the restored encrypted data sequence.

[0192] Based on this, the first stage of local pre-verification is completed by calculating the restored hash value of the encrypted data sequence and comparing it with the received data hash value, thereby quickly filtering out invalid or obviously tampered encrypted data. Subsequently, based on the successful pre-verification, the second stage of blockchain verification is achieved by parsing the restored root hash of the first circulation record and comparing it with the received data hash value.

[0193] By adopting a phased and multi-level tiered data verification mechanism, the verification efficiency is guaranteed through local verification, reducing the cost of direct verification on the blockchain network. At the same time, the immutability of the blockchain network significantly enhances the data receiver's ability to verify the validity of the restored encrypted data sequence.

[0194] In some optional implementations, during the distributed storage of encrypted data in step 213 of this disclosure, the data receiving end can first perform data analysis on the encrypted data and allocate storage resources for distributed storage based on the analysis results, thereby completing the distributed storage of the encrypted data.

[0195] Specifically, please refer to Figure 4 This illustrates a decomposition process 400 of an embodiment of distributed storage of encrypted data in step 213 of this disclosure. The decomposition process 400 is executed by a data receiving end, which is equipped with a pre-trained encrypted data analysis model, a pre-trained data flow analysis model, and a pre-trained resource allocation model. The decomposition process 400 includes the following steps 401 to 404:

[0196] Step 401: The data receiving end uses a pre-trained encrypted data analysis model to perform data analysis on the encrypted data and obtain the data analysis results.

[0197] In some examples, the pre-trained encrypted data analysis model can be built based on LSTM (Long Short-Term Memory) network, Attention mechanism, and MLP (Multilayer Perceptron) algorithm. The encrypted data analysis model includes a encrypted data feature extraction module built on LSTM network, an attention weighting module built on Attention mechanism, and an encrypted data analysis module built on MLP algorithm, which are connected in sequence.

[0198] The encrypted data feature extraction module utilizes the sequence modeling capabilities of the LSTM network to extract features from the input ciphertext data. Through its gating structure, such as the input gate, forget gate, and output gate, the LSTM network can effectively capture long-term dependencies in the ciphertext data and learn key features. Even if the data is encrypted, the LSTM network can still learn the patterns and information hidden in the encrypted sequence, i.e., the ciphertext data, providing a foundation for subsequent analysis.

[0199] Because LSTM networks can better handle long sequence data and avoid the gradient vanishing problem, they can capture long-term dependencies in the data. The gating mechanism of LSTM networks makes them robust to noise and outliers, and can extract features of ciphertext data more stably. This allows LSTM to learn nonlinear features in ciphertext data, providing rich feature representations for subsequent attention weighting modules.

[0200] Furthermore, the attention weighting module uses the attention mechanism to weight the features extracted by the LSTM network, highlighting the most important features in the current data analysis task. The attention mechanism assigns a weight to each feature by calculating the correlation between the feature at each time step and the current data analysis task. After weighting the features represented by feature vectors, the resulting weighted feature vector can more accurately reflect the key information of the encrypted data and improve the model's attention.

[0201] Because the Attention mechanism can dynamically adjust the weight of each feature, the encrypted data analysis model pays more attention to the key information related to the current data analysis task. The weighted feature vector can more accurately reflect the key information of the encrypted data, thereby improving the analysis accuracy of the encrypted data analysis model.

[0202] Furthermore, the encrypted data analysis module can obtain weighted feature vectors from the attention weighting module and use the MLP mechanism for analysis and prediction. The MLP mechanism performs nonlinear transformations on the weighted feature vectors through multiple fully connected layers and activation functions to learn higher-level feature representations. The MLP mechanism outputs the analysis results of the encrypted data, such as classification labels, predicted values, or anomaly detection indicators.

[0203] When the restored encrypted data sequence is verified to be valid in step 206, the data receiving end can input the ciphertext data that has been determined to be untampered into the pre-trained encrypted data analysis model for analysis.

[0204] Specifically, the data receiving end can use the encrypted data feature extraction module of the encrypted data analysis model to extract multiple encrypted data features of the encrypted data.

[0205] Furthermore, the data receiving end uses the attention weighting module of the encrypted data analysis model to perform weighted fusion of the features of each encrypted data to obtain a weighted feature vector.

[0206] Furthermore, the data receiving end uses the encrypted data analysis module of the encrypted data analysis model to perform data analysis based on the weighted feature vector, and obtains the data analysis results of the encrypted data.

[0207] Step 402: The data receiving end uses a pre-trained data flow analysis model to perform data flow analysis on all flow records and obtain the flow analysis results.

[0208] In some examples, the data flow analysis model can be built on GCN (Graph Convolutional Network) and DBN (Deep Belief Network), and the data flow analysis model includes a GCN-based graph structure feature extraction module and a DBN-based data flow analysis module connected in sequence.

[0209] The flow data chain used to represent data flow uses Merkle tree structures for each flow record. Merkle trees are binary tree data structures typically used to efficiently verify the content and order of data blocks. In a Merkle tree flow data chain, each leaf node represents a corresponding flow record and its address, non-leaf nodes represent their corresponding hash values, and edges represent the relationships between flow records. Node features can include information such as the content of the flow record, its hash value, and its position in the tree. The graph structure feature extraction module utilizes GCN's graph data processing capabilities to extract graph features from the flow data chain. GCN treats the nodes and edges in the flow data chain as a graph structure and captures the mutual influence and dependencies between nodes through graph convolution operations.

[0210] Furthermore, the data flow analysis module receives flow chain features extracted from the graph structure feature extraction module and uses DBN to identify and analyze the flow process. DBN can perform deep feature learning to capture complex processes in the flow data chain. By learning the normal data flow process, DBN can detect abnormal data flow behavior and provide support for risk analysis in the data flow process.

[0211] When the data receiving end retrieves a data flow chain containing one or more flow records, it can perform data flow analysis on the data flow chain and obtain the flow analysis results.

[0212] Specifically, the data receiving end can convert the flow data chain into a flow chain information graph, and use the graph structure feature extraction module of the data flow analysis model to extract the real-time graph structure data in the real-time flow chain information graph.

[0213] Furthermore, the data receiving end can use the data flow analysis module of the data flow analysis model to perform data flow analysis based on real-time graph structure data and obtain the flow analysis results.

[0214] Step 403: The data receiving end uses a pre-trained resource allocation model to generate a resource allocation strategy based on the encrypted data, data analysis results, and flow analysis results. The resource allocation strategy is used to guide the storage of the encrypted data.

[0215] In some examples, the resource allocation model is built based on the meta-policy optimization algorithm and the multi-objective group relative policy optimization algorithm. The resource allocation model includes a meta-policy optimization module built based on the meta-policy optimization algorithm and a reinforcement learning module built based on the multi-objective group relative policy optimization algorithm. The reinforcement learning module is equipped with an agent, a policy network and an experience replay pool. The agent is connected to the policy network, the experience replay pool and the meta-policy optimization module respectively.

[0216] The meta-policy optimization module is used to adjust the network parameters of the policy network in the reinforcement learning module so that the network parameters can quickly adapt to new data analysis results and flow analysis results. Under the new data analysis results and flow analysis results, the network parameters in the policy network can be updated based on previous learning experience, thereby improving the generalization ability of the resource allocation model.

[0217] The reinforcement learning module includes a set of objective functions that can handle multiple conflicting optimization objectives, such as minimizing storage resource allocation costs, maximizing storage resource utilization, and / or maximizing storage reliability, and generate resource allocation strategies to balance the various optimization objectives.

[0218] Furthermore, the agent can learn historical resource allocation strategies through the experience replay pool, thereby continuously optimizing its ability to generate resource allocation strategies. This allows the agent to generate more effective resource allocation strategies based on the learned experience control policy network. The design of the experience replay pool and the agent enables the resource allocation model to continuously learn and optimize, improving the quality of resource allocation strategy generation.

[0219] On the other hand, the reinforcement learning module can adopt a group exploration approach to avoid getting stuck in local optima. The policy network outputs the probability distribution of actions, and the reinforcement learning module directly updates the policy network through gradients, avoiding the Critic model in traditional reinforcement learning, making the algorithm structure simpler.

[0220] Based on the data analysis and flow analysis results obtained from the aforementioned steps, the data receiving end can generate a resource allocation strategy for distributed storage of encrypted data.

[0221] Specifically, the data receiving end can adjust the policy network of the reinforcement learning module based on the data analysis results and the flow analysis results, using the meta-policy optimization module of the storage resource allocation model, to obtain the adjusted policy network.

[0222] Furthermore, multiple historical resource allocation strategies are randomly selected from the experience replay pool of the reinforcement learning module, and multiple resource allocation actions are generated based on each historical resource allocation strategy. Based on each resource allocation action, the action space of the agent in the reinforcement learning module is adjusted to obtain the adjusted action space.

[0223] Furthermore, the data receiving end can parse the data analysis results and flow analysis results to obtain multiple analysis states, and adjust the state space of the agent in the reinforcement learning module according to each analysis state to obtain the adjusted state space.

[0224] Furthermore, the data receiver can select an objective function from the set of objective functions of the reinforcement learning module, and based on the objective function, use the agent of the reinforcement learning module to control the adjusted policy network to generate the probability distributions that correspond to each resource allocation action in the adjusted action space and each analysis state in the adjusted state space.

[0225] Furthermore, the resource allocation action with the highest probability distribution in the adjusted action space is determined as the target resource allocation action for the corresponding analysis state.

[0226] Furthermore, the resource allocation actions for each target are taken as resource allocation strategies.

[0227] Real-time resource allocation strategies include real-time data sharding decisions, real-time storage resource scheduling decisions, and real-time distributed storage decisions.

[0228] Step 404: The data receiving end divides the encrypted data into multiple data fragments and performs distributed storage on each data fragment according to the resource allocation strategy.

[0229] Based on the resource allocation strategy determined in step 403 above, the data receiving end can divide the encrypted data into multiple data fragments and perform distributed storage on each data fragment according to the resource allocation strategy when distributing the encrypted data.

[0230] Specifically, the data receiving end can perform data sharding on the encrypted core data, encrypted log data, and encrypted compliance data in the ciphertext according to the data sharding decision included in the resource allocation strategy, resulting in multiple encrypted core data shards, multiple encrypted log data shards, and multiple encrypted compliance data shards.

[0231] Furthermore, the data receiving end can schedule multiple consortium chain nodes, multiple public chain nodes, and multiple AntChain nodes in the consortium chain, public chain, and AntChain respectively, based on the storage resource scheduling decisions included in the resource allocation strategy.

[0232] Furthermore, the data receiving end can utilize multiple consortium blockchain nodes to perform distributed storage of multiple encrypted core data shards based on the distributed storage decisions included in the resource allocation strategy; utilize multiple public blockchain nodes to perform distributed storage of multiple encrypted log data shards; and utilize multiple AntChain nodes to perform distributed storage of multiple encrypted compliant data shards.

[0233] Based on this, the data receiving end can extract the storage addresses of each encrypted core data shard, each encrypted log data shard, and each encrypted compliant data shard, and store each storage address and the corresponding encrypted data analysis results in the distributed ledger, and synchronize the distributed ledger to the blockchain network.

[0234] As can be seen, a pre-trained encrypted data analysis model performs in-depth analysis on the encrypted data and outputs data analysis results; simultaneously, a pre-trained data flow analysis model processes all flow records to generate flow analysis results. Based on this, a pre-trained resource allocation model integrates the encrypted data, data analysis results, and flow analysis results to generate targeted resource allocation strategies to guide storage operations.

[0235] Finally, the data receiving end divides the encrypted data into multiple data fragments according to this strategy, and performs distributed storage on each data fragment according to the strategy instructions. This implementation method achieves precise matching between storage strategy and data characteristics and flow history through multi-model collaborative analysis, significantly improving the rationality of storage resource allocation, the efficiency of storage operations, and the overall reliability of the system.

[0236] As can be seen, in the above embodiments of this application, the data provider achieves hybrid encryption of the preset data through segmented encryption and secondary encryption to effectively protect the preset data. That is, even if the ciphertext data obtained by secondary encryption is cracked, only the encrypted data sequence after segmented encryption can be obtained, and the preset data in plaintext form still cannot be obtained after cracking the ciphertext data.

[0237] Meanwhile, during the encryption process, the data provider calculates the hash value of the encrypted data sequence and sends it along with the ciphertext data to the data receiver, enabling the data receiver to use this hash value to verify whether the ciphertext data has been tampered with during transmission.

[0238] Specifically, after the data provider decrypts the ciphertext data and obtains the restored encrypted data sequence, it can calculate the root hash of the restored encrypted data sequence, i.e., the restored hash value. This allows for timely verification that the ciphertext data has been tampered with when the restored hash value is inconsistent with the received data hash value.

[0239] Furthermore, regarding the lack of transparency and difficulty in tracing financial data, in the above embodiments of this application, before the encrypted data reaches the data receiving end, the data providing end and each data transfer end that comes into contact with the encrypted data send a transfer record containing its address to the data storage end. This enables the data receiving end to effectively trace the flow of the encrypted data after obtaining each transfer record. At the same time, it can verify whether there are any anomalies in each transfer record through the data hash value, thereby effectively identifying the data transfer end or data providing end that may have tampered with the data.

[0240] Meanwhile, the data receiving end in the embodiments of this application also analyzes the flow process of encrypted data through a data flow analysis model, thereby effectively identifying potential risks and the data flow end or data provider end that may have risks.

[0241] Furthermore, regarding the issue of low storage efficiency, in the above embodiments of this application, by dividing the encrypted data into multiple data shards, it is possible to distribute and store each data shard in the blockchain network. When storing data shards, each data shard requires less storage resources. Through distributed storage, fragmented storage space can be effectively utilized, thereby effectively improving storage efficiency.

[0242] Meanwhile, in the embodiments of this application, a resource allocation model is used to provide a resource allocation strategy for the data fragments of encrypted data. By relying on the resource allocation model, suitable storage space for each data fragment can be obtained quickly, thereby greatly improving the efficiency of storing data fragments. Furthermore, when generating the resource allocation strategy, the resource allocation model considers both the data analysis results and the flow analysis results of the encrypted data, so that the resource allocation strategy can effectively adapt to each data fragment.

[0243] Furthermore, in addressing the problem of inefficiency and poor real-time performance when processing large amounts of financial data, the above embodiments of this application employ an encrypted data analysis model to analyze encrypted data. This achieves intelligent data analysis, and the encrypted data analysis model is far more efficient than manual analysis in obtaining data analysis results, thereby effectively improving the efficiency of data processing.

[0244] Further reference Figure 5 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a data management device, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0245] like Figure 5 As shown, the data management device 500 in this embodiment includes: a data providing module 501, a data transfer module 502, and a data receiving module 503.

[0246] The data providing module 501 is configured to encrypt preset data segments through the data providing end to obtain an encrypted data sequence, determine the data hash value of the encrypted data sequence, perform secondary encryption on the encrypted data sequence to obtain ciphertext data, generate a first transfer record associated with the current address of the data providing end using the data hash value and store it in the data storage end, send the data hash value and ciphertext data to the data transfer end, generate a second transfer record associated with the current address of the data transfer end using the data hash value and store it in the data storage end;

[0247] The data transfer module 502 is configured to send the data hash value and ciphertext data to the next data transfer end or data receiving end;

[0248] The data receiving module 503 is configured to decrypt the ciphertext data to obtain the restored encrypted data sequence, determine the restoration hash value of the restored encrypted data sequence, verify whether the restoration hash value is consistent with the data hash value, and in response to verifying that the restoration hash value is consistent with the data hash value, retrieve the first and second transfer records from the data storage end, determine the restoration root hash of each of the first and second transfer records, verify whether each restoration root hash is consistent with the data hash value, and in response to verifying that each restoration root hash is consistent with the data hash value, perform distributed storage of the ciphertext data.

[0249] In this embodiment, the specific processing of the data providing module 501, data transfer module 502, and data receiving module 503 of the data management device 500, and the resulting technical effects, can be found by referring to [reference needed]. Figure 2 The relevant descriptions of steps 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212 and 213 in the corresponding embodiments will not be repeated here.

[0250] In some alternative implementations, the data providing module 501 is further configured to:

[0251] The preset data is divided into multiple data blocks by the data provider, and the preset private key is divided into a corresponding number of sub-private keys;

[0252] The data provider uses each sub-private key to perform asymmetric encryption on each data block to obtain multiple encrypted data blocks.

[0253] The data provider combines the encrypted data blocks into an encrypted data sequence.

[0254] In some alternative implementations, the data providing module 501 is further configured to:

[0255] The data provider calculates the hash value of each encrypted data block in the encrypted data sequence;

[0256] The data hash value is obtained by hashing and merging the hash values ​​of each data block through the data provider.

[0257] In some optional implementations, the data providing module 501 is further configured to:

[0258] A symmetric key is generated through the data provider.

[0259] The data provider uses a majority of symmetric keys to symmetrically encrypt the encrypted data sequence.

[0260] In some alternative implementations, the data receiving module 503 is further configured to:

[0261] The encrypted data is analyzed by using a pre-trained encrypted data analysis model at the data receiving end to obtain the data analysis results.

[0262] The data receiver uses a pre-trained data flow analysis model to perform data flow analysis on all flow records and obtain the flow analysis results.

[0263] The data receiving end uses a pre-trained resource allocation model to generate a resource allocation strategy based on encrypted data, data analysis results, and flow analysis results. The resource allocation strategy is used to guide the storage of encrypted data.

[0264] The encrypted data is divided into multiple data fragments by the data receiving end, and each data fragment is distributed and stored according to the resource allocation strategy.

[0265] It should be noted that the implementation details and technical effects of each unit in the data management device provided in the embodiments of this disclosure can be referred to the descriptions of other embodiments in this disclosure, and will not be repeated here.

[0266] The following is for reference. Figure 6 It shows a schematic diagram of the structure of a computer system 600 suitable for implementing the electronic device of the present disclosure. Figure 6 The computer system 600 shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0267] like Figure 6 As shown, the computer system 600 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 into a random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the operation of the computer system 600. The processing device 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0268] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, magnetic tapes, hard disks, etc.; and communication devices 609. Communication device 609 allows computer system 600 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 A computer system 600 with various electronic devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0269] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by a processing device 601, it performs the functions defined in the methods of embodiments of this disclosure.

[0270] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0271] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0272] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the following functions: Figure 2 The illustrated embodiments and their alternative implementations demonstrate a task management method.

[0273] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0274] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0275] The units or modules described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units or modules do not necessarily limit the specific unit; for example, a data providing module can also be described as "a module that encrypts preset data in segments to obtain an encrypted data sequence, determines the data hash value of the encrypted data sequence, performs secondary encryption on the encrypted data sequence to obtain ciphertext data, and sends the data hash value and the ciphertext data to the data receiving end."

[0276] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

Claims

1. A data management method characterized by, The method is applied to a data management system, and the data management system comprises a data providing end, a data receiving end, a data storage end and at least one data flow transferring end. The data providing end encrypts preset data segments to obtain an encrypted data sequence. The data providing end determines a data hash value of the encrypted data sequence. The data providing end performs secondary encryption on the encrypted data sequence to obtain ciphertext data. The data providing end generates a first flow record associated with a current address of the data providing end by using the data hash value, and stores the first flow record to the data storage end. The data providing end sends the data hash value and the ciphertext data to the data flow transferring end. The data flow transferring end generates a second flow record associated with a current address of the data flow transferring end by using the data hash value, and stores the second flow record to the data storage end. The data flow transferring end sends the data hash value and the ciphertext data to a next data flow transferring end or the data receiving end. The data receiving end decrypts the ciphertext data to obtain a restored encrypted data sequence. The data receiving end determines a restored hash value of the restored encrypted data sequence. The data receiving end verifies whether the restored hash value is consistent with the data hash value. The data receiving end, in response to verifying that the restored hash value is consistent with the data hash value, retrieves the first flow record and the second flow record from the data storage end, and determines respective restored root hashes of the first flow record and the second flow record. The data receiving end verifies whether each restored root hash is consistent with the data hash value. The data receiving end, in response to verifying that each restored root hash is consistent with the data hash value, performs distributed storage on the ciphertext data.

2. The method of claim 1, wherein, The data providing end encrypts preset data segments to obtain an encrypted data sequence, comprising: The data providing end divides the preset data into a plurality of data blocks, and divides a preset private key into a corresponding number of sub-private keys. The data providing end respectively performs asymmetric encryption on each data block by using each sub-private key to obtain a plurality of encrypted data blocks. The data providing end groups each encrypted data block to form the encrypted data sequence.

3. The method of claim 2, wherein, The data providing end determines a data hash value of the encrypted data sequence, comprising: The data providing end calculates a data block hash value for each encrypted data block in the encrypted data sequence. The data providing end performs hash merging on each data block hash value to obtain the data hash value.

4. The method of claim 1, wherein, The data providing end performs secondary encryption on the encrypted data sequence to obtain ciphertext data, comprising: The data providing end generates a symmetric key. The data providing end performs symmetric encryption on the encrypted data sequence by using the majority of symmetric keys.

5. The method of claim 1, wherein, The data receiving end performs distributed storage on the ciphertext data, comprising: The data receiving end performs data analysis on the ciphertext data by using a pre-trained encrypted data analysis model to obtain a data analysis result. The data receiving end performs data flow transferring analysis on all flow records by using a pre-trained data flow transferring analysis model to obtain a flow transferring analysis result. The data receiving end generates a resource allocation strategy based on the ciphertext data, the data analysis result and the flow analysis result by using a pre-trained resource allocation model, and the resource allocation strategy is used to guide storage of the ciphertext data. The data receiving end divides the ciphertext data into multiple data fragments and stores each data fragment in a distributed manner according to the resource allocation strategy.

6. A data management apparatus characterized by comprising: Comprise: A data providing module is configured to encrypt a preset data segment by a data providing end to obtain an encrypted data sequence, determine a data hash value of the encrypted data sequence, encrypt the encrypted data sequence twice to obtain ciphertext data, generate a first flow record associated with a current address of the data providing end by using the data hash value, and store the first flow record to a data storage end, send the data hash value and the ciphertext data to a data flow end, generate a second flow record associated with a current address of the data flow end by using the data hash value, and store the second flow record to the data storage end; A data flow module is configured to send the data hash value and the ciphertext data to a next data flow end or a data receiving end; A data receiving module is configured to decrypt the ciphertext data to obtain a restored encrypted data sequence, determine a restored hash value of the restored encrypted data sequence, verify whether the restored hash value is consistent with the data hash value, in response to verifying that the restored hash value is consistent with the data hash value, retrieve the first flow record and the second flow record from the data storage end, and determine respective restored root hashes of the first flow record and the second flow record, verify whether each restored root hash is consistent with the data hash value, in response to verifying that each restored root hash is consistent with the data hash value, store the ciphertext data in a distributed manner.

7. An electronic device, comprising: Comprise: One or more processors; A storage device having one or more programs stored thereon, When the one or more programs are executed by the one or more processors, the one or more processors implement the method of any one of claims 1-5.

Images