Multi-party privacy intersection method and system in trusted execution environment

Abstract

The invention provides a multi-party privacy intersection method and system in a trusted execution environment, a business application and a database which run independently are deployed in the trusted execution environment, and the method comprises the following steps: responding to a virtual report request sent by a first client, returning a credible certificate containing the public key of the credible execution environment to the first client, so that the first client performs credibility verification on the credible execution environment; receiving a multi-party privacy data intersection calculation request sent by the first client, and obtaining privacy data provided by each second client in the calculation request from the database through the service application; and through the service application, performing intersection calculation based on the acquired private data, encrypting a calculation result through a private key of the trusted execution environment, and returning the calculation result to the first client, so that the first client performs decryption based on the public key to obtain the calculation result.

Description

Technical Field

[0001] This specification relates to the technical field of trusted execution environments, and particularly to a multi-party private set intersection method and system in a trusted execution environment. Background Art

[0002] A trusted execution environment (TEE) is a hardware isolation technology that provides a secure operating environment to ensure that sensitive data and code cannot be accessed or tampered with externally during processing. TEE is widely applied in various scenarios such as cloud computing, data analysis, financial services, medical information, Internet of Things, and enterprise data sharing to provide secure data computing and privacy protection, ensuring the confidentiality and integrity of sensitive information during processing and transmission.

[0003] In the prior art, with the increasing demand for multi-party data collaboration, how to improve the efficiency of multi-party private data set intersection while ensuring data security has become an urgent problem to be solved. Since the TEE technology is "stateless", that is, the TEE environment is deployed when the device starts up, data is transmitted to the TEE environment to execute the service, and when the device shuts down, the operation stops and the data in the TEE environment is cleared.

[0004] It can be seen that in the business scenario of multi-party private data set intersection, although applying the TEE technology improves security, there is still a situation where the data provider needs to transmit the same data to the TEE environment of the same device multiple times, resulting in difficulty in improving the service execution efficiency.

[0005] Based on this, this specification provides a multi-party private set intersection solution in a trusted execution environment to solve the problems existing in the prior art. Summary of the Invention

[0006] In view of this, this specification provides a multi-party private set intersection method in a trusted execution environment to solve the deficiencies existing in the related art.

[0007] Specifically, this specification is implemented through the following technical solutions:

[0008] According to the first aspect of the embodiments of this specification, a multi-party private set intersection method in a trusted execution environment is provided. The method is applied to a server, and a service application and a database that operate independently of each other are deployed in the trusted execution environment of the server, including:

[0009] In response to a virtual report request sent by a first client, return a trusted certificate containing the public key of the trusted execution environment to the first client, so that the first client performs a trustworthiness verification on the trusted execution environment;

[0010] Receive the calculation request for multi-party private data intersection sent by the first client, and obtain the private data provided by each second client in the calculation request from the database through the business application;

[0011] Through the business application, perform intersection calculation based on the obtained private data, and after encrypting the calculation result with the private key of the trusted execution environment, return it to the first client, so that the first client decrypts it based on the public key to obtain the calculation result.

[0012] According to the second aspect of the embodiments of this specification, a multi-party private intersection method in a trusted execution environment is provided. The method is applied to the first client and includes:

[0013] Send a virtual report request to the trusted execution environment of the server to obtain a trusted certificate containing the public key of the trusted execution environment. The business application and the database that operate independently of each other are deployed in the trusted execution environment;

[0014] In response to the successful verification of the trustworthiness of the trusted certificate, generate a calculation request for multi-party private data intersection based on the private data required for the intersection calculation, and send it to the business application, so that the business application accesses the database to obtain the private data provided by each second client in the calculation request, and completes the intersection calculation in the trusted execution environment;

[0015] Receive the calculation result encrypted with the private key of the trusted execution environment returned by the business application, and decrypt it based on the public key to obtain the calculation result.

[0016] According to the third aspect of the embodiments of this specification, a multi-party private intersection method in a trusted execution environment is provided. The method is applied to the second client, where:

[0017] Send a virtual report request to the trusted execution environment of the server to obtain a trusted certificate containing the public key of the trusted execution environment. The business application and the database that operate independently of each other are deployed in the trusted execution environment;

[0018] In response to the successful verification of the trustworthiness of the trusted certificate, send the private data to be stored to the database for storage;

[0019] The private data stored in the database is used to support the intersection calculation based on the private data initiated by the first client, where: the first client sends a calculation request for multi-party private data intersection to the business application, the business application obtains the private data from the database for intersection calculation, and encrypts the calculation result with the private key of the trusted execution environment and returns it to the first client, and the first client decrypts it with the public key to obtain the calculation result.

[0020] According to a fourth aspect of the embodiments of the present specification, an electronic device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the steps of the method described in any one of the first to third aspects are implemented.

[0021] According to a fifth aspect of the embodiments of the present specification, a computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the steps of the method described in any one of the first to third aspects are implemented.

[0022] According to a sixth aspect of the embodiments of the present specification, a computer program product is provided, including a computer program / instructions. When the computer program / instructions are executed by a processor, the steps of the method described in any one of the first to third aspects are implemented.

[0023] In the technical solution provided in the present specification, a service application and a database that operate independently of each other are established in the TEE of the server. Among them, the data provider provides privacy data through its own second client and stores it in the database. Then, when the first client obtains the public key of the TEE through remote authentication, it can send a calculation request to the service application. The service application then accesses the independently operating database to obtain the privacy data required for the calculation for intersection calculation. Finally, the service application encrypts the calculation result based on the private key of the TEE and returns it to the first client, and the first client obtains the plaintext of the calculation result through the public key. It can be seen that by constructing a database within the TEE, the ability to pre-store privacy data is realized, the temporary data transmission requirements during multi-party intersection calculation are reduced, and the efficiency of business execution is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 is a schematic flowchart of a multi-party privacy intersection method in a trusted execution environment shown in an exemplary embodiment of the present specification;

[0025] Figure 2 is a schematic diagram of a trusted execution environment of a server shown in an exemplary embodiment of the present specification;

[0026] Figure 3 is a schematic flowchart of a multi-party privacy intersection method in a trusted execution environment shown in an exemplary embodiment of the present specification;

[0027] Figure 4 is a schematic flowchart of a multi-party privacy intersection method in a trusted execution environment shown in an exemplary embodiment of the present specification;

[0028] Figure 5 is a schematic diagram of multi-party privacy intersection interaction in a trusted execution environment shown in an exemplary embodiment of the present specification;

[0029] Figure 6 It is a schematic structural diagram of an electronic device shown in an exemplary embodiment of this specification;

[0030] Figure 7 It is a schematic structural diagram of a multi-party private set intersection device in a trusted execution environment shown in an exemplary embodiment of this specification;

[0031] Figure 8 It is a schematic structural diagram of a multi-party private set intersection device in a trusted execution environment shown in an exemplary embodiment of this specification;

[0032] Figure 9 It is a schematic structural diagram of a multi-party private set intersection device in a trusted execution environment shown in an exemplary embodiment of this specification. Detailed implementation manners

[0033] A trusted execution environment (TEE) is a security mechanism in modern computing devices. It provides an isolated execution environment for applications to ensure that data and code are protected from external software attacks during processing. The TEE protects sensitive information through hardware-level isolation, so that even if the operating system or other applications are compromised, the data stored in the TEE remains secure. The TEE usually supports running specially designed security applications, which can process sensitive data such as encryption keys and personal identity information. For example, when a user uses fingerprint payment, the comparison process of fingerprint data is not completed in the ordinary operating system, but is executed inside the TEE, ensuring that even if the device is invaded by malware, attackers cannot steal or tamper with key information. This isolation not only relies on the support of physical hardware, but also requires strict constraints on resource scheduling and permission management of the security area through a trusted operating system.

[0034] Although there are currently various TEE technology implementation solutions, they all lack a solution for multi-party private set intersection (PSI). Since the underlying architecture of the TEE is a hardware-level isolation mechanism and the mechanism overly focuses on single-party data protection, there is no real support for multi-party collaboration scenarios, and no lightweight interaction channels are designed for the characteristics of multi-party intersection calculation. These problems seriously restrict the implementation and application of TEE technology in key industries.

[0035] As mentioned above, TEE is a "stateless" technology, that is, "stateful" data is not stored in TEE. For example, when using TEE for multi-party secure computing, the data providers of each piece of private data need to first receive a computing request, then determine the private data to be provided, and then transmit it into the TEE environment for intersection calculation. It can be seen that the TEE environment does not have the function of pre-storing private data, and all private data participating in the calculation is "stateless" and is only obtained when needed. This makes it necessary to start obtaining private data from the data provider every time during the intersection calculation through TEE, and then perform the intersection calculation. This not only greatly increases the communication cost between the data provider and the server TEE, but also increases the complexity of business execution, making it difficult to improve the business efficiency of intersection calculation through TEE.

[0036] Moreover, when using TEE for intersection calculation, although it can ensure that data does not leave the domain, it is still difficult to avoid attackers inferring private data through side-channel attacks. Specifically, side-channel attacks do not directly break the encryption algorithm or access protected data, but infer sensitive information by analyzing the behavioral characteristics of the system, such as time consumption, power consumption patterns, electromagnetic leakage and other indirect information. Common side-channel attacks include but are not limited to: cache timing attacks and retired load attacks. Cache timing attacks utilize the working principle of the CPU cache. For example, in Intel Software Guard Extensions (Intel SGX) technology, it is allowed to create TEEs, so-called "enclaves", on the CPU. These enclaves provide an isolated running space for applications to protect sensitive data and code from attacks by the operating system, BIOS or other software. However, the code and data in the SGX enclaves may share some cache resources with the outside world, and attackers can infer information about the internal operations of the enclaves by observing the time patterns of cache accesses. Retired load attacks are a specific type of side-channel attack that relies on an understanding of the internal architecture details of the processor, such as the speculation execution mechanism. Attackers can construct special code sequences so that even after an instruction is cancelled, data that should not be accessed can still be read from the cache.

[0037] Since the process of TEE multi-party calculation shown above requires obtaining private data every time before performing the intersection calculation. Therefore, there may be a situation where a data provider provides the same private data to TEE multiple times within a period of time for different intersection calculations. This makes it easier for attackers to obtain private data through side-channel attacks.

[0038] In summary, the current TEE technology itself is not specifically designed for multi-party private set intersection, and there are still limitations in supporting multi-party private set intersection scenarios. Based on this, this specification proposes a multi-party private set intersection solution in a trusted execution environment, which will be introduced in detail below with reference to the accompanying drawings.

[0039] Figure 1 It is a schematic flowchart of a multi-party private set intersection method shown in an exemplary embodiment of this specification. As Figure 1 shown, this method is applied to a server, and an independent business application and a database are deployed in the trusted execution environment of the server. This method may include the following steps:

[0040] In one or more embodiments of this specification, the multi-party private set intersection process involves a server providing the set intersection service, a first client submitting a set intersection calculation request, and a second client providing private data. Among them, for the server, it is necessary to establish a TEE after startup, and deploy a database and a business application in this TEE environment respectively, so as to store the private data provided by the second client in the TEE environment through the database, and complete the multi-party private data set intersection process through the business application using the data stored in the database within the TEE. Of course, since the server in this specification needs to set up a TEE, this server is generally a single device to avoid the problems of large consumption of interaction resources and complex process caused by setting up TEE on multiple devices.

[0041] Specifically, the process of enabling the TEE involves multiple steps, including hardware and software configuration, secure boot settings, and application deployment. The following is the general process for the server to enable the TEE. The specific steps may vary depending on the hardware platform and software stack used. Of course, for the embodiments of this specification, it is not limited to implementing this process on a server of a specific type of hardware. The following process is only a general implementation method. If specific models or programs are involved, they can be adjusted as needed without affecting the implementation of the embodiments of this specification.

[0042] First, the server needs to ensure that the hardware supports the TEE technology. For example, it can be confirmed by checking the CPU specifications or using tools. Or, the processor documentation can also be consulted or the supplier can be contacted for confirmation. This specification does not make specific limitations on the judgment method. Of course, in this specification, the example of the server's hardware supporting the TEE technology is continued for illustration.

[0043] Secondly, the server can enable the TEE-related functions in the BIOS or UEFI to ensure sufficient memory, CPU threads, and bandwidth are allocated for the TEE.

[0044] After that, it is determined whether the necessary drivers and libraries that support the TEE technology are installed in the operating system of the server. If not, they are obtained from the corresponding third party.

[0045] Then, the server can be configured for secure boot to ensure that the system boots from a trusted state. For example, a signature database is configured to allow only verified code to run on the system. Alternatively, by configuring a detection tool, ensure that all firmware and boot loaders are signature-verified.

[0046] Finally, a database for independent data storage is deployed inside the TEE environment. This database is used to store the private data provided by the data providers in the intersection calculation. There is no limitation in this specification on what specific type of database it is. For example, databases such as SQLite and Redis (Remote Dictionary Server) can be used. This database runs independently in the TEE to enhance the security of the data it stores and reduce the effect of side-channel attacks.

[0047] In addition, the server can also deploy a business application in the TEE. This business application is used to obtain the private data required for the calculation from the database according to the calculation request sent by the requestor of the intersection calculation through the first client, perform the intersection calculation, and return the encrypted calculation result to the first client of the calculation requestor.

[0048] It should be noted that in the embodiments of this specification, the first client and the second client are named only based on the roles played by the client in the process of intersecting multi-party private data. For example, when Company A provides private data to the database of the TEE through the client, the client of Company A is the second client. When Company A initiates a calculation request, the client of Company A is the first client. That is to say, the first client and the second client can be clients of different users or the same client. The first client and the second client are only convenient for distinguishing the roles of the client in the intersection calculation service in the embodiments.

[0049] Figure 2Schematic diagram of the server provided by the embodiments of this specification. It can be seen that there are business applications and databases in the TEE environment. The business applications and databases operate independently of each other. Data transmission between the two can be achieved through threads within the TEE, avoiding the exposure of private data outside the TEE. Among them, for the second client, since it is the data provider, the process of data storage is completed through interaction with the database. For the first client, since it requests intersection calculation instead of operating on the data in the database, the calculation request is sent to the business application, and the business application obtains data from the database for calculation. Since it is unknown to the outside world whether there is a database within the TEE and what data the database stores, attacks similar to side-channel attacks are more difficult to implement.

[0050] Step 100, in response to a virtual report request sent by the first client, return a trusted certificate containing the public key of the trusted execution environment to the first client, enabling the first client to perform a trust verification on the trusted execution environment.

[0051] In one or more embodiments of this specification, after the TEE is deployed on the server, it can wait for a virtual report request (Attestation Report) sent by the first client that needs to perform multi-party calculation to carry out the process of remote authentication. Among them, the process of remote authentication is mainly for the first client to verify whether the TEE environment is trusted and obtain the public key of the TEE, so as to ensure that the data transmitted between the first client and the TEE can be protected by asymmetric encryption. The specific advantages are similar to the effects of using asymmetric encryption technology during existing data transmission, and this specification will not elaborate.

[0052] Specifically, first, the virtual report request is generated by the first client. Before the first client executes the intersection calculation service through the TEE, it needs to first verify whether the TEE environment is reliable. Therefore, the first client can first create a virtual report request containing a random number or a challenge value (nonce). Among them, the random number or challenge value in the virtual report request is a value generated by the first client to prevent replay attacks, and each request can be ensured to be unique through this value. This request may also include some data about the identity of the first client or other context information, but the core purpose is to ensure that the subsequent response is generated for this specific request. Then, the first client can send this virtual report request to the TEE of the server. This request is usually transmitted through a secure channel to ensure that the data will not be eavesdropped or tampered with during the transmission process.

[0053] For this server, the application or business module for performing remote authentication can receive a virtual report request sent by the first client. For ease of description, in the subsequent specification, the remote authentication module's response to the virtual report request will be used as an example for illustration. After receiving the virtual report request, the remote authentication module of the TEE can generate a trusted certificate containing information about the status of the TEE. The information about the TEE status contained in the trusted certificate is used to prove that the TEE is operating in the expected manner and has not been tampered with. Then the remote authentication module can sign the trusted certificate using the private key of the TEE. Finally, the public key of the TEE, the signature, and the trusted certificate are returned to the first client. Of course, the public key of the TEE can also be provided to the first client in other ways. For example, the TEE pre-provides its own public key to a trusted third party, and the first client obtains the public key through the trusted third party. However, generally, the public key is returned to the first client by the remote authentication module after receiving the virtual report request. The first client can then verify the signature based on the public key and determine whether the trusted certificate has been tampered with.

[0054] It should be noted that the trusted certificate is signed by the private key of the TEE, enabling the client to verify whether it has been tampered with based on the public key of the TEE and to verify the integrity of the trusted certificate. For example, by comparing the hash value in the trusted certificate with a list of known good hash values to further confirm the status of the TEE.

[0055] In one or more embodiments of this specification, after generating the trusted certificate, the remote authentication module can send the trusted certificate to the first client, enabling the first client to verify whether the TEE is secure and trusted. After the first client confirms the trust, the business can continue to be executed.

[0056] Specifically, the remote authentication module can return the generated trusted certificate to the first client through the server. After receiving the trusted certificate returned by the server, the first client, in response to the trusted certificate, verifies the certificate chain provided by the TEE of the server. This includes the validity, expiration date, issuer, and signature of the certificate. If all verifications are successful, it indicates that the TEE of the server is trusted. Among them, the information about the TEE status contained in the trusted certificate is used by the first client to determine whether the TEE of the server is in the expected secure state. Similarly, the first client uses the public key of the TEE to verify the signature to confirm that the trusted certificate was indeed generated by a legitimate TEE and has not been tampered with, which is called signature verification. The first client can first determine the certificate chain where the certificate is located through the trusted certificate and finally trace back to a trusted root certificate authority (Root CA), then it can determine the authenticity and validity of the certificate, which is called certificate chain verification.

[0057] Step 102: Receive the calculation request for multi-party private data intersection sent by the first client, and obtain the private data provided by each second client in the calculation request from the database through the business application.

[0058] In one or more embodiments of this specification, after the first client verifies the trustworthiness of the TEE based on a trusted certificate, it can send a calculation request for multi-party private data intersection to the TEE. The business application of the server can then perform an intersection calculation based on the private data stored in the database of the TEE in response to the calculation request.

[0059] Since in the embodiments provided in this specification, the private data in the database within the TEE is provided by the second client historically, rather than the existing method of obtaining private data from the data provider only when multi-party data intersection calculation is required. Therefore, when the first client initiates a calculation request, the corresponding private data has already been stored in the database of the TEE. Thus, no private data needs to be carried in the calculation request, and the business application of the server does not need to obtain private data from the data provider based on the calculation request either. Instead, it directly obtains the private data required for the calculation from the database of the TEE, which not only makes the service response faster but also makes it difficult for attackers to intercept private data by attacking the calculation request.

[0060] That is to say, by separating the process of providing private data and the process of using private data for intersection calculation, it is difficult for attackers to trace private data, reducing the risk of data leakage during multi-party private data intersection calculation. For example, the second client uploaded three groups of data A - C in the last three days respectively. On the fourth day, the first client performs an intersection calculation based on one of the data. Then, even if the attacker knows that the intersection calculation uses the data provided by the second client, it is difficult to determine which private data is actually used for the calculation. Even if the attacker can obtain the running characteristics of the server, it is also difficult to summarize the rules to crack the private data. Moreover, the second client can continuously update the private data provided in the database. In this case, it is even more difficult for the attacker to summarize the rules and crack the private data through side-channel attacks.

[0061] Specifically, first, after the server receives the calculation request, it can send the calculation request to the business application in the TEE.

[0062] After that, based on the calculation request, the business application determines the identifiers of the second clients that are the data providers of the private data to be calculated and each data identifier. Since there are multiple different data providers who have provided private data through their respective second clients historically, not all the private data stored in the database needs to be used for the intersection calculation. Therefore, the business application needs to determine which private data stored by which second clients should be obtained based on the identifier of the second client and the data identifier.

[0063] Secondly, after determining the identifiers of each second client involved in the intersection calculation, the service application can, for each determined second client, determine a query request according to the identifier of the second client and the data identifier. Specifically, the service application can construct a query request according to the requirements of the database. For example, for an SQlite database, an SQ query statement is constructed according to the identifier of the second client and the data identifier.

[0064] Subsequently, the service application calls the interface of the database, sends the determined query requests to the database, and respectively obtains the private data required for the intersection calculation retrieved by the database according to each query request.

[0065] Step 104: Through the service application, perform an intersection calculation based on the obtained private data, encrypt the calculation result with the private key of the trusted execution environment, and return it to the first client, so that the first client decrypts it based on the public key to obtain the calculation result.

[0066] In one or more embodiments of this specification, after the service application of the server obtains the private data required for the calculation by accessing the database, it can perform an intersection calculation according to each private data in the trusted execution environment to determine the calculation result. If the private data stored in the database is data encrypted with the public key of the TEE, the service application decrypts the private data obtained from the database respectively with the private key of the trusted execution environment to obtain the plaintext data, and finally performs an intersection calculation according to the plaintext data in the trusted execution environment to determine the calculation result.

[0067] Finally, in one or more embodiments of this specification, the service application in the server TEE returns the obtained calculation result to the first client. Moreover, to improve data security, the service application can also encrypt the calculation result with the private key of the TEE.

[0068] Specifically, the service application can determine the private key of the TEE. Then, use the private key of the TEE to encrypt the calculation result and return it to the first client. Then the first client can decrypt the encrypted calculation result according to the public key of the TEE obtained during the previous remote authentication process to obtain the calculation result of the multi-party private intersection.

[0069] In summary, in the technical solution provided in this specification, a service application and a database that operate independently of each other are established in the TEE of the server. Among them, the data provider provides privacy data through its own second client and stores it in the database. Then, when the first client obtains the public key of the TEE through remote authentication, it can send a calculation request to the service application. The service application accesses the independently operating database to obtain the privacy data required for the calculation and performs an intersection calculation. Finally, the service application encrypts the calculation result based on the private key of the TEE and returns it to the first client, and the first client obtains the plaintext of the calculation result through the public key. It can be seen that by constructing a database within the TEE, the ability to pre-store privacy data is achieved, the requirement for temporary data transmission during multi-party intersection calculation is reduced, and the efficiency of business execution is improved.

[0070] In addition, in the embodiments of this specification, in order to further improve the security of the privacy data in the database, before storing the privacy data, the database can encrypt the privacy data with the public key of the TEE. In this way, even if the privacy data is leaked due to an accident, the attacker cannot obtain the plaintext of the privacy data.

[0071] Of course, in this case, the privacy data obtained by the service application from the database in step 104 is the privacy data encrypted with the public key. Then, before performing the intersection calculation, the privacy data can be decrypted with the private key of the TEE to obtain the plaintext of the privacy data, and then the intersection calculation is performed based on the plaintext. The calculation result is encrypted with the private key and returned to the first client as described in step 104.

[0072] It should be noted that in this specification, the server in the TEE can receive and store the privacy data sent by the second client after the TEE is deployed. That is, the privacy data in the database are all the privacy data obtained during the current TEE life cycle. In this way, as long as the TEE environment has not stopped running, the privacy data in this database can be reused for intersection calculation without having to obtain the privacy data from the data provider in real time during the intersection calculation.

[0073] Of course, the privacy data used in the above intersection calculation process is described by taking the database as an example. This is because this specification provides a means to pre-store privacy data, and the data providers in multi-party calculation can generally provide fixed data for multi-party calculation. Therefore, pre-providing this privacy data can meet the requirements of intersection calculation in general cases and improve business efficiency.

[0074] The database within the TEE is cleared when the TEE stops running. This means that when the server restarts, a large amount of private data needs to be retrieved again to reconstruct the database. As a result, the second client may need to repeatedly provide private data at the start of each TEE lifecycle. For example, if the TEE lifecycle is one week, the data provider may need to repeatedly provide the same private data every week to build the database in the TEE.

[0075] In one or more embodiments of this specification, to further reduce the need for data transmission, the server can back up the database before the end of the TEE lifecycle.

[0076] Specifically, before the end of the TEE lifecycle, the server can use the public key of the TEE to encrypt the database, and then store it in the non-volatile memory of the server, such as a hard disk.

[0077] After that, in response to reconstructing the TEE in the server, the public key-encrypted database is retrieved from the non-volatile memory and stored in the TEE. That is, the data stored in the hard disk is transferred back to the TEE environment.

[0078] Finally, the database is decrypted using the private key of the TEE to deploy the database in the trusted execution environment.

[0079] Among them, in this process, since the backup uses the public key of the TEE for encryption and the restoration uses the private key of the TEE for decryption, and the public key and private key are generated in two different TEE lifecycles, therefore, in this specification, it is at least required that the TEE generates consistent asymmetric key pairs during backup and restoration. For example, the asymmetric key pairs are constructed based on the same type of information.

[0080] Of course, since the asymmetric key pairs of the TEE are not immutable within the lifecycle, when updating the asymmetric key pairs within the lifecycle, the above issues do not need to be considered. If the private data in the TEE database is encrypted with the public key, then when updating the asymmetric key pairs, it is necessary to re-determine the plaintext of the private data and encrypt it with the newly generated public key.

[0081] In addition, if the entire database is directly encrypted during backup, it requires higher storage requirements and the encryption process takes a longer time. Therefore, to improve efficiency and reduce storage difficulty, in the embodiments of this specification, the database within the TEE can also be split first to obtain multiple data fragments. Then, each data fragment is encrypted with the public key and stored separately in the non-volatile memory of the server.

[0082] When the database needs to be restored, first decrypt each data segment according to the private key of the TEE. Then, reconstruct the database based on the decrypted data segments and deploy it in the trusted execution environment.

[0083] In the embodiments of this specification, the process of the second client storing private data in the database may include:

[0084] First, in response to the virtual report request sent by the second client, the server returns a trusted certificate containing the public key to the second client, enabling the second client to perform a trust verification on the trusted execution environment.

[0085] This process can refer to the content corresponding to the first client sending a virtual report request in step 100, which is not elaborated in this specification.

[0086] Second, receive the database operation request sent by the second client. The private data carried in the database operation request is encrypted by the public key of the trusted execution environment.

[0087] In the embodiments of this specification, when the second client verifies the trust of the TEE based on the trusted certificate, it can send a database operation request to the database to adjust the private data stored in the database.

[0088] Finally, decrypt the private data with the private key of the trusted execution environment and update the database according to the database operation request.

[0089] Specifically, the database operation request can be divided into four types: addition, deletion, modification, and query.

[0090] The addition operation is to write data. In the database operation request received by the database, the private data to be written is carried. This private data is encrypted by the public key of the second client through the TEE. The database can directly generate an index of the private data and store it in the database. Or, the database can also first decrypt it with the private key of the TEE to obtain the plaintext, confirm that the data is okay, such as whether the format is normal, and then update the database after encrypting it with the public key.

[0091] For the deletion operation, the database can verify whether the private data to be deleted is the data provided by the second client. If so, delete the corresponding private data to complete the update of the database.

[0092] For a modification operation, the database operation request carries the private data to be modified and the index of the modified private data. Then the database can decrypt the private data to be modified in the database and the plaintext of the modification content through the private key, and perform calculations to determine the modified result. For example, if the plaintext value of the private data stored in the original database is 10 and the plaintext of the modification content is -5, then the determined modified plaintext is 5. Then it is encrypted with the public key of the TEE and stored in the database to complete the data update.

[0093] For a query operation, the database operation request carries the index of the private data. After obtaining the corresponding private data according to the index, the private data is decrypted with the private key and then encrypted with the private key, and returned to the second client. The second client can then obtain the plaintext of the query result according to the public key.

[0094] It can be seen that in the embodiments of this specification, when updating the database according to the database operation request, as long as the operation is not a query operation, the database needs to be updated. Then it is necessary to first decrypt through the private key to obtain the plaintext data required for the database operation request. The required data can be carried in the database operation request or can also include the data already stored in the database. As described above, the different operation situations are different. After that, the database can determine the plaintext result corresponding to the database operation request based on the plaintext data. Finally, the plaintext result is encrypted with the public key, and the database is updated based on the encrypted data.

[0095] Furthermore, in the embodiments of this specification, when updating the database, in addition to updating the database in the TEE, the server can also update the database backup stored in its own non-volatile memory. Specifically, the server can encrypt the updated database with the public key and use the database encrypted with the public key to replace the database stored in the non-volatile memory of the server. Of course, similar to the previous embodiments, if the database is split into data segments for storage, it is also stored in the form of each data segment in the non-volatile memory.

[0096] In one or more embodiments of this specification, in the step of the second client providing private data, for data security, the second client can first encrypt the private data with the client key and then encrypt it with the public key. Then the database operation request sent by the second client also needs to carry the client key encrypted with the public key so that the database and the business application can obtain the plaintext of the private data.

[0097] After the database obtains the database operation request sent by the second client, it can first decrypt it with the private key to obtain the client key of the second client.

[0098] After that, through decryption with the private key and decryption with the client key, the plaintext of the private data carried in the database operation request of the second client is obtained. Since the decrypted private data is in plaintext, direct mathematical means can be used for calculation.

[0099] Furthermore, as time goes by, the security of the same key will gradually decrease during use. Therefore, to ensure data security, the server can also update the asymmetric key pair of the TEE.

[0100] Specifically, the server can determine the update time according to a preset update period. When the update time is reached, a new asymmetric key pair of the TEE is generated and the currently used asymmetric key pair is updated.

[0101] After that, using the same process described in step 100, update the trusted certificate of the trusted execution environment at least according to the newly generated public key and the certificate in the trust chain. Then, when any first client or second client sends a virtual report request through the remote authentication process next time, the server returns the updated trusted certificate. This approach can significantly improve the security of the system and help deal with various potential threats and attack scenarios. Once the long-term used asymmetric key pair is leaked, attackers can use the key for malicious activities for a long time. Regularly changing the key can shorten this window period and reduce potential damage. Moreover, even if no vulnerabilities are found currently, it is impossible to completely rule out potential unknown vulnerabilities in the future. Regularly changing the key can effectively reduce the risks brought by these unknown vulnerabilities.

[0102] In addition, if attackers can monitor the communication link for a long time, they may accumulate enough information to crack the key or conduct man-in-the-middle attacks. Regularly changing the key can break the effect of this continuous monitoring. This can also better avoid side-channel attacks. Since side-channel attacks may require long-term data collection to succeed, regularly changing the key can increase the difficulty for attackers and make it difficult for them to obtain enough data for effective attacks.

[0103] And updating the asymmetric key pair is equivalent to providing dynamic encryption means for the TEE. According to system status, external threat intelligence or other factors, the key update frequency can be flexibly adjusted. For example, when a potential threat is detected, the key update can be triggered immediately. And different application scenarios have different requirements for key updates. Through the periodic update mechanism, it is more convenient to configure appropriate update strategies for different scenarios.

[0104] In one or more embodiments of this specification, the server can also determine whether to actively provide the updated trusted certificate for different first clients or second clients.

[0105] Specifically, the server can first determine the historical service information of each first client and each second client when they executed services in the past.

[0106] Finally, based on the historical service information, at least some target clients are screened from each first client and each second client, and the updated trusted certificate is sent to the target clients. That is, select some clients to update the trusted certificate, instead of providing the trusted certificate only when the client performs the remote authentication process. In this way, the highly trusted first clients and second clients can continue to execute services with the updated public key. Of course, for data security considerations, the client can also perform credibility verification through the remote authentication process before each interaction with the TEE.

[0107] Among them, the server can determine indicators such as historical behavior and authentication level according to the historical service information to evaluate the trust score of the first client and the second client. The target clients for sending the trusted certificate are selected according to the trust scores of the first client and the second client. In this way, users with high credibility can be preferentially selected, reducing the risks brought by malicious users and improving the overall security of the system.

[0108] Alternatively, the server can also select the target clients for sending the trusted certificate according to the historical service information and the activity of the second client within a certain time window in the past. Preferentially select active clients to ensure the freshness and relevance of data and reduce the resources consumed on inactive second clients.

[0109] Of course, the server can choose various reasonable methods for screening clients, which are not limited in this specification and can be set according to needs.

[0110] Figure 3 It is a schematic flowchart of another method for multi-party private set intersection in a trusted execution environment shown in an exemplary embodiment of this specification. As Figure 3 shown, the method is applied to the first client; the method may include the following steps:

[0111] Step 300, send a virtual report request to the trusted execution environment of the server, and obtain a trusted certificate containing the public key of the trusted execution environment, where a service application and a database that operate independently of each other are deployed in the trusted execution environment.

[0112] Step 302, in response to the successful verification of the credibility of the trusted certificate, generate a calculation request for multi-party private data set intersection based on the private data required for the intersection calculation, and send it to the service application, so that the service application accesses the database to obtain the private data provided by each second client in the calculation request, and completes the intersection calculation in the trusted execution environment.

[0113] Step 304: Receive the calculation result encrypted with the private key of the trusted execution environment returned by the service application, and decrypt the calculation result based on the public key.

[0114] Figure 4 It is a schematic flowchart of another method for multi-party private intersection under a trusted execution environment shown in an exemplary embodiment of this specification. As Figure 4 shown, the method is applied to a second client; the method may include the following steps:

[0115] Step 400: Send a virtual report request to the trusted execution environment of the server, and obtain a trusted certificate containing the public key of the trusted execution environment, where the trusted execution environment deploys an independently running service application and a database;

[0116] Step 402: In response to the successful verification of the trustworthiness of the trusted certificate, send the private data to be stored to the database for storage;

[0117] The private data stored in the database is used to support the intersection calculation based on the private data initiated by the first client, where: the first client sends a calculation request for multi-party private data intersection to the service application, the service application obtains the private data from the database for intersection calculation, and encrypts the calculation result with the private key of the trusted execution environment and returns it to the first client, and the first client decrypts the calculation result with the public key.

[0118] Optionally, sending the private data to be stored to the database for storage includes: determining the private data to be stored, encrypting the private data according to the public key, and sending it to the database so that the database stores the private data. That is, as described in the above embodiment, in order to avoid the problem that the second client can directly send plaintext and cause data leakage, the second client can encrypt the private data with the TEE public key and then transmit it to the database for storage.

[0119] Optionally, determine a database operation request for the database, as well as the private data carried in the database operation request, encrypt the private data according to the public key, and send the database operation request carrying the encrypted private data to the database, so that the database decrypts the private data with the private key of the trusted execution environment and updates the database according to the database operation request.

[0120] Optionally, encrypting the private data according to the public key includes: determining the client key of the second client, encrypting the private data according to the client key, then encrypting it with the public key, and encrypting the client key with the public key;

[0121] Send to the database, including: sending the encrypted privacy data and the client key to the database, so that the database decrypts to obtain the plaintext of the privacy data through the client key and the private key, so as to update the database according to the database operation request.

[0122] As mentioned above, in order to improve data security, the second client can also encrypt the privacy data with its own client key first, and then encrypt it with the TEE public key. When sending a database operation request, it is also necessary to carry the client key encrypted by the TEE public key so that the database can obtain the client key of the second client.

[0123] It should be noted that: Figure 1 The embodiments shown describe the technical solutions of this specification based on the actions performed jointly by the server, the first client, and the second client, while Figure 3 The embodiments shown describe the technical solutions of this specification from the perspective of the first client, Figure 4 The embodiments shown describe the technical solutions of this specification from the perspective of the second client. Therefore, Figure 3 and Figure 4 The embodiments shown and Figure 1 The embodiments shown are closely related in technical solutions. Except for the process of the client encrypting data locally, Figure 3 and Figure 4 For other contents of the embodiments shown, reference can be made to the description of the embodiments shown in the previous text about Figure 1 and will not be elaborated here.

[0124] This specification also provides an interaction schematic diagram for multi-party private set intersection in a trusted execution environment, as shown in Figure 5 shown, Figure 5 The dotted lines in indicate two non-necessarily consecutive stages before and after. The system includes: a first client, a second client, and a server. The server contains an independently running remote authentication module, a business application, and a database;

[0125] The second client sends a virtual report request to the trusted execution environment of the server to obtain a trusted certificate containing the public key of the trusted execution environment; in response to the successful verification of the trustworthiness of the trusted certificate, the privacy data to be stored is sent to the database for storage.

[0126] The remote authentication module, in response to the virtual report request sent by the first client, returns a trusted certificate containing the public key of the trusted execution environment to the first client, enabling the first client to verify the trustworthiness of the trusted execution environment; in response to the virtual report request sent by the second client, returns a trusted certificate containing the public key to the second client, enabling the second client to verify the trustworthiness of the trusted execution environment.

[0127] The first client sends a virtual report request to the trusted execution environment of the server to obtain a trusted certificate containing the public key of the trusted execution environment; in response to the successful verification of the trustworthiness of the trusted certificate, based on the private data required for intersection calculation, generates a calculation request for multi-party private data intersection, and sends it to the business application, enabling the business application to access the database to obtain the private data provided by each second client in the calculation request, and completes the intersection calculation in the trusted execution environment; receives the calculation result encrypted by the private key of the trusted execution environment returned by the business application, and decrypts to obtain the calculation result based on the public key.

[0128] The database receives the database operation request of the second client and updates the database; receives the query request of the business application and returns the private data.

[0129] The business application receives the calculation request for multi-party private data intersection sent by the first client, obtains the private data provided by each second client in the calculation request from the database through the business application; performs intersection calculation based on the obtained private data, and after encrypting the calculation result with the private key of the trusted execution environment, returns it to the first client.

[0130] Figure 6 It is a schematic structural diagram of an electronic device in an exemplary embodiment. Please refer to Figure 6 , at the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory. Of course, other required hardware may also be included. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs, forming a device for multi-party private intersection at the logical level. Of course, in addition to the software implementation, this specification does not exclude other implementation methods, such as logical devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logical unit, and can also be hardware or logical devices.

[0131] Corresponding to the embodiments of the distributed key sharing method in the foregoing blockchain system, this specification also provides embodiments of a multi-party private intersection device in a trusted execution environment.

[0132] Please refer to Figure 7 , the device is applied to the server; in the trusted execution environment of the server, there are a business application and a database running independently of each other, and the device may include:

[0133] The remote authentication module 701, in response to the virtual report request sent by the first client, returns a trusted certificate containing the public key of the trusted execution environment to the first client, enabling the first client to perform trustworthiness verification on the trusted execution environment;

[0134] A data acquisition module 702 receives a calculation request for multi-party private data intersection sent by the first client, and obtains the private data provided by each second client in the calculation request from the database through the business application;

[0135] An intersection calculation module 703 performs intersection calculation based on the obtained private data through the business application, and after encrypting the calculation result with the private key of the trusted execution environment, returns it to the first client, so that the first client decrypts it based on the public key to obtain the calculation result.

[0136] Optionally, the device includes a deployment module 704. In response to building the trusted execution environment in the server, it obtains the database encrypted by the public key from the non-volatile memory of the server, stores it in the trusted execution environment, decrypts the database with the private key corresponding to the public key, and deploys the database in the trusted execution environment. Here, the private key and the public key are an asymmetric key pair of the trusted execution environment.

[0137] Optionally, what is stored in the non-volatile memory are multiple data segments after the database is split, and each data segment is encrypted by the public key. The deployment module 704 decrypts each data segment respectively according to the private key in the asymmetric key pair, reorganizes the database according to the decrypted data segments, and deploys it in the trusted execution environment.

[0138] Optionally, in response to a virtual report request sent by a second client, the data acquisition module 702 returns a trusted certificate containing the public key to the second client, so that the second client verifies the trustworthiness of the trusted execution environment, receives a database operation request sent by the second client, and the private data carried in the database operation request is encrypted by the public key of the trusted execution environment. It decrypts the private data with the private key of the trusted execution environment, and updates the database according to the database operation request.

[0139] Optionally, the data acquisition module 702 decrypts with the private key to obtain the plaintext data required for the database operation request, determines the plaintext result corresponding to the database operation request based on the plaintext data, encrypts the plaintext result with the public key, and updates the database based on the encrypted data.

[0140] Optionally, the data acquisition module 702 updates the database deployed in the trusted execution environment; and encrypts the updated database with the public key, and uses the database encrypted by the public key to replace the database stored in the non-volatile memory of the server.

[0141] Optionally, the database operation request further carries a client key encrypted by the public key. The private data carried in the database operation request is first encrypted by the client key and then encrypted by the public key. The intersection module 703 decrypts it through the private key to obtain the client key, and obtains the plaintext of the private data carried in the database operation request of the second client through the private key and the client key.

[0142] Optionally, the data acquisition module 702. The service application determines the identifiers of the second clients that provide the private data for intersection calculation and the data identifiers for the intersection calculation according to the calculation request. For each determined second client, a query request is determined and sent to the database according to the identifier and data identifier of the second client, and each query result returned by the database is received to obtain the private data required for the intersection calculation.

[0143] Optionally, the intersection module 703 decrypts the private data obtained from the database respectively according to the private key of the feasible execution environment to obtain plaintext data, and performs intersection calculation according to the plaintext data in the trusted execution environment to determine the calculation result.

[0144] Optionally, the device further includes an update module 705. According to a preset key update period, a key pair of the trusted execution environment is regenerated, and the currently used key pair is updated. At least according to the newly generated public key, the trusted certificate of the trusted execution environment is updated.

[0145] Optionally, the update module 705 determines the historical service information of the first client and the second client when performing services in history. According to the historical service information, at least some target clients are screened from the first client and the second client, and the updated trusted certificate is sent to the target clients.

[0146] Corresponding to the embodiment of the multi-party private intersection method under the foregoing trusted execution environment, this specification also provides an embodiment of a multi-party private intersection device under the trusted execution environment.

[0147] Please refer to Figure 8 , this device is applied to the first client and includes:

[0148] The remote authentication module 801 sends a virtual report request to the trusted execution environment of the server, and obtains a trusted certificate containing the public key of the trusted execution environment. The business application and the database that operate independently of each other are deployed in the trusted execution environment;

[0149] A calculation request module 802, in response to the successful verification of the credibility of the trusted certificate, generates a calculation request for multi-party private data intersection based on the private data required for intersection calculation, and sends it to the service application, enabling the service application to access the database to obtain the private data provided by each second client in the calculation request, and complete the intersection calculation in the trusted execution environment;

[0150] A receiving module 803 receives the calculation result encrypted by the private key of the trusted execution environment returned by the service application, and decrypts the calculation result based on the public key.

[0151] Please refer to Figure 9 , this device is applied to the second client and includes:

[0152] A remote authentication module 901 sends a virtual report request to the trusted execution environment of the server to obtain a trusted certificate containing the public key of the trusted execution environment, where a service application and a database that operate independently of each other are deployed in the trusted execution environment;

[0153] A data operation module 902, in response to the successful verification of the credibility of the trusted certificate, sends the private data to be stored to the database for storage;

[0154] The private data stored in the database is used to support the intersection calculation based on the private data initiated by the first client. Among them: the first client sends a calculation request for multi-party private data intersection to the service application, the service application obtains the private data from the database for intersection calculation, and encrypts the calculation result with the private key of the trusted execution environment and returns it to the first client, and the first client decrypts the calculation result through the public key.

[0155] Optionally, the data operation module 902 determines the private data to be stored, encrypts it according to the public key private data, and sends it to the database, enabling the database to store the private data.

[0156] Optionally, the data operation module 902 determines a database operation request for the database and the private data carried in the database operation request, encrypts the private data according to the public key private data, and sends the database operation request carrying the encrypted private data to the database, enabling the database to decrypt the private data with the private key of the trusted execution environment and update the database according to the database operation request.

[0157] Optionally, the data operation module 902 determines the client key of the second client, encrypts the privacy data according to the client key, then encrypts it with the public key, and encrypts the client key with the public key; and sends the encrypted privacy data and the client key to the database, so that the database decrypts to obtain the plaintext of the privacy data through the client key and the private key, so as to update the database according to the database operation request.

[0158] For the specific implementation process of the functions and effects of each unit in the above device, please refer to the implementation process of the corresponding steps in the above method for details, which will not be repeated here.

[0159] Based on the same concept as the above method, this specification also provides an electronic device, including: a processor; a memory for storing executable instructions of the processor; wherein, the processor realizes the steps of the method as described in any one of the above embodiments by running the executable instructions.

[0160] Based on the same concept as the above method, this specification also provides a computer-readable storage medium, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method as described in any one of the above embodiments are realized.

[0161] Based on the same concept as the above method, this specification also provides a computer program product, including computer programs / instructions, and when the computer programs / instructions are executed by a processor, the steps of the method as described in any one of the above embodiments are realized.

Claims

1. A method for multi - party private set intersection in a trusted execution environment, which is applied to a server. In the trusted execution environment of the server, a business application and a database are deployed to run independently of each other, including: Responding to a virtual report request sent by a first client, returning a trusted certificate containing the public key of the trusted execution environment to the first client, so that the first client verifies the trustworthiness of the trusted execution environment; Receiving a calculation request for multi - party private data intersection sent by the first client, and obtaining the private data provided by each second client in the calculation request from the database through the business application; Through the business application, performing intersection calculation based on the obtained private data, and after encrypting the calculation result with the private key of the trusted execution environment, returning it to the first client, so that the first client decrypts it based on the public key to obtain the calculation result.

2. The method according to claim 1, deploying the database in the trusted execution environment by the following method, where: Responding to the construction of the trusted execution environment in the server, obtaining the database encrypted with the public key from the non - volatile memory of the server and storing it in the trusted execution environment; After decrypting the database with the private key corresponding to the public key, deploying the database in the trusted execution environment; Wherein, the private key and the public key are an asymmetric key pair of the trusted execution environment.

3. The method according to claim 2, the non - volatile memory stores multiple data segments after splitting the database, and each data segment is encrypted with the public key; After decrypting the database with the private key corresponding to the public key, deploying the database in the trusted execution environment specifically includes: According to the private key in the asymmetric key pair, decrypting each data segment respectively; According to the decrypted data segments, reorganizing the database and deploying it in the trusted execution environment.

4. The method according to claim 1, further including: Responding to a virtual report request sent by a second client, returning a trusted certificate containing the public key to the second client, so that the second client verifies the trustworthiness of the trusted execution environment; Receiving a database operation request sent by the second client, and the private data carried in the database operation request is encrypted with the public key of the trusted execution environment; Decrypting the private data with the private key of the trusted execution environment, and updating the database according to the database operation request.

5. The method according to claim 4, updating the database according to the database operation request, including: Decrypting with the private key to obtain the plaintext data required for the database operation request; Based on the plaintext data, determining the plaintext result corresponding to the database operation request; Encrypting the plaintext result with the public key and updating the database based on the encrypted data.

6. The method according to claim 4, updating the database, including: Updating the database deployed in the trusted execution environment; Further, encrypt the updated database with the public key, and use the database encrypted with the public key to replace the database stored in the non-volatile memory of the server.

7. The method according to claim 4, wherein the database operation request further carries a client key encrypted with the public key, and the private data carried in the database operation request is first encrypted with the client key and then encrypted with the public key; Decrypting the private data with the private key of the trusted execution environment includes: Decrypting with the private key to obtain the client key; Obtaining the plaintext of the private data carried in the database operation request of the second client through the private key and the client key.

8. The method according to claim 1, wherein obtaining the private data provided by each second client in the calculation request from the database through the service application includes: The service application determines the identities of the second clients that provide the private data for the intersection calculation and the data identifiers for the intersection calculation according to the calculation request; For each determined second client, determine a query request according to the identity and data identifier of the second client and send it to the database; Receive the query results returned by the database to obtain the private data required for the intersection calculation.

9. The method according to claim 1, wherein performing an intersection calculation based on the obtained private data includes: Decrypting the private data obtained from the database respectively with the private key of the trusted execution environment to obtain plaintext data; In the trusted execution environment, perform an intersection calculation according to the plaintext data to determine the calculation result.

10. The method according to claim 1 further includes: Regenerating the key pair of the trusted execution environment according to a preset key update period, and updating the currently used key pair; Update the trusted certificate of the trusted execution environment at least according to the newly generated public key.

11. The method according to claim 10 further includes: Determine the historical service information of the first client and the second client in performing services historically; Screen at least some target clients from the first client and the second client according to the historical service information, and send the updated trusted certificate to the target clients.

12. A method for multi-party private intersection under a trusted execution environment, the method is applied to a first client, and includes: Send a virtual report request to the trusted execution environment of the server to obtain a trusted certificate containing the public key of the trusted execution environment, and a service application and a database that operate independently of each other are deployed in the trusted execution environment; In response to the successful verification of the trustworthiness of the trusted certificate, generate a calculation request for multi-party private data intersection based on the private data required for the intersection calculation, and send it to the service application, so that the service application accesses the database to obtain the private data provided by each second client in the calculation request, and completes the intersection calculation in the trusted execution environment; Receive the calculation result encrypted by the private key of the trusted execution environment returned by the service application, and decrypt the calculation result based on the public key.

13. A multi-party private intersection method under a trusted execution environment, which is applied to a second client and includes: Send a virtual report request to the trusted execution environment of the server, and obtain a trusted certificate containing the public key of the trusted execution environment, where a service application and a database that operate independently of each other are deployed in the trusted execution environment; In response to the successful verification of the trustworthiness of the trusted certificate, send the private data to be stored to the database for storage; The private data stored in the database is used to support the intersection calculation based on the private data initiated by the first client, where: the first client sends a calculation request for multi-party private data intersection to the service application, the service application obtains the private data from the database for intersection calculation, and encrypts the calculation result with the private key of the trusted execution environment and returns it to the first client, and the first client decrypts the calculation result with the public key.

14. The method according to claim 13, sending the private data to be stored to the database for storage includes: Determine the private data to be stored, encrypt the private data according to the public key, and send it to the database so that the database stores the private data.

15. The method according to claim 13 further includes: Determine a database operation request for the database and the private data carried in the database operation request; Encrypt the private data according to the public key, and send the database operation request carrying the encrypted private data to the database, so that the database decrypts the private data with the private key of the trusted execution environment and updates the database according to the database operation request.

16. The method according to claim 15, encrypting the private data according to the public key includes: Determine the client key of the second client; After encrypting the private data with the client key, encrypt it with the public key, and encrypt the client key with the public key; Sending to the database includes: Send the encrypted private data and the client key to the database, so that the database decrypts the private data plaintext with the client key and the private key to update the database according to the database operation request.

17. An electronic device includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, it implements the steps of the method according to any one of claims 1-16.

18. A computer-readable storage medium stores a computer program, and when the program is executed by a processor, it implements the steps of the method according to any one of claims 1-16.

19. A computer program product includes a computer program / instructions, and when the computer program / instructions are executed by a processor, it implements the steps of the method according to any one of claims 1-16.

Images