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

Abstract

A risk data query method, system, trusted unit, and server are disclosed. The method includes: a first institutional device sending encrypted query data to a server; the server providing the encrypted query data and pre-acquired first encrypted data to a trusted unit for privacy data processing; the trusted unit decrypting the encrypted query data and the first encrypted data to obtain query data and first data; when it is determined that the first data includes a first user identifier, writing the first user identifier and a corresponding first risk tag set into the second data according to the first data; encrypting the second data to obtain second encrypted data, and providing the second encrypted data to the server; the server providing the second encrypted data to the first institutional device; and the first institutional device decrypting the second encrypted data to obtain the first risk tag set corresponding to the first user identifier.

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 anti-money laundering obligations, including analyzing and reporting transaction data for large and suspicious transactions. However, information silos between institutions create information islands, 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-money laundering 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 and a trusted unit to process risk data in the trusted unit, thereby saving the computing and storage resources of the trusted unit.

[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 and the pre-acquired first encrypted data to a trusted unit for privacy data processing. The first encrypted data is obtained by encrypting the first data. The first data includes risk information of n users, and the risk information of each user includes the user's user identifier and risk tag set.

[0007] The trusted unit decrypts the encrypted query data and the first encrypted data to obtain the query data and the first data; when it is determined that the first data includes a first user identifier, it writes the first risk tag set corresponding to the first user identifier in the first data into the second data; it encrypts the second data to obtain the second encrypted data, and provides the second encrypted data to the server;

[0008] The server provides the second encrypted data to the first institutional device;

[0009] The first device decrypts the second encrypted data to obtain the first risk tag set corresponding to the first user identifier.

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

[0011] The encrypted query data and the first encrypted data are obtained from 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 by the first institution. The first encrypted data is obtained by encrypting the first data. The first data includes the risk information of n users. The risk information of each user includes the user identifier and risk tag set of that user.

[0012] Decrypt the ciphertext query data and the first ciphertext data to obtain the query data and the first data;

[0013] When it is determined that the first data includes a first user identifier, the first risk tag set corresponding to the first user identifier in the first data is written into the second data; the second data is encrypted to obtain second ciphertext data, and the second ciphertext data is provided to the server.

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

[0015] 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;

[0016] The trusted unit is provided with the encrypted query data and the pre-acquired first encrypted data. The first encrypted data is obtained by encrypting the first data using the public key of the trusted unit. The first data includes risk information of n users, and the risk information of each user includes the user's user identifier and risk tag set.

[0017] The second encrypted data is received from the trusted unit. The second encrypted data is obtained by encrypting the second data. The second data includes the first user identifier and the first risk label set corresponding to the first user identifier. The first risk label set is obtained from the first data.

[0018] The second encrypted data is provided to the first mechanism device.

[0019] The fourth aspect of this specification provides a risk data query system, including a first-level institutional device and a server.

[0020] The first mechanism device is used to send 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 mechanism device belongs to the first mechanism.

[0021] The server is used to provide the encrypted query data and the pre-acquired first encrypted data to the trusted unit. The first encrypted data is obtained by encrypting the first data. The first data includes risk information of n users, and the risk information of each user includes the user's user identifier and risk tag set.

[0022] The trusted unit is used to decrypt the encrypted query data and the first encrypted data to obtain the query data and the first data; when it is determined that the first data includes a first user identifier, the first risk tag set corresponding to the first user identifier in the first data is written into the second data; the second data is encrypted to obtain the second encrypted data, and the second encrypted data is provided to the server;

[0023] The server is also used to provide the second encrypted data to the first institution device;

[0024] The first device is used to decrypt the second encrypted data to obtain the first risk tag set corresponding to the first user identifier.

[0025] The fifth aspect of this specification provides a reliable element, including:

[0026] The acquisition unit is used to acquire encrypted query data and first encrypted data from 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 by the first institution. The first encrypted data is obtained by encrypting the first data. The first data includes risk information of n users. The risk information of each user includes the user identifier and risk tag set of that user.

[0027] A decryption unit is used to decrypt the ciphertext query data and the first ciphertext data to obtain the query data and the first data.

[0028] The writing unit is configured to write the first risk tag set corresponding to the first user identifier in the first data into the second data when it is determined that the first data includes the first user identifier.

[0029] An encryption unit is used to encrypt the second data to obtain second ciphertext data;

[0030] A providing unit is used to provide the second encrypted data to the server.

[0031] The sixth aspect of this specification provides a server, comprising:

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

[0033] A providing unit is configured to provide the encrypted query data and pre-acquired first encrypted data to a trusted unit. The first encrypted data is obtained by encrypting the first data using the public key of the trusted unit. The first data includes risk information of n users, and the risk information of each user includes the user's user identifier and risk tag set.

[0034] The receiving unit is further configured to receive second encrypted data from the trusted unit. The second encrypted data is obtained by encrypting second data. The second data includes the first user identifier and a first risk label set corresponding to the first user identifier. The first risk label set is obtained from the first data.

[0035] The providing unit is also used to provide the second encrypted data to the first mechanism device.

[0036] The seventh aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the methods described in the second or third aspect.

[0037] This specification provides a computing device in an eighth aspect, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the second or third aspect.

[0038] In the embodiments of this specification, by combining a server and a trusted unit to execute a risk data query method, the institutional equipment performs desensitization, encryption, and other processing on the user identifier of the user to be queried and sends it to the server, which then provides it to the trusted unit, thus protecting user privacy. At the same time, the trusted unit only needs to interact with the server and does not need to interact with each institutional equipment. The trusted unit only needs to set up a relatively simple application, and it does not need to store risk data, thus saving the computing and storage resources of the trusted unit. Attached Figure Description

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

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

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

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

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

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

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

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

[0047] Figure 8 This is an architecture diagram of a trusted unit in one of the embodiments of this specification;

[0048] Figure 9 This is an architecture diagram of a server as described in one of the embodiments of this specification. Detailed Implementation

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

[0050] Data sharing is frequently a necessity for organizations in processing their operations. A single organization often cannot obtain enough information to handle its business, thus creating a need to acquire information from other organizations. For example, many countries require financial institutions to provide anti-money laundering audit results as part of their anti-money laundering compliance requirements. Currently, many central banks and large financial institutions are attempting to utilize blockchain technology in the anti-money laundering field to improve efficiency and accuracy while meeting 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 further illustrate this using the aforementioned anti-money laundering example.

[0051] Anti-Money Laundering (AML) refers to measures to prevent money laundering activities that conceal or disguise the source and nature of proceeds and profits from crimes such as drug trafficking, organized crime, terrorism, smuggling, corruption, bribery, and crimes disrupting financial order. Common money laundering channels involve a wide range of sectors including banking, insurance, securities, and real estate. Most AML efforts include three core aspects:

[0052] 1. Customer due diligence system. When establishing a business relationship or conducting transactions with a customer, entities obligated to combat money laundering shall verify and record the customer's identity based on valid identification documents, and update the customer's identity information in a timely manner during the duration of the business relationship.

[0053] 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 unusual transactions lacking legitimate purpose to the anti-money laundering administrative authorities, as clues for investigating illegal and criminal activities.

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

[0055] 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 of anti-money laundering.

[0056] 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 money laundering risk level, the type of illegal activity, or other money laundering-related information. 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.

[0057] Taking customer money laundering risk rating as an example, different financial institutions may assign different money laundering risk ratings to the same user after conducting suspicious transaction analysis. For instance, Institution A might assign a high-risk rating to user U1, while Institution B might assign a medium-risk rating. A better approach for a financial institution to more accurately assign money laundering risk ratings to users is to obtain the ratings from another (or more) financial institutions for the same user. Therefore, there is a need to share the same user's money laundering risk rating across different financial institutions.

[0058] Figure 1 This is a schematic diagram of the system in the embodiments of this specification. Figure 1 As 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 companies, 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-money laundering 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.

[0059] Taking money laundering risk level as a specific risk label as an example, Institution A and Institution B can each label a user's money laundering risk level based on their own anti-money laundering audit capabilities. Therefore, the money laundering risk level 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 money laundering risk level, multiple institutions can share the same user's money laundering risk level label through an anti-money laundering 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.

[0060] 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 example shown is 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 risk data to server 400, which then stores the risk data of each organization locally or on a file storage server. Figure 1 (Not shown in the diagram). TEE40 can receive the address where risk data is stored from server 400, retrieve the risk data from that address, and fuse the risk data from multiple institutions to obtain a union of risk data. TEE40 can then respond to query requests from various institutions by retrieving user risk data from this union of risk data. 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.

[0061] 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 1Any one of the multiple mechanisms in the system. The following description uses mechanism 100 as an example.

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

[0063] 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 initial risk data 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:

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

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

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

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

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

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

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

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

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

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

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

[0075] 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 together in a persistent medium, so that it can be subsequently used for processing updated risk documents. Specifically, the agency device may store the user identity information and the user ID together in a mapping table.

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

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

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

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

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

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

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

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

[0084] 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 through 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.

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

[0086] 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:

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

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

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

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

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

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

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

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

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

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

[0097] In step S403, server 400 provides TEE with encrypted risk data files (including file F3) and institutional public keys corresponding to each institution's DID.

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

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

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

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

[0102] In step S405, the TEE uploads the public keys of each organization received from the server onto the blockchain.

[0103] In step S405, the TEE uploads the public keys of each organization received from the server onto the blockchain.

[0104] By uploading the public keys of various organizations received from the server to the blockchain, TEE records the server's operations on the blockchain. Each organization can verify the correctness of the public key provided by the server, thus avoiding the possibility of malicious server behavior. For example, the server might replace the public key of the organization's device with its own public key and provide it to TEE. The server could then use its own private key to decrypt a file encrypted with the server's public key that was supposed to be encrypted with the organization's device's public key before being sent to the organization's device. In this way, the server could steal users' private information.

[0105] In step S407, the TEE generates a risk union file F4.

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

[0107] Figure 5 This is a schematic diagram illustrating the process of generating the risk union file F4 in the embodiments of this specification. Figure 5 The 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.

[0108] When merging multiple risk data files in TEE, such as Figure 5 As shown, each risk data file is first indicated by a pointer to the smallest user ID. 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.

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

[0110] Understandable. Figure 5The risk union file F4 shown is merely an example and is not intended to limit the scope of the embodiments described in this specification. For example, the risk union file may only include a set of user identifiers and risk tags for querying user risk data.

[0111] In step S409, the TEE uses its public key to encrypt the risk union file F4, resulting in the ciphertext risk union file F5.

[0112] TEE encrypts file F4 using its public key, preventing server 400 from reading the information in file F4, thereby further protecting user and institutional privacy.

[0113] In step S411, the TEE sends file F5 to server 400.

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

[0115] In step S413, the server stores file F5.

[0116] Specifically, server 400 can store file F5 in an internal or external storage server and record the storage address of file F5 for retrieval.

[0117] Figure 6 This is a flowchart illustrating the method for generating encrypted risk query data 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.

[0118] like Figure 6 As shown, firstly, in step S601, the mechanism device 100 reads the initial query data file F6 to obtain the identity information of the user to be queried.

[0119] Within institution A corresponding to institution device 100, the institution administrator can periodically generate an initial query data file F6 in institution device 100 based on the data analysis results within institution A. This file F6 includes the identity information of one or more users to be queried within institution A. The identity information includes, for example, name and identification number. Specifically, file F6 can include multiple lines, each in the form of "name / certType / certNum", where name is the user's name, certType is the identification type, and certNum is the identification number; these three elements constitute the three key components of the user's identity information.

[0120] After the administrator generates file F6 in the institution's device 100, they upload file F6 to the client's storage. Upon detecting an update to file F6, the client can read file F6 line by line to obtain the identity information of each user to be queried.

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

[0122] To protect user privacy, the user identity information in file F6 needs to be anonymized; that is, user identity information cannot be directly included in the query data file sent from institution 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 F6, the client in institution 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 S605 to request the user's user ID from server 400.

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

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

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

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

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

[0128] 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 data 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.

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

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

[0131] In step S611, the mechanism device 100 writes the user ID into the query data file F7.

[0132] If the mechanism device 100 determines in step S603 that the 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.

[0133] While the client in the mechanism device 100 begins reading file F6, it can initialize file F7. After obtaining the user ID corresponding to a line in file F6 by reading line by line, the client records the user ID in the corresponding line in file F7. After performing the above processing on each line in file F6, the client can generate a query data file F7 corresponding to file F6.

[0134] In one implementation, after generating file F7 as described above, the client can sort the lines in file F7 in ascending order of each user ID, so as to facilitate subsequent queries from the risk union file in ascending order of user ID, thereby improving query efficiency.

[0135] In step S613, the client can also use the TEE's public key to encrypt file F7, thereby generating ciphertext query data file F8. This prevents external entities outside the TEE of server 400 from obtaining the user IDs queried by institutional device 100, further protecting user privacy. It is understood that this is not limited to using the TEE's public key to encrypt file F7; for example, the TEE and institutional device can negotiate other asymmetric or symmetric keys for encrypting file F7.

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

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

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

[0139] In step S703, server 400 provides the aforementioned encrypted risk union file F5, file F8 and the organization's public key to TEE in order to request a query for user risk information.

[0140] After receiving file F8 from device 100, server 400 can store file F8 in a storage server inside or outside the server and obtain the storage address of file F8.

[0141] Subsequently, server 400 can send the storage addresses of files F5 and F8, as well as the public key of institution A, to the TEE. The TEE can then read files F5 and F8 from their respective addresses. The TEE can use its own private key to decrypt files F5 and F8 respectively, obtaining the risk union file F4 and the query data file F7. Institution A's public key is subsequently used to encrypt files sent to institution A. It can be understood that the TEE is not limited to using the institution's public key to encrypt files sent to the institution; it can use any key negotiated between the TEE and the institution's equipment, or between the server and the institution's equipment, including symmetric and asymmetric keys.

[0142] In step S705, the TEE uploads the request parameters to the blockchain.

[0143] The request parameters may include, for example, the public key of the institutional device 100 and the file address.

[0144] By recording request parameters and server operations on the blockchain, the TEE allows institutions to verify the correctness of the public key provided by the server. This prevents malicious server actions, such as the server potentially replacing the institution's public key with its own. The server could then use its private key to decrypt files encrypted with the server's public key but intended to be encrypted with the institution's public key before being sent to the institution, thus stealing user privacy information. Furthermore, server query operations can be documented to prevent the server from initiating queries itself to steal user privacy.

[0145] In step S707, the TEE generates the query result file F9.

[0146] Specifically, after obtaining the risk union file F4 and the query data file F7, the TEE can read the user identifiers line by line from the query data file F7 in the order of the user identifiers, and create the query result file F9 simultaneously with the start of reading file F7. For example, after reading a certain user identifier (e.g., the user identifier of user U2) from file F7, the TEE checks whether the risk union file F4 includes the user identifier of user U2. If the risk union file F4 includes the user identifier of user U2, the TEE reads the set of risk tags corresponding to the user identifier of user U2 from the risk union file F4, and records the user identifier of user U2 and the set of risk tags corresponding to that user identifier in a line in the query result file F9. After performing the above processing on each user identifier in file F7, file F9 can be generated.

[0147] Meanwhile, to encourage institutions to share their risk data with other institutions, the server can record the scores of each institution, which are updated based on the institution's use of file F4. Specifically, after determining that institution A has retrieved the risk label set for user U2 in file F8 by using file F4 as described above, the TEE reduces institution A's score by a preset value, while simultaneously increasing the scores of each institution in the institution identifier set corresponding to user U2 by a preset value. After generating file F9, the TEE also receives the updated score information for each institution.

[0148] In step S709, the TEE uses the public key of organization A to encrypt file F9, resulting in ciphertext file F10.

[0149] TEE encrypts file F9 using organization A's public key before sending it to server 400, preventing server 400 from reading the information in file F9. Only organization A can read file F9, thus further protecting the privacy of both the user and the organization.

[0150] In step S711, the TEE provides file F10 to server 400.

[0151] Specifically, the TEE can store file F10 outside the TEE (i.e., the aforementioned EPC) (e.g., on a storage medium within server 400 or on a storage server outside of server 400), and send the storage address of file F10 to server 400, thus allowing server 400 to read file F10. Alternatively, the TEE can directly send file F10 to server 400.

[0152] Simultaneously, the TEE can provide updated score information for each institution to the server 400. Assuming the updated information reduces institution A's score by 5 points, after receiving this update, the server 400 first queries institution A's current score. If institution A's current score of 3 points is insufficient to deduct 5 points, the server 400 can charge institution A a query fee. At the same time, the server 400 increases the scores of other institutions based on the updated information. In this way, institutions can reduce query fees by sharing their risk data with other institutions, thereby promoting the sharing of risk data among institutions.

[0153] In step S713, server 400 sends file F10 to mechanism device 100.

[0154] After reading file F10, server 400 can directly send file F10 to mechanism device 100.

[0155] In step S715, the mechanism device 100 uses its private key to decrypt file F10 to obtain file F9.

[0156] In step S717, the mechanism device 100 replaces the user ID in file F9 with user identity information to obtain file F11.

[0157] Specifically, the institutional device 100 can read the user identity information corresponding to each user ID in file F9 from the aforementioned stored mapping table of user identity information and user IDs, and replace the user IDs in file F9 with the user identity information, thereby generating file F11. The institutional device 100 can then comprehensively judge the risk level of users based on the risk tag set of each user in file F11, improving the accuracy of the judgment.

[0158] In the embodiments of this specification, by combining a server and a TEE to execute a risk data query method, the institutional equipment performs desensitization, encryption, and other processing on the user identifier of the user to be queried and sends it to the server, which then provides it to the TEE. This protects user privacy and meets the compliance requirements in the business scenario. At the same time, the TEE only needs to interact with the server and does not need to interact with various institutional equipment. Only a relatively simple application needs to be set up in the TEE, and the TEE does not need to store risk data, thus saving the computational and storage resources of the TEE.

[0159] Figure 8 This is an architectural diagram of a trusted unit in one of the embodiments described herein, the trusted unit being used to perform, for example... Figures 2 to 7 The method shown includes:

[0160] The acquisition unit 81 is used to acquire encrypted query data and first encrypted data from 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 by the first institution. The first encrypted data is obtained by encrypting the first data. The first data includes risk information of n users. The risk information of each user includes the user identifier, risk tag set, and institution identifier set of the user. The risk tag set includes risk tags obtained from the multiple risk data based on the user identifier of the user. The institution identifier set includes the institution identifier of the institution that provides the risk tags of the user.

[0161] Decryption unit 82 is used to decrypt the ciphertext query data and the first ciphertext data to obtain the query data and the first data;

[0162] The writing unit 83 is used to write the first user identifier and the first risk label set corresponding to the first user identifier into the second data when it is determined that the first data includes the first user identifier.

[0163] Encryption unit 84 is used to encrypt the second data to obtain the second ciphertext data;

[0164] The providing unit 85 is used to provide the second encrypted data to the server.

[0165] Figure 9 This specification describes an embodiment of a server, which is used to perform actions such as... Figures 2 to 7 The method shown includes:

[0166] The receiving unit 91 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.

[0167] The providing unit 92 is used to provide the encrypted query data and the pre-acquired first encrypted data to the TEE. The first encrypted data is obtained by encrypting the first data using the public key of the TEE. The first data is generated based on multiple risk data from multiple institutions. The first data includes risk information of n users. The risk information of each user includes the user's user identifier, risk tag set, and institution identifier set. The risk tag set includes risk tags obtained from the multiple risk data based on the user's user identifier. The institution identifier set includes the institution identifier of the institution that provided the user's risk tags.

[0168] The receiving unit 91 is further configured to receive second encrypted data from the TEE. The second encrypted data is obtained by encrypting second data. The second data includes the first user identifier and a first risk tag set corresponding to the first user identifier. The first risk tag set is obtained from the first data.

[0169] The providing unit 92 is also used to provide the second encrypted data to the first mechanism device.

[0170] 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 7 The method shown.

[0171] This specification also provides a TEE (Technical Equipment for Executable Execution), including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements... Figures 2 to 7 The method shown.

[0172] 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 7 The method shown.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A method for querying risk data, comprising: Multiple institutions' devices send their respective institutions' encrypted risk data to the server; The trusted unit obtains multiple encrypted risk data from the server, decrypts the multiple encrypted risk data respectively to obtain multiple risk data, and the risk data includes user identifiers and risk tags of multiple users in the corresponding institution; First data is generated based on the aforementioned multiple risk data; The first data is encrypted to obtain the first ciphertext data; The first encrypted data is provided to the server; the first data includes multiple rows, each row corresponding to all risk users included in the multiple institutions, and each row includes a user ID, a risk tag set, and an institution set, wherein the risk tag set is obtained from multiple risk data, and the institution set includes the institution identifier of the institution that provides the risk tags; 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. The server provides the encrypted query data and the pre-acquired first encrypted data to a trusted unit for privacy data processing. The first encrypted data is obtained by encrypting the first data. The first data includes risk information of n users, and the risk information of each user includes the user's user identifier and risk tag set. The trusted unit decrypts the encrypted query data and the first encrypted data to obtain the query data and the first data; when it is determined that the first data includes a first user identifier, it writes the first risk tag set corresponding to the first user identifier in the first data into the second data; it encrypts the second data to obtain the second encrypted data, and provides the second encrypted data to the server; The server provides the second encrypted data to the first institutional device; The first device decrypts the second encrypted data to obtain the first risk tag set corresponding to the first user identifier.

2. The method according to claim 1, wherein the first user identifier comprises: The digest value obtained by hashing one or more pieces of information of the first user.

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

4. The method according to claim 3, wherein the first institutional device decrypts the second encrypted data to obtain the first risk tag set corresponding to the first user identifier, comprising: The first mechanism decrypts the second encrypted data to obtain the second data. Based on the pre-stored correspondence between the first user identifier and one or more pieces of information of the first user, third data is generated, the third data including one or more pieces of information of the first user and the first risk tag set.

5. The method according to claim 1, further comprising: After receiving the multiple encrypted risk data from the multiple institutional devices, the server stores the encrypted risk data of each institution in association with the institution's identifier, and provides the storage address of each encrypted risk data to the trusted unit. The trusted unit obtains multiple encrypted risk data of the multiple institutions through the server, including: the trusted unit obtains the multiple encrypted risk data based on each storage address.

6. The method according to claim 1, further comprising: The server provides the public key of the first institution to the trusted unit, and the trusted unit encrypts the second data by using the public key of the first institution to encrypt the second data.

7. The method according to claim 6, further comprising: After receiving the public key of the first institution from the server, the trusted unit will store the public key of the first institution received from the server in the blockchain.

8. The method according to claim 6, wherein the public key of the first institution is the public key of the DID of the first institution, and the method further comprises: The server obtains the public key of the first institution's DID from the blockchain.

9. The method according to claim 1, wherein the user's risk information further includes a set of institutional identifiers, the set of institutional identifiers including the institutional identifiers of the institution providing the user's risk label, and the method further includes: After generating the second ciphertext data, the trusted unit reduces the score of the first institution, increases the score of each second institution in the institution identifier set corresponding to the first user identifier, and provides the score information of the first institution and each second institution to the server; the server updates the scores of the first institution and each second institution according to the score information.

10. A risk data query method, executed by a trusted unit, comprising: Multiple encrypted risk data from multiple institutions are obtained from the server. The multiple encrypted risk data are decrypted to obtain multiple risk data. The risk data includes user identifiers and risk tags of multiple users in the corresponding institutions. First data is generated based on the aforementioned multiple risk data; The first data is encrypted to obtain the first ciphertext data; The first encrypted data is provided to the server; the first data includes multiple rows, each row corresponding to all risk users included in the multiple institutions, and each row includes a user ID, a risk tag set, and an institution set, wherein the risk tag set is obtained from multiple risk data, and the institution set includes the institution identifier of the institution that provides the risk tags; The encrypted query data and the first encrypted data are obtained from 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 by the first institution. The first encrypted data is obtained by encrypting the first data. The first data includes the risk information of n users. The risk information of each user includes the user identifier and risk tag set of that user. Decrypt the ciphertext query data and the first ciphertext data to obtain the query data and the first data; When it is determined that the first data includes a first user identifier, the first risk tag set corresponding to the first user identifier in the first data is written into the second data; the second data is encrypted to obtain second ciphertext data, and the second ciphertext data is provided to the server.

11. A risk data query method, executed by a server, the method comprising: Receive encrypted risk data from multiple institutions' devices, representing the respective institutions; Obtain the first ciphertext data provided by the trusted unit; The first encrypted data is obtained by encrypting the first data. The first data is generated based on multiple risk data. The multiple risk data are obtained by a trusted unit decrypting multiple encrypted risk data from multiple institutions. The risk data includes user identifiers and risk tags of multiple users in the institution corresponding to the risk data. The first data includes multiple rows, which correspond to all risk users included in the multiple institutions. Each row includes a user ID, a risk tag set, and an institution set. The risk tag set is obtained from multiple risk data, and the institution set includes the institution identifier of the institution that provides the risk tags. 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; The trusted unit is provided with the encrypted query data and the pre-acquired first encrypted data. The first encrypted data is obtained by encrypting the first data using the public key of the trusted unit. The first data includes risk information of n users, and the risk information of each user includes the user's user identifier and risk tag set. The second encrypted data is received from the trusted unit. The second encrypted data is obtained by encrypting the second data. The second data includes the first user identifier and the first risk label set corresponding to the first user identifier. The first risk label set is obtained from the first data. The second encrypted data is provided to the first mechanism device.

12. A risk data query system, comprising a first institutional device, a server, and a trusted unit. The server is used to receive encrypted risk data of the affiliated organization sent by multiple institutional devices; The trusted unit is used to obtain multiple encrypted risk data of the multiple institutions from the server, decrypt the multiple encrypted risk data respectively to obtain multiple risk data, and the risk data includes user identifiers and risk tags of multiple users in the institution corresponding to the risk data; First data is generated based on the aforementioned multiple risk data; The first data is encrypted to obtain the first ciphertext data; The first encrypted data is provided to the server; the first data includes multiple rows, each row corresponding to all risk users included in the multiple institutions, and each row includes a user ID, a risk tag set, and an institution set, wherein the risk tag set is obtained from multiple risk data, and the institution set includes the institution identifier of the institution that provides the risk tags; The first mechanism device is used to send 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 mechanism device belongs to the first mechanism. The server is also used to provide the encrypted query data and the pre-acquired first encrypted data to the trusted unit. The first encrypted data is obtained by encrypting the first data. The first data includes risk information of n users, and the risk information of each user includes the user's user identifier and risk tag set. The trusted unit is further configured to decrypt the encrypted query data and the first encrypted data to obtain the query data and the first data; when it is determined that the first data includes a first user identifier, write the first risk tag set corresponding to the first user identifier in the first data into the second data; encrypt the second data to obtain the second encrypted data, and provide the second encrypted data to the server; The server is also used to provide the second encrypted data to the first institution device; The first device is also used to decrypt the second encrypted data to obtain the first risk tag set corresponding to the first user identifier.

13. A trusted unit, comprising: The aggregation unit is used to obtain multiple encrypted risk data from multiple institutions from the server, decrypt the multiple encrypted risk data respectively to obtain multiple risk data, and the risk data includes user identifiers and risk tags of multiple users in the institution corresponding to the risk data; First data is generated based on the aforementioned multiple risk data; The first data is encrypted to obtain the first ciphertext data; The first encrypted data is provided to the server; the first data includes multiple rows, each row corresponding to all risk users included in the multiple institutions, and each row includes a user ID, a risk tag set, and an institution set, wherein the risk tag set is obtained from multiple risk data, and the institution set includes the institution identifier of the institution that provides the risk tags; The acquisition unit is used to acquire encrypted query data and first encrypted data from 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 by the first institution. The first encrypted data is obtained by encrypting the first data. The first data includes risk information of n users. The risk information of each user includes the user identifier and risk tag set of that user. A decryption unit is used to decrypt the ciphertext query data and the first ciphertext data to obtain the query data and the first data. The writing unit is configured to write the first risk tag set corresponding to the first user identifier in the first data into the second data when it is determined that the first data includes the first user identifier. An encryption unit is used to encrypt the second data to obtain second ciphertext data; A providing unit is used to provide the second encrypted data to the server.

14. A server, comprising: The acquisition unit is used to receive encrypted risk data of the respective organizations sent by multiple institutional devices; Obtain the first ciphertext data provided by the trusted unit; The first encrypted data is obtained by encrypting the first data. The first data is generated based on multiple risk data. The multiple risk data are obtained by a trusted unit decrypting multiple encrypted risk data from multiple institutions. The risk data includes user identifiers and risk tags of multiple users in the institution corresponding to the risk data. The first data includes multiple rows, which correspond to all risk users included in the multiple institutions. Each row includes a user ID, a risk tag set, and an institution set. The risk tag set is obtained from multiple risk data, and the institution set includes the institution identifier of the institution that provides the risk tags. 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. A providing unit is configured to provide the encrypted query data and pre-acquired first encrypted data to a trusted unit. The first encrypted data is obtained by encrypting the first data using the public key of the trusted unit. The first data includes risk information of n users, and the risk information of each user includes the user's user identifier and risk tag set. The receiving unit is further configured to receive second encrypted data from the trusted unit. The second encrypted data is obtained by encrypting second data. The second data includes the first user identifier and a first risk label set corresponding to the first user identifier. The first risk label set is obtained from the first data. The providing unit is also used to provide the second encrypted data to the first mechanism device.

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

Images