CN117176353A

CN117176353A - Method and device for processing data

Info

Publication number: CN117176353A
Application number: CN202210584742.8A
Authority: CN
Inventors: 黎相敏; 张韬
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2022-05-26
Filing date: 2022-05-26
Publication date: 2023-12-05

Abstract

The present disclosure provides a method of processing data, a user terminal, a key management device in a trusted execution environment, an application device in a trusted execution environment, a device for processing data, a computer-readable storage medium and a computer program product. The method comprises the following steps: generating, by a key management device in a trusted execution environment, a self-signed certificate for auditing or verifying key management logic; and verifying the self-signed certificate by the user terminal, and responding to the self-signed certificate passing verification, the user terminal applying a data encryption public key to a key management device in the trusted execution environment, wherein the data encryption public key is used for asymmetrically encrypting communication data.

Description

Method and device for processing data

Technical Field

The present disclosure relates to the field of internet technology and the field of computer data processing, and more particularly, to a method of processing data, a user terminal, a key management device in a trusted execution environment, an application device in a trusted execution environment, a device for processing data, a computer-readable storage medium, and a computer program product.

Background

With the continuous development of internet technology, people's life is already indistinct from the internet. Since the internet has been deep into the living aspects of people, the security of network data transmission is very important. In order to ensure the security of network data transmission, people often encrypt session data to be transmitted through the internet. However, current encrypted data transmission systems still require a large memory space for storing the encryption key, and even there is a risk of key leakage. In addition, there is still a lack of an encrypted data transmission system that can effectively compromise security and ease of use. Accordingly, improvements to existing encrypted data transmission systems are needed.

Disclosure of Invention

To solve the above-described problems, the present disclosure provides a method of processing data, a user terminal, a key management device in a trusted execution environment, an application device in a trusted execution environment, a device for processing data, a computer-readable storage medium, and a computer program product.

According to one aspect of an embodiment of the present disclosure, there is provided a method of processing data, including: generating, by a key management device in a trusted execution environment, a self-signed certificate for auditing or verifying key management logic; and verifying the self-signed certificate by the user terminal, and responding to the self-signed certificate passing verification, the user terminal applying a data encryption public key to a key management device in the trusted execution environment, wherein the data encryption public key is used for asymmetrically encrypting communication data.

According to an aspect of embodiments of the present disclosure, there is provided a user terminal comprising one or more processors, wherein the one or more processors are configured to: receiving, from a key management device in a trusted execution environment, a self-signed certificate, the self-signed certificate for auditing or verifying key management logic; and verifying the self-signed certificate, and responding to the self-signed certificate passing verification, the user terminal applies a data encryption public key to a key management device in the trusted execution environment, wherein the data encryption public key is used for asymmetrically encrypting communication data.

According to one aspect of the disclosed embodiments, there is provided a key management device in a trusted execution environment, the key management device in the trusted execution environment comprising one or more processors, wherein the one or more processors are configured to: transmitting a self-signed certificate to a user terminal, the self-signed certificate being used for auditing or verifying key management logic; receiving a data key request from the user terminal, and generating a data encryption public key and a data decryption private key; and sending the data encryption public key to the user terminal.

According to one aspect of the disclosed embodiments, there is provided an application device in a trusted execution environment, the application device in the trusted execution environment comprising one or more processors, wherein the one or more processors are configured to: receiving communication data from a user terminal, the communication data comprising an authorization credential and data encrypted with a data encryption key; transmitting a first remote attestation to a key management device in the trusted execution environment and receiving a second remote attestation from the key management device in the trusted execution environment; a data decryption private key is received from a key management device in the trusted execution environment in response to both the first remote attestation and the second remote attestation being authenticated.

According to an aspect of an embodiment of the present disclosure, there is provided an apparatus for processing data, including: one or more processors; and one or more memories, wherein the memories have stored therein computer readable code, which, when executed by the one or more processors, causes the one or more processors to perform the method as described above.

According to another aspect of embodiments of the present disclosure, there is provided a computer-readable storage medium having stored thereon computer-readable instructions, which when executed by a processor, cause the processor to perform a method according to any of the above aspects of the present disclosure.

According to another aspect of embodiments of the present disclosure, there is provided a computer program product comprising computer readable instructions which, when executed by a processor, cause the processor to perform a method as in any of the above aspects of the present disclosure.

The above aspects of the present disclosure not only can avoid the risk of key leakage, but also can avoid the user from processing complex trusted environment applications, and improve the usability of the encrypted data transmission system.

Drawings

The above and other objects, features and advantages of the presently disclosed embodiments will become more apparent from the more detailed description of the presently disclosed embodiments when taken in conjunction with the accompanying drawings. The accompanying drawings are included to provide a further understanding of embodiments of the disclosure, and are incorporated in and constitute a part of this specification, illustrate embodiments of the disclosure and together with the description serve to explain the disclosure, without limitation to the disclosure. In the drawings, like reference numerals generally refer to like parts or steps.

Fig. 1 shows a schematic diagram of an application scenario according to an embodiment of the present disclosure.

Fig. 2 shows a schematic diagram of a block structure according to an embodiment of the present disclosure.

Fig. 3 shows a schematic diagram of a TEE application sharing a key with a user terminal.

Fig. 4 shows a schematic diagram of a TEE application negotiating keys with a user terminal.

Fig. 5 illustrates an alternative flow chart of a method of processing data according to an embodiment of the present disclosure.

Fig. 6 shows an alternative schematic diagram of a method of processing data according to an embodiment of the present disclosure.

Fig. 7 shows an alternative schematic diagram of a user terminal applying a data encryption public key to a ttms according to an embodiment of the present disclosure.

Fig. 8 shows yet another alternative schematic diagram of a method of processing data according to an embodiment of the present disclosure.

Fig. 9 shows a schematic diagram of an electronic device according to an embodiment of the disclosure.

Fig. 10 illustrates a schematic diagram of an architecture of an exemplary computing device, according to an embodiment of the present disclosure.

Fig. 11 shows a schematic diagram of a storage medium according to an embodiment of the present disclosure.

Detailed Description

The technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the drawings in the embodiments of the present disclosure. It will be apparent that the described embodiments are merely embodiments of a portion, but not all, of the present disclosure. All other embodiments, which can be made by one of ordinary skill in the art without the need for inventive faculty, are intended to be within the scope of the present disclosure, based on the embodiments in this disclosure.

Embodiments of the present disclosure relate to cloud computing technology. Cloud computing (clouding) is a computing model that distributes computing tasks (e.g., computes user preferences for each of a variety of schemes) across a large number of computer-made resource pools, enabling various application systems to acquire computing power, storage space, and information services as needed. The network that provides the resources is referred to as the "cloud". Resources in the cloud are infinitely expandable in the sense of users, and can be acquired at any time, used as needed, expanded at any time and paid for use as needed.

The present disclosure provides a method of processing data, an apparatus for processing data, a computer readable storage medium, and a computer program product.

First, a method of processing data and an application scenario of a corresponding apparatus or the like according to an embodiment of the present disclosure will be described with reference to fig. 1. Fig. 1 shows a schematic diagram of an application scenario 100 according to an embodiment of the present disclosure.

The system to which the embodiments of the present disclosure relate may be a distributed system formed by a client, a plurality of nodes (any form of computing device in an access network, such as a server, a user terminal) connected by a form of network communication. The server may be an independent server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server for providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, positioning services, basic cloud computing services such as big data and an artificial intelligent platform, which are not particularly limited in the embodiments of the present disclosure. The plurality of user terminals herein may be fixed terminals such as desktop computers, etc., mobile terminals having network functions such as smartphones, tablet computers, portable computers, handheld devices, personal digital assistants, smart wearable devices, car terminals, etc., or any combination thereof, to which the embodiments of the present disclosure are not limited in particular.

The distributed system 100 provided by the embodiments of the present disclosure can be optionally applied to a blockchain system. A plurality of nodes as shown in fig. 1 form a constituent point-To-point (P2P, peer To Peer) network, and the P2P protocol is an application layer protocol that runs on top of a transmission control protocol (TCP, transmission Control Protocol) protocol. In a distributed system, any machine, such as a server, a terminal, may join to become a node, including a hardware layer, an intermediate layer, an operating system layer, and an application layer.

The nodes shown with reference to fig. 1 may relate to routing functions for supporting communication between nodes. The various nodes may also be involved in various application functions. Taking the blockchain application function as an example, each node can realize specific service according to actual service requirements, record data related to the realization function to form record data, carry a digital signature in the record data to represent the source of task data, send the record data to other nodes in the blockchain system, and enable the other nodes to add the record data into the temporary block when verifying the source and integrity of the record data.

The application functions of the nodes in fig. 1 are associated with application traffic. For example, the application service may be a wallet service that provides functions for conducting transactions in electronic currency, including initiating transactions (i.e., sending transaction records of current transactions to other nodes in the blockchain system, after verification by other nodes is successful, as a response acknowledging that the transaction is valid, storing record data of the transaction in a temporary block of the blockchain; of course, the wallet may also support querying electronic currency remaining in the electronic currency address.

Of course, the nodes described above may also be involved in operating the blockchain functionality. The blockchain is a system comprising a series of blocks (blocks) that follow each other in chronological order, and new blocks are not removed once they are added to the blockchain, and record data submitted by nodes in the blockchain system are recorded in the blocks. Referring to fig. 2, fig. 2 is an optional Block Structure (Block Structure) provided in an embodiment of the present disclosure, where each Block includes a hash value of a transaction record stored in the Block (hash value of the Block) and a hash value of a previous Block, and the blocks are connected by the hash values to form a Block chain. In addition, the block may include information such as a time stamp at the time of block generation. The Blockchain (Blockchain), which is essentially a de-centralized database, is a string of data blocks that are generated in association using cryptographic methods, each of which contains associated information that is used to verify the validity (anti-counterfeiting) of its information and to generate the next block.

For another example, the nodes shown in FIG. 1 may also be used for trusted computing. That is, the distributed system 100 is capable of providing a hardware support-based trusted execution environment to protect computing process security, data privacy and authentication data integrity, source reliability, and the like. Thus, each node in distributed system 100 can optionally be such that data, program logic within a trusted execution environment cannot be snooped by external environments without active output.

For example, each node shown in FIG. 1 may be a trusted computing (Trusted Computing, TC) node. A trusted computing node is a node device that contains a trusted execution environment (Trusted Execution Environment, TEE). One or more TEE applications are installed on the trusted computing node, the TEE applications being capable of interacting with a multimedia execution environment (Rich Execution Environment, REE) on the user terminal. To secure TEE resources, the TEE can access resources that the REEs can access, while trusted resources on the TEE only allow other trusted resources to access unless there is explicit authorization by the TEE.

Currently, in some cases, TEE applications have been able to share keys with user terminals to enable user terminals to securely access data in the TEE environment. For example, as shown in fig. 3, a key management system (Key Management System, KMS) may be utilized to host keys. For example, the user terminal may apply for the symmetric key to the KMS in advance, and then encrypt data using the symmetric key through the KMS, and transmit the obtained ciphertext to the TEE application. The TEE application obtains the session key through the KMS to decrypt the ciphertext, using the plaintext for application logic of the TEE application.

As another example, as shown in fig. 4, the user may also conduct key agreement with the TEE application. Before each data transmission, the user terminal executes a key exchange protocol with the TEE application to negotiate a disposable session key pair, then the user terminal encrypts the session data by using a session encryption key, and then the obtained ciphertext is transmitted to the TEE application, and the TEE application decrypts the ciphertext based on the session decryption key to restore the session data for subsequent calculation. In addition, if communication is required between TEE applications, session key pairs need to be negotiated pairwise.

However, neither of the solutions shown in fig. 3 and 4 effectively compromise safety and ease of use. For example, in the KMS key escrow scheme shown in fig. 3, since KMS management logic is running at a remote service, the user terminal cannot verify the confidentiality and integrity of the KMS in real time. There is a risk of leakage of the user key if there is a malicious program or backdoor in the KMS. Furthermore, in general, the key managed by the KMS is not directly derivable. While such a design is advantageous for improving security similar to applications in REEs, it limits the flexibility of the TEE application to use keys for TEE applications. Still further, KMSs require additional equipment, increasing costs. Furthermore, the KMS managed key scheme shown in fig. 3 is also not applicable to outsourced/multiparty computing.

For another example, in the scheme of negotiating a key in real time as shown in fig. 4, each negotiation process requires the ue to verify the TEE application, and the usage threshold is high. Meanwhile, the scheme of negotiation in pairs is not only high in communication complexity and low in efficiency, but also can not multiplex the keys. The TEE application must precede the existence of the key and cannot perform the time-consuming encryption of the data in advance on-line.

Based on this, embodiments of the present disclosure can avoid the risk of key leakage and also reduce the processing of complex information in the TEE (e.g., TEE metric information) by the user terminal. After the user terminal authorizes the data decryption private key, the data decryption private key can be securely issued from a KMS (hereinafter abbreviated as tKMS) based on the TEE to the TEE application for use.

For example, some embodiments of the present disclosure allow a user terminal to apply an encryption public key for asymmetrically encrypting data to a tKMS and authorize use of a corresponding decryption private key for a designated TEE application. After proving the environmental legitimacy of the TEE application to the tKMS by means of a remote proving mechanism, the TEE application can obtain a corresponding data decryption private key for decrypting the ciphertext by only presenting user authorization credentials. Compared with the traditional KMS, the tKMS can also derive data encryption keys in a layering mode, and storage space is saved.

For another example, some embodiments of the present disclosure enable the data decryption private key to be securely circulated within the TEE environment after being strictly authorized, without disclosure to other unrelated parties, avoiding the risk of disclosure due to the need for human custody of the data decryption private key. KMSs implemented by TEE can provide data privacy guarantees for outsourced/multi-party computing compared to traditional KMSs. The outsourcing calculation/multiparty calculation can be used for solving the cooperative calculation problem of protecting privacy among a group of mutually-untrusted participants, and can ensure that input values of all the participants are not revealed to other members participating in calculation under the conditions of realizing independence of input, correctness of calculation and decentralization. That is, multiparty computing can be used to address the problem of how to securely compute a commitment function without a trusted third party, while requiring that each participating entity not obtain any input information from other entities than the result of the computation.

A method of processing data according to an embodiment of the present disclosure is described below with reference to fig. 5 to 8. For example, FIG. 5 illustrates an alternative flow chart of a method 50 of processing data according to an embodiment of the present disclosure. Fig. 6 shows an alternative schematic diagram of a method 50 of processing data according to an embodiment of the present disclosure. Fig. 7 shows an alternative schematic diagram of a user terminal applying a data encryption public key to a ttms according to an embodiment of the present disclosure. Fig. 8 shows yet another alternative schematic diagram of a method 50 of processing data according to an embodiment of the present disclosure. The method 50 may be performed by the distributed system 100 described with reference to fig. 1-2, although the disclosure is not limited in this respect.

In connection with fig. 6, the distributed system 100 includes a key management device (which is shown as tKMS in fig. 6) in a trusted execution environment, a user terminal, and an application device (which is shown as TEE application in fig. 6) in the trusted execution environment. As one example, the method 50 includes operations S510 and S520 shown in fig. 5. The method 50 further optionally includes operations S530 through S560. Of course, the present disclosure is not limited thereto.

For example, in connection with fig. 5, in operation S510, a self-signed certificate is generated by a key management device in a trusted execution environment, the self-signed certificate being used to audit or verify key management logic. In operation S520, the self-signed certificate is verified by the user terminal, and in response to the self-signed certificate passing verification, the user terminal applies a data encryption public key to a key management device in the trusted execution environment, the data encryption public key being used to asymmetrically encrypt communication data.

For example, the trusted execution environment may be comprised of trusted software and hardware resources such as a processor on the terminal device, secure memory, trusted user interface (Trusted User Interface, TUI), trusted operating system (Trusted Operating System, TOS), and trusted applications (Trusted Application, TA), which together constitute a secure execution environment.

For example, in some embodiments of the present disclosure, the trusted execution environments described above can each generate a public-private key pair for identifying the identity of the trusted execution environment in an asymmetric encrypted manner. At the time of chip production, the private key of the trusted execution environment is written into the chip. No node can learn the private key other than the trusted execution environment. While the public key of the trusted execution environment is public. Any file encrypted by the public key corresponding to the chip can be decrypted only by the private key in the chip. It should be noted that the private key in each chip is unique and not tamperable. In this way, personal information of the user can be stored and processed more securely in this running environment isolated from the REEs (e.g., user terminals), so that the user can perform operations with higher confidentiality requirements such as electronic payment with ease.

As another example, a key management device tKMS in a trusted execution environment is a device that is capable of running key management logic in a trusted execution environment. Key management logic includes proxy user terminal generation keys, serving keys, updating keys, storing keys, and the like. The present disclosure is not limited in this regard. The key management device tKMS in a trusted execution environment is capable of handling not only asymmetric keys but also self-signed certificates, as compared to conventional key management devices (e.g., KMSs in fig. 3) that can only handle symmetric keys. Wherein the self-signed certificate is used for auditing (e.g., public auditing) and verification (e.g., runtime verification) key management logic.

In some embodiments, the self-signed certificate is a trusted identity of the tKMS. Conventional KMSs often cannot generate trusted identities. Even if a traditional KMS is able to self-sign its own certificate, it often cannot pass verification by other nodes. However, since the self-signed certificate in operation S510 is generated in a trusted execution environment, it can be audited and verified by any node, thereby ensuring the trustworthiness of the self-signed certificate.

Optionally, the self-signed certificate is randomly generated at a first boot-up of the ttms or at deployment of the ttms. The ttms generates a private key and a public key corresponding to the self-signed certificate at the same time as the self-signed certificate, and hereinafter the private key corresponding to the self-signed certificate is referred to as a self-signed certificate private key and the public key corresponding to the self-signed certificate is referred to as a self-signed certificate public key. The self-signed certificate private key and the self-signed certificate public key are used to verify the legitimacy of the self-signed certificate.

For example, in some embodiments of the present disclosure, the signature information of the self-signed certificate is generated based on the self-signed certificate private key, which can be verified by the self-signed certificate public key. Wherein the process of generating signature information of the self-signed certificate based on said self-signed certificate private key (also called signature process) is publicly auditable and verifiable in real time. Thus, any node that needs to interact with the tKMS can verify the legitimacy of the signature information of the self-signed certificate provided by the tKMS. For example, the user terminal can verify the validity of the signature information of the self-signed certificate using the self-signed certificate public key.

In some embodiments of the present disclosure, the self-signed certificate private key is sealed locally, while the self-signed certificate public key is disclosed. Here, "encryption and decryption" refers to the act of storing encrypted data such as a key (asymmetric key or symmetric key) derived from hardware, locally. The keys derived by the same hardware for the tKMS with the same metric information are identical, and the derived keys are different due to the fact that the hardware or the metric information is changed.

Optionally, at the first startup of the ttms or deployment of the ttms, the ttms will also randomly generate a master key MK and seal the master key MK locally. Thereafter, if the tKMS restarts, the tKMS may restore the same master key MK from the sealed ciphertext, thereby ensuring continuity of the service provided to the outside.

In some embodiments of the present disclosure, optionally, the self-signed certificate further comprises metric information of the trusted execution environment tKMS, and the metric information comprises information of a self-signed certificate public key. For example, the metric information of the trusted execution environment may be embedded into a credential extension field. Information from the signed certificate public key may be embedded in a custom field of the metric information. Further, in some examples of the present disclosure, the ttms, when generating the self-signed certificate, signs the above-described metric information including the information of the self-signed certificate public key based on the self-signed certificate private key to ensure that the self-signed certificate is not tamperable.

In some embodiments of the present disclosure, the information of the self-signed certificate public key is, for example, a hash value corresponding to the self-signed certificate public key. The hash value corresponding to the public key of the self-signed certificate may be obtained by performing hash operation on the public key of the self-signed certificate by using various hash algorithms, which include, but are not limited to, one of the common hash algorithms such as SM3 and SHA 256. The present disclosure is not limited thereto.

Optionally, the measurement information of the trusted execution environment (hereinafter also referred to as TEE measurement information) is a credential for proving the correspondence of the tKMS with its code logic, runtime hardware environment. For example, TEE metric information optionally includes: hash metrics of the application code logic, signature of the hardware to the code logic hash metrics (signature private key built into the hardware by the hardware vendor), signature of the hardware public key by the hardware vendor, and so on. If the signature of the hardware manufacturer to the hardware public key can be verified by any node, the hardware can be proved to originate from a legal hardware manufacturer. If the signature of the hardware on the key management logic can be verified by any one of the nodes, that node can determine that the key management logic it expects the tKMS to execute does operate in the expected hardware environment, thereby proving the integrity of the tKMS. While the security of the ttms is guaranteed by the TEE provided by the hardware. In still other examples, the metric information further includes data determined based on the tKMS, such as intermediate data of a key exchange protocol. Such intermediate data are, for example, public keys that are relied upon (e.g., a certificate public key of the tKMS, or a certificate public key of the TEE application, or an identity public key of the user terminal) negotiated between the tKMS and the TEE application, between the tKMS and the non-TEE application, and between the tKMS and the user terminal, which public keys assist in computing session keys for encrypted communications between the two parties.

For example, any of the nodes in fig. 1 can publicly audit the key management logic of the tKMS. The audit of the key management logic of the tKMS can not only determine that the software source code or any static file corresponding to the key management logic is not tampered, but also determine that the software source code or any static file has no backdoor or vulnerability, thereby ensuring that the key management logic of the tKMS does not leak a user key. As another example, any of the nodes in fig. 1 may also perform run-time authentication (also known as real-time authentication) on the key management logic of the tKMS. Runtime verification of the key management logic of the ttms can ensure that the key management logic runs the intended software source code. Some malicious attackers are likely to attempt to attack the key management logic so that the key management logic does not run audited software source code but rather run errant malicious code. By run-time verification of the key management logic of the ttms, it can be ensured that the key management logic can run the correct code to provide the correct and secure key each time the user terminal requests the ttms to provide the key.

For example, assume that there is one such attack scenario: a malicious attacker uses the tKMS' to impersonate the tKMS in an attempt to fool the trust of any one of the nodes in fig. 1 or the user terminal/TEE application in fig. 6. In order for the tmms 'to successfully impersonate the tmms, a malicious attacker needs to enable the tmms' to provide a fake certificate and needs the user terminal/other node to have difficulty distinguishing the fake certificate from the self-signed certificate of the tmms. For this reason, a malicious attacker needs to construct a fake certificate that includes the metric information of the fake tKMS, and the metric information of the fake tKMS includes the information of the public key of the fake certificate of tKMS'.

However, according to the above-described construction rule of the certificate, the metric information includes information of the public key of the self-signed certificate of the ttms. If a malicious attacker only sets the public key corresponding to the counterfeit certificate as the public key of the ttms 'without changing the information of the public key of the self-signed certificate embedded in the metric information, the user terminal can easily recognize that the public key of the counterfeit certificate is different from the public key embedded in the metric information, so that it can easily verify that the counterfeit certificate is illegal without applying for the data encryption key from the ttms'.

If a malicious attacker sets the public key corresponding to the forged certificate as the public key of the ttms 'and falsifies the public key information of the ttms embedded in the metric information as the public key information of the ttms', the malicious attacker must be able to generate the metric information of the ttms. Whereas the hardware will only generate metrology information for the ttms that is strongly associated with the ttms (any changes to the ttms application will result in changes to the metrology information). Forced replacement of the public key information embedded with the metric information may result in the metric information not being correctly identified as the metric information of the ttms. And once the structure of the metrology information is broken, signatures or the like that protect the integrity of the structure cannot be verified. Thus, it is impossible for a malicious attacker to forge a certificate that can be verified by the user terminal/TEE application based on the metric information of the tKMS and the public key of the tKMS', so that the identity of the tKMS cannot be spoofed.

Optionally, in step 520, after the user terminal receives the self-signed certificate transmitted by the ttms, the user terminal may obtain public key information of the self-signed certificate from the metric information of the self-signed certificate. The user terminal may then determine the association between the self-signed certificate and the tKMS (i.e., determine whether the self-signed certificate must be generated by the tKMS) by verifying whether the public key information in the self-signed certificate matches the public key of the self-signed certificate (a process also known as association verification). For example, in the case where the public key information in the self-signed certificate matches the public key of the self-signed certificate, then the self-signed certificate passes the association verification. In the case that the public key information in the self-signed certificate is not matched with the public key of the self-signed certificate, the self-signed certificate cannot pass the relevance verification, and the self-signed certificate fails to verify.

And then the user terminal performs validity verification on the certificate bookmark name, and if the self-signed certificate passes both the relevance verification and the validity verification, the self-signed certificate passes the verification (namely, the user terminal confirms that the self-signed certificate is legal). Furthermore, if the user terminal determines that the certificate signature is not legal (i.e., the user terminal recognizes the self-signed certificate as illegal), the self-signed certificate also fails to verify.

Examples of the above procedure, i.e. the process of public auditing and runtime verification of a user terminal to a ttms. Of course, depending on the different construction manners of the self-signed certificate, the user terminal may also verify the validity of the self-signed certificate by other manners, which is not limited in this disclosure.

Then, after determining that the self-signed certificate is legal, the user terminal can determine that the metric information in the self-signed certificate can only be generated by the ttms, and the private key of the self-signed certificate is only held by the ttms, so that the user terminal can execute a key exchange protocol with the ttms based on the self-signed certificate to apply a data encryption public key X to the ttms, which is used for asymmetrically encrypting communication data. In some embodiments, the communication data is transmitted by the user terminal to the TEE application. Furthermore, the communication channel between the user terminal and the tKMS is safe, and the third party cannot obtain the session key, so that the third party cannot know the communication data between the user terminal and the tKMS, and the data encryption public key X cannot be revealed.

For example, as shown in fig. 7, the user terminal may apply for a data encryption public key to the tKMS in the following manner. First, the user terminal will acquire a pair of asymmetric key pairs (Y, Y) for authentication of the user terminal, hereinafter referred to as a user identity public key, and a private key Y for authentication of the user terminal as a user identity private key. The ue may calculate the public and private user identities in advance, or the ue may randomly generate the public and private user identities before performing a key agreement with the tKMS. The present disclosure does not limit the manner in which the user identity public key and the user identity private key are obtained.

The user terminal then performs a key agreement with the tKMS based on the user identity public key Y and the tKMS's certificate public key to determine a session key, thereby receiving the session key from the tKMS, and the tKMS will save the session key. Wherein the session key is used only for encrypting information that the user terminal passes to the tKMS, and the session key is used only for decrypting information from the user terminal by the tKMS. The process of key agreement may be based on various key exchange protocols. For example, the process of key agreement may be based on the DHE (Diffie-Hellman-Ephemeral) key exchange protocol. The DHE key exchange protocol is a secure protocol that allows two parties to negotiate a temporary session key over an unsecure channel without any prior information from the parties at all. This key may be used as a symmetric key in subsequent communications to encrypt session content. As another example, the key exchange protocol may also be the ECDHE key exchange protocol. The ECDHE key exchange protocol is a variant of the DHE key exchange protocol implemented based on elliptic curves, and the same effect can be achieved.

After obtaining the session key, the user terminal will encrypt the data key request with the session key. The data key request includes a user identity public key Y. After receiving the ciphertext encrypted by the session key for the data key request, the tKMS decrypts the ciphertext by using the session key to obtain the user identity public key Y. Next, the tKMS will determine the data decryption private key z using the master key MK and the user identity public key Y generated in step 510. For example, the ttms concatenates the hash value of the master key MK and the user identity public key Y into one string "mk|y hash value" (where "|" represents concatenation of strings), and then determines the hash value of the string "mk|y hash value" as the data decryption private key z.

In some embodiments of the present disclosure, the data key request optionally further includes a number of grants T. After receiving the ciphertext encrypted by the session key for the data key request, the tKMS decrypts the ciphertext by using the session key to obtain a user identity public key Y and an authorization frequency upper limit T. the tKMS will set its number of authorizable times to T with the hash value of Y as a key. And updating the authorization times of Y in response to the existence of the T corresponding to Y. If T is less than or equal to 0, the user terminal wishes to cancel its key authorization permission. For example, assuming that the upper limit T of the number of grants included in the data key request is 5, and the tKMS determines that the upper limit of the number of grants corresponding to the user identity public key Y is 2 in the key negotiation process, the tKMS will modify 2 to 5 according to the data key request. Assuming that the upper limit of the authorization times T included in the data key request is-1, and the tKMS determines that the upper limit of the authorization times corresponding to the user identity public key Y is 2 in the key negotiation process, the tKMS modifies the upper limit of the authorization times T from 2 to-1 according to the data key request, and directly cancels the user identity public key Y or directly deletes the user identity public key Y. At this time, if the TEE application applies to the tKMS for obtaining a data decryption private key for decrypting ciphertext of the user terminal, the tKMS will refuse to provide.

In some embodiments of the present disclosure, the data key request optionally further comprises a random string nonce generated by the user terminal. After receiving the ciphertext encrypted by the session key for the data key request, the tKMS decrypts the ciphertext by using the session key to obtain the user identity public key Y, the upper limit T of the authorization times and the random string nonce. Based on the random string nonce, the tKMS may determine that the data key request is a new data key request provided by the user terminal, rather than a data key request provided by a malicious attacker in a replay attack.

After the ttms obtains the data decryption private key Z, the ttms will determine the data encryption public key Z based on the data decryption private key Z and provide the data encryption public key Z to the user terminal. Thereby, the user terminal successfully applies for the data encryption public key Z.

Referring back to fig. 6, the user terminal will communicate with the TEE application using the data encryption public key Z. For example, the user terminal encrypts the communication data using the data encryption public key Z, and then transmits the encrypted communication data to the TEE application. The communication data also comprises the authorization of the user terminal to use the data decryption private key for the TEE application. The TEE application, upon obtaining the data decryption private key from the tKMS based on the authorization, will decrypt the communication data using the data decryption private key, thereby completing the communication data-related calculations.

An example process by which the TEE application applies a data decryption private key to the tKMS is described further below with reference to fig. 8. Optionally, the method 50 further optionally includes operations S530 to S560. The present disclosure is not limited thereto.

In operation S530, communication data encrypted via the data encryption public key is transmitted to the application device in the trusted execution environment by the user terminal. Alternatively, as described above, the TEE application will receive communication data from the user terminal, which communication data is encrypted with the data encryption public key, and which communication data comprises the authorization credentials and the data encrypted with the data encryption key X. In fig. 8, the data encrypted with the data encryption key X is shown as ciphertext. For another example, the authorization credential is a credential that the TEE application proves to the tKMS the legitimacy of its communication with the user terminal, indicating that the TEE application is legitimate to decrypt the private key using the data.

As one example, the authorization credential includes: a user identity public key Y, credential information M, and a signature Sig of the credential information M with the user identity private key Y. The credential information M includes: the application device in the trusted execution environment measures information, hash values of data to be calculated by the TEE application, and user terminal custom data. Wherein, by including the measurement information of the application device (TEE application) in the trusted execution environment in the credential information M, only the TEE application corresponding to the measurement information one-to-one can be made to have the right to obtain the data decryption private key. Other information may also be included in the authorization ticket, which is not limiting to the present disclosure.

Next, in operation S540, a first remote attestation is sent by the application device in the trusted execution environment to the key management device in the trusted execution environment, and a second remote attestation is sent by the key management device in the trusted execution environment to the application device in the trusted execution environment.

For example, an application device in the trusted execution environment will provide a first remote attestation to a key management device in the trusted execution environment. For example, the first remote attestation enables the TEE application to attest to third parties (e.g., tKMS) to the legitimacy of the hardware of the environment in which itself is running. If the third direction TEE application initiates the challenge, the TEE application can send the information set containing the hash metric of the code logic of the TEE application, sign the information set and return the information set to the third party for identity verification. If the verification is successful, the remote attestation is complete. Similarly, the key management device in the trusted execution environment will also provide a second remote attestation to the application device in the trusted execution environment. The process by which the TEE application and the tKMS provide remote attestation with each other is described in fig. 8 as a two-way remote attestation process. After the two-way remote attestation process, both the TEE application and the tKMS confirm the legitimacy of the other party.

In some embodiments of the present disclosure, the first remote attestation further comprises an authorization credential. At this time, the tKMS may verify that the user identity public key Y corresponds to the number of times of authorization T in addition to verifying the metric information (e.g., the above hash metrics including its own code logic) carrying the TEE application. For example, the ttms uses the public user identity key Y as a key to search for the corresponding authorization times T. In response to the metric information being legal and the number of grants T being greater than zero, then the tKMS may confirm that the user identity public key Y in the grant credentials is still valid. At this point, the tKMS will decrement the authorization number T by one and determine that the TEE application is entitled to use the data decryption private key z. In response to the authorization number T being less than or equal to zero, the tKMS may confirm that the user identity public key Y in the authorization credential is invalid, requiring the user terminal to reapply the data encryption public key and update the authorization number T.

In some embodiments of the present disclosure, the tKMS utilizes the user identity public key Y to verify the legitimacy of the signature Sig in the authorization credential in addition to verifying the above-described metric information of the TEE application, the number of authorizations T to which the user identity public key Y corresponds. In response to the metric information being legal, the number of grants T being greater than zero, and the signature Sig being legal, the tKMS will subtract one from the number of grants T and determine that the TEE application is entitled to decrypt the private key z using the data. In addition, the tKMS recognizes that the TEE application has no rights to use the data decryption private key z.

Next, in operation S550, a data decryption private key is transmitted by the key management device in the trusted execution environment to the application device in the trusted execution environment in response to the first remote attestation and the second remote attestation both being verified. For example, the data decryption private key is used to decrypt the communication data. For example, the data decryption private key z is used to decrypt ciphertext sent by the user device to the TEE application.

Note that in operations S540 and S550, the communication information between the tKMS and the TEE application may be transmitted and received through the secure channel, thereby securing the security of the communication between the tKMS and the TEE application. All data communicated in the secure channel is encrypted.

In operation S560, the communication data is decrypted by the application device in the trusted execution environment based on the data decryption private key.

As one example, the method 50 may be applied to trusted computing of electronic medical records (Electronic Health Record, EHR) of a patient, the result of which is, for example, patient condition information. Due to the rapid growth of the medical industry, medical health data has increased rapidly, and many medical institutions have employed electronic medical records to record patient medical data. Because of the complexity of EHR data, it includes pictures generated by contrast, text recordings of physician visits, prescription information, and the like. The patient's condition to be predicted from EHR is very complex and involves a large number of operations. Typically, the computational effort of the user terminal of the patient is often limited. For this reason, a patient needs a remote trusted application to assist in the prognosis of his condition.

Then at this point the patient's user terminal will apply for the data encryption public key Z from the already deployed tKMS, and then encrypt the user's private electronic medical records (which include contrast-generated pictures, physician-interviewed text records, prescription information, etc.) with the data encryption public key Z to form ciphertext.

The user terminal of the patient sends the ciphertext and the authorization credential to the TEE application. The TEE application applies the use right of the data decryption private key z to the tKMS using the authorization credential. After the ciphertext is successfully decrypted by the TEE application, the electronic medical record is analyzed based on the neural network to determine the illness state information of the patient, so that the illness state information of the patient is ensured not to be leaked.

For example, the TEE application may use a neural network model to generate health scores from EHR data provided by a user in communication data through machine learning. With the development of machine learning, various neural network models may be used to accomplish the task of machine learning as described above, such as a Deep Neural Network (DNN) model, a Factorization Machine (FM) model, and the like. These neural network models may be implemented as loop-free graphs in which neurons are arranged in different layers. Typically, the neural network model includes an input layer and an output layer, which are separated by at least one hidden layer. The hidden layer transforms the input received by the input layer into a representation useful for generating an output in the output layer. The neural network nodes are fully connected to nodes in adjacent layers via edges, and there are no edges between nodes within each layer. Data received at a node of an input layer of the neural network is propagated to a node of an output layer via any one of a hidden layer, an active layer, a pooling layer, a convolutional layer, and the like. The input and output of the neural network model may take various forms, which is not limited by the present disclosure. Processing highly private and valuable data such as medical health data (e.g., EHR data) in TEE applications helps to preserve the privacy of the user terminal.

The above embodiment of the present disclosure combines a trusted execution environment with a key management logic, so that the key generation process can be auditable and verifiable, and it is also ensured that only the TEE application authorized by the user can use the key.

Various embodiments of the present disclosure may also optionally have at least one of the following advantages over conventional approaches.

(1) Various embodiments of the present disclosure utilize a TEE to consolidate key management devices to generate a tKMS, ensuring that key management logic can be publicly audited and verifiable at run-time without relying on a third party other than the hardware manufacturer. the tKMS is able to securely host the data decryption private key. the source code of the ttms is only online after being audited by a third party (e.g., a user terminal), and the line status of the ttms does not reveal any key information.

(2) Embodiments of the present disclosure do not risk revealing the data decryption private key. The user terminal can only apply for the data encryption public key to encrypt data, and cannot acquire the data decryption private key in the tKMS. Thus, the problem of decrypting the private key with the compromised data at the user terminal is avoided.

(3) The key authorization flow of each embodiment of the disclosure is concise and efficient. The TEE remote attestation process only needs to occur between the user terminal and the tKMS at low frequency (once or several times), so that the user terminal does not need to repeatedly verify the TEE application executing the calculation, and the user use process is simplified.

(4) The circulation process of the data decryption private key of each embodiment of the present disclosure is safe and controllable. the tKMS strictly and the TEE application forcedly implement a bidirectional remote attestation mechanism, mutually verify the legal of the TEEs strictly, and the tKMS ensures that the data decryption private key is issued after the authorization of the TEE application is legal, so that the data decryption private key is ensured not to flow to the irrelevant TEE application or other equipment, and the security of the data decryption private key is ensured.

(5) The tKMS of the various embodiments of the present disclosure require only a small key storage space. The data encryption public key and the data decryption private key used by the user terminal are both generated by the tKMS based on a hierarchical key derivation algorithm (i.e., both are derived in real-time using the master key MK). the tKMS does not need to store the derived subkeys.

(6) The number of key uses of the various embodiments of the present disclosure is controllable. The user terminal may set or update an upper limit on the number of times the data decryption private key may be authorized for use such that the number of uses exceeds the upper limit and thawed when the upper limit is frozen or the upper limit is below the number of uses.

According to yet another aspect of the present disclosure, there is also provided a user terminal comprising one or more processors, wherein the one or more processors are configured to: receiving, from a key management device in a trusted execution environment, a self-signed certificate, the self-signed certificate for auditing or verifying key management logic; and verifying the self-signed certificate, and responding to the self-signed certificate passing verification, the user terminal applies a data encryption public key to a key management device in the trusted execution environment, wherein the data encryption public key is used for asymmetrically encrypting communication data. Optionally, the one or more processors of the user terminal are further configured to: communication data is sent to an application device in a trusted execution environment, the communication data including authorization credentials and data encrypted with a data encryption key. The respective operations of the user terminal have been described in detail with reference to fig. 5 to 8, and will not be described again here.

According to yet another aspect of the present disclosure, there is also provided a key management device in a trusted execution environment, the key management device in the trusted execution environment comprising one or more processors, wherein the one or more processors are configured to: transmitting a self-signed certificate to a user terminal, the self-signed certificate being used for auditing or verifying key management logic; receiving a data key request from the user terminal, and generating a data encryption public key and a data decryption private key; and sending the data encryption public key to the user terminal. Optionally, the processor of the key management device in the trusted execution environment is further configured to: a first remote attestation is received from an application device in the trusted execution environment and a second remote attestation is sent to the application device in the trusted execution environment, and a data decryption private key is sent to the application device in the trusted execution environment in response to both the first remote attestation and the second remote attestation being verified. The respective operations of the key management device in the trusted execution environment have been described in detail with reference to fig. 5 to 8, and will not be described in detail here.

According to yet another aspect of the present disclosure, there is also provided an application device in a trusted execution environment, the application device in the trusted execution environment comprising one or more processors, wherein the one or more processors are configured to: receiving communication data from a user terminal, the communication data comprising an authorization credential and data encrypted with a data encryption key; transmitting a first remote attestation to a key management device in the trusted execution environment and receiving a second remote attestation from the key management device in the trusted execution environment; a data decryption private key is received from a key management device in the trusted execution environment in response to both the first remote attestation and the second remote attestation being authenticated. Optionally, the processor of the application device in the trusted execution environment is further configured to: the communication data is decrypted based on a data decryption private key. The present disclosure has described in detail the respective operations of the application device in the trusted execution environment with reference to fig. 5 to 8, and will not be described in detail herein.

According to yet another aspect of the present disclosure, there is also provided an apparatus for processing data for implementing a method according to an embodiment of the present disclosure. Fig. 9 shows a schematic diagram of an electronic device 2000 in accordance with an embodiment of the present disclosure.

As shown in fig. 9, the electronic device 2000 may include one or more processors 2010, and one or more memories 2020. Wherein said memory 2020 has stored therein computer readable code which, when executed by said one or more processors 2010, can perform a method as described above.

The processor in embodiments of the present disclosure may be an integrated circuit chip having signal processing capabilities. The processor may be a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components. The methods, operations, and logic blocks of the disclosure in the embodiments of the present disclosure may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like, and may be of the X86 architecture or ARM architecture.

In general, the various example embodiments of the disclosure may be implemented in hardware or special purpose circuits, software, firmware, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While aspects of the embodiments of the present disclosure are illustrated or described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that the blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

For example, a method or apparatus according to embodiments of the present disclosure may also be implemented by means of the architecture of computing device 3000 shown in fig. 10. As shown in fig. 10, computing device 3000 may include a bus 3010, one or more CPUs 3020, a Read Only Memory (ROM) 3030, a Random Access Memory (RAM) 3040, a communication port 3050 connected to a network, an input/output component 3060, a hard disk 3070, and the like. A storage device in the computing device 3000, such as a ROM 3030 or hard disk 3070, may store various data or files for processing and/or communication of the methods provided by the present disclosure and program instructions for execution by the CPU. The computing device 3000 may also include a user interface 3080. Of course, the architecture shown in FIG. 10 is merely exemplary, and one or more components of the computing device shown in FIG. 10 may be omitted as may be practical in implementing different devices.

According to yet another aspect of the present disclosure, a computer-readable storage medium is also provided. Fig. 11 shows a schematic diagram of a storage medium 4000 according to the present disclosure.

As shown in fig. 11, the computer storage medium 4020 has stored thereon computer readable instructions 4010. When the computer readable instructions 4010 are executed by a processor, a method according to an embodiment of the disclosure described with reference to the above figures may be performed. The computer readable storage medium in embodiments of the present disclosure may be volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be Random Access Memory (RAM), which acts as external cache memory. By way of example, and not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), synchronous Dynamic Random Access Memory (SDRAM), double data rate synchronous dynamic random access memory (ddr SDRAM), enhanced Synchronous Dynamic Random Access Memory (ESDRAM), synchronous Link Dynamic Random Access Memory (SLDRAM), and direct memory bus random access memory (DR RAM). It should be noted that the memory of the methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory. It should be noted that the memory of the methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

The disclosed embodiments also provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. A processor of a computer device reads the computer instructions from a computer-readable storage medium, the processor executing the computer instructions, causing the computer device to perform a method according to an embodiment of the present disclosure.

It is noted that the flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The exemplary embodiments of the present disclosure described in detail above are illustrative only and are not limiting. Those skilled in the art will understand that various modifications and combinations of these embodiments or features thereof may be made without departing from the principles and spirit of the disclosure, and such modifications should fall within the scope of the disclosure.

Claims

1. A method of processing data, comprising:

generating, by a key management device in a trusted execution environment, a self-signed certificate for auditing or verifying key management logic; and

And verifying the self-signed certificate by the user terminal, and responding to the self-signed certificate passing verification, the user terminal applying a data encryption public key to a key management device in the trusted execution environment, wherein the data encryption public key is used for asymmetrically encrypting communication data.

2. The method of claim 1, wherein the self-signed certificate includes metric information of the trusted execution environment, and the metric information includes public key information of the self-signed certificate.

3. The method of claim 2, wherein the self-signed certificate includes signature information of a self-signed certificate generated based on the self-signed certificate private key.

4. The method of claim 2, wherein the verifying, by the user terminal, the self-signed certificate comprises:

acquiring public key information of the self-signed certificate from the measurement information of the self-signed certificate by the user terminal;

responding to the public key information of the self-signed certificate to be matched with the public key of the self-signed certificate, and then the self-signed certificate passes the relevance verification;

and in response to the public key information of the self-signed certificate not matching the public key of the self-signed certificate, failing to verify the relevance of the self-signed certificate.

5. The method of claim 1, wherein the user terminal applying for a data encryption public key to a key management device in the trusted execution environment comprises:

acquiring an asymmetric key pair for identity verification of a user terminal by the user terminal, wherein the asymmetric key pair comprises a user identity public key and a user identity private key;

negotiating, by the user terminal, a session key with a key management device in the trusted execution environment based on the user identity public key and a public key of the self-signed certificate; and

based on the session key, the user terminal applies for a data encryption public key to a key management device in the trusted execution environment.

6. The method of claim 5, wherein the applying, by the user terminal, a data encryption public key to a key management device in the trusted execution environment based on the session key comprises:

encrypting, by the user terminal, a data key request using the session key;

transmitting, by the user terminal, an encrypted data key request to a key management device in the trusted execution environment;

generating, by a key management device in the trusted execution environment, the data encryption public key and the data decryption private key based on the encrypted data key request;

And transmitting the data encryption public key to the user terminal by a key management device in the trusted execution environment.

7. The method of claim 6, wherein the data key request comprises a user identity public key or a combination of a user identity public key and one or more of: the authorization times and the random character string generated by the user terminal.

8. The method of claim 1, wherein the method further comprises: communication data is sent by the user terminal to an application device in the trusted execution environment, the communication data comprising an authorization credential and data encrypted with a data encryption key.

9. The method of claim 8, wherein the authorization credential comprises at least: a user identity public key, credential information, and a signature of the credential information with the user identity private key.

10. The method of claim 9, wherein the credential information comprises at least one of: the method comprises the steps of measuring information corresponding to an application device in a trusted execution environment, hash values of data to be calculated by the application device in the trusted execution environment and user terminal customized data.

11. The method of claim 8, wherein the method further comprises:

transmitting, by an application device in the trusted execution environment, a first remote attestation to a key management device in the trusted execution environment, and a second remote attestation to the application device in the trusted execution environment,

wherein the first remote attestation further comprises the authorization credential.

12. The method of claim 11, wherein the method further comprises:

and transmitting, by a key management device in the trusted execution environment, a data decryption private key to an application device in the trusted execution environment in response to both the first remote attestation and the second remote attestation being authenticated.

13. The method of claim 12, wherein the method further comprises: decrypting, by an application device in the trusted execution environment, the communication data based on a data decryption private key.

14. The method of claim 6, wherein the generating the data encryption public key and data decryption private key comprises:

obtaining a master key by a key management device in the trusted execution environment;

generating, by a key management device in the trusted execution environment, the data encryption public key and the data decryption private key based on the master key and the user identity public key.

15. A user terminal comprising one or more processors, wherein the one or more processors are configured to:

receiving, from a key management device in a trusted execution environment, a self-signed certificate, the self-signed certificate for auditing or verifying key management logic;

and verifying the self-signed certificate, and responding to the self-signed certificate passing verification, the user terminal applies a data encryption public key to a key management device in the trusted execution environment, wherein the data encryption public key is used for asymmetrically encrypting communication data.

16. A key management device in a trusted execution environment, the key management device in a trusted execution environment comprising one or more processors, wherein the one or more processors are configured to:

transmitting a self-signed certificate to a user terminal, the self-signed certificate being used for auditing or verifying key management logic;

receiving a data key request from the user terminal, and generating a data encryption public key and a data decryption private key;

and sending the data encryption public key to the user terminal.

17. An application device in a trusted execution environment, the application device in the trusted execution environment comprising one or more processors, wherein the one or more processors are configured to:

Receiving communication data from a user terminal, the communication data comprising an authorization credential and data encrypted with a data encryption key;

transmitting a first remote attestation to a key management device in the trusted execution environment and receiving a second remote attestation from the key management device in the trusted execution environment;

a data decryption private key is received from a key management device in the trusted execution environment in response to both the first remote attestation and the second remote attestation being authenticated.

18. An apparatus for processing data, comprising:

one or more processors; and

one or more memories having stored therein computer readable code which, when executed by the one or more processors, causes the one or more processors to perform the method of any of claims 1-14.

19. A computer readable storage medium having stored thereon computer readable instructions which, when executed by a processor, cause the processor to perform the method of any of claims 1-14.

20. A computer program product comprising computer readable instructions which, when executed by a processor, cause the processor to perform the method of any of claims 1-14.