Data transmission method, and apparatus and device

Abstract

A data transmission method, and an apparatus and a device. In the present application, a data sending apparatus processes data to be sent, so as to obtain a plurality of blocks; for any block among the plurality of blocks, the data sending apparatus encrypts the block by using a data key in a TEE that corresponds to the block, wherein different blocks correspond to different data keys; and the data sending apparatus encrypts a data key corresponding to each block, and transmits to a data receiving apparatus the plurality of encrypted blocks and data keys corresponding to the respective encrypted blocks. The data keys which are used for encrypting the blocks are generated in the TEE. Since the TEE has a relatively high degree of security, the TEE is not prone to experiencing information leakage, thereby effectively ensuring the security of the data keys on the side of the data sending apparatus. Each block is encrypted using a data key corresponding to the block, such that the difficulty of breaching the block is increased, thus ensuring the security of each block.

Description

Data transmission method, device and equipment

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of the People's Republic of China on February 29, 2024, with application number 202410232644.7 and application name "A Data Transmission Method, Device and Equipment", the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of communication technology, and in particular to a data transmission method, apparatus, and device. Background Art

[0004] In recent years, with the increasing demand for data transmission, the security requirements of data during transmission have become an important criterion for measuring data transmission.

[0005] The following uses file transfer as an example to illustrate how data transmission security is ensured. Typically, file transfer is implemented in a secure sockets layer (SSL) / transport layer security (TLS) network channel. The encryption key provided by the SSL / TLS protocol encrypts the transmitted file to ensure the security of the file. In this protocol, a key exchange is performed at the beginning of the session establishment for file transfer. The two parties to the transfer exchange a key, which is the encryption key used to encrypt / decrypt the file. The security of the file is guaranteed by this key. Since the key used to encrypt the file is a key previously exchanged between the two parties to the transfer, when the file has a long data volume, it is easy to find the correspondence between the ciphertext and the plaintext, which will easily lead to the leakage of the file, and even the key used to encrypt the file can be easily cracked. Summary of the Invention

[0006] The embodiments of the present application provide a data transmission method, apparatus, and device for ensuring data security.

[0007] In a first aspect, an embodiment of the present application further provides a data transmission method, which is performed by a data sending device, wherein:

[0008] When the data sending device determines that data needs to be sent, the data sending device processes the data to be sent to obtain multiple blocks.

[0009] After obtaining the multiple blocks, the data transmitting device stores the data key corresponding to any of the multiple blocks in the TEE. The data transmitting device encrypts the block using the data key corresponding to the block, with different data keys corresponding to different blocks. The data transmitting device encrypts the data key corresponding to each block and transmits the encrypted multiple blocks and the encrypted data key corresponding to each block to the data receiving device.

[0010] Through the above method, the data key used to encrypt each block is generated within the TEE. Due to the high security of the TEE, information leakage is unlikely, effectively ensuring the security of the data key on the data transmission device. Furthermore, each block is encrypted using its corresponding data key, increasing the difficulty of decrypting the block and ensuring the security of each block. Furthermore, encrypting the data key corresponding to each block reduces the risk of leakage during transmission.

[0011] In one possible implementation, the data sending device can obtain the data key corresponding to the block from the TEE when encrypting the block using the data key corresponding to the block, and encrypt the block using the data key corresponding to the block. After encrypting the data key corresponding to each of the multiple blocks, the data sending device destroys the data key corresponding to each of the multiple blocks. The destruction here refers to destroying the data key corresponding to each block outside the TEE. The data key corresponding to each block can be retained in the TEE.

[0012] Through the above method, the data key corresponding to each block in the multiple blocks is destroyed after the encryption is completed, which can prevent the data key from being leaked after encryption and ensure the security of the block.

[0013] In one possible implementation, a secure channel is provided within the data transmission device. This secure channel is used to transmit the data key corresponding to each block from the TEE to outside the TEE. When encrypting a block, the data key corresponding to the block is obtained from the TEE through the secure channel, and the block is encrypted using the obtained data key.

[0014] Through the above method, the existence of a secure channel ensures that the data key corresponding to the block can be securely obtained from the TEE, further reducing the risk of data key leakage.

[0015] In one possible implementation, multiple blocks cannot be derived from each other.

[0016] Through the above method, the data sending device cannot deduce the multiple blocks obtained after data processing, ensuring that during the transmission process, even if some of the blocks are cracked, the cracked blocks cannot be used to deduce other blocks, effectively ensuring the security of the data during transmission.

[0017] In one possible implementation, there are many ways to encrypt the data key corresponding to each block, one of which is listed here. The data sending device generates a transfer key in the TEE and uses the transfer key to encrypt the data key corresponding to each block. The transfer key is then encrypted using the public key of the data receiving device and transmitted to the data receiving device.

[0018] Through the above method, the security of the data key is guaranteed by the circulation key, and the security of the circulation key is guaranteed by the public key of the data receiving device. This ensures that only the data receiving device can decrypt and obtain the circulation key, and then decrypt and obtain the data key.

[0019] In a possible implementation, when the data sending device processes data to obtain multiple data, data recovery information can be obtained according to the data processing process. The data recovery information describes a method for restoring multiple blocks into data.

[0020] When the data recovery information is generated, the data sending device encrypts the data recovery information and transmits the encrypted data recovery information to the data receiving device.

[0021] In some application scenarios, the data sending device and the data receiving device may pre-agreed on a data segmentation method, and the data receiving device may independently determine how to restore the multiple segments into data based on the data segmentation method. In this case, the data sending device may no longer generate and transmit the data recovery information.

[0022] Through the above method, the data transmitting device transmits the data recovery information, ensuring that the data receiving device can quickly and easily recover the data using the multiple blocks. Encrypting the data recovery information effectively ensures its security, prevents leakage, and reduces the possibility of it being obtained by devices other than the data receiving device, further ensuring data security.

[0023] In one possible implementation, before transmitting the encrypted multiple blocks and the data key corresponding to each encrypted block to the data receiving device, the data sending device uses the private key of the data sending device to sign the encrypted multiple blocks and the data key corresponding to each encrypted block.

[0024] Through the above method, by signing the information to be transmitted (such as the encrypted multiple blocks and the encrypted data key), the integrity of the information to be transmitted can be effectively guaranteed and the information to be transmitted can be prevented from being tampered with.

[0025] In one possible implementation, the data sending device may generate a data access policy that describes the conditions required for accessing data, encrypt the data access policy, and transmit the encrypted data access policy to the data receiving device.

[0026] Through the above method, the existence of the data access policy can ensure that after the data reaches the data receiving device, the data is only accessed when it complies with the data access policy, thereby ensuring the security of the data after reaching the data receiving device.

[0027] In one possible implementation, the data access policy includes some or all of the following:

[0028] The objects that are allowed to initiate data access operations, the time when data access is allowed, and the types of operations that are allowed to be performed on the data.

[0029] Through the above method, the data access policy describes the conditions required to access data from different dimensions. The control granularity of data access is flexible and changeable, suitable for different application scenarios.

[0030] In one possible implementation, the embodiment of the present application does not limit the method of processing data to obtain multiple blocks. Two methods are listed below:

[0031] Method 1: Subdivision and reorganization.

[0032] Split the data into multiple shards.

[0033] Disrupt the order of multiple shards, reorganize multiple shards, and generate multiple blocks.

[0034] Method 2: Increase noise.

[0035] Split the data into multiple candidate chunks.

[0036] Noise is added to each candidate block or data in each candidate block is modified to obtain multiple blocks.

[0037] Through the above method, the way of obtaining multiple blocks for data processing is more flexible and suitable for different application scenarios.

[0038] In a possible implementation, the data sending device may generate a data key corresponding to each block in the TEE.

[0039] Through the above method, the data key corresponding to each block is generated in TEE, which can prevent the data key from being leaked during the generation process.

[0040] In a second aspect, an embodiment of the present application further provides a data transmission method, which can be performed by a data receiving device, wherein:

[0041] The data receiving device receives a plurality of encrypted blocks and a data key corresponding to each encrypted block from the data sending device.

[0042] The data receiving device stores the encrypted multiple blocks. After decrypting the data key corresponding to each encrypted block, the data receiving device stores the data key corresponding to each block in the TEE or encrypts and stores the data key corresponding to each block in the TEE.

[0043] Through the above method, the data receiving device directly stores the encrypted multiple blocks, which can prevent the blocks from being leaked on the data receiving device side. The data key corresponding to each block can effectively ensure the security of the data key corresponding to each block in the TEE.

[0044] In one possible implementation, when accessing data, the data receiving device obtains the data key corresponding to each block from the TEE, uses the data key corresponding to each block to decrypt the stored encrypted blocks to obtain the data, and then destroys the data key corresponding to each block. This destruction refers to destroying the data key corresponding to each block outside the TEE, while the TEE can retain the data key corresponding to each block.

[0045] Through the above method, the data receiving device will decrypt the encrypted multiple blocks only when it needs to access the data, so as to ensure the security of the multiple blocks on the data receiving device side.

[0046] In one possible implementation, when the data receiving device decrypts the data key corresponding to each encrypted block, it obtains the encrypted circulation key from the data sending device; decrypts the encrypted circulation key using the private key of the data receiving device; and decrypts the data key corresponding to each encrypted block using the circulation key.

[0047] Through the above method, the security of the data key is guaranteed by the circulation key, and the security of the circulation key is guaranteed by the public key of the data receiving device, so that only the device that has the private key of the data receiving device can decrypt and obtain the circulation key, and then decrypt and obtain the data key.

[0048] In one possible implementation, a data receiving device receives encrypted data recovery information from a data transmitting device. The data recovery information describes how to recover data from multiple blocks. The data receiving device decrypts the encrypted data recovery information and stores it. When access to the data is required, the data receiving device processes the multiple blocks based on the data recovery information to retrieve the data.

[0049] Through the above method, the data receiving device can quickly and accurately obtain the data using the data recovery information, and because the data recovery information is transmitted to the data receiving device after being encrypted, it is ensured that the data recovery information is not easily leaked.

[0050] In one possible implementation, the data receiving device receives the encrypted multiple blocks and the signature of the data key corresponding to each encrypted block from the data sending device before decrypting the data key corresponding to each encrypted block; and uses the public key of the data sending device to verify the encrypted multiple blocks and the signature of the data key corresponding to each encrypted block.

[0051] Through the above method, by verifying the signature, the integrity of the multiple encrypted blocks and the data keys corresponding to each encrypted block can be effectively guaranteed, and it can be discovered in time whether the multiple encrypted blocks and the data keys corresponding to each encrypted block have been tampered with.

[0052] In one possible implementation, a data receiving device receives an encrypted data access policy from a data sending device. The data access policy describes the conditions required for accessing the data. After decrypting the encrypted data access policy, the data receiving device transmits it to a kernel-mode rights management program. The rights management program then determines whether the data access operation complies with the data access policy.

[0053] Through the above method, the permission management program in the kernel state authenticates the data access operations initiated for the data based on the data access policy, ensuring that the operations to access the data can always meet the data access policy, preventing malicious applications from accessing the data, and ensuring the security of the data.

[0054] In one possible implementation, the data access policy includes some or all of the following:

[0055] The objects that are allowed to initiate data access operations, the time when data access is allowed, and the types of operations that are allowed to be performed on the data.

[0056] Through the above method, the data access policy can describe the conditions required to access data from multiple different aspects, which is applicable to different data access scenarios. The control granularity of data access is not single.

[0057] In a possible implementation, when acquiring the data, the data receiving device may restore the multiple data into the data based on the data recovery information or the data block method pre-agreed with the data sending device.

[0058] When the data sending device divides the data into blocks in a detailed and reorganized manner, the data receiving device divides each block into multiple blocks, reorders the multiple blocks, and reorganizes them into the data.

[0059] When the data sending device divides the data into blocks in a manner of increasing noise, the data receiving device deletes the noise in each block or modifies the data in the block to obtain multiple candidate blocks, and reorganizes the multiple candidate blocks into the data.

[0060] Through the above method, the data receiving device can recover the data in different ways, which are applicable to different scenarios.

[0061] In a third aspect, an embodiment of the present application further provides a data transmission system, which includes a data sending device and a data receiving device. The beneficial effects can be found in the description of the first aspect and are not repeated here. In the data transmission system:

[0062] A data sending device is used to generate multiple blocks based on the data to be sent; for any block among the multiple blocks, the block is encrypted using the data key corresponding to the block stored in the TEE, and the data keys corresponding to different blocks are different; the data key corresponding to each block is encrypted, and the encrypted multiple blocks and the encrypted data key corresponding to each block are transmitted to the data receiving device.

[0063] A data receiving device is used to receive multiple encrypted blocks and the data key corresponding to each encrypted block; save the multiple encrypted blocks; after decrypting the data key corresponding to each encrypted block, save the data key corresponding to each block in the TEE or encrypt and save the data key corresponding to each block in the TEE.

[0064] In one possible implementation, the data sending device obtains the data key corresponding to the block from the TEE, and encrypts the block using the data key corresponding to the block; after the encryption of the data key corresponding to each block in the multiple blocks is completed, the data key corresponding to each block in the multiple blocks is destroyed.

[0065] In one possible implementation, the data sending device obtains the data key corresponding to the block from the TEE through a secure channel.

[0066] In one possible implementation, the data sending device generates a data key corresponding to each block in the TEE.

[0067] In one possible implementation, multiple blocks cannot be derived from each other.

[0068] In one possible implementation, the data sending device generates a data key corresponding to each block in the TEE.

[0069] In a possible implementation, when the data receiving device needs to access the data, it decrypts the stored encrypted multiple blocks using the data key corresponding to each block to obtain the data.

[0070] In one possible implementation, when the data sending device encrypts the data key corresponding to each block, it generates a transfer key in the TEE, and uses the transfer key to encrypt the data key corresponding to each block; the transfer key is encrypted using the public key of the data receiving device, and the encrypted transfer key is transmitted to the data receiving device.

[0071] The data receiving device receives the encrypted transfer key; decrypts the encrypted transfer key using the private key of the data receiving device; and decrypts the data key corresponding to each encrypted block using the transfer key.

[0072] In a possible implementation, the data sending device encrypts the data recovery information and transmits the encrypted data recovery information to the data receiving device. The data recovery information describes a method for restoring the multiple blocks into data.

[0073] The data receiving device recovers information from the received encrypted data; decrypts the encrypted data recovery information, processes the multiple blocks according to the data recovery information, and obtains data.

[0074] In one possible implementation, before the data sending device transmits the encrypted multiple blocks and the data key corresponding to each encrypted block to the data receiving device, the data sending device uses the private key of the data sending device to sign the encrypted multiple blocks and the data key corresponding to each encrypted block, and sends the signatures of the encrypted multiple blocks and the data key corresponding to each encrypted block to the data receiving device.

[0075] The data receiving device receives the encrypted multiple blocks and the signature of the data key corresponding to each encrypted block; and uses the public key of the data sending device to verify the encrypted multiple blocks and the signature of the data key corresponding to each encrypted block.

[0076] In a possible implementation, the data sending device encrypts the data access policy and transmits the encrypted data access policy to the data receiving device. The data access policy describes the conditions that need to be followed for accessing the data.

[0077] The data receiving device receives the encrypted data access policy; after decrypting the encrypted data access policy, the data access policy is transmitted to the authority management program in the kernel state. The authority management is used to determine whether the operation of accessing data complies with the data access policy based on the data access policy.

[0078] In one possible implementation, the data access policy includes some or all of the following:

[0079] The objects that are allowed to initiate data access operations, the time when data access is allowed, and the types of operations that are allowed to be performed on the data.

[0080] In a possible implementation, the data sending device splits the data into multiple fragments, disrupts the order of the multiple fragments, and reorganizes the multiple fragments to generate multiple blocks.

[0081] In a possible implementation, the data sending device splits the data into multiple candidate blocks; adds noise to each candidate block or modifies the data in each candidate block to obtain multiple blocks.

[0082] In a fourth aspect, an embodiment of the present application further provides a data sending device, which has the function of implementing the behavior in the method example in the first aspect above. The beneficial effects can be found in the description of the first aspect and will not be repeated here. The functions can be implemented by hardware or by executing corresponding software through hardware. The hardware or software includes one or more modules corresponding to the above functions. In one possible design, the structure of the data sending device includes a block module, an encryption module, and a sending module. These modules can perform the corresponding functions in the method example in the first aspect above. Please refer to the detailed description in the method example for details, which will not be repeated here.

[0083] In the fifth aspect, the embodiment of the present application further provides a data receiving device, which has the function of implementing the behavior in the method example in the second aspect above. The beneficial effects can be found in the description of the second aspect and will not be repeated here. The functions can be implemented by hardware, or by hardware executing corresponding software implementations. The hardware or software includes one or more modules corresponding to the above functions. In one possible design, the structure of the device includes a receiving module and a decryption module, which can perform the corresponding functions in the method example in the second aspect above. Please refer to the detailed description in the method example for details, which will not be repeated here.

[0084] In a sixth aspect, the present application further provides a computing device comprising a processor and a memory, and may further comprise a communication interface, wherein the processor executes program instructions in the memory to perform the method provided in the first aspect or any possible implementation of the first aspect. Alternatively, the processor executes program instructions in the memory to perform the method provided in the second aspect or any possible implementation of the second aspect. The memory is coupled to the processor and stores computer program instructions and data necessary to determine the data transmission process. The communication interface is used to communicate with other devices.

[0085] In a seventh aspect, the present application provides a computing device system comprising at least one computing device. Each computing device comprises a memory and a processor. The processor of at least one computing device is configured to access code in the memory to execute the method provided in the first aspect or any possible implementation of the first aspect, or the processor of at least one computing device is configured to access code in the memory to execute the method provided in the second aspect or any possible implementation of the second aspect.

[0086] In an eighth aspect, the present application provides a computer-readable storage medium. When the computer-readable storage medium is executed by a computing device, the computing device executes the method provided in the first aspect or any possible implementation of the first aspect, or executes the method provided in the second aspect or any possible implementation of the second aspect. The storage medium stores computer program instructions. The storage medium includes, but is not limited to, volatile memory, such as random access memory, and non-volatile memory, such as flash memory, a hard disk drive (HDD), and a solid state drive (SSD).

[0087] In a ninth aspect, the present application provides a computing device program product, the computing device program product including computer program instructions, which, when executed by a computing device, causes the computing device to perform the method provided in the aforementioned first aspect or any possible implementation of the first aspect, or to perform the method provided in the aforementioned second aspect or any possible implementation of the second aspect. The computer program product may be a software installation package, which may be downloaded and executed on a computing device when the method provided in the aforementioned first aspect or any possible implementation of the first aspect, or the method provided in the aforementioned second aspect or any possible implementation of the second aspect, is required to be used.

[0088] In the tenth aspect, the present application also provides a computer chip, which is connected to a memory, and the chip is used to read and execute computer program instructions stored in the memory, execute the methods in the above-mentioned first aspect and each possible implementation of the first aspect, or execute the above-mentioned second aspect and each possible implementation of the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0089] FIG1A is a block diagram of a neural network model weight file provided by the present application;

[0090] FIG1B is a schematic diagram of a data table file provided in this application;

[0091] FIG2 is a schematic diagram of the structure of a file transmission system provided by the present application;

[0092] 3A and 3B are schematic diagrams of application scenarios of a data transmission method provided by this application;

[0093] FIG4 is a schematic diagram of a data transmission method provided by the present application;

[0094] 5A to 5C are schematic diagrams of a file segmentation method provided by the present application;

[0095] FIG6 is a schematic diagram of authentication of a rights management program provided by this application;

[0096] FIG7 is a schematic structural diagram of a data sending device provided by the present application;

[0097] FIG8 is a schematic structural diagram of a data receiving device provided by the present application;

[0098] 9 and 10 are schematic structural diagrams of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0099] Before introducing a data transmission method provided in an embodiment of the present application, some concepts involved in the embodiment of the present application are clarified:

[0100] (1) File, object, data block.

[0101] Files, objects, and data blocks are specific forms of data. The present embodiments do not limit the specific form of data. Instead, they use file transmission as an example to illustrate a data transmission method provided by the present embodiments. Files can be in the form of documents, images, videos, data tables, audio, and so on.

[0102] (2) Trusted execution environment (TEE).

[0103] A trusted execution environment (TEE) is a secure computing environment based on the underlying hardware. It protects computer program instructions and data running in the TEE from external attacks, including but not limited to attacks from the operating system, hardware, and other applications.

[0104] From the perspective of a computing device's internal processor, a TEE can be considered a feature supported by the device's processor. A processor with this feature can request an independent memory space within the device's memory to store computer program instructions or data with high security requirements. This memory space is accessed only when the processor needs to execute the function, to run the computer program instructions or access the data within it; access is prohibited at all other times.

[0105] In an embodiment of the present application, the data key and the transfer key may be generated in the TEE. The embodiment of the present application does not limit the method of generating the data key and the transfer key in the TEE, such as deriving the data key and the transfer key from the root key of the device. In addition, the keys involved in the embodiment of the present application (such as the data key, the transfer key, the public key and private key of the device, the public key and private key of the opposite device, and the local key of the device) are stored in the TEE to ensure the security of the keys required for data encryption.

[0106] (3) Data encryption algorithm.

[0107] Data encryption algorithms include symmetric encryption algorithms and non-object encryption algorithms.

[0108] A symmetric encryption algorithm is characterized by using the same key for both data encryption and decryption. In the embodiments of the present application, a symmetric encryption algorithm can be used to encrypt each block. A symmetric encryption algorithm can also be used to encrypt the key used for each block encryption. To distinguish between different keys, the key used for block encryption is referred to as the data key, and the key used to encrypt the data key is referred to as the flow key.

[0109] The characteristic of an asymmetric encryption algorithm is that different keys are used to encrypt and decrypt data, and the different keys are generally divided into public keys and private keys. Among them, data encrypted with a public key can be decrypted using a private key, and vice versa. Generally speaking, the public key is public and can be obtained by any device or apparatus, while the private key is non-public and can only be known and saved by the owner of the key. In an embodiment of the present application, a data receiving device has its public key and private key, and the public key of the data receiving device can be obtained by a data sending device. Similarly, a data sending device has its public key and private key, and the public key of the data sending device can be obtained by a data receiving device. In an embodiment of the present application, an asymmetric key algorithm can be used to encrypt the flow key.

[0110] (4) Data signature and signature verification.

[0111] Signing data to be sent is a method used to ensure data integrity and non-repudiation. Data signing and signature verification is essentially an asymmetric encryption algorithm.

[0112] A data signature is a string of characters generated by the sender of the data based on the data to be sent and their own private key. For example, the sender extracts a portion of the data to be sent and then encrypts it using their own private key to generate a string of characters.

[0113] The sender of the data sends the data and the data signature to the receiver of the data. The receiver of the data can verify the received data signature (i.e., verify the signature) to determine the integrity of the received data.

[0114] On the one hand, this string is generated based on the data sender's private key, and the data signature is non-repudiatory, meaning the sender cannot deny sending the signed data to the receiver. The receiver verifies the signature using the sender's public key, thereby verifying the sender's signature. On the other hand, this string is generated based on the data to be sent. After verifying the signature using the sender's public key, the receiver can also generate a new string using the received data. By comparing the new string with the verified signature, they can determine whether the data to be received has been tampered with or remains intact.

[0115] In the embodiment of the present application, the data sending device can sign each encrypted block, and when sending each encrypted block (that is, the ciphertext of the block) to the data receiving device, the data sending device can send the signature of each encrypted block. The data sending device can also sign each encrypted data key, and when sending each encrypted data key (that is, the ciphertext of the data key) to the data receiving device, the data sending device can send the signature of each encrypted data key.

[0116] (5) Keys: data key, transfer key, local key.

[0117] The data transmission method in the embodiment of the present application involves a variety of different keys. In order to facilitate distinction, these different keys are named.

[0118] The data key used for block encryption is called the data key. The key used to encrypt the data key is called the transfer key. Furthermore, the data receiving device also stores a local key. After obtaining the data key, the data receiving device can use the local key to encrypt and store the data key to ensure its security.

[0119] It should be noted that in the embodiment of the present application, the encryption of the blocks and the encryption of the data key are both performed using a symmetric encryption algorithm as an example. Therefore, when the data sending device sends the encrypted multiple blocks to the data receiving device, it is also necessary to send the data key (encrypted data key) to the data receiving device. In actual applications, an asymmetric encryption algorithm can be used to encrypt the blocks. The data transmission process is similar. The difference is that when the data sending device sends the encrypted multiple blocks to the data receiving device, it is also necessary to send the key required for decrypting each block (referred to as the data decryption key) to the data receiving device. The operation process of the data decryption key is similar to the operation process of the data key when the blocks are encrypted using a symmetric encryption algorithm in the embodiment of the present application. For details, please refer to the relevant description of the data key in the embodiment of the present application, which will not be repeated here. Similarly, an asymmetric encryption algorithm can also be used to encrypt the data key. For example, the data key is encrypted using the public key of the data receiving device. For another example, an encryption key and a decryption key are generated for encrypting and decrypting the data key, and the data key is encrypted using the encryption key. After the decryption key is encrypted, the encrypted decryption key is transmitted to the data receiving device. The operation process of the decryption key is similar to the operation process of the circulation key when the data key is encrypted using a symmetric encryption algorithm in the embodiment of the present application (such as using the circulation key encryption). For details, please refer to the relevant description of the data key in the embodiment of the present application, which will not be repeated here.

[0120] (6) User state and kernel state.

[0121] User mode and kernel mode are two operating states of the operating system of a computing device.

[0122] Kernel state: A processor in kernel state (such as a central processing unit (CPU)) can access any data, including peripheral devices such as network cards and hard drives. It can switch from one program to another without preempting the currently occupied processor. Kernel state is typically the state a processor is in when executing instructions from a computer program at privilege level 0 (also known as ring 0). Data operations (such as reading and writing) and network data transmission typically require kernel state.

[0123] User state: The processor in user state can only access restricted resources and cannot directly access hardware devices such as memory. When an application in user state (that is, an application running on the processor) needs to directly access hardware devices such as memory, the application in user state needs to be converted to kernel state through a "system call" before it can access hardware devices such as memory and hard disk.

[0124] In an embodiment of the present application, when an application on a data receiving device needs to access the data recovered from each block received by the data receiving device, the application can first transfer the access instruction issued for the data to the kernel state through a system call, and the permission management program in the kernel state will first determine whether the application has data access rights. After determining that the application has data access rights, the processing flow of the access instruction for the data will be completed in the kernel state to achieve access to the data.

[0125] (7) Extended Berkeley Packet Filter (eBPF).

[0126] eBPF is a mechanism for extending the capabilities of the Linux kernel, enabling the addition of new features without modifying the kernel source code. It can be used to expand monitoring and interception of system calls, and is commonly used in performance tracking, log auditing, and other areas.

[0127] (8) Blocks cannot be deduced from each other.

[0128] In the embodiments of the present application, data is processed to obtain multiple blocks. These blocks must satisfy the following conditions: the blocks cannot be derived from each other. The so-called "cannot be derived from each other" means that it is impossible to obtain some or all of the remaining blocks based on the use of some of the blocks. This block partitioning method does not result in obvious correlations between the blocks, or no data patterns exist between the multiple blocks.

[0129] The following uses the block division of the weight file of the neural network model and the block division of the data table as examples to illustrate that "blocks cannot be deduced from each other".

[0130] 1. Weight file of the neural network model.

[0131] Neural network models typically have a specific topological structure. For example, convolutional neural network models like VGG16 and ResNet152 maintain a characteristic of gradually decreasing parameters and increasing channel dimensions from shallow to deep layers. Language models such as BERT, Roberta, and LLaMA also share similar basic structural building blocks. The topological structures of many neural network models are even widely known, as they are published in papers and open source communities. Therefore, a crucial file that determines the performance of a neural network model is the file that records the model's weights (referred to as the neural network model's weight file). This neural network model's weight file is a valuable asset and must not be leaked.

[0132] The weights of a neural network model have a characteristic: by using known weights to initialize certain layers in the neural network model and retraining the model, the weights of each layer in the neural network model can be obtained after the training is completed.

[0133] Therefore, if the weight file of the neural network model is divided into blocks at the layer granularity, resulting in multiple blocks, then when one or more of these blocks are obtained, the neural network model can be retrained using these blocks to eventually obtain the remaining blocks, or data close to the remaining blocks. This situation is considered "blocks can be deduced from each other."

[0134] In an embodiment of the present application, the weight file of the neural network model can be first segmented by layer, and then each layer can be segmented to obtain multiple fragments. The order of the fragments can be disrupted and reorganized to obtain multiple blocks. If one block only contains part of the weights of certain layers in the neural network model, the blocks cannot be deduced from each other.

[0135] As shown in Figure 1A, there are two ways to block the weight file of the neural network model. The left side is a way to block the weight file of the neural network model with layer granularity. This blocking method can easily use some of the blocks to deduce unknown blocks. The right side is the blocking method of the weight file of the neural network model in the embodiment of the present application. It is first divided by layer granularity, and then each layer is divided, and the order is shuffled and then reorganized into multiple blocks. It can be seen that there is no longer any correlation between the blocks, and the blocks cannot be deduced from each other.

[0136] 2. Data table.

[0137] For data table files, if an attacker obtains information about some rows or columns, they can infer other information. For example, if the data table in Figure 1B is divided into behavioral granularity, if an attacker obtains information about some rows and already knows the total cost, combined with the known costs of some individuals, they can infer the costs of the remaining individuals. This allows for mutual deduction between blocks.

[0138] In the embodiment of the present application, after segmenting at the behavioral granularity, it is further segmented at the column granularity to obtain multiple fragments (each fragment can be understood as a cell in the data table). After the multiple fragments are shuffled, they are reorganized into multiple rows. That is, each row still includes name, phone number, and cost, but the name, phone number, and cost are in disorder and not in the correct correspondence. In this way, even if the attacker obtains the information of some rows and knows the total cost, he cannot accurately obtain the cost of the remaining people. It can be seen that there is no longer any correlation between the fragments, and the fragments cannot be deduced from each other.

[0139] As shown in FIG2 , a file encryption system is provided in an embodiment of the present application. From the perspective of file sending and receiving, the file encryption system includes two devices, namely a data sending device 100 and a data receiving device 200 .

[0140] The data sending device 100 is a device for sending data. As the sender of data, the data sending device 100 can encrypt the data to be sent and send the encrypted data to the data receiving device 200. In an embodiment of the present application, the data sending device 100 can use the data key corresponding to the block to encrypt, and encrypt the data key corresponding to each block, and then send the encrypted block and the encrypted data key to the data receiving device 200. In this embodiment of the present application, the specific form of the data sent by the data sending device 100 is not limited. The data can be a file, an object, a data block, or a portion of the data in a file or object, or a user-defined data transmission form.

[0141] In order to ensure the security of data during transmission, the data sending device 100 has the following functions:

[0142] Function 1: Data splitting function.

[0143] For any data to be transmitted, the data transmitting device 100 splits the data into multiple blocks. There are many ways to split data into multiple blocks. For example, the data transmitting device 100 can segment the data according to a fixed granularity to obtain multiple blocks. In another example, the data transmitting device 100 can analyze the semantics of the data and divide the data into multiple blocks based on the semantics of the data, with each block having independent semantics.

[0144] In an embodiment of the present application, to further ensure the security of the data to be transmitted, the data transmitting device 100 may split the data into multiple blocks to satisfy the following conditions: the blocks cannot be derived from each other. "Cannot be derived from each other" means that any block cannot be derived from any other or all of the multiple blocks other than that block. This embodiment of the present application does not limit the method by which the data transmitting device 100 splits the data; any method that ensures that the multiple blocks after the split cannot be derived from each other is applicable to this embodiment of the present application.

[0145] To facilitate the data receiving device 200 in recovering the data from the encrypted blocks after receiving them, the data transmitting device 100 may also generate data recovery information describing how to recover the data from the blocks. In some scenarios, the data transmitting device 100 may not send the data recovery information. For example, the data transmitting device 100 and the data receiving device 200 may pre-agreed on a data splitting method, and the data receiving device 200 may determine how to recover the multiple blocks from the data based on the pre-agreed data splitting method. In this case, the data transmitting device 100 does not need to send the data recovery information to the data receiving device 200.

[0146] Function 2: key generation and encryption function.

[0147] The data sending device 100 can generate and store the keys required for data transmission, such as data keys and transfer keys, in the TEE. The embodiments of the present application do not limit the specific method in which the data sending device 100 generates the keys required for data transmission.

[0148] The number of data keys generated by the data sending device 100 is the same as the number of blocks. Each block corresponds to a data key, and the block is encrypted using the corresponding data key.

[0149] The data sending device 100 can also encrypt the data key. This embodiment of the application does not limit the key used to encrypt the data key. For example, the data sending device 100 uses the public key of the data receiving device 200 to encrypt the data key. For another example, the data sending device 100 can generate a transfer key in the TEE and use the transfer key to encrypt the data key. For the transfer key, the data sending device 100 can use the public key of the data receiving device 200 to encrypt the transfer key.

[0150] When the data sending device 100 also generates data recovery information, the data sending device 100 may also encrypt the data recovery information. The embodiment of the present application does not limit the key used to encrypt the data recovery information. For example, the data sending device 100 uses the public key of the data receiving device 200 to encrypt the data recovery information. For another example, the data sending device 100 may generate a transfer key in a trusted execution environment, and use the transfer key to encrypt the data key. For the transfer key, the data sending device 100 may use the public key of the data receiving device 200 to encrypt the transfer key. For another example, the data sending device 100 may generate a key specifically for encrypting data recovery information in a trusted execution environment, and use the key to encrypt the data recovery information. For the key specifically for encrypting data recovery information, the data sending device 100 may use the public key of the data receiving device 200 to encrypt the key.

[0151] Function three: Data access policy management.

[0152] For data to be sent, after the data is transmitted to the data receiving device 200, access to the data within the data receiving device 200 must meet certain conditions. The data sending device 100 can set a data access policy for the data to be sent, which describes the conditions required to access the data.

[0153] Data access policies include some or all of the following: objects that are allowed to initiate data access operations, the time when data access is allowed, and the types of operations that are allowed to be performed on the data.

[0154] Among them, the object that initiates the data access operation describes which objects are allowed to access the data. The embodiment of the present application does not limit the specific type of the object. The object can be a device or application that directly initiates the data access operation, and the object can also be a user that indirectly triggers the data access operation. In the data access policy, there are many ways to record the objects that are allowed to initiate data access operations. For example, the address of the object can be recorded, such as the device address that initiates the data access operation. The device address includes but is not limited to: an Internet protocol (IP) address, or a media access control address (MAC) address. For another example, the identification information of the object can be recorded, such as the device identification, application identification or user identification that initiates the data access operation. The embodiment of the present application does not limit the specific way of recording the objects that are allowed to initiate data access operations in the data access policy.

[0155] The time allowed to access data describes the time or time period during which data access is allowed. The type of operation allowed to be performed on the data describes the operations allowed to be performed on the data, including but not limited to: adding new data to the data, modifying part of the data, deleting part of the data, viewing the data, and deleting the data.

[0156] The following uses a file as an example to illustrate the data access process: Once a file arrives at data receiving device 200, if a user needs to access the file, they can operate the application running on data receiving device 200 to access the file. The user must log in their personal information on the computing device or the application on the computing device to obtain permission to operate the application on the computing device. Once permission is obtained, the application on the computing device can be triggered to access the file. Therefore, a data access policy controls file operations by describing the objects allowed to initiate file access operations, the time allowed for file access, and the operations allowed on the file, thereby ensuring file security.

[0157] The embodiments of the present application do not limit the specific form of the data sending device 100. The data sending device 100 may be a hardware device, such as a computing device, a computing device cluster, or a chip or processor in a computing device. The data sending device 100 may also be a software device, such as data management software, a container, or a virtual machine deployed on one or more computing devices.

[0158] The data receiving device 200 is a device that receives data. As the data receiver, the data receiving device 200 can receive the encrypted blocks and data keys, decrypt the encrypted data keys, and save the encrypted blocks and data keys.

[0159] In order to ensure that the data can be received smoothly, the data receiving device 200 has the following functions:

[0160] Function 1: Decryption function.

[0161] The various information sent by the data sending device 100 (such as blocks, data keys, data recovery information, encrypted flow keys, etc.) are all encrypted. In order to obtain various information, the data receiving device 200 needs to decrypt the encrypted various information. The embodiment of the present application does not limit the time when the data receiving device 200 decrypts the various information. For example, after receiving various information, the data receiving device 200 immediately decrypts the various information and saves the decrypted various information. For another example, the data receiving device 200 can first decrypt the data key and temporarily keep the encrypted blocks. When it is necessary to access the data, the encrypted blocks are decrypted using the data key to obtain the data and access the data.

[0162] For another example, for the encrypted blocks, the data receiving device 200 may directly save the encrypted blocks after receiving the encrypted blocks.

[0163] For the encrypted data key, the data receiving device 200 may first decrypt the encrypted data key, obtain the data key, and then encrypt the data key using the local key of the data receiving device 200, and save the encrypted data key.

[0164] Decrypting the encrypted data key corresponds to encrypting the data key on the data transmitting device 100. When the data transmitting device 100 encrypts the data key using the circulation key, the data receiving device 200 decrypts the encrypted circulation key using its private key, obtaining the circulation key, and then decrypts the encrypted data key using the circulation key. When the data transmitting device 100 encrypts the data key using its public key, the data receiving device 200 decrypts the encrypted data key using its private key.

[0165] The data receiving device 200 may store the encrypted data recovery information in association with the encrypted blocks, or may decrypt the encrypted data recovery information and store the data recovery information in association with the encrypted blocks.

[0166] Function 2: Data recovery function.

[0167] After receiving the encrypted blocks, the data receiving device 200 can not only decrypt the encrypted blocks, but also process the multiple blocks and restore the multiple blocks to data.

[0168] When the data receiving device 200 receives the encrypted blocks, it also receives the encrypted data recovery information. After decrypting the data recovery information, the data receiving device 200 can process each block according to the data recovery information and restore the multiple blocks to data.

[0169] When a block division method is pre-agreed between the data receiving device 200 and the data sending device 100, the data receiving device 200 can process each block according to the pre-agreed block division method to restore the data.

[0170] Function 3: Data access permission management function

[0171] The data receiving device 200 can also receive a data access policy from the data transmitting device 100. The data receiving device 200 is internally provided with a rights management program running in kernel mode. The rights management program can parse the data access policy and, based on the data access policy, determine whether the initiated access operation to the data complies with the data access policy. For example, when an application initiates an access operation to the data, the rights management program determines, based on the data access policy, whether the application has data access rights and performs authentication.

[0172] In an embodiment of the present application, when an application needs to access data, the application will initiate an access instruction for the data, and the access instruction for the data needs to be processed in the kernel state. In the kernel state, the access instruction for the data will pass through the permission management program. Only after the permission management program successfully authenticates, the access instruction for the data will be processed in the kernel state to access the data and complete the reading or writing of the data.

[0173] The embodiments of the present application do not limit the specific form of the data receiving device 200. The data receiving device 200 may be a hardware device, such as a computing device, a computing device cluster, or a chip or processor in a computing device. The data receiving device 200 may also be a software device, and the data sending device 100 may be software, a container, or a virtual machine deployed on one or more computing devices.

[0174] In an embodiment of the present application, when data needs to be sent, the data sending device 100 splits the data into multiple blocks, and the blocks cannot be deduced from each other. The data sending device 100 encrypts the blocks using the data key corresponding to each block, and encrypts the data key corresponding to each block. After the encryption operation is completed, the data sending device 100 transmits the encrypted blocks and the encrypted data key to the data receiving device 200. After receiving the encrypted blocks and the encrypted data key, the data receiving device 200 decrypts and saves the encrypted data key, thereby saving the encrypted blocks. In an embodiment of the present application, each block is encrypted using the corresponding data key. This ensures that even if the data key corresponding to one of the blocks is cracked, the cracked data key cannot be used to decrypt other blocks, thereby ensuring the security of the data. Moreover, since the blocks formed after the data sending device 100 split the data cannot be deduced from each other, even if some of the blocks are stolen, the stolen blocks cannot be used to deduce other blocks, further ensuring the security of the data.

[0175] The data transmission method provided in the embodiments of the present application is applicable to various data transmission scenarios, two of which are listed below.

[0176] Scenario 1: Transmission scenario of neural network model weight files.

[0177] In the field of artificial intelligence, neural network models are core assets. Loss or theft of a neural network model's weight file (which records the weights configured at each network layer in the machine learning module) can cause significant losses to the company to which the model belongs. Therefore, the security of the machine learning module must be ensured during the transmission of the neural network model's weight file.

[0178] As shown in Figure 3A, the transmission of the weight file of the neural network model can adopt the file transmission method provided in the embodiment of the present application. Taking the server's need to send the weight file of the neural network model to the terminal where the neural network model is deployed as an example, when the server sends the weight file of the neural network model, it will split the weight file of the neural network model to generate multiple blocks. When splitting the weight file of the neural network model, the information association between the multiple blocks can be avoided and the splitting granularity can be reduced. For example, you can first use the layer as the granularity, split it, and then divide each layer, and reorganize it into multiple data blocks in a disordered order, and each block only contains part of the weights configured in a single network layer.

[0179] After the server completes the splitting of the weight file of the neural network model, it generates a data key corresponding to each block in the TEE, encrypts the block using the data key corresponding to each block, and encrypts the data key corresponding to each block. The server sends the encrypted blocks and encrypted data keys (optionally, also including encrypted data recovery information) to the terminal that needs to deploy the neural network model. After receiving the encrypted blocks and encrypted data keys (optionally, also including encrypted data recovery information), the terminal decrypts the encrypted data keys and saves the data keys in the TEE. When it is necessary to run the neural network model, the encrypted blocks are encrypted using the saved data keys, and each block is processed based on the data recovery information to generate a neural network model.

[0180] Scenario 2: Data trading market scenario.

[0181] As shown in Figure 3B, in the data trading market scenario, data transactions will be conducted between data owners and data demanders. The data owner can provide the data demander with the files required by the data demander, and the data demander will provide the data owner with corresponding remuneration in accordance with the agreement with the data owner to complete the transaction. During the entire transaction process, a third party trusted by both parties can supervise the transaction, such as recording information during the interaction process and issuing the public key required for data interaction to both parties of the data transaction.

[0182] In this scenario, if the file transmitted by the data owner to the data demander is leaked, it will cause losses to both parties of the transaction. The file can be transmitted using the file transmission method provided in the embodiment of the present application. When the data owner transmits a file to the data demander, the file can be split into multiple blocks that have no information connection with each other. For example, for a file containing multiple tables, the table can be split along the column direction, and then the columns from different tables can be reorganized to form multiple new tables. Each table is regarded as a block.

[0183] After completing the splitting of the file, the data owner generates a data key corresponding to each block, encrypts the block using the data key corresponding to each block, and encrypts the data key corresponding to each block. The data owner sends the encrypted blocks and encrypted data keys (optionally, also including encrypted data recovery information) to the data demander. After receiving the encrypted blocks and encrypted data keys (optionally, also including encrypted data recovery information), the data demander decrypts the encrypted data keys and saves the data keys in the TEE. When the file needs to be used, the encrypted blocks are encrypted using the saved data keys, and each block is processed based on the data recovery information to generate the file containing multiple tables.

[0184] The following uses the case where the data to be transmitted is a file as an example, and describes a data transmission method provided by an embodiment of the present application in conjunction with FIG4 . The method includes two parts. One part is the file processing process on the data sending device 100 side, which can be specifically referred to as steps 401 to 405. During this processing process, the data sending device 100 needs to implement the splitting of the file, the encryption of the blocks, and the encryption of the relevant keys. The other part is the file processing operation on the file receiving side, which can be specifically referred to as steps 407 to 412. During this processing process, the data receiving device 200 needs to implement the storage of the blocks, the decryption and storage of the relevant keys, and the access to the files.

[0185] Step 401: The data sending device 100 splits the file to obtain multiple blocks. Optionally, the data sending device 100 can also generate data recovery information, which is used to describe the method of recovering the multiple blocks into the file.

[0186] The embodiment of the present application does not limit the specific manner in which the data sending device 100 performs step 401. For example, the data sending device 100 performs segmentation based on a fixed granularity starting from the first character of the file to form a plurality of blocks of the same size. For another example, the data sending device 100 analyzes the semantics of the file and splits the file into a plurality of blocks with independent semantics; taking a data table file as an example, assuming that the data representation records the personal information of each employee in a company, and each row in the data table describes the personal information of an employee, then each row has independent semantics, and the data sending device 100 can split the data table file by row to obtain a plurality of blocks, each block being a row in the data table file.

[0187] The data sending device 100 may also use other methods to split the file, and the obtained multiple blocks meet the following requirements: the multiple blocks cannot be deduced from each other. The embodiment of the present application does not limit the file splitting method that makes the multiple blocks cannot be deduced from each other. The following are two ways to split the file:

[0188] Method 1: Refine and reorganize.

[0189] As shown in FIG5A , it is a schematic diagram of a file splitting method provided in an embodiment of the present application.

[0190] First, the data transmitting device 100 splits the file into smaller fragments than the block. That is, the data transmitting device 100 splits the file to obtain multiple fragments. The embodiment of the present application does not limit the manner in which the data transmitting device 100 splits the file into fragments. For example, the data transmitting device 100 may split the file into multiple fragments without semantic meaning (that is, a single fragment does not represent any semantic meaning).

[0191] Afterwards, the data transmitting device 100 disrupts the order of the multiple fragments and reorganizes the multiple fragments after the order is disrupted into multiple blocks.

[0192] Method 2: Add noise to the blocks.

[0193] 1. Add noise at set positions within the block.

[0194] As shown in FIG5B , it is a schematic diagram of a file splitting method provided in an embodiment of the present application.

[0195] First, the data sending device 100 splits the file into candidate blocks.

[0196] Afterwards, for any candidate block, the data transmitting apparatus 100 adds noise (ie, redundant data) to one or more positions in the candidate block, and uses the candidate block with added noise as the block. In essence, this process adds some noise to the block.

[0197] 2. Modify the data at the set position within the block.

[0198] As shown in FIG5C , it is a schematic diagram of a file splitting method provided in an embodiment of the present application.

[0199] First, the data sending device 100 splits the file into candidate blocks.

[0200] Afterwards, for any candidate block, the data transmitting device 100 modifies the data at one or more locations within the candidate block. For example, the data at the one or more locations is modified according to a predetermined method. In essence, the data modification process adds noise to the data itself.

[0201] In order to facilitate the subsequent use of each block to restore the file, the data sending device 100 can generate data recovery information based on the process of splitting the file, and the data recovery information describes the method of restoring multiple blocks into the file. For example, when the data sending device 100 adopts method one to split the file, the data recovery information can record the size of the block, the size of the fragment, and the position of each fragment in the file. For another example, when the data sending device 100 adopts method two (such as adding noise at a set position) to split the file, the data recovery information can record the size of the block, the position where the noise is added in the block, and the added noise. For another example, when the data sending device 100 adopts method two (such as modifying the data at a set position) to split the file, the data recovery information can record the size of the block, the position of the data modification in the block, and the method.

[0202] Step 402: The data sending device 100 generates multiple data keys in the TEE, and the number of the data keys is the same as the number of blocks.

[0203] On the data sending device 100 side, the data sending device 100 can have multiple data keys in the TEE. One data key is used to encrypt a block, and different data keys are used to encrypt different blocks. Therefore, there is a corresponding relationship between the data key and the block. In the embodiment of the present application, the data key used to encrypt the block is called the data key corresponding to the block. Generating a data key in the TEE can ensure that the data key is not leaked and ensure the security of the data key. The number of data keys is the same as the number of blocks, which can ensure that each block can correspond to a data key. Different blocks correspond to different data keys.

[0204] Step 403: For any block, the data sending device 100 uses the data key corresponding to the block in the TEE to encrypt the block.

[0205] After the data sending device 100 generates multiple data keys, the data sending device 100 may execute step 403 to encrypt the multiple blocks using a symmetric encryption algorithm.

[0206] Inside the data sending device 100, for any block, the data sending device 100 obtains the data key corresponding to the block from the TEE, encrypts the block using the data key corresponding to the block, and destroys the data key when the encryption is completed and step 404 is completed.

[0207] From a hardware perspective, inside the data sending device 100, step 403 can be completed by the processor inside the data sending device 100. Step 403 can also be completed by the processor inside the data sending device 100 and the accelerator card for data encryption. The processor can transmit the data key from the TEE to the accelerator card through a secure channel. After obtaining the data key, the accelerator card encrypts the blocks and destroys the data key after the encryption is completed. The embodiment of the present application does not limit the specific type of the secure channel. For example, the secure channel is a physical transmission line between the processor and the accelerator card. For another example, the secure channel is a logical transmission channel based on the physical transmission line between the processor and the accelerator card. Specific transmission rules need to be followed in the logical transmission channel (such as scrambling the data transmitted in the logical transmission channel).

[0208] Step 404: The data sending device 100 encrypts the data key.

[0209] Since a symmetric encryption algorithm is used to encrypt the blocks, the data key is also the key required to decrypt the encrypted blocks. In order to enable the data receiving device 200 to decrypt the encrypted blocks, the data sending device 100 needs to transmit the data key to the data receiving device 200.

[0210] To ensure the security of the data key, the data sending device 100 may perform step 404. The embodiment of the present application does not limit the manner in which the data sending device 100 encrypts the data key. Several manners for encrypting the data key are listed below.

[0211] Method 1: Use a symmetric encryption algorithm to encrypt the data key.

[0212] On the data transmitting device 100 side, the data transmitting device 100 can generate a transfer key in the TEE. The transfer key represents the key used for encryption / decryption using a symmetric encryption algorithm. The data transmitting device 100 can use the transfer key to encrypt the data key in the TEE. The data transmitting device 100 can encrypt the transfer key using the public key of the data receiving device 200.

[0213] Method 2: Use a symmetric encryption algorithm to encrypt the data key.

[0214] On the data transmitting device 100 side, the data transmitting device 100 may store the public key of the data receiving device 200 in the TEE, and the data transmitting device 100 may encrypt the data key using the public key of the data receiving device 200 in the TEE.

[0215] On the data transmitting device 100 side, the data transmitting device 100 generates a first encryption key and a second decryption key in the TEE. The data transmitting device 100 can use the first encryption key to encrypt the data key in the TEE. The data transmitting device 100 can also use the public key of the data receiving device 200 to encrypt the first decryption key in the TEE. Subsequently, when the data transmitting device 100 sends the encrypted transfer key, it also sends the encrypted first decryption key.

[0216] Step 405: The data transmitting device 100 encrypts the data access policy. The data access policy describes the conditions required for accessing the file. The data access policy includes some or all of the following: the objects allowed to initiate file access operations, the time allowed to access the file, and the types of operations allowed to be performed on the file.

[0217] Among them, the meanings expressed by the object that initiates the file access operation, the time when file access is allowed, and the type of operation allowed to be performed on the file are similar to the meanings of the object that allows the initiation of data access operations, the time when data access is allowed, and the type of operation allowed to be performed on the data in the aforementioned description. The only difference is the object of access. What is described here is the data access policy when accessing the file, and the aforementioned description is the data access policy when accessing the data. Please refer to the aforementioned description for details and will not be repeated here.

[0218] As the sender of a file, the data sending device 100 can set a data access policy for the file to prevent the file from being stolen or leaked after being transmitted to the other party. After setting the data access policy, the data sending device 100 can encrypt the data access policy.

[0219] The embodiment of the present application does not limit the way in which the data sending device 100 encrypts the data access policy. The way in which the data sending device 100 encrypts the data access policy is similar to the way in which the data sending device 100 encrypts the data key. That is, the data access policy can be encrypted using a circulation key or the public key of the data receiving device 200. Of course, in actual applications, the key used by the data sending device 100 to encrypt the data access policy can also be other keys. It should be noted that if the amount of data in the data access policy is large, the space in the TEE is insufficient to store the data access policy. When encrypting the data access policy, the data sending device 100 obtains the key used for encryption (such as the circulation key) from the TEE, and encrypts the data access policy outside the TEE.

[0220] Optionally, if the data sending device 100 also generates data recovery information, the data sending device 100 may also encrypt the data recovery information. The present embodiment does not limit the manner in which the data sending device 100 encrypts the data recovery information. The manner in which the data sending device 100 encrypts the data recovery information is similar to the manner in which the data sending device 100 encrypts the data access policy. For details, please refer to the aforementioned content and will not be repeated here.

[0221] After encrypting the blocks, data keys, data access policies (optionally, data recovery information), the data sending device 100 can also sign the encrypted information (such as blocks, data keys, transfer keys, data access policies, data recovery information), that is, the data sending device 100 can use the private key of the data sending device 100 to sign the encrypted information.

[0222] Step 406: The data transmitting device 100 transmits the encrypted blocks, the encrypted data key, and the encrypted data access policy to the data receiving device 200. Optionally, the data transmitting device 100 may also transmit encrypted data recovery information.

[0223] After encrypting the blocks, data keys, and data access policies (optionally, data recovery information), the data sending device 100 may execute step 406 to transmit the encrypted blocks, data keys, and data access policies to the data receiving device 200 .

[0224] Since there is a correspondence between blocks and data keys, in order to ensure that the data receiving device 200 can use the corresponding key to decrypt the encrypted blocks, the data sending device 100 can inform the data receiving device 200 of the correspondence between blocks and data keys through some or all of the following.

[0225] Method 1: The data transmitting device 100 transmits the encrypted blocks and the encrypted data keys in sequence. That is, the order of the encrypted blocks and the encrypted data keys can represent the corresponding relationship between the blocks and the data keys.

[0226] For example, there are three blocks, namely block 1, block 2, and block 3, and the data key blocks corresponding to these three blocks are data key 1, data key 2, and data key 3. The blocks and their corresponding data keys are sent in the order that the first data key (that is, the encrypted data key) after the block (that is, the encrypted block) is the data key corresponding to the block.

[0227] The order of the encrypted blocks and the encrypted data key can be: encrypted block 1, encrypted data key 1, encrypted block 2, encrypted data key 2, encrypted block 3, encrypted data key 3.

[0228] The order of the encrypted blocks and the encrypted data keys can also be: encrypted block 1, encrypted block 2, encrypted data key 1, encrypted data key 2, encrypted block 3, encrypted data key 3.

[0229] The order of the encrypted blocks and the encrypted data keys can also be: encrypted block 1, encrypted block 2, encrypted block 3, encrypted data key 1, encrypted data key 2, encrypted data key 3.

[0230] For the data receiving device 200, for any encrypted block, the first encrypted data key received thereafter is the data key of the block.

[0231] In the above example, the data key corresponding to the block is sent after the block. The data key of the block can also be sent before the block. Then, the sending order of the blocks and their corresponding data keys satisfies: the block after the data key (that is, the encrypted data key) (that is, the encrypted block) is the block corresponding to the data key.

[0232] In fact, this sequential sending method is essentially that the data sending device 100 and the data receiving device 200 pre-agree or default on a sending rule between blocks and data keys (such as the conditions satisfied by the sending order of blocks and their corresponding data keys mentioned above). The data sending device 100 sends the encrypted blocks and encrypted data keys according to the sending rule, and the data receiving device 200 determines the correspondence between blocks and data keys according to the sending rule.

[0233] Method 2: The data sending device 100 notifies the data receiving device 200 of the corresponding relationship between each block and the data key.

[0234] The data sending device 100 can record the correspondence between each block and the data key, and the correspondence can be stored in the TEE or in a location outside the TEE. The recorded correspondence is transmitted to the data receiving device 200. The embodiment of the present application does not limit the specific presentation form of the correspondence. For example, the correspondence is presented as a correspondence between the identifier of the block and the identifier of the data key corresponding to it, wherein the identifier of the block is the information configured by the data sending device 100 for the block and used to identify the block. The identifier of the data key is the information configured by the data sending device 100 for the data key and used to identify the data key. The identifier of the block can be transmitted to the data receiving device 200 together with the encrypted block, and the identifier of the data key can be transmitted to the data receiving device 200 together with the encrypted data key. For another example, the correspondence is presented as a correspondence between the transmission sequence number of the block and the transmission sequence number of the corresponding data key. The transmission sequence number of the block identifies the order of the block in the transmitted information (that is, the information transmitted in step 406), and the transmission sequence number of the data key identifies the order of the data key in the transmitted information (that is, the information transmitted in step 406).

[0235] The data receiving device 200 obtains the corresponding relationship from the data sending device 100, stores the corresponding relationship, and determines the data key corresponding to the block based on the corresponding relationship. The data receiving device 200 can store the corresponding relationship in the TEE or in a location outside the TEE.

[0236] The data transmission device 100 can send the corresponding relationship separately or as part of the data recovery information. If the corresponding relationship is sent separately, the data transmission device 100 can send the corresponding relationship in plain text (i.e., the corresponding relationship is not encrypted). The data transmission device can also send the corresponding relationship in cipher text (i.e., the corresponding relationship is encrypted). The encryption method of the corresponding relationship can be similar to that of the data recovery information and will not be repeated here.

[0237] If the data sending device 100 uses the private key of the data sending device 100 to sign the encrypted information, the data receiving device 200 can also use the public key of the data sending device 100 to verify the signature after receiving the encrypted information, and can execute subsequent steps after successful verification.

[0238] After receiving the encrypted blocks, data keys, and data access policies (optionally, data recovery information), the data receiving device 200 can perform different processing operations on different information. For details, please refer to the following steps.

[0239] Step 407: For each encrypted block, the data receiving device 200 saves the encrypted block. Optionally, for the encrypted data recovery information, the data receiving device 200 decrypts the encrypted data recovery information and saves the data recovery information in association with each block.

[0240] After receiving the encrypted blocks, the data receiving device 200 directly saves the encrypted blocks to ensure that the file is always saved in an encrypted state except when the file needs to be accessed on the data receiving device 200 side, thereby ensuring the security of the file on the data receiving device 200 side.

[0241] In order to be able to use each block to restore the file when accessing the file subsequently, the data receiving device 200 can also associate and save the data recovery information with each block. The so-called "associated saving" is to save the data recovery information and the encrypted blocks in the data receiving device 200, and record the association between the data recovery information and each block.

[0242] The way in which the data receiving device 200 decrypts the encrypted data recovery information is similar to the way in which the encrypted data key is decrypted. For details on the way in which the encrypted data key is decrypted, please refer to step 408 , and for details, please refer to the description below.

[0243] Step 408: The data receiving device 200 decrypts each encrypted data key and stores the data key in the TEE, or encrypts the data key and stores it in the TEE.

[0244] After receiving the encrypted data keys, the data receiving device 200 decrypts the encrypted data keys.

[0245] When the data transmitting device 100 encrypts the data key using method 1, the data receiving device 200 first decrypts the encrypted transfer key using the private key of the data receiving device 200 to obtain the transfer key. The data receiving device 200 then decrypts each encrypted data key using the transfer key to obtain each data key.

[0246] When the data transmitting device 100 encrypts the data key using method 2, the data receiving device 200 can decrypt each encrypted data key using the private key of the data receiving device 200 to obtain each data key. The data receiving device 200 can also decrypt the encrypted first decryption key using the private key of the data receiving device 200 to obtain the first decryption key; and then decrypt each encrypted data key using the first decryption key to obtain each data key.

[0247] After obtaining each data key, the data receiving device 200 can directly save each data key in the TEE, or save each data key in the TEE after encrypting it. For example, the data receiving device 200 can use the local key of the data receiving device 200 to encrypt each data key, wherein the local key can be a key saved in the TEE.

[0248] Step 409 : The data receiving device 200 decrypts the encrypted data access policy and transmits the data access policy to the rights management program in the kernel state of the data receiving device 200 .

[0249] The decryption method of the encrypted data access policy by the data receiving device 200 corresponds to the encryption method of the data access policy by the data sending device 100. Since the encryption method of the data access policy is similar to the encryption method of the data key, the decryption method of the encrypted data access policy by the data receiving device 200 is similar to the decryption method of the encrypted data key. For the decryption method of the encrypted data key, please refer to step 408 and will not be repeated here.

[0250] As shown in FIG6 , the rights management program is an application running in the kernel state of the data receiving device 200. The rights management program determines whether the access operation to the file complies with the data access policy. The rights management program can authenticate any application that needs to access the file to determine whether the application has the file access permission. If it is determined that the application has the file access permission, the processing flow of the access instruction for the file can be completed in the kernel state.

[0251] After obtaining the data access policy, the permission management program can parse the data access policy and generate a whitelist with file access permissions based on the data access policy. The whitelist with file access permissions records the applications, users or devices that can access the files. Optionally, the whitelist can also record the time when file access is allowed or the operations allowed on the files (such as adding, deleting, checking, and modifying files).

[0252] In order to ensure that the rights management program can run normally and no abnormalities occur, an abnormality detection program can be run in the user state on the data receiving device 200 side. The abnormality detection program is used to detect the running status of the rights management program. The rights management program can maintain a heartbeat connection with the abnormality detection program running in the user state, that is, the rights management program can periodically send setting information to the abnormality detection program. If the abnormality detection program periodically receives the setting information, it is considered that the rights management program is running normally. If the abnormality detection program does not periodically receive the setting information, it is considered that the rights management program is running abnormally. The abnormality detection program can suspend the application's access to the file and initiate an alarm to remind the staff that an abnormality has occurred in the rights management program.

[0253] At this point, the data receiving device 200 has completed processing the encrypted information received, and can access the file on the data receiving device 200. The following describes the file access process using an application running on the data receiving device 200.

[0254] When any application running on the data receiving device 200 needs to access the file, the data receiving device 200 can complete the access to the file through the following steps.

[0255] Step 410: When the application determines that it needs to access a file, the application initiates an access instruction for the file, and triggers the processing of the access instruction for the file in the kernel state through a "system call".

[0256] When a user needs to access a file and perform operations such as adding, deleting, checking, or modifying a file, the user can operate the application to trigger the file access. For example, if the application is a file query program, the user can use the file query program to select the file to be queried and the data to be queried in the file.

[0257] When an application detects a user's operation, it can initiate a file access instruction. Still taking the file query program as an example, when the file query program detects the file and data that the user needs to query, the file query program can initiate a file query instruction, which is used to query the data in the file. The application is interrupted by a "system call" until the file query instruction is processed in kernel mode. At the same time, the file query instruction is transmitted to kernel mode to trigger the processing of the file query instruction in kernel mode.

[0258] Step 411: After the access instruction for the file enters the kernel state, the access instruction for the file needs to first pass through the rights management program. The rights management program authenticates the application based on the file access rights to determine whether the application has the file access rights.

[0259] After entering the kernel state, any access instruction for a file will first pass through the rights management program in the kernel state to determine whether the application has file access rights. Exemplarily, the rights management program can determine whether the application is an application recorded in the whitelist, determine the initiation time of the access instruction for the file and whether the operation on the file complies with the time recorded in the whitelist for allowing access to the file and the operations allowed on the file. After determining that the application complies with the whitelist, it is determined that the application has file access rights. Otherwise, the application does not have file access rights, and the rights management program can reject the access instruction for the file and notify the application that it cannot access the file.

[0260] Step 412: If the rights management program successfully authenticates the application based on the file access rights, the access instruction for the file is processed in the kernel state to achieve access to the file. The access instruction processing for the file is completed by a process or thread in the kernel state.

[0261] When processing the access instruction for the file in kernel mode (i.e., the processing flow of the access instruction for the file), the following steps may be performed in sequence:

[0262] Step 1: Read the encrypted blocks and data recovery information, and obtain the data keys corresponding to each block from TEE.

[0263] Step ②: For any encrypted block, use the data key corresponding to the block to decrypt the encrypted block and destroy the data key corresponding to each block.

[0264] Step 3: Use the data recovery information to process each block and restore the file.

[0265] When the data transmitting device 100 splits the file in the manner shown in FIG5A , the data recovery information records the size of each block, the size of each fragment, and the position of each fragment in the file. The processor in kernel mode can split each block according to the fragment granularity, obtain each fragment, and then combine each fragment according to its position in the file to obtain the file.

[0266] When the data transmitting device 100 splits the file in the manner shown in FIG5B , the data recovery information records the size of the blocks, the locations in the blocks where noise was added, and the added noise. The processor in kernel mode can remove the added noise at the locations in each block, and then combine the noise-deleted blocks to obtain the file.

[0267] Step ④: Access the file according to the access instruction for the file.

[0268] After the file is obtained, the file is accessed according to the access instruction for the file, for example, operations such as adding, deleting, checking, and modifying the file are performed.

[0269] It is worth noting that in the embodiment of the present application, after the access instruction for the file completes the access to the file, the file can be deleted on the data receiving device 200 side; when a subsequent application initiates access to the file, steps 410 to 412 can be executed again to restore the file. That is, each time a file is accessed, the file needs to be restored. In this way, on the data receiving device 200 side, the file will only exist in plain text (non-encrypted) when it is accessed. When the file is not accessed, the file is saved on the data receiving device 200 side in encrypted blocks. This can effectively ensure the security of the file on the data receiving device 200 side. Of course, it is also possible to perform only one file recovery operation, that is, save the file after executing step ③. This can reduce the number of executions of the file recovery operation, reduce the occupancy of the processor on the data receiving device 200 side, and facilitate subsequent access to the file.

[0270] In order to ensure the security of file access in the embodiment of the present application, the eBPF technology can be used to add a monitoring function for read file access in the kernel, that is, to deploy a file monitoring program to monitor the access operation to the file. The file monitoring program can monitor whether the access operation to the file is completed through steps ① to ④ in the kernel state. If the access operation does not comply with steps ① to ④, the access to the file can be terminated and a reminder can be issued to the staff.

[0271] Based on the same inventive concept as the method embodiment, the present embodiment further provides a data transmission device for executing the method performed by the data transmission device 100 in the method embodiment described above. As shown in Figure 7, the data transmission device 700 includes a block segmentation module 701, an encryption module 702, and a transmission module 703. Specifically, in the data transmission device 700, each module is connected via a communication path.

[0272] The block module 701 is configured to generate multiple blocks according to the data to be sent.

[0273] Encryption module 702, used to encrypt any block among the multiple blocks using the data key corresponding to the block in the TEE, where different blocks have different data keys; encrypt the data key corresponding to each block;

[0274] The sending module 703 is used to transmit the encrypted multiple blocks and the data key corresponding to each encrypted block to the data receiving device.

[0275] As a possible implementation method, the encryption module 702 obtains the data key corresponding to the block from the TEE, and encrypts the block using the data key corresponding to the block; after the data key corresponding to each block in the multiple blocks is encrypted, the data key corresponding to each block in the multiple blocks is destroyed.

[0276] As a possible implementation, the encryption module 702 obtains the data key corresponding to the block from the TEE through a secure channel.

[0277] As a possible implementation, the encryption module 702 generates a data key corresponding to each block in the TEE.

[0278] As a possible implementation method, multiple blocks cannot be derived from each other.

[0279] As a possible implementation method, the encryption module 702 generates a transfer key in the TEE, and uses the transfer key to encrypt the data key corresponding to each block; the transfer key is encrypted using the public key of the data receiving device, and after the encryption of the data key corresponding to each block in the multiple blocks is completed, the data key corresponding to each block in the multiple blocks is destroyed; the sending module 703 transmits the encrypted transfer key to the data receiving device.

[0280] As a possible implementation, the encryption module 702 may generate data recovery information and encrypt the data recovery information, wherein the data recovery information describes a method for recovering multiple blocks into data. The sending module 703 transmits the encrypted data recovery information to the data receiving device.

[0281] As a possible implementation, the encryption module 702 uses the private key of the data sending device to sign the encrypted multiple blocks and the data key corresponding to each encrypted block.

[0282] The sending module 703 transmits the encrypted multiple blocks and the signature of the data key corresponding to each encrypted block to the data receiving device.

[0283] As a possible implementation, the encryption module 702 encrypts the data access policy, which describes the conditions that need to be followed for accessing data; the sending module 703 transmits the encrypted data access policy to the data receiving device.

[0284] As a possible implementation, the data access strategy includes some or all of the following:

[0285] The objects that are allowed to initiate data access operations, the time when data access is allowed, and the types of operations that are allowed to be performed on the data.

[0286] As a possible implementation, the chunking module 701 splits the data into multiple shards, disrupts the order of the multiple shards, and reorganizes the multiple shards to generate multiple chunks.

[0287] As a possible implementation, the block module 701 divides the data into multiple candidate blocks; adds noise to each candidate block and then modifies the data in each candidate block to obtain multiple blocks.

[0288] Based on the same inventive concept as the method embodiment, the present embodiment further provides a data receiving device for executing the method performed by data receiving device 200 in the method embodiment described above. As shown in Figure 8, data receiving device 800 includes a receiving module 801 and a decryption module 802. Specifically, in data receiving device 800, each module is connected via a communication path.

[0289] The receiving module 801 is configured to receive a plurality of encrypted blocks and a data key corresponding to each encrypted block from a data sending device.

[0290] The decryption module 802 is used to save the encrypted multiple blocks; after decrypting the data key corresponding to each encrypted block, the data key corresponding to each block is saved in the TEE or the data key corresponding to each block is encrypted and saved in the TEE.

[0291] As a possible implementation method, when the decryption module 802 needs to access data, it obtains the data key corresponding to each block from the TEE, uses the data key corresponding to each block to decrypt the saved encrypted multiple blocks to obtain the data, and destroys the data key corresponding to each block.

[0292] As a possible implementation method, the receiving module 801 receives the encrypted flow key from the data sending device; the decryption module 802 is also used to: use the private key of the data receiving device to decrypt the encrypted flow key; use the flow key to decrypt the data key corresponding to each encrypted block.

[0293] As one possible implementation, the receiving module 801 receives encrypted data recovery information from the data transmitting device, the data recovery information describing a method for recovering data using multiple blocks. The processing module decrypts the encrypted data recovery information and processes the multiple blocks based on the data recovery information to obtain data.

[0294] As a possible implementation, the receiving module 801 receives the encrypted multiple blocks and the signature of the data key corresponding to each encrypted block from the data sending device. The decryption module 802 verifies the encrypted multiple blocks and the signature of the data key corresponding to each encrypted block using the public key of the data sending device.

[0295] As a possible implementation method, the receiving module 801 receives an encrypted data access policy from a data sending device, where the data access policy describes the conditions that must be followed to access the data; after decrypting the encrypted data access policy, the decryption module 802 transmits the data access policy to the permission management program in the kernel state, where the permission management is used to determine whether the operation of accessing the data complies with the data access policy based on the data access policy.

[0296] As a possible implementation, the data access strategy includes some or all of the following:

[0297] The objects that are allowed to initiate data access operations, the time when data access is allowed, and the types of operations that are allowed to be performed on the data.

[0298] The division of modules in the embodiments of the present application is illustrative and is merely a logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional modules in the various embodiments of the present application may be integrated into a single processor, or may exist physically separately, or two or more modules may be integrated into a single module. The aforementioned integrated modules may be implemented in the form of hardware or software functional modules.

[0299] If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a number of instructions for enabling a terminal device (which can be a personal computer, mobile phone, or network device, etc.) or a processor to execute all or part of the steps of the method of each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc., various media that can store program code.

[0300] The present application also provides a computing device 900 as shown in Figure 9. The computing device 900 includes a bus 901, a processor 902, a communication interface 903, and a memory 904. The processor 902, the memory 904, and the communication interface 903 communicate with each other via the bus 901.

[0301] Among them, the processor 902 can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0302] The memory 904 may be a dynamic random access memory (DRAM). In addition to DRAM, the memory 904 may be other random access memories, such as static random access memory (SRAM). In addition, the memory 904 may be a read-only memory (ROM). For example, a programmable read-only memory (PROM) or an erasable programmable read-only memory (EPROM) may be used. The memory 904 may also be a flash memory (FLASH), a hard disk drive (HDD), or a solid state drive (SSD).

[0303] The memory 904 stores computer program instructions, and the processor 902 calls the computer program instructions to execute the steps performed by the data sending device 100 in the method described in FIG. 4 or calls the computer program instructions to execute the steps performed by the data receiving device 200 in the method described in FIG. 4. The memory 904 may also include software modules required for other running processes such as an operating system (such as multiple modules in the data receiving device 800 or multiple modules in the data sending device 700). The operating system may be LINUX TM ,UNIX TM ,WINDOWS TM wait.

[0304] The present application also provides a computing device system, comprising at least one computing device 1000 as shown in FIG10 . The computing device 1000 comprises a bus 1001, a processor 1002, a communication interface 1003, and a memory 1004. The processor 1002, the memory 1004, and the communication interface 1003 communicate with each other via the bus 1001. The at least one computing device 1000 in the computing device system communicates with each other via a communication path.

[0305] Among them, the specific types of the processor 1002 and the memory 1004 can refer to the relevant descriptions of the processor 1002 and the memory 1004, which will not be repeated here. The processor 1002 calls the computer program instructions stored in the memory 1004 to execute part or all of the steps executed by the data sending device 100 in the method described in Figure 4. Or the processor 1002 calls the computer program instructions stored in the memory 1004 to execute part or all of the steps executed by the data receiving device 200 in the method described in Figure 4. The memory may also include software modules required for other running processes such as the operating system. The operating system may be LINUX TM ,UNIX TM ,WINDOWS TM wait.

[0306] At least one computing device 1000 in the computing device system establishes communication with each other through a communication network, and each computing device 1000 runs any one or more modules in the data sending device 700.

[0307] At least one computing device 1000 in the computing device system establishes communication with each other via a communication network, and each computing device 1000 runs any one or multiple modules in the data receiving apparatus 800 .

[0308] The descriptions of the processes corresponding to the above figures have different focuses. For parts that are not described in detail in a certain process, please refer to the relevant descriptions of other processes.

[0309] In the above embodiments, all or part of the embodiments may be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes computer program instructions that, when loaded and executed on a computer, fully or partially generate the process or functions described in FIG. 4 of the embodiment of the present invention.

[0310] The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line, or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., an SSD).

[0311] Obviously, those skilled in the art may make various changes and modifications to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include these modifications and variations.

Claims

1. A data transmission method, characterized in that: The method comprises: Generate multiple blocks according to the data to be sent; For any block among the multiple blocks, encrypt the block using a data key corresponding to the block, wherein different blocks correspond to different data keys, and the data key corresponding to any block is stored in a trusted execution environment (TEE); The data key corresponding to each of the multiple blocks is encrypted, and the encrypted multiple blocks and the encrypted data key corresponding to each block are transmitted to a data receiving device.

2. The method according to claim 1, wherein The encrypting the block by using the data key corresponding to the block includes: Obtaining the data key corresponding to the block from the TEE, and encrypting the block using the data key corresponding to the block; After the data key corresponding to each of the multiple blocks is encrypted, the data key corresponding to each of the multiple blocks is destroyed.

3. The method according to claim 2, wherein The obtaining the data key corresponding to the block from the TEE includes: The data key corresponding to the block is obtained from the TEE through a secure channel.

4. The method according to any one of claims 1 to 3, wherein: The multiple blocks cannot be derived from each other.

5. The method according to any one of claims 1 to 3, wherein: The encrypting of the data key corresponding to each block includes: Generate a transfer key in the TEE, and use the transfer key to encrypt the data key corresponding to each block; The circulation key is encrypted using the public key of the data receiving device, and the encrypted circulation key is transmitted to the data receiving device.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: The data access policy is encrypted and transmitted to the data receiving device. The data access policy describes the conditions that need to be followed for accessing the data.

7. The method according to claim 6, wherein The data access policy includes some or all of the following: The objects that are allowed to initiate data access operations, the time when access to the data is allowed, and the types of operations that are allowed to be performed on the data.

8. The method according to any one of claims 1 to 7, wherein: The step of generating a plurality of blocks according to the data to be sent includes: Splitting the data into a plurality of shards; The multiple fragments are reorganized to generate the multiple blocks.

9. A data transmission method, characterized in that: The method comprises: receiving, from a data transmitting device, a plurality of encrypted blocks and a data key corresponding to each encrypted block; Saving the encrypted multiple blocks; After decrypting the data key corresponding to each encrypted block, the data key corresponding to each block is saved in the TEE or the data key corresponding to each block is encrypted and saved in the TEE.

10. The method according to claim 9, wherein The method further comprises: When data access is required, the data key corresponding to each block is obtained from the TEE; Decrypting the stored encrypted multiple blocks using the data key corresponding to each block to obtain the data; Destroy the data key corresponding to each block.

11. The method according to claim 9 or 10, wherein: Decrypting the data key corresponding to each encrypted block includes: receiving the encrypted transfer key from the data sending device; decrypting the encrypted transfer key using the private key of the data receiving device; The data key corresponding to each encrypted block is decrypted using the transfer key.

12. The method according to any one of claims 9 to 11, wherein: The method further comprises: receiving an encrypted data access policy from the data sending device, wherein the data access policy describes conditions to be followed for accessing the data; After decrypting the encrypted data access policy, the data access policy is transmitted to the rights management program in the kernel state, and the rights management is used to determine whether the operation of accessing the data complies with the data access policy based on the data access policy.

13. A data sending device, characterized in that: The device comprises: A block module, used to generate multiple blocks according to the data to be sent; an encryption module, configured to encrypt any one of the multiple blocks using a data key corresponding to the block in the trusted execution environment (TEE), where different blocks have different data keys; and encrypt the data key corresponding to each block; The sending module is used to transmit the encrypted multiple blocks and the data key corresponding to each encrypted block to the data receiving device.

14. The device according to claim 13, wherein The encryption module is used to: Obtaining the data key corresponding to the block from the TEE, and encrypting the block using the data key corresponding to the block; After the data key corresponding to each of the multiple blocks is encrypted, the data key corresponding to each of the multiple blocks is destroyed.

15. The device according to any one of claims 13 to 14, characterized in that The multiple blocks cannot be derived from each other.

16. The device according to any one of claims 13 to 15, characterized in that: The encryption module is further configured to: encrypt a data access policy, wherein the data access policy describes conditions to be followed for accessing the data; The sending module is further configured to transmit the encrypted data access policy to the data receiving device.

17. A data receiving device, characterized in that: The device comprises: A receiving module, configured to receive a plurality of encrypted blocks and a data key corresponding to each encrypted block from a data sending device; A decryption module is used to save the encrypted multiple blocks; after decrypting the data key corresponding to each encrypted block, the data key corresponding to each block is saved in the TEE or the data key corresponding to each block is encrypted and saved in the TEE.

18. The device according to claim 17, wherein The receiving module is further configured to: receiving an encrypted data access policy from the data sending device, wherein the data access policy describes conditions to be followed for accessing the data; The decryption module is also used to: after decrypting the encrypted data access policy, transmit the data access policy to the permission management program in the kernel state, and the permission management is used to determine whether the operation of accessing the data complies with the data access policy based on the data access policy.

19. A computing device, characterized in that The computing device includes a processor and a memory; The memory is used to store computer program instructions; The processor executes and calls the computer program instructions in the memory to perform the method according to any one of claims 1 to 12.

20. A computer-readable storage medium, characterized in that When the computer-readable storage medium is executed by a computing device, the computing device executes the method according to any one of claims 1 to 12.

Images