CN115795238A - Method for performing privacy calculations - Google Patents

Abstract

The present disclosure relates to a method of performing privacy calculations, comprising: causing the TAPP to run in the one or more TEEs; in response to the TAPP being to invoke a first trusted library function of the plurality of trusted library functions, initiating a challenge to the first trusted library function to obtain a remote attestation report and a public key of the first trusted library function; comparing the first metric value with the second metric value, in response to the first metric value being consistent with the second metric value, encrypting the call request of the first trusted library function by using the public key of the first trusted library function, and sending the encrypted call request and the public key of the software module to the first trusted library function; receiving, from the first trusted library function, a function return encrypted with the public key of the software module; and returning the execution result of the first trusted library function to the TAPP in response to the verification of the signature of the first trusted library function and the hash value of the call request. The disclosure also relates to non-transitory computer-readable storage media and computing devices.

Description

Method for performing privacy calculations

Technical Field

The embodiment of the disclosure belongs to the technical field of computers, and particularly relates to a method for privacy calculation.

Background

Cloud computing, big data and artificial intelligence all need to process massive data. How to ensure the security of data and the privacy of users is a considerable issue. Privacy Computing, or Confidential Computing, may be used to solve this problem. The privacy calculation utilizes a Trusted Execution Environment (TEE) technology to keep data always in an encrypted and strongly isolated state, thereby ensuring the safety and privacy of user data. The privacy computing can solve the trust problem in many application scenarios, such as data fusion and joint analysis among multiple untrusted organizations, confidentiality protection of intelligent contracts on a block chain, defense of public cloud platforms against external or internal attacks, security protection of highly sensitive information (such as cryptographic materials, medical archives, etc.), and the like.

Disclosure of Invention

It is an object of the present disclosure to provide a method, non-transitory computer-readable storage medium and computing device for performing privacy calculations.

According to a first aspect of the present disclosure, there is provided a method of performing a privacy computation performed by a trusted application TAPP deployed in one or more trusted execution environments TEE, the TEE or TEEs also having a plurality of trusted library functions deployed therein, each of the plurality of trusted library functions providing a call interface and a first metric value externally, the method comprising the steps performed by a software module of: causing the TAPP to run in the one or more TEEs; in response to a TAPP being to invoke a first trusted library function of the plurality of trusted library functions, initiating a challenge to the first trusted library function to obtain a remote attestation report and a public key for the first trusted library function, the remote attestation report for the first trusted library function including a second metric value for the first trusted library function; comparing the first metric value and the second metric value, in response to the first metric value and the second metric value being consistent, encrypting a call request to the first trusted library function with a public key of the first trusted library function, and sending the encrypted call request and the public key of the software module to the first trusted library function; receiving a function return encrypted with a public key of the software module from the first trusted library function, the function return including an execution result of the first trusted library function, a signature of the first trusted library function, and a hash value of a call request; and responding to the verification of the signature of the first trusted library function and the hash value of the calling request, and returning the execution result of the first trusted library function to the TAPP.

According to a second aspect of the present disclosure, there is provided a method of performing privacy calculations performed by a trusted application TAPP running in one or more trusted execution environments TEE, the TAPP being based on at least a first trusted library function of a plurality of trusted library functions deployed in the TEE, the method comprising the following steps performed by software modules associated with the plurality of trusted library functions: providing a calling interface and a first metric value of each of the plurality of trusted library functions outward; in response to receiving a challenge to the first trusted library function from the TAPP, sending a remote attestation report of the first trusted library function and a public key to the TAPP, the remote attestation report of the first trusted library function including a second metric value for the first trusted library function; receiving a public key from the TAPP and a call request for the first trusted library function, decrypting the call request by using a private key of the first trusted library function, and executing the first trusted library function according to the call request; and encrypting a function return of the first trusted library function with a public key from the TAPP, and sending the encrypted function return to the TAPP, wherein the function return comprises an execution result of the first trusted library function, a signature of the first trusted library function, and a hash value of the call request.

According to a third aspect of the present disclosure, there is provided a method of performing privacy computations performed by a trusted application TAPP deployed in one or more trusted execution environments TEE, the one or more TEEs also having a plurality of trusted library functions deployed therein, and the one or more TEEs having a first software module associated with the TAPP and a second software module associated with the plurality of trusted library functions running therein, the method comprising: the second software module providing a call interface and a first metric value of each trusted library function of the plurality of trusted library functions externally; the first software module causes a TAPP to run in the one or more TEEs; in response to a TAPP about to invoke a first trusted library function of the plurality of trusted library functions, the first software module sending a challenge to the first trusted library function to the second software module to perform a remote attestation process; in response to receiving a challenge to the first trusted library function from the first software module, the second software module sending a remote attestation report of the first trusted library function and a public key to the first software module, the remote attestation report of the first trusted library function including a second metric value for the first trusted library function; the first software module comparing the first metric value and the second metric value, in response to the first metric value and the second metric value being consistent, the first software module encrypting a call request to the first trusted library function with a public key of the first trusted library function and sending the encrypted call request and the public key of the first software module to the second software module; the second software module receives the public key of the first software module and the call request of the first trusted library function, decrypts the call request by using the private key of the first trusted library function, and executes the first trusted library function according to the call request; the second software module encrypts a function return of the first trusted library function by using the public key of the first software module and sends the encrypted function return to the first software module, wherein the function return comprises an execution result of the first trusted library function, a signature of the first trusted library function and a hash value of a call request; and the first software module receives a function return from the second software module, and in response to the verification of the signature of the first trusted library function and the hash value of the call request passing, the first software module returns the execution result of the first trusted library function to the TAPP.

According to a fourth aspect of the present disclosure, there is provided a non-transitory computer-readable storage medium having stored thereon a series of computer-executable instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform a method as described above.

According to a fifth aspect of the present disclosure, there is provided a computing device comprising one or more processors and one or more memories configured to store a series of computer executable instructions, wherein the series of computer executable instructions, when executed by the one or more processors, cause the one or more processors to perform the method as described above.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings required to be used in the description of the embodiments are briefly introduced below, it is obvious that the drawings in the description below are only some embodiments described in the present disclosure, and for those skilled in the art, other drawings may be obtained according to the drawings without inventive labor.

FIG. 1 is a schematic diagram of a hardware environment in which a method of performing privacy computations may be implemented in accordance with an embodiment of the present disclosure;

FIG. 2 is a schematic diagram of a software environment in which a method of performing privacy calculations may be implemented in accordance with an embodiment of the present disclosure;

FIG. 3 is a schematic illustration of at least a partial flow of a method of performing privacy calculations in accordance with an embodiment of the present disclosure;

FIG. 4 is a schematic diagram of a function call and data access of a method of performing privacy calculations according to an embodiment of the present disclosure;

FIG. 5 is a schematic illustration of a verification process of a method of performing privacy calculations according to an embodiment of the present disclosure;

FIG. 6 is a schematic diagram of an operational flow of an Intel SGX application according to an embodiment of the present disclosure;

fig. 7 is a schematic diagram of a down-link node of a blockchain network including TEEs in accordance with an embodiment of the present disclosure;

fig. 8 is a schematic structural diagram of at least a portion of a computing device according to an embodiment of the present disclosure.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present disclosure, 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, and it is obvious that the described embodiments are only a part of the embodiments of the present disclosure, and not all of the embodiments. It should be understood, however, that one or more embodiments of the present disclosure may be presented in a number of different ways and are not limited to the embodiments described below. It should also be understood that one or more embodiments of the present disclosure can be combined in various ways to provide further additional embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments disclosed herein without making any creative effort, shall fall within the protection scope of the present disclosure.

It is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. All terms (including technical and scientific terms) used herein have the meaning commonly understood by one of ordinary skill in the art unless otherwise defined. Well-known functions or constructions may not be described in detail for brevity and/or clarity.

In this document, the term "connected" is intended to encompass a physical, electrical, and/or communicative connection of one feature to another, and may or may not have intervening features between them. When the connection is a communication connection, even though reference is made to a and B as being "directly connected," it is intended to emphasize that there is no feature or features emphasized by one or more embodiments of the present disclosure between the connection of a and B, but does not represent a limitation that the connection between a and B is not through any element, and those skilled in the art will understand that the connection between a and B may be through a cable, a router, a gateway, a channel, a link, a network, and the like. It should be noted that in the drawings of one or more embodiments of the present disclosure, a direct connection or an indirect connection between a and B is represented by a straight line or other graphic element connected between a and B.

Herein, the term "a or B" includes "a and B" and "a or B" rather than exclusively including "a" or "B" only, unless specifically stated otherwise.

In this document, the term "exemplary" means "serving as an example, instance, or illustration," and not as a "model" that is to be reproduced exactly. Any implementation exemplarily described herein is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, brief summary or the following detailed description.

In this document, the term "substantially" is intended to encompass any minor variations due to design or manufacturing imperfections, tolerances of the devices or components, environmental influences and/or other factors. The term "substantially" also allows for differences from a perfect or ideal situation due to parasitics, noise, and other practical considerations that may exist in a practical implementation.

In addition, "first," "second," and like terms may also be used herein for reference purposes only, and thus are not intended to be limiting. For example, the terms "first," "second," and other such numerical terms referring to structures or elements do not imply a sequence or order unless clearly indicated by the context.

It will be further understood that the terms "comprises/comprising," "includes" and/or "including," when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should be noted that: in other embodiments, the steps of the respective methods are not necessarily performed in the order shown and described in the present disclosure. In some other embodiments, the method may include more or fewer steps than those described in the present disclosure. Moreover, a single step described in this disclosure may be broken down into multiple steps for description in other embodiments; while multiple steps described in this disclosure may be combined into a single step for description in other embodiments.

FIG. 1 is a schematic diagram of a hardware environment in which a method of performing privacy computations may be implemented according to an embodiment of the present disclosure. In some embodiments, a hardware environment for implementing a method of performing private computations includes one or more computing nodes (shown as n in fig. 1), each having a trusted execution environment TEE to support private computations. Where multiple computing nodes are included, the multiple computing nodes may provide private computing services as a computing cluster, in which case the hardware environment may also include a control node. The control node may be used for communication between the computing cluster and the outside world, such as forwarding of messages and data, and may also be used for load balancing among the computing nodes, and the like.

In some embodiments, one or more of the compute nodes may be compute nodes in a blockchain network, also referred to as "on-chain nodes. A trusted application TAPP for performing privacy calculations, such as smart contracts for privacy transactions, may be deployed into the TEE of the on-chain node to perform privacy calculations by invoking the TAPP.

In some embodiments, one or more compute nodes may not be an on-chain node, referred to as a "down-chain node". One or more of the downlinked nodes can be independent of the blockchain network, e.g., the control node communicates directly with the client to receive requests for privacy calculations, return results of privacy calculations, etc. One or more of the downlink nodes may also be associated with a blockchain network, as shown in fig. 7. Each of the one or more down-link nodes may be connected to an on-link node in at least one blockchain network to receive computation requests from the on-link node. When a plurality of nodes under the chain form a cluster, the nodes on the chain can be connected through the control node. The control node may be responsible for message forwarding between the on-chain nodes and the off-chain nodes. It should be appreciated that the downlinked nodes do not require a consensus process between node devices, and thus, each downlinked node can perform a respective computing task and the control node can schedule computing resources among the plurality of downlinked nodes. The blockchain network may send a transaction request to the down-chain nodes, e.g. as shown in fig. 7, the control node receives a transaction request from the up-chain node 4, which may be e.g. a request to invoke a TAPP for privacy calculations that has been deployed into the down-chain node. In response to a request by the blockchain network, the down-chain node runs the TAPP in the TEE, performing privacy calculations, and returns the calculation results to the blockchain network, e.g. via a control node to the up-chain node 4. The returned calculation result can be stored in the block chain network.

TEE is a CPU hardware based security extension and is completely isolated from the outside. TEE was originally proposed by Global Platform to address the secure isolation of resources on mobile devices, providing a trusted and secure execution environment for applications parallel to the operating system. An application running in a TEE may be referred to as a Trusted APP (TAPP). As technology has evolved, TEEs have become more generalized TEEs than the concepts originally presented. For example, server chip vendors Intel, AMD, and others have introduced hardware-assisted TEE in tandem and enriched TEE concepts and features. The mention of TEE now is more generally directed to such hardware assisted TEE techniques. Unlike the mobile side, the cloud access requires remote access, and the end user is not visible to the hardware platform, so the first step of using the TEE is to confirm the authenticity and credibility of the TEE. Therefore, the existing TEE technology introduces a remote attestation mechanism which is endorsed by a hardware vendor (mainly a CPU vendor) and ensures that a user can verify the TEE state through a digital signature technology. Meanwhile, the security requirement which cannot be met by only the security resource isolation is also met, and further data privacy protection is also provided. Commercial TEE including Intel SGX, AMD SEV also provide memory encryption techniques, limiting trusted hardware within the CPU, with the data of the bus and memory being ciphertext to prevent snooping by malicious users. For example, TEE technology such as Intel's software protection extensions (SGX) isolates code execution, remote attestation, secure configuration, secure storage of data, and trusted paths for executing code. Applications running in the TEE are secured and are almost impossible to access by third parties.

Taking Intel SGX as an example, SGX provides an enclosure (also called enclave), that is, an encrypted trusted execution area in a memory, and a CPU protects data from being stolen. Taking a CPU supporting SGX as an example, a part of an EPC (enclosure Page Cache, enclave Page Cache, or Enclave Page Cache) may be allocated in a Memory by using a newly added processor instruction, and data therein is encrypted by an Encryption Engine MEE (Memory Encryption Engine) in the CPU. The encrypted content in the EPC is decrypted into plaintext only after entering the CPU. In practical application, the private data can be encrypted and then transmitted to the enclosure in a ciphertext mode, and the corresponding secret key is transmitted to the enclosure through the remote certification. Then, the operation is performed using the data under the encryption protection of the CPU, and the result is returned in the form of a ciphertext, as shown in fig. 6.

FIG. 2 is a schematic diagram of a software environment in which a method of performing privacy calculations may be implemented in accordance with an embodiment of the present disclosure. The privacy calculations may be performed by one or more taps (shown in the figures as taps 1, taps 2, taps n) deployed in one or more TEEs, which may be located on one or more computing nodes in the hardware environment shown in fig. 1. A privacy calculation can be completed by one TAPP, or can be completed by a plurality of TAPPs together. Although in the example of fig. 2, only one TAPP is deployed in one TEE, it should be understood that one or more TAPPs may be deployed in one TEE, depending on the state of the TEE's computing and storage resources. Also running in one or more TEEs is a software module (also referred to herein as "first software module") associated with the TAPP, which provides services to the TAPP, including functions such as deployment of the TAPP in the TEE, generation of key pairs for the TAPP, running of the TAPP in the TEE, and communication of the TAPP with the outside world. In some embodiments, the software module associated with the TAPP comprises a trusted computing engine. In some embodiments, the trusted computing engine may be a verifiable computing engine MyTF using technologies such as TEE and WASM virtual machine, the TAPP runs in the WASM virtual machine through the MyTF, and the computing task of the TAPP may be performed by uploading the WASM bytecode of the TAPP into the MyTF and calling the WASM code to obtain the computing result.

A plurality of trusted library functions are also deployed in the one or more TEEs for calling by the TAPP. In some embodiments, the trusted library function may include Trusted Operators (TOPs), shown in the figures as TOP11, TOP12, TOP21, TOP22, TOP1, TOP 2. In some cases, TAPP may involve complex calculations in machine learning. The deep learning algorithm is composed of individual calculation units, which are called Operators (OP). In the network model, the operator corresponds to the computation logic in the Layer, for example, the Convolution Layer (constraint Layer) may be an operator; the weight summation process in the Fully-connected Layer (full-connected Layer) can also be an operator. The operator executed in the TEE is called the trusted operator TOP. A TOP may be, for example, a function that performs a particular machine learning or data analysis, and a TAPP may perform the corresponding computation by calling one or more TOPs. Also running in one or more TEEs is a TOP-associated software module (also referred to herein as a "second software module") that services the TOP, including functions such as TOP deployment in the TEE, generation of key pairs for the TOP, TOP running in the TEE, and TOP communications with the outside world.

Fig. 3 is a schematic diagram of at least a partial flow of a method of privacy computation in accordance with an embodiment of the present disclosure, illustrating operation of a first software module associated with a TAPP and a second software module associated with a plurality of trusted library functions.

The first software module deploys the TAPP on one or more TEEs and generates metric value and key pairs for the TAPP. It will be appreciated that before the first software module deploys the TAPP on one or more TEEs, the one or more TEEs also need to be verified, such as may be accomplished by a local attestation process and a remote attestation process, to verify that the target TEE to which the TAPP is to be deployed is itself authentic.

The second software module deploys the plurality of TOPs on the one or more TEEs and provides the call interface and metric values (also referred to herein as "first metric values") for each of the plurality of TOPs out. The TOP call interface may include the TOP name and version number and the metric values may be, for example, two metric values mrenclaves or MRSigner that intel SGX provides for programs in each Enclave. For example, the second software module may provide the outside world with a list of TOPs including the names, version numbers, and metric values of each TOP that has been deployed. In addition, the second software module also generates a key pair for each TOP. In some embodiments, deploying TOP onto the TEE may include: the second software module receives the computation logic code of the TOP, compiles the computation logic code, and packages the compiled computation logic code and the TEE operation environment component to generate an executable file corresponding to the computation logic code; and the second software module stores the executable file in at least one of the one or more TEEs (and generates the key pair and metric value for the TOP), thereby deploying the TOP in the at least one TEE. It should be noted that at least one TEE deployed by TOP here may be a single TEE or a cluster of TEEs. It will be appreciated that before the second software module deploys the TOP on the at least one TEE, for example before storing the TOP's executable file in the at least one TEE, it is also necessary to verify the at least one TEE, for example by means of a local attestation process and a remote attestation process, to verify that the target TEE to which the TOP is to be deployed is itself authentic.

The first software module, for example in response to an external privacy computation request, causes the TAPP to run in one or more TEEs. TAPP can call a TOP through its call interface, and before calling the TOP, TAPP and TOP need each prove to each other that it is an application in trusted Enclave created in SGX that is legitimate. Thus, in response to the TAPP about to invoke a first trusted library function of the plurality of trusted library functions, for example, the TAPP about to invoke TOP22 as shown in FIG. 4, the first software module sends a challenge to the TOP22 to the second software module to perform the remote attestation process. The following describes a mutual authentication process between TAPP and TOP22 before TAPP calls TOP22, and a process of TAPP calling TOP22, in conjunction with a specific example of TAPP calling TOP22. In the examples described below, the interaction between the first software module and the second software module is sometimes also described as the interaction between TAPP and TOP22 for the sake of simplicity. It should be understood that the interaction between TAPP and TOP22 is achieved by interaction between a first software module and a second software module.

As shown, the TAPP may send a Challenge message ("Challenge") to the TOP22, which may contain a metric value MREnclave ("MREnclave _ TAPP") of the TAPP. Upon receipt of the challenge message, the TOP22 may generate a remote attestation Report ("Report _ TOP 22") for the TOP22 by invoking an eport instruction provided by the CPU. Report _ TOP22 includes the metric value MREnclave of TOP22 ("MREnclave _ TOP22", also referred to herein as the "second metric value"), and may also include identity information and attributes of TOP22, as well as platform hardware TCB information, etc. Thus, TOP22 may return a Response message ("Response _ TOP 22") to TAPP, with Response _ TOP22 including Report _ TOP22 and fields for integrity verification, etc.

The TAPP receives the Response _ TOP22 message and then carries out integrity verification, obtains Report _ TOP22 in the Response _ TOP22 after the verification is passed, and reads MREnclave _ TOP22 from the Report _ TOP22 to carry out verification on the measurement value of the TOP22. The first software module compares the metric value of TOP22 provided to the outside by the second software module (i.e., the first metric value) with MREnclave _ TOP22 read from Report _ TOP22 (i.e., the second metric value). If the first metric value and the second metric value are consistent, the TAPP verifies that the TOP22 is passed.

The TAPP may then send a Response message ("Response _ TAPP") to TOP22, including a remote attestation Report ("Report _ TAPP", which may be generated, for example, by calling an EREPORT instruction provided by the CPU) of the TAPP, a field for integrity verification, and so on. After TOP22 receives Response _ TAPP, the integrity of Report _ TAPP is verified. In response to the integrity verification passing, TOP22 verifies TAPP. Thus, mutual authentication between TAPP and TOP22 was accomplished.

For the communication between TAPP and TOP22 to follow, TAPP and TOP22 need to inform each other of their own public keys. In some embodiments, the TOP22 may include its public key ("Pub _ TOP 22") in its Response message Response _ TOP22 during remote attestation, or the TAPP may include its public key ("Pub _ TAPP") in its Response message Response _ TAPP during remote attestation. After the TAPP and TOP22 receive the public key of the other party, respectively, the message transmitted to the other party can be encrypted with the public key of the other party in the subsequent communication.

In some embodiments, the TAPP may send a call Request to the TOP22, along with its own remote attestation Report _ TAPP, e.g., also including a call Request to TOP22 ("Request _ TOP 22") in the Response _ TAPP. The call request may include an identification of the TOP to be called (e.g., name, version number, etc. of the TOP), a logical cluster in which the TOP resides (e.g., domain, region, etc.), a function name for which the TOP is to execute, required input parameters and data (or a deposit address for the data), etc. To ensure the security of communication, the Request _ TOP22 is encrypted with the public key Pub _ TOP22 of the TOP22, and only the TOP22 having the corresponding private key can decrypt the encrypted data. The TAPP may also carry information about the type of encryption algorithm of Request _ TOP22 in Response _ TAPP, for specifying different encryption/decryption modes, signature verification modes, and the like. After the TOP22 receives the Response _ TAPP and performs integrity verification, it can decrypt the Response _ TOP22 with the private key and execute the TOP22 according to the content in the Request _ TOP22.

In some embodiments, a hash value of Request _ TOP22 may also be included in the remote attestation Report _ TAPP of the TAPP. Thus, after receiving the Response _ TAPP and performing integrity verification, the TOP22 may decrypt the Response _ TAPP with the private key to obtain the Request _ TOP22, and calculate the hash value of the Request _ TOP 22; the calculated hash value of Request _ TOP22 is then compared with the hash value of Request _ TOP22 contained in the received Report _ TAPP, and if the comparison result is consistent, request _ TOP22 is trusted, so that TOP22 can be executed according to the contents in Request _ TOP22.

After TOP22 has executed, the Result of the execution ("Result") is encrypted with the TAPP's public key Pub _ TAPP and returned to the TAPP. The TAPP can decrypt with the private key to obtain the Result of execution. In some embodiments, the TOP22 message returned to the TAPP may include its own signature in order for the TAPP to verify that the message is indeed from the TOP22. In addition, the message returned by the TOP22 to the TAPP may also include a hash value of the Request _ TOP22, so that the TAPP verifies that the Result is the Result of execution for the call Request _ TOP22. For example, in response to the signature of TOP22 and the verification of the hash value of the call request both passing, the first software module returns the execution Result of TOP22 to TAPP.

Even in the same computing cluster as shown in fig. 1, the TEEs of the computing nodes are not trusted naturally, so the TEEs of the computing nodes in the cluster need to authenticate each other and obtain a key before secure interaction can be performed through the key. Thus, the process of TAPP calling a trusted library function (e.g., TOP) is logically two-level authentication, i.e., the TEE is authenticated first, and the application is authenticated after passing. Also taking as an example the specific example that a TAPP deployed on TEE1 is going to invoke a TOP22 deployed on TEE2, as shown in fig. 5, the complete authentication process comprises two levels of authentication operations, namely a first level: mutual authentication between TEE1 and TEE2, and second stage: mutual authentication between TAPP and TOP22. Wherein the second level of verification is detailed above in connection with the description of fig. 3. The first level of authentication is the same as the mutual authentication procedure between two TEEs known in the art, and may be accomplished, for example, by both a local attestation procedure and a remote attestation procedure. It should be noted that mutual authentication between TEE1 and TEE2 need not be performed before each application call deployed on TEE1 calls a trusted library function deployed on TEE2, or before an application call deployed on TEE2 calls a trusted library function deployed on TEE 1. For example, when a TEE cluster is established, or when TEE1 and TEE2 are started, one-time mutual authentication between TEE1 and TEE2 is enough, and the authentication is not required to be repeated before function calling.

In some cases, TAPP calls trusted library functions (e.g., TOP) to process a relatively large amount of data that is input to the trusted library functions. Due to the limited storage space within the TEE, these data may be stored on storage space outside the TEE. Since it is the data that participates in the privacy calculation, these data are stored encrypted on the storage space outside the TEE. In some cases, encrypting large amounts of input data may use a symmetric key and encrypt with a symmetric encryption algorithm. In some embodiments, such as where the TAPP is in the same TEE as the TOP being invoked, the TAPP may read these data from storage space outside the TEE and decrypt it into plaintext data in the TEE using the symmetric key, and then invoke the TOP. The called TOP can directly read the plain text input data from the TEE for processing. In some embodiments, the TAPP and invoked TOP may not be in the same TEE, and the TAPP may not read and decrypt the data, but rather inform the TOP of the symmetric key used to encrypt the incoming data. It should be understood that TAPP encrypts the symmetric key using the TOP's public key and then sends the encrypted symmetric key to TOP. In some embodiments, the encrypted symmetric key may be sent to the TOP as part of a call request to the TOP. The TOP can decrypt the symmetric key with its own private key, so that the input data can be decrypted into plaintext data in the TEE using the symmetric key, thereby performing the TOP for the calculation process. Thus, the complicated process of TAPP first decrypting data and then encrypting data for transmission to TOP can be avoided.

Fig. 8 is a schematic structural diagram of at least part of a computing device 800 (which may be, for example, a node device in the above embodiments, such as a control node, a computing node, an on-chain node, or an off-chain node) according to an embodiment of the present disclosure. The computing device 800 includes one or more processors 810, one or more memories 820, and other components (not shown) typically present in a computer or the like. Each of the one or more memories 820 may store content accessible by the one or more processors 810, including instructions 821 executable by the one or more processors 810, and data 822 retrievable, manipulable, or stored by the one or more processors 810.

The instructions 821 may be any set of instructions to be executed directly, such as machine code, or indirectly, such as scripts, by one or more processors 810. The terms "instructions," "applications," "processes," "steps," and "programs" in this disclosure may be used interchangeably. The instructions 821 may be stored in object code format for direct processing by the one or more processors 810, or in any other computer language, including scripts or collections of independent source code modules that are interpreted on demand or compiled in advance. The functions, methods, and routines of the instructions 821 are explained in more detail elsewhere in this disclosure.

The one or more memories 820 may be any temporary or non-temporary computer-readable storage medium capable of storing content accessible by the one or more processors 810, such as a hard drive, memory card, ROM, RAM, DVD, CD, USB memory, writeable memory, read-only memory, and so forth. One or more of the one or more memories 820 may comprise a distributed storage system, where the instructions 821 and/or data 822 may be stored on a plurality of different storage devices, which may be physically located at the same or different geographic locations. One or more of the one or more memories 820 may be connected to the one or more first devices 810 via a network and/or may be directly connected to or incorporated into any of the one or more processors 810.

The one or more processors 810 may retrieve, store, or modify the data 822 according to the instructions 821. Although the subject matter described in this disclosure is not limited by any particular data structure, data 822 may also be stored in a computer register (not shown) as a table or XML document having many different fields and records in a relational database. The data 822 may be formatted in any computing device readable format, such as, but not limited to, binary values, ASCII, or unicode. Further, the data 822 may include any information sufficient to identify the relevant information, such as a number, descriptive text, proprietary code, pointer, reference to data stored in other memory, such as at other network locations, or information used by a function to calculate the relevant data.

The one or more processors 810 may be any conventional processor, such as a commercially available Central Processing Unit (CPU), graphics Processing Unit (GPU), or the like. Alternatively, one or more processors 810 may also be special-purpose components, such as an Application Specific Integrated Circuit (ASIC) or other hardware-based processor. Although not required, one or more of processors 810 may include specialized hardware components to perform particular computing processes faster or more efficiently.

Although one or more processors 810 and one or more memories 820 are schematically illustrated in fig. 8 within the same block, computing device 800 may actually comprise multiple processors or memories that may reside within the same physical housing or within different physical housings. Accordingly, references to a processor, computer, computing device, or memory are to be understood as including references to a collection of processors, computers, computing devices, or memories that may or may not operate in parallel.

Although aspects of the present disclosure have been described thus far with reference to the accompanying drawings, the above-described methods, systems and apparatuses are merely exemplary examples, and the scope of the present disclosure is not limited by these aspects, but is only limited by the following aspects: the appended claims and their equivalents. Various elements may be omitted or equivalent elements may be substituted. In addition, the steps may be performed in a different order than described in the present disclosure. Further, the various elements may be combined in various ways. It is also important that as technology develops, many of the elements described can be replaced by equivalent elements which appear after the present disclosure.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain a corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical blocks. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as ABEL (Advanced Boolean Expression Language), AHDL (alternate Hardware Description Language), traffic, CUPL (core universal Programming Language), HDCal, jhddl (Java Hardware Description Language), lava, lola, HDL, PALASM, rhyd (Hardware Description Language), and vhigh-Language (Hardware Description Language), which is currently used in most popular applications. It will also be apparent to those skilled in the art that hardware circuitry for implementing the logical method flows can be readily obtained by a mere need to program the method flows with some of the hardware description languages described above and into an integrated circuit.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a server system. Of course, this application does not exclude that with future developments in computer technology, the computer implementing the functionality of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle mounted human interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device or a combination of any of these devices.

Although one or more embodiments of the present disclosure provide method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in processes, methods, articles, or apparatus that include the recited elements is not excluded. For example, if the terms first, second, etc. are used to denote names, they do not denote any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, which are described separately. Of course, when implementing one or more of the present disclosure, the functions of each module may be implemented in one or more software and/or hardware, or the modules implementing the same functions may be implemented by a plurality of sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The present disclosure is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, may implement the information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

One skilled in the art will appreciate that one or more embodiments of the present disclosure may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present disclosure may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

One or more embodiments of the disclosure may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present disclosure may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the present disclosure are described in a progressive manner, and the same and similar parts among the embodiments can be referred to each other, and each embodiment focuses on differences from other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment. In the description of the present disclosure, reference to the description of "one embodiment," "some embodiments," "an example," "a specific example," or "some examples" or the like means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present disclosure. In this disclosure, the schematic representations of the terms used above are not necessarily intended to be the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this disclosure can be combined and combined by one skilled in the art without contradiction.

The above description is intended to be merely illustrative of one or more embodiments of the present disclosure and should not be taken to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments of the present disclosure will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present disclosure should be included in the scope of claims.

Claims (23)

1. A method of performing privacy calculations performed by a trusted application TAPP deployed in one or more trusted execution environments, TEEs, in which are also deployed a plurality of trusted library functions, each of which provides outwards a calling interface and a first metric value, the method comprising the following steps performed by a software module:

causing the TAPP to run in the one or more TEEs;

in response to a TAPP about to invoke a first trusted library function of the plurality of trusted library functions, initiating a challenge to the first trusted library function to obtain a remote attestation report and a public key for the first trusted library function, the remote attestation report for the first trusted library function including a second metric for the first trusted library function;

comparing the first metric value with the second metric value, in response to the first metric value being consistent with the second metric value, encrypting a call request to the first trusted library function with a public key of the first trusted library function, and sending the encrypted call request and a public key of a TAPP to the first trusted library function;

receiving a function return encrypted with a public key of a TAPP from the first trusted library function, the function return including a result of execution of the first trusted library function, a signature of the first trusted library function, and a hash value of a call request; and

and responding to the verification of the signature of the first trusted library function and the hash value of the calling request, and returning the execution result of the first trusted library function to the TAPP.

2. The method of claim 1, further comprising:

and encrypting a symmetric key used for encrypting the input data of the first trusted library function by using the public key of the first trusted library function, and sending the encrypted symmetric key to the first trusted library function as a part of an encrypted call request so that the first trusted library function can decrypt the input data.

3. The method of claim 1, further comprising:

verifying the one or more TEEs prior to running the TAPP.

4. The method of claim 1, further comprising:

sending, along with the call request, a remote attestation report of the TAPP to the first trusted library function, the remote attestation report of the TAPP including a hash value of the call request.

5. The method of claim 1, wherein the trusted library function comprises a trusted operator.

6. The method of claim 1, wherein the software module comprises a trusted computing engine.

7. A method of performing privacy calculations performed by a trusted application TAPP running in one or more trusted execution environments, TEEs, the TAPP being based on at least a first trusted library function of a plurality of trusted library functions deployed in a TEE, the method comprising the following steps performed by software modules associated with the plurality of trusted library functions:

providing a calling interface and a first metric value of each of the plurality of trusted library functions outward;

in response to receiving a challenge to the first trusted library function from the TAPP, sending a remote attestation report of the first trusted library function and a public key to the TAPP, the remote attestation report of the first trusted library function including a second metric value for the first trusted library function;

receiving a public key from TAPP and a call request for the first trusted library function, decrypting the call request by using a private key of the first trusted library function, and executing the first trusted library function according to the call request; and

encrypting a function return of the first trusted library function with a public key from the TAPP, and sending the encrypted function return to the TAPP, wherein the function return comprises an execution result of the first trusted library function, a signature of the first trusted library function, and a hash value of a call request.

8. The method of claim 7, further comprising:

and acquiring a symmetric key for encrypting the input data of the first trusted library function from the decrypted call request, and decrypting the input data by using the symmetric key in the TEE so as to execute the first trusted library function.

9. The method of claim 7, further comprising:

receiving a computational logic code of at least one trusted library function of the plurality of trusted library functions, compiling the computational logic code, and packaging the compiled computational logic code and the TEE operating environment component to generate an executable file corresponding to the computational logic code; and

storing the executable file in at least one of the one or more TEEs and generating a key pair and the first metric value for the at least one trusted library function, thereby deploying the at least one trusted library function in the at least one TEE.

10. The method of claim 9, further comprising:

verifying the at least one TEE through a remote attestation process prior to storing the executable file in the at least one TEE.

11. The method of claim 9, wherein the at least one TEE is a TEE cluster.

12. The method of claim 7, further comprising:

receiving a remote attestation report of the TAPP with the invocation request, the remote attestation report of the TAPP including a hash value of the invocation request;

and executing the first trusted library function in response to the hash value calculated according to the received call request being consistent with the hash value of the call request in the remote attestation report of the TAPP.

13. The method of claim 7, wherein the trusted library function comprises a trusted operator.

14. A method of performing privacy calculations performed by a trusted application TAPP deployed in one or more trusted execution environment TEEs, one or more TEEs also having a plurality of trusted library functions deployed therein, and the one or more TEEs having a first software module running therein associated with the TAPP and a second software module running therein associated with the plurality of trusted library functions, the method comprising:

the second software module providing a call interface and a first metric value of each trusted library function of the plurality of trusted library functions externally;

the first software module causes a TAPP to run in the one or more TEEs;

in response to a TAPP about to invoke a first trusted library function of the plurality of trusted library functions, the first software module sending a challenge to the first trusted library function to the second software module to perform a remote attestation process;

in response to receiving a challenge to the first trusted library function from the first software module, the second software module sending a remote attestation report of the first trusted library function and a public key to the first software module, the remote attestation report of the first trusted library function including a second metric value for the first trusted library function;

the first software module compares the first metric value and the second metric value, and in response to the first metric value and the second metric value being consistent, the first software module encrypts a call request to the first trusted library function with a public key of the first trusted library function and sends the encrypted call request and a public key of a TAPP to the second software module;

the second software module receives a public key of the TAPP and a call request for the first trusted library function, decrypts the call request by using a private key of the first trusted library function, and executes the first trusted library function according to the call request;

the second software module encrypts a function return of the first trusted library function by using a public key of TAPP, and sends the encrypted function return to the first software module, wherein the function return comprises an execution result of the first trusted library function, a signature of the first trusted library function and a hash value of a call request; and

and the first software module receives function return from the second software module, and responds to the verification of the signature of the first trusted library function and the hash value of the calling request, and returns the execution result of the first trusted library function to the TAPP.

15. The method of claim 14, further comprising:

the first software module encrypts a symmetric key used for encrypting the input data of the first trusted library function by using a public key of the first trusted library function, and sends the encrypted symmetric key to the second software module as a part of an encrypted call request; and

the second software module obtains the symmetric key from the decrypted call request and decrypts input data using the symmetric key in the TEE to execute the first trusted library function.

16. The method of claim 14, further comprising:

the first software module sends a remote attestation report of the TAPP to the second software module together with the invocation request, the remote attestation report of the TAPP including a hash value of the invocation request; and

and the second software module receives the remote attestation report of the TAPP together with the call request, and executes the first trusted library function in response to the fact that the hash value calculated according to the received call request is consistent with the hash value of the call request in the remote attestation report of the TAPP.

17. The method of claim 14, further comprising:

the second software module receives a computational logic code of at least one trusted library function of the plurality of trusted library functions, compiles the computational logic code, and packages the compiled computational logic code with the TEE operating environment component to generate an executable file corresponding to the computational logic code; and

the second software module stores the executable file in at least one of the one or more TEEs and generates a key pair for the at least one trusted library function and the first metric value, thereby deploying the at least one trusted library function in the at least one TEE.

18. The method of claim 17, further comprising:

the second software module verifies the at least one TEE through a remote attestation process prior to storing the executable file in the at least one TEE.

19. The method of claim 17, wherein the at least one TEE is a TEE cluster.

20. The method of claim 14, further comprising:

before causing the TAPP to run, the first software module verifies the one or more TEEs.

21. The method of claim 14, wherein the trusted library function comprises a trusted operator.

22. A non-transitory computer-readable storage medium having stored thereon a series of computer-executable instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform the method of any of claims 1-21.

23. A computing device comprising one or more processors and one or more memories configured to store a series of computer-executable instructions, wherein the series of computer-executable instructions, when executed by the one or more processors, cause the one or more processors to perform the method of any one of claims 1-21.

Images