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

Abstract

A risk data query method, system, TEE and server, the method comprises: a first institution device sends ciphertext query data to a server, the server provides the ciphertext query data and pre-acquired first ciphertext data to a trusted unit; the trusted unit decrypts the ciphertext query data and the first ciphertext data to obtain query data and first data; when it is determined that the first data includes account information of a second account, a first risk label set corresponding to the account information of the second account in the first data is written in second data; the second data is encrypted to obtain second ciphertext data, and the second ciphertext data is provided to the server; the server provides the second ciphertext data to the first institution device; the first institution device decrypts the second ciphertext data to obtain a first risk label set corresponding to the second account.

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 analyze and report 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. 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 query the risk data of an organization's upstream and downstream accounts within the trusted unit, thereby improving the efficiency of querying risk data of an organization's upstream and downstream accounts.

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

[0005] The first institution device sends encrypted query data to the server. The encrypted query data is obtained by encrypting the query data. The query data includes the account information of the second account of the second institution to be queried. The first institution device belongs to the first institution, and the second account is the business-related account of the first account in 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 at least account information and a risk label set of n accounts in the second institution, where n can be a natural number.

[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 the account information of the second account, it writes the first risk tag set corresponding to the account information of the second account 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 institution device decrypts the second encrypted data to obtain the first risk tag set corresponding to the second account.

[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 account information of the second account of the second institution to be queried. The first encrypted data is obtained by encrypting the first data. The first data includes at least the account information and risk label set of n accounts in the second institution.

[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 the account information of the second account, a first risk tag set corresponding to the account information of the second account 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 the first institution. The encrypted query data is obtained by encrypting the query data. The query data includes account information of the second account of the second institution to be queried. The first institution belongs to the first institution, and the second account is the business-related account of the first account in the first institution.

[0016] The encrypted query data and the pre-acquired first encrypted data are provided to the trusted unit. The first encrypted data is obtained by encrypting the first data. The first data includes at least account information and a risk label set of n accounts in the second institution.

[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 a first risk tag set corresponding to the account information of the second account. The first risk tag set is obtained from the first data based on the account information of the second account.

[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 institutional device, a server, and a trusted unit.

[0020] The first institution 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 account information of the second account of the second institution to be queried. The first institution device belongs to the first institution, and the second account is the business-related account of the first account in the first institution.

[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 at least account information and a risk tag set of n accounts in the second institution.

[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 the account information of the second account, the first risk tag set corresponding to the account information of the second account 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 also used to decrypt the second encrypted data to obtain the first risk tag set corresponding to the second account.

[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 account information of the second account of the second institution to be queried. The first encrypted data is obtained by encrypting the first data. The first data includes account information and a risk label set of at least n accounts in the second institution.

[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 used to write a first risk tag set corresponding to the account information of the second account in the first data into the second data when it is determined that the first data includes the account information of the second account.

[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] The receiving unit is configured to receive encrypted query data from the first institution's equipment. The encrypted query data is obtained by encrypting query data. The query data includes account information of the second account of the second institution to be queried. The first institution's equipment belongs to the first institution, and the second account is a business-related account of the first account in the 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 first data, and the first data includes at least account information and a risk tag set of n accounts in the second institution.

[0034] The receiving unit is further configured to: receive second encrypted data from the trusted unit, the second encrypted data being obtained by encrypting second data, the second data including a first risk tag set corresponding to the account information of the second account, the first risk tag set being obtained from the first data based on the account information of the second account;

[0035] The providing unit is further configured 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 TEE to perform a risk data query method, the institutional device performs desensitization, encryption and other processing on the user identifier of the user to be queried and sends it to the server. The server provides the encrypted query file and the encrypted summary file to the TEE, and the TEE decrypts the encrypted query file and the encrypted summary file, thereby querying the risk data of the institution's upstream and downstream accounts. This improves the efficiency of the institution in querying the risk data of upstream and downstream accounts while protecting user privacy. 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 push 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 summary file of the organization in the embodiments of this specification.

[0045] Figure 6 This is a schematic diagram illustrating the process of generating a summary file in the embodiments of this specification;

[0046] Figure 7 This is a flowchart illustrating the method for generating encrypted query files on the device side in the embodiments of this specification.

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

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

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

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

[0051] Data sharing is frequently a necessity for organizations to process their business. A single organization often cannot obtain enough information to handle its operations, thus creating a need to acquire information from other organizations. 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.

[0052] Different financial institutions have an obligation to review suspicious transactions. Institution A can proactively push the account information and risk label of Client A's counterparty B to Institution B, allowing Institution B to reassess the risk level of Client B's account based on this information. Here, Client B's account can be referred to as a business upstream / downstream account (or business-related account) of Client A's account, and Institution B can be referred to as an upstream / downstream account-opening institution of Institution A. When Institution C discovers that Client C, who has an account with Institution C, is suspected of having high risk, assuming Institution C determines that Client C has a large number of transactions with Client B of Institution B, Institution C can query Client B's risk data from Institution B.

[0053] In the embodiments described in this specification, risk data pushed by multiple institutions to upstream and downstream account opening institutions can be aggregated based on a trusted unit. Institution C can use the trusted unit to query risk data of upstream and downstream accounts of one or more other institutions from the aggregated data, thereby improving the efficiency of risk data query while protecting user privacy.

[0054] 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, for example, institutions A, B, and C. Institutions A, B, and C can be any of the following: financial institutions, insurance companies, trading institutions, etc. It is understood that although only three institutional devices are shown in the figure as an example, in practice, there may be multiple other institutional devices. Each institutional device has a client installed, and each device can directly receive user information. The client then performs certain processing tasks based on this user information, such as reviewing suspicious transactions, thereby obtaining risk labels for each user.

[0055] As mentioned above, while each institution labels the risk level of the accounts opened by the institution, it can also label the risk level of the upstream and downstream accounts opened by the corresponding accounts in other institutions, and generate push data based on the risk data of the upstream and downstream accounts of other institutions.

[0056] 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 computing devices 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 push data to server 400, which stores the push data of each organization locally or on a file storage server. Figure 1 (Not shown in the diagram). TEE40 can receive the address where push data is stored from server 400, retrieve the push data from that address, and fuse the push data from multiple organizations to obtain aggregated data. Each organization can then query the risk data of other organizations' business-related users from the aggregated data via TEE. Server 400 and TEE40 can be connected to blockchain 500, and the risk data query scheme in the embodiments of this specification 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.

[0057] Figure 2 This is a flowchart illustrating the method for generating encrypted push 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.

[0058] like Figure 2 As shown, firstly, in step S201, the institutional device 100 reads file F1 to obtain upstream and downstream accounts and risk labels.

[0059] In institution A corresponding to institution device 100, the institution administrator can periodically generate file F1 in institution device 100 based on the data analysis results within institution A. File F1 includes risk data of upstream and downstream accounts of the institution's account. It is understood that although the data or information is presented in file form, this embodiment is not limited to this; for example, it can also be presented in text or table form, and there is no limitation on this. The risk file F1 includes multiple lines, each line including an upstream or downstream account and its risk label. In one embodiment, a line in file F1 may also include the institution identifier of the account-opening institution of the upstream or downstream account. The risk label is a label indicating the level of risk agreed upon by multiple institutions. For example, risk labels 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 label may include multiple risk labels, such as risk1 and riskH, where risk1 indicates a specific type of risk.

[0060] 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 file F1 line by line for de-identification processing.

[0061] In step S203, the device 100 requests the de-identified accounts of upstream and downstream accounts from the server 400.

[0062] Specifically, since server 400 is not entirely trustworthy, when organizational device 100 requests the de-identified account corresponding to an account in a row from server 400 during the line-by-line de-identification process, it also needs to de-identify the upstream and downstream accounts. Specifically, organizational device 100 can calculate the hash value of the upstream and downstream account Account1: hash1 = hash(Account1). Then, organizational device 100 can send this hash value hash1 to server 400 to request the de-identified account corresponding to that hash value.

[0063] In step S205, server 400 returns the de-identified account to institutional device 100.

[0064] After receiving hash1, server 400 can use preset rules to calculate the de-identified account corresponding to hash1.

[0065] 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 de-identified account, where salt is a pre-generated value by the server. By salting hash1 to obtain the de-identified account, malicious parties can be prevented from speculating on the account corresponding to hash1.

[0066] After determining the de-identified account, the server returns the de-identified account to the organization device 100. When other organizations request the de-identified account for the same account from the server 400, the server can calculate the de-identified account based on the same rules and parameters (i.e., salt), thus obtaining the same de-identified account and returning it to the organization device. In this way, different organization devices use the same de-identified account for the same user account in the push files they send to the server.

[0067] Each organization's equipment can request the de-identified account of its own account from the server in the same way, and create a mapping table between the user identifier of its own account and its de-identified account. This can be used to identify the user corresponding to the de-identified account in the future. The user identifier can be the user's identity information (such as name, identity identifier, etc.) or the account opened by the user in the organization.

[0068] In step S207, the institutional device 100 writes the de-identified account and risk label into the push file F2.

[0069] While the client in the institutional device 100 begins reading file F1, it can initialize file F2. After obtaining the de-identified account corresponding to an account in a line of file F1, it records the de-identified account and risk label in the corresponding line of file F2. In one embodiment, if file F1 includes the institutional identifier of the account's opening institution, then a line in file F2 also includes the institutional identifier of the account's opening institution. After performing the above processing on each line of file F1, the client can generate a push file F2 corresponding to file F1.

[0070] 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 de-identified account, so as to facilitate the subsequent fusion processing of push files from multiple organizations.

[0071] In step S209, the client can also use the TEE's public key to encrypt file F2, thereby generating an encrypted push file F3. This prevents the plaintext data in file F2 from being accessed externally by the TEE of server 400, 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.

[0072] In one implementation, where security requirements are low, the upstream and downstream accounts in file F1 do not need to be de-identified, so file F1 can be directly encrypted to obtain encrypted push file F3.

[0073] 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 plaintext data, rather than the complex cryptographic operations of homomorphic encryption, resulting in almost no loss of efficiency.

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

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

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

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

[0078] 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 DID document (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:

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

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

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

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

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

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

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

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

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

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

[0089] In step S403, server 400 provides TEE with encrypted push files (including file F3) and organization public keys corresponding to each organization's DID.

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

[0091] Subsequently, server 400 can send a list of DIDs for each organization, along with the file address and public key of the encrypted push file corresponding to each DID, to TEE. TEE can then read the encrypted push 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 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 TEE and the organization's device, or between the server and the organization's device, including symmetric and asymmetric keys.

[0092] In one implementation, after the server 400 verifies the signature of each organization on its encrypted push file, it sends a list of DIDs of each organization, as well as the file address and public key of the encrypted push file corresponding to each DID, to the TEE.

[0093] In one implementation, the server can provide multiple signatures from the multiple institutions and devices to the TEE. Thus, before decrypting the multiple encrypted push files, the TEE first verifies the multiple signatures using the public keys of the multiple institutions. If the verification is successful, the TEE decrypts the multiple encrypted push files.

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

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

[0096] In step S407, TEE generates summary file F4.

[0097] Specifically, after obtaining the encrypted push files from various organizations, the TEE uses its own private key to decrypt each encrypted push file, thereby obtaining the push files from each organization (including the aforementioned push file F2). Then, based on the push files from multiple organizations, the TEE can generate a summary file corresponding to each organization.

[0098] Figure 5 This is a schematic diagram illustrating the process of generating a summary file of the organization in the embodiments of this specification. Figure 5 The upper middle section illustrates the push notifications from each institution. Institution A's push notification corresponds to its institution identifier DIDa, Institution B's corresponds to its institution identifier DIDb, and Institution C's corresponds to its institution identifier DIDc. Each line in the push notification includes the anonymized accounts (or upstream and downstream accounts) of the institution's upstream and downstream accounts, risk labels, and the account opening institution's identifier. Multiple lines in the push notification can be arranged in ascending order of the anonymized accounts.

[0099] When merging multiple push files in TEE, such as Figure 5 As shown, each push file is first indicated by a pointer to the smallest de-identified account. Figure 5 Among the de-identified accounts pointed to by the pointers in the three push files, the de-identified account Acc1 is the smallest account, and the account opening institution corresponding to the de-identified account Acc1 is institution B. Therefore, in Figure 5 In the first line of the organization summary file (the middle file) of organization b shown below, write "Acc1 {risk1}", where {risk1} is the current risk label set of Acc1.

[0100] After recording the information corresponding to Acc1 in Institution B's institutional push file, the pointer is moved to the next line in Institution A's push file, i.e., the line corresponding to Acc3, and the above process is repeated. Specifically, after determining that the smallest ID pointed to by the three pointers is Acc2 in the TEE, the information corresponding to Acc2, "Acc2 {risk2, riskL}", is recorded in the first line of the institutional push file F4 of Institution A, the account opening institution corresponding to the de-identified account Acc2. Through the same process described above, after traversing all lines in each push file using pointers, the following can be obtained: Figure 5 The lower section shows the organizational summary files for each organization, including summary file F4 corresponding to organization A.

[0101] Figure 6 This is a schematic diagram illustrating the process of generating a summary file F4 in another implementation, where the summary file aggregates data from multiple push files into a single file. Specifically, each push file's line includes the anonymized accounts (or upstream and downstream accounts) and risk labels for each organization's upstream and downstream accounts. A line in the summary file includes the anonymized accounts and a set of risk labels, where the risk label set is derived from multiple push files. Furthermore, the multiple lines in the summary file can be arranged in ascending order of the anonymized accounts.

[0102] In step S409, the TEE uses its public key to encrypt the summary file F4, resulting in the encrypted summary file F5.

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

[0104] In step S411, the TEE provides the encrypted summary file F5 to the server 400.

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

[0106] In step S413, the server stores the encrypted summary file F5.

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

[0108] Figure 7 This is a flowchart illustrating the method for generating encrypted query files on the device 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.

[0109] like Figure 7 As shown, firstly, in step S701, the mechanism device 100 reads file F6 to obtain upstream and downstream accounts.

[0110] In institution A corresponding to institution equipment 100, the institution administrator can periodically generate file F6 in institution equipment 100 based on the data analysis results within institution A. File F6 includes multiple lines, each line including an upstream and downstream account of this institution's account. In one embodiment, each line of file F6 may also include the institution identifier of the opening institution of the upstream and downstream accounts in that line.

[0111] 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 for de-identification processing.

[0112] In step S703, the device 100 requests the de-identified accounts of upstream and downstream accounts from the server 400.

[0113] Specifically, since server 400 is not entirely trustworthy, when organizational device 100 requests the de-identified account corresponding to an account in a row from server 400 during the line-by-line de-identification process, it also needs to de-identify the upstream and downstream accounts. Specifically, organizational device 100 can calculate the hash value of the upstream and downstream account Account1: hash1 = hash(Account1). Then, organizational device 100 can send this hash value hash1 to server 400 to request the de-identified account corresponding to that hash value.

[0114] In step S705, server 400 returns the de-identified account to institutional device 100.

[0115] After receiving hash1, server 400 can use preset rules to calculate the de-identified account corresponding to hash1.

[0116] 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 de-identified account, where salt is a pre-generated value by the server. By salting hash1 to obtain the de-identified account, malicious parties can be prevented from speculating on the account corresponding to hash1.

[0117] After identifying the de-identified account, the server returns the de-identified account to the organization's device 100.

[0118] In step S707, the device 100 writes the de-identified account into the query file F7.

[0119] While the client in the institutional device 100 begins reading file F6, it can initialize file F7. After obtaining the de-identified account corresponding to the account in a line of file F6 by reading line by line, the de-identified account is recorded in the corresponding line of file F7. In one embodiment, if file F6 also includes the institution's identifier, the corresponding institution's identifier for the de-identified account in the line of file F7 is also included. After performing the above processing on each line of file F6, the client can generate a push file F7 corresponding to file F6.

[0120] The device 100 can also store a mapping table between upstream and downstream accounts and de-identified accounts in file F6, which can be used to replace de-identified accounts with upstream and downstream accounts according to the mapping table.

[0121] In one implementation, after generating file F7 as described above, the client can sort the rows in file F7 in ascending order of each de-identified account, so as to facilitate subsequent querying from the summary file in ascending order of the de-identified accounts, thereby improving query efficiency.

[0122] In step S709, the client can also use the TEE's public key to encrypt file F7, thereby generating an encrypted query file F8. This prevents the plaintext data in file F7 from being accessed externally by the TEE of server 400, 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 the institution's equipment can negotiate other asymmetric or symmetric keys for encrypting file F7.

[0123] In one implementation, where security requirements are low, the upstream and downstream accounts in file F6 can be left unidentified, allowing file F6 to be directly encrypted to obtain encrypted query file F8.

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

[0125] like Figure 8 As shown, in step S801, the mechanism device 100 sends the encrypted query file F8 to the server 400.

[0126] Specifically, institution device 100 can sign file F8 using the private key of institution A's DID, and send institution A's DID (e.g., DIDa), file F8, and the signature of file F8 using the private key of DIDa to server 400. Server 400 can then verify the signature to verify the institution identity corresponding to institution device 100.

[0127] In step S803, server 400 provides TEE with the aforementioned encrypted summary file, encrypted query file F8, and institutional public key to request a query of risk information for upstream and downstream accounts.

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

[0129] In one implementation, server 400 may send data to TEE based on... Figure 6 The process shown yields the storage addresses of files F5 and F8, as well as the public key of organization A. Therefore, the TEE can read files F5 and F8 from their respective addresses. The TEE can then use its own private key to decrypt files F5 and F8 separately, obtaining... Figure 6The summary file F4 and query file F7 shown are illustrated. Query file F7 includes the de-identified accounts to be queried. Organization A's public key is subsequently used to encrypt files sent to Organization A. It can be understood that the TEE is not limited to using the organization's public key to encrypt files sent to the organization, but 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.

[0130] In another implementation, server 400 may send data to TEE based on... Figure 5 The process shown obtains the storage addresses of multiple encrypted summary files and file F8 corresponding to multiple institutions, as well as the public key of institution A. The TEE can then obtain these multiple encrypted summary files and file F8, and decrypt them to obtain the following... Figure 5 The multiple summary files and query file F7 shown are included in the query file F7, which contains the de-identified account to be queried and the institutional identifier of the corresponding account opening institution.

[0131] In step S805, the TEE uploads the request parameters to the blockchain.

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

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

[0134] In step S807, TEE generates query result file F9.

[0135] Specifically, in one implementation, the TEE obtains such Figure 6After creating the summary file F4 and query file F7, the TEE can read the anonymized accounts line by line from query file F7 in the order they appear. A query result file F9 is created simultaneously with the reading of file F7. For example, after the TEE reads a specific anonymized account (e.g., Acc2) from file F7, it checks if summary file F4 includes Acc2. If summary file F4 includes Acc2, the TEE reads the risk label set corresponding to Acc2 from summary file F4 and records Acc2 and its corresponding risk label set in a single line of query result file F9. After performing this process on each anonymized account in file F7, file F9 is generated.

[0136] In another implementation, the TEE obtains as follows: Figure 5 The document shows multiple summary files (including summary file F4 for institution A) and a query file F7. Each line in query file F7 includes the de-identified account to be queried and the corresponding institution's identifier. After the TEE reads a de-identified account (e.g., Acc2) and its institution's identifier (e.g., institution A) from file F7, it determines summary file F4 for institution A based on institution A's identifier and checks if summary file F4 includes Acc2. If summary file F4 includes Acc2, the TEE reads the risk label set corresponding to Acc2 from summary file F4 and records Acc2 and its corresponding risk label set in a line in the query result file F9. After performing the above processing on each de-identified account in file F7, file F9 can be generated.

[0137] In step S809, the TEE encrypts file F9 to obtain encrypted file F10.

[0138] Specifically, TEE uses the public key of organization A to encrypt file F9, resulting in encrypted file F10.

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

[0140] In step S811, the TEE provides the encrypted result file F10 to the server 400.

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

[0142] In step S813, server 400 sends file F10 to mechanism device 100.

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

[0144] In step S815, the mechanism device 100 decrypts file F10 to obtain file F9.

[0145] Specifically, the device 100 can use its private key to decrypt file F10 and obtain file F9.

[0146] In step S817, the mechanism equipment 100 replaces the de-identified account in file F9 with the upstream and downstream accounts to obtain file F11.

[0147] Specifically, the institutional device 100 can read the upstream and downstream accounts corresponding to each de-identified account in file F9 from the aforementioned stored mapping table of upstream and downstream accounts and de-identified accounts, and replace the de-identified accounts in file F9 with the upstream and downstream accounts, thereby generating file F11. The institutional device 100 can then comprehensively judge the risk level of the accounts associated with each upstream and downstream account based on the risk label set of each upstream and downstream account in file F11, thus improving the accuracy of the judgment.

[0148] In the embodiments of this specification, by combining a server and a TEE to perform a risk data query method, the institutional device performs desensitization, encryption and other processing on the user identifier of the user to be queried and sends it to the server. The server provides the encrypted query file and the encrypted summary file to the TEE, and the TEE decrypts the encrypted query file and the encrypted summary file, thereby performing risk data query on the institution's upstream and downstream accounts. This improves the efficiency of the institution in querying risk data on upstream and downstream accounts while protecting user privacy.

[0149] Figure 9 This is an architectural diagram of a trusted unit in an embodiment of this specification, including:

[0150] The acquisition unit 91 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 account information of the second account of the second institution to be queried. The first encrypted data is obtained by encrypting the first data. The first data includes at least the account information of n accounts in the second institution and a risk label set.

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

[0152] The writing unit 93 is used to write a set of first risk tags corresponding to the account information of the second account in the first data into the second data when it is determined that the first data includes the account information of the second account.

[0153] Encryption unit 94 is used to encrypt the second data to obtain second ciphertext data;

[0154] The providing unit 95 is used to provide the second encrypted data to the server.

[0155] Figure 10 This is an architecture diagram of a server as described in one embodiment of this specification, including:

[0156] The receiving unit 101 is used to receive encrypted query data from the first institution device. The encrypted query data is obtained by encrypting query data. The query data includes account information of the second account of the second institution to be queried. The first institution device belongs to the first institution, and the second account is the business-related account of the first account in the first institution.

[0157] The providing unit 102 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 at least account information and a risk label set of n accounts in the second institution.

[0158] The receiving unit 101 is further configured to: receive second encrypted data from the trusted unit, the second encrypted data being obtained by encrypting second data, the second data including a first risk tag set corresponding to the account information of the second account, the first risk tag set being obtained from the first data based on the account information of the second account;

[0159] The providing unit 102 is further configured to: provide the second encrypted data to the first mechanism device.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0177] 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 devices send encrypted push data to the server; The trusted unit obtains multiple encrypted push data from the server, decrypts the multiple encrypted push data respectively, and obtains multiple push data. The push data includes account information and risk tags of accounts in other institutions that are business-related to one or more accounts in the institution that sent the push data. First data is generated based on the multiple push data; The first data is encrypted to obtain the first ciphertext data; The first encrypted data is provided to the server; The first institution device sends encrypted query data to the server. The encrypted query data is obtained by encrypting the query data. The query data includes the account information of the second account of the second institution to be queried. The first institution device belongs to the first institution, and the second account is the business-related account of the first account in 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 data includes at least account information and a set of risk tags for n accounts in the second institution. 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 the account information of the second account, it writes the first risk tag set corresponding to the account information of the second account 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 institution device decrypts the second encrypted data to obtain the first risk tag set corresponding to the second account.

2. The method according to claim 1, wherein the push data further includes the organization identifier of the other organization that created the account in the other organization, and the trusted unit generates the first data based on the plurality of push data including: Based on the multiple push data, multiple summary data corresponding to multiple institutions are generated, and the multiple summary data include the first data; The trusted unit provides the first ciphertext data to the server by providing multiple ciphertext summary data obtained by encrypting the multiple summary data to the server.

3. The method according to claim 1, wherein the account information of the second account includes: The digest value obtained by hashing the second account.

4. The method according to claim 2, further comprising: The first device calculates a first hash value for the second account and sends the first hash value to the server; The server calculates the first hash value and a second hash value with a preset value as the account information of the second account, and returns the account information of the second account to the first institution device.

5. The method according to claim 1, wherein the encrypted query data and the first encrypted data are obtained by encrypting them using the public key of the trusted unit, and the trusted unit decrypts the encrypted query data and the first encrypted data by: The trusted unit uses its private key to decrypt the ciphertext query data and the first ciphertext data.

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 2, wherein the query data further includes the organization identifier of the second organization corresponding to the second account, and the server provides the pre-acquired first encrypted data to the trusted unit including: The server provides the pre-acquired aggregated data of the multiple ciphertexts to the trusted unit; The trusted unit's decryption of the encrypted query data and the first encrypted data includes: the trusted unit decrypting the plurality of encrypted summary data to obtain the plurality of summary data, and selecting the first data from the plurality of summary data according to the organization identifier of the second organization included in the query data.

10. A risk data query method, executed by a trusted unit, comprising: The trusted unit obtains multiple encrypted push data from the server. The encrypted push data is sent to the server by multiple institutional devices. The multiple encrypted push data are decrypted to obtain multiple push data. The push data includes account information and risk tags of accounts in other institutions that are business-related to one or more accounts in the institution that sent the push data. First data is generated based on the multiple push data; The first data is encrypted to obtain the first ciphertext data; The first encrypted data is provided to the server; 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 account information of the second account of the second institution to be queried. The first data includes at least the account information and risk label set of n accounts in the second institution. 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 the account information of the second account, a first risk tag set corresponding to the account information of the second account 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 push data from multiple institutions and devices; Multiple encrypted push data are sent to a trusted unit, so that the trusted unit can decrypt the multiple encrypted push data respectively to obtain multiple push data. The push data includes account information and risk tags of accounts in other institutions that are business-related to one or more accounts in the institution that sent the push data. First data is generated based on the multiple push data, and the first data is encrypted to obtain first encrypted data. Receive the first ciphertext data from the trusted unit; The device receives encrypted query data from the first institution. The encrypted query data is obtained by encrypting the query data. The query data includes account information of the second account of the second institution to be queried. The first institution belongs to the first institution, and the second account is the business-related account of the first account in the first institution. The encrypted query data and the pre-acquired first encrypted data are provided to the trusted unit, wherein the first data includes at least account information and a set of risk tags for n accounts in the second institution; 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 a first risk tag set corresponding to the account information of the second account. The first risk tag set is obtained from the first data based on the account information of the second account. The second encrypted data is provided to the first mechanism device.

12. A risk data query system, comprising multiple institutional devices, servers, and trusted units. The multiple mechanisms and devices send encrypted push data to the server; The trusted unit is used to obtain multiple encrypted push data from the server, decrypt the multiple encrypted push data respectively to obtain multiple push data, the push data includes account information and risk tags of accounts in other institutions that are business-related to one or more accounts in the institution that sent the push data, generate first data based on the multiple push data, encrypt the first data to obtain first encrypted data, and provide the first encrypted data to the server. The first institutional 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 account information of the second account of the second institution to be queried. The first institutional device belongs to the first institution, and the second account is the business-related account of the first account in the first institution. The server is used to provide the encrypted query data and the pre-acquired first encrypted data to the trusted unit. The first data includes at least the account information and risk label set of n accounts in the second institution. 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 the account information of the second account, the first risk tag set corresponding to the account information of the second account 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; 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 second account.

13. A trusted unit, comprising: The acquisition unit is used to acquire multiple encrypted push data from the server. The encrypted push data is sent to the server by multiple institutional devices. The unit acquires 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 account information of the second account of the second institution to be queried. The first data includes at least the account information and risk label set of n accounts in the second institution. The decryption unit is used to decrypt the multiple encrypted push data respectively to obtain multiple push data. The push data includes account information and risk tags of accounts in other institutions that are business-related to one or more accounts in the institution that sent the push data. The unit also decrypts the encrypted query data and the first encrypted data to obtain the query data and the first data. The writing unit is used to write a first risk tag set corresponding to the account information of the second account in the first data into the second data when it is determined that the first data includes the account information of the second account. An encryption unit is used to generate the first data based on the plurality of push data, encrypt the first data to obtain the first ciphertext data, and encrypt the second data to obtain the second ciphertext data; A providing unit is configured to provide the first ciphertext data to the server and the second ciphertext data to the server.

14. A server, comprising: The receiving unit is used to receive encrypted push data from multiple institutional devices and to receive encrypted query data from a first institutional device. The encrypted query data is obtained by encrypting the query data. The query data includes account information of a second account of a second institution to be queried. The first institutional device belongs to the first institution, and the second account is a business-related account of the first account in the first institution. A providing unit is configured to provide multiple encrypted push data to a trusted unit, so that the trusted unit can decrypt the multiple encrypted push data respectively to obtain multiple push data. The push data includes account information and risk tags of accounts in other institutions that are business-related to one or more accounts in the institution that sent the push data. Based on the multiple push data, first data is generated, and the first data is encrypted to obtain first encrypted data. The encrypted query data and the first encrypted data are provided to the trusted unit, wherein the first data includes at least account information and a set of risk tags for n accounts in the second institution; The receiving unit is further configured to: receive the first encrypted data from the trusted unit, receive the second encrypted data from the trusted unit, the second encrypted data being obtained by encrypting the second data, the second data including a first risk tag set corresponding to the account information of the second account, the first risk tag set being obtained from the first data based on the account information of the second account; The providing unit is further configured 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