CN111082934B

CN111082934B - Cross-domain secure multiparty computing method and device based on trusted execution environment

Info

Publication number: CN111082934B
Application number: CN201911410359.5A
Authority: CN
Inventors: 赵原; 殷山
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2019-12-31
Filing date: 2019-12-31
Publication date: 2021-04-06
Anticipated expiration: 2039-12-31
Also published as: CN111082934A

Abstract

One or more embodiments of the present specification provide a method and apparatus for cross-domain secure multi-party computing based on a trusted execution environment, the method comprising: the secure computing server creates a trusted execution environment for secure multi-party computing, and uses a secure key maintained by the secure computing server to encrypt and store a private key at a computing side generated in the trusted execution environment. The technical scheme of the specification can be applied to business processing processes in various scenes, such as artificial intelligence scenes, block chain scenes and the like.

Description

Cross-domain secure multiparty computing method and device based on trusted execution environment

Technical Field

One or more embodiments of the present disclosure relate to the field of security technologies, and in particular, to a method and an apparatus for cross-domain secure multi-party computing based on a trusted execution environment.

Background

Secure Multi-Party computing (Secure Multi-Party computing) can compute the original data provided by a plurality of computing participants respectively, and ensure that the original data held by the computing participants are not leaked in the whole process, thereby taking data processing requirements and privacy protection requirements into account.

At present, the safe multi-party calculation faces the problem that privacy and performance are difficult to be considered, and most of the existing solutions trade privacy for performance loss or pursue performance without considering privacy greatly. Common encryption technologies for solving privacy problems, such as Homomorphic encryption (Homomorphic encryption) and Zero-knowledge proof (Zero-knowledge proof), have high complexity, are not only poor in universality, but also can cause serious performance loss.

In terms of addressing privacy, a Trusted Execution Environment (TEE) is another approach. The TEE can play a role of a black box in hardware, a code and data operating system layer executed in the TEE cannot be peeped, and the TEE can be operated only through an interface defined in advance in the code. In the aspect of efficiency, due to the black box property of the TEE, plaintext data is operated in the TEE instead of complex cryptography operation in homomorphic encryption, and the efficiency of the calculation process is not lost, so that the safety requirement and the privacy requirement of safe multi-party calculation can be met to a great extent on the premise of less performance loss by combining with the TEE. The industry is concerned with TEE solutions, and almost all mainstream chip and Software consortiums have their own TEE solutions, such as TPM (Trusted Platform Module) in Software, and Intel SGX (Software Guard Extensions) in hardware, ARM Trustzone, and AMD PSP (Platform Security Processor).

Disclosure of Invention

In view of the above, one or more embodiments of the present specification provide a method and apparatus for cross-domain secure multi-party computing based on a trusted execution environment.

To achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:

according to a first aspect of one or more embodiments of the present specification, there is provided a method for cross-domain secure multi-party computing based on a trusted execution environment, comprising:

the method comprises the steps that a secure computing server creates a trusted execution environment for secure multi-party computing and obtains a trusted authentication report aiming at the trusted execution environment; in a computing side public and private key pair generated by the trusted execution environment, a computing side private key is encrypted by a security key maintained by the security computing server to form a computing side private key ciphertext;

under the condition that the security computing server is outside the isolation domain, the security computing server sends the credible authentication report to a first computing participant for verification, and receives a first data ciphertext and a first key ciphertext returned by the first computing participant after the verification is confirmed, wherein the first data ciphertext is obtained by encrypting a first shared key maintained by the first computing participant, and the first key ciphertext is obtained by encrypting the first shared key by a public key at a computing side;

under the condition that the whole machine or at least core hardware related to the generation of the security key is migrated into an isolation domain, the security computing server sends the credible authentication report to a second computing party in the isolation domain for verification, and receives a second data ciphertext and a second key ciphertext returned by the second computing party after the second computing party passes verification confirmation, wherein the second data ciphertext is obtained by encrypting a second shared key maintained by the second computing party, and the second key ciphertext is obtained by encrypting the second shared key by a computing side public key;

the secure computing server decrypts the computing side private key ciphertext in the trusted execution environment by using the secure key to obtain the computing side private key, decrypts the first key ciphertext and the second key ciphertext by using the computing side private key respectively, decrypts the first data ciphertext and the second data ciphertext by using the obtained first shared key and the obtained second shared key respectively to obtain a first data plaintext and a second data plaintext, and performs multi-party computing according to the first data plaintext and the second data plaintext.

According to a second aspect of one or more embodiments of the present specification, there is provided an apparatus for cross-domain secure multi-party computing based on a trusted execution environment, comprising:

an environment creating unit that causes the secure computing server to create a trusted execution environment for secure multiparty computing;

a report acquisition unit that causes the secure computing server to acquire a trusted authentication report for the trusted execution environment; in a computing side public and private key pair generated by the trusted execution environment, a computing side private key is encrypted by a security key maintained by the security computing server to form a computing side private key ciphertext;

a first ciphertext obtaining unit, configured to send the trusted authentication report to a first computation participant for verification when the secure computation server is outside an isolation domain, and receive a first data ciphertext and a first key ciphertext returned by the first computation participant after the first computation participant passes verification confirmation, where the first data ciphertext is obtained by encrypting a first shared key maintained by the first computation participant, and the first key ciphertext is obtained by encrypting the first shared key with a public key at a computation side;

a second cipher text obtaining unit, configured to, when the whole secure computing server or at least core hardware related to generation of the secure key is migrated into an isolated domain, send the trusted authentication report to a second computing party in the isolated domain for verification, and receive a second data cipher text and a second key cipher text returned by the second computing party after verification is confirmed, where the second data cipher text is obtained by encrypting a second shared key maintained by the second computing party, and the second key cipher text is obtained by encrypting the second shared key with a public key on a computing side;

and the multiparty computing unit enables the secure computing server to decrypt the computing side private key ciphertext in the trusted execution environment by using the secure key to obtain the computing side private key, decrypt the first key ciphertext and the second key ciphertext by using the computing side private key respectively, decrypt the first data ciphertext and the second data ciphertext by using the obtained first shared key and the obtained second shared key respectively to obtain a first data plaintext and a second data plaintext, and implement multiparty computing according to the first data plaintext and the second data plaintext.

According to a third aspect of one or more embodiments of the present specification, there is provided an electronic apparatus including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of the first aspect by executing the executable instructions.

According to a fourth aspect of one or more embodiments of the present description, a computer-readable storage medium is presented, having stored thereon computer instructions which, when executed by a processor, implement the steps of the method according to the first aspect.

Drawings

FIG. 1 is an architectural diagram of a secure multi-party computing system, according to an exemplary embodiment.

FIG. 2 is a flow diagram of a method for cross-domain secure multi-party computing based on a trusted execution environment, provided by an exemplary embodiment.

Fig. 3 is a schematic diagram of a scenario of secure multiparty computing based on SGX technology according to an exemplary embodiment.

Fig. 4 is a flow chart illustrating interactions within a public network according to an exemplary embodiment.

FIG. 5 is a flow chart illustrating interactions within an isolated domain in accordance with an illustrative embodiment.

Fig. 6 is a schematic structural diagram of an apparatus according to an exemplary embodiment.

FIG. 7 is a block diagram of an apparatus for cross-domain secure multi-party computing based on a trusted execution environment, according to an example embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

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

FIG. 1 is an architectural diagram of a secure multi-party computing system, according to an exemplary embodiment. As shown in FIG. 1, the system may include a secure computing server 11, a network 12, a number of computing participants 13-15, and the like. The calculation participants 13 to 15 respectively maintain a part of private data, and the private data can be used in a certain calculation process to meet corresponding business requirements, such as sample data for training an artificial intelligence model, historical transaction data respectively collected by a plurality of transaction platforms, and the like, which is not limited in this specification.

Due to the requirements on data security and privacy, the computation participants 13 to 15 and the like can respectively provide the private data maintained by the computation participants to the secure computation server 11, and the secure computation server 11 performs secure multi-party computation by combining all the received data, and finally feeds back the computation result to the computation participants 13 to 15 or other demand parties, so that the computation participants 13 to 15 do not contact the private data of the other parties, and only the data security and privacy protection at the secure computation server 11 need to be ensured.

As described above, in the related art, a mode based on homomorphic encryption and zero knowledge proof is adopted to ensure the security and privacy of data, so that data from each computation participant needs to participate in computation in a ciphertext state, and although the requirement on data security can be met, the computation efficiency is extremely low. In the technical solution of the present specification, the secure computing server 11, by using the TEE technology, can enable data from each computing participant to participate in computing in the TEE in a plaintext form under the condition of ensuring data security and privacy requirements, so as to greatly improve computing efficiency.

The secure multiparty computing scheme of the present specification is described below with reference to the flow shown in fig. 2:

FIG. 2 is a flow diagram of a method for cross-domain secure multi-party computing based on a trusted execution environment, provided by an exemplary embodiment. As shown in fig. 2, the method may include the steps of:

step 202, a secure computing server creates a trusted execution environment for secure multiparty computing, and obtains a trusted authentication report for the trusted execution environment; and in a computing side public and private key pair generated by the trusted execution environment, a computing side private key is encrypted into a computing side private key ciphertext by a security key maintained by the secure computing server.

The secure computation server enables subsequently received data from each computation participant to participate in secure multi-party computation in the TEE in a plaintext form by creating the TEE for secure multi-party computation. The TEE is a trusted execution environment that is based on a secure extension of the CPU hardware 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. 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.

The Intel SGX (hereinafter referred to as SGX) technology is taken as an example. The secure computation server acts as an SGX server, which can create enclaves (enclosures or enclaves) based on SGX technology as TEEs for secure multi-party computation. The secure computing server may allocate a part of an EPC (enclosure Page Cache, a ring Page Cache, or an Enclave Page Cache) in the memory by using a processor instruction newly added to the CPU, so as to reside the above-mentioned enclosure. The CPU can simultaneously create one or more enclaves, and codes run by different enclaves can be the same or different, depending on the purposes of the corresponding enclaves. For example, the code for secure computation may be encapsulated in the created enclave in the present specification, so as to obtain the enclave for secure multi-party computation. The memory area corresponding to the EPC is encrypted by a memory Encryption engine mee (memory Encryption engine) inside the CPU, the contents (code and data in the enclave) in the memory area can be decrypted only in the CPU core, and a key for Encryption and decryption is generated and stored in the CPU only when the EPC is started. It can be seen that the security boundary of enclave only includes itself and CPU, and no matter privileged or non-privileged software can not access enclave, even an operating system administrator and VMM (virtual machine monitor, or called Hypervisor) can not affect code and data in enclave, so that the security is very high.

The trusted authentication report is used to indicate that the enclave created by the secure computing server for secure multi-party computing is trusted and running on a legitimate platform. The enclave is on a secure computing server, and a trusted authentication report for the enclave can be generated by a third party on other platforms, and the authentication mode can be referred to as remote authentication. In the remote authentication process, the secure computing server may generate an authentication request for the created enclave, where the authentication request may be sent to the third party, for example, the third party may be a remote authentication server, and the secure computing server may receive the trusted authentication report returned by the authentication server, where the trusted authentication report is returned by the authentication server after the enclave is authenticated according to the authentication request. The trusted authentication report comprises an authentication result of the authentication server for the enclave based on the authentication request so as to indicate whether the enclave is trusted or not; accordingly, each computing participant can transmit the held data to the secure computing server by looking at the authentication result contained in the trusted authentication report, so that the secure computing server implements the secure multi-party computing in the enclave under the condition that the authentication result indicates that the enclave is trusted. The authentication request may be sent directly from the secure computing server to the authentication server, or may be provided by the secure computing server to an external object and sent from the external object to the authentication server, for example, the external object may be a computing party or any other object in the same network environment as the authentication server.

Still take the SGX technique as an example. Assuming that the above described enclave for secure multi-party computing is enclave a, the remote authentication procedure also involves another special enclave on the secure computing server, namely, Quoting Enclave (QE), which is an architected enclave (architectural enclave) provided and signed by intel. enclave A firstly needs to generate a REPORT structure for local authentication, QE verifies whether enclave A is on the same platform with itself based on the REPORT structure, QE packages the REPORT structure into a structure body QUOTE, and uses an EPID (enhanced private identification) key for signature. The EPID key not only represents the platform of the secure computing server, but also represents the credibility of the underlying hardware of the secure computing server, and can bind information such as the version of processor firmware, and only the QE can access the EPID key for signing the structure queue. In the SGX technique, the authentication server may be an IAS (intel authentication service) server provided by intel corporation, and the authentication request sent by the secure computing server to the IAS server includes the structure body qualte and its signature, so that the IAS server can verify whether the enclave a is trusted according to the structure body qual and return a corresponding trusted authentication report to the secure computing server.

In the above enclave for secure multiparty computation, a set of computation-side public and private key pairs, i.e., a computation-side public key and a computation-side private key based on an asymmetric cryptographic algorithm, may be generated. Specifically, the compute-side public-private Key pair may be generated by the secure compute Server itself in the enclave, or may be imported into the enclave after being generated by an external object, for example, the external object may be a Key Management Server (KMS), and the Key Management Server may encrypt and transmit the compute-side private Key (or the compute-side public-private Key pair) to the secure compute Server after determining that the enclave passes the remote authentication, and import the compute-side private Key pair into the enclave by the secure compute Server. The key for encrypted transmission of the private key on the computing side may be determined by negotiation with the KMS in advance for the secure computing server, or may be determined by negotiation based on a key negotiation algorithm such as ECDH (explicit users Diffie-Hellman) or other methods in the above-mentioned remote authentication process. For example, the secure computing server may generate a negotiation private key X, and include a negotiation public key X generated based on the negotiation private key X in the authentication request sent to the KMS, so that the KMS obtains the negotiation public key X; meanwhile, the KMS may generate a negotiation private key Y, and a trusted authentication report sent to the secure computing server includes a negotiation public key Y generated based on the negotiation private key Y, so that the secure computing server may generate a key seed z based on the negotiation private key X and the negotiation public key Y, the KMS may generate the same key seed z based on the negotiation private key Y and the negotiation public key X, and finally, the secure computing server and the KMS may derive the same key through the key seed z, so as to perform encryption transmission on the computing-side private key.

The secure computing server can encrypt the computing side private key through a secure key maintained by the secure computing server, and store an encrypted computing side private key ciphertext outside the enclave. The security key is maintained by the security computing server, only the security computing server can know the security key, the security of the private key at the computing side can be ensured, the private key at the computing side is prevented from being leaked in a plaintext form, and the leaked private key ciphertext at the computing side can not be cracked, because only the security key is known, the decryption of the private key ciphertext at the computing side can be realized. Taking the SGX technology as an example, the above-mentioned security Key may be a Seal Key, which is derived by the secure computing server based on a Root Seal Key (RSK). If the CPU of the secure computing server supports the SGX technology, the CPU includes an e-fuses storage circuit for storing the RSK keys burned in by intel during production, and intel claims that traces of these RSK keys will be deleted after the burn-in operation is completed, so that the RSK keys are only grasped by the CPU of the secure computing server, ensuring the security of the Seal Key derived therefrom and the reliability of the computing-side private Key ciphertext. Although in the SGX technique described above the security Key used is the Seal Key, which is a derivative of the secure root Key RSK, in other embodiments it is not excluded that the security Key may be the secure root Key itself.

Step 204a, under the condition that the security computing server is outside the isolation domain, the security computing server sends the trusted authentication report to a first computing participant for verification, and receives a first data ciphertext and a first key ciphertext returned by the first computing participant after the verification is confirmed, wherein the first data ciphertext is obtained by encrypting a first shared key maintained by the first computing participant, and the first key ciphertext is obtained by encrypting the first shared key by a computing side public key.

The network environment of the present specification may include an intranet environment within an isolated domain and a public network environment outside the isolated domain, and when the secure computing server is outside the isolated domain, the secure computing server may interact with a first computing participant that is also outside the isolated domain but may not interact with a second computing participant that is inside the isolated domain. Therefore, when there are multiple computing participants in different network environments, the secure computing server needs to migrate between the network environments to interact with the computing participants respectively to obtain data held by the computing participants.

When interacting with the first computing participant, it is necessary to ensure that the secure computing server is outside the isolation domain, otherwise interaction failure may result. During the interaction, the secure computing server enables the first computing participant to verify the enclave for secure multi-party computing based on the trusted authentication report by sending the trusted authentication report to the first computing participant to determine the reliability of the first computing participant. For example, the trusted authentication report may include an authentication result, and if the authentication result indicates that the authentication server determines that the enclave is trusted, the first computing participant may determine that the enclave is trusted, that is, the enclave passes the verification of the first computing participant.

In order to avoid tampering of the authentication request received by the authentication server, the secure computation server may add a hash value of the public key on the computation side to the authentication request; when the content of the authentication request is contained in the trusted authentication report, the trusted authentication report contains the hash value of the public key on the computing side. Accordingly, the secure computing server may provide the computing-side public key to the first computing participant in addition to sending the trusted authentication report to the first computing participant, so that the first computing participant may verify the hash value of the computing-side public key included in the trusted authentication report based on the computing-side public key, and determine that the authentication request received by the authentication server has not been tampered after the verification is passed. The secure computing server may send the trusted authentication report and the computing-side public key to the first computing participant together, or separately.

In order to avoid tampering with the trusted authentication report received by the first computing participant, the authentication server may sign the trusted authentication report. Correspondingly, the first computing participant can perform signature verification on the trusted authentication report, and after the verification is passed, the trusted authentication report is determined to be not tampered, and the authentication result contained in the trusted authentication report can be trusted, so that the first computing participant can determine that the enclave is trusted according to the authentication result when the authentication result indicates that the authentication server determines that the enclave is trusted; otherwise, the first computing participant may not trust the enclave, such as by verifying the signature to indicate that the trusted authentication report has been tampered with. The authentication server signs the credible authentication report through an authenticator private key held by the authentication server, and the first computing participant signs and verifies the signature through a corresponding authenticator public key. The first computing participant can obtain the public key of the authenticator through any channel; or, the secure computing server may provide, to the first computing party, a certificate chain corresponding to the authentication server in addition to sending the trusted authentication report to the first computing party, where a bottom layer of the certificate chain is a digital certificate corresponding to an end-user (end-user) that is the authentication server, and an upper layer of the certificate chain includes one or more levels of digital certificates corresponding to issuers (lssuers), and the first computing party may hold a root key for verifying the certificate chain, and perform layer-by-layer verification on the certificate chain according to the root key until an authenticator public key included in the digital certificate of the bottom layer is obtained, and perform signature verification based on the authenticator public key. The secure computing server may send the trusted authentication report and the certificate chain to the first computing participant together, or separately.

The secure computing server may send the trusted authentication report, the certificate chain, and the computing-side public key to the first computing participant, so that the first computing participant may perform signature verification on the trusted authentication report based on the foregoing manner, and perform verification on a hash value of the computation public key included in the trusted authentication report, so that in a case that the first computing participant passes the verification, the first computing participant trusts an authentication result included in the trusted authentication report, and thus, in a case that the authentication result indicates that the authentication server determines that the enclave is trusted, the first computing participant may determine that the enclave is trusted accordingly. The secure computing server may send the trusted authentication report, the certificate chain, and the computing public key to the first computing participant together, or send any two of the trusted authentication report, the certificate chain, and the computing public key together, or send any three of the trusted authentication report, the certificate chain, and the computing public key separately, or send the trusted authentication report, the certificate chain, and the computing public key separately.

The first computing party holds a first data plaintext and a first shared key, the first shared key is a symmetric key generated by the first computing party, and the computing-side public key is an asymmetric key, so that when encryption and decryption operations are performed on the same data, the computing efficiency based on the first shared key is higher than that based on the computing-side public key, the difference between the computing-side public key and the computing-side public key is increased along with the increase of the data volume, but the security of the asymmetric encryption algorithm is much higher than that of the symmetric encryption algorithm.

The first computing participant represents a computing participant outside of the quarantine domain. The number of first computing participants may be one or more. When a plurality of first computation participants exist, the secure computation server interacts with each first computation participant through step 204a, so as to obtain a first data ciphertext and a first key ciphertext returned by each first computation participant.

Step 204b, when the whole machine or at least the core hardware related to the generation of the security key is migrated into the isolated domain, the security computing server sends the trusted authentication report to a second computing party in the isolated domain for verification, and receives a second data ciphertext and a second key ciphertext returned by the second computing party after the verification is confirmed, wherein the second data ciphertext is obtained by encrypting a second shared key maintained by the second computing party, and the second key ciphertext is obtained by encrypting the second shared key by a computing side public key.

As previously described, the security Key may be derived by the secure compute server from a secure root Key, such as a Seal Key derived from an RSK in SGX technology. In the process of deriving the security key, the security computing server may jointly compute the security root key and information of a specific hardware adopted by itself to derive a corresponding security key, where the specific hardware is the above core hardware, such as a CPU, a motherboard, and the like, and practically all hardware related to generating the security key belongs to the above core hardware.

As previously described, due to the differences in network environments, the secure computing server needs to migrate into the isolation domain to enable interaction with the second computing participant. Therefore, in the process of migrating the secure computing server, the complete machine migration of the secure computing server may be selected, or at least the core hardware should be ensured to be migrated, and the core hardware and other non-core hardware are reassembled to obtain the secure computing server in the isolated domain, even if the contained hardware is not completely the same, the secure computing server may be considered to be migrated into the isolated domain, and the reassembled secure computing server may derive the secure key based on the information of the core hardware and the secure root key stored in the CPU, and further decrypt the compute-side ciphertext private key based on the secure key to obtain the compute-side private key, so that the first data plaintext, the second data plaintext, and the like are obtained based on the compute-side private key, thereby implementing secure multiparty computing.

During the interaction, the secure computing server may verify the above enclave for secure multi-party computing based on the trusted authentication report by sending the trusted authentication report to the second computing party to determine its authenticity. For example, the trusted authentication report may include an authentication result, and if the authentication result indicates that the authentication server determines that the enclave is trusted, the second computing participant may determine that the enclave is trusted, that is, the enclave passes the verification of the second computing participant. By generating a trusted authentication report outside the isolated domain in advance and caching the trusted authentication report, the second computing party in the isolated domain can still perform trusted verification on the TEE created on the secure computing server, and therefore the second data ciphertext and the second key ciphertext are provided to the secure computing server after the verification is passed.

In order to avoid tampering of the authentication request received by the authentication server, the secure computation server may add a hash value of the public key on the computation side to the authentication request; when the content of the authentication request is contained in the trusted authentication report, the trusted authentication report contains the hash value of the public key on the computing side. Accordingly, the secure computing server may provide the computing-side public key to the second computing party in addition to sending the trusted authentication report to the second computing party, so that the second computing party may verify the hash value of the computing-side public key included in the trusted authentication report based on the computing-side public key, and determine that the authentication request received by the authentication server has not been tampered after the verification is passed. The secure computing server may send the trusted authentication report and the computing-side public key to the second computing participant together, or separately.

In order to avoid tampering with the trusted authentication report received by the second computing participant, the authentication server may sign the trusted authentication report. Correspondingly, the second computing participant can perform signature verification on the trusted authentication report, and after the verification is passed, the trusted authentication report is determined to be not tampered, and the authentication result contained in the trusted authentication report can be trusted, so that the second computing participant can determine that the enclave is trusted according to the authentication result when the authentication server determines that the enclave is trusted; otherwise, the second computing participant may not trust the enclave, such as by signature verification indicating that the trusted authentication report was tampered with. The authentication server signs the credible authentication report through the own private key of the authenticator, and the second computing participant signs and verifies the signature through the corresponding public key of the authenticator. The second computing participant can obtain the public key of the authenticator through any channel; or, the secure computing server may provide, to the second computing party, a certificate chain corresponding to the authentication server in addition to sending the trusted authentication report to the second computing party, where a bottom layer of the certificate chain is a digital certificate corresponding to an end-user (end-user) that is the authentication server, and an upper layer of the certificate chain includes one or more levels of digital certificates corresponding to issuers (lsuers), and the second computing party may hold a root key for verifying the certificate chain, and perform layer-by-layer verification on the certificate chain according to the root key until an authenticator public key included in the digital certificate of the bottom layer is obtained, and perform signature verification based on the authenticator public key. The secure computing server may send the trusted authentication report and the certificate chain to the second computing participant together, or separately.

The secure computing server may send the trusted authentication report, the certificate chain, and the computing-side public key to the second computing participant, so that the second computing participant may perform signature verification on the trusted authentication report based on the foregoing manner, and verify a hash value of the computation public key included in the trusted authentication report, so that, in a case where the second computing participant passes the verification, the second computing participant trusts the authentication result included in the trusted authentication report, and thus, in a case where the authentication result indicates that the authentication server determines that the enclave is trusted, the second computing participant may determine that the enclave is trusted accordingly. The secure computing server may send the trusted authentication report, the certificate chain, and the computing public key to the second computing party together, or send any two of them together, send the third party separately, or send the three separately.

The second computing party holds a second data plaintext and a second shared key, the second shared key is a symmetric key generated by the second computing party, and the computing-side public key is an asymmetric key, so that when encryption and decryption operations are performed on the same data, the computing efficiency based on the second shared key is higher than that based on the computing-side public key, the difference between the computing-side public key and the computing-side public key is increased along with the increase of the data volume, but the security of the asymmetric encryption algorithm is much higher than that of the symmetric encryption algorithm.

If the complete machine migration is adopted, the secure computing server migrated into the isolated domain includes the trusted authentication report, the certificate chain, the computing side public key and the like. If only the core hardware is migrated, the trusted authentication report, the certificate chain, the computing side public key and the like can be stored in an external memory before migration, then the external memory is connected to the assembled secure computing server, and the data such as the trusted authentication upgrade, the certificate chain and the computing side public key are read from the external memory by the secure computing server.

The second computing participant represents a computing participant outside of the quarantine domain. Within the same isolation domain, the number of second computing participants may be one or more; when a plurality of second computation participants exist, the secure computation server interacts with each second computation participant through step 204b, so as to obtain a second data ciphertext and a second key ciphertext returned by each second computation participant. If a plurality of isolation domains exist, the secure computation server can be respectively migrated into each isolation domain and respectively interacts with the second computation participants in each isolation domain to obtain second data ciphertexts and second key ciphertexts respectively returned by each second computation participant.

There is no necessarily a sequential order between step 204a and step 204 b. The secure computing server may first perform step 204a to obtain a first data ciphertext and a first key ciphertext provided by a first computing party, then migrate into the isolated domain, and obtain a second data ciphertext and a second key ciphertext provided by a second computing party through step 204 b; alternatively, step 204b may be performed first, followed by step 204 a. In addition, in the case that the number of the first computation participants or the second computation participants is multiple, or the number of the isolation domains is multiple, the execution times of the

steps

204a and 204b may also be multiple, and the execution order between the steps may be arbitrarily combined, which is not limited in this specification.

Step 206, the secure computing server decrypts the cryptograph of the computing side private key in the trusted execution environment by using the secure key to obtain the computing side private key, decrypts the first cryptograph of the computing side private key and the second cryptograph of the computing side private key by using the computing side private key respectively, decrypts the first data cryptograph and the second data cryptograph by using the obtained first shared key and the obtained second shared key respectively to obtain a first data plaintext and a second data plaintext, and performs multi-party computation according to the first data plaintext and the second data plaintext.

The security key maintained by the security computing server is related to the information of the core hardware, and the core hardware is ensured to be unchanged in the migration process, so that the security computing server can generate the same security key no matter before or after the migration, and the computing side private key ciphertext is decrypted based on the security key to obtain the computing side private key. Therefore, the secure computation server can perform the decryption operation described in step 206 based on the computation-side private key, finally obtain the first data plaintext and the second data plaintext, and perform secure multi-party computation on the first data plaintext and the second data plaintext in the TEE.

If the secure computing server generates the computing side private key ciphertext outside the isolated domain, the secure computing server can write the computing side private key ciphertext into an external memory such as a mobile hard disk, a U disk and the like under the condition that the secure computing server is outside the isolated domain, and after core hardware of the secure computing server is migrated into the isolated domain and is re-formed into the secure computing server after being assembled with other hardware, the computing side private key ciphertext can be read from the connected external memory, so that the migration of the computing side private key ciphertext is realized, and the computing side private key ciphertext is in a ciphertext state in the migration process, so that the security problem cannot be caused. Or, if the secure computing server generates the computing-side private key ciphertext in the isolated domain, the secure computing server may write the computing-side private key ciphertext into the external memory after being in the isolated domain, and after the core hardware of the secure computing server is migrated outside the isolated domain, and is assembled with other hardware to reform the secure computing server, the computing-side private key ciphertext may be read from the connected external memory.

If the secure computing server obtains the first data ciphertext and the first key ciphertext outside the isolated domain, the secure computing server may write the first data ciphertext and the first key ciphertext into the external memory while being outside the isolated domain, and after the core hardware of the secure computing server is migrated into the isolated domain, and is re-assembled with other hardware to form the secure computing server, the secure computing server may read the first data ciphertext and the first key ciphertext from the external memory that is connected. Or, if the secure computing server obtains the second data ciphertext and the second key ciphertext in the isolated domain, the secure computing server may write the second data ciphertext and the second key ciphertext into the external memory after being in the isolated domain, and after the core hardware of the secure computing server is migrated outside the isolated domain, and is assembled with other hardware to form the secure computing server again, the secure computing server may read the second data ciphertext and the second key ciphertext from the external memory that is connected thereto.

The secure computing server may perform the secure multi-party computing operations described above within or outside the isolated domain, which is not limited in this specification. And after the calculation is finished, the safety calculation server sends the calculated multi-party calculation result to the data demand party. If the data demand party is in the isolation domain, for example, the data demand party is the second computation participant, the secure computation server may obtain the first data ciphertext and the first key ciphertext outside the isolation domain in advance, and then migrate to the isolation domain to obtain the second data ciphertext and the second key ciphertext, at this time, the secure computation server may directly perform secure multi-party computation in the isolation domain, and send the multi-party computation result to the second computation participant, thereby reducing the migration frequency as much as possible, and if the data demand party further includes the first computation participant outside the isolation domain, for example, after the secure computation server migrates to the isolation domain, the multi-party computation result may be sent to the first computation participant.

The secure multiparty computing scheme of the present specification is described below by taking the SGX technique as an example. Fig. 3 is a schematic diagram of a scenario of secure multiparty computing based on SGX technology according to an exemplary embodiment. As shown in fig. 3, assuming that there are an SGX client 1 located in a public network and an SGX client 2 located in an isolated domain, the SGX server provides secure multiparty computing services to the SGX client 1 and the SGX client 2. Because the IAS server is in the public network and the SGX server is also in the public network by default, the SGX server interacts with the IAS server in the public network to complete remote authentication, interacts with the SGX client 1 to obtain data required by calculation, then migrates to an isolation domain to interact with the SGX client 2 to obtain data required by calculation, and finally completes safe multi-party calculation. The interaction process within the public network and the isolated domain is described below with reference to fig. 4 and 5, respectively.

Fig. 4 is a flow chart illustrating interactions within a public network according to an exemplary embodiment. As shown in fig. 4, the interaction process between the SGX server, the IAS server and the SGX client 1 may include the following steps:

in step 401, the SGX server creates enclave and generates RSA public and private key pair.

The SGX server creates enclaves based on SGX technology, which contains code for performing secure multi-party computation, so that the enclaves can be used to perform secure multi-party computation on data from the SGX clients 1, 2. Based on the created enclave, a set of RSA public and private key pairs, including an RSA public key and an RSA private key, may be generated in the enclave.

And step 402, the SGX server side encrypts and stores the RSA private key and embeds the hash of the RSA public key into the QUOTE.

Aiming at the RSA public key and the RSA private key generated in enclave, the SGX server side adopts different processing modes. For the RSA private key, the SGX server derives a seal key according to the RSK key maintained in the CPU and the information of the core hardware of the SGX server, encrypts the RSA private key in the envelope based on the seal key, and persistently stores the obtained RSA private key ciphertext out of the envelope, such as in a hard disk of the SGX server.

For the RSA public key, the SGX server side performs hash operation on the RSA public key by adopting a preset hash algorithm to obtain the hash of the RSA public key. The present description does not limit the hashing algorithm employed herein, and for example, the hashing algorithm may include SHA-256 or the like. Then, the SGX server may embed the hash of the RSA public key in the queue in the process of generating the queue for remote attestation. More specifically, the SGX server first generates a local report structure for the above enclave, and then the QE generates a quantum based on the local report structure.

In step 403, the SGX server initiates a request for remote authentication to the IAS server based on quantum.

And step 404, the SGX server receives and stores the remote authentication report returned by the IAS server.

After receiving the request initiated by the SGX server, the IAS server performs remote authentication on the enclave created in step 401 based on the above-mentioned quantum, and includes an authentication result in the above-mentioned remote authentication report, for example, the authentication result may include trusted and untrusted. Meanwhile, the remote authentication report also contains the content of quantum, so that the remote authentication report contains the hash of the RSA public key.

In step 405, SGX client 1 initiates negotiation with the SGX server.

Step 406, the SGX server sends the remote authentication report, the Intel certificate chain, and the RSA public key to the SGX client 1.

The SGX client 1 maintains a root key for verifying the Intel certificate chain; after the Intel certificate chain is verified, the SGX client 1 obtains an authenticator public key corresponding to the IAS server from the Intel certificate chain, and the IAS server adopts an authenticator private key to sign the remote authentication report before, so that the SGX client 1 can carry out signature verification based on the authenticator public key, and the received remote authentication report is determined to be not tampered; the SGX client 1 may also perform hash calculation on the received RSA public key, and compare the obtained hash with the hash contained in the remote authentication report to determine whether the remote authentication report contains the hash of the RSA public key, thereby determining that the quite received by the ISA server is not tampered. In the case that the above verification is passed and the authentication result included in the remote authentication report is trusted, the SGX client 1 may determine that enclave created by the SGX server is trusted, so as to go to step 407, otherwise, it terminates.

Step 407, the SGX client 1 generates a data ciphertext 1 and a key ciphertext 1, and sends the data ciphertext 1 to the SGX server for storage.

The SGX client 1 maintains private data 1 for secure multiparty computing and a shared key 1 for encrypted transmission of the private data 1, and the SGX client 1 may encrypt the private data 1 through the shared key 1 to obtain a data ciphertext 1, and encrypt the shared key 1 through the RSA public key to obtain a key ciphertext 1.

The SGX client 1 transmits the data ciphertext 1 and the key ciphertext 1 to the SGX server in an associated manner, and the SGX server stores the data ciphertext 1 and the key ciphertext 1. The data ciphertext 1 and the key ciphertext 1 may be stored in a storage space outside enclave, such as a hard disk on the SGX server. Because the data ciphertext 1 and the key ciphertext 1 are in an encrypted state, and the RSA private key is needed for decryption, but the RSA private key is encrypted by the SGX server through the seal key to be stored as the RSA private key ciphertext, and the seal key is maintained by the CPU, the data ciphertext 1 and the key ciphertext 1 can be ensured to be in a safe state.

After the embodiment shown in fig. 4, the SGX service end complete machine may be migrated to the isolated domain where the SGX client 2 is located, or only the core hardware in the SGX service end may be migrated, and these core hardware and other hardware may be reassembled in the isolated domain to obtain the SGX service end' shown in fig. 3. However, since the CPU, the motherboard, and the like of the core hardware are not changed, the SGX server' after migration does not have a substantial difference from the SGX server before migration, and for ease of understanding, the following description is still made in the form of the SGX server.

FIG. 5 is a flow chart illustrating interactions within an isolated domain in accordance with an illustrative embodiment. As shown in fig. 5, the interaction process between the SGX server and the SGX client 2 may include the following steps:

step 501, the SGX server reads and stores the RSA private key ciphertext, the data ciphertext 1, and the key ciphertext 1.

If the complete machine is migrated, the SGX server can read the RSA private key ciphertext, the data ciphertext 1 and the key ciphertext 1 from the local after the SGX server is migrated and started. If the core hardware is migrated, the RSA private key ciphertext, the data ciphertext 1 and the key ciphertext 1 can be stored in an external memory, such as a mobile hard disk, a U disk and the like, before migration, and the data are ciphertext states without content leakage; then, by connecting the external memory to the SGX server, the SGX server can read the RSA private key ciphertext, the data ciphertext 1, the key ciphertext 1, and the like from the external memory.

Step 502, the SGX client 2 initiates negotiation to the SGX server.

In step 503, the SGX sends the remote authentication report, the Intel certificate chain, and the RSA public key to the SGX client 2.

If the whole machine is migrated, the SGX server can read the remote authentication report, the Intel certificate chain and the RSA public key from the local after the SGX server is migrated and started. If the core hardware is migrated, the remote authentication report, the Intel certificate chain and the RSA public key can be stored in an external memory, such as a mobile hard disk, a U disk and the like, before migration, and the data are all ciphertext states, so that content leakage cannot be caused; then, by connecting the external storage to the SGX server, the SGX server can read the remote authentication report, the Intel certificate chain, the RSA public key, and the like from the external storage.

Step 504, the SGX client 2 generates a data ciphertext 2 and a key ciphertext 2, and sends the data ciphertext 2 to the SGX server for storage.

The SGX client 2 performs trusted verification on enclave on the SGX server based on the remote authentication report, the Intel certificate chain, and the RSA public key, and this process may refer to the verification operation performed by the SGX client 1 based on step 406 and step 407 shown in fig. 4, which is not described herein again. After the verification is completed, if enclave is determined to be trusted, the SGX client 2 may encrypt the private data 2 by using the shared key 2 to obtain a data ciphertext 2, and encrypt the shared key 2 by using the RSA public key to obtain a key ciphertext 2.

And 505, the SGX server generates a seal key and decrypts the RSA private key ciphertext.

The SGX server derives the seal key from the RSK stored in the CPU based on the information of the core hardware of the SGX server. No matter the SGX server is subjected to complete machine migration or partial migration, the SGX server can be ensured to derive the same seal key in a public network or an isolated domain as long as the core hardware is ensured to participate in the migration process, so that the RSA private key ciphertext obtained by encrypting in the step is decrypted, and the RSA private key is obtained. The SGX server reads the RSA private key ciphertext into enclave, and decrypts the RSA private key ciphertext in the enclave through the seal key to obtain the RSA private key.

Step 506, the SGX server decrypts the key ciphertext 1 and the key ciphertext 2.

Because the key ciphertext 1 and the key ciphertext 2 are obtained by encrypting the RSA public key, the SGX server decrypts the key ciphertext 1 and the key ciphertext 2 by using the RSA private key, and can smoothly obtain the corresponding shared key 1 and the shared key 2. The SGX server reads the key ciphertext 1 and the key ciphertext 2 into enclave, and decrypts the key ciphertext 1 and the key ciphertext 2 in the enclave through RSA public keys respectively to obtain a corresponding shared key 1 and a corresponding shared key 2.

And step 507, the SGX server decrypts the data ciphertext 1 and the data ciphertext 2.

Since the data ciphertext 1 and the data ciphertext 2 are obtained by encrypting the shared key 1 and the shared key 2, respectively, the SGX server may decrypt the data ciphertext 1 using the shared key 1 to obtain the private data 1, and decrypt the data ciphertext 2 using the shared key 2 to obtain the private data 2. The SGX server reads the data ciphertext 1 and the data ciphertext 2 into enclave, and decrypts the data ciphertext 1 and the data ciphertext 2 in the enclave through the shared key 1 and the shared key 2 respectively to obtain the private data 1 and the private data 2.

Step 508, perform secure multiparty computation.

And the SGX server side performs secure multi-party calculation on the private data 1 and the private data 2 in enclave to obtain corresponding calculation results.

In step 509, the SGX server sends the calculation result to the SGX client 2.

If the SGX client 2 is the data demanding party, the SGX server may perform secure multiparty computation within the isolated domain, so as to send the computation result to the SGX client 2 within the isolated domain. The SGX server may encrypt the calculation result by using the shared key 2, and then send the calculation result ciphertext to the SGX client 2, so that the SGX client 2 may decrypt the calculation result smoothly, and there is no need to worry about data leakage occurring in the transmission process.

Similarly, if the SGX client 1 is the data demander, the SGX server may be migrated from the quarantine domain, and then the calculation result may be sent to the SGX client 1. The SGX server may encrypt the calculation result by using the shared key 1, and then send the calculation result ciphertext to the SGX client 1, so as to improve security.

FIG. 6 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 6, at the hardware level, the apparatus includes a processor 602, an internal bus 604, a network interface 606, a memory 608 and a non-volatile memory 610, but may also include hardware required for other services. The processor 602 reads the corresponding computer program from the non-volatile memory 610 into the memory 608 and then runs, forming a device for cross-domain secure multi-party computing based on a trusted execution environment on a logical level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Referring to fig. 7, in a software implementation, the apparatus for cross-domain secure multi-party computing based on a trusted execution environment may include:

an environment creating unit 701 that causes the secure computing server to create a trusted execution environment for secure multiparty computing;

a report acquisition unit 702 that causes the secure computing server to acquire a trusted authentication report for the trusted execution environment; in a computing side public and private key pair generated by the trusted execution environment, a computing side private key is encrypted by a security key maintained by the security computing server to form a computing side private key ciphertext;

a first ciphertext obtaining unit 703, configured to send the trusted authentication report to a first computation participant for verification when the secure computation server is outside an isolation domain, and receive a first data ciphertext and a first key ciphertext returned by the first computation participant after the first computation participant passes verification confirmation, where the first data ciphertext is obtained by encrypting a first shared key maintained by the first computation participant, and the first key ciphertext is obtained by encrypting the first shared key with a public key on a computation side;

a second ciphertext obtaining unit 704, configured to, when the whole secure computing server or at least core hardware related to generating the secure key is migrated into an isolated domain, send the trusted authentication report to a second computing party in the isolated domain for verification, and receive a second data ciphertext and a second key ciphertext returned by the second computing party after the second computing party passes verification confirmation, where the second data ciphertext is obtained by encrypting a second shared key maintained by the second computing party, and the second key ciphertext is obtained by encrypting the second shared key with a computing-side public key;

the multiparty computation unit 705 enables the secure computing server to decrypt the computation-side private key ciphertext in the trusted execution environment by using the secure key to obtain the computation-side private key, decrypt the first key ciphertext and the second key ciphertext by using the computation-side private key respectively, decrypt the first data ciphertext and the second data ciphertext by using the obtained first shared key and the obtained second shared key respectively to obtain a first data plaintext and a second data plaintext, and perform multiparty computation according to the first data plaintext and the second data plaintext.

Optionally, the report obtaining unit 702 is specifically configured to:

causing the secure computing server to generate an authentication request for the trusted execution environment;

and enabling the secure computing server to receive the trusted authentication report returned by an authentication server, wherein the trusted authentication report is returned after the authentication server performs trusted authentication on the trusted execution environment according to the authentication request.

Optionally, the trusted authentication report is signed by the authentication server; the device further comprises:

a certificate chain sending unit 706, configured to enable the secure computing server to send certificate chains corresponding to the authentication servers to the first computing participant and the second computing participant, respectively, so that the first computing participant and the second computing participant check and sign the trusted authentication report; wherein a root key is maintained at the first and second computing participants for verifying the certificate chain.

Optionally, the authentication request includes a hash value of the public key on the computing side, and the trusted authentication report includes the authentication request; the device further comprises:

a public key sending unit 707, configured to cause the secure computing server to send the computing-side public keys to the first computing participant and the second computing participant, respectively, so that the first computing participant and the second computing participant verify the hash value included in the authentication request.

Optionally, in a case that the core hardware is migrated into the isolated domain, and is assembled with other hardware and then runs to form the secure computing server, the apparatus further includes:

a first migration unit 708 that causes the secure computing server to write the computing-side private key ciphertext into an external memory when the secure computing server is outside the isolated domain, and to read the computing-side private key ciphertext from the connected external memory after migrating into the isolated domain; or after the secure computing server is in the isolated domain, writing the computing side private key ciphertext into an external memory, and after the secure computing server is migrated out of the isolated domain, reading the computing side private key ciphertext from the connected external memory.

a second migration unit 709, configured to enable the secure computing server to write the first data ciphertext and the first key ciphertext into an external memory when the secure computing server is outside an isolated domain, and read the first data ciphertext and the first key ciphertext from the connected external memory after migrating into the isolated domain; or after the security computing server is in the isolated domain, writing the second data ciphertext and the second key ciphertext into an external memory, and after the security computing server is migrated out of the isolated domain, reading the second data ciphertext and the second key ciphertext from the connected external memory.

Optionally, the security key includes: a secure root key, or a derivative of the secure root key, that is unique and maintained only by the secure compute server.

Optionally, the secure key is derived by the secure computation server according to the secure root key and the information of the core hardware.

Optionally, the method further includes:

and a result sending unit 710, which enables the secure computing server to send the multi-party computing result to the data demand party.

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. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

In a typical configuration, a computer 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 non-transitory and non-transitory, removable and non-removable media, may implement 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 Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that 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.

It should also be noted that 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, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. A trusted execution environment based cross-domain secure multi-party computing method, comprising:

2. The method of claim 1, the secure computing server obtaining a trusted authentication report for the trusted execution environment, comprising:

the secure computing server generating an authentication request for the trusted execution environment;

and the security computing server receives the credible authentication report returned by the authentication server, and the credible authentication report is returned after the authentication server carries out credible authentication on the credible execution environment according to the authentication request.

3. The method of claim 2, the trusted authentication report being signed by the authentication server; the method further comprises the following steps:

the secure computing server sends certificate chains corresponding to the authentication servers to the first computing party and the second computing party respectively so that the first computing party and the second computing party can check and sign the trusted authentication report; wherein a root key is maintained at the first and second computing participants for verifying the certificate chain.

4. The method of claim 2, the authentication request including therein a hash value of the computing-side public key, and the authentication request being included in the trusted authentication report; the method further comprises the following steps:

and the secure computing server respectively sends the computing side public keys to the first computing party and the second computing party so that the first computing party and the second computing party can verify the hash value contained in the authentication request.

5. The method of claim 1, in the case where the core hardware is migrated into the isolated domain and assembled with other hardware to run to form the secure compute server, further comprising:

the secure computing server writes the computing side private key ciphertext into an external memory under the condition that the secure computing server is outside an isolation domain, and reads the computing side private key ciphertext from the connected external memory after migrating into the isolation domain; alternatively, the first and second electrodes may be,

and the secure computing server writes the computing side private key ciphertext into an external memory after being in the isolated domain, and reads the computing side private key ciphertext from the connected external memory after migrating to the outside of the isolated domain.

6. The method of claim 1, in the case where the core hardware is migrated into the isolated domain and assembled with other hardware to run to form the secure compute server, further comprising:

the secure computing server writes the first data ciphertext and the first key ciphertext into an external memory when the secure computing server is outside an isolation domain, and reads the first data ciphertext and the first key ciphertext from the connected external memory after migrating into the isolation domain; alternatively, the first and second electrodes may be,

and the secure computing server writes the second data ciphertext and the second key ciphertext into an external memory after being in the isolated domain, and reads the second data ciphertext and the second key ciphertext from the connected external memory after migrating to the outside of the isolated domain.

7. The method of claim 1, the security key comprising: a secure root key, or a derivative of the secure root key, that is unique and maintained only by the secure compute server.

8. The method of claim 7, the secure key derived by the secure compute server from the secure root key and information of the core hardware.

9. The method of claim 1, further comprising:

and the safety calculation server sends the multi-party calculation result to the data demand party.

10. An apparatus for cross-domain secure multi-party computing based on a trusted execution environment, comprising:

11. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-9 by executing the executable instructions.

12. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 9.