Privacy data flow transferring method, device, system and trusted execution environment

Abstract

This specification provides embodiments of a method, apparatus, system, and trusted execution environment (TEE) for privacy data transfer. The method involves a terminal device, which includes a first app associated with several first organizations, a second app from a second organization that needs to use user privacy data, and a TEE. The TEE stores the first privacy data of the target user provided by the first app. The second app can send a data usage request for the first privacy data to the TEE. Subsequently, the TEE can request a disclosure verification from the first organization node of the first organization to which the first privacy data belongs. This allows the first organization node to generate a usage authorization statement after identifying no risk of using the first privacy data, to store the usage authorization statement on the blockchain, and to return the usage authorization statement to the TEE. Then, after the usage authorization statement is verified, the TEE can send disclosure information including the first privacy data to the second app.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of computer technology, and in particular relate to methods, apparatus, systems and trusted execution environments for privacy data transfer. Background Technology

[0002] In government data transfer scenarios, the plaintext privacy data of users (referred to as C-type users) is highly sensitive, so it is generally handled cautiously by institutions with strong backing on the server side. However, a large number of mid-to-long-tail institutions (referred to as B-type institutions) have a strong demand for the privacy data of C-type users. For example, in urban services, there is information on people with disabilities. Many scenic spots, theaters, parks, and other B-type institutions provide many benefits to people with disabilities, but they struggle to verify the authenticity of the disability information provided by users online.

[0003] Therefore, a reasonable and reliable solution is needed to achieve the trustworthy transfer of user privacy data. Summary of the Invention

[0004] The purpose of this invention is to provide a privacy data transfer scheme that eliminates the need for Category B organizations to directly connect with the first organization (such as a government agency) and enables the first organization to supervise the transfer of privacy data, thereby achieving trusted transfer of privacy data across apps on terminal devices.

[0005] This specification provides a method for transferring privacy data, relating to a terminal device. The terminal device includes a first app associated with several first organizations, a second app of a second organization requiring the use of user privacy data, and a Trusted Execution Environment (TEE). The method includes: the second app sending a data usage request for first privacy data of a target user to the TEE; wherein the data usage request includes descriptive information of the first privacy data, and the TEE stores the first privacy data provided by the first app; the TEE, via the second app, sending a disclosure request to a server corresponding to the second app, including the descriptive information and the target user's first decentralized identity identifier (DID); the server adding organization-related information, including the second DID of the second organization, to the disclosure request, and sending an updated disclosure request to a first organization node of the first organization to which the first privacy data belongs; the first organization node generating a usage authorization statement after identifying no risk of use of the first privacy data, generating authorization proof information based on the usage authorization statement, storing the authorization proof information in a blockchain system, and sequentially sending the usage authorization statement to the TEE via the server and the second app; and the TEE sending disclosure information including the first privacy data to the second app after verifying the usage authorization statement.

[0006] This specification provides a second aspect of a method for transferring privacy data, relating to a terminal device. The terminal device includes a first app associated with several first organizations, a second app of a second organization requiring the use of user privacy data, and a Trusted Execution Environment (TEE). The method is executed by the TEE and includes: receiving a data usage request from the second app for first privacy data of a target user; wherein the data usage request includes descriptive information of the first privacy data, and the TEE stores the first privacy data provided by the first app; sending a disclosure request, including the descriptive information and the target user's first decentralized identity (DID), to a server corresponding to the second app via the second app; causing the server to add organization-related information, including the second DID of the second organization, to the disclosure request, and then sending an updated disclosure request to a first organization node of the first organization to which the first privacy data belongs; thereby causing the first organization node to generate a usage authorization statement after identifying that the first privacy data has no usage risk, and then sending the usage authorization statement to the TEE sequentially via the server and the second app; and after the usage authorization statement is verified, sending disclosure information including the first privacy data to the second app.

[0007] This specification provides a third aspect of a method for transferring privacy data, relating to a terminal device. The terminal device includes a first APP associated with several first organizations, a second APP of a second organization that needs to use user privacy data, and a Trusted Execution Environment (TEE). The method is executed by a first organization node of any of the several first organizations, including: receiving an updated disclosure and investigation request sent by a server corresponding to the second APP. The updated disclosure and investigation request is obtained by the server adding organization-related information, including the second decentralized identity (DID) of the second organization, to the original disclosure and investigation request. The original disclosure and investigation request is generated by the TEE after receiving a data usage request from the second APP for the first privacy data of the target user belonging to any of the first organizations. The data usage request includes descriptive information of the first privacy data. The original disclosure and investigation request includes the descriptive information and the first DID of the target user. The TEE stores the first privacy data provided by the first APP. After identifying that the first privacy data poses no risk of use, a usage authorization statement is generated; based on the usage authorization statement, authorization proof information is generated and stored in the blockchain system; the usage authorization statement is sent to the TEE via the server and the second APP in sequence, so that after the TEE verifies the usage authorization statement, it sends disclosure information including the first privacy data to the second APP.

[0008] This specification provides a Trusted Execution Environment (TEE) in a terminal device, the terminal device further including a first APP associated with several first organizations, and a second APP of a second organization that needs to use user privacy data. The TEE includes: a receiving unit configured to receive a data usage request from the second APP for the first privacy data of a target user; wherein the data usage request includes descriptive information of the first privacy data, and the TEE stores the first privacy data provided by the first APP; a sending unit configured to send a disclosure and investigation request, including the descriptive information and the first decentralized identity identifier (DID) of the target user, to a server corresponding to the second APP via the second APP, such that the server adds organization-related information including the second DID of the second organization to the disclosure and investigation request, and then sends an updated disclosure and investigation request to a first organization node of the first organization to which the first privacy data belongs, thereby enabling the first organization node to generate a usage authorization statement after identifying that the first privacy data has no usage risk, and then send the usage authorization statement to the TEE via the server and the second APP in sequence; the sending unit is further configured to send disclosure information including the first privacy data to the second APP after the usage authorization statement is verified.

[0009] This specification provides a privacy data transfer device in a fifth aspect, relating to a terminal device. The terminal device includes a first app associated with a plurality of first organizations, a second app of a second organization requiring user privacy data, and a Trusted Execution Environment (TEE). The device is applied to a first organization node of any of the plurality of first organizations and includes: a receiving unit configured to receive an updated disclosure request sent by a server corresponding to the second app. The updated disclosure request is obtained by the server adding organization-related information, including the second decentralized identity (DID) of the second organization, to the original disclosure request. The original disclosure request is generated by the TEE upon receiving data from the second app regarding the target user's first privacy data belonging to any of the first organizations. The data usage request is generated after a usage request is made. The data usage request includes a description of the first privacy data. The original disclosure and investigation request includes the description and the first DID of the target user. The TEE stores the first privacy data provided by the first APP. A generation unit is configured to generate a usage authorization statement after identifying that the first privacy data has no usage risk. A storage unit is configured to generate authorization proof information based on the usage authorization statement and store the authorization proof information in a blockchain system. A sending unit is configured to send the usage authorization statement to the TEE sequentially via the server and the second APP, so that the TEE sends disclosure information including the first privacy data to the second APP after the usage authorization statement is verified.

[0010] This specification provides a privacy data transfer system in a sixth aspect. The system includes a terminal device, a server corresponding to a second APP of a second organization on the terminal device that needs to use user privacy data, a first organization node of any first organization, and a blockchain system. The terminal device further includes a first APP associated with several first organizations and a Trusted Execution Environment (TEE), wherein the "any first organization" is included among the several first organizations. The second APP is configured to send a data usage request to the TEE for first privacy data belonging to the "any first organization" of a target user. The data usage request includes descriptive information of the first privacy data, and the TEE stores the first privacy data provided by the first APP. The TEE is configured to send data to the service via the second APP. The server sends a disclosure request, which includes the description information and the target user's first decentralized identity (DID). The server is configured to add organization-related information, including the second organization's second DID, to the disclosure request and send the updated disclosure request to the first organization node. The first organization node is configured to generate a usage authorization statement after identifying that the first privacy data has no usage risk, generate authorization proof information based on the usage authorization statement, store the authorization proof information in the blockchain system, and send the usage authorization statement to the TEE via the server and the second APP in sequence. The TEE is also configured to send disclosure information including the first privacy data to the second APP after the usage authorization statement is verified.

[0011] The seventh aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in any of the implementations of the second and third aspects.

[0012] An eighth aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method described in any of the implementations of the second and third aspects.

[0013] The ninth aspect of this specification provides a computer program product that, when executed in a computer, causes the computer to perform the method described in any of the implementations of the second and third aspects.

[0014] The solutions provided in the embodiments described above relate to terminal devices, which include a first application associated with several first institutions, a second application of a second institution that needs to use user privacy data, and a Trusted Execution Environment (TEE). In this solution, the TEE stores the first privacy data of the target user provided by the first application. When the second application needs to use the first privacy data, it can send a data usage request to the TEE. Subsequently, the TEE can request a disclosure verification from the first institution node of the first institution to which the first privacy data belongs. This allows the first institution node to generate a usage authorization statement after identifying no risk of using the first privacy data, to store the usage authorization statement on the blockchain, and to return the usage authorization statement to the TEE. Then, after the usage authorization statement is verified, the TEE can send disclosure information including the first privacy data to the second application. This eliminates the need for direct connections between Category B institutions and the first institutions to monitor the flow of privacy data, enabling trusted flow of privacy data across applications within the terminal device. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a diagram of a blockchain system architecture in one embodiment;

[0017] Figure 2 This is an architecture diagram of the privacy data transfer system in the embodiments of this specification;

[0018] Figure 3 This is a schematic diagram illustrating the development and deployment of the DAPP_G1 in the embodiments of this specification;

[0019] Figure 4 This is a schematic diagram of the real-person authentication process in the embodiments of this specification;

[0020] Figure 5 This is a schematic diagram of the privacy data storage process in the embodiments of this specification;

[0021] Figure 6 This is a schematic diagram of the selection process for privacy data to be transferred in the embodiments of this specification;

[0022] Figure 7This is a schematic diagram of the privacy data transfer method in the embodiments of this specification;

[0023] Figure 8 This is a schematic diagram of the privacy data transfer method in the embodiments of this specification;

[0024] Figure 9 This is a schematic diagram of the Trusted Execution Environment (TEE) in the terminal device in the embodiments of this specification;

[0025] Figure 10 This is a schematic diagram of the privacy data transfer device in the embodiments of this specification. Detailed Implementation

[0026] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0027] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain, data blocks are sequentially linked together in a chain-like data structure, and cryptographic methods are used to ensure the immutability and forgery resistance of these data blocks. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application.

[0028] Figure 1 A diagram of a blockchain system architecture in one embodiment is shown. Figure 1 The blockchain system architecture diagram shown indicates that the blockchain system includes N nodes. Figure 1 The diagram illustrates nodes 1 through 8. The lines connecting the nodes schematically represent connections between them, such as TCP connections, used for data transmission. These nodes can store the entire ledger, including the state of all blocks and accounts. Each node in the blockchain system can generate the same state within the system by executing the same transactions, and each node can store the same state database.

[0029] In the blockchain field, a transaction refers to a task unit executed and recorded within the blockchain system. A transaction typically includes a From field, a To field, and a Data field. For example, in the case of a transfer transaction, the From field represents the account address that initiated the transaction (i.e., initiated the transfer task to another account), the To field represents the account address that received the transaction (i.e., received the transfer), and the Data field includes the transfer amount.

[0030] Blockchain systems offer smart contract functionality. A smart contract on a blockchain is a contract that can be triggered and executed by transactions. Smart contracts can be defined in the form of code. Calling a smart contract within a blockchain system involves initiating a transaction pointing to the smart contract's address, causing the smart contract code to run distributedly across each node in the blockchain system.

[0031] As mentioned earlier, in the context of government data flow, the plaintext privacy data of users (who can be referred to as C-type users) is highly sensitive, so it is generally handled cautiously by institutions with strong backing on the server side. However, a large number of mid-to-long-tail institutions (who can be referred to as B-type institutions) have a strong demand for the privacy data of C-type users. For example, in urban services, there is information on people with disabilities. Many scenic spots, theaters, parks, and other B-type institutions provide many benefits to people with disabilities, but they are struggling to verify the authenticity of the disability information provided by users online.

[0032] This specification provides a method for transferring privacy data, involving a terminal device. The terminal device includes a first app associated with several first organizations, a second app of a second organization that needs to use user privacy data, and a TEE (Transaction Entity Execution Environment). In this method, the second app can send a data usage request for the target user's first privacy data to the TEE. This data usage request includes descriptive information about the first privacy data, and the TEE stores the first privacy data provided by the first app. Subsequently, the TEE can send a disclosure request via the second app to the server corresponding to the second app, including the descriptive information and the target user's first DID (Decentralized Identifier). Next, the server can add organization-related information, including the second DID of the second organization, to the disclosure request and send an updated disclosure request to the first organization node of the first organization to which the first privacy data belongs. Then, after identifying that the first privacy data poses no risk of use, the first organization node can generate a usage authorization statement, generate authorization proof information based on the usage authorization statement, store the authorization proof information in a blockchain system, and send the usage authorization statement to the TEE sequentially via the server and the second app. Then, after the TEE verifies the authorization statement, it can send disclosure information, including the first privacy data, to the second app. This eliminates the need for Category B organizations to directly connect with the first organization and allows the first organization to oversee the flow of privacy data, thus enabling trusted cross-app privacy data transfer on terminal devices.

[0033] It should be noted that the first type of institution includes, but is not limited to, government agencies, and the first type of app can be called a government app, which provides government services. A single government agency may include, for example, the Civil Affairs Bureau or the Social Security Bureau, etc., without specific limitations. The second type of institution can belong to category B, and the target users can belong to category C. Here, B is short for Business, which can represent scenic spots, theaters, parks, commercial banks, third-party payment institutions, e-commerce platforms, etc. C is short for Consumer, which can represent individual consumers, etc.

[0034] Below, taking the first organization as a government agency as an example, we will introduce the privacy data transfer scheme provided in the embodiments of this specification.

[0035] See Figure 2 This is an architecture diagram of the privacy data flow system in the embodiments of this specification. Figure 2 As shown, the privacy data transfer system may include a terminal device 201 used by the target user. The terminal device 201 includes government apps associated with several government agencies and providing government services, and apps from second-party agencies (such as...). Figure 2The APP_B and TEE shown in the document. These government agencies include, but are not limited to, those such as... Figure 2 The government agency G1 is shown in the image.

[0036] The government affairs app and app_B reside in the REE (Rich Execution Environment) of terminal device 201. The REE is generally the runtime environment of the mobile terminal's operating system (such as Android or iOS), which is an open environment and vulnerable to malware attacks.

[0037] TEE is an independent execution environment that runs alongside REE. Specifically, it's a secure extension of CPU hardware and a trusted execution environment completely isolated from the outside world. Currently, the industry is paying close attention to TEE solutions, and almost all mainstream chip and software alliances have their own TEE solutions. Examples include software-based TPM (Trusted Platform Module) and hardware-based ARM Trustzone and AMD PSP (Platform Security Processor). TEE acts as a black box; the code and data executed within it cannot be viewed even at the operating system level. Operations can only be performed through predefined interfaces in the code. In terms of efficiency, due to the black-box nature of TEE, the computations performed within it are on plaintext data, rather than the complex cryptographic operations of homomorphic encryption, resulting in almost no loss of efficiency.

[0038] The government affairs app and app_B can communicate with the TEE through any feasible communication method. In one implementation, the terminal device 201 may also include a target SDK (Software Development Kit), through which the government affairs app and app_B can communicate with the TEE respectively. By enabling the terminal device 201 to access the target SDK, a trusted connection to the TEE can be achieved, allowing multiple apps to achieve trusted data flow through the same TEE.

[0039] In addition, such as Figure 2As shown, the privacy data transfer system also includes server 202 corresponding to APP_B, institutional node 204 of government agency G1, and blockchain system 205. Server 202 is specifically the backend server for APP_B. Institutional node 204 can be used to monitor and process the transfer of privacy data of target users on the government agency G1 side, ensuring the trustworthy transfer of privacy data. Blockchain system 205 can be used for data storage and other purposes during the privacy data transfer process. Blockchain system 205 can include N nodes; for an explanation of these N nodes, please refer to the relevant descriptions above, which will not be repeated here.

[0040] Furthermore, such as Figure 2 As shown, the privacy data transfer system may also include an institution node 203 of a second institution and / or an institution node 206 of an identity issuing authority.

[0041] Government agencies G1 can have regulatory DApps (such as those for overseeing the flow of privacy data) for monitoring the transfer of privacy data. Figure 2 The supervisory DAPP_G1 shown can be deployed on institutional nodes 203 and 204, and these nodes can communicate with each other. DAPP stands for Decentralized Application. The supervisory DAPP_G1 can have various supervisory capabilities, such as supervising the storage of user privacy data by the TEE and supervising the flow of privacy data. The supervisory DAPP_G1 deployed on institutional node 203 can enable some supervisory capabilities, such as enabling the supervision of privacy data flow. The supervisory DAPP_G1 deployed on institutional node 204 can enable all supervisory capabilities.

[0042] Identity issuing authorities are typically identity service providers with official or brand endorsements, such as provincial identity authentication centers. The institution node 206 of an identity issuing authority can provide user identification and issue verifiable claims (VCs), and store the issued verifiable claims on the blockchain for verification.

[0043] In practice, if an institution wants to utilize the data storage and other capabilities of the blockchain system 205 during the privacy data transfer process, then, as mentioned earlier, the institutional nodes need to register their node identities in the blockchain system 205. Specifically, in a privacy data transfer system including institutional nodes 203, 204, and 206, any one of these institutional nodes can send a transaction Tx1 to the blockchain system 205 to register its node identity. Transaction Tx1 includes registration information, which may include, but is not limited to, the node name, node type, node service address, node public key, and timestamp. The node type can be referred to as the node identity, and a single node type may include, for example, a civil affairs bureau, a bank, or a third-party CA certification center. The node public key may include the public key of the institution to which the node belongs. Afterwards, the blockchain system 205 can assign a DID to the institutional node by executing transaction Tx1, store the registration information and the corresponding DID in the blockchain system 205, and return the DID to the institutional node. This DID can be generated, for example, based on the public key of any of the institution's nodes. Furthermore, this DID can be obtained by hashing the node's public key.

[0044] As described above, government agency G1 can have a regulatory DAPP_G1, which can be deployed on agency nodes 203 and 204. Specifically, the regulatory DAPP_G1 can be developed on agency node 204.

[0045] Specifically, in one implementation, institutional nodes 203 and 204 may include a digital identity infrastructure component (referred to as a digital identity infrastructure base). The digital identity infrastructure component may have hardware and software resources, and can be a unified component providing DApp development, listing, release, deployment, and interoperability; typically, one component is deployed per institutional node. To quickly develop the regulatory DApp_G1, institutional node 204 can obtain a pre-defined regulatory DApp scaffolding, making the digital identity infrastructure component include this scaffolding. This scaffolding provides a standardized architectural encapsulation of some capabilities within the regulatory DApp, primarily defining data terminal key management, data usage authorization, data usage risk control, on-chain contract calls, and static page resources during management.

[0046] As an example, the download address information for the scaffolding can be stored in blockchain system 205. After completing node identity registration, institutional node 204 can access it as follows: Figure 3As indicated by label S301, the download address information is retrieved from blockchain system 205. Then, as indicated by label S303, the scaffolding is downloaded based on this download address information. Next, as indicated by label S305, the scaffolding is used to develop and deploy the supervisory DAPP_G1. Among these steps... Figure 3 This is a schematic diagram illustrating the development and deployment of the DAPP_G1 in the embodiments of this specification.

[0047] After the development of the regulatory DAPP_G1 is completed, institutional node 204 can, as follows: Figure 3 As shown in label S307, the regulatory DAPP_G1 is published to the blockchain system 205. After that, the institutional node 203 can subscribe to the regulatory DAPP_G1 from the blockchain system 205 as shown in label S309, and after the subscription is successful, it can pull the regulatory DAPP_G1 from the blockchain system 205 as shown in label S311, and then deploy the regulatory DAPP_G1 locally as shown in label S313.

[0048] It should be noted that, to alleviate the storage pressure on blockchain system 205, institutional node 204 can store the installation package of regulatory DAPP_G1 in a target location accessible to institutional node 203, and then publish regulatory DAPP_G1 to blockchain system 205. Specifically, institutional node 204 can send transaction Tx2 to blockchain system 205 for publishing regulatory DAPP_G1. Transaction Tx2 includes the publishing content, which includes the DID (which can be referred to as the third DID) of government agency G1, a description of the regulatory data fields, the download address of the installation package, and the hash value of the installation package. This hash value can be obtained by hashing the installation package using the MD5 (Message-Digest Algorithm 5) algorithm. Furthermore, the publishing content may also include at least one of the following: the institutional name of government agency G1, the version number of regulatory DAPP_G1, and a set of use cases. The use cases in this set of use cases are those that can be used by Class B institutions. Subsequently, blockchain system 205 can assign an identifier to the regulatory DAPP_G1 by executing transaction Tx2, and store the identifier and the published content accordingly. Furthermore, transaction Tx2 can also include a signature based on the private key of the government agency G1 (referred to as the first signature). After verifying the first signature, blockchain system 205 can assign an identifier to the regulatory DAPP_G1, and store the identifier and the published content accordingly.

[0049] When a second institution wants to subscribe to the regulatory DAPP_G1, it can use institution node 203 to send a transaction Tx3 to the blockchain system 205 for subscribing to the regulatory DAPP_G1. Transaction Tx3 can include the identifier of the regulatory DAPP_G1, the second institution's DID (which can be called the second DID), the subscription time, and a signature based on the second institution's private key (which can be called the second signature). Blockchain system 205 can execute transaction Tx3 and, after verifying the second signature, return a subscription execution number to institution node 203. Then, institution node 203 can pull the download address and hash value of the installation package of the regulatory DAPP_G1 from blockchain system 205, download the installation package according to the download address, and after verifying the downloaded installation package based on the hash value, import the subscription execution number and the downloaded installation package into the local digital identity infrastructure component, and deploy the regulatory DAPP_G1 according to the execution order indicated by the subscription execution number.

[0050] After successfully deploying the regulatory DAPP_G1, institutional node 203 can activate the regulatory DAPP_G1 and perform on-chain activation and verification. As an example, the aforementioned publication could also include a strategy for deciding whether to allow Category B institutions to use the regulatory DAPP_G1. When institutional node 203 activates the regulatory DAPP_G1 to the blockchain system 205, the blockchain system 205 can determine, based on this strategy, whether to allow the second institution to use the regulatory DAPP_G1. Further, this strategy could include, for example, an institutional DID blacklist, which could include the DIDs of several Category B institutions that are not allowed to use the regulatory DAPP_G1 by government agency G1. The blockchain system 205 can search for the second institution's second DID in this institutional DID blacklist. If found, it determines that the second institution is not allowed to use the regulatory DAPP_G1. If not found, it determines that the second institution is allowed to use the regulatory DAPP_G1.

[0051] The preceding text described how institutional nodes obtain their DID by registering their node identity with the blockchain system 205. In the scheme provided in the embodiments of this specification, in addition to institutional nodes having DIDs, target users should also have DIDs.

[0052] When the target user does not have a DID associated with terminal device 201, for example when terminal device 201 is a new device, the target user can request the institution node 206 of the identity issuing authority to perform real-person authentication through terminal device 201, thereby generating a DID associated with terminal device 201 for the target user (which can be called the first DID).

[0053] Specifically, see Figure 4 This is a schematic diagram of the real-person authentication process in the embodiments of this specification.

[0054] like Figure 4 As shown, in step S401, the TEE in the terminal device 201 collects identity information from the target user.

[0055] Specifically, a TEE can have a built-in TUI (Trusted User Interface). The TEE can use the built-in TUI to guide the target user to provide identity information. When the target user is an individual, the identity information can include the target user's name and identification code. When the target user is a company, the identity information can include the company's business license name, unified social credit code, legal representative's name, and legal representative's identification code.

[0056] In step S403, the TEE sends a real-person authentication request to the identity issuing authority's institution node 206, which includes the TEE's public key, the target user's public key, identity information, and device identifier.

[0057] The public key of the TEE is included with the terminal device 201 at the factory. Furthermore, the real-person authentication request may specifically include the TEE public key certificate included with the terminal device 201, which includes the TEE's identifier, the TEE's public key, and the brand of the terminal device 201. The device identifier may include, but is not limited to, the TEE's identifier. The target user's public key can be generated by the TEE; for example, the TEE may have a preset key generation algorithm. After collecting the target user's identity information, the TEE can use this key generation algorithm to generate a public-private key pair for the target user, and include the public key in the real-person authentication request.

[0058] In step S405, the organization node 206 verifies the identity of the target user.

[0059] As one implementation, the institution node 206 can verify the identity of the target user by verifying the identity information. As another implementation, when the target user is a natural person, the TEE can collect the target user's biometric information (such as facial features, palm prints, or fingerprints) along with their identity information, and include this biometric information in the real-person authentication request. Based on this, the institution node 206 can verify the target user's identity by verifying both the identity information and the biometric information.

[0060] In step S407, the organization node 206 generates a first DID for the target user in response to the successful verification of the target user's identity.

[0061] Specifically, the institutional node 206 can generate a first DID based on the target user's public key. For example, the target user's public key can be hashed, and the calculated hash value can be used as the first DID. Afterwards, the institutional node 206 can execute steps S409 and S417.

[0062] In step S409, the mechanism node 206 sends the first DID to the TEE.

[0063] After receiving the first DID, the TEE can execute step S411. Furthermore, to enhance the security of user privacy data, the TEE can also execute steps S413 and S415.

[0064] Specifically, in step S411, the TEE uses the identity information as an identity information template and stores the identity information template and the first DID in the local TEE.

[0065] In one implementation, after generating the first DID, the institution node 206 can also issue a verifiable claim containing the first DID to the target user. Further, the verifiable claim may include at least one of the following: the target user's public key, the public key of the TEE in the terminal device 201, the target user's identity information, the third DID of the identity issuing authority, the issuance time, and a signature based on the identity issuing authority's private key (which may be referred to as a third signature), etc. In step S409, the institution node 206 may specifically send the verifiable claim to the TEE in the terminal device 201. In step S411, the TEE may specifically store the identity information template and the verifiable claim locally on the TEE. For example, the TEE may store the identity information template and the verifiable claim locally on the TEE after the third signature verification is successful.

[0066] In step S413, the TEE collects access verification information from the target user.

[0067] Specifically, the TEE can guide the target user to provide access verification information through its built-in TUI. When the target user is an individual, the access verification information can be any of the following: a Personal Identification Number (PIN), a fingerprint image, or a facial image. When the target user is an enterprise, the access verification information can include a PIN.

[0068] In step S415, the TEE stores the collected access verification information as a verification information template, associated with the identity information template, locally on the TEE.

[0069] In step S417, the institution node 206 generates the target user's identity verification information, including the first DID and the public key of the TEE.

[0070] The identity verification information may also include a hash value of the target user's identity information. Furthermore, when issuing a verifiable claim to the target user, the identity verification information may also include the issuance time of the verifiable claim.

[0071] In step S419, the institutional node 206 sends transaction Tx4 to the blockchain system 205, which includes the device identifier of the terminal device 201 and the identity verification information of the target user.

[0072] In step S421, the blockchain system 205 stores the device identifier and identity verification information by executing transaction Tx4.

[0073] The above combination Figure 4 This paper describes the process of performing real-person authentication on terminal device 201. In order to achieve the trusted transfer of private data, after real-person authentication is completed on terminal device 201, the target user can store the private data on the government agency side into the TEE of terminal device 201 through the government affairs APP according to actual needs.

[0074] Below, the privacy data of target users on the G1 side of government agencies will be referred to as second privacy data, combined with Figure 5 This section describes the process of storing private data. Specifically, Figure 5 This is a schematic diagram of the privacy data storage process in the embodiments of this specification.

[0075] like Figure 5 As shown, in step S501, the government affairs APP in the terminal device 201 responds to the target user's request for local storage of the second privacy data and sends an identity verification request to the TEE in the terminal device 201; both the local storage request and the identity verification request include the target user's second identity information.

[0076] The second identity information is the target user's identity information to be verified. This second identity information uses the same fields as the identity information template stored in the TEE.

[0077] In step S503, the TEE verifies the identity of the target user based on the second identity information.

[0078] Specifically, in one implementation, the TEE stores several identity information templates. The TEE can search among these identity information templates for a target identity information template that matches the second identity information. If a target identity information template is found, the target user verification is deemed successful. If no target identity information template is found, the target user verification is deemed unsuccessful.

[0079] In another implementation, the TEE stores several identity information templates and their corresponding verification information templates for access verification. The TEE can search among these identity information templates for a target identity information template that matches the second identity information. If no target identity information template is found, the target user verification is determined to have failed. If a target identity information template is found, the TEE collects access verification information from the target user and then determines whether the collected access verification information matches the verification information template corresponding to the target identity information template. If the result is yes, the target user verification is determined to have passed; otherwise, the target user verification is determined to have failed.

[0080] In step S505, after the TEE verifies the target user, it returns the verification certificate verifyId to the government affairs APP.

[0081] In step S507, the government affairs APP sends a privacy data storage request to the TEE, which includes verifyId and second privacy data.

[0082] The privacy data storage request may also include at least one of the following: the data identifier of the second privacy data on the government agency G1 side, the hash value of the second privacy data (which may be referred to as the first hash value), the expiration date, and the third DID of the government agency G1. It should be noted that this data identifier is only understood by the government agency G1 and will not disclose privacy information.

[0083] After receiving a privacy data storage request, in one implementation, the TEE can directly execute step S517; in another implementation, in order to enable the government agency G1 to supervise the storage of privacy data, the TEE can execute step S509, which causes the agency node 204 of the government agency G1 to execute steps S511-S515 to perform the corresponding supervision processing.

[0084] Specifically, in step S509, the TEE sends a storage verification request to the agency node 204 of the government agency G1, which includes the first DID, the public key of the TEE, and the data identifier of the second privacy data on the side of the government agency G1.

[0085] The TEE may include Trusted Applications (TAs), which can send storage verification requests to the agency node 204 of the government agency G1 via TA programs. Where the privacy data storage request also includes at least one of verifyId, a first hash value, and an expiration date, the storage verification request may also include that at least one. Furthermore, the storage verification request may also include a signature based on the TEE's private key (referred to as a fourth signature), a signature based on the target user's private key (referred to as a fifth signature), and / or a TEE public key certificate.

[0086] It should be noted that when the institutional node 204 includes the supervisory DAPP_G1 as described above, the TEE can specifically send a storage verification request to the supervisory DAPP_G1 in the institutional node 204, so that the supervisory DAPP_G1 processes the storage verification request.

[0087] In step S511, the institutional node 204 verifies the information in the storage verification request.

[0088] Specifically, the institutional node 204 can verify whether the public key of the TEE is associated with the first DID. As an example, the institutional node 204 can send a transaction Tx5 to the blockchain system 205 to verify whether the public key of the TEE is associated with the first DID. Transaction Tx5 includes the public key of the TEE and the first DID. Further, if the storage verification request includes a TEE public key certificate, and the TEE's identifier in the certificate serves as the device identifier for the terminal device 201, transaction Tx5 can also include the device identifier. The blockchain system 205 can execute transaction Tx5 to find identity verification information including the public key of the TEE and the first DID; for example, if transaction Tx5 includes the device identifier, it can first obtain the stored identity verification information corresponding to the device identifier, and then determine whether the obtained identity verification information includes both the public key of the TEE and the first DID. If identity verification information including the public key of the TEE and the first DID is found, the blockchain system 205 can return verification result information to the institutional node 204 indicating that the public key of the TEE is associated with the first DID. If no identity verification information, including the TEE's public key and the first DID, is found, the blockchain system 205 can return a verification result to the institution node 204 indicating that the TEE's public key is not associated with the first DID. The institution node 204 can then determine whether the TEE's public key is associated with the first DID based on the received verification result.

[0089] Additionally, when the storage verification request includes at least one of the first hash value, the fourth signature, and the fifth signature, the institution node 204 can also verify at least one of these. Specifically, when verifying the first hash value, the second privacy data can be obtained based on the data identifier of the second privacy data on the G1 side of the government agency, and a hash value can be calculated from the second privacy data. The first hash value and the calculated hash value are then compared. If the first hash value and the calculated hash value are the same, the first hash value verification is considered successful; otherwise, the first hash value verification is considered unsuccessful. When verifying the fourth signature, the verification can be specifically based on the public key of the TEE. When verifying the fifth signature, the verification can be specifically based on the public key of the target user.

[0090] In step S513, after the information verification is passed, the agency node 204 identifies the storage risks of the second privacy data.

[0091] Specifically, after all the information to be verified in the storage verification request has been verified, the institutional node 204 can identify storage risks of the second privacy data.

[0092] As an example, agency node 204 may have a pre-defined device blacklist, which may include device identifiers of terminal devices that government agency G1 is not allowed to store user privacy data. If the storage verification request includes the device identifier of terminal device 201, agency node 204 can determine whether the device identifier of terminal device 201 is included in the device blacklist. If the determination is yes, then the second privacy data is determined to have a storage risk; otherwise, the second privacy data is determined not to have a storage risk.

[0093] As another example, institution node 204 may have a pre-defined field for storing risk information. This field may include several fields and their corresponding risk values. Institution node 204 can retrieve the risk values ​​corresponding to each field involved in the second privacy data from this field-stored risk information. If none of the retrieved risk values ​​reach the risk threshold, it can be determined that the second privacy data has no storage risk. If at least one of the retrieved risk values ​​reaches the risk threshold, it can be determined that the second privacy data has a storage risk.

[0094] As another example, the organization node 204 may have pre-defined first sensitive field information, which contains fields that are not allowed to be stored by the terminal device. The organization node 204 can determine whether each field involved in the second privacy data is included in the first sensitive field information. If none of the fields are included in the first sensitive field information, it can be determined that the second privacy data has no storage risk. If at least one of the fields is included in the first sensitive field information, it can be determined that the second privacy data has a storage risk.

[0095] It should be noted that the various storage risk identification methods listed above can be used individually or in combination. For example, if the device identifier of terminal device 201 is not included in the device blacklist, the risk values ​​corresponding to each field involved in the second privacy data do not reach the risk threshold, and none of these fields are included in the first sensitive field information, then it is determined that the second privacy data has no storage risk. Furthermore, these storage risk identification methods are merely exemplary; specific identification methods can be set according to actual needs and are not specifically limited here.

[0096] In step S515, in response to identifying that the second privacy data has no storage risk, the agency node 204 returns a storage verification result to the TEE.

[0097] The storage verification result may include at least one of the following: verifyId, category number and field description of the second privacy data, root hash value of the second privacy data after being constructed into the target Merkle tree, field sorting path used when constructing the second privacy data into the target Merkle tree, reporting public key, timestamp, seed value, and signature based on the private key of the government agency G1 (which may be referred to as the sixth signature). The sixth signature may be a signature of the root hash value. It should be noted that the reporting public key may be a temporary public key, which can be used by the TEE for data encryption during subsequent communication with agency node 204. The seed value may specifically be a HOTP (HMAC-based One-Time Password) seed, which is used for authorization verification during the authorization phase of using all or part of the second privacy data.

[0098] In step S517, the TEE associates the second privacy data with the target user and stores it locally on the TEE.

[0099] Specifically, during steps S509-S515, the TEE, in response to receiving a storage verification pass result from the institutional node 204, can associate the second privacy data with the target user and store it locally on the TEE. For example, it can associate the second privacy data with the target user's identity information template or the first DID and store it locally on the TEE. Furthermore, when the storage verification pass result includes a sixth signature, the TEE can associate the second privacy data with the target user and store it locally on the TEE after verifying the sixth signature.

[0100] In one implementation, when the storage verification result includes the root hash value of the second privacy data after it has been constructed into a target Merkle tree, and the field sorting path used when constructing the target Merkle tree, the TEE can construct the target Merkle tree based on the field sorting path and associate the target Merkle tree with the target user and store it locally on the TEE. Furthermore, when the storage verification result also includes the root hash value of the target Merkle tree, after constructing the target Merkle tree from the second privacy data, the TEE can, in response to the root hash value of the constructed target Merkle tree being the same as the root hash value in the storage verification result, associate the constructed target Merkle tree with the target user and store it locally on the TEE.

[0101] In one implementation, when the storage verification result includes the category number and field description of the second privacy data, the TEE can generate target index information including the category number and field description, and associate the target index information and the second privacy data with the target user and store it locally on the TEE. Further, the target index information may also include at least one of the following: expiration date, the third DID of government agency G1, the agency name of government agency G1, etc.

[0102] In one implementation, when the storage verification result includes a seed value, the TEE can associate the seed value and second privacy data with the target user and store them locally on the TEE. Further, when the seed value is ciphertext obtained by encrypting its original text, the TEE can first decrypt the ciphertext. For example, if the seed value is ciphertext obtained by encrypting the original text using the target user's public key, the TEE can use the target user's private key to decrypt the ciphertext, thereby obtaining the original seed value, and then associate the original seed value with the second privacy data and store it locally on the TEE.

[0103] It should be understood that when the storage verification result includes the category number and field description of the second privacy data, as well as the seed value, the TEE can associate the target index information, the second privacy data, and the seed value as described above with the target user and store them locally on the TEE.

[0104] Figure 5 The corresponding embodiment provides a solution that allows target users to store permitted privacy data for disclosure into a TEE (Transmission Equipment) on the same terminal device via a government affairs app, based on their actual disclosure needs. This enables a second agency's app on the same terminal device to retrieve the target user's privacy data from the TEE. This achieves trusted data transfer across apps on the terminal device. Furthermore, by executing steps S509-S515, government agencies can strengthen oversight of the storage of user privacy data by the TEE on the terminal device, ensuring the security of user privacy data.

[0105] After the second privacy data is stored in the TEE in the terminal device 201, if the APP_B of the second organization in the terminal device 201 needs to use all or part of the second privacy data (which can be referred to as the first privacy data), the APP_B can obtain the first privacy data from the TEE. For example, the APP_B can send a data usage request for the first privacy data of the target user to the TEE. In one example, which privacy data the APP_B needs to use can be determined by the APP_B.

[0106] Furthermore, to enable users to initiate on-demand data transfer independently, with selective disclosure of transferred data fields and complete self-control, the solution provided in this specification allows target users to perform a privacy data transfer trigger operation in APP_B, selecting fields to be disclosed, thereby causing APP_B to determine the content of the fields to be disclosed as the first privacy data. Afterwards, APP_B can send a data usage request for the target user's first privacy data to the TEE.

[0107] Specifically, see Figure 6 This is a schematic diagram illustrating the selection process of privacy data to be transferred in the embodiments of this specification. The selection process includes steps S601-S615 as shown below.

[0108] like Figure 6 As shown, in step S601, the target user provides first identity information in APP_B by executing a privacy data flow trigger operation.

[0109] The first identity information is the target user's identity information to be verified. The first identity information involves the same fields as the identity information template stored in the TEE.

[0110] In step S603, APP_B sends a privacy data filtering request to TEE, which includes the first identity information.

[0111] In step S605, the TEE verifies the identity of the target user.

[0112] Specifically, TEE can verify the identity of the target user based on the first identity information. The specific verification process can be referred to the identity verification process based on the second identity information described above, and will not be repeated here.

[0113] In step S607, after the target user passes the verification, the TEE obtains some index information of some privacy data corresponding to the target user from the TEE local machine.

[0114] In step S609, the TEE sends several index information to APP_B.

[0115] In step S611, APP_B displays several index information.

[0116] In step S613, the target user selects the fields to be disclosed based on several index information.

[0117] In step S615, APP_B determines the field content of the field to be disclosed as the first privacy data.

[0118] Below, in conjunction with Figure 7 This section describes the flow of primary privacy data. Figure 7This is a schematic diagram of the privacy data transfer method in the embodiments of this specification. The method includes the following steps S701-S719.

[0119] like Figure 7 As shown, in step S701, APP_B sends a data usage request for the target user's first privacy data to the TEE; wherein, the data usage request includes descriptive information of the first privacy data.

[0120] Among them, this first privacy data can be in Figure 6 In the corresponding embodiment, the content of the field to be disclosed selected by the target user, or the privacy data to be used selected by APP_B, is not specifically limited here. The description information of the first privacy data may include each field involved in the first privacy data (which may be referred to as the field to be disclosed), and the corresponding target category number.

[0121] In step S703, the TEE sends a disclosure request to the server 202 corresponding to APP_B via APP_B, which includes the description information of the first privacy data and the first DID of the target user.

[0122] Specifically, the TEE can generate a disclosure request for the first private data via the TA program and send it to server 202 via APP_B. The disclosure request includes a description of the first private data and the first DID, and may also include at least one of the following: a random number, the hash value of the first private data, the number of bytes of the first private data, a timestamp, and a signature based on the TEE's private key (which can be referred to as the seventh signature). The random number is randomly generated by the TEE. Including a random number in the disclosure request is a security measure to prevent replay attacks.

[0123] In step S705, server 202 adds organization-related information, including the second DID of the second organization, to the disclosure of the investigation request.

[0124] The organization-related information may also include at least one of the following: usage scenario, timestamp, signature based on the private key of the second organization (which may be called the eighth signature).

[0125] In step S707, server 202 sends an updated disclosure request to agency node 204 of government agency G1, to which the first privacy data belongs.

[0126] Specifically, when both institutional nodes 203 and 204 of the second institution have a supervisory DAPP_G1 deployed, server 202 can send an updated disclosure cooperation request to supervisory DAPP_G1 in institutional node 203, so that supervisory DAPP_G1, after determining that the second institution has not obtained authorization to use the first privacy data, will forward the updated disclosure cooperation request to supervisory DAPP_G1 in institutional node 204.

[0127] The content of several target fields in the privacy data usage authorization statement can be determined based on a disclosure verification request for the privacy data, and the hash value of the content of these target fields can be stored as authorization proof information in the blockchain system 205. Based on this, when the supervisory DAPP_G1 in the institutional node 203 determines whether the second institution has obtained authorization to use the first privacy data, it can determine the content of these target fields based on the updated disclosure verification request described above, perform a hash calculation on the field content to obtain a hash value, and send a transaction Tx6 containing the hash value to the blockchain system 205 to verify whether the second institution has obtained authorization to use the first privacy data. The blockchain system 205 can search for authorization proof information including the hash value by executing transaction Tx6, and in response to not finding the authorization proof information, return a verification failure result to the supervisory DAPP_G1 in the institutional node 203. Next, the regulatory DAPP_G1 can determine from the verification failure result that the second agency has not obtained authorization to use the first privacy data, and then send an updated disclosure cooperation request to the regulatory DAPP_G1 in agency node 204.

[0128] Furthermore, the blockchain system 205 may include a target smart contract that indicates the target fields in the authorization statement, and the contract state of the target smart contract is used to store authorization proof information. Based on this, the institutional node 203 can obtain the target fields based on the target smart contract, and then determine the field content of the target fields based on the updated disclosure verification request. In addition, transaction Tx6 can invoke the target smart contract, and the blockchain system 205 can search for authorization proof information including the hash value in the contract state of the target smart contract.

[0129] In step S709, the agency node 204 identifies the risks of using the first privacy data.

[0130] Specifically, when the updated disclosure request includes at least one of the seventh and eighth signatures, the agency node 204 can verify the at least one signature and, after the at least one signature passes verification, identify the risk of use of the first privacy data.

[0131] Institutional node 204 can use any applicable risk identification method to identify the risks of using primary privacy data.

[0132] As an example, institution node 204 may have a pre-defined institution DID blacklist, which may include the DIDs of Category B institutions that are not permitted to use user privacy data by government agency G1. Institution node 204 can determine whether the second DID of the second institution is included in the institution DID blacklist. If the determination result is yes, then the first privacy data is determined to be at risk of use; otherwise, the first privacy data is determined not to be at risk of use.

[0133] As another example, institution node 204 may have pre-set field usage risk information, which may include several fields and their corresponding risk values. Institution node 204 can obtain the risk values ​​corresponding to each field involved in the first privacy data from this field usage risk information. If none of the obtained risk values ​​reach the risk threshold, it can be determined that the first privacy data has no usage risk. If at least one of the obtained risk values ​​reaches the risk threshold, it can be determined that the first privacy data has usage risk.

[0134] As another example, organization node 204 may have pre-defined second sensitive field information, where the fields are those that are not permitted for use by Category B organizations. Organization node 204 can determine whether each field involved in the first privacy data is included in the second sensitive field information. If none of these fields are included in the second sensitive field information, it can be determined that the first privacy data poses no risk of use. If at least one of these fields is included in the second sensitive field information, it can be determined that the first privacy data poses a risk of use.

[0135] As another example, institutional node 204 may have pre-set scenario usage risk information, which may include several usage scenarios and their corresponding risk values. If the updated disclosure and investigation request includes usage scenarios, institutional node 204 can obtain the risk value corresponding to that usage scenario from the scenario usage risk information. If the obtained risk value does not reach the risk threshold, it can be determined that the first privacy data has no usage risk. If the obtained risk value reaches the risk threshold, it can be determined that the first privacy data has usage risk.

[0136] It should be noted that the various risk identification methods listed above can be used individually or in combination. Furthermore, these methods are merely illustrative; specific methods can be tailored to actual needs and are not limited here.

[0137] In step S711, after identifying that the first privacy data has no risk of being used, the agency node 204 generates a usage authorization statement and generates authorization certificate information based on the usage authorization statement.

[0138] When the updated disclosure request includes a random number, the authorization statement also includes that random number. Furthermore, the authorization statement may also include at least one of the following: an authorization code, the hash value of the updated disclosure request, a timestamp, an expiration time, and a signature (ninth signature) based on the private key of the government agency G1. The authorization code can be a 6-digit number and can be generated based on the seed value as described above. Further, the authorization code can be generated based on the seed value, the random number, and the target time. The target time is the time when the authorization code is generated. Taking the authorization code generated based on the seed value, the random number, and the target time as an example, agency node 204 can use the TEE's public key to encrypt the combination of the seed value, the random number, and the target time, and determine the encryption result as the authorization code.

[0139] When generating authorization proof information, for example, the content of several target fields in the authorization statement as described above can be hashed to obtain a second hash value, and authorization proof information including the second hash value can be generated. Further, the institution node 204 can obtain the several target fields based on the target smart contract as described above, and then hash the content of the several target fields in the authorization statement to obtain a second hash value.

[0140] In step S713, the institution node 204 stores the authorization certificate information into the blockchain system 205.

[0141] Specifically, institutional node 204 can send transaction Tx7, which includes the authorization proof information, to blockchain system 205, enabling blockchain system 205 to store the authorization proof information by executing transaction Tx7. Furthermore, transaction Tx7 can invoke the target smart contract, and blockchain system 205 can store the authorization proof information in the contract state of the target smart contract.

[0142] In step S715, the organization node 204 sends a usage authorization statement to the TEE via server 202 and APP_B in sequence.

[0143] In step S717, the TEE verifies the use of the authorization statement.

[0144] Specifically, when the authorization statement includes at least one of the following: a random number generated by the TEE, an authorization code generated by the agency node 204, and a ninth signature, the TEE can verify at least one of these items. For example, the TEE can verify at least one of these items using the TA program. Specifically, the TEE can verify the random number in the authorization statement based on the generated random number, verify the authorization code based on the seed value associated with the second privacy data storage where the target user and the first privacy data are located, and / or verify the ninth signature based on the public key of the government agency G1. Taking the authorization code obtained by the agency node 204 using the TEE's public key to encrypt the combination of the seed value, the random number, and the target time as an example, the TEE can decrypt the authorization code using its own private key and determine whether the decrypted seed value is the same as the stored seed value, whether the decrypted random number is the same as the generated random number, and whether the current time is within a time interval of a preset duration (e.g., 40 seconds, 50 seconds, or 1 minute) before or after the target time. When all the determination results are yes, the authorization code verification is considered successful. When at least one determination result is no, the authorization code verification is considered to have failed.

[0145] If all verified information passes the verification, the TEE can determine that the verification using the authorization statement has succeeded. If at least one of the verified information fails the verification, the TEE can determine that the verification using the authorization statement has failed.

[0146] In step S719, after the TEE verifies the use authorization statement, it sends disclosure information including the first privacy data to APP_B.

[0147] The first private data in the disclosed information can be in encrypted form, for example, it can be obtained by encrypting the original first private data using the public key of the second institution. Additionally, the disclosed information may also include the root hash value and verification path of the second private data containing the first private data after constructing the target Merkle tree, and the sorting path of each field involved in the first private data. Furthermore, the disclosed information may also include at least one of the following: the second institution's second DID, the use case, a signature based on the target user's private key (which may be referred to as the tenth signature), and the sixth signature in the previously mentioned storage verification result, etc.

[0148] Figure 7The corresponding embodiment provides a solution involving a terminal device 201, which includes a government affairs APP associated with several government agencies and providing government services, an APP_B of a second agency that needs to use user privacy data, and a TEE. In this solution, the TEE stores the first privacy data of the target user provided by the government affairs APP. When APP_B needs to use the first privacy data, it can send a data usage request to the TEE. Subsequently, the TEE can request the agency node 204 of the government agency G1 to which the first privacy data belongs to conduct a disclosure verification. This allows agency node 204 to generate a usage authorization statement after identifying that the first privacy data has no usage risk, store the usage authorization statement on the blockchain, and return the usage authorization statement to the TEE. Then, after the usage authorization statement is verified, the TEE can send disclosure information including the first privacy data to APP_B. Thus, the B-type agency no longer needs to directly connect with the government agencies, and the government agencies can supervise the flow of privacy data, realizing the trusted flow of privacy data across APPs in the terminal device.

[0149] After APP_B obtains the disclosure information returned by TEE, APP_B can transfer the disclosure information to its corresponding server 202, so that server 202 can complete its own business based on the first privacy data in the disclosure information.

[0150] It should be noted that, in order to supervise the actual use of user privacy data by Category B institutions, achieve privacy compliance, and prevent Category B institutions from abusing user privacy data, they can request the blockchain system to perform a 205 verification of the authorization statement for the use of the user privacy data when they actually use it, thereby leaving evidence of the Category B institution's use of the user privacy data in the blockchain system.

[0151] Specifically, see Figure 8 This is a schematic diagram of the privacy data transfer method in the embodiments of this specification. The method includes the following steps S801-S811.

[0152] like Figure 8 As shown, in step S801, APP_B sends disclosure information including the first privacy data to its corresponding server 202.

[0153] The disclosure also includes the root hash value and verification path of the second privacy data containing the first privacy data after it has been constructed into a target Merkle tree, as well as the sorting path of each field involved in the first privacy data. Furthermore, the disclosure may also include at least one of the following: the second DID of the second organization, the use case, and the sixth and tenth signatures as previously mentioned.

[0154] In step S803, server 202 performs data verification.

[0155] Specifically, to prevent tampering, server 202 can verify the first privacy data. For example, server 202 can calculate the root hash value of the target Merkle tree based on the verification path of the target Merkle tree, the sorting path of each field involved in the first privacy data, and the first privacy data itself. If the root hash value matches the root hash value of the target Merkle tree in the disclosed information, the server determines that the first privacy data has passed verification. It should be noted that if the first privacy data in the disclosed information is in encrypted form, server 202 can first decrypt the encrypted first privacy data to obtain the original first privacy data, and then verify the original first privacy data.

[0156] Furthermore, when the disclosed information also includes a sixth signature and / or a tenth signature, server 202 can also verify the sixth signature and / or the tenth signature. Specifically, when verifying the sixth signature, it can be verified based on the public key of the government agency G1, thus ensuring that the primary privacy data originates from government agency G1. When verifying the tenth signature, it can be verified based on the public key of the target user, thus ensuring that the primary privacy data originates from the target user's local machine.

[0157] It should be noted that, to improve the reliability of the verification result of the tenth signature and ensure that the primary privacy data definitely originates from the target user's local storage, server 202 can request blockchain system 205 to verify the tenth signature. For example, server 202 can send transaction Tx8 to blockchain system 205 for verifying the tenth signature, and transaction Tx8 includes the disclosure information of the primary privacy data. Subsequently, blockchain system 205 can execute transaction Tx8 to verify the tenth signature based on the target user's public key and return the verification result to server 202. Server 202 can then determine whether the tenth signature verification passed or failed based on this result.

[0158] After all the information that needs to be verified in the disclosed information has been verified, server 202 can determine that the data verification has passed and then proceed to step S805. If at least one of the information fails to be verified, server 202 can determine that the data verification has failed.

[0159] In step S805, after the data verification is passed, the server 202 obtains the field content of several target fields in the first privacy data usage authorization statement, and performs hash calculation on the field content to obtain a third hash value.

[0160] Specifically, server 202 can obtain the target fields based on the target smart contract as described above, and then obtain the field content of the target fields in the authorization statement for the use of the first privacy data, and perform hash calculation on the field content to obtain a third hash value.

[0161] In step S807, server 202 sends transaction Tx9, which includes a third hash value and invokes the target smart contract, to blockchain system 205.

[0162] In step S809, the blockchain system 205 executes transaction Tx9 to search for target authorization proof information, including the third hash value, in the contract state of the target smart contract.

[0163] In step S811, in response to finding the target authorization proof information, the blockchain system 205 returns a verification result to the server 202.

[0164] Subsequently, server 202 can respond to the receipt of the verification result and complete its own business based on the first privacy data.

[0165] As described above, the solution provided in this specification allows Category B institutions to no longer need direct connections with government agencies. Instead, they can achieve unified access and use through a loosely coupled standard of blockchain system + regulatory DApp, thus covering all Category B institutions. Data flow on the user's terminal is triggered based on specific scenarios, enabling users to initiate on-demand data flow autonomously, selectively disclose flowed data, and maintain complete autonomy and control. Furthermore, strong pre-emptive supervision of local data storage on the terminal and strong in-process supervision of data flow are possible. User-disclosed data can be watermarked with authorized business and scenario information, allowing for rapid tracing of the leaking institution in case of secondary misuse. Government agencies can also declare data discontinuation and revoke authorization at any time, ensuring full-process control and auditing of data flow by government agencies.

[0166] Figure 9 This is a schematic diagram of the Trusted Execution Environment (TEE) in a terminal device as described in this specification embodiment. The terminal device also includes a first application associated with several first organizations, and a second application from a second organization that needs to use user privacy data. The TEE can execute, for example... Figures 4 to 7The method is shown below. The TEE includes: a receiving unit 901, configured to receive a data usage request from a second app for a target user's first privacy data; wherein the data usage request includes descriptive information of the first privacy data, and the TEE stores the first privacy data provided by the first app; a sending unit 902, configured to send a disclosure request including the descriptive information and the target user's first DID to a server corresponding to the second app via the second app, such that the server adds organization-related information including the second DID of the second organization to the disclosure request, and then sends an updated disclosure request to the first organization node of the first organization to which the first privacy data belongs, thereby enabling the first organization node to generate a usage authorization statement after identifying that the first privacy data has no usage risk, and then sends the usage authorization statement to the TEE via the server and the second app in sequence; the sending unit 902 is also configured to send disclosure information including the first privacy data to the second app after the usage authorization statement is verified.

[0167] Figure 10 This is a schematic diagram of the privacy data transfer device in the embodiments of this specification. The device relates to a terminal device, which includes a first APP associated with several first organizations, a second APP of a second organization that needs to use user privacy data, and a Trusted Execution Environment (TEE). The device is applied to a first organization node of any of the several first organizations and can execute actions such as... Figure 3 , Figure 5 , Figure 7 The method is shown. The apparatus may include: a receiving unit 1001, configured to receive an updated disclosure cooperation request sent by a server corresponding to the second APP, which is obtained by the server adding organization-related information including the second DID of the second organization to the original disclosure cooperation request. The original disclosure cooperation request is generated by the TEE after receiving a data usage request from the second APP for the first privacy data of the target user belonging to any first organization. The data usage request includes descriptive information of the first privacy data. The original disclosure cooperation request includes the descriptive information and the first DID of the target user. The TEE stores the first privacy data provided by the first APP; a generating unit 1002, configured to generate a usage authorization statement after identifying that there is no risk of using the first privacy data; a storage unit 1003, configured to generate authorization proof information based on the usage authorization statement and store the authorization proof information in the blockchain system; and a sending unit 1004, configured to send the usage authorization statement to the TEE sequentially via the server and the second APP, so that the TEE sends disclosure information including the first privacy data to the second APP after the usage authorization statement is verified.

[0168] This specification also provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed in a computer, it causes the computer to perform actions such as... Figures 3 to 8 The method shown.

[0169] This specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements, as shown in the embodiment. Figures 3 to 8 The method shown.

[0170] This specification also provides a computer program product, wherein when the computer program product is executed in a computer, it causes the computer to perform the following: Figures 3 to 8 The method shown.

[0171] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0172] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0173] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0174] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0175] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0176] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0177] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0178] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0180] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0181] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0182] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0183] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0184] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0185] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for transferring privacy data, relating to a terminal device, the terminal device including a first APP associated with several first organizations, a second APP of a second organization that needs to use user privacy data, and a Trusted Execution Environment (TEE), the method comprising: The second APP sends a data usage request for the target user's first privacy data to the TEE; wherein, the data usage request includes description information of the first privacy data, and the TEE stores the first privacy data provided by the first APP; The TEE sends a disclosure request to the server corresponding to the second APP via the second APP, including the description information and the decentralized identity identifier (DID) of the target user. The server adds organization-related information, including the second DID of the second organization, to the disclosure and investigation request, and sends the updated disclosure and investigation request to the first organization node of the first organization to which the first privacy data belongs. After identifying that the first privacy data has no risk of being used, the first institutional node generates a usage authorization statement, generates authorization proof information based on the usage authorization statement, stores the authorization proof information in the blockchain system, and sends the usage authorization statement to the TEE in sequence via the server and the second APP; After the TEE verifies the usage authorization statement, it sends disclosure information including the first privacy data to the second APP.

2. The method according to claim 1, wherein, The terminal device also includes a target software development kit (SDK), and both the first APP and the second APP communicate with the TEE through the target SDK.

3. The method according to claim 1, wherein, The TEE stores several privacy data of the target user and several index information corresponding to the privacy data. Any of the index information includes a category number and a field description. The privacy data is provided to the TEE by the first APP. Before the second APP sends a data usage request for the target user's first privacy data to the TEE, the following is also included: After obtaining the first identity information provided by the target user through the execution of a privacy data transfer trigger operation, the second APP sends a privacy data filtering request to the TEE, which includes the first identity information; After the TEE verifies the target user based on the first identity information, it obtains the index information locally from the TEE and sends the index information to the second APP. The second APP displays the aforementioned index information, obtains the field to be disclosed selected by the target user based on the aforementioned index information, and determines the field content of the field to be disclosed as the first privacy data; The description information includes the fields to be disclosed and the corresponding target category number.

4. The method according to claim 3, wherein, The TEE stores several identity information templates and their corresponding verification information templates for access verification. The step of verifying the target user based on the first identity information includes: Search among the plurality of identity information templates for a target identity information template that matches the first identity information; In response to finding the target identity information template, access verification information is collected from the target user; Determine whether the collected access verification information matches the verification information template corresponding to the target identity information template; If the result is yes, the target user verification is deemed successful.

5. The method according to claim 4, wherein, The individual verification information template indicates that the user has set one of the following: personal identification code, fingerprint image, or facial image.

6. The method according to claim 1, wherein, The first institution corresponding to the first institution node has a regulatory DAPP for monitoring the flow of privacy data, and the regulatory DAPP is deployed in the second institution node of the first institution node and the second institution node of the second institution.

7. The method according to any one of claims 1-6, wherein, The first privacy data is all or part of the target user's second privacy data; Before the second APP sends a data usage request for the target user's first privacy data to the TEE, the following is also included: In response to the target user's request for local storage of the second privacy data, the first APP sends an identity verification request to the TEE; both the local storage request and the identity verification request include the target user's second identity information. After the TEE verifies the target user based on the second identity information, it returns a verification certificate to the first APP. The first APP sends a privacy data storage request to the TEE, which includes the verification pass certificate and the second privacy data; The TEE associates the second privacy data with the target user and stores it locally on the TEE.

8. The method according to claim 7, wherein, The privacy data storage request also includes the data identifier of the second privacy data on the first institution side corresponding to the first institution node, and the third DID of the first institution; The method further includes: The TEE sends a storage verification request to the first institution node, which includes the first DID, the public key of the TEE, and the data identifier; After determining that the public key is associated with the first DID, the first institutional node identifies the storage risk of the second privacy data, and in response to the identification that the second privacy data has no storage risk, returns a storage verification result to the TEE; The TEE associates the second privacy data with the target user and stores it locally on the TEE, including: In response to receiving the storage verification result, the TEE associates the second privacy data with the target user and stores it locally on the TEE.

9. The method according to claim 8, wherein, The storage verification request also includes the first hash value of the second privacy data; After determining that the public key is associated with the first DID, the step of identifying storage risks for the second privacy data includes: After determining that the public key is associated with the first DID and the first hash value is verified, the storage risk of the second privacy data is identified.

10. The method according to claim 8, wherein, The storage verification result includes the category number and field description of the second privacy data; The method further includes: The TEE generates target index information including the category number and field description of the second privacy data; The step of associating the second privacy data with the target user and storing it locally on the TEE includes: The target index information and the second privacy data are associated with the target user and stored locally in the TEE.

11. The method according to claim 8, wherein, The storage verification result includes the field sorting path; The step of associating the second privacy data with the target user and storing it locally on the TEE includes: The second privacy data is constructed into a target Merkle tree based on the field sorting path; The target Merkle tree is associated with the target user and stored locally in the TEE.

12. The method according to any one of claims 8-11, wherein, The storage verification result includes a seed value, which is used for authorization verification during the authorization phase of all or part of the second privacy data. The step of associating the second privacy data with the target user and storing it locally on the TEE includes: The seed value and the second privacy data are associated with the target user and stored locally in the TEE.

13. The method according to claim 6, wherein, Sending the updated disclosure request to the first agency node of the first agency to which the first privacy data belongs includes: The server sends the updated disclosure and investigation request to the regulatory DAPP in the second agency node, so that the regulatory DAPP in the second agency node forwards the updated disclosure and investigation request to the regulatory DAPP in the first agency node after determining that the second agency has not obtained authorization to use the first privacy data. After identifying that the first privacy data poses no risk of use, the first institutional node generates a usage authorization statement, including: The regulatory DApp in the first institutional node generates a usage authorization statement after identifying that the first privacy data poses no risk of use. The process of sending the usage authorization statement to the TEE sequentially via the server and the second APP includes: The usage authorization statement is sent to the TEE sequentially via the regulatory DAPP in the second agency node, the server, and the second APP.

14. The method according to claim 1 or 6, wherein, The first privacy data is all or part of the target user's second privacy data. The TEE stores a seed value corresponding to the second privacy data. The seed value is provided to the TEE by the first agency node when it allows the TEE to store the second privacy data. The disclosure request also includes a random number generated by the TEE. The use authorization statement includes the random number and an authorization code. The authorization code is generated based on the seed value. The verification of the usage authorization statement passed, including: The TEE verifies the random number in the usage authorization statement based on the generated random number, verifies the authorization code based on the stored seed value, and determines that the usage authorization statement has passed verification in response to both the random number and the authorization code in the usage authorization statement passing verification.

15. The method according to claim 1 or 6, wherein, The blockchain system is deployed with a target smart contract that displays several target fields in the authorization statement. The generation and use of the authorization statement includes: The content of several target fields in the authorization statement is hashed to obtain a second hash value, and authorization proof information including the second hash value is generated. The step of storing the authorization certificate information in the blockchain system includes: The first institutional node sends a first transaction to the blockchain system, which invokes the target smart contract and includes the authorization proof information; The blockchain system stores the authorization proof information into the contract state of the target smart contract by executing the first transaction; The method further includes: The second APP sends the disclosure information to the server; After the server verifies the first privacy data, it obtains the field content of the several target fields in the use authorization statement, performs a hash calculation on the field content to obtain a third hash value, and sends a second transaction to the blockchain system that calls the target smart contract and includes the third hash value. The blockchain system executes the second transaction, searches for target authorization proof information including the third hash value in the contract state, and returns a verification result to the server in response to finding the target authorization proof information.

16. The method according to claim 15, wherein, The first privacy data is all or part of the second privacy data of the target user. The second privacy data is constructed into a target Merkle tree and stored in the TEE. The disclosure information also includes the root hash value and verification path of the target Merkle tree, and the sorting path of each field involved in the first privacy data. The verification of the first privacy data is successful, including: The server calculates the root hash value of the target Merkle tree based on the verification path, the sorting path of each field, and the first privacy data, and determines that the first privacy data verification is successful if the root hash value is the same as the root hash value of the target Merkle tree in the disclosure information.

17. A method for transferring privacy data, relating to a terminal device, the terminal device including a first APP associated with several first organizations, a second APP of a second organization that needs to use user privacy data, and a Trusted Execution Environment (TEE), the method comprising: The method described in claim 1 is performed by the TEE.

18. A method for transferring privacy data, relating to a terminal device, the terminal device including a first APP associated with several first organizations, a second APP of a second organization that needs to use user privacy data, and a Trusted Execution Environment (TEE), the method comprising: The method described in claim 1 is performed by any first agency node of any of the plurality of first agencies.

19. A Trusted Execution Environment (TEE) system in a terminal device, the terminal device further comprising a first application associated with a plurality of first organizations, and a second application of a second organization that needs to use user privacy data, the TEE system comprising: The receiving unit is configured to receive a data usage request from the second APP for the first privacy data of the target user; wherein the data usage request includes description information of the first privacy data, and the TEE stores the first privacy data provided by the first APP; The sending unit is configured to send a disclosure and investigation request, including the description information and the first decentralized identity identifier (DID) of the target user, to the server corresponding to the second APP via the second APP. This causes the server to add organization-related information, including the second DID of the second organization, to the disclosure and investigation request, and then send the updated disclosure and investigation request to the first organization node of the first organization to which the first privacy data belongs. This causes the first organization node to generate a usage authorization statement after identifying that the first privacy data has no usage risk, and then send the usage authorization statement to the TEE system via the server and the second APP in sequence. The sending unit is further configured to send disclosure information, including the first privacy data, to the second APP after the use authorization statement has been verified.

20. A privacy data transfer device, relating to a terminal device, the terminal device including a first APP associated with a plurality of first institutions, a second APP of a second institution that needs to use user privacy data, and a Trusted Execution Environment (TEE), the device being applied to a first institution node of any of the plurality of first institutions, comprising: The receiving unit is configured to receive an updated disclosure assistance request sent by the server corresponding to the second APP. The updated disclosure assistance request is obtained by the server adding organization-related information, including the second decentralized identity identifier (DID) of the second organization, to the original disclosure assistance request. The original disclosure assistance request is generated by the TEE after receiving a data usage request from the second APP for the first privacy data of the target user belonging to any of the first organizations. The data usage request includes a description of the first privacy data. The original disclosure assistance request includes the description and the first DID of the target user. The TEE stores the first privacy data provided by the first APP. The generation unit is configured to generate a usage authorization statement after identifying that the first privacy data poses no risk of use. The storage unit is configured to generate authorization proof information based on the authorization statement and store the authorization proof information in the blockchain system; The sending unit is configured to send the usage authorization statement to the TEE sequentially via the server and the second APP, so that after the TEE verifies the usage authorization statement, it sends disclosure information including the first privacy data to the second APP.

21. A privacy data transfer system, the system comprising a terminal device, a server corresponding to a second APP of a second institution in the terminal device that needs to use user privacy data, a first institution node of any first institution, and a blockchain system, wherein the terminal device further comprises a first APP associated with a plurality of first institutions and a Trusted Execution Environment (TEE), wherein the arbitrary first institution is included in the plurality of first institutions; The second APP is configured to send a data usage request to the TEE for first privacy data of the target user belonging to any of the first organizations; wherein, The data usage request includes description information of the first privacy data, and the TEE stores the first privacy data provided by the first APP. The TEE is configured to send a disclosure request to the server via the second APP, including the description information and the target user's first decentralized identity identifier (DID). The server is configured to add organization-related information, including the second DID of the second organization, to the disclosure and investigation request, and to send the updated disclosure and investigation request to the first organization node. The first institutional node is configured to generate a usage authorization statement after identifying that the first privacy data has no risk of use, generate authorization proof information based on the usage authorization statement, store the authorization proof information in the blockchain system, and send the usage authorization statement to the TEE in sequence via the server and the second APP; The TEE is also configured to send disclosure information, including the first privacy data, to the second APP after the use authorization statement has been verified.

22. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of claim 17 or 18.

23. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of claim 17 or 18.

Images