A user risk level determination method, system and trusted unit

Abstract

A user risk level determination method, system and trusted unit, the method comprising: a plurality of institutional devices sending encrypted user data of an institution to a trusted unit for privacy data processing; the trusted unit decrypting a plurality of encrypted user data respectively to obtain a plurality of user data sets; generating summary data of each user based on the plurality of user data sets; determining the risk level of each user based on the summary data of each user; generating prediction result data corresponding to each institution; encrypting a plurality of prediction result data to obtain a plurality of encrypted result data; providing each encrypted result data to each institutional device; and each institutional device decrypting the encrypted result data to obtain the prediction result data of each institution.

Description

Technical Field

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

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

[0003] The purpose of this invention is to provide a user risk level determination scheme, which obtains the user's risk level by jointly processing user data from multiple institutions through a trusted unit, thereby improving the level of risk control.

[0004] The first aspect of this specification provides a method for determining a user's risk level, including:

[0005] Multiple organizations send their encrypted user data to a trusted unit for privacy data processing;

[0006] The trusted unit decrypts the multiple encrypted user data to obtain multiple user datasets. Each user dataset includes user identifiers of multiple users in the corresponding institution and data corresponding to those user identifiers. Based on the multiple user datasets, summary data for each user is generated. Based on the summary data for each user, the risk level of each user is determined. Prediction result data corresponding to each institution is generated. The prediction result data includes user identifiers of multiple users in the corresponding institution and risk levels corresponding to those user identifiers. The multiple prediction result data are encrypted to obtain multiple encrypted result data. Each encrypted result data is provided to the equipment of the respective institution.

[0007] Each institution and device decrypts the encrypted result data to obtain the prediction result data of each institution.

[0008] The second aspect of this specification provides a method for determining a user risk level, executed by a trusted unit, including:

[0009] Receive encrypted user data from multiple mechanisms and devices, including the mechanisms to which each structure belongs.

[0010] The multiple encrypted user data are decrypted to obtain multiple user datasets. Each user dataset includes user identifiers of multiple users in the organization corresponding to the user dataset and data corresponding to the user identifiers.

[0011] Generate summary data for each user based on the multiple user datasets;

[0012] The risk level of each user is determined based on the aggregated data of each user.

[0013] Generate prediction result data corresponding to each institution. The prediction result data includes user identifiers of multiple users in the institution corresponding to the prediction result data and the risk level corresponding to the user identifiers.

[0014] Encrypt multiple prediction result data to obtain multiple ciphertext result data;

[0015] The encrypted result data is provided to each institution and device.

[0016] The third aspect of this specification provides a user risk level determination system, including multiple institutional devices and trusted units.

[0017] The plurality of institutional devices are used to send encrypted user data of their respective institutions to the trusted unit;

[0018] The trusted unit is configured to: decrypt the plurality of encrypted user data respectively to obtain a plurality of user datasets, wherein the user datasets include user identifiers of a plurality of users in the institution corresponding to the user dataset and data corresponding to the user identifiers; generate summary data for each user based on the plurality of user datasets; determine the risk level of each user based on the summary data for each user; generate prediction result data corresponding to each institution, wherein the prediction result data includes user identifiers of a plurality of users in the institution corresponding to the prediction result data and the risk level corresponding to the user identifiers; encrypt the plurality of prediction result data to obtain a plurality of encrypted result data; and provide each of the encrypted result data to the equipment of each institution.

[0019] Each mechanism and device is also used to decrypt the encrypted result data to obtain the prediction result data of each mechanism.

[0020] The fourth aspect of this specification provides a trusted element, comprising:

[0021] The receiving unit is used to receive encrypted user data from multiple mechanisms and devices, each belonging to a specific mechanism or device.

[0022] The decryption unit is used to decrypt the multiple encrypted user data respectively to obtain multiple user datasets. The user datasets include user identifiers of multiple users in the organization corresponding to the user dataset and data corresponding to the user identifiers.

[0023] A generation unit is used to generate summary data for each user based on the multiple user datasets;

[0024] The determination unit is used to determine the risk level of each user based on the aggregated data of each user.

[0025] The generation unit is also used to generate prediction result data corresponding to each institution. The prediction result data includes user identifiers of multiple users in the institution corresponding to the prediction result data and the risk level corresponding to the user identifiers.

[0026] An encryption unit is used to encrypt multiple prediction result data to obtain multiple ciphertext result data;

[0027] A providing unit is used to provide the encrypted result data to the respective institutional devices.

[0028] The fifth aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the second aspect.

[0029] A sixth aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method described in the second aspect.

[0030] In the embodiments described in this specification, by using a trusted unit to perform joint model prediction on user data from various organizations, a more comprehensive risk assessment of users can be conducted, thereby improving the level of risk control. Attached Figure Description

[0031] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

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

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

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

[0035] Figure 4 This is a flowchart of a user risk level determination method in one embodiment of this specification;

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

[0037] Figure 6 This is a schematic diagram of a system according to another embodiment of this specification;

[0038] Figure 7 This is a flowchart of a user risk level determination method in another embodiment of this specification;

[0039] Figure 8 This is an architecture diagram of a trusted unit in one of the embodiments of this specification. Detailed Implementation

[0040] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0041] Data sharing is frequently a necessity for organizations in processing their operations. A single organization often cannot obtain enough information to handle its business, thus creating a need to acquire information from other organizations. For example, many countries require financial institutions to provide anti-money laundering audit results as part of their anti-money laundering compliance requirements. Currently, many central banks and large financial institutions are attempting to utilize blockchain technology in the anti-money laundering field to improve efficiency and accuracy while meeting regulatory requirements. Meanwhile, data, as a resource, has liquidity and accessibility that form the basis for many data applications and industrial development; however, privacy protection during data exchange and sharing remains a significant challenge for industry development. The following section will further illustrate this using the aforementioned anti-money laundering example.

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

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

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

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

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

[0047] Different financial institutions have an obligation to review suspicious transactions. However, the transaction information related to the same user and the user's information often differ between different financial institutions. Therefore, the risk labels assigned to the same user after suspicious transaction analysis by different financial institutions may also differ. These risk labels may include multiple pre-set labels, each indicating the user's money laundering risk level, the type of illegal activity, or other money laundering-related information. A better approach to assigning risk labels to users is to combine data from multiple financial institutions to assign risk labels (or risk levels) to the same user.

[0048] Figure 1 This is a schematic diagram of the system in the embodiments of this specification. Figure 1As shown, institutional devices 100, 200, and 300 can be computing devices for, for example, institutions A, B, and C. Institutions A, B, and C can be any of the following: financial institutions, insurance companies, trading institutions, etc. It is understood that the three institutional devices shown in the figure are examples, and in practice, there may be multiple other institutional devices. Each institutional device has an anti-money laundering platform client installed, and each institutional device can directly receive user information, such as user registration information, historical transaction information, and historical transfer information.

[0049] Clients within institutional devices can perform certain processing tasks based on this user information, such as reviewing suspicious transactions as mentioned above, thereby obtaining risk labels for each user. Taking money laundering risk level as a specific risk label as an example, Institution A and Institution B can each label a user's money laundering risk level based on their own anti-money laundering audit capabilities. Therefore, the money laundering risk level labeled by Institution A and Institution B for user U1 may be different. For example, Institution A might label user U1 as "[High Risk Level]," while Institution B might label it as "[Medium Risk Level]." To obtain a more accurate money laundering risk level, multiple institutions can perform joint modeling through an anti-money laundering server (hereinafter referred to as the server) 400, that is, determining the user's risk level based on user data from multiple institutions.

[0050] The server 400 includes a trusted unit, which can be any computing unit capable of processing private or confidential data and protecting data from leakage. The trusted unit may include, for example, a Trusted Execution Environment (TEE) or a computing device in a trusted organization. Figure 1 The example shown is of TEE40 as a trusted unit, and the following description uses TEE40 as an example of a trusted unit. Each organization's equipment can send de-identified and encrypted user data to server 400, which then stores the user data locally or on a file storage server. Figure 1 (Not shown in the image). TEE40 can receive the address where user data is stored from server 400, retrieve user data from that address, aggregate user data from multiple institutions, and determine the user's risk level based on the aggregated user data. Server 400 and TEE40 can be connected to blockchain 500, and the user risk level determination scheme in the embodiments of this specification can be implemented in conjunction with blockchain 500.

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

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

[0053] In institution A corresponding to institution device 100, the institution administrator can periodically generate an initial data file F1 through institution device 100. File F1 includes user data of each user within institution A, which can be used for joint model prediction together with user data from other institutions. It is understood that although the data is presented in file form, this embodiment is not limited to this; for example, data or information can also be presented in text or table form, and there is no limitation on this. File F1 includes the identity information and user data of each user in institution A. The identity information includes, for example, name, and ID number. The user data includes, for example, user registration data, historical transaction data, historical transfer data, historical operation data, and user risk tags. This user data may be in vector form, where each element of the vector corresponds to a user feature. Specifically, file F1 may include multiple lines, each line in the form: “name / certType / certNum / data”, where name is the user's name, certType is the ID type, certNum is the ID number, these three constitute the three elements of user identity information, and data represents the user's user data.

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

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

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

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

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

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

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

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

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

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

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

[0065] In step S211, the device 100 writes the user ID and user data into the de-identified data file F2.

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

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

[0068] In one implementation, after generating file F2 as described above, the client can sort the lines in file F2 in ascending order according to each user ID, so as to facilitate the subsequent summary processing of de-identified data files from multiple organizations.

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

[0070] TEE (Trusted Execution Environment) is a secure extension of CPU hardware, completely isolated from the outside world. Currently, the industry is paying close attention to TEE solutions, and almost all mainstream chip and software alliances have their own TEE solutions. Examples include software-based TPM (Trusted Platform Module) and hardware-based Intel SGX (Software Guard Extensions), ARM Trustzone, and AMD PSP (Platform Security Processor). TEE acts as a hardware black box; the code and data executed within it cannot be viewed even at the operating system level. Operations can only be performed through predefined interfaces in the code. In terms of efficiency, due to the black-box nature of TEE, the computations performed within it are on plaintext data, rather than the complex cryptographic operations of homomorphic encryption, resulting in almost no loss of efficiency.

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

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

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

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

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

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

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

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

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

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

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

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

[0083] After the organization's authentication is successful, the server can execute 400 responses. Figure 4 The method for determining user risk levels is shown.

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

[0085] Server 400 can periodically receive encrypted data files (including file F3) from various institutions for joint model prediction. Specifically, taking institution device 100 as an example, institution device 100 can use the private key of institution A's DID to sign file F3, and send institution A's DID (e.g., DIDa), file F3, and the signature of file F3 using the private key of DIDa to server 400.

[0086] In step S403, server 400 provides TEE with the encrypted data file (including file F3) corresponding to each organization's DID and the organization's public key.

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

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

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

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

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

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

[0093] In step S407, the TEE generates a summary file F4.

[0094] Specifically, after obtaining the encrypted data files of each organization, the TEE uses its own private key to decrypt each encrypted file, thereby obtaining the de-identified data files of each organization (including the aforementioned de-identified data file F2). Then, the TEE generates a summary file F4 based on the de-identified data files of each organization. This summary file F4 includes multiple lines, each corresponding to all users included in the multiple organizations. Each line includes a user ID, a user data set, and an organization set. The user data set is obtained from multiple de-identified data files, and the organization set includes the organization identifiers of the organizations that provided the user data.

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

[0096] When summarizing multiple de-identified data files in TEE, such as Figure 5 As shown, each de-identified data file is first indicated by a pointer to the smallest user ID. Figure 5 Among the user IDs indicated by pointers in the three de-identified data files, the user IDs of organization A and organization B are the smallest. Therefore, in Figure 5 The first line of the summary file shown below contains ID1{data1, data5}{DIDa, DIDb}, meaning that {data1, data5} is a collection of user data for ID1 from multiple anonymized data files.

[0097] {DIDa, DIDb} is a set of organization identifiers for the organizations that provide user data in the user data set.

[0098] After recording the information corresponding to ID1 in the summary file, the pointers are moved to the next line in the de-identified data files of Organization A and Organization B, and the above process is repeated. Specifically, after determining that the smallest ID pointed to by the three pointers is ID2 in the TEE, the information corresponding to ID2, "ID2{data6,data9}{DIDb,DIDc}", is recorded in the second line of the summary file. Through the same process described above, after traversing all lines in each de-identified data file using pointers, the following can be obtained: Figure 5 The summary file F4 shown below.

[0099] In step S409, the TEE determines the user's risk level based on the summary file F4.

[0100] The TEE (Traffic Execution Environment) includes a pre-defined algorithm or model for determining a user's risk level. The TEE can input user data sets from the summary file F4 into the model, causing the model to output the user's risk level. In this way, the TEE uses joint model prediction based on aggregated user data from multiple institutions to more accurately determine a user's risk level.

[0101] In step S411, the TEE generates a result file F5 corresponding to the mechanism.

[0102] TEE can generate prediction result files corresponding to each institution based on file F4. For example, taking institution A as an example, for user ID1 in file F4, after TEE outputs the risk level level1 of user ID1 through the model, when it is determined that the institution identifier set of ID1 includes the identifier DIDa of institution A, it records in the first line of the pre-created result file F5 corresponding to institution A: User ID1: level1. After TEE outputs the risk level level2 of user ID3 through the model, when it is determined that the institution identifier set of ID3 includes the identifier DIDa of institution A, it records in the second line of result file F5: User ID3: level2. TEE can generate result files corresponding to other institutions in the same way. After traversing file F4 as described above, TEE can complete the result files corresponding to each institution.

[0103] In step S413, the TEE uses the public key of organization A to encrypt the result file F5, resulting in the ciphertext result file F6.

[0104] The TEE encrypts file F5 using institution A's public key to obtain ciphertext file F6, preventing server 400 from reading the risk level corresponding to the user ID in file F5, thus further protecting user privacy. It can be understood that the TEE is not limited to using institution A's public key to encrypt file F5, but can use other keys (symmetric or asymmetric keys) negotiated with institution A to encrypt file F5.

[0105] In step S415, the TEE provides the encrypted result file F6 to the server 400.

[0106] Specifically, the TEE stores file F6 outside the TEE (i.e., the EPC mentioned above) and sends the storage address to the server, so that the server 400 can read file F6.

[0107] In step S417, the server sends file F6 to mechanism device 100 of mechanism A.

[0108] In step S419, the mechanism device 100 uses the private key of mechanism A to decrypt file F6 and obtain file F5.

[0109] In step S421, the mechanism device 100 replaces the user ID in file F5 with user identity information to obtain file F7.

[0110] Specifically, the institutional device 100 can read the user identity information corresponding to each user ID in file F5 from the aforementioned stored mapping table of user identity information and user IDs, and replace the user IDs in file F5 with the user identity information, thereby generating file F7. The institutional device 100 can then perform business processing based on the risk level of each user in file F7, thereby improving risk control of business operations.

[0111] In the embodiments described in this specification, by combining the server and TEE to perform joint model prediction on user data from various institutions, a more comprehensive risk assessment of users can be achieved, improving the level of risk control. Simultaneously, by de-identifying and encrypting user data through institutional devices before sending it to the server, and then providing the de-identified and encrypted user data to the TEE, user privacy is protected. Furthermore, the TEE only needs to interact with the server and not with the individual institutional devices; therefore, only a simple application needs to be configured within the TEE, saving on its computational and storage resources.

[0112] Figure 6 This is a schematic diagram of a system according to another embodiment of this specification. Figure 6 As shown, institutional devices 100, 200, and 300 can directly connect to TEE40, sending their anonymized and encrypted user data to TEE40. TEE40 can then aggregate user data from multiple institutions, determining the user's risk level based on the aggregated data. TEE40 can also directly connect to blockchain 500, enabling the user risk level determination scheme in this embodiment to be implemented using blockchain 500.

[0113] In this embodiment, when generating file F3, each mechanism or device can request the user's ID from the TEE, or calculate the user's ID itself according to a pre-agreed algorithm, thereby generating file F3.

[0114] In addition, after the TEE is connected to the mechanical equipment, it can execute... Figure 3 The steps performed by the server verify the identity of the organization corresponding to the equipment. When verifying the identity of an organization, the TEE can obtain the public key of the organization's DID and store the public keys of each organization.

[0115] After TEE40 verifies the identity of the organization, it can perform... Figure 7The method for determining user risk levels is shown.

[0116] like Figure 7 As shown, firstly, in step S701, the mechanism device 100 sends the encrypted data file F3 to the TEE40.

[0117] Specifically, taking the organization device 100 as an example, the organization device 100 can use its own private key to sign the file F3, and send the organization device 100's DID (e.g., DIDa), the file F3, and the signature of the file F3 by the private key through DIDa to the TEE40.

[0118] In step S703, TEE40 can generate a summary file F4 based on the encrypted data files of each organization.

[0119] Specifically, after obtaining the encrypted data files from each organization, the TEE uses its own private key to decrypt each encrypted file, thereby obtaining the de-identified data files from each organization (including the aforementioned de-identified data file F2). Then, the TEE can generate a summary file F4 based on the de-identified data files from each organization. The specific process can be found in the description of step S407 above, and will not be repeated here.

[0120] In step S705, the TEE determines the user's risk level based on the summary file F4.

[0121] The TEE (Traffic Execution Environment) includes a pre-defined algorithm or model for determining a user's risk level. The TEE can input data from each user in the summary file F4 into the model, causing the model to output the user's risk level. In this way, the TEE uses joint model prediction based on user data from multiple institutions to more accurately determine a user's risk level.

[0122] In step S707, the TEE generates a result file F5 corresponding to the mechanism.

[0123] TEE can generate prediction result files corresponding to each institution based on file F4. For example, taking institution A as an example, for user ID1 in file F4, after TEE outputs the risk level level1 of user ID1 through the model, when it is determined that the institution identifier set of ID1 includes the identifier DIDa of institution A, it records in the first line of the pre-created result file F5 corresponding to institution A: User ID1: level1. After TEE outputs the risk level level2 of user ID3 through the model, when it is determined that the institution identifier set of ID3 includes the identifier DIDa of institution A, it records in the second line of result file F5: User ID3: level2. TEE can generate result files corresponding to other institutions in the same way. After traversing file F4 as described above, TEE can complete the result files corresponding to each institution.

[0124] In step S709, the TEE uses the public key of organization A to encrypt the result file F5, resulting in the ciphertext result file F6.

[0125] The TEE encrypts file F5 using organization A's public key, preventing server 400 from reading the risk level corresponding to the user ID in file F5, thus further protecting user privacy. It can be understood that the TEE is not limited to using organization A's public key to encrypt file F5, but can use other keys (symmetric or asymmetric keys) negotiated with organization A to encrypt file F5.

[0126] In step S711, the TEE provides file F6 to the mechanism device 100.

[0127] Specifically, the TEE stores file F6 outside the TEE (i.e., the EPC mentioned above) and sends the storage address to the mechanism device 100, so that the mechanism device 100 can read file F6.

[0128] In step S713, the mechanism device 100 uses the private key of mechanism A to decrypt file F6 and obtain file F5.

[0129] In step S715, the mechanism device 100 replaces the user ID in file F5 with user identity information to obtain file F7.

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

[0131] In the embodiments described in this specification, by using TEE to perform joint model prediction on user data from various institutions, a more comprehensive risk assessment of users can be conducted, thereby improving the level of risk control.

[0132] Figure 8 This is an architectural diagram of a trusted unit in an embodiment of this specification, the trusted unit being used to perform, for example... Figure 2 , Figure 3 , Figure 4 or Figure 7 The method shown includes:

[0133] The receiving unit 81 is used to receive encrypted user data of the mechanism to which each structural device belongs from multiple mechanism devices;

[0134] The decryption unit 82 is used to decrypt the multiple encrypted user data respectively to obtain multiple datasets. The datasets include user identifiers of multiple users in the organization corresponding to the user dataset and data corresponding to the user identifiers.

[0135] Generation unit 83 is used to generate summary data for each user based on the multiple datasets;

[0136] Unit 84 is used to determine the risk level of each user based on the aggregated data of each user.

[0137] The generation unit 83 is also used to generate prediction result data corresponding to each institution. The prediction result data includes user identifiers of multiple users in the institution corresponding to the prediction result data and the risk level corresponding to the user identifiers.

[0138] Encryption unit 85 is used to encrypt multiple prediction result data to obtain multiple ciphertext result data;

[0139] The providing unit 86 is used to provide the encrypted result data to the respective institutional devices.

[0140] This specification also provides a computer-readable storage medium storing a computer program thereon, which, when executed in a computer, causes the computer to perform actions such as... Figure 2 , Figure 3 , Figure 4 or Figure 7 The method shown.

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

[0142] This specification also provides a server, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements... Figure 2 , Figure 3 or Figure 4 The method shown.

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

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

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

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

[0147] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

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

[0149] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0150] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0152] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0153] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0154] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0155] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0156] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

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

Claims

1. A method for determining user risk level, comprising: Multiple organizations send their encrypted user data to a trusted unit for privacy data processing; The trusted unit decrypts the multiple encrypted user data respectively to obtain multiple datasets. Each dataset includes user identifiers of multiple users in the organization corresponding to the dataset and data corresponding to the user identifiers. Generate summary data for each user based on the multiple datasets; determine the risk level for each user based on the summary data for each user. Generate prediction result data corresponding to each institution. The prediction result data includes user identifiers of multiple users in the institution corresponding to the prediction result data and the risk level corresponding to the user identifiers. The multiple prediction result data are encrypted to obtain multiple ciphertext result data; each of the ciphertext result data is provided to the respective institutions and devices; Each institution and device decrypts the encrypted result data to obtain the prediction result data of each institution.

2. The method according to claim 1, wherein multiple institutional devices send their respective encrypted user data to a trusted unit for privacy data processing, comprising: Multiple institutions send their encrypted user data to a server, which then provides the encrypted user data to a trusted unit. The trusted unit provides each of the encrypted result data to each institution and device by providing each of the encrypted result data to each institution and device via the server.

3. The method according to claim 2, further comprising: The server provides the public keys of multiple institutions to the trusted unit, and the trusted unit encrypts the multiple prediction result data by using the public keys of each institution to encrypt the prediction result data corresponding to each institution.

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

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

6. The method according to claim 3, wherein the user's aggregated data includes the user's user identifier, user data set, and organization identifier set, wherein, The user data set includes data obtained from the multiple datasets based on the user's user identifier, and the organization identifier set includes organization identifiers of the organizations that provide the user's data; The generated prediction result data corresponding to each institution includes: In cases where the first user's aggregated data determines that the first user's corresponding institution identifier set includes the first institution's institution identifier, the first user's user identifier and the first user's risk level are added to the prediction result data corresponding to the first institution.

7. The method according to claim 3, further comprising: After obtaining the public keys of each organization from the server, the trusted unit stores the public keys of the multiple organizations in the blockchain.

8. The method according to claim 5, further comprising: After obtaining the prediction result data, each institution and device generates second prediction result data based on the pre-stored correspondence between the user's user identifier and one or more pieces of information about the user. The second prediction result data includes one or more pieces of information about the user and the user's risk level.

9. The method according to claim 2, further comprising: After receiving the encrypted user data from the multiple institutional devices, the server stores the encrypted user data of each institution. The server provides the encrypted user data to the trusted unit by sending the storage address of each encrypted user data to the trusted unit.

10. The method according to claim 6, wherein multiple institutional devices send their encrypted user data to the server, further comprising: Multiple institutions send their respective institution's DID and encrypted user data to a server. The institution identifier set includes a set of institution DIDs, and the public key of the multiple institutions is the public key of the multiple institutions' DIDs. The method further includes: the server obtaining the public key of the multiple institutions' DIDs from the blockchain.

11. A method for determining a user risk level, executed by a trusted unit, comprising: Receive encrypted user data from multiple institutions and devices, each belonging to its respective institution; The multiple encrypted user data are decrypted to obtain multiple datasets, each dataset including user identifiers of multiple users in the organization corresponding to the dataset and data corresponding to the user identifiers; Generate summary data for each user based on the multiple datasets; The risk level of each user is determined based on the aggregated data of each user. Generate prediction result data corresponding to each institution. The prediction result data includes user identifiers of multiple users in the institution corresponding to the prediction result data and the risk level corresponding to the user identifiers. Encrypt multiple prediction result data to obtain multiple ciphertext result data; The encrypted result data is provided to each institution and device.

12. A user risk level determination system, comprising multiple institutional devices and trusted units, The plurality of institutional devices are used to send encrypted user data of their respective institutions to the trusted unit; The trusted unit is used to: decrypt the plurality of encrypted user data respectively to obtain a plurality of datasets, wherein the datasets include user identifiers of a plurality of users in the institution corresponding to the dataset and data corresponding to the user identifiers; Generate summary data for each user based on the multiple datasets; determine the risk level for each user based on the summary data for each user. Generate prediction result data corresponding to each institution. The prediction result data includes user identifiers of multiple users in the institution corresponding to the prediction result data and the risk level corresponding to the user identifiers. The multiple prediction result data are encrypted to obtain multiple ciphertext result data; each of the ciphertext result data is provided to the respective institutions and devices; Each mechanism and device is also used to decrypt the encrypted result data to obtain the prediction result data of each mechanism.

13. The system according to claim 12 further includes a server. The server is configured to: receive encrypted user data from the plurality of institutional devices, and provide the encrypted user data to a trusted unit; obtain encrypted result data from the trusted unit and provide the encrypted result data to the respective institutional devices.

14. A trusted unit, comprising: The receiving unit is used to receive encrypted user data from multiple mechanisms and devices, each belonging to a specific mechanism or device. The decryption unit is used to decrypt the multiple encrypted user data respectively to obtain multiple datasets, wherein the datasets include user identifiers of multiple users in the institution corresponding to the dataset and data corresponding to the user identifiers; A generation unit is used to generate summary data for each user based on the multiple datasets; The determination unit is used to determine the risk level of each user based on the aggregated data of each user. The generation unit is also used to generate prediction result data corresponding to each institution. The prediction result data includes user identifiers of multiple users in the institution corresponding to the prediction result data and the risk level corresponding to the user identifiers. An encryption unit is used to encrypt multiple prediction result data to obtain multiple ciphertext result data; A providing unit is used to provide the encrypted result data to the respective institutional devices.

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

Images