A risk data push method, system and trusted unit

Abstract

A risk data push method, system and trusted unit, the method comprising: multiple institution devices send ciphertext push data to a trusted unit for privacy data processing; the trusted unit decrypts the received multiple ciphertext push data respectively to obtain multiple push data; based on the multiple push data, first data corresponding to a first institution is generated, the first data includes account information of a first account in the first institution and a first risk label set; the first data is encrypted to obtain first ciphertext data; the first ciphertext data is provided to a first institution device; the first institution device decrypts the first ciphertext data to obtain a first risk label set for the first account.

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, 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 realizes the push of risk data between multiple institutions by processing the risk data of upstream and downstream accounts of institutional accounts in a trusted unit, thereby improving the processing efficiency of push data of multiple institutions while protecting privacy data.

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

[0005] A plurality of institutional devices send encrypted push data to a trusted unit, wherein the plurality of institutional devices include a first institutional device, the first institutional device belongs to a first institution, and the trusted unit is used to process private data;

[0006] The trusted unit decrypts the received multiple ciphertext push data respectively to obtain multiple push data, wherein the push data includes account information, risk labels and institution identifications of accounts in other institutions that are business-related to one or more accounts in the institution that sends the push data; generates first data corresponding to the first institution based on the multiple push data, wherein the first data includes account information and a first risk label set of a first account in the first institution; encrypts the first data to obtain first ciphertext data; and provides the first ciphertext data to the first institution device;

[0007] The first institution device decrypts the first ciphertext data to obtain a first risk label set for the first account.

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

[0009] Acquire multiple encrypted push data of multiple institutions, wherein the multiple institutions include the first institution;

[0010] Decrypting the plurality of ciphertext push data respectively to obtain a plurality of push data, wherein the push data includes account information, risk labels and institution identifiers of other institutions of one or more accounts in the institution sending the push data that are business-related to accounts in other institutions;

[0011] generating first data corresponding to the first institution based on the multiple pushed data, wherein the first data includes account information of a first account in the first institution and a first risk label set;

[0012] Encrypting the first data to obtain first ciphertext data;

[0013] The first ciphertext data is provided to a first institution device of the first institution.

[0014] A third aspect of this specification provides a risk data push system, including multiple institutional devices and trusted units.

[0015] The plurality of institutional devices are used to send the ciphertext push data to the trusted unit, wherein the plurality of institutional devices include a first institutional device, and the first institutional device belongs to a first institution;

[0016] The trusted unit is used to decrypt the received multiple ciphertext push data respectively to obtain multiple push data, wherein the push data includes account information, risk labels and institution identifications 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 corresponding to the first institution based on the multiple push data, wherein the first data includes account information and a first risk label set of a first account in the first institution; encrypt the first data to obtain first ciphertext data; and provide the first ciphertext data to the first institution device;

[0017] The first institution device is used to decrypt the first ciphertext data to obtain a first risk label set for the first account.

[0018] A fourth aspect of the present specification provides a trusted unit, including:

[0019] An acquisition unit, used to acquire multiple ciphertext push data of multiple institutions, wherein the multiple institutions include the first institution;

[0020] a decryption unit, configured to decrypt the plurality of ciphertext push data respectively to obtain a plurality of push data, wherein the push data includes account information, risk labels and institution identifications of other institutions of accounts in other institutions that are business-related to one or more accounts in the institution sending the push data;

[0021] a generating unit, configured to generate first data corresponding to the first institution based on the plurality of pushed data, wherein the first data includes account information of a first account in the first institution and a first risk label set;

[0022] An encryption unit, used for encrypting the first data to obtain first ciphertext data;

[0023] A providing unit is used to provide the first ciphertext data to a first institution device of the first institution.

[0024] A fifth 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.

[0025] A sixth 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 is implemented.

[0026] In the embodiments of the present specification, the push file including the risk data of upstream and downstream accounts is desensitized and encrypted by the institutional equipment and then sent to the TEE, and the risk data is aggregated in the TEE, thereby improving the efficiency of pushing risk data of upstream and downstream accounts between multiple institutions while protecting user privacy. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0029] Figure 2 This is a flow chart of a method for generating an encrypted push file on the device side of the mechanism in the embodiment of this specification;

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

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

[0032] Figure 5 A schematic diagram of the process of pushing files by the generation mechanism in the embodiment of this specification;

[0033] Figure 6 This is an architectural diagram of a trusted unit in an embodiment of this specification. DETAILED DESCRIPTION

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

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

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

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

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

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

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

[0041] Different financial institutions have the obligation to review suspicious transactions. For example, when institution A discovers in monitoring and analysis that customer "A" who is 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 embodiment of this specification, the risk data pushed by multiple institutions to the upstream and downstream account opening institutions are summarized based on the trusted unit, thereby improving the efficiency of risk data push.

[0042] 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 reviewing suspicious transactions, so as to obtain the risk label of each user.

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

[0044] 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 The example of TEE40 as a trusted unit is shown in the figure, and the following description is based on TEE40 as a trusted unit. Each institution device can send the desensitized and encrypted push data to the server 400, and the server 400 stores the push data of each institution locally or in a file storage server ( Figure 1 TEE40 can receive the address for storing push data from server 400, obtain push data from the address, perform fusion processing on the push data of multiple institutions, and return the fusion processed data to the equipment of each institution, thereby pushing the user's risk data between institutions while protecting the user's privacy. Among them, server 400 and TEE40 can be connected to blockchain 500, and the risk data push solution in the embodiment of this specification can be implemented in combination with blockchain 500. 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.

[0045] Figure 2 This is a flow chart of the method for generating an encrypted push file on the device side of the mechanism 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.

[0046] like Figure 2 As shown, first, in step S201, the institutional device 100 reads the file F1 to obtain the upstream and downstream accounts, risk labels and institutional identification of the account opening institution.

[0047] In the institution A corresponding to the institution device 100, the institution administrator can regularly generate a file F1 in the institution device 100 according to the data analysis results in the institution A, and the file F1 includes the risk data of the upstream and downstream accounts of the account of the institution, so as to push the risk data to the upstream and downstream account opening institutions corresponding to the upstream and downstream accounts. It can be understood that although the data or information is carried in the form of a file here, the embodiments of this specification are not limited to this. For example, the data or information can also be carried in the form of text or table, and this is not limited. The risk file F1 includes multiple rows, each row includes an upstream and downstream account, the risk label of the upstream and downstream account, and the institution identification of the account opening institution of the upstream and downstream account. The risk label is a label indicating the degree of risk negotiated 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.

[0048] After the organization administrator generates the file F1 in the organization device 100, the file F1 is uploaded to the storage of the client. After monitoring the update of the file F1, the client can read the file F1 line by line, for example, to perform desensitization processing line by line.

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

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

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

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

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

[0054] 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 user account in the push files they send to the server.

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

[0056] In step S207, the institution device 100 writes the desensitized account, risk label and institution identification of the account opening institution into the push file F2.

[0057] When the client in the institution device 100 starts to read the file F1, the file F2 can be initialized. After reading the file F1 line by line to obtain the desensitized account corresponding to the account in a row, the desensitized account, risk label and institution identification of the account opening institution are recorded in a row in the file F2 corresponding to the row in the file F1. After the client performs the above processing on each row in the file F1, the push file F2 corresponding to the file F1 can be generated.

[0058] In one implementation, after generating file F2 as described above, the client may sort the rows in file F2 in ascending order of each desensitized account to facilitate subsequent fusion processing of push files from multiple institutions.

[0059] In step S209, the client can also use the public key of the TEE to encrypt the file F2, thereby generating an encrypted push file F3. In this way, the plaintext data in the file F2 cannot be obtained from outside the TEE of the server 400, further protecting the user's privacy. It can be understood that this is not limited to using the public key of the TEE to encrypt the file F2. For example, other asymmetric keys or symmetric keys can be negotiated between the TEE and the institution's equipment to encrypt the file F2.

[0060] In one implementation, when the security requirement is low, the upstream and downstream accounts in the file F1 may not be desensitized, so that the file F1 may be directly encrypted to obtain the encrypted push file F3.

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

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

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

[0064] For example, before using the public key of TEE to encrypt file F2, the institutional device 100 can first verify whether TEE is trustworthy. Specifically, the institutional device 100 can challenge TEE and receive the remote attestation report returned by TEE. After obtaining the remote attestation report, the institutional 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 TEE is trustworthy. Specifically, after receiving the verification request, TEE generates authentication information based on its internal mechanism, and sends the authentication information and the hardware public key of TEE to the institutional 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 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.

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

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

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

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

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

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

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

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

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

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

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

[0076] The server 400 may periodically request encrypted push files from various institutional devices, and the institutional device 100 may respond to the server's request by sending the encrypted push files to the encrypted push files. Figure 2 The file F3 generated by the process shown is sent to the server 400. Specifically, the organization device 100 can use the private key of the DID of organization A to sign the file F3, and send the DID of organization A (such as DIDa), file F3 and the signature of file F3 by the private key of DIDa to the server 400.

[0077] In step S403, the server 400 provides the TEE with the encrypted push files (including file F3) and the institution public key corresponding to each institution DID.

[0078] After receiving the encrypted push file from each institution device, the server 400 may store the encrypted push file in a storage server inside the server or outside the server, and obtain the storage address of the encrypted push file.

[0079] Afterwards, the server 400 may send the DID list of each organization, and the file address and public key of the encrypted push file corresponding to each DID to the TEE. The TEE can read the encrypted push file corresponding to each DID from the file address corresponding to each DID. Among them, the public key of each organization is subsequently used to encrypt the files sent to the organization. It can be understood that the TEE is not limited to using the public key of the organization to encrypt the files sent to the organization, but can use any key negotiated between the TEE and the organization's equipment, or the server and the organization's equipment, including symmetric keys and asymmetric keys.

[0080] In one implementation, the server 400 may send the DID list of each organization, and the file address and public key of the encrypted push file corresponding to each DID to the TEE after passing the signature verification of the encrypted push file of each organization.

[0081] In one embodiment, the server may provide multiple signatures of the multiple agency devices to TEE, so that before decrypting the multiple encrypted push files respectively, TEE first uses the public keys of the multiple agencies to verify the multiple signatures respectively, and decrypts the multiple encrypted push files if the verification is successful.

[0082] In step S405, TEE uploads the public keys of each institution received from the server to the chain.

[0083] TEE chains the server's operations by putting the public keys of various institutions received from the server on the chain. Each institution can verify whether the public key provided by the server is correct, avoiding the following possibility of server misconduct: the server may replace the public key of the institution'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 output by TEE that is encrypted with the server's public key. The file should have been encrypted with the public key of the institution's device and sent to the institution's device, so the server can steal user privacy information in this way.

[0084] In step S407, TEE generates organization push files for each organization, including organization push file F4 of organization A.

[0085] Specifically, after obtaining the encrypted push files of each organization, TEE uses its own private key to decrypt each encrypted push file, thereby obtaining the push files of each organization (including the above-mentioned push file F2). Afterwards, TEE can generate an organization push file corresponding to each organization based on the push files of multiple organizations.

[0086] Figure 5 This is a schematic diagram of the process of the generation mechanism pushing files in the embodiment of this specification. Figure 5 The upper middle part schematically shows the push files of each institution, where the push file of institution A corresponds to the institution identification DIDa of institution A, the push file of institution B corresponds to the institution identification DIDb of institution B, and the push file of institution C corresponds to the institution identification DIDc of institution C. Each push file shows the desensitized accounts (or upstream and downstream accounts), risk labels and account opening institution identifications of the upstream and downstream accounts of each institution. Among them, multiple lines in the push file can be arranged in ascending order of desensitized accounts.

[0087] When merging multiple pushed files in TEE, such as Figure 5 As shown in , firstly, for each push file, a pointer is used to indicate the minimum desensitized account. Figure 5 Among the three desensitized accounts indicated by the pointers in the push files, the desensitized account Acc1 of institution A is the smallest account, and the account opening institution corresponding to the desensitized account Acc1 is institution b. Therefore, in Figure 5 In the first line of the organization push file (the middle file) of organization b shown in the lower part, "Acc1{risk1}" is written, where {risk1} is the current risk label set of Acc1.

[0088] After recording the information corresponding to Acc1 in the institution push file of institution B, point the pointer to the next line in the push file of institution A, that is, the line corresponding to Acc3, and repeat the above process. Specifically, after determining that the smallest ID indicated by the three pointers is Acc2 in TEE, record the information corresponding to Acc2 "Acc2{risk2, riskL}" in the first line of the institution push file F4 of the account opening institution A corresponding to the desensitized account Acc2. Through the same process as above, after traversing all the lines in each push file using the pointer, we can get Figure 5 The organization push files of each organization shown in the lower part are used to be sent to the organization devices of each organization.

[0089] In one embodiment, the TEE may first generate a summary file based on the push files of each institution, and the summary file aggregates the data in multiple push files into one file, wherein a line in the summary file includes a desensitized account, a risk label set, and an account opening institution identifier, wherein the risk label set is obtained based on multiple push files. In addition, the multiple lines in the summary file can be arranged in order from small to large of the desensitized accounts. After generating the summary file, the TEE can generate an institution push file for each institution based on the summary file. Taking institution A as an example, the TEE can traverse each line in the summary file, and when the institution identifier in the line is "DIDa", the desensitized account and risk label set in the line are recorded in the institution push file F4 of institution A. In this way, for example, the following can be obtained: Figure 5 The organization shown in push file F4.

[0090] In step S409, TEE encrypts the organization-pushed file F4 to obtain file F5.

[0091] TEE can use the public key of organization A to encrypt the organization-pushed file F4 and obtain file F5.

[0092] TEE encrypts file F4 using the public key of institution A, so that server 400 cannot read the plaintext data in file F4, thereby further protecting the privacy of the user. It can be understood that the embodiments of this specification are not limited to using the public key of institution A to encrypt file F4. For example, TEE can encrypt file F4 in an envelope based on the public key of institution A, or TEE can use other symmetric keys or asymmetric keys pre-negotiated with institution A to encrypt file F4.

[0093] In step S411 , the TEE provides the file F5 to the server 400 .

[0094] Specifically, TEE stores the file F5 outside the TEE (ie, the above-mentioned EPC) and sends the storage address to the server, so that the server 400 can read the file F5.

[0095] In step S413 , the server sends the file F5 to the institution device 100 of institution A.

[0096] In step S415, the mechanism device 100 decrypts the file F5 to obtain the file F4

[0097] Specifically, when file F5 is encrypted using the public key of institution A, institution device 100 uses the private key of institution A to decrypt file F5 to obtain file F4.

[0098] In step S417, the institution device 100 uses the user identifier to replace the desensitized account in the file F4 to obtain the file F6.

[0099] Specifically, the institutional device 100 can read the user identifier corresponding to each desensitized account in the file F4 from the aforementioned stored mapping table of user identifiers and user desensitized accounts, and replace the desensitized account in the file F4 with the user identifier, thereby generating the file F6. The institutional device 100 can thus make a comprehensive judgment on the risk level of the risk user based on the risk tag set of each user in the file F6, thereby improving the judgment accuracy.

[0100] Figure 4 Although the risk data push method is shown in combination with the server and TEE, the embodiments of this specification are not limited to this. In one embodiment, the institution device can directly send the encrypted push file to the TEE, and the TEE can directly send the generated file F5 to the institution device, thereby implementing the risk data push method. Among them, the TEE can obtain the institution public key of each institution from the blockchain to encrypt the push file of each institution.

[0101] In the embodiments of this specification, the push file is desensitized and encrypted by the institution's equipment and then sent to the TEE, and the risk data is aggregated in the TEE, thereby improving the efficiency of risk data push between multiple institutions while protecting user privacy.

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

[0103] An acquisition unit 61 is used to acquire multiple encrypted push data of multiple institutions, wherein the multiple institutions include the first institution;

[0104] A decryption unit 62, configured to decrypt the plurality of ciphertext push data respectively to obtain a plurality of push data, wherein the push data includes account information, risk labels and organization identifications of other organizations to which one or more accounts in the organization sending the push data are business-related;

[0105] A generating unit 63, configured to generate first data corresponding to the first institution based on the plurality of pushed data, wherein the first data includes account information of a first account in the first institution and a first risk label set;

[0106] An encryption unit 64, configured to encrypt the first data to obtain first ciphertext data;

[0107] The providing unit 65 is used to provide the first ciphertext data to a first institution device of the first institution.

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

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

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

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

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

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

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

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

[0116] 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 comprising 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.

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

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

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

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

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

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

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

[0124] 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 plurality of institutional devices send encrypted push data to a trusted unit, wherein the plurality of institutional devices include a first institutional device, the first institutional device belongs to a first institution, and the trusted unit is used to process private data; The trusted unit decrypts the received multiple ciphertext push data respectively to obtain multiple push data, wherein the push data includes account information, risk labels and organization identification of the organization that created the account of one or more accounts in the organization that sent the push data; generates first data corresponding to the first organization based on the multiple push data, wherein the first data includes account information and a first risk label set of a first account in the first organization; encrypts the first data to obtain first ciphertext data; and provides the first ciphertext data to the first organization device; The first institution device decrypts the first ciphertext data to obtain a first risk label set for the first account.

2. The method according to claim 1, wherein: The multiple institutional devices sending the ciphertext push data to the trusted unit includes: the multiple institutional devices sending the ciphertext push data to the server, and the server providing the ciphertext push data to the trusted unit; The trusted unit providing the first ciphertext data to the first institution device includes: the trusted unit providing the first ciphertext data to the server, and the server sending the first ciphertext data to the first institution device.

3. The method according to claim 2, wherein the account information comprises: The digest value obtained by hashing the account in the other institution.

4. The method of claim 3, further comprising: The institution device calculates a first hash value of an account in another institution, and sends the first hash value to the server; The server calculates the first hash value and a second hash value of a preset value as the account information of the account in the other institution, and returns the account information to the institution device.

5. According to the method of claim 3, the first institution device decrypts the first ciphertext data to obtain the first risk label set of the first account, comprising: The first mechanism device decrypts the first ciphertext data to obtain the first data; According to the pre-stored correspondence between the user identifier corresponding to the first account and the account information of the first account, second data is generated, where the second data includes the user identifier corresponding to the first account and the first risk label set.

6. The method according to claim 1 or 2, wherein the ciphertext push data is obtained by encrypting the push data using the public key of the trusted unit, and the trusted unit decrypts the plurality of ciphertext push data respectively, comprising: The trusted unit uses its private key to decrypt the multiple ciphertext push data respectively.

7. The method according to claim 2, further comprising: After receiving the plurality of ciphertext push data from the plurality of institution devices, the server stores the ciphertext push data pushed by each institution in association with the institution identification of each institution, and provides the storage address of each ciphertext push data to the trusted unit.

8. The method according to claim 2, further comprising: The server provides the public key of the first institution to the trusted unit, and the trusted unit encrypts the first data including: the trusted unit encrypts the first data using the public key of the first institution.

9. The method according to claim 8, further comprising: After receiving the public key of the first institution from the server, the trusted unit stores the public key of the first institution received from the server in the blockchain.

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

11. A risk data push method, executed by a trusted unit, comprising: Acquire multiple encrypted push data of multiple institutions, wherein the multiple institutions include the first institution; Decrypting the plurality of ciphertext push data respectively to obtain a plurality of push data, wherein the push data includes account information of accounts in other institutions that are business-related to one or more accounts in the institution sending the push data, risk labels, and an institution identifier of the institution that created the account; generating first data corresponding to the first institution based on the multiple pushed data, wherein the first data includes account information of a first account in the first institution and a first risk label set; Encrypting the first data to obtain first ciphertext data; The first ciphertext data is provided to a first institution device of the first institution.

12. A risk data push system, comprising multiple institutional devices and trusted units, Multiple mechanism devices are used to send encrypted push data to a trusted execution environment trusted unit, wherein: The plurality of institutional devices include a first institutional device, and the first institutional device belongs to a first institution; The trusted unit is used to decrypt the received multiple ciphertext push data respectively to obtain multiple push data, wherein the push data includes account information, risk labels and organization identification of the organization that created the account of one or more accounts in the organization sending the push data in other organizations that are business-related; generate first data corresponding to the first organization based on the multiple push data, wherein the first data includes account information and a first risk label set of a first account in the first organization; encrypt the first data to obtain first ciphertext data; Providing the first ciphertext data to the first mechanism device; The first institution device is used to decrypt the first ciphertext data to obtain a first risk label set for the first account.

13. A trusted unit, comprising: An acquisition unit, used to acquire multiple ciphertext push data of multiple institutions, wherein the multiple institutions include the first institution; a decryption unit, configured to decrypt the plurality of ciphertext push data respectively to obtain a plurality of push data, wherein the push data includes account information of accounts in other institutions that are business-related to one or more accounts in the institution sending the push data, risk labels, and an institution identifier of the institution that created the account; a generating unit, configured to generate first data corresponding to the first institution based on the plurality of pushed data, wherein the first data includes account information of a first account in the first institution and a first risk label set; An encryption unit, used for encrypting the first data to obtain first ciphertext data; A providing unit is used to provide the first ciphertext data to a first institution device of the first institution.

14. 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 claim 11.

15. A computing device comprising a memory and a processor, wherein the memory stores executable codes, and when the processor executes the executable codes, the method according to claim 11 is implemented.

Images