A risk data query method, system, trusted unit and server

Abstract

A risk data query method, system, trusted unit and server, the method comprises: a first institution device sends ciphertext query data to a server; the server provides the ciphertext query data to the trusted unit; the trusted unit decrypts the ciphertext query data, obtains a first user identifier of a first user, processes the first user identifier of the first user through a preset algorithm to obtain a second user identifier of the first user; sends the second user identifier of the first user to the server; the server sends a query request to a block chain to query whether the second user identifier of the first user is included in a risk user list stored in the block chain; the block chain queries according to the query request and returns a query result to the server; when it is determined according to the query result that the risk user list does not include the second user identifier of the first user, the server returns first information to the first institution device, and the first information is used to indicate that the first user is not a risk user.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of computer technology, and in particular relate to a risk data query method, system, trusted unit, and server. Background Technology

[0002] Currently, regulatory authorities typically require institutions involved in significant transactions to fulfill their obligations to prevent illicit fund transfers. This involves analyzing and reporting transaction data for large and suspicious transactions. However, information silos exist between institutions, making it difficult for them to identify suspicious users when information is insufficient. How multiple institutions can share risk information while protecting user privacy is a problem that current anti-illicit fund transfer solutions need to address. Summary of the Invention

[0003] The purpose of this invention is to provide a risk data query scheme that combines a server, a trusted unit, and a blockchain to perform risk data queries, thereby improving the efficiency of risk data query.

[0004] The first aspect of this specification provides a method for querying risk data, including:

[0005] The first institution sends encrypted query data to the server. The encrypted query data is obtained by encrypting the query data. The query data includes the first user identifier of the first user to be queried. The first institution belongs to the first institution.

[0006] The server provides the encrypted query data to the trusted unit;

[0007] The trusted unit decrypts the encrypted query data to obtain the first user's first user identifier, processes the first user's first user identifier using a preset algorithm to obtain the first user's second user identifier, and sends the first user's second user identifier to the server.

[0008] The server sends a query request to the blockchain to query whether the risk user list stored in the blockchain includes the second user identifier of the first user. The risk user list is generated based on multiple risk data from multiple institutions and includes the second user identifiers of multiple risk users.

[0009] The blockchain queries whether the risk user list includes the second user identifier of the first user according to the query request, and returns the query result to the server;

[0010] When the server determines, based on the query results, that the second user identifier of the first user is not included in the list of risky users, it returns first information to the first institution device. The first information is used to indicate that the first user is not a risky user.

[0011] The second aspect of this specification provides a method for querying risk data, including:

[0012] The first mechanism device sends encrypted query data to the trusted unit. The encrypted query data is obtained by encrypting the query data. The query data includes the first user identifier of the first user to be queried. The first mechanism device belongs to the first mechanism.

[0013] The trusted unit decrypts the encrypted query data to obtain the first user's first user identifier, processes the first user's first user identifier using a preset algorithm to obtain the first user's second user identifier, and sends a query request to the blockchain to query whether the risk user list stored in the blockchain includes the first user's second user identifier. The risk user list is generated based on multiple risk data from multiple institutions and includes the second user identifiers of multiple risk users.

[0014] The blockchain queries whether the risk user list includes the second user identifier of the first user according to the query request, and returns the query result to the trusted unit;

[0015] When the trusted unit determines, based on the query result, that the second user identifier of the first user is not included in the list of risky users, it returns first information to the first institution device. The first information is used to indicate that the first user is not a risky user.

[0016] A third aspect of this specification provides a risk data query method, executed by a server, the method comprising:

[0017] The device receives encrypted query data from a first institution, the encrypted query data being obtained by encrypting query data, the query data including the first user identifier of the first user to be queried, and the first institution belonging to the first institution;

[0018] The encrypted query data is provided to the trusted unit;

[0019] The second user identifier of the first user is received from the trusted unit, and the second user identifier of the first user is obtained by processing the first user identifier of the first user through a preset algorithm;

[0020] A query request is sent to the blockchain to query whether the risk user list stored in the blockchain includes the second user identifier of the first user. The risk user list is generated based on multiple risk data from multiple institutions and includes the second user identifiers of multiple risk users.

[0021] Receive query results from the blockchain;

[0022] When the query results determine that the second user identifier of the first user is not included in the list of risky users, the first information is returned to the first institution device, and the first information is used to indicate that the first user is not a risky user.

[0023] The fourth aspect of this specification provides a risk data query method, executed by a trusted unit, including:

[0024] The device receives encrypted query data from a first institution, the encrypted query data being obtained by encrypting query data, the query data including the first user identifier of the first user to be queried, and the first institution belonging to the first institution;

[0025] The encrypted query data is decrypted to obtain the first user identifier of the first user. The first user identifier of the first user is then processed by a preset algorithm to obtain the second user identifier of the first user.

[0026] A query request is sent to the blockchain to query whether the risk user list stored in the blockchain includes the second user identifier of the first user. The risk user list is generated based on multiple risk data from multiple institutions and includes the second user identifiers of multiple risk users.

[0027] Receive query results from the blockchain;

[0028] When the query results determine that the second user identifier of the first user is not included in the list of risky users, the first information is returned to the first institution device, and the first information is used to indicate that the first user is not a risky user.

[0029] This specification provides a risk data query system in its fifth aspect, comprising a first-institutional device, a server, a blockchain system, and a trusted unit for performing privacy data processing.

[0030] The first mechanism device is used to send encrypted query data to the server. The encrypted query data is obtained by encrypting query data. The query data includes the first user identifier of the first user to be queried. The first mechanism device belongs to the first mechanism.

[0031] The server is used to provide the encrypted query data to the trusted unit;

[0032] The trusted unit is used to decrypt the encrypted query data, obtain the first user identifier of the first user, process the first user identifier of the first user using a preset algorithm to obtain the second user identifier of the first user, and send the second user identifier of the first user to the server.

[0033] The server is also used to send a query request to the blockchain to query whether the risk user list stored in the blockchain includes the second user identifier of the first user. The risk user list is generated based on multiple risk data from multiple institutions and includes the second user identifiers of multiple risk users.

[0034] The blockchain system is used to query whether the risk user list includes the second user identifier of the first user according to the query request, and return the query result to the server;

[0035] The server is also configured to return first information to the first institution device when it is determined from the query results that the second user identifier of the first user is not included in the list of risky users, the first information being used to indicate that the first user is not a risky user.

[0036] A sixth aspect of this specification provides a server, the server comprising:

[0037] A receiving unit is configured to receive encrypted query data from a first institutional device. The encrypted query data is obtained by encrypting query data. The query data includes a first user identifier of the first user to be queried. The first institutional device belongs to a first institution.

[0038] A providing unit is configured to provide the encrypted query data to a trusted unit;

[0039] The receiving unit is further configured to: receive the second user identifier of the first user from the trusted unit, wherein the second user identifier of the first user is obtained by processing the first user identifier of the first user through a preset algorithm;

[0040] The sending unit is used to send a query request to the blockchain to query whether the risk user list stored in the blockchain includes the second user identifier of the first user. The risk user list is generated based on multiple risk data from multiple institutions and includes the second user identifiers of multiple risk users.

[0041] The receiving unit is also configured to receive query results from the blockchain;

[0042] The return unit is used to return first information to the first institution device when it is determined from the query result that the second user identifier of the first user is not included in the list of risky users. The first information is used to indicate that the first user is not a risky user.

[0043] The seventh aspect of this specification provides a reliable element, including:

[0044] A receiving unit is configured to receive encrypted query data from a first institutional device. The encrypted query data is obtained by encrypting query data. The query data includes a first user identifier of the first user to be queried. The first institutional device belongs to a first institution.

[0045] The decryption unit is used to decrypt the encrypted query data, obtain the first user identifier of the first user, and process the first user identifier of the first user through a preset algorithm to obtain the second user identifier of the first user.

[0046] The sending unit is used to send a query request to the blockchain to query whether the risk user list stored in the blockchain includes the second user identifier of the first user. The risk user list is generated based on multiple risk data from multiple institutions and includes the second user identifiers of multiple risk users.

[0047] The receiving unit is also configured to receive query results from the blockchain;

[0048] The return unit is used to return first information to the first institution device when it is determined from the query result that the second user identifier of the first user is not included in the list of risky users. The first information is used to indicate that the first user is not a risky user.

[0049] The eighth 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 methods described in the second or third aspect.

[0050] A ninth 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 the second or third aspect.

[0051] In the embodiments of this specification, by combining a trusted unit and blockchain to execute a risk data query method, the institutional equipment performs desensitization, encryption and other processing on the information of the user to be queried to obtain a user identifier and sends it to the trusted unit. The trusted unit then processes the user identifier using a preset algorithm to obtain a desensitized user identifier, which is used to query whether the desensitized user identifier is included in the risk user list stored in the blockchain. This improves the query speed in real-time query scenarios while protecting user privacy. Attached Figure Description

[0052] 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.

[0053] Figure 1 This is a schematic diagram of the system in the embodiments of this specification;

[0054] Figure 2 This is a flowchart illustrating the method for generating encrypted risk data files on the device side in the embodiments of this specification.

[0055] Figure 3 This is a flowchart illustrating the server verification mechanism's identity method in the embodiments of this specification.

[0056] Figure 4 This is a flowchart of a risk data sharing method in one embodiment of this specification;

[0057] Figure 5 This is a schematic diagram illustrating the process of generating a risk union file in the embodiments of this specification;

[0058] Figure 6 This is a flowchart illustrating the method for generating encrypted risk query files on the equipment side in the embodiments of this specification.

[0059] Figure 7 This is a flowchart of the risk data query method in the embodiments of this specification;

[0060] Figure 8 This is a flowchart of the risk data query method in the embodiments of this specification;

[0061] Figure 9 This is a flowchart of the risk data query method in the embodiments of this specification;

[0062] Figure 10 This is a flowchart of the risk data query method in the embodiments of this specification;

[0063] Figure 11This is an architecture diagram of a server as described in one of the embodiments of this specification;

[0064] Figure 12 This is an architectural diagram of a trusted unit in an embodiment of this specification. Detailed Implementation

[0065] 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.

[0066] Data sharing is frequently a necessity for organizations handling their operations. A single organization often cannot obtain sufficient information to process its business, thus creating a need to acquire information from other organizations. For example, many countries require financial institutions to provide audit results regarding illicit fund transfers as part of their compliance requirements for combating such transfers. Currently, many central banks and large financial institutions are experimenting with using blockchain technology to improve efficiency and accuracy in the field of illicit fund transfers and to meet regulatory requirements. Meanwhile, data, as a resource, has liquidity and accessibility that form the basis for many data applications and industrial development; however, privacy protection during data exchange and sharing remains a significant challenge for industry development. The following section will continue to illustrate this using the aforementioned example of combating illicit fund transfers.

[0067] Common illicit fund transfer methods involve a wide range of sectors, including banking, insurance, securities, and real estate. Most efforts to combat illicit fund transfers include three core aspects:

[0068] 1. Customer due diligence system. Entities obligated to combat illicit fund transfers must verify and record the identity of their customers based on valid identification documents when establishing a business relationship or conducting transactions with them, and must update customer identity information promptly throughout the business relationship.

[0069] 2. Suspicious Transaction Report (STR) System. Illegal fund flows are generally characterized by large sums of money and unusual transactions. Therefore, the law stipulates a STR system, requiring financial institutions to promptly report transactions that reach a certain threshold and abnormal transactions lacking legitimate purpose to the administrative authorities in charge of combating illegal fund transfers, as clues for investigating illegal and criminal activities.

[0070] 3. Customer Identity Information and Transaction Record Preservation System: Customer identity information and transaction record preservation refers to the legally mandated measures taken by financial institutions to retain customer identity information and transaction details for a certain period, which can provide evidence to support the investigation of illegal and criminal activities.

[0071] Customer identification systems, also known as "Know Your Customer" (KYC), refer to obtaining relevant customer identification information, including understanding the customer's identity when establishing business with the customer, understanding the purpose of the transaction, understanding the source and destination of funds, and understanding the customer's long-term business activities and financial transactions. It is the foundation for preventing illegal fund transfers.

[0072] Different financial institutions have an obligation to review suspicious transactions. However, the transaction information related to the same user and the user's information often differ between different financial institutions. Therefore, the risk labels assigned to the same user after suspicious transaction analysis by different financial institutions may also differ. These risk labels may include multiple pre-set labels, each indicating the user's level of illicit fund transfer risk, the type of illegal activity, or other information related to illicit fund transfer risks. For a financial institution to more accurately assign risk labels to a user, a better approach is to obtain the risk labels assigned to the same user by another (or more) financial institutions. This creates a need to share the same user's risk labels among different financial institutions.

[0073] Taking the risk level of illicit fund transfers for a customer as an example, different financial institutions may assign different risk levels for illicit fund transfers to the same user after conducting suspicious transaction analysis. For instance, Institution A might assign a high risk level to user U1, while Institution B might assign a medium risk level. A better approach for a financial institution to more accurately assign illicit fund transfer risk levels to a user is to obtain the risk level labels from another (or more) financial institutions for the same user. Therefore, there is a need to share the illicit fund transfer risk level labels for the same user across different financial institutions.

[0074] Figure 1 This is a schematic diagram of the system in the embodiments of this specification. Figure 1As shown, institutional devices 100, 200, and 300 can be computing devices for example, institutions A, B, and C, respectively. Institutions A, B, and C can be any of the following: financial institutions, insurance institutions, trading institutions, etc. It is understood that the three institutional devices shown in the figure are examples, and in practice, there may be multiple other institutional devices. Each institutional device is equipped with a client for an anti-illegal fund transfer platform. Each institutional device can directly receive user information, and the client performs certain processing tasks based on this user information, such as reviewing suspicious transactions as described above, thereby obtaining risk labels for each user.

[0075] Taking the risk label specifically as the risk level of illegal fund transfer as an example, Institution A and Institution B can each label a user's illegal fund transfer risk level based on their own anti-illegal fund transfer auditing capabilities. Therefore, the illegal fund transfer risk levels labeled by Institution A and Institution B for User U1 may be different. For example, Institution A might label User U1 as "[High Risk Level]," while Institution B might label it as "[Medium Risk Level]." To obtain a more accurate illegal fund transfer risk level, multiple institutions can share the same user's illegal fund transfer risk level label through an anti-illegal fund transfer server (hereinafter referred to as the server). However, this risk data sharing process needs to meet several compliance requirements. For example, the institution providing the risk data cannot know the institution querying its data, the institution querying the risk data cannot know which institution provided the risk data, and the server cannot know which institution's data an institution is querying, nor the plaintext data retrieved. These compliance requirements increase the difficulty of sharing and querying risk data.

[0076] The server 400 includes a trusted unit, which can be any computing unit capable of processing private or confidential data and protecting data from leakage. The trusted unit may include, for example, a Trusted Execution Environment (TEE) or a computing device in a trusted organization. Figure 1 The image shows an example of TEE40 as a trusted unit, and the following description uses TEE40 as an example of a trusted unit. Each organization's equipment can send de-identified and encrypted ciphertext risk data to server 400, which then stores the ciphertext risk data of each organization locally or on a file storage server. Figure 1(Not shown in the image). TEE40 can receive the address where risk data is stored from server 400, retrieve encrypted risk data from that address, and fuse risk data from multiple institutions to obtain a risk user list. The user identifiers in this risk user list are anonymized identifiers. In this embodiment, user risk data can be queried based on this risk user list. Server 400 and TEE40 can be connected to blockchain 500, and the risk data query scheme in this embodiment can be implemented in conjunction with blockchain 500. It is understood that... Figure 1 Although the trusted element is shown to be located inside server 400, the embodiments in this specification are not limited to this. The TEE may also be located in another computing device, and server 400 may connect to the TEE by connecting to the computing device.

[0077] Figure 2 This is a flowchart illustrating the method for generating encrypted risk data files on the device side in the embodiments of this specification. Figure 2 The mechanisms and equipment in the middle can be Figure 1 Any one of the multiple mechanisms in the system. The following description uses mechanism 100 as an example.

[0078] like Figure 2 As shown, firstly, in step S201, the institutional device 100 reads the initial risk data file F1 to obtain user identity information and risk labels.

[0079] In institution A corresponding to institution equipment 100, the institution administrator can periodically generate an initial risk data file F1 in institution equipment 100 based on the data analysis results within institution A, for sharing risk data with other institutions. It is understood that although risk data and other risk information described below are carried in file form, this embodiment is not limited to this; for example, risk data or risk information can also be carried in the form of data or tables, and this is not limited. The file F1 includes the identity information and risk tags of the risk users in institution A. The identity information includes, for example, name, identification number, etc. The risk tags are labels agreed upon by multiple institutions to indicate the degree of risk. For example, risk tags may include riskH, riskM, riskL, etc., where riskH indicates high risk, riskM indicates medium risk, and riskL indicates low risk. A single user's risk tag may also include multiple risk tags, such as risk1 and riskH, where risk1 indicates a specific type of risk, etc. Specifically, file F1 may include multiple lines, each line of which can be in the following form:

[0080] The string “name / certType / certNum / risk1,riskH” contains the user's name, certificate type, and certificate number. These three elements constitute the three essential components of a user's identity information.

[0081] After the administrator generates file F1 in the institution's device 100, they upload file F1 to the client's storage. Upon detecting an update to file F1, the client can read the file line by line to obtain the identity information and risk tags of each risky user.

[0082] In step S203, the mechanism device 100 determines whether the user ID corresponding to the identity information is stored locally.

[0083] To protect user privacy, the user identity information in file F1 needs to be anonymized; that is, user identity information cannot be directly included in shared files sent from institutional device 100. Therefore, each institution only needs to use the same user ID to replace the user's identity information for the same user. Specifically, for a line of user identity information in file F1, the client in institutional device 100 first determines whether the corresponding user ID is stored locally. For example, the client can determine whether the mapping table at a preset address on the hard drive includes the identity information and the corresponding user ID. If not, the client can execute step S205 to request the user's user ID from server 400.

[0084] In step S205, the device 100 requests the user's user ID from the server 400.

[0085] Specifically, since server 400 is not entirely trustworthy, institutional device 100 also needs to anonymize the user's three-factor information when requesting a user ID from server 400. Specifically, institutional device 100 can calculate the hash value of the three-factor information: hash1 = hash(name + certType + certNum), where "+" indicates sequential concatenation of the two data items. Then, institutional device 100 can send this hash value hash1 to server 400 to request the user ID corresponding to that hash value.

[0086] In step S207, server 400 returns the user's user ID to mechanism device 100.

[0087] After receiving hash1, server 400 can use preset rules to calculate the ID corresponding to hash1.

[0088] In one implementation, to further enhance data security, server 400 can salt hash1, for example, by calculating hash(hash1+salt) and using the resulting hash value as the user ID, where salt is a pre-generated value by the server. Obtaining the user ID by salting hash1 prevents malicious parties from speculating on the three key information corresponding to hash1.

[0089] After determining the user ID, the server returns the user ID to the agency device 100. When other agencies request the user ID from the server 400, the server can calculate the user ID based on the same rules and parameters, thus obtaining the same user ID, and return the same user ID to the agency device. In this way, different agencies use the same user ID for the same user in the risk data files they send to the server.

[0090] In step S209, the mechanism device 100 associates and stores user identity information and user ID.

[0091] After receiving the user ID from the server 400, the agency device 100 may, for example, store the user identity information and the user ID in a persistent medium for subsequent processing of updated risk documents. Specifically, the agency device may store the user identity information and the user ID in a mapping table.

[0092] In step S211, the mechanism device 100 writes the user ID and risk label into the risk data file F2.

[0093] If the mechanism device 100 determines in step S203 that a user ID corresponding to the identity information is stored locally (e.g., in the mapping table mentioned above), it can directly execute step S211. Alternatively, the mechanism device 100 can execute step S211 after executing step S209.

[0094] While the client in the institutional device 100 begins reading file F1, it can initialize file F2. After obtaining the user ID corresponding to each line in file F1, the client records the user ID and the user's risk label in the corresponding line in file F2. After performing the above processing on each line in file F1, the client can generate a risk data file F2 corresponding to file F1.

[0095] In one implementation, after generating file F2 as described above, the client can sort the lines in file F2 in ascending order according to each user ID to facilitate subsequent fusion processing of risk data files from multiple institutions.

[0096] In step S213, the client can also use the TEE's public key to encrypt file F2, thereby generating a ciphertext risk data file F3. This prevents external access to the TEE of server 400 from obtaining the risk values ​​corresponding to each user ID, further protecting user privacy. It is understood that this is not limited to using the TEE's public key to encrypt file F2; for example, the TEE and the institution's equipment can negotiate other asymmetric or symmetric keys for encrypting file F2.

[0097] TEE (Trusted Execution Environment) is a secure extension of CPU hardware, 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 Intel SGX (Software Guard Extensions), ARM Trustzone, and AMD PSP (Platform Security Processor). TEE acts as a hardware 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.

[0098] Taking Intel SGX (hereinafter referred to as SGX) technology as an example, blockchain nodes can create enclaves (enclaves or enclaves) as TEEs based on SGX technology. The server can utilize the newly added processor instructions in the CPU to allocate a portion of memory as an EPC (Enclave Page Cache) to house the aforementioned enclaves. The memory area corresponding to the EPC is encrypted by the CPU's internal Memory Encryption Engine (MEE). The content in this memory area (code and data within the enclave) can only be decrypted within the CPU core, and the encryption and decryption keys are only generated and stored in the CPU when the EPC is started. As can be seen, the security boundary of an enclave only includes itself and the CPU. Neither privileged nor non-privileged software can access the enclave. Even operating system administrators and VMMs (Virtual Machine Monitors, or Hypervisors) cannot affect the code and data within the enclave, thus providing extremely high security. Furthermore, given this security guarantee, the CPU can process plaintext data within the enclave with extremely high computational efficiency, thereby balancing data security and computational efficiency. Data entering and leaving the TEE can be encrypted, thus ensuring data privacy.

[0099] Before being used, the TEE can prove its trustworthiness to the user. This process of proving trustworthiness may involve a remote verification report. The remote verification report is generated during the remote verification process of the TEE. It can be generated by an authoritative authentication server after verifying the self-recommendation information generated by the TEE. This remote verification report can be used to demonstrate that the TEE is trustworthy.

[0100] For example, before encrypting file F2 using the TEE's public key, the institution device 100 can first verify the trustworthiness of the TEE. Specifically, the institution device 100 can challenge the TEE and receive a remote verification report returned by the TEE. After obtaining the remote verification report, the institution device 100 can verify the signature of the remote verification report using the public key of the authoritative authentication server. If the verification passes, the trustworthiness of the TEE can be confirmed. Specifically, after receiving the verification request, the TEE generates authentication information based on its internal mechanism and sends the authentication information and the TEE's hardware public key to the institution device 100. The authentication information includes, for example, the TEE's signature information, hardware information, and software information. The signature information is generated, for example, using the TEE's hardware key; the hardware information includes, for example, various hardware specifications, such as CPU clock speed, memory capacity, etc.; the software information includes the code hash value, code name, version, and runtime logs of each program. As those skilled in the art know, a TEE can perform "measurements" on the programs running within it via memory hardware, such as obtaining the program's code hash value, the hash value of the program's memory usage at a specific execution point, etc., and include this "measurement" information in the authentication information. Since this "measurement" information is executed by the TEE itself (memory hardware) without involving any software or operating system, it is authentic and reliable. After receiving the authentication information, the organization device 100 can send the authentication information to the TEE's remote authentication server, thereby receiving a remote verification report for the TEE from the server. The remote verification report includes the TEE's authentication and verification of the programs executed within the TEE, etc. Therefore, based on this remote verification report, the organization device 100 can determine that the TEE is trustworthy, and the query results through the TEE are trustworthy. Simultaneously, the organization device 100 can locally store the TEE's hardware public key for subsequent verification of the TEE's signature. The TEE stores a public-private key pair, with the private key securely stored within the TEE. The content transmitted by the TEE can be signed using the private key stored within the TEE, thereby proving that it was the result executed by the TEE.

[0101] In the embodiments described in this specification, a digital identity can be created for various institutions by combining DIS with blockchain. Blockchain can provide a decentralized (or weakly centralized), immutable (or difficult to tamper with), and trustworthy distributed ledger, and can provide a secure, stable, transparent, auditable, and efficient way to record transactions and exchange data. A blockchain network can include multiple nodes. Generally, one or more nodes in a blockchain belong to a single participant. Broadly speaking, the more participants in a blockchain network, and the more authoritative the participants, the higher the trustworthiness of the blockchain network. Here, a blockchain network composed of multiple participants is referred to as a blockchain platform. With the help of a blockchain platform, institutions can verify their identities.

[0102] To utilize the distributed digital identity services provided by a blockchain platform, organizations can register their identities on the platform. For example, organization A can create a public-private key pair, storing the private key securely, and create a distributed digital identity (also known as a decentralized identifier, DID). Organization A can create its own DID or request it from a Decentralized Identity Service (DIS) system. DIS is a blockchain-based identity management solution that provides functions such as digital identity creation, verification, and management, thereby achieving standardized management and protection of entity data, ensuring the authenticity and efficiency of information flow, and solving challenges such as cross-organizational identity authentication and data collaboration. The DIS system can connect to a blockchain platform. The DIS system can create a DID for organization A, send the DID and its public key to the blockchain platform for storage, and return the created DID to organization A. The public key can be included in a DIDdoc, which can be stored on the blockchain platform. DIS creates a DID for organization A. This can be based on the public key provided by organization A, for example, by calculating the public key using a hash function. Alternatively, it can be based on other information about organization A (which may or may not include the public key). The latter may require organization A to provide information beyond the public key. Afterward, organization A can provide verification functionality to prove its identity to other parties. Figure 3 This is a flowchart of a server-based method for verifying the identity of an organization, as described in an embodiment of this specification, including:

[0103] S301: Institutional device 100 of institution A initiates a DID creation request to DIS, the request including the public key of institution A.

[0104] S303: In response to the creation request, after verifying the organizational information (e.g., qualifications, certificates, etc.) of organization A, the DIS creates a DID and a corresponding DIDdoc for organization A, and sends the DID and corresponding DIDdoc to the blockchain platform for storage. The DIDdoc includes the public key of organization A. The DIDdoc also includes information such as the download address of a verifiable proof of organization A's identity.

[0105] S305: The blockchain platform receives a verification request from the server, the verification request including the DID of the institution A.

[0106] S307: The blockchain platform retrieves the DIDdoc corresponding to the DID from its own storage and returns it to the server.

[0107] S309: The server generates a string and sends the string to the mechanism device 100 of the mechanism A.

[0108] S311: The mechanism device 100 signs the string using the private key of mechanism A and returns it to the server.

[0109] S313: The server uses the public key in the previously received DIDdoc to verify whether the returned signature is correct. If correct, the identity of the organization A is confirmed.

[0110] After the organization's authentication is successful, the server can execute 400. Figure 4 The risk data sharing method shown.

[0111] like Figure 4 As shown, firstly, in step S401, the mechanism device 100 sends the encrypted risk data file F3 to the server 400.

[0112] Server 400 can periodically request encrypted risk data files from various institutional devices, and institutional device 100 can respond to this request by... Figure 2 The process shown generates a file F3, which is then sent to server 400. Specifically, organization device 100 can sign file F3 using the private key of organization A's DID, and send organization A's DID (e.g., DIDa), file F3, and the signature of file F3 using the private key of DIDa to server 400.

[0113] In step S403, server 400 provides TEE with encrypted risk data files (including file F3) corresponding to the DIDs of each organization.

[0114] After receiving the encrypted risk data file from various institutions and devices, server 400 can store the encrypted risk data file in a storage server inside or outside the server, and obtain the storage address of the encrypted risk data file.

[0115] Subsequently, server 400 can send the list of DIDs of various organizations, along with the file address and public key of the encrypted risk data file corresponding to each DID, to the TEE. The TEE can then read the encrypted risk data file corresponding to each DID from the file address. The public key of each organization is subsequently used to encrypt files sent to that organization. It can be understood that the TEE is not limited to using the organization's public key to encrypt files sent to that organization; it can use any key negotiated between the TEE and the organization's equipment, or between the server and the organization's equipment, including symmetric and asymmetric keys.

[0116] In one implementation, after the server 400 verifies the signatures of each organization on its encrypted risk data files, it can send the list of DIDs of each organization, as well as the file address and public key of the encrypted risk data file corresponding to each DID, to the TEE.

[0117] In one implementation, the server can provide multiple signatures from the multiple institutions and devices to the trusted unit. Thus, before decrypting the multiple encrypted risk data files, the trusted unit first verifies the multiple signatures using the public keys of the multiple institutions. If the verification is successful, the multiple encrypted risk data files are decrypted.

[0118] In step S405, the TEE generates a risk union file F4.

[0119] Specifically, after obtaining the encrypted risk data files of each institution, the TEE uses its own private key to decrypt each encrypted risk data file, thereby obtaining the risk data files of each institution (including the aforementioned risk data file F2). Then, the TEE generates a risk union file F4 based on the risk data files of each institution. This risk union file F4 includes multiple lines, each corresponding to all risk users included in the multiple institutions. Each line includes a user ID, a set of risk tags, and a set of institutions. The risk tag set is obtained from multiple risk data files, and the institution set includes the institution identifiers of the institutions that provided the risk tags.

[0120] Figure 5 This is a schematic diagram illustrating the process of generating the risk union file F4 in the embodiments of this specification. Figure 5The upper middle section illustrates the risk data files of each institution. Institution A's risk data file corresponds to its institution identifier DIDa, Institution B's risk data file corresponds to its institution identifier DIDb, and Institution C's risk data file corresponds to its institution identifier DIDc. Each risk data file displays the user IDs and corresponding risk tags of the risk users within that institution, and the multiple rows in the risk data file are arranged in ascending order of user IDs.

[0121] When merging multiple risk data files in TEE, such as Figure 5 As shown, the smallest user ID is first indicated by a pointer to each risk data file. Figure 5 Among the user IDs indicated by pointers in the three risk data files, the user ID of organization A is the smallest. Therefore, in Figure 5 The first line of the risk union file shown below contains ID1{risk1}{DIDa}, which means that {risk1} is a set of risk labels for ID1 in multiple risk data files, and {DIDa} is a set of institutional identifiers that provide the labels in the risk label set.

[0122] After recording the information corresponding to ID1 in the risk union file, the pointer is moved to the next line in Institution A's risk data file, i.e., the line corresponding to ID3, and the above process is repeated. Specifically, after determining that the smallest ID pointed to by the three pointers is ID2 in the TEE, the information corresponding to ID2, "ID2{risk2,riskL}{DIDb,DIDc}", is recorded in the second line of the risk union file. Through the same process described above, after traversing all lines in each risk data file using pointers, the following can be obtained: Figure 5 The risk union file F4 is shown below.

[0123] In step S407, the TEE performs desensitization processing on the user identifiers in the risk union file F4 and writes the desensitized user identifiers into the risk user file F5.

[0124] TEE can create a risk user file F5 to record a list of risk users before anonymizing the user identifiers in the risk union file F4.

[0125] In one implementation, the TEE can obtain a salt value to salt the user identifier; for example, the TEE can calculate the hash value of file F4 as the salt value. Then, the TEE can encrypt the concatenated value of the user identifier (i.e., ID) and the salt value to obtain a de-identified user identifier. The TEE can use a symmetric key or its public key to encrypt the concatenated value.

[0126] In another implementation, the TEE can use its private key to sign the concatenated value and use the resulting signature as a de-identified user identifier.

[0127] In another implementation, the TEE can use its private key to sign the concatenated value and calculate a hash value from the obtained signature, using the hash value as the de-identified user identifier.

[0128] After obtaining the anonymized user identifier, TEE records the anonymized user identifier in the risk user list in file F5. After processing the user identifiers in each line of file F4 as described above, TEE completes the generation of file F5. The completed file F5 includes multiple anonymized user identifiers.

[0129] In addition, after determining the salt value used to generate file F5, TEE can encrypt the salt value using its public key to obtain the salt ciphertext, and then send the salt ciphertext to server 400. After receiving the salt ciphertext, server 400 can store it in the blockchain.

[0130] In step S409, the TEE sends file F5 to server 400.

[0131] Specifically, the TEE stores file F5 outside the TEE (i.e., the aforementioned EPC) (e.g., on a storage medium in server 400 or on a storage server outside of server 400), and sends the storage address of file F5 to server 400, so that server 400 can read file F5.

[0132] In step S411, server 400 stores file F5 in the blockchain.

[0133] Specifically, server 400 can store file F5 in the blockchain by sending a transaction that includes file F5. That is, each node in the blockchain, after executing the transaction, stores it in the block database, thus storing file F5 in the blockchain. By storing file F5 in the blockchain, file F5 is immutably preserved. Furthermore, because file F5 includes an anonymized user identifier, user privacy is not compromised.

[0134] Figure 6 This is a flowchart illustrating the method for generating encrypted risk query files on the equipment side in the embodiments of this specification. Figure 6 The mechanisms and equipment in the middle can be Figure 1 Any one of the multiple mechanisms in the system. The following description uses mechanism 100 as an example.

[0135] like Figure 6As shown, firstly, in step S601, the mechanism device 100 obtains initial query data, which includes the identity information of the user to be queried.

[0136] In institution A corresponding to institution device 100, the institution administrator may need to perform real-time risk data queries on users in the current business to mitigate business risks when processing business operations. To this end, the institution administrator can input the identity information of the users to be queried into institution device 100 to generate initial query data. In this scenario, high query speed is required. The user's identity information includes, for example, name and ID number. Specifically, the user's identity information can be in the following format: "name / certType / certNum", where name is the user's name, certType is the ID type, and certNum is the ID number; these three constitute the three essential elements of the user's identity information.

[0137] In step S603, the mechanism device 100 determines whether the user ID corresponding to the identity information is stored locally.

[0138] After receiving the initial query data, the institutional device 100 needs to anonymize the user's identity information to protect user privacy; that is, the user's identity information cannot be directly included in the query request sent from the institutional device 100. To this end, each institution only needs to use the same user ID to replace the user's identity information for the same user. Specifically, for the identity information of the user to be queried, the client in the institutional device 100 first determines whether the user ID corresponding to that identity information is stored locally. For example, the client can determine whether the mapping table at a preset address on the hard drive includes the identity information and the corresponding user ID. If not, the client can execute step S605 to request the user's user ID from the server 400.

[0139] In step S605, the mechanism device 100 requests the user's user ID from the server 400.

[0140] Specifically, since server 400 is not entirely trustworthy, institutional device 100 also needs to anonymize the user's three-factor information when requesting a user ID from server 400. Specifically, institutional device 100 can calculate the hash value of the three-factor information: hash1 = hash(name + certType + certNum), where "+" indicates sequential concatenation of the two data items. Then, institutional device 100 can send this hash value hash1 to server 400 to request the user ID corresponding to that hash value.

[0141] In step S607, server 400 returns the user's user ID to mechanism device 100.

[0142] After receiving hash1, server 400 can use preset rules to calculate the ID corresponding to hash1.

[0143] In one implementation, to further enhance data security, server 400 can salt hash1, for example, by calculating hash(hash1+salt) and using the resulting hash value as the user ID, where salt is a pre-generated value by the server. Obtaining the user ID by salting hash1 prevents malicious parties from speculating on the three key information corresponding to hash1.

[0144] After determining the user ID, the server returns the user ID to the agency device 100. In this way, the agency device 100 uses the same user ID for a user in the query file it sends to the server as the user ID for that user in the previous risk union file, thus allowing it to query the user's risk information in the risk union file based on that user ID.

[0145] In step S609, the mechanism device 100 associates and stores user identity information and user ID.

[0146] This step can be referred to in the description of step S209 above, and will not be repeated here.

[0147] In step S611, the mechanism device 100 generates query data, which includes the obtained user ID. The query data is then encrypted to obtain encrypted query data.

[0148] If the mechanism device 100 determines in step S603 that a user ID corresponding to the identity information is stored locally (e.g., in the mapping table mentioned above), it can directly execute step S611. Alternatively, the mechanism device 100 can execute step S611 after executing step S609.

[0149] Specifically, the institutional device 100 can generate a random string as a salt value, and use the TEE public key to encrypt the concatenated data containing the user ID and the salt value, thereby generating ciphertext including the user ID information. It can be understood that the institutional device is not limited to using the TEE public key to encrypt the concatenated data; it can use other symmetric and asymmetric keys negotiated with the TEE to encrypt the concatenated data.

[0150] Figure 7 This is a flowchart of the risk data query method in the embodiments of this specification.

[0151] like Figure 7 As shown, in step S701, the mechanism device 100 sends the generated encrypted query data to the server 400.

[0152] Specifically, institution device 100 can use its own private key to sign the encrypted query data and send the institution device 100's DID (e.g., DIDa), the encrypted query data, and the signature of the encrypted data using the private key with the DIDa to server 400. Server 400 can then verify the signature to verify the institution identity corresponding to institution device 100.

[0153] In step S703, server 400 provides the aforementioned encrypted query data to TEE.

[0154] After receiving encrypted query data including user ID information from the institutional device 100, server 400 can store the encrypted query data in a storage server (either internally or externally) and obtain the storage address of the encrypted query data. Then, server 400 can send the storage address of the encrypted query data to TEE. The TEE can then read the encrypted query data from that storage address. Alternatively, server 400 can directly send the encrypted query data to the TEE.

[0155] In step S705, the TEE generates a de-identified user identifier based on the encrypted query data.

[0156] Specifically, after obtaining the encrypted query data including the user ID information, the TEE uses its own private key to decrypt the encrypted query data and retrieves the user ID from the decrypted data. Then, the TEE can use the same method as the de-identified user identifier in the generated file F5 to generate a de-identified user identifier corresponding to that user ID.

[0157] Specifically, server 400 can query the salt ciphertext used to generate the anonymized user identifier in file F5 from the blockchain and provide the salt ciphertext to TEE. After obtaining the salt ciphertext, TEE uses its private key to decrypt the salt ciphertext to obtain the salt value used when generating file F5, and generates the anonymized user identifier corresponding to the user ID based on the salt value.

[0158] In step S707, the TEE sends the generated de-identified user identifier to the server 400.

[0159] In step S709, server 400 requests the blockchain to query whether the de-identified user identifier is in the risk user file F5.

[0160] Specifically, server 400 can send a transaction to any node or a specific node in the blockchain to invoke the query contract in order to query whether the de-identified user identifier is in the risk user file F5.

[0161] In step S711, the blockchain returns the query results to server 400.

[0162] Upon receiving the aforementioned transaction, the aforementioned nodes in the blockchain execute the transaction, thereby reading file F5 stored in the blockchain to determine whether file F5 contains the anonymized user identifier of the user to be queried. After obtaining the query result, the query result is returned to server 400.

[0163] In step S713, server 400 determines whether the de-identified user identifier is in file F5 based on the query results.

[0164] If the query result indicates that the anonymized user identifier is not in file F5, server 400 executes step S715, returning a query result indicating that the user is risk-free to the institutional device 100. By combining the risk user file stored in the TEE and the blockchain, it is possible to quickly determine whether the queried user is risk-free, improving feedback speed and user experience.

[0165] When the query result indicates that the de-identified user identifier is in file F5, the server issues a 400 error. Figure 8 The process shown in flowchart 800.

[0166] Figure 8 This is a flowchart of the risk data query method in the embodiments of this specification.

[0167] like Figure 8 As shown, in step S801, server 400 instructs TEE to perform a query on the user.

[0168] Specifically, server 400 can provide the TEE with the public key of other organizations and the ciphertext including the user ID, instructing the TEE to perform user queries.

[0169] The other institutions refer to institutions and devices in the system other than the institution / device 100 that initiated the query. Specifically, the server 400 can, for example, send the storage address of a file containing the public keys of each institution to the TEE, thereby enabling the TEE to obtain the public keys of each other institution. The public keys of each other institution are used to encrypt query requests sent to that institution. It can be understood that the TEE is not limited to using the institution's public key to encrypt query requests sent to that institution, but can use any key negotiated between the TEE and the institution / device, or between the server and the institution / device, including symmetric and asymmetric keys.

[0170] In step S803, the TEE generates encrypted query requests corresponding to each of the other agencies.

[0171] For other organizations, the TEE can use the organization's public key to encrypt the user ID corresponding to the encrypted query data to obtain the encrypted query request.

[0172] Specifically, the TEE can use the organization's public key to encrypt the user ID and obtain a ciphertext query request.

[0173] In step S805, the TEE sends the encrypted query requests corresponding to each other agency to the server 400.

[0174] In step S807, server 400 sends the encrypted query request to each other agency device.

[0175] In step S809, other equipment and devices return encrypted query results to server 400.

[0176] Upon receiving a encrypted query request, other institutions' equipment decrypts the request using their private key to obtain the user ID and then queries the risk tag corresponding to that user ID locally. If no risk tag is found, the TEE's public key can be used to encrypt preset data (such as the string VALID) to obtain the encrypted query result. If a risk tag is found, a random string can be generated, and the concatenation of the risk tag and the random string can be encrypted using the TEE's public key to obtain the encrypted query result.

[0177] In step S811, the server 400 provides the TEE with the encrypted query results received from various other organizations.

[0178] In step S813, the TEE aggregates the risk labels of various institutions and generates a set of encrypted risk labels.

[0179] Specifically, after receiving encrypted query results from other institutions, the TEE uses its own private key to decrypt each encrypted query result and summarizes the results to generate a risk label set. This risk label set includes one or more risk labels corresponding to the user ID. Then, the TEE uses institution A's public key to encrypt the risk label set, obtaining a encrypted risk label set.

[0180] In step S815, the TEE provides the set of encrypted risk tags to the server 400.

[0181] In step S817, server 400 provides the encrypted risk label set to agency device 100.

[0182] In step S819, after receiving the encrypted risk label set, the institutional device 100 uses its own private key to decrypt the encrypted risk label set to obtain the risk label set corresponding to the user ID, and can then perform business processing based on the risk label set.

[0183] In the embodiments of this specification, a risk data query method is implemented by combining a server, a TEE, and a blockchain. The institutional device performs desensitization and encryption on the information of the user to be queried to obtain a user identifier, which is then sent to the server. The server provides the user identifier to the TEE, which then processes the user identifier using a preset algorithm to obtain a desensitized user identifier. This desensitized user identifier is used to query whether the list of risk users stored in the blockchain includes the desensitized user identifier. This improves the query speed in real-time query scenarios while protecting user privacy and meeting compliance requirements in business scenarios.

[0184] While the foregoing describes a risk data query scheme implemented by combining a server and a TEE, the embodiments in this specification are not limited to this. The following will illustrate... Figure 9 and Figure 10 This specification describes a risk data query scheme implemented via TEE in another embodiment.

[0185] Figure 9 This is a flowchart of the risk data query method in the embodiments of this specification.

[0186] like Figure 9 As shown, in step S901, the mechanism device 100 sends the above-mentioned encrypted query data to the TEE.

[0187] Specifically, Institutional Device 100 can use its own private key to sign the encrypted query data, and send the Institutional Device 100's DID (e.g., DIDa), the encrypted query data, and the signature of the encrypted query data using the DIDa's private key to the TEE. The TEE can pre-store the public keys of each institution, or can obtain the public keys of each institution from outside the TEE, such as querying the DIDa's public key from the blockchain. Thus, the TEE can verify the signature to verify the institution identity corresponding to Institutional Device 100.

[0188] In step S903, the TEE generates a de-identified user identifier based on the encrypted query data.

[0189] Specifically, after obtaining the encrypted query data, the TEE uses its own private key to decrypt the encrypted query data and obtains the user ID from the decrypted data. Then, the TEE can use the same method as the de-identified user identifier in the generated file F5 to generate a de-identified user identifier corresponding to that user ID.

[0190] Specifically, the TEE can query the salt ciphertext used to generate the anonymized user identifier in file F5 from the blockchain. This salt ciphertext can be uploaded to the blockchain by the TEE when generating file F5. Afterwards, the TEE uses its private key to decrypt the salt ciphertext to obtain the salt value used when generating file F5, and generates the anonymized user identifier corresponding to the user ID based on this salt value.

[0191] In step S905, the TEE requests the blockchain to query whether the de-identified user identifier is in the risk user file F5.

[0192] Specifically, the TEE can send a transaction to any node or a specific node in the blockchain to invoke the query contract in order to query whether the de-identified user identifier is in the risk user file F5.

[0193] In step S907, the blockchain returns the query results to the TEE.

[0194] Upon receiving the aforementioned transaction, the aforementioned nodes in the blockchain execute the transaction, thereby reading file F5 stored in the blockchain to determine whether file F5 contains the anonymized user identifier of the user to be queried. After obtaining the query result, the query result is returned to the TEE.

[0195] In step S909, the TEE determines whether the de-identified user identifier is in file F5 based on the query results.

[0196] When the query result indicates that the anonymized user identifier is not in file F5, the TEE executes step S911, returning a risk-free query result to the agency device 100. By combining the risk union file stored in the TEE and the blockchain in this way, it is possible to quickly determine whether the user being queried is risk-free, improving feedback speed and user experience.

[0197] When the query results indicate that the de-identified user identifier is in file F5, TEE executes. Figure 10 The process shown in process 1000.

[0198] Figure 10 This is a flowchart of the risk data query method in the embodiments of this specification.

[0199] like Figure 10 As shown, in step S1001, the TEE generates encrypted query requests corresponding to each of the other agencies.

[0200] For other organizations, the TEE can use the organization's public key to encrypt the aforementioned user ID and obtain a ciphertext query request.

[0201] In step S1003, the TEE sends the encrypted query requests corresponding to each of the other agencies to each of the other agencies.

[0202] In step S1005, each of the other mechanisms and devices returns the encrypted query result to the TEE.

[0203] Upon receiving a encrypted query request, other institutions' equipment decrypts the request using their private key to obtain the user ID and then queries the risk tag corresponding to that user ID locally. If no risk tag is found, the TEE's public key can be used to encrypt preset data (such as the string VALID) to obtain the encrypted query result. If a risk tag is found, a random string can be generated, and the concatenation of the risk tag and the random string can be encrypted using the TEE's public key to obtain the encrypted query result.

[0204] In step S1007, the TEE aggregates the risk data from various institutions and generates a set of encrypted risk labels.

[0205] Specifically, after receiving encrypted query results from other institutions, the TEE uses its own private key to decrypt each encrypted query result and summarizes the results to generate a risk label set. This risk label set includes one or more risk labels corresponding to the user ID. Then, the TEE uses institution A's public key to encrypt the risk label set, obtaining a encrypted risk label set.

[0206] In step S1009, the TEE provides the encrypted risk tag set to the agency device 100.

[0207] The TEE can store the encrypted risk tag set on a storage server and send the storage address to the institutional device 100 so that the institutional device 100 can read the encrypted risk tag set. Alternatively, the TEE can directly send the encrypted risk tag set to the institutional device 100.

[0208] In step S1011, after receiving the encrypted risk tag set, the institutional device 100 uses its own private key to decrypt the encrypted risk tag set to obtain the risk tag set corresponding to the user ID, and can then perform business processing based on the risk tag set.

[0209] In the embodiments of this specification, by combining TEE and blockchain to execute the risk data query method, the institutional equipment performs desensitization, encryption and other processing on the information of the user to be queried to obtain the user identifier and sends it to the TEE. The TEE then uses a preset algorithm to process the user identifier to obtain a desensitized user identifier, which is used to query whether the desensitized user identifier is included in the risk user list stored in the blockchain. This improves the query speed in real-time query scenarios while protecting user privacy and meeting the compliance requirements in the business scenario.

[0210] Figure 11 This is an architecture diagram of a server according to an embodiment of this specification, the server being used to execute... Figures 2 to 8 The server, as shown in any of the accompanying drawings, comprises:

[0211] The receiving unit 111 is used to receive encrypted query data from the first institutional device. The encrypted query data is obtained by encrypting query data. The query data includes the first user identifier of the first user to be queried. The first institutional device belongs to the first institution.

[0212] The providing unit 112 is used to provide the encrypted query data to the TEE;

[0213] The receiving unit 111 is further configured to: receive the second user identifier of the first user from the TEE, wherein the second user identifier of the first user is obtained by processing the first user identifier of the first user through a preset algorithm;

[0214] Sending unit 113 is used to send a query request to the blockchain to query whether the risk user list stored in the blockchain includes the second user identifier of the first user. The risk user list is generated based on multiple risk data from multiple institutions and includes the second user identifiers of multiple risk users.

[0215] The receiving unit 111 is further configured to receive query results from the blockchain;

[0216] The return unit 114 is used to return first information to the first institution device when it is determined from the query result that the second user identifier of the first user is not included in the list of risky users. The first information is used to indicate that the first user is not a risky user.

[0217] Figure 12 This is an architectural diagram of a trusted unit in an embodiment of this specification, the trusted unit being used to execute... Figure 9 or Figure 10 The method shown, wherein the trusted unit includes:

[0218] The receiving unit 121 is used to receive encrypted query data from the first institutional device. The encrypted query data is obtained by encrypting query data. The query data includes the first user identifier of the first user to be queried. The first institutional device belongs to the first institution.

[0219] The decryption unit 122 is used to decrypt the ciphertext query data, obtain the first user identifier of the first user, and process the first user identifier of the first user through a preset algorithm to obtain the second user identifier of the first user.

[0220] Sending unit 123 is used to send a query request to the blockchain to query whether the risk user list stored in the blockchain includes the second user identifier of the first user. The risk user list is generated based on multiple risk data from multiple institutions and includes the second user identifiers of multiple risk users.

[0221] The receiving unit 121 is also configured to receive query results from the blockchain;

[0222] The return unit 124 is used to return first information to the first institution device when it is determined from the query result that the second user identifier of the first user is not included in the list of risky users. The first information is used to indicate that the first user is not a risky user.

[0223] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform actions such as... Figures 2 to 10 The method shown in any of the accompanying figures.

[0224] This specification also provides a trusted unit, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements as follows: Figures 2 to 10 The method shown in any of the accompanying figures.

[0225] This specification also provides a server, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements... Figures 2 to 8 The method shown in any of the accompanying figures.

[0226] 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 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 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.

[0227] 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, ASICs, 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.

[0228] 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.

[0229] 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 the 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.

[0230] 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.

[0231] 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... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0232] 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.

[0233] 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.

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

[0235] 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.

[0236] 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.

[0237] 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.

[0238] 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.

[0239] 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.

[0240] 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 risk data query method, comprising: a first institution device sending ciphertext query data to a server, the ciphertext query data being obtained by encrypting query data, the query data including a first user identifier of a first user to be queried, the first institution device belonging to a first institution; the server providing the ciphertext query data to a trusted unit for processing private data; the trusted unit decrypting the ciphertext query data, obtaining the first user identifier of the first user, and performing desensitization processing on the first user identifier of the first user by a preset algorithm to obtain a second user identifier of the first user; sending the second user identifier of the first user to the server; the server sending a first query request to a blockchain to query whether the second user identifier of the first user is included in a risk user list stored in the blockchain, the risk user list being generated based on multiple risk data from multiple institutions and including second user identifiers of multiple risk users; the blockchain querying whether the second user identifier of the first user is included in the risk user list according to the first query request and returning a query result to the server; when the server determines that the second user identifier of the first user is not included in the risk user list according to the query result, returning first information to the first institution device, the first information being used to indicate that the first user is not a risk user.

2. The method of claim 1, further comprising: multiple institution devices sending ciphertext risk data of institutions to which the multiple institution devices belong to a server; the trusted unit obtaining multiple ciphertext risk data of the multiple institutions from the server, decrypting the multiple ciphertext risk data respectively to obtain multiple risk data, the risk data including user identifiers and risk labels corresponding to the user identifiers; generating the risk user list based on the multiple risk data; providing the risk user list to the server; the server storing the risk user list in the blockchain.

3. The method of claim 1 or 2, further comprising: when the server determines that the second user identifier of the first user is included in the risk user list according to the query result, instructing the trusted unit to perform a query according to the ciphertext query data; the trusted unit generating a second query request, the second query request including the first user identifier of the first user, encrypting the second query request to generate ciphertext query requests corresponding to multiple second institutions respectively, and sending each ciphertext query request to each second institution; each second institution decrypting the ciphertext query request to obtain the first user identifier, querying a risk label of the first user based on the first user identifier to obtain a query result, encrypting the query result to obtain a ciphertext query result, and sending the ciphertext query result to the server; the server providing the ciphertext query result of each second institution to the trusted unit; The trusted unit decrypts the ciphertext query result of each second institution to obtain a plurality of query results, generates a risk label set of the first user based on the plurality of query results, encrypts the risk label set, and obtains a ciphertext risk label set; The ciphertext risk label set is sent to the server; The server provides the ciphertext risk label set to the first institution device; The first institution device decrypts the ciphertext risk label set to obtain the risk label set of the first user.

4. The method of claim 1 or 2, the first user identity comprising: An abstract value of the one or more pieces of information of the first user is calculated through hash calculation.

5. The method of claim 4, further comprising: The first institution device calculates a first hash value of the one or more pieces of information of the first user, and sends the first hash value to the server; The server calculates a second hash value of the first hash value and a preset value as a first user identifier of the first user, and returns the first user identifier to the first institution device; The first institution device stores the correspondence between the first user identifier and the one or more pieces of information of the first user.

6. The method of claim 3, further comprising: The server stores the ciphertext risk data of each institution in association with the institution identifier of each institution after receiving a plurality of ciphertext risk data from a plurality of institution devices, and provides a storage address of each ciphertext risk data to the trusted unit, The trusted unit obtains the plurality of ciphertext risk data of the plurality of institutions through the server, including that the trusted unit obtains the plurality of ciphertext risk data based on each storage address.

7. The method of claim 3, the plurality of institutional devices sending the encrypted risk data of their respective institutions to the server further comprising: The plurality of institution devices sends the DID and the ciphertext risk data of the institution to which the plurality of institution devices belong to the server, and the method further includes that the server obtains the public key of the DID of the plurality of institutions from a block chain.

8. The method of claim 7, further comprising: The server provides the public key of the first institution to the trusted unit, and the trusted unit encrypting the risk label set includes that the trusted unit encrypts the risk label set using the public key of the first institution.

9. The method of claim 2, wherein the preset algorithm comprises any one of the following algorithms: concatenating the first user identifier with a preset string, performing symmetric encryption on the concatenated string, and taking the encrypted ciphertext as the second user identifier; concatenating the first user identifier with a preset string, encrypting the concatenated string using a trusted unit public key, and taking the encrypted ciphertext as the second user identifier; concatenating the first user identifier with a preset string, signing the concatenated string using a trusted unit private key, and taking the obtained signature as the second user identifier; concatenating the first user identifier with a preset string, signing the concatenated string using a trusted unit private key, and taking the hash value of the obtained signature as the second user identifier.

10. The method of claim 9, generating the risk user list based on the plurality of risk data comprises: determining the preset string, generating the risk user list based on the plurality of risk data through the preset algorithm, encrypting the preset string to obtain a ciphertext string, and storing the ciphertext string in a block chain, The method further includes that the trusted unit obtains the ciphertext string from the block chain before processing the first user identifier of the first user by a preset algorithm, and decrypts the ciphertext string to obtain the preset string.

11. A risk data query method, comprising: a first institution device sends ciphertext query data to a trusted unit, the ciphertext query data being obtained by encrypting query data, the query data including a first user identifier of a first user to be queried, and the first institution device belonging to a first institution; the trusted unit decrypts the ciphertext query data to obtain the first user identifier, and processes the first user identifier by a preset algorithm to obtain a second user identifier of the first user; a first query request is sent to a block chain to query whether the second user identifier of the first user is included in a risk user list stored in the block chain, the risk user list being generated based on multiple risk data from multiple institutions and including second user identifiers of multiple risk users; the block chain queries whether the second user identifier of the first user is included in the risk user list according to the first query request, and returns a query result to the trusted unit; when it is determined according to the query result that the second user identifier of the first user is not included in the risk user list, the trusted unit returns first information to the first institution device, the first information being used to indicate that the first user is not a risk user.

12. The method of claim 11, further comprising: when it is determined according to the query result that the second user identifier of the first user is included in the risk user list, the trusted unit generates a second query request including the first user identifier of the first user, encrypts the second query request to generate ciphertext query requests corresponding to respective second institutions, and sends the ciphertext query requests to the respective second institutions; each second institution decrypts the ciphertext query request to obtain the first user identifier, queries a risk label of the first user based on the first user identifier to obtain a query result, encrypts the query result to obtain a ciphertext query result, and sends the ciphertext query result to the trusted unit; the trusted unit decrypts the ciphertext query result of each second institution to obtain multiple query results, generates a risk label set of the first user based on the multiple query results, encrypts the risk label set to obtain a ciphertext risk label set, and sends the ciphertext risk label set to the first institution device; the first institution device decrypts the ciphertext risk label set to obtain the risk label set of the first user.

13. A risk data query method performed by a server, the method comprising: receiving ciphertext query data from a first institution device, the ciphertext query data being obtained by encrypting query data, the query data including a first user identifier of a first user to be queried, and the first institution device belonging to a first institution; ​ provide the ciphertext query data to the trusted unit; receive, from the trusted unit, a second user identifier of the first user, the second user identifier of the first user being obtained by desensitizing the first user identifier of the first user through a preset algorithm; send, to a blockchain, a query request for querying whether the second user identifier of the first user is included in a risk user list stored in the blockchain, the risk user list being generated based on multiple risk data from multiple institutions and including second user identifiers of multiple risk users; receive, from the blockchain, a query result; when it is determined according to the query result that the second user identifier of the first user is not included in the risk user list, return first information to the first institution device, the first information being used to indicate that the first user is not a risk user.

14. A risk data query method, performed by a trusted unit, comprising: receiving, from a first institution device, ciphertext query data, the ciphertext query data being obtained by encrypting query data, the query data including a first user identifier of a first user to be queried, the first institution device belonging to a first institution; decrypting the ciphertext query data to obtain the first user identifier of the first user, and obtaining a second user identifier of the first user by desensitizing the first user identifier of the first user through a preset algorithm; sending, to a blockchain, a query request for querying whether the second user identifier of the first user is included in a risk user list stored in the blockchain, the risk user list being generated based on multiple risk data from multiple institutions and including second user identifiers of multiple risk users; receiving, from the blockchain, a query result; when it is determined according to the query result that the second user identifier of the first user is not included in the risk user list, returning first information to the first institution device, the first information being used to indicate that the first user is not a risk user.

15. A risk data query system, comprising a first institution device, a server, a blockchain system, and a trusted unit for processing private data, the first institution device is configured to send ciphertext query data to the server, the ciphertext query data being obtained by encrypting query data, the query data including a first user identifier of a first user to be queried, the first institution device belonging to a first institution; the server is configured to provide the ciphertext query data to the trusted unit; the trusted unit is configured to decrypt the ciphertext query data to obtain the first user identifier of the first user, and obtain a second user identifier of the first user by desensitizing the first user identifier of the first user through a preset algorithm; and send the second user identifier of the first user to the server; the server is further configured to send, to a blockchain, a query request for querying whether the second user identifier of the first user is included in a risk user list stored in the blockchain, the risk user list being generated based on multiple risk data from multiple institutions and including second user identifiers of multiple risk users; The blockchain system is configured to query whether the first user's second user identifier is included in the risk user list according to the query request, and return a query result to the server; The server is further configured to return first information to the first institution device when it is determined according to the query result that the first user's second user identifier is not included in the risk user list, wherein the first information is used to indicate that the first user is not a risk user.

16. A server, comprising: a receiving unit configured to receive ciphertext query data from a first institution device, wherein the ciphertext query data is obtained by encrypting query data, the query data including a first user identifier of a first user to be queried, and the first institution device belongs to a first institution; a providing unit configured to provide the ciphertext query data to a trusted unit; the receiving unit is further configured to receive a second user identifier of the first user from the trusted unit, wherein the second user identifier of the first user is obtained by desensitizing the first user identifier of the first user through a preset algorithm; a sending unit configured to send a query request to a blockchain to query whether the first user's second user identifier is included in a risk user list stored in the blockchain, wherein the risk user list is generated based on multiple risk data from multiple institutions and includes second user identifiers of multiple risk users; the receiving unit is further configured to receive a query result from the blockchain; a returning unit configured to return first information to the first institution device when it is determined according to the query result that the first user's second user identifier is not included in the risk user list, wherein the first information is used to indicate that the first user is not a risk user.

17. A trusted unit, comprising: a receiving unit configured to receive ciphertext query data from a first institution device, wherein the ciphertext query data is obtained by encrypting query data, the query data including a first user identifier of a first user to be queried, and the first institution device belongs to a first institution; a decryption unit configured to decrypt the ciphertext query data to obtain the first user identifier of the first user, and to obtain a second user identifier of the first user by desensitizing the first user identifier of the first user through a preset algorithm; a sending unit configured to send a query request to a blockchain to query whether the first user's second user identifier is included in a risk user list stored in the blockchain, wherein the risk user list is generated based on multiple risk data from multiple institutions and includes second user identifiers of multiple risk users; the receiving unit is further configured to receive a query result from the blockchain; a returning unit configured to return first information to the first institution device when it is determined according to the query result that the first user's second user identifier is not included in the risk user list, wherein the first information is used to indicate that the first user is not a risk user.

18. A computer-readable storage medium having a computer program stored thereon, the computer program, when executed in a computer, causing the computer to perform the method of claim 13 or 14.

Images