Method and apparatus for processing data

Abstract

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

Description

Technical Field

[0001] This disclosure relates to the fields of Internet technology and computer data processing, and more specifically, to a method for processing data, a user terminal, a key management device in a trusted execution environment, an application device in a trusted execution environment, a data processing device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] With the continuous development of internet technology, people's lives have become inseparable from the internet. As the internet has penetrated every aspect of life, the security of network data transmission has become extremely important. To ensure the security of network data transmission, people often encrypt session data that needs to be transmitted over the internet. However, current encrypted data transmission systems still require a large amount of storage space to store encryption keys, and there is even a risk of key leakage. Furthermore, there is currently a lack of encrypted data transmission systems that can effectively balance security and ease of use. Therefore, it is necessary to improve existing encrypted data transmission systems. Summary of the Invention

[0003] To address the aforementioned problems, this disclosure provides a method for processing data, a user terminal, a key management device in a trusted execution environment, an application device in a trusted execution environment, a data processing device, a computer-readable storage medium, and a computer program product.

[0004] According to one aspect of the present disclosure, a method for processing data is provided, comprising: generating a self-signed certificate by a key management device in a trusted execution environment, the self-signed certificate being used for auditing or verifying key management logic; and verifying the self-signed certificate by a user terminal, and in response to the self-signed certificate passing verification, the user terminal applying to the key management device in the trusted execution environment for a data encryption public key, the data encryption public key being used for asymmetric encryption of communication data.

[0005] According to one aspect of the present disclosure, a user terminal is provided, the user terminal including one or more processors, wherein the one or more processors are configured to: receive a self-signed certificate from a key management device in a trusted execution environment, the self-signed certificate being used to audit or verify key management logic; verify the self-signed certificate; and in response to the self-signed certificate being verified, the user terminal requesting a data encryption public key from the key management device in the trusted execution environment, the data encryption public key being used to asymmetrically encrypt communication data.

[0006] According to one aspect of the present disclosure, a key management device in a trusted execution environment is provided. The key management device in the trusted execution environment includes one or more processors, wherein the one or more processors are configured to: send a self-signed certificate to a user terminal, the self-signed certificate being used to audit or verify key management logic; receive a data key request from the user terminal, generate a data encryption public key and a data decryption private key; and send the data encryption public key to the user terminal.

[0007] According to one aspect of the present disclosure, an application apparatus in a trusted execution environment is provided. The application apparatus in the trusted execution environment includes one or more processors, wherein the one or more processors are configured to: receive communication data from a user terminal, the communication data including authorization credentials and data encrypted with a data encryption key; send a first remote certificate to a key management device in the trusted execution environment and receive a second remote certificate from the key management device in the trusted execution environment; and receive a data decryption private key from the key management device in the trusted execution environment in response to both the first remote certificate and the second remote certificate being verified.

[0008] According to one aspect of the present disclosure, an apparatus for processing data is provided, comprising: one or more processors; and one or more memories, wherein the memories store computer-readable code that, when executed by the one or more processors, causes the one or more processors to perform the method as described above.

[0009] According to another aspect of the present disclosure, a computer-readable storage medium is provided that stores computer-readable instructions thereon, which, when executed by a processor, cause the processor to perform the method as described in any of the foregoing aspects of the present disclosure.

[0010] According to another aspect of the embodiments of the present disclosure, a computer program product is provided, which includes computer-readable instructions that, when executed by a processor, cause the processor to perform the method as described in any of the foregoing aspects of the present disclosure.

[0011] The above-mentioned aspects of this disclosure not only avoid the risk of key leakage, but also prevent users from dealing with complex trusted environments, thus improving the ease of use of the encrypted data transmission system. Attached Figure Description

[0012] The above and other objects, features, and advantages of the present disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0013] Figure 1 A schematic diagram of an application scenario according to an embodiment of this disclosure is shown.

[0014] Figure 2 A schematic diagram of a block structure according to an embodiment of the present disclosure is shown.

[0015] Figure 3 This diagram illustrates the sharing of keys between the TEE application and the user terminal.

[0016] Figure 4 This diagram illustrates the key negotiation between the TEE application and the user terminal.

[0017] Figure 5 An optional flowchart of a method for processing data according to an embodiment of this disclosure is shown.

[0018] Figure 6 An optional schematic diagram of a method for processing data according to an embodiment of this disclosure is shown.

[0019] Figure 7 An optional schematic diagram is shown of a user terminal requesting a data encryption public key from tKMS according to an embodiment of this disclosure.

[0020] Figure 8 Another optional schematic diagram of a method for processing data according to an embodiment of the present disclosure is shown.

[0021] Figure 9 A schematic diagram of an electronic device according to an embodiment of the present disclosure is shown.

[0022] Figure 10 A schematic diagram of the architecture of an exemplary computing device according to an embodiment of the present disclosure is shown.

[0023] Figure 11 A schematic diagram of a storage medium according to an embodiment of the present disclosure is shown. Detailed Implementation

[0024] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0025] Embodiments of this disclosure relate to cloud computing technology. Cloud computing is a computing model that distributes computing tasks (e.g., calculating user preferences for each of multiple options) across a resource pool consisting of a large number of computers, enabling various application systems to access computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." Resources in the "cloud" appear to users to be infinitely scalable, readily available, on-demand, expandable, and payable only for usage.

[0026] This disclosure provides a method for processing data, an apparatus for processing data, a computer-readable storage medium, and a computer program product.

[0027] First refer to Figure 1 This disclosure describes the application scenarios of data processing methods and corresponding apparatuses according to embodiments of the present disclosure. Figure 1 A schematic diagram of an application scenario 100 according to an embodiment of the present disclosure is shown.

[0028] The system disclosed herein can be a distributed system formed by connecting clients and multiple nodes (any form of computing device accessing the network, such as servers and user terminals) through network communication. The server here can be an independent server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, location services, and big data and artificial intelligence platforms. This disclosure does not impose specific limitations on this. The multiple user terminals here can be fixed terminals such as desktop computers, mobile terminals with network capabilities such as smartphones, tablets, portable computers, handheld devices, personal digital assistants, smart wearable devices, and vehicle terminals, or any combination thereof. This disclosure does not impose specific limitations on this.

[0029] The distributed system 100 provided in this disclosure can optionally be applied to a blockchain system. For example... Figure 1The diagram shows a peer-to-peer (P2P) network formed by multiple nodes. The P2P protocol is an application layer protocol that runs on top of the Transmission Control Protocol (TCP). In a distributed system, any machine, such as a server or terminal, can join and become a node. A node includes a hardware layer, a middleware layer, an operating system layer, and an application layer.

[0030] See Figure 1 The nodes shown may be involved in routing functions, which support communication between nodes. Each node may also be involved in various application functions. Taking blockchain application functions as an example, each node can implement specific business functions according to actual business needs, record data related to the implementation of the function to form record data, carry a digital signature in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system. When other nodes successfully verify the source and integrity of the record data, they add the record data to a temporary block.

[0031] Figure 1 The application functions of each node in the blockchain are associated with application services. For example, an application service could be a wallet service, which provides the function of conducting cryptocurrency transactions, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system; after successful verification by other nodes, the transaction record data is stored in a temporary block of the blockchain as a response acknowledging the validity of the transaction); of course, the wallet also supports querying the remaining cryptocurrency in the cryptocurrency address. Another example is a shared ledger service, which provides the functions of storing, querying, and modifying ledger data, sending the record data of operations on the ledger data to other nodes in the blockchain system, and after successful verification by other nodes, the record data is stored in a temporary block of the blockchain. A response acknowledging the validity of the ledger data stores the recorded data in a temporary block and can also send a confirmation to the node that initiated the operation. For example, application services can also be smart contract services, which implement computerized protocols to execute the terms of a contract. This is achieved through code deployed on a shared ledger that executes when certain conditions are met. Based on actual business needs, the code is used to automate transactions, such as querying the logistics status of goods purchased by a buyer and transferring the buyer's electronic funds to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions; they can also execute contracts for processing received information.

[0032] Of course, the nodes mentioned above can also be involved in operating the blockchain. A blockchain consists of a series of blocks linked together in chronological order of their creation. Once a new block is added to the blockchain, it cannot be removed. Each block records the data submitted by nodes within the blockchain system. See also... Figure 2 , Figure 2 This is an optional schematic diagram of the block structure provided in this embodiment. Each block includes the hash value of the transaction records stored in this block (the hash value of this block) and the hash value of the previous block. The blocks are connected through their hash values ​​to form a blockchain. Additionally, the block may include information such as a timestamp when it was generated. A blockchain is essentially a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains relevant information used to verify the validity of the information (anti-counterfeiting) and to generate the next block.

[0033] For example, Figure 1 The nodes shown can also be used for trusted computing. That is, the distributed system 100 can provide a hardware-supported trusted execution environment to protect the security of the computing process, data privacy, and the integrity and reliability of authentication data. Thus, each node in the distributed system 100 can optionally prevent the data and program logic within the trusted execution environment from being spied on by the external environment without active output.

[0034] For example, Figure 1 Each node shown may be a Trusted Computing (TC) node. A Trusted Computing node is a node device that contains a Trusted Execution Environment (TEE). A Trusted Computing node hosts one or more TEE applications, which can interact with the Rich Execution Environment (REE) on the user terminal. To ensure the security of TEE resources, the TEE can access resources that the REE can access, but unless explicitly authorized by the TEE, trusted resources on the TEE are only accessible to other trusted resources.

[0035] Currently, in some cases, TEE applications are already able to share keys with user terminals to enable user terminals to securely access data within the TEE environment. For example, ... Figure 3 As shown, a Key Management System (KMS) can be used to manage keys. For example, a user terminal can request a symmetric key from the KMS in advance. Then, the user terminal uses the symmetric key through the KMS to encrypt data and transmits the ciphertext to the TEE application. The TEE application obtains the session key through the KMS to decrypt the ciphertext and uses the plaintext in its application logic.

[0036] For example, such as Figure 4As shown, users can also negotiate keys with TEE applications. Before each data transmission, the user terminal and the TEE application execute a key exchange protocol to negotiate a one-time session key pair. The user terminal then encrypts the session data using the session encryption key and transmits the resulting ciphertext to the TEE application. The TEE application decrypts the ciphertext based on the session decryption key to restore the session data for subsequent calculations. Furthermore, if TEE applications need to communicate with each other, they also need to negotiate session key pairs.

[0037] However, Figure 3 and Figure 4 The solutions shown in the text fail to effectively balance security and ease of use. For example, in... Figure 3 In the KMS-managed key scheme shown, because the KMS management logic runs on a remote server, the user terminal cannot verify the confidentiality and integrity of the KMS in real time. If malware or backdoors exist in the KMS, there is a risk of leaking user keys. Furthermore, keys managed by KMS are typically not directly exportable. While this design is beneficial for improving the security of applications like those in REEs, it limits the flexibility of key usage for TEE applications. Moreover, KMS requires additional equipment, increasing costs. Figure 3 The KMS-managed key scheme shown is also not applicable to outsourced computation / multi-party computation.

[0038] For example, in Figure 4 In the real-time key negotiation scheme shown, each negotiation process requires the user terminal to verify the TEE application, which raises the barrier to entry. Furthermore, the pairwise negotiation scheme is not only inefficient and complex in terms of communication, but also prevents key reuse. The TEE application must exist before the key, making it impossible to pre-perform time-consuming data encryption offline.

[0039] Based on this, the embodiments disclosed herein can both avoid the risk of key leakage and reduce the processing of complex information (such as TEE measurement information) in the TEE by the user terminal. Furthermore, after the user terminal authorizes the data decryption private key, the data decryption private key can be securely distributed from the TEE-based KMS (hereinafter referred to as tKMS) to the TEE application for use.

[0040] For example, some embodiments of this disclosure enable user terminals to apply to tKMS for asymmetric encryption public keys and authorize corresponding decryption private keys for use by designated TEE applications. After the TEE application proves the legitimacy of its environment to tKMS using a remote authentication mechanism, it only needs to present user authorization credentials to obtain the corresponding data decryption private key for decrypting ciphertext. Compared to traditional KMS, tKMS can also derive data encryption keys in a hierarchical manner, saving storage space.

[0041] For example, some embodiments of this disclosure enable the secure circulation of data decryption private keys within the TEE environment after strict authorization, preventing disclosure to unrelated parties and mitigating the risk of leakage caused by the need for human custody of the data decryption private keys. Compared to traditional KMS, KMS implemented by TEE provides data privacy guarantees for outsourced computation / multi-party computation. Outsourced computation / multi-party computation can be used to solve the problem of privacy-preserving collaborative computation among a group of mutually distrustful participants. It can achieve input independence, computational correctness, and decentralization while ensuring that the input values ​​of each participant are not disclosed to other members participating in the computation. In other words, multi-party computation can be used to address the problem of how to securely compute an agreed-upon function without a trusted third party, while requiring that each participating entity cannot obtain any input information from other entities except for the computation result.

[0042] The following reference Figures 5 to 8 A method for processing data according to embodiments of this disclosure is described. For example, Figure 5 An optional flowchart of a method 50 for processing data according to an embodiment of the present disclosure is shown. Figure 6 An optional schematic diagram of a method 50 for processing data according to an embodiment of the present disclosure is shown. Figure 7 An optional schematic diagram is shown of a user terminal requesting a data encryption public key from tKMS according to an embodiment of this disclosure. Figure 8 Another alternative schematic diagram of a data processing method 50 according to an embodiment of the present disclosure is shown. Method 50 can be derived from reference... Figures 1 to 2 The distributed system 100 described is executed, but this disclosure is not limited thereto.

[0043] Combination Figure 6 The distributed system 100 includes a key management device in a trusted execution environment (which in... Figure 6 The components shown are tKMS, user terminals, and application devices in a trusted execution environment (which are shown in the context of tKMS). Figure 6 (This is shown as a TEE application). As an example, method 50 includes... Figure 5 Operations S510 and S520 are shown. Additionally, method 50 may optionally include operations S530 to S560. Of course, this disclosure is not limited thereto.

[0044] For example, combining Figure 5In operation S510, a self-signed certificate is generated by the key management device in the Trusted Execution Environment (TEE). This self-signed certificate is used to audit or verify the key management logic. In operation S520, the user terminal verifies the self-signed certificate. Upon successful verification, the user terminal requests a data encryption public key from the key management device in the TEE. This data encryption public key is used for asymmetric encryption of communication data.

[0045] For example, a trusted execution environment can be composed of trusted hardware and software resources such as processors, secure memory, trusted user interfaces (TUI), trusted operating systems (TOS), and trusted applications (TA) on terminal devices. These devices together construct a secure operating environment.

[0046] For example, in some embodiments of this disclosure, the aforementioned Trusted Execution Environments (TEEs) can all generate public-private key pairs for identifying the TEE using asymmetric encryption. During chip manufacturing, the private key of the TEE is written into the chip. No node other than the TEE can obtain this private key. The public key of the TEE, however, is public. Any file encrypted with the public key corresponding to the chip can only be decrypted using the private key within that chip. It should be noted that the private key in each chip is unique and immutable. Thus, in this operating environment isolated from the REE (e.g., the user terminal), user personal information can be stored and processed more securely, allowing users to confidently perform highly confidential operations such as electronic payments.

[0047] For example, a key management device (tKMS) in a trusted execution environment is a device capable of running key management logic within a trusted execution environment. The key management logic includes key generation, key distribution, key updating, and key storage by the agent user terminal, etc. This disclosure does not limit this. Compared to traditional key management devices that can only handle symmetric keys (e.g., Figure 3 In a Trusted Execution Environment (KMS), the key management device (tKMS) can not only handle asymmetric keys but also generate self-signed certificates. These self-signed certificates are used for auditing (e.g., public auditing) and verifying (e.g., runtime verification) the key management logic.

[0048] In some embodiments, the self-signed certificate is a trusted identity identifier for tKMS. Traditional KMS systems often cannot generate trusted identity identifiers. Even if a traditional KMS system can 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.

[0049] Optionally, the self-signed certificate is randomly generated when tKMS is first started or deployed. Simultaneously with generating the self-signed certificate, tKMS also generates a corresponding private key and public key. The private key and public key are referred to as the self-signed certificate private key and the self-signed certificate public key, respectively. The self-signed certificate private key and public key are used to verify the legitimacy of the self-signed certificate.

[0050] For example, in some embodiments of this disclosure, the signature information of the self-signed certificate is generated based on the private key of the self-signed certificate, and can be verified by the public key of the self-signed certificate. The process of generating the signature information of the self-signed certificate based on the private key of the self-signed certificate (also called the signing process) is also publicly auditable and verifiable in real time. Therefore, any node that needs to interact with tKMS can verify the legitimacy of the signature information of the self-signed certificate provided by tKMS. For example, a user terminal can use the public key of the self-signed certificate to verify the legitimacy of the signature information of the self-signed certificate.

[0051] In some embodiments of this disclosure, the private key of the self-signed certificate is sealed and stored locally, while the public key of the self-signed certificate is made public. "Sealed storage" refers to the act of saving encrypted data, such as hardware-derived keys (asymmetric or symmetric keys), locally. Specifically, the keys derived from tKMS with the same hardware and identical metric information are identical; changes in the hardware or metric information will result in different derived keys.

[0052] Optionally, when tKMS is first started or deployed, tKMS will also randomly generate a master key MK and store it locally in an encrypted form. Subsequently, if tKMS restarts, it can recover the same master key MK from the encrypted encrypted text, thus ensuring the continuity of services provided.

[0053] In some embodiments of this disclosure, optionally, the self-signed certificate further includes measurement information of the Trusted Execution Environment (tKMS), and the measurement information includes information about the self-signed certificate's public key. For example, the measurement information of the Trusted Execution Environment can be embedded in a certificate extension field. The information about the self-signed certificate's public key can be embedded in a custom field of the measurement information. Furthermore, in some examples of this disclosure, when generating a self-signed certificate, tKMS signs the measurement information including the self-signed certificate's public key based on the self-signed certificate's private key to ensure that the self-signed certificate is tamper-proof.

[0054] In some embodiments of this disclosure, the information of the self-signed certificate public key is, for example, the hash value corresponding to the self-signed certificate public key. The hash value corresponding to the self-signed certificate public key can be obtained by hashing the public key of the self-signed certificate using various types of hash algorithms, including but not limited to commonly used hash algorithms such as SM3 and SHA256. This disclosure is not limited thereto.

[0055] Optionally, the Trusted Execution Environment (TEE) metrics information (hereinafter referred to as TEE metrics information) serves as evidence to prove the correspondence between the tKMS and its code logic and runtime hardware environment. For example, the TEE metrics information may optionally include: the hash metrics of the application code logic, the hardware's signature of the code logic hash metrics (the signing private key is embedded in the hardware by the hardware manufacturer), the hardware manufacturer's signature of the hardware public key, and so on. If the hardware manufacturer's signature of the hardware public key can be verified by any node, it proves that the hardware originates from a legitimate hardware manufacturer. If the hardware's signature of the key management logic can be verified by any node, then that node can determine that the key management logic that the tKMS should execute is indeed running in the expected hardware environment, thus proving the integrity of the tKMS. The security of the tKMS is guaranteed by the TEE provided by the hardware. In some other examples, the metrics information also includes data determined based on the tKMS, such as intermediate data of the key exchange protocol. These intermediate data include, for example, public keys (e.g., the public key of the tKMS certificate, the public key of the TEE application certificate, or the public key of the user terminal) that are negotiated between tKMS and TEE applications, between tKMS and non-TEE applications, and between tKMS and user terminals. These public keys help to calculate session keys for encrypted communication between the two parties.

[0056] For example, Figure 1 Any node in the system can publicly audit tKMS's key management logic. Auditing tKMS's key management logic not only ensures that the corresponding software source code or any static file has not been tampered with, but also confirms that the software source code or any static file does not contain backdoors or vulnerabilities, thus ensuring that tKMS's key management logic does not leak user keys. For example, Figure 1 Any node in the system can also perform runtime verification (also known as real-time verification) of tKMS's key management logic. Runtime verification of tKMS's key management logic ensures that it executes the expected software source code. Malicious attackers might attempt to compromise the key management logic to cause it to run incorrect malicious code instead of the audited software source code. By performing runtime verification of tKMS's key management logic, it is guaranteed that every time a user terminal requests a key from tKMS, the key management logic executes the correct code to provide the correct and secure key.

[0057] For example, suppose there is an attack scenario where a malicious attacker uses tKMS' to impersonate tKMS in an attempt to defraud... Figure 1 any node or Figure 6 Trust in user terminals / TEE applications is crucial. For tKMS' to successfully impersonate tKMS, a malicious attacker needs to enable tKMS' to provide a forged certificate, and this forged certificate needs to be difficult for the user terminal / other nodes to distinguish from tKMS's self-signed certificate. To achieve this, the malicious attacker needs to construct a forged certificate that includes forged tKMS metrics, and this forged tKMS metrics includes the public key information of the forged tKMS' certificate.

[0058] However, according to the aforementioned certificate construction rules, the measurement information includes the public key information of tKMS's self-signed certificate. If a malicious attacker simply sets the public key corresponding to the forged certificate to tKMS's public key without changing the information of the self-signed certificate's public key embedded in the measurement information, the user terminal can easily identify that the public key of the forged certificate is different from the public key embedded in the measurement information. This allows them to easily verify that the forged certificate is illegitimate and avoid requesting a data encryption key from tKMS'.

[0059] If a malicious attacker sets the public key corresponding to a forged certificate to the public key of tKMS' and tampers with the public key information of tKMS embedded in the measurement information to the public key information of tKMS', then the malicious attacker must be able to generate the measurement information of tKMS. However, the hardware will only generate measurement information strongly associated with tKMS (any modification to the tKMS application will cause the measurement information to change). Forcibly replacing the public key information embedded in the measurement information will cause the measurement information to be unable to be correctly identified as tKMS measurement information. Furthermore, once the structure of the measurement information is damaged, signatures and other means that protect the structural integrity will fail to be verified. Therefore, a malicious attacker cannot forge a certificate that can be verified by the user terminal / TEE application based on the measurement information of tKMS and the public key of tKMS', thus failing to impersonate the identity of tKMS.

[0060] Optionally, in step 520, after the user terminal receives the self-signed certificate transmitted by tKMS, the user terminal can obtain the public key information of the self-signed certificate from the measurement information of the self-signed certificate. Then, the user terminal can determine the association between the self-signed certificate and tKMS (i.e., whether the self-signed certificate was necessarily generated by tKMS) by verifying whether the public key information in the self-signed certificate matches the public key of the self-signed certificate (this process is also called association verification). For example, if 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. If the public key information in the self-signed certificate does not match the public key of the self-signed certificate, then the self-signed certificate fails the association verification, and the self-signed certificate verification fails.

[0061] The user terminal then verifies the validity of the certificate signature. If the self-signed certificate passes both the association verification and the validity verification, the self-signed certificate is verified (i.e., the user terminal considers the self-signed certificate to be valid). Conversely, if the user terminal determines that the certificate signature is invalid (i.e., the user terminal considers the self-signed certificate to be invalid), the self-signed certificate verification also fails.

[0062] The above process is an example of the public auditing and runtime verification of tKMS by the user terminal. Of course, depending on the construction method of the self-signed certificate, the user terminal can also verify the legitimacy of the self-signed certificate in other ways, and this disclosure is not limited to this.

[0063] Next, after verifying the legitimacy of the self-signed certificate, the user terminal can determine that the measurement information in the self-signed certificate can only be generated by tKMS, and that only tKMS holds the private key of the self-signed certificate. Therefore, the user terminal can execute a key exchange protocol with tKMS based on this self-signed certificate to request a data encryption public key X from tKMS, which is used for asymmetric encryption of communication data. In some embodiments, this communication data is transmitted from the user terminal to the TEE application. Furthermore, the communication channel between the user terminal and tKMS is secure; third parties cannot obtain the session key, thus preventing them from knowing the communication data between the user terminal and tKMS, thereby ensuring that the data encryption public key X is not leaked.

[0064] For example, such as Figure 7As shown, the user terminal can request a data encryption public key from tKMS in the following manner. First, the user terminal will obtain an asymmetric key pair (y, Y) for user terminal authentication. Hereinafter, the public key Y used for user terminal authentication will be referred to as the user identity public key, and the private key y used for user terminal authentication will be referred to as the user identity private key. The user terminal may pre-compute the user identity public key and user identity private key, or the user terminal may randomly generate the user identity public key and user identity private key before key negotiation with tKMS. This disclosure does not restrict the method of obtaining the user identity public key and user identity private key.

[0065] Next, the user terminal negotiates a session key with tKMS based on its user identity public key Y and tKMS's certificate public key to determine the session key, thereby receiving the session key from tKMS, which then stores the session key. The session key is used only to encrypt information transmitted from the user terminal to tKMS, and only by tKMS to decrypt information from the user terminal. The key negotiation process can be based on various key exchange protocols. For example, the key negotiation process can be based on the DHE (Diffie-Hellman-Ephemeral) key exchange protocol. The DHE key exchange protocol is a secure protocol that allows both parties to negotiate a temporary session key over an insecure channel without any prior information about the other party. This key can be used as a symmetric key to encrypt session content in subsequent communications. Another example is the ECDHE key exchange protocol. The ECDHE key exchange protocol is a variant of the DHE key exchange protocol implemented based on elliptic curves, achieving the same effect.

[0066] After obtaining the session key, the user terminal will encrypt the data key request using the session key. The data key request includes the user's public key Y. Upon receiving the ciphertext encrypted with the session key, tKMS will decrypt the ciphertext using the session key to obtain the user's public key Y. Next, tKMS will determine the data decryption private key z using the master key MK generated in step 510 and the user's public key Y. For example, tKMS will concatenate the hash values ​​of the master key MK and the user's public key Y into a string "MK|Hash value of Y" (where "|" indicates string concatenation), and then determine the hash value of the string "MK|Hash value of Y" as the data decryption private key z.

[0067] In some embodiments of this disclosure, the data key request may optionally include an authorization count T. After receiving the ciphertext encrypted with the session key, the tKMS decrypts the ciphertext using the session key to obtain the user's public key Y and the authorization count limit T. The tKMS sets the authorized count T using the hash value of Y as the key. If T corresponding to Y already exists, the authorization count of Y is updated. If T is less than or equal to 0, it indicates that the user terminal wishes to revoke its key authorization license. For example, assuming the authorization count limit T included in the data key request is 5, and the tKMS determines during key negotiation that the authorization count limit corresponding to the user's public key Y is 2, then the tKMS will modify 2 to 5 according to the data key request. Assuming the authorization count limit T included in the data key request is -1, and the tKMS determines during key negotiation that the authorization count limit corresponding to the user's public key Y is 2, then the tKMS will modify the authorization count limit T from 2 to -1 according to the data key request, directly revoking or deleting the user's public key Y. At this point, if the TEE application requests the private key for decrypting encrypted data from the user terminal from tKMS, tKMS will refuse to provide it.

[0068] In some embodiments of this disclosure, the data key request may optionally include a random string (nonce) generated by the user terminal. After receiving the ciphertext encrypted with the session key, tKMS decrypts the ciphertext using the session key to obtain the user's public key Y, the maximum number of authorization attempts T, and the random string (nonce). Based on the random string (nonce), tKMS can 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.

[0069] After obtaining the data decryption private key z, tKMS 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. Thus, the user terminal successfully obtains the data encryption public key Z.

[0070] Return to reference Figure 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 sends the encrypted communication data to the TEE application. The aforementioned communication data also includes the user terminal's authorization to the TEE application to use the data decryption private key. Based on this authorization, the TEE application obtains the data decryption private key from tKMS and uses the data decryption private key to decrypt the communication data, thereby completing the calculations related to the communication data.

[0071] Next reference Figure 8The example process of a TEE application requesting a data decryption private key from tKMS is further described. Optionally, method 50 may also include operations S530 to S560. This disclosure is not limited thereto.

[0072] In operation S530, the user terminal sends communication data encrypted with a data encryption public key to an application device in the Trusted Execution Environment (TEE). Optionally, as described above, the TEE application receives communication data from the user terminal, which is encrypted with a data encryption public key and includes authorization credentials and data encrypted with a data encryption key X. Figure 8 In this context, data encrypted with the data encryption key X is displayed as ciphertext. For example, an authorization credential is a certificate used by the TEE application to prove to tKMS the legitimacy of its communication with the user terminal, instructing the TEE application that using the data decryption private key is legitimate.

[0073] As an example, the authorization credential includes: a user's public key Y, credential information M, and a signature Sig of the credential information M using the user's private key Y. The credential information M includes: measurement information of the application device in the Trusted Execution Environment (TEE), the hash value of the data to be calculated by the TEE application, and user-defined data. By including the measurement information of the application device (TEE application) in the credential information M, only the TEE application corresponding one-to-one with that measurement information is authorized to obtain the data decryption private key. The authorization credential may also include other information, which is not limited in this disclosure.

[0074] Next, in operation S540, the application device in the trusted execution environment sends a first remote certificate to the key management device in the trusted execution environment, and the key management device in the trusted execution environment sends a second remote certificate to the application device in the trusted execution environment.

[0075] For example, the application device in the Trusted Execution Environment (TEE) will provide a first remote proof to the key management device in the TEE. This first remote proof enables the TEE application to prove the legitimacy of its operating environment hardware to a third party (e.g., tKMS). If the third party challenges the TEE application, the TEE application can send a set of information, including a hash measure of its own code logic, sign it, and return it to the third party for authentication. If the authentication is successful, the remote proof is complete. Similarly, the key management device in the TEE will also provide a second remote proof to the application device in the TEE. The process of the TEE application and tKMS providing remote proofs to each other is described in... Figure 8 This process is described as a two-way remote verification process. After the two-way remote verification process, both the TEE application and tKMS confirm the other's legitimacy.

[0076] In some embodiments of this disclosure, the first remote authentication also includes authorization credentials. In this case, tKMS, in addition to verifying the metric information carrying the TEE application (e.g., the hash metric containing its own code logic mentioned above), can also verify the authorization count T corresponding to the user's public key Y. For example, tKMS uses the user's public key Y as the key to look up the corresponding authorization count T. If the metric information is valid and the authorization count T is greater than zero, tKMS can confirm that the user's public key Y in the authorization credentials is still valid. At this time, tKMS will decrement the authorization count T by one and determine that the TEE application has the right to use the data decryption private key z. If the authorization count T is less than or equal to zero, tKMS can confirm that the user's public key Y in the authorization credentials is invalid, requiring the user terminal to reapply for a data encryption public key and update the authorization count T.

[0077] In some embodiments of this disclosure, in addition to verifying the aforementioned measurement information of the TEE application and the authorization count T corresponding to the user identity public key Y, tKMS also uses the user identity public key Y to verify the legality of the signature Sig in the authorization credential. In response to the validity of the measurement information, the authorization count T being greater than zero, and the signature Sig being valid, tKMS will decrement the authorization count T by one and determine that the TEE application is authorized to use data to decrypt the private key z. Furthermore, tKMS consistently determines that the TEE application is not authorized to use data to decrypt the private key z.

[0078] Next, in operation S550, in response to the successful verification of both the first and second remote authentications, the key management device in the Trusted Execution Environment (TEE) sends a data decryption private key to the application device in the TEE. For example, this data decryption private key is used to decrypt the communication data. For instance, this data decryption private key z is used to decrypt ciphertext sent by the user device to the TEE application.

[0079] It is worth noting that during the operation of S540 and S550, communication information between tKMS and TEE applications can be sent and received through a secure channel, thus ensuring the security of communication between tKMS and TEE applications. All data communicated through the secure channel is encrypted.

[0080] In operation S560, the application device in the trusted execution environment decrypts the communication data based on the data decryption private key.

[0081] As an example, Method 50 can be applied to trusted computation of a patient's Electronic Health Record (EHR), the result of which may be, for example, the patient's medical condition information. Due to the rapid development of the healthcare industry and the rapid increase in healthcare data, many medical institutions have adopted electronic health records to record patient medical data. Because EHR data is complex, including images from imaging studies, written records of doctor's consultations, prescription information, and so on, predicting a patient's condition from the EHR is very complex and involves a large amount of computation. Typically, the computing power of a patient's user terminal is often limited. Therefore, patients need a remote trusted application to assist in the prediction of their condition.

[0082] At this point, the patient's user terminal will request a data encryption public key Z from the already deployed tKMS, and then use this data encryption public key Z to encrypt the user's private electronic medical records (including images generated by imaging, text records of doctor's consultations, prescription information, etc.) to form ciphertext.

[0083] The patient's user terminal sends the encrypted data and authorization credentials to the TEE application. The TEE application uses these authorization credentials to request access to the data decryption private key z from tKMS. After the TEE application successfully decrypts the encrypted data, it analyzes the electronic medical record based on a neural network to determine the patient's medical information, thus ensuring that the patient's medical information is not leaked.

[0084] For example, TEE applications can use neural network models to generate health scores from EHR data provided by users in their communication data through machine learning. With the development of machine learning, various neural network models can be used to accomplish the aforementioned machine learning tasks, such as deep neural network (DNN) models, factorization machine (FM) models, and so on. These neural network models can be implemented as acyclic graphs, where neurons are arranged in different layers. Typically, a neural network model includes an input layer and an output layer, separated by at least one hidden layer. The hidden layer transforms the input received by the input layer into a representation useful for generating the output in the output layer. 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 the nodes of the input layer of the neural network is propagated to the nodes of the output layer via any of the hidden layers, activation layers, pooling layers, convolutional layers, etc. The input and output of the neural network model can take various forms, and this disclosure does not limit this. Processing highly private and valuable data such as medical and health data (e.g., EHR data) in TEE applications helps protect the privacy of user terminals.

[0085] The above embodiments of this disclosure combine a trusted execution environment with key management logic, which enables the key generation process to be auditable and verifiable, and also ensures that only user-authorized TEE applications can use the key. Compared with existing solutions, this reduces the risk of key leakage and also reduces the user's burden.

[0086] Compared to traditional solutions, the various embodiments of this disclosure may also optionally have at least one of the following advantages.

[0087] ① The embodiments of this disclosure utilize a TEE to harden the key management device to generate tKMS, ensuring that the key management logic is publicly auditable and verifiable at runtime, without relying on any third party other than the hardware manufacturer. tKMS can securely host the data decryption private key. The source code of tKMS is audited by a third party (e.g., user terminal) before being put into operation, and its operation status does not disclose any key information.

[0088] ② The embodiments disclosed herein do not pose a risk of leaking the data decryption private key. User terminals can only obtain the data encryption public key to encrypt data; they cannot access the data decryption private key within tKMS. Therefore, the problem of data decryption private key leakage at the user terminal is avoided.

[0089] ③ The key authorization process of the various embodiments of this disclosure is simple and efficient. The TEE remote verification process only needs to occur infrequently (once or a few times) between the user terminal and tKMS, so that the user terminal does not need to repeatedly verify the TEE application performing the calculation, simplifying the user process.

[0090] ④ The data decryption private key transfer process in the various embodiments of this disclosure is secure and controllable. tKMS and TEE applications strictly implement a two-way remote authentication mechanism, rigorously verifying the legitimacy of each other's TEEs. tKMS only issues the data decryption private key after ensuring the TEE application's authorization is legitimate, ensuring that the data decryption private key will not be transferred to unrelated TEE applications or other devices, thus guaranteeing the security of the data decryption private key.

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

[0092] ⑥ The number of times the key can be used in the various embodiments of this disclosure is controllable. The user terminal can set or update the upper limit of the number of times the data decryption private key can be authorized for use, so that it is frozen when the number of uses exceeds the upper limit or unfrozen when the upper limit is lower than the number of uses.

[0093] According to another aspect of this disclosure, a user terminal is also provided, the user terminal including one or more processors, wherein the one or more processors are configured to: receive a self-signed certificate from a key management device in a trusted execution environment, the self-signed certificate being used for auditing or verifying key management logic; verify the self-signed certificate; and, in response to the self-signed certificate being verified, request a data encryption public key from the key management device in the trusted execution environment, the data encryption public key being used for asymmetric encryption of communication data. Optionally, the one or more processors of the user terminal are further configured to: send communication data to an application device in the trusted execution environment, the communication data including authorization credentials and data encrypted with the data encryption key. This disclosure has been referenced. Figures 5 to 8 The various operations on the user terminal are described in detail, so I will not repeat them here.

[0094] According to another aspect of this disclosure, a key management device in a trusted execution environment is also provided. The key management device in the trusted execution environment includes one or more processors, wherein the one or more processors are configured to: send a self-signed certificate to a user terminal, the self-signed certificate being used to audit or verify key management logic; receive a data key request from the user terminal; generate a data encryption public key and a data decryption private key; and send the data encryption public key to the user terminal. Optionally, the processors of the key management device in the trusted execution environment are further configured to: receive a first remote certificate from an application device in the trusted execution environment and send a second remote certificate to the application device in the trusted execution environment; and, in response to both the first and second remote certificates being verified, send the data decryption private key to the application device in the trusted execution environment. This disclosure has been referenced. Figures 5 to 8 The various operations of the key management device in the trusted execution environment are described in detail, and will not be repeated here.

[0095] According to another aspect of this disclosure, an application apparatus in a trusted execution environment (TEE) is also provided. The TEE includes one or more processors, wherein the processors are configured to: receive communication data from a user terminal, the communication data including authorization credentials and data encrypted with a data encryption key; send a first remote certificate to a key management device in the TEE and receive a second remote certificate from the key management device in the TEE; and, in response to both the first and second remote certificates being verified, receive a data decryption private key from the key management device in the TEE. Optionally, the processors of the TEE are further configured to: decrypt the communication data based on the data decryption private key. This disclosure has been referenced. Figures 5 to 8 The detailed description of each operation of the application device in the trusted execution environment will not be repeated here.

[0096] According to another aspect of this disclosure, an apparatus for processing data is also provided for implementing the method according to embodiments of this disclosure. Figure 9 A schematic diagram of an electronic device 2000 according to an embodiment of the present disclosure is shown.

[0097] like Figure 9 As shown, the electronic device 2000 may include one or more processors 2010 and one or more memories 2020. The memories 2020 store computer-readable code that, when executed by the one or more processors 2010, can perform the methods described above.

[0098] The processor in this disclosure embodiment can be an integrated circuit chip with signal processing capabilities. The processor can 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 devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, operations, and logic block diagrams disclosed in this disclosure embodiment. The general-purpose processor can be a microprocessor or any conventional processor, and can be based on an x86 architecture or an ARM architecture.

[0099] In general, the various exemplary embodiments of this disclosure can be implemented in hardware or dedicated circuitry, software, firmware, logic, or any combination thereof. Some aspects can be implemented in hardware, while others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device. When aspects of embodiments of this disclosure are illustrated or described as block diagrams, flowcharts, or using some other graphical representation, it will be understood that the blocks, apparatuses, systems, techniques, or methods described herein can be implemented as non-limiting examples in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0100] For example, the method or apparatus according to embodiments of this disclosure can also be used by means of Figure 10 The architecture of the computing device 3000 shown is used for implementation. For example... Figure 10As shown, the 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, etc. The storage devices in the computing device 3000, such as the ROM 3030 or the hard disk 3070, may store various data or files used for processing and / or communication of the methods provided in this disclosure, as well as program instructions executed by the CPU. The computing device 3000 may also include a user interface 3080. Of course, Figure 10 The architecture shown is merely exemplary and can be omitted as needed when implementing different devices. Figure 10 One or more components in the computing device shown.

[0101] According to another aspect of this disclosure, a computer-readable storage medium is also provided. Figure 11 A schematic diagram of a storage medium 4000 according to the present disclosure is shown.

[0102] like Figure 11 As shown, the computer storage medium 4020 stores computer-readable instructions 4010. When the computer-readable instructions 4010 are executed by a processor, the method described with reference to the above figures according to embodiments of the present disclosure can be performed. The computer-readable storage medium in the embodiments of the present disclosure may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. 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 may be random access memory (RAM), which is used as an external cache. By way of example, but 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 (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct memory bus random access memory (DR RAM). It should be noted that the memory used in the methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0103] This disclosure also provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform a method according to an embodiment of this disclosure.

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

[0105] In general, the various exemplary embodiments of this disclosure can be implemented in hardware or dedicated circuitry, software, firmware, logic, or any combination thereof. Some aspects can be implemented in hardware, while others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device. When aspects of embodiments of this disclosure are illustrated or described as block diagrams, flowcharts, or using some other graphical representation, it will be understood that the blocks, apparatuses, systems, techniques, or methods described herein can be implemented as non-limiting examples in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0106] The exemplary embodiments of this disclosure described in detail above are merely illustrative and not restrictive. Those skilled in the art will understand that various modifications and combinations of these embodiments or their features can be made without departing from the principles and spirit of this disclosure, and such modifications should fall within the scope of this disclosure.

Claims

1. A method for processing data, comprising: A self-signed certificate is generated by a key management device in a trusted execution environment, and the self-signed certificate is used to audit or verify the key management logic; as well as The user terminal verifies the self-signed certificate, and in response to the self-signed certificate being verified, the user terminal requests a data encryption public key from the key management device in the trusted execution environment. The data encryption public key is used to encrypt communication data asymmetrically. The user terminal sends communication data encrypted with the data encryption public key to the application device in the trusted execution environment, and the communication data includes authorization credentials; An application device in the trusted execution environment sends a first remote certificate to a key management device in the trusted execution environment, and the key management device in the trusted execution environment sends a second remote certificate to the application device in the trusted execution environment. The first remote certificate includes the authorization credential, which is a credential used by the application device in the trusted execution environment to prove the legitimacy of its communication with the user terminal to the key management device in the trusted execution environment. In response to the successful verification of both the first and second remote proofs, the key management device in the trusted execution environment sends the data decryption private key to the application device in the trusted execution environment.

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

3. The method as described in claim 2, wherein, The self-signed certificate includes signature information generated based on the self-signed certificate's private key.

4. The method of claim 2, wherein, The verification of the self-signed certificate by the user terminal includes: The user terminal obtains the public key information of the self-signed certificate from the measurement information of the self-signed certificate; If the public key information of the self-signed certificate matches the public key of the self-signed certificate, then the self-signed certificate passes the association verification. If the public key information of the self-signed certificate does not match the public key of the self-signed certificate, the self-signed certificate association verification fails.

5. The method of claim 1, wherein, The user terminal requests a data encryption public key from the key management device in the trusted execution environment, including: The user terminal obtains an asymmetric key pair for user terminal authentication, the asymmetric key pair including a user identity public key and a user identity private key; Based on the user's public key and the public key of the self-signed certificate, the user terminal negotiates a session key with the key management device in the trusted execution environment; and Based on the session key, the user terminal requests a data encryption public key from the key management device in the trusted execution environment.

6. The method of claim 5, wherein, The step of the user terminal requesting a data encryption public key from the key management device in the trusted execution environment based on the session key includes: The user terminal uses the session key to encrypt the data key request; The user terminal sends an encrypted data key request to the key management device in the trusted execution environment; The key management device in the trusted execution environment generates the data encryption public key and the data decryption private key based on the encrypted data key request; The key management device in the trusted execution environment sends the data encryption public key to the user terminal.

7. The method of claim 6, wherein, The data key request includes a user identity public key, or the data key request includes a combination of the user identity public key and one or more of the following: the number of authorizations and a random string generated by the user terminal.

8. The method of claim 1, wherein, The communication data includes data encrypted with a data encryption key.

9. The method of claim 8, wherein, The authorization credentials include at least: the user's public key, credential information, and a signature of the credential information using the user's private key.

10. The method of claim 9, wherein, The credential information includes at least one of the following: measurement information corresponding to the application device in the trusted execution environment, hash value of data to be calculated by the application device in the trusted execution environment, and user-defined data.

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

12. The method of claim 6, wherein, The generation of the data encryption public key and data decryption private key includes: The master key is obtained from the key management device in the trusted execution environment; The key management device in the trusted execution environment generates the data encryption public key and the data decryption private key based on the master key and the user identity public key.

13. A user terminal, the user terminal comprising one or more processors, wherein the one or more processors are configured to: Receive a self-signed certificate from the key management device in the trusted execution environment, the self-signed certificate being used to audit or verify the key management logic; The self-signed certificate is verified, and in response to the self-signed certificate being verified, the user terminal requests a data encryption public key from the key management device in the trusted execution environment. The data encryption public key is used to encrypt communication data asymmetrically. The application device in the trusted execution environment sends communication data encrypted with the data encryption public key, the communication data including authorization credentials, to enable: the application device in the trusted execution environment to send a first remote certificate to the key management device in the trusted execution environment, and the key management device in the trusted execution environment to send a second remote certificate to the application device in the trusted execution environment, wherein... The first remote proof includes the authorization credential, which is a credential used by the application device in the trusted execution environment to prove the legitimacy of its communication with the user terminal to the key management device in the trusted execution environment; in response to the successful verification of both the first and second remote proofs, the key management device in the trusted execution environment sends a data decryption private key to the application device in the trusted execution environment.

14. 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: A self-signed certificate is sent to a user terminal so that the user terminal can verify the self-signed certificate, which is used to audit or verify the key management logic. The user terminal receives a data key request and generates a data encryption public key and a data decryption private key. The data key request is sent by the user terminal in response to the self-signed certificate being verified. The system sends the data encryption public key to the user terminal. This public key is used to asymmetrically encrypt communication data, enabling the user terminal to send communication data encrypted with the public key to an application device in the trusted execution environment (TEER). The communication data includes authorization credentials. The application device in the TEEER sends a first remote certificate to a key management device in the TEEER, and the key management device in the TEEER sends a second remote certificate to the application device in the TEEER. The first remote certificate includes the authorization credentials, which are credentials used by the application device in the TEEER to prove the legitimacy of its communication with the user terminal to the key management device in the TEEER. In response to the successful verification of both the first and second remote proofs, a data decryption private key is sent to the application device in the trusted execution environment.

15. An application apparatus in a trusted execution environment, the application apparatus in the trusted execution environment comprising one or more processors, wherein the one or more processors are configured to: The user terminal receives communication data asymmetrically encrypted using a data encryption public key. The communication data includes authorization credentials and data encrypted using a data encryption key. The data encryption public key is obtained by the user terminal from the key management device in the trusted execution environment after the user terminal verifies the self-signed certificate. The self-signed certificate is generated by the key management device in the trusted execution environment and is used to audit or verify the key management logic. Sending a first remote certificate to the key management device in the trusted execution environment and receiving a second remote certificate from the key management device in the trusted execution environment, wherein the first remote certificate includes the authorization credential, which is a credential used by the application device in the trusted execution environment to prove the legitimacy of its communication with the user terminal to the key management device in the trusted execution environment; In response to the successful verification of both the first and second remote proofs, the private key for data decryption is received from the key management device in the trusted execution environment.

16. An apparatus for processing data, comprising: One or more processors; as well as One or more memories, wherein computer-readable code is stored in the memories, which, when executed by the one or more processors, causes the one or more processors to perform the method as described in any one of claims 1-12.

17. A computer-readable storage medium having stored thereon computer-readable instructions, which, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-12.

18. A computer program product comprising computer-readable instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-12.

Images