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

Abstract

A risk data push method, system, server and trusted unit, the method comprising: a first institution device of a first institution generates push data, the push data comprising account information and risk tags of a second account in a second institution that is business-associated with one or more first accounts in the first institution; first ciphertext push data is generated based on the push data; the first ciphertext push data is sent to an intermediate device; a second institution device of a second institution obtains second ciphertext push data of the push data via the intermediate device, decrypts the second ciphertext push data, and obtains the push data.

Description

Technical Field

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

[0002] At present, regulatory authorities usually require institutions involved in major transactions to fulfill their anti-money laundering obligations, that is, to analyze and report transaction data of large and suspicious transactions. However, the information between institutions is isolated from each other, forming information islands, and it is difficult for institutions to identify suspicious users without sufficient information. How multiple institutions can push risk information to the account opening institutions of upstream and downstream accounts of the transaction while protecting the privacy data of users is a problem that needs to be solved in the current anti-money laundering solution. Summary of the invention

[0003] The purpose of the present invention is to provide a risk data push solution, which pushes risk data of upstream and downstream accounts of an organization through an intermediate device, thereby improving the efficiency of pushing risk data of upstream and downstream accounts between institutions while protecting privacy data.

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

[0005] A first institution device of a first institution generates push data, the push data including account information and risk tags of a second account in a second institution that is business-related to one or more first accounts in the first institution, the risk tags of the second account being determined based on the risk tags of the one or more first accounts, and generating first encrypted push data based on the push data; and sending the first encrypted push data to an intermediate device;

[0006] The second mechanism device of the second mechanism obtains second ciphertext push data of the push data via the intermediate device, the second ciphertext push data corresponds to the first ciphertext push data, and decrypts the second ciphertext push data to obtain the push data.

[0007] A second aspect of the present specification provides a risk data push method, which is executed by a trusted unit and includes:

[0008] Acquire first encrypted push data, where the first encrypted push data is generated by encrypting combined data of push data and an identifier of a second institution, where the push data includes account information and a risk tag of a second account in a second institution that is business-associated with one or more first accounts in the first institution, where the risk tag of the second account is determined based on the risk tags of the one or more first accounts;

[0009] Decrypting the first ciphertext push data to obtain the push data and an identifier of the second institution;

[0010] Encrypt the push data using the pre-acquired public key of the second institution to obtain the second ciphertext push data;

[0011] The second ciphertext push data is output for sending to the second mechanism device.

[0012] A third aspect of the present specification provides a risk data push method, which is executed by a server and includes:

[0013] receiving first encrypted push data from a first institution device of a first institution, the first encrypted push data being generated by encrypting combined data of the push data and an identifier of a second institution, the push data comprising account information and a risk tag of a second account in a second institution that is business-associated with one or more first accounts in the first institution, the risk tag of the second account being determined based on the risk tags of the one or more first accounts;

[0014] Providing the first ciphertext push data and pre-acquired public keys of multiple institutions to a trusted unit, wherein the multiple institutions include the second institution and one or more third institutions;

[0015] receiving, from the trusted unit, second ciphertext push data and an identifier of a second institution corresponding thereto, and one or more third ciphertext push data and an identifier of a third institution corresponding thereto, wherein the second ciphertext push data is generated by encrypting the push data using a public key of the second institution, and the one or more third ciphertext push data is generated by encrypting one or more data indicating invalid data respectively using public keys of respective third institutions;

[0016] The second ciphertext push data is sent to the second institution, and each third ciphertext push data is sent to each third institution.

[0017] A fourth aspect of the present specification provides a risk data push system, including a first institution device of a first institution, a second institution device of a second institution, and an intermediate device,

[0018] The first institution device is used to generate push data, the push data including account information and risk tags of a second account in a second institution that is business-related to one or more first accounts in the first institution, the risk tag of the second account being determined based on the risk tags of the one or more first accounts, and generating first ciphertext push data based on the push data; and sending the first ciphertext push data to the intermediate device;

[0019] The second mechanism device is used to obtain second ciphertext push data of the push data via the intermediate device, the second ciphertext push data corresponds to the first ciphertext push data, and decrypt the second ciphertext push data to obtain the push data.

[0020] A fifth aspect of the present specification provides a trusted unit, including:

[0021] an acquiring unit, configured to acquire first ciphertext push data, the first ciphertext push data being generated by encrypting combined data of push data and an identifier of a second institution, the push data comprising account information and a risk label of a second account in a second institution that is business-associated with one or more first accounts in the first institution, the risk label of the second account being determined based on the risk labels of the one or more first accounts;

[0022] a decryption unit, configured to decrypt the first ciphertext push data to obtain the push data and an identifier of the second institution;

[0023] an encryption unit, configured to encrypt the push data using the pre-acquired public key of the second institution to obtain the second ciphertext push data;

[0024] An output unit is used to output the second ciphertext push data for sending to the second mechanism device.

[0025] A sixth aspect of the present specification provides a server, including:

[0026] a receiving unit, configured to receive first encrypted push data from a first institution device of a first institution, wherein the first encrypted push data is generated by encrypting combined data of the push data and an identifier of a second institution, wherein the push data includes account information and a risk tag of a second account in a second institution that is business-associated with one or more first accounts in the first institution, wherein the risk tag of the second account is determined based on the risk tags of the one or more first accounts;

[0027] a providing unit, configured to provide the first ciphertext push data and pre-acquired public keys of multiple institutions to a trusted unit, wherein the multiple institutions include the second institution and one or more third institutions;

[0028] The receiving unit is further used to: receive, from the trusted unit, second ciphertext push data and an identifier of a second institution corresponding thereto, and one or more third ciphertext push data and an identifier of a third institution corresponding thereto, wherein the second ciphertext push data is generated by encrypting the push data using a public key of the second institution, and the one or more third ciphertext push data is generated by encrypting one or more data indicating invalid data using public keys of respective third institutions;

[0029] The sending unit is used to send the second ciphertext push data to the second institution, and send each third ciphertext push data to each third institution.

[0030] A seventh aspect of the present specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method described in the second aspect or the third aspect.

[0031] An eighth aspect of the present specification provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the second aspect or the third aspect is implemented.

[0032] In the embodiments of the present specification, the institutional equipment can send the encrypted push data sent to multiple other institutions to the intermediate device to provide it to other institutional equipment. The institutional equipment can also obtain the encrypted push data sent to it by other institutions from the intermediate device, thereby improving the efficiency of the institutional equipment in sending encrypted push data to upstream and downstream institutions, and ensuring data security while protecting privacy data. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use 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 ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0034] Figure 1 A schematic diagram of a system in an embodiment of this specification;

[0035] Figure 2 This is a flow chart of a method for desensitizing an account on the device side of an institution in an embodiment of this specification;

[0036] Figure 3 This is a flow chart of a method for verifying the identity of an institution by a server in an embodiment of this specification;

[0037] Figure 4 This is a flow chart of a risk data push method in an embodiment of this specification;

[0038] Figure 5 This is a flow chart of a risk data push method according to another embodiment of this specification;

[0039] Figure 6 This is a flow chart of a risk data push method according to another embodiment of this specification;

[0040] Figure 7This is a flow chart of a risk data push method according to another embodiment of this specification;

[0041] Figure 8 is an architecture diagram of a trusted unit in an embodiment of this specification;

[0042] Fig. 9 This is an architecture diagram of a server in an embodiment of this specification. DETAILED DESCRIPTION

[0043] In order 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 in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0044] Data sharing is often a requirement for institutions to handle business. A single institution often cannot obtain enough information to handle business, which creates a need to obtain information from other institutions. For example, in the requirements for anti-money laundering compliance performance in many countries, many financial institutions are required to provide anti-money laundering audit results. At present, many central banks and many large financial institutions have tried to use blockchain in the field of anti-money laundering to improve efficiency and accuracy and meet regulatory requirements. At the same time, as a resource, the liquidity and accessibility of data are the basis for many data applications and industrial development, but privacy protection in the process of data exchange and sharing has always been a major challenge for industrial development. The following is still an example of anti-money laundering.

[0045] Anti-Money Laundering (AML) refers to measures to prevent money laundering activities that conceal the source and nature of criminal proceeds and proceeds from drug crimes, organized crimes of a mafia nature, terrorist crimes, smuggling crimes, corruption and bribery crimes, and crimes that undermine the financial management order. Common money laundering channels widely involve various fields such as banking, insurance, securities, and real estate. Most anti-money laundering work includes three core matters:

[0046] 1. Customer identification system. When establishing a business relationship or conducting transactions with a customer, the anti-money laundering obligated entity shall verify and record the identity of its customer based on authentic and valid identity documents, and update the customer's identity information in a timely manner during the business relationship.

[0047] 2. Suspicious Transaction Report (STR) system. Illegal capital flows are generally characterized by huge amounts and abnormal transactions. Therefore, the law stipulates a large and suspicious transaction reporting system, requiring financial institutions to report transactions that reach a certain amount and abnormal transactions that lack legitimate purposes to the anti-money laundering administrative department in a timely manner, as a clue to track down illegal and criminal activities.

[0048] 3. Customer identity information and transaction record preservation system Customer identity information and transaction record preservation refers to the financial institutions taking necessary measures in accordance with the law to preserve customer identity information and transaction information for a certain period of time, which can provide evidence support for the investigation of illegal and criminal activities.

[0049] The customer identity identification system, commonly known as "Know Your Customer" (KYC), refers to obtaining customer-related 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, etc. It is the basis of anti-money laundering.

[0050] Different financial institutions have the obligation to review suspicious transactions. For example, when institution A discovers in monitoring and analysis that customer "A" suspected of money laundering risk has frequent / large transactions with "B" who has opened an account in institution B, it can be determined that B and A have a close relationship and there is a money laundering risk. Institution A can actively push the account information and risk label of "B", the counterparty of customer "A", to institution B, so that institution B can re-determine the risk level of customer "B"'s account based on the pushed information. Among them, the account of "B" can be referred to as the upstream and downstream accounts (or business-related accounts) of the account of "A", and institution B can be referred to as the upstream and downstream account opening institutions of institution A. In the embodiments of this specification, the risk data push of institutions to upstream and downstream account opening institutions is based on the server or blockchain, which improves the efficiency of risk data push and data security.

[0051] Figure 1 Schematic diagram of the system in the embodiment of this specification. Figure 1 As shown, the institutional device 100, the institutional device 200 and the institutional device 300 can be computing devices of, for example, institution A, institution B and institution C, respectively. The institution A, institution B and institution C can be, for example, any of financial institutions, insurance institutions, trading institutions and the like. It can be understood that the figure shows three institutional devices as an example, and in practice, other numbers of institutional devices may be included. The institutional device is installed with a client of the anti-money laundering platform, and each institutional device can directly receive user information, so that the client completes certain processing work based on the user information, such as the above-mentioned review of suspicious transactions, so as to obtain the risk label of each user.

[0052] Taking the risk label as money laundering risk level as an example, institution A and institution B can respectively label the money laundering risk level of the user accounts opened in their institutions based on their own anti-money laundering audit capabilities. As mentioned above, while each institution labels the risk level of the account opened in its own institution, it can also label the risk level of the corresponding upstream and downstream accounts opened in other institutions, and generate push data based on the risk data of the upstream and downstream accounts of other institutions.

[0053] The server 400 includes a trusted unit, which may be any computing unit that can process private data or confidential data and protect data from leakage. The trusted unit may include, for example, a trusted execution environment (TEE), a computing device in a trusted organization, and the like. Figure 1 In one embodiment, each institution device can send the desensitized and encrypted ciphertext push data to the server 400, and the server 400 stores the ciphertext push data of each institution locally or in a file storage server ( Figure 1 TEE40 can receive the address of the encrypted push data storage from the server 400, obtain the encrypted push data from the address, and send the encrypted push data to the upstream and downstream institutions of the institutions corresponding to the encrypted push data according to each encrypted push data, thereby pushing the user's risk data between various institutions while protecting the user's privacy. Among them, the server 400 and TEE40 can be connected to the blockchain 500, so as to combine the blockchain 500 to carry out the risk data sharing solution in the embodiment of this specification. It can be understood that Figure 1 Although the trusted unit is shown to be located inside the server 400, the embodiments of this specification are not limited to this. The TEE can also be located in another computing device, and the server 400 can be connected to the TEE by connecting to the computing device.

[0054] In another embodiment, each institution's equipment can send encrypted push data to its upstream and downstream institutions through the server 400 or the blockchain 500.

[0055] Figure 2 This is a flow chart of the method for desensitizing accounts on the institutional device side in the embodiments of this specification. Figure 2 The mechanism equipment in can be Figure 1 Any one of the multiple mechanism devices in the embodiment. The following description will be made by taking the mechanism device 100 as an example.

[0056] like Figure 2 As shown, first, in step S201, the institution device 100 obtains the upstream and downstream accounts of other institutions.

[0057] In the institution A corresponding to the institutional device 100, the institutional administrator can regularly generate risk data of the upstream and downstream accounts of other institutions of the risk account of the institution based on the data analysis results within the institution A. The risk data may include multiple rows, each row including an upstream and downstream account, the risk label of the upstream and downstream account, and the institutional identification of the account opening institution of the upstream and downstream account. The risk label is a label indicating the degree of risk agreed upon by multiple institutions. For example, the risk label may include risk labels such as riskH, riskM, and riskL, where riskH indicates high risk, riskM indicates medium risk, and riskL indicates low risk. The risk label of a single user may include multiple risk labels, such as risk1 and riskH, where risk1 indicates a specific type of risk, etc.

[0058] After the institution administrator generates risk data in the institution device 100, the risk data is uploaded to the storage of the client. After monitoring the risk data update, the client can read the risk data line by line, for example, to obtain the upstream and downstream accounts in the line line by line for desensitization processing.

[0059] In step S203 , the institution device 100 requests the server 400 for desensitized accounts of upstream and downstream accounts.

[0060] Specifically, since the server 400 is not completely trustworthy, the institution device 100 also needs to desensitize the upstream and downstream accounts when requesting the desensitized account corresponding to the account in a row from the server 400 during the desensitization process. Specifically, the institution device can calculate the hash value hash1=hash(Account1) of the upstream and downstream account Account1, and then the institution device 100 can send the hash value hash1 to the server 400 to request the desensitized account corresponding to the hash value.

[0061] In step S205 , the server 400 returns the desensitized account to the institution device 100 .

[0062] After receiving hash1, the server 400 may use a preset rule to calculate the desensitized account corresponding to hash1.

[0063] In one embodiment, in order to further strengthen data security protection, the server 400 can perform a salting operation on hash1, for example, by calculating hash(hash1+salt), and using the obtained hash value as the desensitized account, where salt is a value pre-generated by the server. By performing a salting operation on hash1 to obtain the user ID, malicious parties can be prevented from speculating on the account corresponding to hash1.

[0064] After determining the desensitized account, the server returns the desensitized account to the institution device 100. When other institutions request the desensitized account of the account from the server 400, the server can calculate the desensitized account based on the same rules and parameters (i.e., salt), thereby obtaining the same desensitized account, and returns the desensitized account to the institution device, so that different institution devices use the same desensitized account for the same account in the push data they send to other institutions.

[0065] Each institution's equipment can request the server for the desensitized account of the account opened by the institution in the same way, and create a mapping table between the user identifier of the account opened by the institution and its desensitized account, which can be used to determine the user corresponding to the desensitized account in the future, wherein the user identifier can be the user's identity information (such as name, identity identifier, etc.), or it can also be an account opened by the user in the institution.

[0066] In one implementation, when security requirements are low, the upstream and downstream accounts of other organizations may not be desensitized, that is, the accounts of other organizations are directly included in the push data sent to other organizations.

[0067] In the embodiments of this specification, a digital identity can be created for each organization by combining DIS with blockchain. Blockchain can provide a decentralized (or weakly centralized), tamper-proof (or difficult to tamper with), and trusted distributed ledger, and can provide a safe, stable, transparent, auditable and efficient way to record transactions and data information interaction. A blockchain network can include multiple nodes. Generally speaking, one or more nodes of a blockchain belong to a participant. Generally speaking, the more participants a blockchain network has, the more authoritative the participant is, and the higher the credibility of the blockchain network. A blockchain network consisting of multiple participants is referred to here as a blockchain platform. With the help of a blockchain platform, institutions can be helped to verify their identities.

[0068] In order to use the distributed digital identity service provided by the blockchain platform, an organization can register its own identity in the blockchain platform. For example, organization A can create a pair of public and private keys, store the private key confidentially, and create a distributed digital identity (also known as decentralized identifier, Decentralized Identitfiers, DID). DID can be created by organization A itself, or a distributed identity service (DIS) system can be requested to create DID. DIS is a blockchain-based identity management solution that can provide functions such as creation, verification and management of digital identities, thereby achieving standardized management and protection of entity data, while ensuring the authenticity and efficiency of information flow, and can solve problems such as cross-institutional identity authentication and data cooperation. The DIS system can be connected to the blockchain platform. Through the DIS system, a DID can be created for organization A, and the DID and the public key can be sent to the blockchain platform for storage, and the created DID can be returned to organization A. The public key can be included in a DID document (DIDdoc), which can be stored in the blockchain platform. DIS creates a DID for organization A. It can be created based on the public key sent by organization A, for example, by calculating the public key of organization A using a hash function, or it can be created based on other information of organization A (which may include or exclude the public key). The latter may require organization A to provide some information other than the public key. Afterwards, organization A can provide a verification function to prove to other parties that it is organization A. Figure 3 This is a flow chart of a method for server verification of institution identity in an embodiment of this specification, including:

[0069] S301: The institution device 100 of institution A initiates a DID creation request to the DIS, wherein the request includes the public key of institution A.

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

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

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

[0073] S309: The server generates a character string and sends the character string to the institution device 100 of the institution A.

[0074] S311: The institution device 100 signs the string with the private key of institution A and returns it to the server.

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

[0076] After the server 400 passes the identity verification of the institution, it can execute Figure 4 The risk data push method shown.

[0077] like Figure 4 As shown, first, in step S401, the mechanism device 100 generates ciphertext push data.

[0078] After desensitizing one or more upstream and downstream accounts in, for example, institution B, the institution device 100 may generate push data D0 corresponding to institution B, which includes one or more upstream and downstream accounts in institution B or their desensitized accounts, and risk labels of each account. In one embodiment, the push data may also include the identifier of institution A, and accounts associated with the upstream and downstream accounts in institution A (or their desensitized accounts) to indicate the source of the risk label.

[0079] The institution device 100 may obtain the public key of the DID of the institution B from the blockchain in advance, so that the institution device 100 may use the public key of the institution B to encrypt the push data D0 and generate the ciphertext push data D1. It is understood that the institution device 100 is not limited to using the public key of the institution B to encrypt the push data, but may use any key negotiated with the institution device 200, including symmetric keys and asymmetric keys.

[0080] In step S403 , the organization device 100 sends the encrypted push data and the identification of organization B to the server 400 .

[0081] Specifically, the organization device 100 can use the private key of organization A (for example, the private key of organization A's DID) to sign the combined data (for example, spliced ​​data) of the ciphertext push data and the identification of organization B to obtain a digital signature, and send the DID of organization A (for example, DIDa), the ciphertext push data, the identification of organization B and the above-mentioned digital signature to the server 400.

[0082] In step S405 , the server 400 sends encrypted push data to the mechanism device 200 .

[0083] In one embodiment, after receiving the above data from the institution device 100, the server 400 obtains the public key of DIDa according to "DIDa", which is generated by the server 400 in the following manner: Figure 3 The digital signature is obtained from the blockchain and stored locally during the verification process of the institution device 100. Afterwards, the server 400 verifies the digital signature using the public key of DIDa. If the verification is successful, the server 400 obtains the connection address of the institution device 200 stored in advance, and sends the encrypted push data to the institution device 200 through the connection address.

[0084] In one embodiment, the server may provide the public key of the DID of organization A, the ciphertext push data, the identifier of organization B, and the above-mentioned digital signature to the organization device 200, so that the organization device 200 first uses the public key of organization A to verify the signature before decrypting the ciphertext push data, and decrypts the ciphertext push data if the verification is successful.

[0085] In step S407, the mechanism device 200 decrypts the encrypted push data to obtain the push data.

[0086] After receiving the ciphertext push data, the institution device 200 uses the negotiated key (for example, the private key of DIDb of institution B) to decrypt the ciphertext push data to obtain the push data. Specifically, the push data may include desensitized accounts and corresponding risk labels of one or more accounts in institution B. The institution device 200 can obtain the user identifier corresponding to each desensitized account based on the pre-generated mapping table between the user identifier corresponding to the account in the institution and its desensitized account, thereby replacing the desensitized account in the push data with the corresponding user identifier. After performing this processing, the institution device 200 can redetermine the risk level of the user corresponding to the desensitized account based on the push data, thereby improving the accuracy of risk control.

[0087] In this embodiment, the organization device 100 can send all the push data sent to other multiple organizations to the server, and the server will forward them to each other organization respectively, which improves the efficiency of the organization device 100 in sending encrypted push data to upstream and downstream organizations. At the same time, by transferring between organizations through the server, the sending organization (i.e., organization A) of the push data can be hidden from organization B, thereby further protecting user privacy.

[0088] Figure 5 This is a flow chart of a risk data push method according to another embodiment of this specification.

[0089] like Figure 5As shown, first in step S501, the organization device 100 generates ciphertext push data D2. The organization device 100 can generate push data D0 similarly to step S401, and then the organization device 100 encrypts the push data D0 using the public key of the TEE to generate ciphertext push data D2.

[0090] In step S503, the organization device 100 sends the encrypted push data D2 and the identification of the organization B to the server 400. For step S503, reference may be made to the above description of step S403, which will not be repeated here.

[0091] In step S505 , the server 400 sends the encrypted push data D2 and the public key of organization B to TEE 40 .

[0092] After receiving the ciphertext push data D2 and the identification of the institution B from the institution device 100 , the server 400 may store the ciphertext push data in a storage server within the server or outside the server, and obtain the storage address of the ciphertext push data.

[0093] Afterwards, the server 400 may send the file address of the ciphertext push data and the public key of the organization B to the TEE, so that the TEE can read the ciphertext push data D2 from the file address, wherein the public key of the organization B is subsequently used to encrypt the data sent to the organization B. It can be understood that the TEE is not limited to using the public key of the organization to encrypt the data sent to the organization B, but can use any key negotiated between the TEE and the organization device 200, including symmetric keys and asymmetric keys. The server 400 can also send the ciphertext push data D2 and the public key of the organization B directly to the TEE40. Among them, the TEE can also verify the organization A by verifying the signature.

[0094] Optionally, TEE can store the public key of organization B received from the server on the blockchain. TEE can chain the server's operations by putting the public key of organization B received from the server on the blockchain. Organization B can verify whether the public key provided by the server is correct, avoiding the following possibility of the server doing evil: the server may replace the public key of the organization's device with its own public key and provide it to TEE, so that the server can use its own private key to decrypt the file encrypted with the server's public key output by TEE. The file should have been encrypted with the public key of the organization's device and sent to the organization's device, so that the server can steal the user's privacy information in this way.

[0095] In step S507, TEE decrypts the ciphertext push data D2 to obtain the push data, and encrypts the push data using the public key of organization B to obtain the ciphertext push data D3.

[0096] Specifically, after obtaining the ciphertext push data D2, TEE40 uses its own private key to decrypt the ciphertext push data D2, thereby obtaining the push file D0. Afterwards, TEE uses the public key of organization B to encrypt the push data D0 to obtain the ciphertext push data D3.

[0097] Among them, TEE is a trusted execution environment that is completely isolated from the outside and based on the security extension of CPU hardware. At present, the industry pays great attention to the TEE solution. Almost all mainstream chip and software alliances have their own TEE solutions, such as TPM (Trusted Platform Module) in software and Intel SGX (Software Guard Extensions), ARM Trustzone and AMD PSP (Platform Security Processor) in hardware. TEE can play the role of a hardware black box. The code and data executed in TEE cannot be peeped even at the operating system layer. They can only be operated through the pre-defined interfaces in the code. In terms of efficiency, due to the black box nature of TEE, the calculations performed in TEE are plaintext data, rather than complex cryptographic operations in homomorphic encryption, and there is almost no loss in the efficiency of the calculation process.

[0098] Take 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. Among them, the server can use the newly added processor instructions in the CPU to allocate a part of the area EPC (Enclave Page Cache, enclave page cache or enclave page cache) in the memory for the above enclave to reside. The memory area corresponding to the above EPC is encrypted by the memory encryption engine MEE (Memory Encryption Engine) inside the CPU. The content in this memory area (code and data in the enclave) can only be decrypted in the CPU core, and the key used for encryption and decryption is only generated and stored in the CPU when the EPC is started. It can be seen that the security boundary of the enclave only includes itself and the CPU. No privileged or non-privileged software can access the enclave. Even the operating system administrator and VMM (Virtual Machine Monitor, or Hypervisor) cannot affect the code and data in the enclave, so it has extremely high security. Under the premise of the above security guarantee, the CPU can process data in plain text in the enclave with extremely high computing efficiency, thus taking into account both data security and computing efficiency. Data entering and leaving the TEE can be encrypted to ensure data privacy.

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

[0100] For example, before using the public key of TEE to encrypt the push data D0, the institution device 100 can first verify whether the TEE is trustworthy. Specifically, the institution device 100 can challenge the TEE and receive the remote attestation report returned by the TEE. After obtaining the remote attestation report, the institution device 100 can verify the signature of the remote attestation report according to the public key of the authoritative authentication server. If the verification passes, it can be confirmed that the TEE is trustworthy. Specifically, after receiving the verification request, the TEE generates authentication information based on its internal mechanism, and sends the authentication information and the hardware public key of the TEE to the institution device 100. The authentication information includes, for example, the signature information, hardware information and software information of the TEE. Among them, the signature information is generated, for example, by the hardware key of the TEE; the hardware information includes, for example, various hardware indicators, such as CPU main frequency, memory capacity, etc.; the software information includes the code hash value, code name, version, operation log, etc. of each program. As known to those skilled in the art, TEE can perform "measurement" of the program running therein through memory hardware, such as obtaining the code hash value of the program, the hash value of the memory occupied by the program at a specific execution point, etc., and include the "measurement" information of the program in the authentication information. Since the "measurement" information is executed by the TEE entity itself (memory hardware) without involving any software or operating system, it is authentic and reliable. After receiving the authentication information, the institution device 100 can send the authentication information to the remote authentication server of the TEE, thereby receiving a remote attestation report of the TEE from the server. The remote attestation report includes the identity authentication of the TEE, the verification of the program executed inside the TEE, etc. Therefore, the institution device 100 can determine that the TEE is credible based on the remote attestation report, and the query result through the TEE is credible. At the same time, the institution device 100 can save the hardware public key of the TEE locally for subsequent verification of the signature of the TEE. Among them, a pair of public and private keys are stored in the TEE, and the private key is properly kept in the TEE. The content transmitted by the TEE can be signed with the private key stored in the TEE, thereby proving that it is the result of execution by the TEE.

[0101] In step S509 , TEE provides the encrypted push data D3 to the server 400 .

[0102] Specifically, TEE can store the ciphertext push data D3 outside TEE (i.e., the above-mentioned EPC) and send the storage address to the server, so that the server 400 can read the ciphertext push data D3. Among them, TEE can store the ciphertext push data D3 in association with the identifier "D2" of the ciphertext push data D2 to indicate that the ciphertext push data D3 corresponds to the data D2.

[0103] In step S511, the server sends the encrypted push data D3 to the institution device 200 of institution B.

[0104] Specifically, after receiving the encrypted push data D3, the server 400 obtains the connection address of the institution device 200 according to the correspondence between the encrypted push data D2 and the institution B identifier, and sends the encrypted push data D3 to the institution device 200 through the connection address.

[0105] In step S513, the mechanism device 200 decrypts the ciphertext push data D3 to obtain the push data.

[0106] This step may refer to the above description of step S407 and will not be described again here.

[0107] In the embodiments of this specification, the push file is desensitized and encrypted by the organization's equipment and then sent to the TEE via the server, and the encrypted push data is processed in the TEE, thereby eliminating the possibility of the server doing evil and further improving the security of private data. At the same time, by having the server transfer between organizations, the sending organization of the push data (i.e., organization A) can be hidden from organization B, thereby further protecting user privacy.

[0108] In the above two embodiments, the server can know to which institution the institution device 100 will push the ciphertext push data, which leaks some private data to the server. If the server is untrustworthy, it may bring the risk of privacy leakage. Figure 6 Another embodiment shown avoids this risk.

[0109] Figure 6 This is a flow chart of a risk data push method in another embodiment of this specification.

[0110] like Figure 6 As shown, first in step S601, the mechanism device 100 generates ciphertext push data D4.

[0111] The organization device 100 first generates push data D0 corresponding to organization B, and the push data D0 includes an account (or desensitized account) in organization B and a risk label for the account. In one embodiment, the push data may also include an identifier of the sending organization (i.e., organization A) and an account in organization A corresponding to the account in the above-mentioned organization B, to indicate the source of the risk label. Afterwards, the organization device 100 uses the TEE public key to encrypt the combined data of the push data and the identifier of the target organization (e.g., organization B) (e.g., DIDb of organization B) to generate ciphertext push data D4. By including the identifier of organization B in the ciphertext push data instead of sending the identifier of organization B in plain text to the server, the server cannot obtain the target organization of the push data, thereby protecting user privacy.

[0112] In step S603 , the mechanism device 100 sends the encrypted push data D4 to the server 400 .

[0113] In step S605, the server 400 sends the encrypted push data D4 and the public keys of multiple institutions to TEE 40, where the multiple institutions include institution B. The multiple institutions are, for example, Figure 3 All the organizations verified by the server are shown to include, for example, organization A, organization B, and organization C, so that the server can obtain the public key of each organization, including the public key of organization B, during the verification process of each organization.

[0114] In step S607, TEE decrypts the ciphertext push data D4 to obtain the push data D0 and the organization B identifier, encrypts the push data using the organization B public key to obtain the ciphertext push data D5, and encrypts the preset string using the public key of other organizations to obtain the corresponding ciphertext push data.

[0115] TEE40 can use its own private key to decrypt the ciphertext push data D4 to obtain the push data D0 and the identification of organization B. Afterwards, TEE40 uses the public key of organization B to encrypt the push data D0 to obtain the ciphertext push data D5, and stores the ciphertext push data D5 in association with the identification of organization B in TEE. At the same time, TEE40 uses the public key of organization C to encrypt a string indicating invalidity (for example, "valid+random number x") to obtain the ciphertext push data D6, and stores the ciphertext push data D6 in association with the identification of organization C in TEE; uses the public key of organization A to encrypt another string indicating invalidity (for example, "valid+random number y") to obtain the ciphertext push data D7 ( Figure 6 (not shown in the figure), the encrypted push data D7 is associated with the identification of organization A and stored in TEE.

[0116] In step S609, TEE40 provides the encrypted push data and its corresponding organization identification to the server 400.

[0117] Specifically, TEE 40 may provide the server 400 with a table as shown below:

[0118] Institution A Ciphertext push data D7 Institution B Ciphertext push data D5 Institution C Ciphertext push data D6

[0119] The server 400 can then send the corresponding encrypted push data to each organization according to the table. Figure 6 As shown in , the server 400 may send the encrypted push data D6 to the institution device 300 in step S611, and may send the encrypted push data D5 to the institution device 200 in step S613.

[0120] In step S615, after receiving the encrypted push data D5, the institution device 200 may use the private key of the institution B to decrypt the encrypted push data D5, thereby obtaining the push data D0.

[0121] After receiving the ciphertext push data D6, the institution device 300 can use the private key of the institution C to decrypt the ciphertext push data D6 to obtain "valid+random number x". The institution device 300 can determine that the plaintext data is invalid data based on the "valid" in the plaintext data.

[0122] In this embodiment, TEE40 generates encrypted push data sent to each organization by using the public key of each organization, thereby obfuscating the encrypted push data sent by organization A to organization B, so that the server 400 cannot know that the target organization of the encrypted push data sent by organization A is organization B, thereby protecting privacy data and improving data security.

[0123] Figure 6 Although it is shown that the institution device 100 sends the ciphertext push data D4 to the server, and the server provides the ciphertext push data D4 and each institution public key to the TEE, the embodiments of this specification are not limited to this. In one embodiment, the institution device 100 can send the ciphertext push data D4 directly to the trusted unit, and the trusted unit can generate the ciphertext push data D5 and D6 based on the pre-acquired multiple institution public keys, and directly send the ciphertext push data D5 and D6 to the corresponding institution device.

[0124] Figure 7 This is a flow chart of a risk data push method according to another embodiment of this specification.

[0125] like Figure 7 As shown, first, in step S701, the mechanism device 100 generates ciphertext push data D1. This step can refer to the description of step S401 above, and will not be repeated here.

[0126] In step S703, the institution device 100 associates the encrypted push data D1 with the identifier of institution B and stores it in the blockchain.

[0127] Specifically, the institution device 100 can send, for example, a transaction Tx1 to the blockchain, where the sending account of the transaction Tx1 is DIDa of institution A, and the transaction includes the ciphertext push data D1 and the associated identifier of institution B. After receiving the transaction Tx1, each node in the blockchain respectively executes the transaction Tx1 after reaching a consensus on the transaction Tx1, and stores the transaction Tx1 in the blockchain, thereby associating the ciphertext push data D1 and the identifier of institution B in the blockchain.

[0128] In step S705, the institution device 200 obtains the encrypted push data D1 from the blockchain.

[0129] The institutional device 200 can periodically pull block data from a node of the blockchain. After pulling the block data, it can search for transactions that include the identification of institution B in the block data, thereby searching for transaction Tx1 and reading the ciphertext push data D1 from transaction Tx1.

[0130] In one embodiment, the organization device 200 may periodically pull data stored in association with the identification of organization B from the blockchain node, so that the blockchain node only returns the encrypted push data D1 to the organization device 200. In this way, the organization device 200 cannot know that the encrypted push data D1 is sent from organization A to organization B, thereby further protecting the privacy data.

[0131] In step S707 , the mechanism device 200 decrypts the ciphertext push data D1 to obtain the push data D0 .

[0132] The organization device 200 can use the private key of organization B to decrypt the ciphertext push data D1 to obtain the push data D0.

[0133] In this embodiment, the institution device 100 can store all the ciphertext push data sent to other institutions in the blockchain, and each institution can also query the ciphertext push data sent to it by other institutions from the blockchain, thereby improving the efficiency of the institution device 100 in sending ciphertext push data to upstream and downstream institutions. At the same time, by storing the ciphertext push data on the blockchain, data security is guaranteed while protecting privacy data.

[0134] Figure 8 The following is an architecture diagram of a trusted unit in an embodiment of this specification, including:

[0135] an acquisition unit 81, configured to acquire first ciphertext push data, the first ciphertext push data being generated by encrypting combined data of push data and an identifier of a second institution, the push data comprising account information and a risk label of a second account in a second institution that is business-associated with one or more first accounts in the first institution, the risk label of the second account being determined based on the risk labels of the one or more first accounts;

[0136] A decryption unit 82, configured to decrypt the first ciphertext push data to obtain the push data and the identifier of the second institution;

[0137] An encryption unit 83 is used to encrypt the push data using the pre-acquired public key of the second institution to obtain the second ciphertext push data;

[0138] The output unit 84 is used to output the second encrypted push data for sending to the second mechanism device.

[0139] Fig. 9 The following is an architecture diagram of a server in an embodiment of this specification, including:

[0140] A receiving unit 91 is configured to receive first encrypted push data from a first institution device of a first institution, where the first encrypted push data is generated by encrypting combined data of the push data and an identifier of a second institution, where the push data includes account information and a risk tag of a second account in a second institution that is business-associated with one or more first accounts in the first institution, where the risk tag of the second account is determined based on the risk tags of the one or more first accounts;

[0141] A providing unit 92, configured to provide the first ciphertext push data and pre-acquired public keys of multiple institutions to a trusted unit, wherein the multiple institutions include the second institution and one or more third institutions;

[0142] The receiving unit 91 is further used to: receive from the trusted unit second ciphertext push data and an identifier of a second institution corresponding thereto, and one or more third ciphertext push data and an identifier of a third institution corresponding thereto, wherein the second ciphertext push data is generated by encrypting the push data using a public key of the second institution, and the one or more third ciphertext push data is generated by encrypting one or more data indicating invalid data using public keys of respective third institutions;

[0143] The sending unit 93 is used to send the second ciphertext push data to the second institution, and send each third ciphertext push data to each third institution.

[0144] The embodiment of the present specification also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the following Figure 2 , Figure 3 or Figure 4 The method shown.

[0145] The embodiment of the present specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the following is implemented: Figure 2 , Figure 3 or Figure 4 The method shown.

[0146] In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, 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, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0147] The controller can be implemented in any appropriate manner, for example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) that can be executed by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, the controller can be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and structures within the hardware component.

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

[0149] Although one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps, and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such a process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any specific order.

[0150] For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing one or more of the present specification, the functions of each module can be implemented in the same or more software and / or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0151] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0152] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0153] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

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

[0155] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0156] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules 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 technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0157] It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present 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.

[0158] One or more embodiments of the present specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0159] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.

[0160] The above description is only an example of one or more embodiments of the present specification and is not intended to limit one or more embodiments of the present specification. For those skilled in the art, one or more embodiments of the present specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present specification shall be included in the scope of the claims.

Claims

1. A risk data push method, comprising: A first institution device of a first institution generates push data, the push data including account information and risk tags of a second account in a second institution that is business-related to one or more first accounts in the first institution, the risk tags of the second account being determined based on the risk tags of the one or more first accounts, and generating first encrypted push data based on the push data; Sending the first ciphertext push data to an intermediate device, wherein the intermediate device includes a trusted unit, the trusted unit is used to process privacy data, and the first ciphertext push data is generated by encrypting the combined data of the push data and the identifier of the second institution; wherein the first institution device sending the first ciphertext push data to the intermediate device includes: the first institution device sending the first ciphertext push data to the trusted unit; The trusted unit decrypts the first ciphertext push data to obtain the push data and the identifier of the second institution, encrypts the push data using the pre-acquired public key of the second institution to obtain second ciphertext push data, and outputs the second ciphertext push data for sending to the second institution device; The second mechanism device of the second mechanism obtains second ciphertext push data of the push data via the intermediate device, the second ciphertext push data corresponds to the first ciphertext push data, and decrypts the second ciphertext push data to obtain the push data. 2 . The method according to claim 1 , wherein the first ciphertext push data is generated by encrypting using a public key of the trusted unit.

3. According to the method of claim 1 or 2, the intermediate device further comprises a server, and the first mechanism device sending the first ciphertext push data to the trusted unit comprises: The first mechanism device sends the first ciphertext push data to the server, so that the server provides the first ciphertext push data to the trusted unit; The method further includes: the server providing the public keys of multiple institutions acquired in advance to the trusted unit, the multiple institutions including the second institution and one or more third institutions; the trusted unit encrypts one or more data indicating invalid data using the public keys of the third institutions respectively to obtain one or more third ciphertext push data, and providing the one or more third ciphertext push data and the corresponding third institution identifiers to the server; The trusted unit outputting the second ciphertext push data includes: the trusted unit providing the second ciphertext push data and the identifier of the corresponding second institution to the server; The method further includes: the server sending the second ciphertext push data to the second institution, and sending each third ciphertext push data to each third institution.

4. The method according to claim 1, wherein the first ciphertext push data is generated by encrypting the push data, and the first mechanism device sends the first ciphertext push data to the intermediate device, comprising: The first institution device sends the first ciphertext push data and the identifier of the second institution to the intermediate device.

5. The method according to claim 4, wherein the intermediate device comprises a server, the second ciphertext push data is consistent with the first ciphertext push data, and the method further comprises: The server sends the first encrypted push data to the second institution device according to the identifier of the second institution.

6. The method according to claim 4, wherein the intermediate device comprises a server and a trusted unit, The first institution device sending the first ciphertext push data and the identifier of the second institution to the intermediate device includes: The first institution device sends the first ciphertext push data and the identifier of the second institution to the server; The method further comprises: the server providing the first ciphertext push data and the pre-acquired public key of the second institution to the trusted unit; The trusted unit decrypts the first ciphertext push data to obtain the push data, encrypts the push data using the public key of the second institution to obtain second ciphertext push data, and provides the second ciphertext push data to the server for sending to the second institution device.

7. The method according to claim 4, wherein the intermediate device comprises a blockchain system, The first institution device sending the first ciphertext push data and the identifier of the second institution to the intermediate device includes: The first institution device sends the first ciphertext push data and the identifier of the second institution to the blockchain system to store evidence in the blockchain system; The second institution device of the second institution obtains the second encrypted push data of the push data via the intermediate device, including: the second institution device obtains the first encrypted push data from the blockchain system based on the identifier of the second institution.

8. According to the method of claim 5 or 6, the account information of the second account includes: A digest value obtained by hashing the second account.

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

10. The method according to claim 3, further comprising: After receiving the public keys of the multiple institutions from the server, the trusted unit stores the public keys of the multiple institutions received from the server in the blockchain.

11. The method according to claim 3, wherein the public keys of the multiple institutions are public keys of the DIDs of the multiple institutions, and the method further comprises: The server obtains the public keys of the DIDs of the multiple institutions from the blockchain.

12. A risk data push method, executed by a trusted unit in an intermediate device, comprising: receiving first encrypted push data from a first institution device of a first institution via the intermediate device, the first encrypted push data being generated by encrypting, by the first institution device, combined data of the push data and an identifier of a second institution, the push data comprising account information and a risk tag of a second account in a second institution that is business-related to one or more first accounts in the first institution, the risk tag of the second account being determined based on the risk tags of the one or more first accounts; Decrypting the first ciphertext push data to obtain the push data and an identifier of the second institution; Encrypt the push data using the pre-acquired public key of the second institution to obtain second ciphertext push data; The second ciphertext push data is output for sending to the second mechanism device.

13. The method according to claim 12, wherein the obtaining of the first ciphertext push data comprises receiving the first ciphertext push data from a server, and the method further comprises: receiving public keys of a plurality of institutions from the server, the plurality of institutions including the second institution and one or more third institutions; Using the public keys of the third-party institutions, one or more data indicating invalid data are encrypted to obtain one or more third ciphertext push data, and the one or more third ciphertext push data and the corresponding identifiers of the third-party institutions are provided to the server; The outputting the second ciphertext push data includes: providing the second ciphertext push data and the identifier of the corresponding second institution to the server.

14. A risk data push method, executed by a server, comprising: receiving first encrypted push data from a first institution device of a first institution, the first encrypted push data being generated by encrypting combined data of the push data and an identifier of a second institution, the push data comprising account information and a risk tag of a second account in a second institution that is business-associated with one or more first accounts in the first institution, the risk tag of the second account being determined based on the risk tags of the one or more first accounts; Providing the first ciphertext push data and pre-acquired public keys of multiple institutions to a trusted unit, wherein the multiple institutions include the second institution and one or more third institutions; receiving, from the trusted unit, second ciphertext push data and an identifier of a second institution corresponding thereto, and one or more third ciphertext push data and an identifier of a third institution corresponding thereto, wherein the second ciphertext push data is generated by encrypting the push data using a public key of the second institution, and the one or more third ciphertext push data is generated by encrypting one or more data indicating invalid data respectively using public keys of respective third institutions; The second ciphertext push data is sent to the second institution, and each third ciphertext push data is sent to each third institution.

15. A risk data push system, comprising a first institution device of a first institution, a second institution device of a second institution and an intermediate device, The first institution device is used to generate push data, the push data including account information and risk tags of a second account in a second institution that is business-associated with one or more first accounts in the first institution, the risk tag of the second account being determined based on the risk tags of the one or more first accounts, and generating first ciphertext push data based on the push data; The first ciphertext push data is sent to the intermediate device, wherein: The intermediate device includes a trusted unit, the trusted unit is used to process privacy data, the first ciphertext push data is generated by encrypting the combined data of the push data and the identifier of the second institution; wherein the first institution device sends the first ciphertext push data to the intermediate device, comprising: the first institution device sends the first ciphertext push data to the trusted unit; The trusted unit decrypts the first ciphertext push data to obtain the push data and the identifier of the second institution, encrypts the push data using the pre-acquired public key of the second institution to obtain second ciphertext push data, and outputs the second ciphertext push data for sending to the second institution device; The second mechanism device is used to obtain second ciphertext push data of the push data via the intermediate device, the second ciphertext push data corresponds to the first ciphertext push data, and decrypt the second ciphertext push data to obtain the push data.

16. A trusted unit in an intermediate device, comprising: an acquiring unit, configured to receive first encrypted push data from a first institution device of a first institution via the intermediate device, wherein the first encrypted push data is generated by encrypting, by the first institution device, a combination of push data and an identifier of a second institution, the push data comprising account information and a risk label of a second account in a second institution that is business-associated with one or more first accounts in the first institution, wherein the risk label of the second account is determined based on the risk labels of the one or more first accounts; a decryption unit, configured to decrypt the first ciphertext push data to obtain the push data and an identifier of the second institution; an encryption unit, configured to encrypt the push data using the pre-acquired public key of the second institution to obtain second ciphertext push data; An output unit is used to output the second encrypted push data for sending to the second mechanism device.

17. A server, comprising: a receiving unit, configured to receive first encrypted push data from a first institution device of a first institution, wherein the first encrypted push data is generated by encrypting combined data of the push data and an identifier of a second institution, wherein the push data includes account information and a risk tag of a second account in a second institution that is business-associated with one or more first accounts in the first institution, wherein the risk tag of the second account is determined based on the risk tags of the one or more first accounts; a providing unit, configured to provide the first ciphertext push data and pre-acquired public keys of multiple institutions to a trusted unit, wherein the multiple institutions include the second institution and one or more third institutions; The receiving unit is further used to: receive, from the trusted unit, second ciphertext push data and an identifier of a second institution corresponding thereto, and one or more third ciphertext push data and an identifier of a third institution corresponding thereto, wherein the second ciphertext push data is generated by encrypting the push data using a public key of the second institution, and the one or more third ciphertext push data is generated by encrypting one or more data indicating invalid data using public keys of respective third institutions; The sending unit is used to send the second ciphertext push data to the second institution, and send each third ciphertext push data to each third institution.

18. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 12 to 14.

Images