CN106980794B - TrustZone-based file encryption and decryption method and device and terminal equipment - Google Patents
TrustZone-based file encryption and decryption method and device and terminal equipment Download PDFInfo
- Publication number
- CN106980794B CN106980794B CN201710214710.8A CN201710214710A CN106980794B CN 106980794 B CN106980794 B CN 106980794B CN 201710214710 A CN201710214710 A CN 201710214710A CN 106980794 B CN106980794 B CN 106980794B
- Authority
- CN
- China
- Prior art keywords
- file
- execution environment
- metadata
- trusted
- key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 71
- 238000004891 communication Methods 0.000 description 26
- 230000007246 mechanism Effects 0.000 description 18
- 238000010586 diagram Methods 0.000 description 11
- 230000006870 function Effects 0.000 description 9
- 230000008569 process Effects 0.000 description 9
- 238000013478 data encryption standard Methods 0.000 description 4
- 238000004590 computer program Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000003252 repetitive effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2107—File encryption
Abstract
The application discloses a TrustZone-based file encryption and decryption method, device and terminal equipment. The method comprises the following steps: receiving a metadata encryption request for a file, the metadata encryption request comprising: metadata and class key identification of the file, wherein the metadata comprises: a file key for encrypting the file; searching a class key corresponding to the stored class key identification; sending a data encryption request to a trusted application in the trusted execution environment through a client interface between the normal execution environment and the trusted execution environment, the data encryption request including: class keys and metadata; the trusted application program decrypts the class key according to the master key pre-stored in the trusted execution environment; the trusted application program encrypts the metadata according to the decrypted class key; and the trusted application program returns the encrypted metadata to the common execution environment for storage through the client interface. The method can improve the security of file encryption.
Description
Technical Field
The invention relates to the technical field of mobile terminal equipment safety, in particular to a TrustZone-based file encryption and decryption method, a TrustZone-based file encryption and decryption device and terminal equipment.
Background
At present, the following common file encryption schemes are available:
(1) file system based encryption schemes such as eCryptoFS;
(2) block device based encryption schemes such as dm-crypto;
(3) file-based encryption schemes such as various proprietary encryption schemes.
The various file encryption schemes adopt a mode of encrypting based on a local key system, so that a sufficiently safe key chain is the basis for ensuring the file encryption safety, and the protection of the key needs a system to provide a reliable trust root to construct a firm protection chain. Common secure hardware typically provides some hardware unique identification, or an unwriteable solidified root key, as the system's unique root of trust. All other keys within the system are derived or cryptographically protected, either directly or indirectly, from the root of trust.
The above information disclosed in this background section is only for enhancement of understanding of the background of the invention and therefore it may contain information that does not constitute prior art that is already known to a person of ordinary skill in the art.
Disclosure of Invention
The invention provides a TrustZone-based file encryption and decryption method, a TrustZone-based file encryption and decryption device and a terminal device, which can improve the security of file encryption.
Additional features and advantages of the invention will be set forth in the detailed description which follows, or may be learned by practice of the invention.
According to an aspect of the present invention, there is provided a TrustZone-based file encryption method, including: receiving a metadata encryption request for a file, the metadata encryption request comprising: metadata and class key identification of the file, wherein the metadata comprises: a file key for encrypting the file; searching a class key corresponding to the stored class key identification; sending a data encryption request to a trusted application in the trusted execution environment through a client interface between the normal execution environment and the trusted execution environment, the data encryption request including: class keys and metadata; the trusted application program decrypts the class key according to the master key pre-stored in the trusted execution environment; the trusted application program encrypts the metadata according to the decrypted class key; and the trusted application program returns the encrypted metadata to the common execution environment for storage through the client interface.
According to an embodiment of the present invention, the class key identifier corresponds to an application scenario; the application scene comprises the following steps: the terminal equipment can be accessed after being successfully started, the terminal equipment can be accessed after being successfully started and legally logged in and the user interface is unlocked, and the terminal equipment can be only written in when being successfully started and legally logged in and the user interface is locked.
According to an embodiment of the present invention, the method further includes: encrypting the file in the trusted execution environment according to the file key; receiving encrypted metadata; and merging the encrypted metadata and the encrypted file into one file for storage.
According to an embodiment of the present invention, encrypting a file in a trusted execution environment according to a file key includes: dividing a file into a plurality of data blocks; and independently encrypting the plurality of data blocks.
According to an embodiment of the present invention, the size of the data block is equal to the size of the operating system kernel memory page multiplied by the power of 2 to the nth power, where N is a positive integer greater than or equal to 2.
According to another aspect of the present invention, there is provided a TrustZone-based file decryption method suitable for use in any one of the above encryption methods, comprising: receiving a metadata decryption request for a file, the metadata decryption request comprising: metadata and a class key identifier of the file to be decrypted, wherein the metadata comprises: a file key for encrypting the file; searching a class key corresponding to the stored class key identification; sending a data decryption request to a trusted application program in the trusted execution environment through a client interface between the normal execution environment and the trusted execution environment, wherein the data decryption request comprises: class keys and metadata to be decrypted; the trusted application program decrypts the class key according to the master key pre-stored in the trusted execution environment; the trusted application program decrypts the metadata according to the decrypted class key; and the trusted application program returns the decrypted metadata to the common execution environment through the client interface.
According to an embodiment of the present invention, the method further includes: receiving an operation request for a file sent by a client application program in a common execution environment; and sending a metadata decryption request of the file according to the operation request.
According to an embodiment of the present invention, the method further includes: decrypting the file in the trusted execution environment according to the file key in the decrypted metadata; and
the decrypted file is returned to the client application.
According to an embodiment of the present invention, decrypting the file in the trusted execution environment according to the file key in the decrypted metadata includes: a plurality of encrypted data blocks divided from a file are independently decrypted.
According to still another aspect of the present invention, there is provided a TrustZone-based file encryption apparatus, including: an encryption request receiving module, configured to receive a metadata encryption request for a file, where the metadata encryption request includes: metadata and class key identification of the file, wherein the metadata comprises: a file key for encrypting the file; the first type key acquisition module is used for searching a class key corresponding to the stored class key identifier; an encryption request module, configured to send a data encryption request to a trusted application in a trusted execution environment through a client interface between a normal execution environment and the trusted execution environment, where the data encryption request includes: class keys and metadata; the first type key decryption module is used for decrypting the type key according to a master key which is stored in a trusted execution environment in advance through a trusted application program; the encryption execution module is used for encrypting the metadata according to the decrypted class key through the trusted application program; and the encrypted data returning module is used for returning the encrypted metadata to the common execution environment for storage through the client interface by the trusted application program.
According to an embodiment of the present invention, the class key identifier corresponds to an application scenario; the application scene comprises the following steps: the terminal equipment can be accessed after being successfully started, the terminal equipment can be accessed after being successfully started and legally logged in and the user interface is unlocked, and the terminal equipment can be only written in when being successfully started and legally logged in and the user interface is locked.
According to an embodiment of the present invention, the apparatus further includes: the file encryption module is used for encrypting the file in the trusted execution environment according to the file key; the metadata receiving module is used for receiving the encrypted metadata; and the merging storage module is used for merging the encrypted metadata and the encrypted file into one file for storage.
According to an embodiment of the present invention, a file encryption module includes: the data block dividing submodule is used for dividing the file into a plurality of data blocks; and the database encryption submodule is used for independently encrypting the data blocks.
According to an embodiment of the present invention, the size of the data block is equal to the size of the operating system kernel memory page multiplied by the power of 2 to the nth power, where N is a positive integer greater than or equal to 2.
According to still another aspect of the present invention, there is provided a TrustZone-based file decrypting apparatus adapted to the encrypting apparatus according to any one of the above, comprising: a decryption request receiving module, configured to receive a metadata decryption request for a file, where the metadata decryption request includes: metadata and a class key identifier of the file to be decrypted, wherein the metadata comprises: a file key for encrypting the file; the second type key obtaining module is used for searching a class key corresponding to the stored class key identification; a decryption request module, configured to send a data decryption request to a trusted application in a trusted execution environment through a client interface between a common execution environment and the trusted execution environment, where the data decryption request includes: class keys and metadata to be decrypted; the second type key decryption module is used for decrypting the type key according to the main key which is stored in the trusted execution environment in advance through the trusted application program; the decryption execution module is used for decrypting the metadata according to the decrypted class key through the trusted application program; and the decrypted data returning module is used for returning the decrypted metadata to the common execution environment through the client interface by the trusted application program.
According to an embodiment of the present invention, the apparatus further includes: an operation request receiving module, configured to receive an operation request for a file sent by a client application in a common execution environment; and the decryption request sending module is used for sending the metadata decryption request of the file according to the operation request.
According to an embodiment of the present invention, the apparatus further includes: the file decryption module is used for decrypting the file in the trusted execution environment according to the file key in the decrypted metadata; and a decrypted file returning module for returning the decrypted file to the client application program.
According to an embodiment of the present invention, the file decryption module includes: and the data block decryption submodule is used for independently decrypting a plurality of encrypted data blocks divided according to the file.
According to still another aspect of the present invention, there is provided a terminal device including: a processor; and a memory for storing executable instructions for the processor; wherein the processor is configured to perform the method of any one of the above via execution of the executable instructions.
According to still another aspect of the present invention, there is provided a terminal device including: a processor; and a memory for storing executable instructions for the processor; wherein the processor is configured to perform the method of any one of the above via execution of the executable instructions.
According to the TrustZone-based file encryption method, the metadata containing the file key is encrypted in the trusted execution environment, and the ciphertext of the file key is stored in the common execution environment, so that the safe storage and use of the file key for encrypting the file are ensured.
In addition, according to some embodiments, the TrustZone-based file encryption method according to the embodiments of the present invention further enhances the security of file encryption by encrypting the file key in the trusted execution environment. In addition, the security of the file is further enhanced by carrying out encryption operation in a trusted execution environment by taking a single file as a logic encryption unit.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
Drawings
The above and other objects, features and advantages of the present invention will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings.
Fig. 1 is an architectural diagram illustrating a generic execution environment and trusted execution in a terminal device according to an example.
Fig. 2 is a flowchart illustrating a TrustZone-based file encryption method according to an exemplary embodiment.
Fig. 3 is a flowchart illustrating another TrustZone-based file encryption method according to an exemplary embodiment.
Fig. 4 is an architecture diagram illustrating a general execution environment and trusted execution in another terminal device according to an example.
Fig. 5 is a flowchart illustrating a TrustZone-based file decryption method according to an exemplary embodiment.
Fig. 6 is a flowchart illustrating another TrustZone-based file decryption method according to an exemplary embodiment.
Fig. 7 is a block diagram illustrating a TrustZone-based file encryption apparatus according to an exemplary embodiment.
Fig. 8 is a block diagram illustrating a TrustZone-based file decryption apparatus according to an exemplary embodiment.
Fig. 9 is an architecture diagram illustrating a generic execution environment and trusted execution in yet another terminal device according to an example.
Detailed Description
Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The drawings are merely schematic illustrations of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus their repetitive description will be omitted.
Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known structures, methods, devices, implementations, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
TrustZone technology is a Trusted Execution Environment (TEE) standard on the ARM platform that provides the ability to execute portions of code securely in a Trusted execution environment through access isolation of hardware and cooperation of secure kernel software. The trusted Execution Environment constructed based on the TrustZone hardware isolation technology divides the application programs related to sensitive data into a Client application program (Client APP) and a trusted application program (trusted APP, TA), the Client application program is executed in a normal Execution Environment (REE) for processing most of non-sensitive services, i.e. a normal operating System (Rich OS) of the mobile terminal device, and the trusted application program is executed in the trusted Execution Environment for processing sensitive services. The normal execution environment and the trusted execution environment are isolated from each other, and a Client application program running in the normal execution environment accesses (access) the trusted application program running in the trusted execution environment through a Client interface (TrustZone Client API), or exchanges data with the trusted application program through the Client interface.
Fig. 1 is an architectural diagram illustrating a generic execution environment and trusted execution in a terminal device according to an example. Fig. 2 is a flowchart illustrating a TrustZone-based file encryption method according to an exemplary embodiment. With reference to fig. 1 and 2, the method 10 shown in fig. 2 includes:
in step S102, a metadata encryption request for a file is received.
The metadata encryption request includes: metadata of the file and a class key Identification (ID). The metadata includes: a file key for encrypting the file.
For example, a file key encryption request sent by the file encryption implementation service is received by the encryption/decryption storage service in fig. 1. The file encryption implementation service sends the file key encryption request to the encryption and decryption storage service, and the request encryption and decryption storage service encrypts the metadata containing the file key used for encrypting the data file in fig. 1.
The encryption and decryption storage service and the file encryption implementation service can be implemented as a code set consisting of at least one function, and each function comprises: function name, function call information, and some or all of the function implementations. When there are multiple functions, a function implementation may also include calling other defined functions, etc.
The file key encryption request is sent, for example, by Inter-Process Communication (IPC), such as Dbus, a folder Inter-Process Communication mechanism, or the like.
The file key encryption request carries the metadata and the class key identifier in a parameter form.
In step S104, the stored class key is searched for to identify the corresponding class key.
For example, the stored class key is looked up by the encryption and decryption storage service to identify the corresponding class key. In the encryption and decryption storage service, class keys corresponding to various key identifications are stored, wherein the various keys are ciphertexts encrypted by using a master key in a trusted execution environment.
In some embodiments, the class key identification corresponds to an application scenario of an application program that invokes the database file. Application scenarios include, for example:
1) after the terminal equipment is successfully started, the following access can be carried out: this scenario is typically used for the requirements of system-resident services for encryption;
2) after the terminal equipment is successfully started and legally logged in, the terminal equipment can access: this scenario is typically used for the encryption requirements of system services and system applications;
3) the terminal equipment is successfully started, legally logs in and can access after the user interface is unlocked: this scenario is typically used for the encryption requirements of common client applications; alternatively, the first and second electrodes may be,
4) the terminal equipment can only write in when successfully started and legally logged in and the user interface is locked: this scenario is generally used for the encryption requirements of resident applications, such as short messages, emails, Instant Messaging (IM), and the like, and data needs to be written to the system securely with the user interface locked.
Because the security policies of the application program under different application scenarios are different, the application scenario selects the application scenario to determine the corresponding class key at each time, and the differentiated application scenario can improve the security of the application data. For example, if the policy of an encrypted item is set to that the terminal device successfully starts and legally logs in and the user interface can access after being unlocked, access requests at other times are rejected, and the corresponding class key is also cleared from the memory, so that the encryption security is further improved.
The key is a main attack point of the black box encryption algorithm, so that the security of the key in storage and use needs to be guaranteed. The storage security mainly refers to that an attacker cannot perform read-write access on the key, and the used security mainly refers to the possibility that the key is subjected to dynamic attack in the memory. In the method, in order to enhance the security of the key, the class key stored in the common execution environment is stored in a ciphertext form.
In some embodiments, the encryption and decryption storage service also needs to confirm to the trusted application through the client interface whether the master key is available during initialization.
In some embodiments, the method 10 may further include the following step before step S104:
in step 1, the encryption and decryption storage service sends a class key corresponding to each application scenario to the trusted application program through the client interface.
In step 2, the trusted application encrypts the class key of each application scenario according to the master key in the TrustZone context.
In step 3, the trusted application program returns the class key corresponding to each encrypted application scenario to the encryption and decryption storage service in the common execution environment for storage through the client interface.
In step S106, a data encryption request is sent to the trusted application in the trusted execution environment through the client interface between the normal execution environment and the trusted execution environment.
The data encryption request includes: class keys and metadata.
For example, a data encryption request is sent by the cryptographic storage service to a trusted application in the trusted execution environment, the data encryption request including: the class key and metadata found in step S102.
As shown in fig. 1, in a specific implementation, the encryption/decryption storage service may implement, through a TrustZone client interface, a call between the encryption storage service and a trusted application that is specifically served for key encryption/decryption, that is, a communication service between the encryption storage service and the trusted application, by using communication mechanisms in a common execution environment and a trusted execution environment in a kernel space. It should be noted that the communication mechanisms in the normal execution environment and the trusted execution environment in the kernel space are known to those skilled in the art and will not be described herein.
In some embodiments, the client interface employs a Mandatory Access Control (MAC) rights management mechanism, such as a SELinux access control mechanism.
SELinux is a suite of Label-based security systems. In the SELinux strategy, the subject controls the object by setting the tag. The subject may be each process running in the terminal device, and the object is all resources in the system, including: file system, directory, file start indicator, port, message interface, network interface, and the like. Each process has its own tag, and each object has its own tag. The process tag is controlled to access the object tag through the written SELinux strategy, such as file access, read-write, SOCKET operation and the like. For example, through policy configuration, the process labeled a is allowed to call the client interface labeled B, thereby ensuring that the interface of the encrypted storage service is not abused arbitrarily.
In step S108, the trusted application decrypts the class key according to the master key pre-stored in the trusted execution environment.
The master key is owned independently by each terminal device and is loaded into the image file of the TrustZone, i.e. into the context of the TrustZone's trusted execution environment, during the initialization of the executable environment. Since the master key is pre-buried in the trusted execution environment and cannot appear in the ordinary execution environment, the class key cannot be decrypted in the ordinary execution environment because the master key cannot be acquired, so that the security of the application data encrypted by the class key is enhanced.
In step S110, the trusted application encrypts the metadata according to the decrypted class key.
The trusted application may use a symmetric Encryption algorithm such as AES (Advanced Encryption Standard) or DES (Data Encryption Standard), for example, to encrypt the metadata according to the decrypted class key, which is not limited in the present invention. Available encryption modes include: CBC (Cipher blocking chaining), OFB (Output Feedback), CFB (Cipher Feedback).
As shown in fig. 1, the trusted application may perform the above-described data encryption operation by calling a hardware encryption engine that is commonly used in the trusted execution environment.
In step S112, the trusted application returns the encrypted metadata to the normal execution environment through the client interface for storage.
And after the trusted application program completes encryption, returning the encrypted metadata to the common execution environment through the client interface.
According to the TrustZone-based file encryption method, the metadata containing the file key is encrypted in the trusted execution environment, and the ciphertext of the file key is stored in the common execution environment, so that the safe storage and use of the file key for encrypting the file are ensured.
It should be clearly understood that the present disclosure describes how to make and use particular examples, but the principles of the present disclosure are not limited to any details of these examples. Rather, these principles can be applied to many other embodiments based on the teachings of the present disclosure.
Fig. 3 is a flowchart illustrating another TrustZone-based file encryption method according to an exemplary embodiment. The method 20 shown in fig. 3 includes:
in step S202, the file is encrypted in the trusted execution environment according to the file key.
For example, as shown in FIG. 1, a file encryption implementation service may implement encryption of a file by a trusted application in a trusted execution environment.
The access interface of the file encryption implementation service to the data file is designed to be as close as possible to a general high-level file access interface (different from the underlying file interface of a Linux or Windows system), and basically the details of encryption are transparent to the user except for the specified file password or the parameters of the encryption class.
The file encryption implementation service sends the file to be encrypted to the trusted application program, and the trusted application program encrypts the file. In specific implementation, the file encryption implementation service may implement the call between the file encryption implementation service and the trusted application program, that is, the communication service between the file encryption implementation service and the trusted application program, through the TrustZone client interface and by using a communication mechanism in the common execution environment and the trusted execution environment in the kernel space. It should be noted that the communication mechanisms in the normal execution environment and the trusted execution environment in the kernel space are known to those skilled in the art and will not be described herein.
The trusted application program encrypts the file by taking a single file as a logic encryption unit to perform overall encryption, instead of encrypting a general universal data block and a data stream in any type, the encryption is not common file encryption based on a file system or a block device.
The trusted application may use a symmetric Encryption algorithm such as AES (Advanced Encryption Standard) or DES (Data Encryption Standard), for example, to encrypt the file according to the file key, which is not limited in the present invention.
As shown in fig. 1, the trusted application may perform the above-described data encryption operation by calling a hardware encryption engine that is commonly used in the trusted execution environment.
In some embodiments, to balance system performance and security, the trusted application may divide the file into multiple data blocks and encrypt the multiple data blocks independently. There is no correlation between the data blocks, so the trusted application can implement parallel encryption operation on a plurality of data blocks. The size of the data block can be adjusted as required, for example, the size of the kernel memory page of the operating system of the mobile terminal device can be multiplied by the power of N of 2, where N is a positive integer greater than or equal to 2. For example, for a 32-bit operating system, the memory page size is 4KB, then the data block size may be 16KB, 64KB, 256KB, etc.; for a 64-bit operating system, the memory page size is 64KB, and the data block size can be 128KB, 256KB, 1024KB, etc. The data block size depends on the choice of platform resources, configuration and encryption algorithm. Generally speaking, the larger the block, the faster the serial access speed, such as a copy file operation; the smaller the partitions, the better the random access performance, e.g., random read and write operations.
Fig. 4 is an architecture diagram illustrating a general execution environment and trusted execution in another terminal device according to an example. In some embodiments, as shown in FIG. 4, the file encryption implementation service may also encrypt the file through a second trusted application in the trusted execution environment. The file encryption implementation service sends the file to be encrypted and the plaintext of the file key to the second trusted application program, and the second trusted application program encrypts the file. In specific implementation, the file encryption implementation service may implement the call between the file encryption implementation service and the second trusted application program, that is, the communication service between the file encryption implementation service and the second trusted application program, through the TrustZone client interface and by using a communication mechanism in the common execution environment and the trusted execution environment in the kernel space. Whereas the first trusted application in figure 4 is used to implement the encryption operation on the metadata in method 10. It should be noted that the communication mechanisms in the normal execution environment and the trusted execution environment in the kernel space are known to those skilled in the art and will not be described herein. Furthermore, to strike a balance between system performance and security, the second trusted application may divide the file into a plurality of data blocks and encrypt the plurality of data blocks independently. The specific data block division description is the same as above, and is not described herein again.
Fig. 9 is an architecture diagram illustrating a generic execution environment and trusted execution in yet another terminal device according to an example. In some embodiments, as shown in FIG. 9, the encryption implementation service encrypts the file through a generic hardware encryption engine in the trusted execution environment. The file encryption implementation service sends the file to be encrypted and the plaintext of the file key to a hardware encryption engine in the trusted execution environment, and the hardware encryption engine encrypts the file. In specific implementation, the file encryption implementation service may implement the call between the file encryption implementation service and the hardware encryption engine through the TrustZone client interface and by using a communication mechanism in the common execution environment and the trusted execution environment in the kernel space, that is, the communication service between the file encryption implementation service and the hardware encryption engine. It should be noted that the communication mechanisms in the normal execution environment and the trusted execution environment in the kernel space are known to those skilled in the art and will not be described herein. In addition, to strike a balance between system performance and security, the file encryption implementation service may divide the file into a plurality of data blocks and request the hardware encryption engine to independently encrypt the plurality of data blocks. The specific data block division description is the same as above, and is not described herein again.
In step S204, the encrypted metadata is received.
For example, the metadata encrypted by method 10 is received by the file encryption implementation service in fig. 1.
In step S206, the encrypted metadata and the encrypted file are merged into one file for storage.
The encrypted metadata is integrated with the encrypted file, so that the encrypted file can be freely copied and moved.
According to the TrustZone-based file encryption method, the file key is encrypted in the trusted execution environment, so that the security of file encryption is further enhanced. In addition, the security of the file is further enhanced by carrying out encryption operation in a trusted execution environment by taking a single file as a logic encryption unit.
Fig. 5 is a flowchart illustrating a TrustZone-based file decryption method according to an exemplary embodiment. The decryption method is applicable to the file encryption methods 10 and 20 described above. Referring to fig. 1, the method 30 shown in fig. 5 includes:
in step S302, a metadata decryption request for a file is received.
For example, a metadata decryption request sent by the file encryption implementation service is received by the encryption/decryption storage service shown in fig. 1.
The metadata decryption request is, for example, a password creation call sent through interprocess communication, such as Dbus, a binary interprocess communication mechanism, or the like.
The metadata decryption request carries metadata to be decrypted and a class key identifier of the file in a parameter form, for example, and the metadata includes: a file key for encrypting the file.
In step S304, the stored class key is searched for a class key corresponding to the class key identifier.
For example, the stored class key is looked up by the encryption and decryption storage service to identify the corresponding class key. In the encryption and decryption storage service, class keys corresponding to various key identifications are stored, wherein the various keys are ciphertexts encrypted by using a master key in a trusted execution environment.
In some embodiments, the class key identification corresponds to an application scenario of an application program that invokes the database file. The types of the application scenarios are the same as above, and are not described herein again.
The key is a main attack point of the black box encryption algorithm, so that the security of the key in storage and use needs to be guaranteed. The storage security mainly refers to that an attacker cannot perform read-write access on the key, and the used security mainly refers to the possibility that the key is subjected to dynamic attack in the memory. In the method, in order to enhance the security of the key, the class key stored in the common execution environment is stored in a ciphertext form.
In step S306, a data decryption request is sent to the trusted application in the trusted execution environment through the client interface between the normal execution environment and the trusted execution environment.
For example, a data encryption request is sent by the cryptographic storage service to a trusted application in the trusted execution environment, the data encryption request including: the class key found in step S304 and the metadata to be decrypted.
As shown in fig. 1, in a specific implementation, the encryption/decryption storage service may implement a call between the encryption storage service and a trusted application exclusively serving for encryption/decryption, that is, a communication service between the encryption storage service and a trusted application exclusively serving for encryption/decryption, through a TrustZone client interface and by using communication mechanisms in a common execution environment and a trusted execution environment in a kernel space. It should be noted that the communication mechanisms in the normal execution environment and the trusted execution environment in the kernel space are known to those skilled in the art and will not be described herein.
In step S308, the trusted application decrypts the class key according to the master key pre-stored in the trusted execution environment.
The master key is owned independently by each terminal device and is loaded into the image file of the TrustZone, i.e. into the context of the TrustZone's trusted execution environment, during the initialization of the executable environment. Since the master key is pre-buried in the trusted execution environment and cannot appear in the ordinary execution environment, the class key cannot be decrypted in the ordinary execution environment because the master key cannot be acquired, so that the security of the application data encrypted by the class key is enhanced.
In step S310, the trusted application decrypts the metadata to be decrypted according to the decrypted class key.
And carrying out decryption operation on the data to be decrypted corresponding to the encryption algorithm used in the encryption process.
In step S312, the trusted application returns the decrypted metadata to the encryption/decryption storage service through the client interface.
And after the trusted application program finishes decryption, the decrypted metadata is returned to the common execution environment through the client interface.
Fig. 6 is a flowchart illustrating another TrustZone-based file decryption method according to an exemplary embodiment. As shown in fig. 6, the method 40 includes:
in step S402, an operation request for a file sent by a client application in the normal execution environment is received.
For example, as shown in FIG. 1, when a client application needs to open the file, the operation request is sent to a file encryption implementation service.
It should be noted that, in the implementation, the file encryption implementation service may be implemented inside each application, i.e., each call to the service. Or may be an independent service, and each application realizes the call to the service through mechanisms such as interprocess communication.
In step S404, a metadata decryption request for the file is transmitted according to the operation request.
Thereby performing the decryption operation on the metadata in method 30.
In some embodiments, the method 40 further comprises:
in step S406, the file is decrypted in the trusted execution environment according to the file key in the decrypted metadata.
For example, as shown in FIG. 1, a file encryption implementation service may implement decryption of a file by a trusted application in a trusted execution environment.
The file encryption implementation service sends the file to be decrypted to the trusted application program, and the trusted application program decrypts the file. In specific implementation, the file encryption implementation service may implement the call between the file encryption implementation service and the trusted application program, that is, the communication service between the file encryption implementation service and the trusted application program, through the TrustZone client interface and by using a communication mechanism in the common execution environment and the trusted execution environment in the kernel space.
As shown in fig. 1, the trusted application may perform the above-described data decryption operation by calling a hardware encryption engine that is commonly used in the trusted execution environment.
In some embodiments, when the file to be decrypted is composed of a plurality of encrypted data blocks, the first trusted application independently decrypts the plurality of encrypted data blocks in accordance with the file key.
In some embodiments, as shown in FIG. 4, the file encryption implementation service may also decrypt the file through a second trusted application in the trusted execution environment. The file encryption implementation service sends the file to be decrypted and the plaintext of the file key to the second trusted application program, and the second trusted application program encrypts the file. In specific implementation, the file encryption implementation service may implement the call between the file encryption implementation service and the second trusted application program, that is, the communication service between the file encryption implementation service and the second trusted application program, through the TrustZone client interface and by using a communication mechanism in the common execution environment and the trusted execution environment in the kernel space.
In some embodiments, as shown in FIG. 9, the encryption implementation service decrypts files through a generic hardware encryption engine in the trusted execution environment. The file encryption implementation service sends the file to be decrypted and the plaintext of the file key to a hardware encryption engine in the trusted execution environment, and the hardware encryption engine encrypts the file. In specific implementation, the file encryption implementation service may implement the call between the file encryption implementation service and the hardware encryption engine through the TrustZone client interface and by using a communication mechanism in the common execution environment and the trusted execution environment in the kernel space, that is, the communication service between the file encryption implementation service and the hardware encryption engine.
In step S408, the decrypted file is returned to the client application.
Those skilled in the art will appreciate that all or part of the steps implementing the above embodiments are implemented as computer programs executed by a CPU. The computer program, when executed by the CPU, performs the functions defined by the method provided by the present invention. The program may be stored in a computer readable storage medium, which may be a read-only memory, a magnetic or optical disk, or the like.
Furthermore, it should be noted that the above-mentioned figures are only schematic illustrations of the processes involved in the method according to exemplary embodiments of the invention, and are not intended to be limiting. It will be readily understood that the processes shown in the above figures are not intended to indicate or limit the chronological order of the processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, e.g., in multiple modules.
The following are embodiments of the apparatus of the present invention that may be used to perform embodiments of the method of the present invention. For details which are not disclosed in the embodiments of the apparatus of the present invention, reference is made to the embodiments of the method of the present invention.
Fig. 7 is a block diagram illustrating a TrustZone-based file encryption apparatus according to an exemplary embodiment. As shown in fig. 7, the apparatus 50 includes: an encryption request receiving module 502, a first-type key obtaining module 504, an encryption request module 506, a first-type key decryption module 508, an encryption execution module 510, and an encrypted data returning module 512.
The encryption request receiving module 502 is configured to receive a metadata encryption request of a file, where the metadata encryption request includes: metadata and class key identification of the file, wherein the metadata comprises: a file key for encrypting the file.
The first class key obtaining module 504 is configured to search for a class key corresponding to the stored class key identifier.
In some embodiments, the class key identification corresponds to an application scenario; the application scene comprises the following steps: the terminal equipment can be accessed after being successfully started, the terminal equipment can be accessed after being successfully started and legally logged in and the user interface is unlocked, and the terminal equipment can be only written in when being successfully started and legally logged in and the user interface is locked.
The encryption request module 506 is configured to send a data encryption request to a trusted application in the trusted execution environment through a client interface between the normal execution environment and the trusted execution environment, where the data encryption request includes: class keys and metadata.
The first type key decryption module 508 is configured to decrypt, by the trusted application, the type key according to a master key pre-stored in the trusted execution environment.
The encryption execution module 510 is configured to encrypt the metadata according to the decrypted class key by the trusted application.
The encrypted data returning module 512 is configured to return the encrypted metadata to the normal execution environment through the client interface by the trusted application.
In some embodiments, the apparatus 50 further comprises: a file encryption module 514, a metadata receiving module 516, and a merge storage module 518. The file encryption module 514 is configured to encrypt a file in the trusted execution environment according to the file key. The metadata receiving module 516 is used for receiving the encrypted metadata. The merge storage module 518 is configured to merge the encrypted metadata and the encrypted file into one file for storage.
In some embodiments, the file encryption module 514 includes: a data block dividing sub-module 5142 and a database encryption sub-module 5144. The data block dividing sub-module 5142 is configured to divide the file into a plurality of data blocks. The database encryption sub-module 5144 is used to independently encrypt a plurality of data blocks.
According to the TrustZone-based file encryption method, the metadata containing the file key is encrypted in the trusted execution environment, and the ciphertext of the file key is stored in the common execution environment, so that the safe storage and use of the file key for encrypting the file are ensured.
Fig. 8 is a block diagram illustrating a TrustZone-based file decryption apparatus according to an exemplary embodiment. The decryption means is adapted to the encryption means 50 described above. As shown in fig. 8, the decryption apparatus 60 includes: a decryption request receiving module 602, a second-type key obtaining module 604, a decryption request module 606, a second-type key decryption module 608, a decryption execution module 610 and a decrypted data returning module 612.
The decryption request receiving module 602 is configured to receive a metadata decryption request of a file, where the metadata decryption request includes: metadata and a class key identifier of the file to be decrypted, wherein the metadata comprises: a file key for encrypting the file.
The second-class key obtaining module 604 is configured to search for a class key corresponding to the stored class key identifier.
The decryption request module 606 is configured to send a data decryption request to a trusted application in the trusted execution environment through a client interface between the normal execution environment and the trusted execution environment, where the data decryption request includes: class keys and metadata to be decrypted.
The second type key decryption module 608 is configured to decrypt the type key according to the master key pre-stored in the trusted execution environment by the trusted application.
The decryption execution module 610 is configured to decrypt, by the trusted application, the metadata according to the decrypted class key.
The decrypted data returning module 612 is configured to return the decrypted metadata to the normal execution environment through the client interface by using the trusted application.
In some embodiments, the apparatus 60 further comprises: an operation request receiving module 614 and a decryption request sending module 616. The operation request receiving module 614 is configured to receive an operation request for a file sent by a client application in the normal execution environment. The decryption request sending module 616 is configured to send a metadata decryption request of the file according to the operation request.
In some embodiments, the apparatus 60 further comprises: a file decryption module 618 and a decrypted file return module 620. The file decryption module 618 is configured to decrypt the file in the trusted execution environment according to the file key in the decrypted metadata. Decrypted file return module 620 is used to return the decrypted file to the client application.
In some embodiments, the file decryption module 618 includes: the data block decryption submodule 6182 is configured to decrypt the plurality of encrypted data blocks partitioned according to the file independently.
It is noted that the block diagrams shown in the above figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.
Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiment of the present invention can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to make a computing device (which can be a personal computer, a server, a mobile terminal, or a network device, etc.) execute the method according to the embodiment of the present invention.
Exemplary embodiments of the present invention are specifically illustrated and described above. It is to be understood that the invention is not limited to the precise construction, arrangements, or instrumentalities described herein; on the contrary, the invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.
Claims (13)
1. A file encryption method based on TrustZone is applied to terminal equipment, the terminal equipment comprises a common execution environment and a trusted execution environment, and is characterized by comprising the following steps:
in the normal execution environment, receiving a metadata encryption request for a file, the metadata encryption request comprising: metadata and a class key identifier of the file, wherein the metadata comprises: a file key for encrypting the file;
searching a class key corresponding to the stored class key identification in the common execution environment;
sending a data encryption request to a trusted application in the trusted execution environment through a client interface between the normal execution environment and the trusted execution environment, the data encryption request comprising: the class key and the metadata;
in the trusted execution environment, the trusted application program decrypts the class key according to a master key pre-stored in the trusted execution environment;
in the trusted execution environment, the trusted application program encrypts the metadata according to the decrypted class key; and
the trusted application program returns the encrypted metadata to the common execution environment through the client interface for storage;
wherein the class key identification corresponds to an application scenario.
2. The method of claim 1, wherein the application scenario comprises: the terminal equipment can be accessed after being successfully started, the terminal equipment can be accessed after being successfully started and legally logged in and the user interface is unlocked, and the terminal equipment can be only written in when being successfully started and legally logged in and the user interface is locked.
3. The method of claim 2, further comprising:
encrypting the file in the trusted execution environment according to the file key;
receiving the encrypted metadata; and
and merging the encrypted metadata and the encrypted file into a file for storage.
4. The method of claim 3, wherein encrypting the file in the trusted execution environment according to the file key comprises:
dividing the file into a plurality of data blocks; and
independently encrypting the plurality of data blocks.
5. The method of claim 4, wherein the size of the data block is equal to the size of an operating system kernel memory page multiplied by a power of 2 to the Nth power, where N is a positive integer greater than or equal to 2.
6. A TrustZone-based file decryption method applicable to the encryption method according to any one of claims 1 to 5, applied to a terminal device, the terminal device comprising a normal execution environment and a trusted execution environment, comprising:
receiving a metadata decryption request for a file, the metadata decryption request comprising: the metadata and the class key identification of the file to be decrypted comprise: a file key for encrypting the file;
searching a class key corresponding to the stored class key identification;
sending a data decryption request to a trusted application in the trusted execution environment through a client interface between the normal execution environment and the trusted execution environment, the data decryption request comprising: the class key and the metadata to be decrypted;
the trusted application program decrypts the class key according to a master key pre-stored in the trusted execution environment;
the trusted application program decrypts the metadata according to the decrypted class key; and
and the trusted application program returns the decrypted metadata to the common execution environment through the client interface.
7. The method of claim 6, further comprising:
receiving an operation request for the file sent by a client application program in the common execution environment; and
and sending the metadata decryption request of the file according to the operation request.
8. The method of claim 7, further comprising:
decrypting the file in the trusted execution environment according to the decrypted file key in the metadata; and
and returning the decrypted file to the client application program.
9. The method of claim 8, wherein decrypting the file in the trusted execution environment based on a file key in the decrypted metadata comprises:
a plurality of encrypted data blocks divided from the file are independently decrypted.
10. A file encryption device based on TrustZone is applied to terminal equipment, the terminal equipment comprises a common execution environment and a trusted execution environment, and is characterized by comprising the following components:
an encryption request receiving module, configured to receive a metadata encryption request for a file in the common execution environment, where the metadata encryption request includes: metadata and a class key identifier of the file, wherein the metadata comprises: a file key for encrypting the file;
the first class key acquisition module is used for searching a class key corresponding to the stored class key identifier in the common execution environment;
an encryption request module, configured to send a data encryption request to a trusted application in the trusted execution environment through a client interface between the normal execution environment and the trusted execution environment, where the data encryption request includes: the class key and the metadata;
the first-class key decryption module is used for decrypting the class key in the trusted execution environment through the trusted application program according to a master key pre-stored in the trusted execution environment;
the encryption execution module is used for encrypting the metadata in the trusted execution environment through the trusted application program according to the decrypted class key; and
the encrypted data returning module is used for returning the encrypted metadata to the common execution environment for storage through the client interface by the trusted application program;
wherein the class key identification corresponds to an application scenario.
11. A TrustZone-based file decrypting apparatus suitable for the encrypting apparatus according to claim 10, applied to a terminal device, the terminal device including a normal execution environment and a trusted execution environment, comprising:
a decryption request receiving module, configured to receive a metadata decryption request for a file, where the metadata decryption request includes: the metadata and the class key identification of the file to be decrypted comprise: a file key for encrypting the file;
the second type key obtaining module is used for searching a stored class key corresponding to the class key identifier;
a decryption request module, configured to send a data decryption request to a trusted application in the trusted execution environment through a client interface between the normal execution environment and the trusted execution environment, where the data decryption request includes: the class key and the metadata to be decrypted;
the second type key decryption module is used for decrypting the type key according to a main key pre-stored in the trusted execution environment by the trusted application program;
the decryption execution module is used for decrypting the metadata according to the decrypted class key through the trusted application program; and
and the decrypted data returning module is used for returning the decrypted metadata to the common execution environment through the client interface by the trusted application program.
12. A terminal device, comprising:
a processor; and
a memory for storing executable instructions of the processor;
wherein the processor is configured to perform the method of any of claims 1-5 via execution of the executable instructions.
13. A terminal device, comprising:
a processor; and
a memory for storing executable instructions of the processor;
wherein the processor is configured to perform the method of any of claims 6-9 via execution of the executable instructions.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710214710.8A CN106980794B (en) | 2017-04-01 | 2017-04-01 | TrustZone-based file encryption and decryption method and device and terminal equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710214710.8A CN106980794B (en) | 2017-04-01 | 2017-04-01 | TrustZone-based file encryption and decryption method and device and terminal equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106980794A CN106980794A (en) | 2017-07-25 |
| CN106980794B true CN106980794B (en) | 2020-03-17 |
Family
ID=59344433
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710214710.8A Active CN106980794B (en) | 2017-04-01 | 2017-04-01 | TrustZone-based file encryption and decryption method and device and terminal equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106980794B (en) |
Families Citing this family (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107609412A (en) * | 2017-09-19 | 2018-01-19 | 山东大学 | A kind of method for realizing that mobile terminal safety stores under mobile Internet based on TrustZone technologies |
| CN109905233B (en) * | 2017-12-08 | 2022-07-29 | 阿里巴巴集团控股有限公司 | Equipment data processing method and system |
| CN110324138B (en) * | 2018-03-29 | 2022-05-24 | 阿里巴巴集团控股有限公司 | Data encryption and decryption method and device |
| CN111566989B (en) * | 2018-06-14 | 2022-06-07 | 华为技术有限公司 | Key processing method and device |
| CN111899102A (en) | 2018-11-30 | 2020-11-06 | 创新先进技术有限公司 | Method for realizing privacy protection in block chain |
| CN109684126B (en) * | 2018-12-25 | 2022-05-03 | 贵州华芯通半导体技术有限公司 | Memory verification method for ARM equipment and ARM equipment for executing memory verification |
| CN111400726B (en) * | 2019-01-03 | 2024-04-09 | 斑马智行网络(香港)有限公司 | Data processing method, device, equipment and machine-readable medium |
| CN110443078B (en) * | 2019-07-19 | 2021-05-28 | 南京芯驰半导体科技有限公司 | Security storage system based on privilege hierarchy |
| CN110543764B (en) * | 2019-09-11 | 2021-07-23 | 飞腾信息技术有限公司 | System-on-chip memory protection method, password acceleration engine and memory protection device |
| CN112596802B (en) * | 2019-09-17 | 2022-07-12 | 华为技术有限公司 | Information processing method and device |
| CN111310213A (en) * | 2020-02-20 | 2020-06-19 | 苏州浪潮智能科技有限公司 | Service data protection method, device, equipment and readable storage medium |
| CN111917540B (en) * | 2020-08-07 | 2023-05-12 | 广州市百果园信息技术有限公司 | Data encryption and decryption method and device, mobile terminal and storage medium |
| CN112446042A (en) * | 2020-12-14 | 2021-03-05 | 中国科学院信息工程研究所 | Encryption method and device, decryption method and device, mobile terminal and storage medium |
| CN115242415A (en) | 2021-04-23 | 2022-10-25 | 伊姆西Ip控股有限责任公司 | Data encryption method implemented at edge switch, electronic device, and program product |
| CN113612746B (en) * | 2021-07-26 | 2023-05-09 | 中国建设银行股份有限公司 | Sensitive information storage method and system based on Android system |
| CN113672955B (en) * | 2021-08-19 | 2024-04-19 | 支付宝(杭州)信息技术有限公司 | Data processing method, system and device |
| CN113821821B (en) * | 2021-11-24 | 2022-02-15 | 飞腾信息技术有限公司 | Security architecture system, cryptographic operation method of security architecture system and computing device |
| CN115186300B (en) * | 2022-09-08 | 2023-01-06 | 粤港澳大湾区数字经济研究院(福田) | File security processing system and file security processing method |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105187204A (en) * | 2015-09-29 | 2015-12-23 | 北京元心科技有限公司 | Encryption method and decryption method for file, and encryption and decryption system |
| CN105260663A (en) * | 2015-09-15 | 2016-01-20 | 中国科学院信息工程研究所 | Secure storage service system and method based on TrustZone technology |
| CN105812332A (en) * | 2014-12-31 | 2016-07-27 | 北京握奇智能科技有限公司 | Data protection method |
| CN106464485A (en) * | 2014-02-11 | 2017-02-22 | 爱立信股份有限公司 | System and method for securing content keys delivered in manifest files |
-
2017
- 2017-04-01 CN CN201710214710.8A patent/CN106980794B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106464485A (en) * | 2014-02-11 | 2017-02-22 | 爱立信股份有限公司 | System and method for securing content keys delivered in manifest files |
| CN105812332A (en) * | 2014-12-31 | 2016-07-27 | 北京握奇智能科技有限公司 | Data protection method |
| CN105260663A (en) * | 2015-09-15 | 2016-01-20 | 中国科学院信息工程研究所 | Secure storage service system and method based on TrustZone technology |
| CN105187204A (en) * | 2015-09-29 | 2015-12-23 | 北京元心科技有限公司 | Encryption method and decryption method for file, and encryption and decryption system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN106980794A (en) | 2017-07-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106980794B (en) | TrustZone-based file encryption and decryption method and device and terminal equipment | |
| CN106997439B (en) | TrustZone-based data encryption and decryption method and device and terminal equipment | |
| US10708051B2 (en) | Controlled access to data in a sandboxed environment | |
| LU101903B1 (en) | System and method for storing and accessing private data of Hyperledger Fabric blockchain | |
| CN109923548B (en) | Method, system and computer program product for implementing data protection by supervising process access to encrypted data | |
| CN106992851B (en) | TrustZone-based database file password encryption and decryption method and device and terminal equipment | |
| CN107506659B (en) | Data protection system and method of general database based on SGX | |
| US7587608B2 (en) | Method and apparatus for storing data on the application layer in mobile devices | |
| EP2656270B1 (en) | Tamper proof location services | |
| US8751818B2 (en) | Method and apparatus for a trust processor | |
| CN106980793B (en) | TrustZone-based universal password storage and reading method, device and terminal equipment | |
| US9286488B2 (en) | System and method for secure database queries | |
| US7577838B1 (en) | Hybrid systems for securing digital assets | |
| KR20050085678A (en) | Attestation using both fixed token and portable token | |
| WO2021164166A1 (en) | Service data protection method, apparatus and device, and readable storage medium | |
| WO2022028289A1 (en) | Data encryption method and apparatus, data decryption method and apparatus, terminal, and storage medium | |
| US11626976B2 (en) | Information processing system, information processing device, information processing method and information processing program | |
| US20040139317A1 (en) | Methods for improved security of software applications | |
| US20210248245A1 (en) | Calculation device, calculation method, calculation program and calculation system | |
| Aloraini et al. | A survey on data confidentiality and privacy in cloud computing | |
| Fan et al. | One secure access scheme based on trusted execution environment | |
| da Rocha et al. | Secure cloud storage with client-side encryption using a trusted execution environment | |
| Wang et al. | Malicious code detection for trusted execution environment based on paillier homomorphic encryption | |
| EP2827276B1 (en) | Secure data processing | |
| US11683159B2 (en) | Hybrid content protection architecture |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20210204 Address after: 101300 room 153, 1 / F, building 17, 16 Caixiang East Road, Nancai Town, Shunyi District, Beijing Patentee after: Yuanxin Information Technology Group Co.,Ltd. Address before: 100176 room 2222, building D, building 33, 99 Kechuang 14th Street, Beijing Economic and Technological Development Zone, Beijing Patentee before: BEIJING YUANXIN SCIENCE & TECHNOLOGY Co.,Ltd. |
|
| EE01 | Entry into force of recordation of patent licensing contract | ||
| EE01 | Entry into force of recordation of patent licensing contract |
Application publication date: 20170725 Assignee: Beijing Yuanxin Junsheng Technology Co.,Ltd. Assignor: Yuanxin Information Technology Group Co.,Ltd. Contract record no.: X2021110000018 Denomination of invention: File encryption and decryption method, device and terminal device based on TrustZone Granted publication date: 20200317 License type: Common License Record date: 20210531 |