Credit investigation data processing method and device based on alliance chain and server

Abstract

The invention provides a credit investigation data processing method and device based on an alliance chain and a server, and can be applied to the field of block chains. Based on the method, before specific implementation, an alliance chain and an intelligent contract technology can be used in a combined manner, a supervision server of a supervision mechanism is introduced, and a corresponding credit investigation data management system is constructed. In specific implementation, a node server receives and responds to a target query request for credit investigation data of a target user, calls an intelligent contract, determines a role type of a querier according to an identity label of the querier, and obtains a matched target query rule based on the role type of the querier; calling the smart contract to interact with the supervision server according to the target query rule; in response to the target query request, querying the alliance chain based on the target hash value to obtain ciphertext data of a target query result; according to the target query rule, a target query result is touched to the terminal equipment; and storing a corresponding access operation record in the smart contract. Therefore, the data privacy security of the credit investigation data of the user can be effectively protected.

Description

Technical Field

[0001] This specification belongs to the field of blockchain technology, and in particular to a credit data processing method, device and server based on a consortium chain. Background Art

[0002] A user's credit data is an important data used to objectively evaluate the credit status of users (including individuals and enterprises), and this data is needed in many business scenarios.

[0003] Usually, the credit data of users will involve their privacy information. However, in the process of querying and using the credit data of users based on the existing methods, there are often illegal operations such as unauthorized query of the credit data of users and leakage of the credit data of users, which makes it impossible to effectively protect the privacy security of the credit data of users.

[0004] To address the above problems, no effective solution has been proposed yet. Summary of the invention

[0005] This specification provides a credit data processing method, device and server based on an alliance chain, which can effectively protect the data privacy and security of user credit data during the data processing process involving credit data.

[0006] This specification provides a credit data processing method based on a consortium chain, which is applied to a node server in a credit data management system. The credit data management system is constructed based on the consortium chain, and the credit data management system is deployed with a corresponding smart contract. The method includes:

[0007] Receiving a target query request for the credit data of a target user initiated by a terminal device; wherein the target query request carries at least a target hash value corresponding to the credit data of the target user to be queried, and an identity identifier of the queryer;

[0008] Call the smart contract to determine the role type of the inquirer based on the inquirer's identity; and obtain the target query rule that matches the target query request based on the inquirer's role type;

[0009] Call the smart contract to interact with the regulatory server according to the target query rules; and respond to the target query request, query the alliance chain based on the target hash value, and obtain the corresponding ciphertext data of the target query result; wherein the regulatory server is deployed on the regulatory agency side;

[0010] According to the target query rules, the target query results are delivered to the terminal device; and the corresponding access operation records are saved in the smart contract; wherein the access operation records are at least associated with the target hash value.

[0011] In one embodiment, the role type of the inquirer includes at least one of the following: target user, other user authorized by the target user, other institution authorized by the target user, third-party institution, and regulatory agency.

[0012] In one embodiment, when the role type of the queryer is another user authorized by the target user, the smart contract is called to interact with the supervision server according to the target query rule; and in response to the target query request, the alliance chain is queried based on the target hash value to obtain the corresponding ciphertext data of the target query result, including:

[0013] Call the smart contract to detect whether the target query request carries the authorization certificate according to the target query rules;

[0014] When it is determined that the target query request carries the authorization certificate, a target verification request is sent to the supervision server; wherein the target verification request carries at least the authorization certificate; the supervision server holds at least the backup private key of the target user; the supervision server uses the backup private key of the target user to verify the authenticity of the authorization certificate;

[0015] Receive verification results fed back by the regulatory server;

[0016] According to the verification result, when it is determined that the authorization credential has been verified, the inquirer's identity information is interacted with the supervision server to query and register the inquirer's identity information according to the inquirer's identity identification;

[0017] Call the smart contract to query the alliance chain based on the target hash value to obtain the corresponding ciphertext data of the target query result.

[0018] In one embodiment, according to the target query rule, the target query result is delivered to the terminal device, including:

[0019] Generate a target decryption request for the ciphertext data of the target query result according to the target query rule; wherein the target decryption request carries at least the ciphertext data of the target query result and the authorization credential of the target user;

[0020] Sending the target decryption request to the supervision server; wherein the supervision server responds to the target decryption request and uses the corresponding backup private key to decrypt the ciphertext data of the target query result to obtain the plaintext data of the target query result;

[0021] Receive the plaintext data of the target query result fed back by the supervision server;

[0022] According to the target query rules, the plaintext data of the target query results is sent to the terminal device through the corresponding secure data transmission channel.

[0023] In one embodiment, when the role type of the queryer is a third-party institution, the smart contract is called to interact with the regulatory server according to the target query rule; and in response to the target query request, the alliance chain is queried based on the target hash value to obtain the corresponding ciphertext data of the target query result, including:

[0024] Call the smart contract to detect whether the target query request carries the institution certificate of a third-party institution according to the target query rules;

[0025] In the case where it is determined that the target query request carries an institution certificate, determining whether the institution certificate is valid through the supervision server;

[0026] When it is determined that the institution's credentials are valid, the institution information database is queried through the regulatory server to determine the authority parameters of the third-party institution;

[0027] Call the smart contract to query the alliance chain based on the target hash value and the permission parameters of the third-party agency to obtain the corresponding ciphertext data of the target query result.

[0028] In one embodiment, the target query request also carries a usage purpose parameter related to the target query result. Accordingly, according to the target query rule, the target query result is delivered to the terminal device, including:

[0029] According to the target query rule, when the queryer's purpose of using the target query result does not involve the plaintext data of the target query result based on the purpose parameter, determine the operation call link of the matching homomorphic encryption operation module according to the purpose parameter;

[0030] The ciphertext data of the target query result and the operation call link are sent to the terminal device; wherein the terminal device calls a matching homomorphic encryption operation module according to the operation call link, and uses the homomorphic encryption operation module to perform a homomorphic encryption operation using the ciphertext data of the target query result in a ciphertext state to obtain the target operation result.

[0031] In one embodiment, the target query request further includes an attribute indication parameter; wherein the attribute indication parameter corresponds to at least one attribute data in the credit data of the target user.

[0032] In one embodiment, the method further comprises:

[0033] At every preset time period, the regulatory server queries the smart contract to obtain the access operation records of the current time period;

[0034] The supervision server detects whether the inquirer has any risk of illegal operation in the process of inquiring the user's credit data based on the access operation records in the current time period;

[0035] When it is determined that there is a risk of illegal operation, the supervision server determines the risk inquirer based on the access operation records in the current time period; and generates a risk tag for the risk inquirer.

[0036] In one embodiment, after generating the risk mark for the risk inquirer, the method further includes:

[0037] The supervision server detects whether the cumulative number of risk tags of the risk inquirer is greater than a preset risk tag number threshold;

[0038] When it is determined that the cumulative number of risk marks of the risk inquirer is greater than a preset risk mark number threshold, the supervision server adds the identity of the risk inquirer to the supervision blacklist.

[0039] In one embodiment, after receiving a target query request for credit information data of a target user initiated by a terminal device, the method further includes:

[0040] Obtain the identity of the queryer in the target query request;

[0041] Check whether the identity of the inquirer hits the regulatory blacklist;

[0042] When it is determined that the identity of the inquirer hits the regulatory blacklist, an error message is generated to reject the query.

[0043] In one embodiment, the method further comprises:

[0044] Receive a credit data upload request initiated by a data collection terminal; wherein the credit data upload request carries at least updated data of the credit data of multiple users in the current time period;

[0045] The request for uploading the credit data to the chain is sent to the supervision server; wherein the supervision server is deployed with a preset anomaly detection model; the supervision server uses the preset anomaly detection model to process the updated data of the credit data of multiple users in the current time period and the updated data of the credit data of multiple users in the historical time period, and detects whether the updated data of the credit data of multiple users has abnormal risks; and when it is determined that there is no abnormal risk, feedbacks a confirmation instruction that the detection has passed;

[0046] Receive and respond to confirmation instructions, and according to the preset chain rules, add the updated credit data of multiple users in the current time period to the corresponding block of the alliance chain.

[0047] This specification also provides a credit data processing device based on the alliance chain, which is applied to a node server in a credit data management system. The credit data management system is constructed based on the alliance chain. The credit data management system is deployed with a corresponding smart contract. The device includes:

[0048] A receiving module, configured to receive a target query request for the credit data of a target user initiated by a terminal device; wherein the target query request carries at least a target hash value corresponding to the credit data of the target user to be queried, and an identity identifier of the queryer;

[0049] A determination module is used to call a smart contract to determine the role type of the inquirer according to the identity of the inquirer; and obtain a target query rule that matches the target query request according to the role type of the inquirer;

[0050] The query module is used to call the smart contract to interact with the regulatory server according to the target query rules; and respond to the target query request, query the alliance chain based on the target hash value, and obtain the corresponding ciphertext data of the target query result; wherein the regulatory server is deployed on the regulatory agency side;

[0051] A processing module is used to reach the target query result to the terminal device according to the target query rule; and save the corresponding access operation record in the smart contract; wherein the access operation record is at least associated with the target hash value.

[0052] This specification also provides a server, including a processor and a memory for storing processor executable instructions, and the processor implements the steps of the credit data processing method based on the alliance chain when executing the instructions.

[0053] This specification also provides a computer-readable storage medium on which computer instructions are stored. When the instructions are executed by a processor, the relevant steps of the credit data processing method based on the alliance chain are implemented.

[0054] This specification also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the credit data processing method based on the alliance chain are implemented.

[0055] Based on the credit data processing method, device and server based on the alliance chain provided in this specification, before specific implementation, the alliance chain and smart contract technology can be used together, and the regulatory server of the regulatory agency can be introduced to build a credit data management system adapted to the credit data management usage scenario. In specific implementation, when the inquirer needs to query the credit data of the target user, the terminal device can be used to send a target query request carrying at least the target hash value corresponding to the credit data of the target user and the identity of the inquirer to the node server in the credit data management system. The node server receives and responds to the target query request, calls the smart contract according to the identity of the inquirer, determines and obtains the matching target query rules based on the role type of the inquirer; then calls the smart contract according to the target query rules, interacts with the regulatory server; and responds to the target query request, queries the alliance chain based on the target hash value, and obtains the ciphertext data of the target query result; according to the target query rules, the target query result is reached to the terminal device; and the corresponding access operation record is saved in the smart contract. In this way, the advantages and characteristics of the alliance chain and the smart contract can be fully utilized, and the characteristics of the regulatory server of the regulatory agency can be introduced and utilized to effectively protect the data privacy security of the user's credit data in the data processing process involving credit data. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the embodiments of this specification, the drawings required for use in the embodiments will be briefly introduced below. 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 work.

[0057] Figure 1 It is a flowchart of a credit data processing method based on a consortium chain provided by an embodiment of this specification;

[0058] Figure 2 It is a schematic diagram of an embodiment of a credit investigation data processing method based on a consortium chain provided in an embodiment of this specification, in a scenario example;

[0059] Figure 3 It is a schematic diagram of an embodiment of a credit investigation data processing method based on a consortium chain provided in an embodiment of this specification, in a scenario example;

[0060] Figure 4 It is a schematic diagram of an embodiment of a credit investigation data processing method based on a consortium chain provided in an embodiment of this specification, in a scenario example;

[0061] Figure 5 It is a schematic diagram of an embodiment of a credit investigation data processing method based on a consortium chain provided in an embodiment of this specification, in a scenario example;

[0062] Figure 6 It is a schematic diagram of an embodiment of a credit investigation data processing method based on a consortium chain provided in an embodiment of this specification, in a scenario example;

[0063] Figure 7 It is a schematic diagram of an embodiment of a credit investigation data processing method based on a consortium chain provided in an embodiment of this specification, in a scenario example;

[0064] Figure 8 It is a schematic diagram of the structure of a server provided by an embodiment of this specification;

[0065] Fig. 9 It is a schematic diagram of the structure of a credit investigation data processing device based on a consortium chain provided by an embodiment of this specification;

[0066] Fig.10 It is a schematic diagram of an embodiment of a credit investigation data processing method based on a consortium chain provided in an embodiment of this specification, in a scenario example;

[0067] Fig.11 This is a schematic diagram of an embodiment of a credit data processing method based on an alliance chain provided in an embodiment of this specification, in a scenario example. DETAILED DESCRIPTION

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

[0069] It should be noted that the user-related information and data involved in the embodiments of this specification are all information and data authorized by the user or fully authorized by relevant parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with relevant laws, regulations and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users or relevant parties to choose to authorize or refuse.

[0070] It should also be noted that in the embodiments of this specification, certain software, components, models and other existing solutions in the industry may be mentioned. They should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of this application, but it does not mean that the applicant has or will necessarily use the solution.

[0071] See also Figure 1 As shown, the embodiment of this specification provides a credit data processing method based on the alliance chain. Among them, the method is specifically applied to the node server side in the credit data management system, the credit data management system is constructed based on the alliance chain, and the credit data management system is deployed with a corresponding smart contract. In specific implementation, the method may include the following contents:

[0072] S101: receiving a target query request for credit data of a target user initiated by a terminal device; wherein the target query request carries at least a target hash value corresponding to the credit data of the target user to be queried, and an identity identifier of the queryer;

[0073] S102: calling the smart contract to determine the role type of the inquirer according to the identity of the inquirer; and obtaining a target query rule matching the target query request according to the role type of the inquirer;

[0074] S103: calling the smart contract to interact with the regulatory server according to the target query rules; and responding to the target query request, querying the alliance chain based on the target hash value, and obtaining the corresponding ciphertext data of the target query result; wherein the regulatory server is deployed on the regulatory agency side;

[0075] S104: According to the target query rule, the target query result is delivered to the terminal device; and the corresponding access operation record is saved in the smart contract; wherein the access operation record is at least associated with the target hash value.

[0076] The above-mentioned target users may specifically include individual users or corporate users.

[0077] Correspondingly, the credit data of the target user may specifically include a variety of different types of attribute data.

[0078] Specifically, when the target user is an individual user, the credit data of the target user may include at least one of the following: salary data, consumption data, credit data, mortgage data, etc.

[0079] In the case where the target user is a corporate user, the credit data of the target user may include at least one of the following: revenue data, expenditure data, dividend data, tax payment data, etc.

[0080] In addition, the credit data of the target user may also include credit evaluation results of the target user by a credible credit evaluation agency based on the credit data of the target user.

[0081] Of course, it should be noted that the credit data of the target user listed above is only a schematic illustration. In specific implementation, according to specific circumstances and processing requirements, the credit data of the target user may also include other content and other types of data. This specification does not limit this.

[0082] The above target query rules are specifically understood as query rules that match the role type of the inquirer and comply with the authority scope of the inquirer.

[0083] Based on the above embodiments, it is possible to fully utilize the advantages of alliance chains and smart contracts, introduce and utilize the characteristics of the regulatory agency's regulatory server, better adapt to credit data management usage scenarios, and effectively protect the data privacy security of user credit data during the data processing process involving credit data.

[0084] In some embodiments, the above-mentioned credit data management system can be specifically understood as a data processing system built on a consortium chain for collecting, organizing, using and supervising users' credit data.

[0085] Among them, the above-mentioned alliance chain can be specifically understood as a distributed ledger technology, which is a type of blockchain. It has the following characteristics: 1) Data immutability. The data in the alliance chain is linked together in the form of blocks and encrypted and connected through cryptographic hash functions. Once the data is written into the blockchain, it is difficult to change or delete, so it is immutable. 2) The data on the chain is open and transparent between alliance nodes. Any node participating in the alliance chain can obtain the full data of the blockchain. This feature is conducive to solving the problem of data islands. All institutions that deploy alliance chain nodes can share data. 3) Decentralization. The alliance chain is a decentralized technology without a centralized control agency. The data is stored on multiple nodes in the network, and the consensus algorithm is used to manage and maintain the consistency of the network.

[0086] Furthermore, the above-mentioned credit data management system is deployed with corresponding smart contracts and includes multiple node servers.

[0087] Among them, the above-mentioned smart contract can be specifically understood as an automated contract running on the blockchain, which has the following characteristics: 1) Automated execution. Smart contracts are stored in the form of code on the alliance chain. Once the preset conditions are met, they can be automatically executed without human intervention. 2) Immutability. Once the smart contract is deployed on the alliance chain, their code and execution results are immutable and cannot be modified or deleted, so they have a high degree of credibility and reliability. 3) Transparent and verifiable. Smart contracts on the alliance chain are publicly visible. Anyone can view the code and execution results of the contract, thereby improving the transparency and verifiability of the contract. 4) De-trust. Smart contracts make it possible to conduct transactions and cooperation in an untrusted environment, because the execution of the contract is verified and confirmed by the consensus algorithm on the blockchain network without relying on trusted middlemen.

[0088] Specifically, the above-mentioned smart contract can save the protocol rules and related codes regarding the credit data management system.

[0089] In specific implementation, based on the above-mentioned credit data management system, the user's credit data can be saved in the block of the alliance chain, and the access operation records of the user's credit data can be saved in the smart contract.

[0090] Among them, the credit data of the above-mentioned user can be specifically stored in the form of ciphertext based on the homomorphic encryption algorithm in a block associated with the target hash value on the alliance chain.

[0091] The above-mentioned homomorphic encryption algorithm can be specifically understood as a special encryption algorithm, based on which operations can be performed in ciphertext form in an encrypted state without decrypting the data. This means that operations can be performed without exposing the true content of the data, thereby effectively protecting the user's data privacy.

[0092] Based on the homomorphic encryption algorithm, corresponding public and private keys are usually generated. The public key can be made public, while the private key can be held by the user alone.

[0093] Specifically, the homomorphic encryption algorithm used may be a double trapdoor homomorphic encryption algorithm.

[0094] In specific implementation, the target user's credit data can be encrypted using a public key generated based on a homomorphic encryption algorithm to obtain the corresponding ciphertext data of the target user's credit data; and the ciphertext data of the target user's credit data is stored on the alliance chain. The target user can hold a corresponding private key that can be decrypted (which can be recorded as the user's private key); at the same time, a trusted regulatory agency can obtain and keep a backup of the private key (which can be recorded as a backup private key).

[0095] In the credit data management scenario, the joint use of alliance chain and smart contracts can better collect and save users' credit data, making it impossible for credit data to be tampered with at will; at the same time, it can also record the access operation records of different inquirers to credit data, ensure that access to credit data is traceable, and save the time, content and purpose of the access to the alliance chain for subsequent retrospective inquiries by regulatory agencies.

[0096] The node server may specifically include a background server applied to the credit data management system side, which can realize data transmission, data processing and other functions. Specifically, the node server may be, for example, an electronic device with data calculation, storage and network interaction functions. Alternatively, the node server may also be a software program running in the electronic device to provide support for data processing, storage and network interaction. In this embodiment, the number of the node servers is not specifically limited. The node server may specifically be one server, or several servers, or a server cluster formed by several servers.

[0097] In some embodiments, during specific implementation, when the inquirer wants to inquire or use the credit data of the target user, a terminal device can be used to initiate a target query request for the credit data of the target user to the credit data management system.

[0098] The terminal device may include a front-end device applied to the inquirer side and capable of realizing functions such as data collection and data transmission. Specifically, the terminal device may be, for example, a desktop computer, a tablet computer, a laptop computer, a smart phone or other electronic device.

[0099] Specifically, the target query request at least carries a target hash value corresponding to the credit data of the target user to be queried, and the identity of the inquirer.

[0100] The target hash value may be data calculated using a hash function based on the identity information of the target user and corresponding to the target user. The credit data of the target user stored in the credit data management system and the access operation record of the credit data of the target user may be associated with the target hash value.

[0101] The above-mentioned identity identifier can be specifically understood as identification information used to indicate the identity of the inquirer, for example, the inquirer's account name, the inquirer's ID information, the inquirer's IP address, etc.

[0102] In some embodiments, after receiving a target query request, the node server in the credit data management system may first parse the target query request and extract the identity of the inquirer; then call the smart contract to determine the role type of the inquirer based on the identity of the inquirer; and obtain the target query rules that match the target query request based on the role type of the inquirer.

[0103] Among them, the above-mentioned smart contract can also be configured with a role-based access control (RBAC) permission data set.

[0104] Specifically, the above-mentioned role access control permission data set may include a role type mapping relationship table and a plurality of preset processing rules corresponding to a plurality of role types, wherein each preset processing rule is obtained according to the permission parameter configuration of the corresponding role type, and each preset processing rule matches the permission of the corresponding role type.

[0105] In specific implementation, the node server can first call the smart contract to query the role type mapping relationship table according to the identity identifier of the inquirer, and determine the role type corresponding to the identity identifier of the inquirer as the role type of the inquirer; then, according to the role type of the inquirer, determine the corresponding preset processing rule from the multiple preset processing rules contained in the role access control permission data set as the target processing rule that matches the target query request; obtain the rules related to the query business from the target processing rules to obtain the target query rules.

[0106] In some embodiments, the role type of the inquirer may specifically include at least one of the following: a target user, another user authorized by the target user, another institution authorized by the target user, a third-party institution, and a regulatory agency.

[0107] Among them, the other users authorized by the above-mentioned target user can be understood as personal users authorized by the target user.

[0108] The third-party institution mentioned above can be understood as a financial institution that has full or partial access to the credit data of the target user, but is not directly authorized by the target user, based on the corresponding agreement or regulations. Specifically, the third-party financial institution mentioned above can be a bank that has business dealings with the target user, or a credit rating agency entrusted by the target user's partner.

[0109] Furthermore, the above role types may also include corresponding detailed sub-role types.

[0110] Specifically, for example, taking the regulatory agency as an example, based on the dimension of management level, it can also be refined to include multiple regulatory agencies at different levels: first-level regulatory agencies, second-level regulatory agencies, third-level regulatory agencies, etc. Among them, the third-level regulatory agency is subordinate to the second-level regulatory agency, and the second-level regulatory agency is subordinate to the first-level regulatory agency.

[0111] For another example, taking other institutions authorized by the target user as an example, based on the dimensions of the business services provided, it can also be further refined to include multiple institutions providing different business services: banks that provide credit services to the target user, cooperative companies that provide debt guarantees to the target user, credit rating agencies that provide credit assessments to the target user, etc.

[0112] Based on the above embodiments, it is possible to finely distinguish between a variety of different role types, and respond to target query requests initiated by inquirers of a variety of different role types, and provide differentiated query services that match the permissions of their role types, thereby completing relevant data queries for inquirers while ensuring the data privacy and security of the target user's credit data.

[0113] In some embodiments, before specific implementation, a large number of existing authority management rules for credit data can be collected and obtained as sample rules; then the above multiple sample rules are clustered to obtain multiple data groups; wherein each data group corresponds to a role type (for example, corresponding to the target user, other users authorized by the target user, other institutions authorized by the target user, third-party institutions, and regulatory agencies, which are five different role types). Then, according to the rule features contained in each data group, combined with expert experience and the authority parameters of the relevant role types, multiple preset processing rules corresponding to multiple role types can be configured.

[0114] In some embodiments, when the role type of the inquirer is other users authorized by the target user, refer to Figure 2 As shown, the above-mentioned calling smart contract interacts with the regulatory server according to the target query rules; and responds to the target query request, queries the alliance chain based on the target hash value, and obtains the corresponding ciphertext data of the target query result. When implemented specifically, it may include the following contents:

[0115] S1: Call the smart contract to detect whether the target query request carries the authorization certificate according to the target query rule;

[0116] S2: When it is determined that the target query request carries the authorization certificate, a target verification request is sent to the supervision server; wherein the target verification request carries at least the authorization certificate; the supervision server holds at least the backup private key of the target user; the supervision server uses the backup private key of the target user to verify the authenticity of the authorization certificate;

[0117] S3: Receive the verification result fed back by the supervision server;

[0118] S4: Based on the verification result, if it is determined that the authorization credential has been verified, the inquirer's identity information is interacted with the supervision server to query and register the inquirer's identity information according to the inquirer's identity identification;

[0119] S5: Call the smart contract to query the alliance chain based on the target hash value to obtain the corresponding ciphertext data of the target query result.

[0120] Based on the above embodiment, for target query requests initiated by inquirers of other users whose role class is authorized by the target user, the target query request can be responded to in a timely manner according to the matching target query rules, and the ciphertext data of the corresponding target query results can be accurately queried while effectively protecting the data privacy security of the target user's credit data.

[0121] In specific implementation, the above authorization certificate can specifically be the certificate data signed by the user's private key when the target user authorizes other users to query his or her credit data.

[0122] Accordingly, when verifying, the supervision server can first detect whether there is a user signature on the authorization certificate; if it is determined that there is a user signature, it can further use the backup private key held to verify the authenticity of the signature on the certificate data. If the signature is determined to be true, the authorization certificate is determined to be authentic and valid, and a verification result indicating that the authorization certificate has passed the verification is generated. On the contrary, if the signature is determined to be false, the authorization certificate is determined to be forged and invalid, and a verification result indicating that the authorization certificate has failed the verification is generated.

[0123] In specific implementation, when it is determined that the authorization credential has been verified, the node server can also interact with the regulatory server based on the identity identification of the inquirer, so as to query the system's registered user database under the monitoring of the regulatory server to obtain the identity information of the inquirer; and register the identity information of the inquirer in the alliance chain to temporarily bind the inquirer to the target query request; then call the smart contract, according to the target query request, based on the target hash value, search the alliance chain, and determine the block associated with the target hash value; then extract the ciphertext data of the target user's credit data from the block as the ciphertext data of the target query result.

[0124] In some embodiments, when the role type of the inquirer is other users authorized by the target user, refer to Figure 3 As shown, the above-mentioned target query result is delivered to the terminal device according to the target query rule. When implemented specifically, it may include the following contents:

[0125] S1: Generate a target decryption request for the ciphertext data of the target query result according to the target query rule; wherein the target decryption request carries at least the ciphertext data of the target query result and the authorization credential of the target user;

[0126] S2: Sending the target decryption request to the supervision server; wherein the supervision server responds to the target decryption request, decrypts the ciphertext data of the target query result using the corresponding backup private key, and obtains the plaintext data of the target query result;

[0127] S3: receiving the plaintext data of the target query result fed back by the supervision server;

[0128] S4: According to the target query rules, the plain text data of the target query result is sent to the terminal device through the corresponding secure data transmission channel.

[0129] Here, it is considered that other users authorized by the target user often do not have the corresponding user private key and cannot decrypt by themselves; and other users authorized by the target user often do not have the ability to perform homomorphic encryption operations, and most of the time they just want to know the specific data value of the target user's credit data. It is also considered that only the regulatory server holds the backup private key of the target user, and the regulatory server is a trusted regulatory agency.

[0130] Therefore, in specific implementation, the node server can send a target decryption request to the supervision server. After receiving the target decryption request, the supervision server can first verify the authenticity of the authorization certificate carried by the target decryption request; if it is determined to be true, it can determine the corresponding backup private key of the target user based on the authorization certificate; then respond to the target decryption request, use the backup private key to perform confidentiality processing on the ciphertext data of the target query result, and obtain the corresponding plaintext data of the target query result; and feed back the plaintext data of the target query result to the node server.

[0131] The node server can temporarily establish a secure data transmission channel with the terminal device according to the target query rules and based on the corresponding transmission protocol, which is specifically used to transmit the credit data query results and has a higher security; then, through this secure data transmission channel, the plaintext data of the target results is sent to the terminal device.

[0132] Based on the above embodiment, for a target query request initiated by a queryer whose role class is other users authorized by the target user, the corresponding target query result can be safely and efficiently delivered to the queryer according to the matching target query rules.

[0133] In some embodiments, when the role type of the inquirer is a third-party organization, refer to Figure 4As shown, the above-mentioned calling smart contract interacts with the regulatory server according to the target query rules; and responds to the target query request, queries the alliance chain based on the target hash value, and obtains the corresponding ciphertext data of the target query result. When implemented specifically, it may include the following contents:

[0134] S1: Call the smart contract to detect whether the target query request carries the institution certificate of a third-party institution according to the target query rule;

[0135] S2: When it is determined that the target query request carries an institution certificate, determining whether the institution certificate is valid through the supervision server;

[0136] S3: When it is determined that the institution's credentials are valid, query the institution information database through the supervision server to determine the authority parameters of the third-party institution;

[0137] S4: Call the smart contract to query the alliance chain based on the target hash value and the permission parameters of the third-party organization to obtain the corresponding ciphertext data of the target query result.

[0138] Before the specific implementation, when a third-party institution registers and connects to the credit data management system, in order to ensure the compliance of the third-party institution, the third-party institution needs to upload relevant institutional data and qualification documents as required during registration; the regulatory server conducts compliance checks on the third-party institution based on the above institutional data and qualification documents; when it is determined that the compliance check has passed, the regulatory server generates and provides the institutional certificate corresponding to the third-party institution. The third-party institution can use the institutional certificate to complete the registration and finally connect to the credit data management system.

[0139] In specific implementation, the above-mentioned target query request may also carry the institutional credentials of a third-party institution. Accordingly, the node server may first call the smart contract to detect whether the target query request carries the institutional credentials of the corresponding third-party institution according to the target query rules; if it is determined that the institutional credentials are carried, the institutional credentials are sent to the regulatory server. The regulatory server may verify the validity of the institutional credentials; and feed back the verification results to the node server. Based on the verification results, if the node server determines that the institutional credentials are valid, it may query the institutional information database through the regulatory server to determine the authority parameters of the third-party institution. Among them, the regulatory agency is responsible for updating and maintaining the institutional information database. The above-mentioned institutional information database may store the authority information of each registered institution.

[0140] Furthermore, the node server can first call the smart contract to determine whether the third-party agency has the authority to query the target user's credit data without the target user's direct authorization based on the third-party agency's authority parameters; when it is determined that the third-party agency has the authority to query the target user's credit data without the target user's direct authorization, the query authority scope of the third-party agency is determined based on the authority parameters; then the smart contract is called to query the alliance chain based on the target hash value to find the corresponding block; data that meets the query authority scope of the third-party agency is filtered out from the ciphertext data of the target user's credit data stored in the block as the ciphertext data of the target result.

[0141] Based on the above embodiment, for the target query request initiated by the inquirer whose role class is a third-party organization, the target query request can be responded to in a timely manner according to the matching target query rules, and the ciphertext data of the corresponding target query result can be accurately queried while effectively protecting the data privacy and security of the target user's credit data.

[0142] In some embodiments, when the role type of the queryer is a third-party organization, the target query request may also carry a parameter of the purpose of use of the target query result. Accordingly, according to the target query rule, the target query result is reached to the terminal device. Figure 5 As shown, during specific implementation, it may include:

[0143] S1: According to the target query rule, based on the usage purpose parameter, when the queryer's usage purpose for the target query result does not involve the plaintext data of the target query result, determine the operation call link of the matching homomorphic encryption operation module according to the usage purpose parameter;

[0144] S2: Send the ciphertext data of the target query result and the operation call link to the terminal device; wherein the terminal device calls a matching homomorphic encryption operation module according to the operation call link, and uses the homomorphic encryption operation module to perform a homomorphic encryption operation using the ciphertext data of the target query result in a ciphertext state to obtain the target operation result.

[0145] Among them, the above-mentioned homomorphic encryption operation module can be specifically understood as an operation module constructed based on the homomorphic encryption algorithm.

[0146] Specifically, the homomorphic encryption algorithm used by the above homomorphic encryption operation module is the same as the homomorphic encryption algorithm used to encrypt the credit data of the target user.

[0147] Based on the above embodiment, for a target query request initiated by a third party organization, the corresponding target query result can be safely and efficiently delivered to the inquirer according to the matching target query rules.

[0148] In specific implementation, when the node server determines that the inquirer's purpose of using the target query result does not directly involve the plaintext data of the target query result according to the purpose parameter, it can further determine the operation mode that matches the purpose of use according to the purpose parameter. Among them, the above operation mode can specifically include at least one of the following: accumulation operation, difference operation, comparison operation, audit operation, etc. Then, according to the operation mode, a matching homomorphic encryption operation module is determined from multiple preset homomorphic encryption operation modules; and the ciphertext data of the target query result and the call link of the homomorphic encryption operation module are sent to the terminal device.

[0149] Correspondingly, the terminal device can call the matching homomorphic encryption operation module according to the operation call link, use the ciphertext data of the target query result in the ciphertext state, and perform homomorphic encryption operation in combination with other relevant data provided by the terminal device to obtain the target operation result that the inquirer really needs.

[0150] This can avoid the target user's credit data from being leaked to the greatest extent, while also better meeting the inquirer's query needs.

[0151] In specific implementation, when the node server determines the inquirer's purpose of use of the target query result involving the plaintext data of the target query result based on the target query rule and the purpose parameter, it can then interact with the supervision server to obtain the plaintext data of the target query result; and then, according to the target query rule, send the plaintext data of the target query result to the terminal device through the corresponding secure data transmission channel.

[0152] In some embodiments, when the role type of the queryer is the target user, the above-mentioned calling smart contract interacts with the supervision server according to the target query rule; and responds to the target query request, queries the alliance chain based on the target hash value, and obtains the corresponding ciphertext data of the target query result. When implemented specifically, it may include the following contents:

[0153] S1: Call the smart contract to verify the identity of the target user on the terminal device in conjunction with the regulatory server according to the target query rules;

[0154] S2: When the identity verification is confirmed to be successful, the smart contract is called to query the alliance chain based on the target hash value to obtain the corresponding ciphertext data of the target query result.

[0155] Furthermore, the node server can directly send the encrypted data of the target query result to the terminal device according to the target query rule, thereby achieving the target query result.

[0156] The terminal device can use the user private key provided by the target user to decrypt the ciphertext data of the target query result to obtain the plaintext data of the target query result.

[0157] In some embodiments, when the role type of the queryer is other institutions authorized by the target user, the above-mentioned calling smart contract interacts with the supervision server according to the target query rules; and responds to the target query request, queries the alliance chain based on the target hash value, and obtains the corresponding ciphertext data of the target query result. When implemented specifically, it may include the following contents:

[0158] S1: Call the smart contract to detect whether the target query request carries the authorization certificate according to the target query rule;

[0159] S2: When it is determined that the target query request carries the authorization certificate, a target verification request is sent to the supervision server; wherein the target verification request carries at least the authorization certificate; the supervision server holds at least the backup private key of the target user; the supervision server uses the backup private key of the target user to verify the authenticity of the authorization certificate;

[0160] S3: Receive the verification result fed back by the supervision server;

[0161] S4: Based on the verification results, when it is determined that the authorization credential has passed the verification, the smart contract is called to query the alliance chain based on the target hash value to obtain the corresponding ciphertext data of the target query result.

[0162] Furthermore, the node server can reach the target query result to the terminal device according to the target query rule in the following manner:

[0163] S1: According to the target query rule, based on the usage purpose parameter, when the queryer's usage purpose for the target query result does not involve the plaintext data of the target query result, determine the operation call link of the matching homomorphic encryption operation module according to the usage purpose parameter;

[0164] S2: Send the ciphertext data of the target query result and the operation call link to the terminal device; wherein the terminal device calls a matching homomorphic encryption operation module according to the operation call link, and uses the homomorphic encryption operation module to perform a homomorphic encryption operation using the ciphertext data of the target query result in a ciphertext state to obtain the target operation result.

[0165] In some embodiments, when the role type of the inquirer is a regulatory agency, the above-mentioned calling smart contract interacts with the regulatory server according to the target query rule; and responds to the target query request, queries the alliance chain based on the target hash value, and obtains the corresponding ciphertext data of the target query result. When implemented specifically, it may include the following contents:

[0166] S1: Call the smart contract to detect whether the target query request carries the signature certificate of the regulatory server according to the target query rule;

[0167] S2: When it is determined that the target query request carries the signature certificate of the regulatory server and the signature certificate is valid, respond to the target query request, query the alliance chain based on the target hash value, and obtain the corresponding ciphertext data of the target query result.

[0168] Furthermore, the ciphertext data of the target query result may be sent to a supervision server.

[0169] In some embodiments, after responding to the target query request and completing the query and access to the credit data of the target user, the node server can generate a corresponding access operation record.

[0170] The access operation record at least includes the query time, the identity of the queryer, the ciphertext data of the target query result, the target query rule used during the query, and the relevant credentials used. Furthermore, the access operation record may also include the corresponding query request.

[0171] Next, the node server may store the access operation record in the smart contract; and associate the access operation record with the target hash value.

[0172] In this way, subsequent regulatory agencies can query the smart contract based on the target hash value and trace back the relevant access operation records to determine whether the previous inquirer had any illegal operations in the process of querying the target user's credit data.

[0173] In some embodiments, the target query request may further specifically include an attribute indication parameter; wherein the attribute indication parameter corresponds to at least one attribute data in the credit data of the target user.

[0174] Specifically, the target user's credit data may include multiple different attribute data. Correspondingly, the ciphertext data of the target user's credit data stored on the alliance chain may include the ciphertext data of multiple attribute data.

[0175] Correspondingly, during the specific implementation, the node server can call the smart contract to query the alliance chain based on the target hash value, and filter out the ciphertext data of the attribute data corresponding to the attribute indication parameter from the ciphertext data of the target user's credit data, and combine them to obtain the ciphertext data of the target query result.

[0176] Based on the above embodiments, it is possible to more specifically query and provide the ciphertext data of the required target query results for the inquirer. On the one hand, this can help reduce the overall data processing cost, and on the other hand, it can avoid increasing the risk of leakage of the target user's credit data due to providing the inquirer with ciphertext data of unnecessary attribute data.

[0177] Furthermore, the attribute data may be divided into different security levels according to the sensitivity of the attribute data.

[0178] For attribute data with a higher security level, encryption processing can be performed using the user's private key according to a relatively more complex first encryption rule to obtain the corresponding ciphertext data of the attribute data. For attribute data with a lower security level, encryption processing can be performed using the user's private key according to a relatively simple second encryption rule to obtain the corresponding ciphertext data of the attribute data. For attribute data that does not involve user privacy and is not sensitive, encryption processing may not be performed.

[0179] In some embodiments, see Figure 6 As shown, when the method is implemented specifically, it may also include the following contents:

[0180] S1: At every preset time period, the regulatory server queries the smart contract to obtain the access operation records of the current time period;

[0181] S2: The supervision server detects whether the inquirer has any risk of illegal operation in the process of inquiring the user's credit data according to the access operation records of the current time period;

[0182] S3: When it is determined that there is a risk of illegal operation, the supervision server determines the risk inquirer based on the access operation records in the current time period; and generates a risk tag for the risk inquirer.

[0183] In specific implementation, the regulatory server can use its own regulatory private key to query the smart contract and obtain the access operation record of the current time period; and detect whether the inquirer matches the query rule based on the inquirer's identity and query request in the access operation record; when it is determined that the inquirer matches the query rule, the ciphertext data of the query result is further checked according to the query rule and the scope of authority of the inquirer to determine whether the ciphertext data of the query result has an unauthorized risk, and obtain the first test result. In addition, the regulatory server can also check the validity of the relevant credentials contained in the access operation record to obtain the second test result. Combined with the first test result and the second test result, it is determined whether the inquirer has an illegal operation risk such as unauthorized query in the process of querying the user's credit data.

[0184] In the case of determining that there is a risk of illegal operation, the supervision server determines the identity of the risk inquirer based on the access operation records of the current time period; based on the identity, it detects whether the risk inquirer exists in the risk statistics table. If not, a new risk record about the risk inquirer is added to the risk statistics table using the identity, and the number of risk markers in the risk record is initialized to 1. If it exists, the risk record about the risk inquirer in the risk statistics table is determined based on the identity, and the number of risk markers in the risk record table is increased by 1.

[0185] Based on the above embodiment, the regulatory server can conduct a retrospective investigation on the query process of the inquirer's credit data in the current time period at preset time intervals, so as to promptly discover behaviors and inquirers with risks of illegal operations, thereby better protecting the user's credit data security.

[0186] In some embodiments, after generating the risk mark for the risk inquirer, the method may further include the following when implemented:

[0187] S1: The supervision server detects whether the cumulative number of risk tags of the risk inquirer is greater than a preset risk tag number threshold;

[0188] S2: When it is determined that the cumulative number of risk tags of the risk inquirer is greater than a preset risk tag number threshold, the supervision server adds the identity of the risk inquirer to the supervision blacklist.

[0189] Among them, the above-mentioned regulatory blacklist can be maintained by the regulatory server and regularly updated and published to each node server.

[0190] Based on the above embodiment, the node server can accurately identify malicious risk inquirers according to the cumulative number of risk tags in the risk statistics table, and promptly add the identity of such risk inquirers to the regulatory blacklist, so as to better protect the data privacy security of the user's credit data in the future.

[0191] In some embodiments, after receiving a target query request for credit information data of a target user initiated by a terminal device, the method may further include the following when implemented:

[0192] S1: Obtain the identity of the queryer in the target query request;

[0193] S2: Check whether the identity of the inquirer hits the regulatory blacklist;

[0194] S3: When it is determined that the identity of the inquirer hits the regulatory blacklist, an error message is generated to reject the query.

[0195] Based on the above embodiment, after the node server receives the target query request, it can first determine whether the inquirer is a risk inquirer in the regulatory blacklist based on the regulatory blacklist detection; only when it is determined that the inquirer is not a risk inquirer in the regulatory blacklist will it further perform subsequent data processing; when it is determined that the inquirer is a risk inquirer in the regulatory blacklist, it can directly refuse to respond to the target query request to protect the data security of the target user's credit data.

[0196] In some embodiments, see Figure 7 As shown, when the method is implemented specifically, it may also include the following contents:

[0197] S1: receiving a credit data upload request initiated by a data collection terminal; wherein the credit data upload request carries at least updated data of the credit data of multiple users in the current time period;

[0198] S2: Send the credit data upload request to the supervision server; wherein the supervision server is deployed with a preset anomaly detection model; the supervision server uses the preset anomaly detection model to process the updated data of the credit data of multiple users in the current time period and the updated data of the credit data of multiple users in the historical time period, and detects whether the updated data of the credit data of multiple users has abnormal risks; when determining that there is no abnormal risk, the supervision server feeds back a confirmation instruction that the detection has passed;

[0199] S3: Receive and respond to the confirmation instruction, and add the updated credit data of multiple users in the current time period to the corresponding block of the alliance chain according to the preset chain rules.

[0200] Based on the above embodiment, before the data collection terminal uploads the updated data of the credit data of multiple users to the chain, the regulatory server can also perform anomaly detection on the updated data of the credit data of multiple users as a whole, so as to use a relatively small amount of data processing to ensure that the updated data of the credit data of multiple users subsequently uploaded to the chain are normal and accurate, and avoid uploading erroneous and abnormal data and saving it on the alliance chain, which makes it difficult to modify it later.

[0201] Specifically, each data collection terminal may be responsible for collecting and updating the credit data of multiple users belonging to one area and / or one type.

[0202] In specific implementation, the data collection terminal can regularly collect updated data of the credit data of multiple users in the current time period, generate a corresponding credit data upload request, and send the credit data upload request to the node server. The credit data upload request can also carry the terminal identification of the collection terminal.

[0203] After receiving the request to upload the credit data to the chain, the node server can forward the request to upload the credit data to the chain to the supervision server.

[0204] After receiving the request to upload the credit data to the chain, the regulatory server can first query the historical chain records according to the terminal identification of the collection terminal, and obtain the updated data of the credit data of multiple users in the historical time period that the collection terminal is responsible for (for example, the updated data of the credit data of multiple users uploaded to the chain in the previous time period of the collection terminal); then splice the updated data of the credit data of multiple users in the current time period with the updated data of the credit data of multiple users in the historical time period as a whole, to obtain the updated data of the spliced ​​credit data; then use the pre-trained preset anomaly detection model to process the updated data of the spliced ​​credit data to obtain the corresponding anomaly prediction results; according to the anomaly prediction results, it can be judged whether the overall change trends of the updated data of the credit data of multiple users in the two time periods match; when it is determined that the overall change trends of the updated data of the credit data of multiple users in the two time periods do not match, it can be judged that there is an abnormal risk.

[0205] At this time, the supervision server can feedback a rejection instruction that the detection failed, and forward the rejection instruction to the collection terminal through the node server. Correspondingly, the collection terminal can check the updated data of the credit data of multiple users collected in the current time period according to the rejection instruction to locate the updated data of the credit data of the user with abnormal collected data; and re-collect the updated data of the credit data of the user alone.

[0206] On the contrary, when it is determined that the overall change trend of the updated data of the credit data of multiple users in two time periods matches, it can be judged that there is no abnormal risk. At this time, the regulatory server can feedback the confirmation instruction of the detection. Correspondingly, the node server can receive and respond to the confirmation instruction, and according to the preset chain rules, the updated data of the credit data of multiple users in the current time period will be added to the corresponding block of the alliance chain in a timely manner to realize data chaining.

[0207] When the node server uploads data to the chain, it can call the regulatory server to use the corresponding backup private key to encrypt the updated data of different attribute data in the updated data of each user's credit data according to the preset chain-up rules; then create the corresponding JSON object based on the ciphertext data of the updated data of each attribute data; and then store the corresponding JSON object in the corresponding block on the alliance chain based on the hash value of the user's credit data.

[0208] In some embodiments, the supervision server may also periodically perform credit anomaly detection on the user's credit data to promptly discover the credit data of users with credit anomalies and mark the credit data of the user as credit anomalies.

[0209] In addition, the access operation records can be regularly audited through the regulatory server to detect and determine whether there are any illegal operations such as users or institutions illegally tampering with users' credit data.

[0210] In some embodiments, the regulatory agency may include multiple levels of regulatory agencies, for example, a first-level regulatory agency, a second-level regulatory agency, a third-level regulatory agency, etc. Correspondingly, the regulatory server may include: a first-level regulatory server, a second-level regulatory server, a third-level regulatory server, etc.

[0211] Specifically, regulatory agencies at different levels may respectively hold corresponding regulatory private keys generated based on preset key generation rules; wherein the regulatory private key held by each regulatory agency can decrypt and process data encrypted based on the regulatory private key of a lower-level regulatory agency affiliated with the regulatory agency.

[0212] For example, regulatory agency A is a second-level regulatory agency, regulatory agency B and regulatory agency C are third-level regulatory agencies and fourth-level regulatory agencies respectively subordinate to regulatory agency A; regulatory agency D is another second-level regulatory agency independent of regulatory agency A; regulatory agency E is a third-level regulatory agency subordinate to regulatory agency D. In this case, regulatory agency A can use the regulatory private key it holds to decrypt and process data encrypted with the regulatory private keys of regulatory agencies B and C, but cannot decrypt and process data encrypted with the regulatory private keys of regulatory agencies D and E.

[0213] Based on the above embodiment, by generating and configuring corresponding regulatory private keys for different regulatory agencies according to preset key generation rules, it is possible to implement authority management between regulatory agencies at different levels and without affiliation, thereby achieving multi-party and multi-supervision, so as to protect the data privacy security of user credit data more effectively and accurately.

[0214] In some embodiments, when specifically generating a regulatory private key, you can first obtain and use the hierarchical relationship and affiliation between regulatory agencies according to the preset key generation rules to construct a forest-like relationship data body; wherein each tree in the data body represents a regulatory agency, the layer where each tree is located represents the level of the regulatory agency, and the edge between each tree and the adjacent layer represents the affiliation between the regulatory agency and other regulatory agencies. Then, according to the preset key generation rules and the above-mentioned relationship data body, batch generate corresponding regulatory private keys with hierarchical relationships and affiliations; then, each regulatory private key is respectively allocated to the corresponding regulatory agency according to the above-mentioned relationship data body, so that the regulatory servers of each regulatory agency each hold the corresponding regulatory private key.

[0215] In some embodiments, after the regulatory server completes the detection of the access operation records, the user's credit data, or the updated data of the user's credit data to be uploaded to the chain, it will generate a corresponding detection record; and use the regulatory private key it holds to encrypt the detection record; and then store the encrypted detection record on the alliance chain; wherein the encrypted detection record carries at least the institutional identification of the regulatory agency to which the regulatory server belongs.

[0216] Correspondingly, the regulatory server of a higher-level regulatory agency can randomly extract the encrypted detection records of the regulatory agency at the lower level from the alliance chain according to the agency identification; and use the regulatory private key held to decrypt the encrypted detection records to obtain the detection records in plain text; and then review the detection records according to the internal detection rules to determine whether the detection of the relevant regulatory agency is accurate and standardized, and whether there are omissions or errors, so as to ensure that the detection based on the regulatory agency in the above-mentioned credit data management system is accurate and reliable. This can more effectively protect the data security of the user's credit data.

[0217] In some embodiments, for the credit data of users with relatively high security requirements, the regulatory server of the high-level regulatory agency can first query the smart contract based on the corresponding hash value, and detect whether there are access operation records in the current time period by the regulatory server of the low-level regulatory agency. After completing the access operation record detection, the regulatory server leaves a signature generated using the regulatory private key of the low-level regulatory agency.

[0218] When it is determined that no relevant signature exists, a detection reminder can be generated for the lower-level regulatory agency to detect the access operation records of the user's credit data in the current time period, so as to remind the agency server of the lower-level regulatory agency to conduct relevant detection in a timely manner.

[0219] When it is determined that there is a relevant signature, the regulatory server of the high-level regulatory agency can use the regulatory private key it holds to verify the authenticity of the signature; when it is determined to be true, it can be determined that the underlying regulatory agency has indeed completed the detection of the access operation records of the user's credit data in the current time period; further, the regulatory server of the high-level regulatory agency can re-check the access operation records of the user's credit data in the current time period, determine whether there is a risk of illegal operation by the inquirer in the process of inquiring about the user's credit data in the current time period, and obtain the re-inspection result.

[0220] The server of the high-level regulatory agency then compares the re-test result with the previous test result obtained by the regulatory server of the low-level regulatory agency. If the difference between the re-test result and the previous test result is less than a preset difference threshold, it can be determined that the previous test result is accurate.

[0221] If the difference between the re-test result and the previous test result is greater than or equal to the preset difference threshold, it can be determined that the previous test result may have an error risk. At this time, the regulatory server of the high-level regulatory agency can send a joint detection request for the access operation record of the current time period of the user's credit data to the regulatory server of the relevant low-level regulatory agency. The regulatory server of the high-level regulatory agency and the regulatory server of the low-level regulatory agency jointly detect the access operation record of the current time period of the user's credit data to ultimately determine whether there is a risk of illegal operation in the process of the inquirer querying the user's credit data in the current time period.

[0222] As can be seen from the above, based on the credit data processing method based on the alliance chain provided by the embodiment of this specification, before specific implementation, the alliance chain and smart contract technology can be used, and the regulatory server of the regulatory agency can be introduced to build a corresponding credit data management system. In specific implementation, when the inquirer needs to query the credit data of the target user, the terminal device can be used to send a target query request carrying at least the target hash value corresponding to the credit data of the target user and the identity of the inquirer to the node server in the credit data management system. The node server receives and responds to the target query request, calls the smart contract according to the identity of the inquirer, determines and obtains the matching target query rules based on the role type of the inquirer; then calls the smart contract according to the target query rules, interacts with the regulatory server; and responds to the target query request, queries the alliance chain based on the target hash value, and obtains the ciphertext data of the target query result; according to the target query rules, the target query result is reached to the terminal device; and the corresponding access operation record is saved in the smart contract. In this way, the advantages and characteristics of the alliance chain and the smart contract can be fully utilized, and the characteristics of the regulatory server of the regulatory agency can be introduced and utilized to effectively protect the data privacy security of the user's credit data in the data processing process involving credit data.

[0223] This specification embodiment provides a server, referring to Figure 8 The server includes a network communication port 801, a processor 802 and a memory 803, and the above structures are connected through internal cables so that each structure can perform specific data interaction.

[0224] Among them, the network communication port 801 can be specifically used to receive a target query request for the credit data of a target user initiated by a terminal device; wherein the target query request carries at least a target hash value corresponding to the credit data of the target user to be queried, and the identity of the inquirer.

[0225] The processor 802 can be specifically used to call the smart contract to determine the role type of the inquirer according to the identity of the inquirer; and obtain the target query rule that matches the target query request according to the role type of the inquirer; call the smart contract to interact with the regulatory server according to the target query rule; and respond to the target query request, query the alliance chain based on the target hash value, and obtain the corresponding ciphertext data of the target query result; wherein, the regulatory server is deployed on the regulatory agency side; according to the target query rule, the target query result is delivered to the terminal device; and the corresponding access operation record is saved in the smart contract; wherein, the access operation record is at least associated with the target hash value.

[0226] The memory 803 may be specifically used to store corresponding instruction programs, target query rules, ciphertext data of target query results and other related data.

[0227] Based on the above method, the relevant structural performance of the server can be effectively utilized, the data processing speed of electronic devices can be improved, and credit data processing based on the alliance chain can be efficiently realized.

[0228] In this embodiment, the network communication port 801 can be a virtual port that is bound to different communication protocols so that different data can be sent or received. For example, the network communication port can be a port responsible for web data communication, a port responsible for FTP data communication, or a port responsible for email data communication. In addition, the network communication port can also be a physical communication interface or communication chip. For example, it can be a wireless mobile network communication chip, such as GSM, CDMA, etc.; it can also be a Wifi chip; it can also be a Bluetooth chip.

[0229] In this embodiment, the processor 802 may be implemented in any appropriate manner. For example, the processor may take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) executable by the (micro)processor, a logic gate, a switch, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, etc. This specification does not limit this.

[0230] In this embodiment, the memory 803 may include multiple levels. In a digital system, anything that can store binary data can be a memory; in an integrated circuit, a circuit with a storage function but no physical form is also called a memory, such as RAM, FIFO, etc.; in a system, a storage device with a physical form is also called a memory, such as a memory stick, TF card, etc.

[0231] The embodiment of this specification also provides a computer-readable storage medium based on the above-mentioned credit data processing method based on the alliance chain, and the computer-readable storage medium stores computer program instructions, which, when executed, implement: receiving a target query request for the credit data of a target user initiated by a terminal device; wherein the target query request carries at least a target hash value corresponding to the credit data of the target user to be queried, and an identity identifier of the inquirer; calling a smart contract to determine the role type of the inquirer according to the identity identifier of the inquirer; and obtaining a target query rule that matches the target query request according to the role type of the inquirer; calling a smart contract to interact with a regulatory server according to the target query rule; and responding to the target query request, querying the alliance chain based on the target hash value, and obtaining the corresponding ciphertext data of the target query result; wherein the regulatory server is deployed on the regulatory agency side; according to the target query rule, reaching the target query result to the terminal device; and saving the corresponding access operation record in the smart contract; wherein the access operation record is at least associated with the target hash value.

[0232] In this embodiment, the storage medium includes, but is not limited to, a random access memory (RAM), a read-only memory (ROM), a cache, a hard disk (HDD), or a memory card. The memory may be used to store computer program instructions. The network communication unit may be an interface for network connection communication set in accordance with the standard specified by the communication protocol.

[0233] In this embodiment, the functions and effects specifically implemented by the program instructions stored in the computer-readable storage medium can be explained in comparison with other implementations and will not be described in detail here.

[0234] The embodiments of the present specification also provide a computer program product, which at least includes a computer program, and when the computer program is executed by a processor, it implements the following method steps: receiving a target query request for the credit data of a target user initiated by a terminal device; wherein the target query request carries at least a target hash value corresponding to the credit data of the target user to be queried, and an identity identifier of the inquirer; calling a smart contract to determine the role type of the inquirer according to the identity identifier of the inquirer; and obtaining a target query rule that matches the target query request according to the role type of the inquirer; calling a smart contract to interact with a regulatory server according to the target query rule; and responding to the target query request, querying the alliance chain based on the target hash value, and obtaining the corresponding ciphertext data of the target query result; wherein the regulatory server is deployed on the regulatory agency side; according to the target query rule, reaching the target query result to the terminal device; and saving the corresponding access operation record in the smart contract; wherein the access operation record is at least associated with the target hash value.

[0235] See also Fig. 9 As shown, at the software level, the embodiment of this specification also provides a credit data processing device based on the alliance chain, which is applied to the node server in the credit data management system. The credit data management system is constructed based on the alliance chain. The credit data management system is deployed with a corresponding smart contract. The device may specifically include the following structure:

[0236] The receiving module 901 may be specifically configured to receive a target query request for the credit data of a target user initiated by a terminal device; wherein the target query request carries at least a target hash value corresponding to the credit data of the target user to be queried, and an identity identifier of the queryer;

[0237] The determination module 902 may be specifically used to call the smart contract to determine the role type of the inquirer according to the identity of the inquirer; and obtain the target query rule matching the target query request according to the role type of the inquirer;

[0238] The query module 903 can be specifically used to call the smart contract to interact with the regulatory server according to the target query rules; and respond to the target query request, query the alliance chain based on the target hash value, and obtain the corresponding ciphertext data of the target query result; wherein the regulatory server is deployed on the regulatory agency side;

[0239] Processing module 904 can be specifically used to reach the target query result to the terminal device according to the target query rule; and save the corresponding access operation record in the smart contract; wherein the access operation record is at least associated with the target hash value.

[0240] In some embodiments, the role type of the inquirer may specifically include at least one of the following: a target user, another user authorized by the target user, another institution authorized by the target user, a third-party institution, a regulatory agency, etc.

[0241] In some embodiments, when the role type of the inquirer is other users authorized by the target user, when the above-mentioned query module 903 is specifically implemented, the smart contract can be called in the following manner to interact with the regulatory server according to the target query rules; and in response to the target query request, the alliance chain is queried based on the target hash value to obtain the corresponding ciphertext data of the target query result: the smart contract is called to detect whether the target query request carries the authorization certificate according to the target query rules; when it is determined that the target query request carries the authorization certificate, a target verification request is sent to the regulatory server; wherein the target verification request carries at least the authorization certificate; the regulatory server at least holds the backup private key of the target user; the regulatory server uses the backup private key of the target user to verify the authenticity of the authorization certificate; receives the verification result fed back by the regulatory server; according to the verification result, when it is determined that the authorization certificate has been verified, according to the identity identification of the inquirer, interact with the regulatory server to query and register the identity information of the inquirer; the smart contract is called to query the alliance chain based on the target hash value to obtain the corresponding ciphertext data of the target query result.

[0242] In some embodiments, when the above-mentioned processing module 904 is implemented, the target query result can be delivered to the terminal device according to the target query rules in the following manner: according to the target query rules, a target decryption request for the ciphertext data of the target query result is generated; wherein the target decryption request carries at least the ciphertext data of the target query result and the authorization credentials of the target user; the target decryption request is sent to the regulatory server; wherein the regulatory server responds to the target decryption request, decrypts the ciphertext data of the target query result using the corresponding backup private key, and obtains the plaintext data of the target query result; receives the plaintext data of the target query result fed back by the regulatory server; according to the target query rules, the plaintext data of the target query result is sent to the terminal device through the corresponding secure data transmission channel.

[0243] In some embodiments, when the role type of the inquirer is a third-party organization, when the above-mentioned query module 903 is specifically implemented, the smart contract can be called in the following manner to interact with the regulatory server according to the target query rules; and in response to the target query request, the alliance chain is queried based on the target hash value to obtain the corresponding ciphertext data of the target query result: the smart contract is called to detect whether the target query request carries the institutional credentials of the third-party organization according to the target query rules; when it is determined that the target query request carries the institutional credentials, the regulatory server is used to determine whether the institutional credentials are valid; when it is determined that the institutional credentials are valid, the institutional information database is queried through the regulatory server to determine the authority parameters of the third-party organization; the smart contract is called to query the alliance chain based on the target hash value and the authority parameters of the third-party organization to obtain the corresponding ciphertext data of the target query result.

[0244] In some embodiments, the target query request also carries a usage purpose parameter for the target query result. Accordingly, when the above-mentioned processing module 904 is implemented, the target query result can be delivered to the terminal device according to the target query rule in the following manner: according to the target query rule, when the inquirer's usage purpose for the target query result does not involve the plaintext data of the target query result based on the usage purpose parameter, determine the operation call link of the matching homomorphic encryption operation module according to the usage purpose parameter; send the ciphertext data and the operation call link of the target query result to the terminal device; wherein, the terminal device calls the matching homomorphic encryption operation module according to the operation call link, and uses the homomorphic encryption operation module to perform homomorphic encryption operation using the ciphertext data of the target query result in the ciphertext state to obtain the target operation result.

[0245] In some embodiments, the target query request may further specifically include an attribute indication parameter; wherein the attribute indication parameter corresponds to at least one attribute data in the credit data of the target user.

[0246] In some embodiments, when the device is implemented, it can also be used to: query the smart contract using the regulatory server at preset time intervals to obtain the access operation records of the current time period; use the regulatory server to detect whether the inquirer has a risk of illegal operation in the process of querying the user's credit data based on the access operation records of the current time period; when it is determined that there is a risk of illegal operation, use the regulatory server to determine the risk inquirer based on the access operation records of the current time period; and generate a risk tag for the risk inquirer.

[0247] In some embodiments, after generating a risk mark for the risk inquirer, the device can also be used when implemented to: use a regulatory server to detect whether the cumulative number of risk marks of the risk inquirer is greater than a preset risk mark number threshold; when it is determined that the cumulative number of risk marks of the risk inquirer is greater than the preset risk mark number threshold, use the regulatory server to add the identity of the risk inquirer to the regulatory blacklist.

[0248] In some embodiments, after receiving a target query request for the credit data of a target user initiated by a terminal device, the device, when implemented, can also be used to: obtain the identity of the inquirer in the target query request; detect whether the identity of the inquirer hits the regulatory blacklist; and generate an error prompt for rejecting the query when it is determined that the identity of the inquirer hits the regulatory blacklist.

[0249] In some embodiments, when the device is implemented, it can also be used to: receive a credit data chain request initiated by a data collection terminal; wherein the credit data chain request carries at least updated data of the credit data of multiple users in the current time period; send the credit data chain request to a regulatory server; wherein the regulatory server is deployed with a preset anomaly detection model; the regulatory server uses the preset anomaly detection model to process the updated data of the credit data of multiple users in the current time period, as well as the updated data of the credit data of multiple users in the historical time period, to detect whether there is an abnormal risk in the updated data of the credit data of multiple users; and when it is determined that there is no abnormal risk, feedback a confirmation instruction of the detection passing; receive and respond to the confirmation instruction, and according to the preset chain rules, add the updated data of the credit data of multiple users in the current time period to the corresponding block of the alliance chain.

[0250] It should be noted that the units, devices or modules described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. For the convenience of description, the above devices are described separately by functions divided into various modules. Of course, when implementing this specification, the functions of each module can be implemented in the same or more software and / or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units. 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, such as 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.

[0251] It can be seen from the above that the credit data processing device based on the alliance chain provided in the embodiment of this specification can make full use of the advantages and characteristics of the alliance chain and smart contracts, introduce and utilize the characteristics of the regulatory server of the regulatory agency, and effectively protect the data privacy security of user credit data in the data processing process involving credit data.

[0252] In a specific scenario example, the credit data processing method based on alliance chain provided in this specification can be applied to implement credit data management based on alliance chain and privacy computing. The specific implementation process can be found in the following content.

[0253] In this scenario example, most credit reporting agencies do not introduce blockchain technology when processing data. Instead, they store data in a database, grant different data access rights to different roles through permission access control, and make data tamper-proof for users with read-only permissions. The above method cannot prevent high-authority users and database system administrators from changing data, so it does not fundamentally solve the problem of data tamper-proof from a technical perspective.

[0254] In addition, the same data operations can be recorded using traditional traceability methods, which only records the access to data. However, the record is not completely trustworthy because the operation record is stored centrally, so it is possible to modify the operation record.

[0255] In addition, credit reporting agencies currently use symmetric encryption technology when processing sensitive data. They encrypt the data when it is stored, and then use the key to decrypt it when it is needed, and analyze and audit the decrypted plaintext data. The disadvantage of the above approach is the management of sensitive data. Sensitive data is restricted by the key holder, which is a centralized management method. Once the private key holder loses the key or is prone to abuse or leak data due to personal problems, it will bring huge risks to the credit reporting data system and data subjects.

[0256] In view of the above situation, in this scenario example, a credit data management solution based on alliance chain technology and privacy computing is proposed to solve the problems of traditional credit data being tamperable, sensitive data not being encrypted, and the operation process not being recorded. At present, credit reporting agencies manage a large amount of credit data of individuals and institutions, which contains a lot of sensitive data, such as: information on income, deposits, securities, commercial insurance, real estate, and tax amounts of individuals and institutions. These data are very important and cannot be modified arbitrarily after entry. At the same time, this information is relatively sensitive and needs to be encrypted before storage; in order to make the encrypted data meet the audit requirements, it is necessary to provide regulators with a safe and fast decryption method.

[0257] Specifically, the alliance chain and smart contract technology can be integrated to develop a smart contract and deploy it on the alliance chain (for example, a credit data management system). It is used to record credit data so that the credit data cannot be tampered with at will. At the same time, it can record the access records of different people to the data to ensure that data access is traceable, and save the time, content and purpose of the access data to the alliance chain. Furthermore, multi-party multi-regulatory technology is also introduced to meet the regulatory needs of credit reporting agencies. Regulatory agencies come from different administrative departments, forming multi-party supervision. Regulatory agencies themselves usually have multiple levels, forming multiple supervision. In other words, multi-party multi-regulatory technology aims to establish a system that can be supervised by multiple institutions and departments at different levels in institutions through a family of collateral unsolvable functions in cryptography.

[0258] In general, by using the alliance chain as a distributed ledger to store credit data, the problem of credit data being tamper-proof and single point failure of storage services is solved. By using alliance chain and smart contract technology, smart contracts are used to store records of access to data, so that the operation records of credit data can be traced, and the access record data itself cannot be tampered with. By recording the operation records of credit data in a blockchain transaction, a transaction hash can be used for query when accessing. By using multi-party multi-regulatory technology, sensitive data can be encrypted, and keys can be distributed to regulators, so that regulators have the regulatory private keys of their children, grandchildren and future generations in their hands, and can decrypt all data within their regulatory scope. This technology realizes the management of keys and the supervision of sensitive data ciphertexts, taking into account the problems of non-leakage of sensitive data and auditability of privacy data. By using double trapdoor homomorphic encryption technology to encrypt users' sensitive technologies, "data is available but invisible" is achieved.

[0259] Invention point 6: When operating on the encrypted sensitive data ciphertext, such as using homomorphic addition operations to accumulate user deposits, it is performed in the form of transactions, and the specific homomorphic addition operation process is implemented in the smart contract.

[0260] In the specific implementation, the credit data chain and access process, please refer to Fig.10 As shown, the following contents may be included.

[0261] 1. Structured data stored in blockchain

[0262] 1.1 Data formatted and uploaded to the chain

[0263] Format the credit data (e.g., the user's credit data) and upload it to the chain. For example, if an institution wants to upload someone's credit data to the chain, and the credit data itself has many attributes (e.g., attribute data), the credit agency can construct all the attributes of the data to be uploaded to the chain into a JSON object, and then upload the formatted (serialized) product object to the chain.

[0264] 1.2 Data is encrypted and uploaded to the chain

[0265] For sensitive information such as income, deposits, securities, commercial insurance, real estate information and tax amounts contained in the credit data, this solution uses asymmetric encryption - double trapdoor homomorphic encryption for encryption. The advantage of double trapdoor homomorphic encryption is security, and it can encrypt numerical plaintext such as income, deposits, securities, etc. and then perform ciphertext operations. The result of ciphertext operation and decryption is consistent with the result of plaintext operation; at the same time, it can encrypt non-numerical plaintext, and the ciphertext can only be decrypted by the owner of the private key. The encrypted data content must also be formatted into a json object before being uploaded to the chain.

[0266] 1.3 How to upload data to the chain

[0267] Before the business data is uploaded to the chain, it needs to be processed and the information needs to be signed. These processes can be completed through corresponding tools, such as serialization tools and various elliptic curve signature tools, but more often they are completed through SDKs that integrate various tools. Put the information of the calling function plus the chain data into the relevant part of the transaction structure (payload field). The transaction structure before signing is determined by the chain, but generally contains the called contract, timestamp, random number, and information of the calling function plus data. After the data before signing is assembled, it will be further serialized for message transmission. The processing stage before the business is uploaded to the chain mainly converts the business data into a readable way of the blockchain through tools, and binds the sender's identity and the sent information through signatures, which plays a role in identity authentication and preventing repudiation, and finally sends the processed information to the blockchain node. The processing before the chain is centralized, and these processing processes do not involve blockchain nodes, so this stage does not require node participation.

[0268] 2. Synchronize the data in the blockchain to the database

[0269] In order to improve the efficiency of a large number of business operations, this solution will establish a data engine and use event monitoring to monitor the latest block height of the data. It will also parse the blockchain transactions in the block height and store the JSON serialized data in the database.

[0270] 2.1 In the blockchain network, there are several different node roles, each of which has different functions and responsibilities. The following is a detailed introduction to the common node roles in the blockchain network:

[0271] Full Node, a full node is the most complete node in the blockchain network, which stores and maintains a complete copy of the entire blockchain. Full nodes have the following main functions: participate in the consensus process, including mining and verifying blocks; verify the validity of transactions and execute smart contract operations; propagate transactions and block data by communicating with other full nodes; store all blockchain data, including block headers, transactions, and smart contract codes. Full nodes play an important role in blockchain networks. They provide a high degree of security and reliability, but require a large amount of storage space and network bandwidth.

[0272] Light Node, a lightweight node in the blockchain network, which only stores a small part of the blockchain data, is mainly used to implement lightweight client applications. Light nodes have the following main functions: store a small amount of blockchain data, such as block headers and a small amount of transaction data; obtain missing block data and status data by communicating with full nodes; verify the validity of transactions, but do not execute smart contract operations; support the development and use of client applications. Light nodes take up less storage space and network bandwidth, have relatively fast synchronization speeds, and are suitable for mobile devices and resource-constrained environments.

[0273] Validator Node: Validator Node is a node role in the blockchain network. They participate in the consensus and verification process of the blockchain. Validator nodes have the following main functions: store and verify part of the blockchain data, including block headers and a small amount of transaction data; verify the validity of transactions, but do not execute smart contract operations; communicate with other validator nodes to disseminate information related to blocks and consensus.

[0274] 2.2 Synchronization method

[0275] The synchronization methods of block data mainly include full node synchronization, light node synchronization and validator node synchronization. Here we need to synchronize all transaction information in the blockchain, so we deploy a blockchain full node to synchronize the full amount of data in the blockchain network, and then deploy the blockchain data engine service to parse the data in the transaction into the database of the data engine. The database here is the MySQL database.

[0276] Full node synchronization, a full node is the most complete node in the blockchain network. It stores and maintains complete blockchain data. Full nodes synchronize by requesting block data from other full nodes. The process of full node synchronization is called the full node synchronization algorithm.

[0277] Specifically, the steps of full node synchronization are as follows: Initialization, the full node initializes its own blockchain database by requesting block data one by one starting from the genesis block. Block request, the full node sends block requests to other full nodes to obtain missing block data. Block verification, the full node verifies the validity of the received block data, including verifying the hash value of the block, the signature of the transaction, and the result of the contract execution. Block application, the full node applies the verified block data to its own blockchain database, and updates the status and transaction history. Block loading, the data engine service listens to the newly generated blocks through the RPC of the blockchain full node, and parses the payload field in the transaction after obtaining the block. The payload field contains json format data, where the field is the field in the mysql database, and the data is stored in the corresponding table.

[0278] 3. Role-based access control

[0279] RBAC allows for high-level access to be created and enforced by assigning a set of permissions. Permissions are based on the level of access a particular category of user requires to perform their duties. In other words, different people in an organization can have completely different levels and types of access based on factors such as their job function and responsibilities. For example, an HR employee can view employee records but not customer data. An HR manager can delete or change HR records, while a lower-level HR specialist can only view them.

[0280] 3.1 The Role of RBAC

[0281] In the RBAC framework, roles are semantic constructs used to build permissions. Roles can be defined by any number of criteria, including permissions, responsibilities, cost centers, and business units. A role essentially refers to a collection of user permissions. This is different from traditional user groups, which are collections of users. In the context of RBAC, permissions are tied to roles rather than being directly connected to identities. Roles are more stable than groups because roles are organized around access management, and in a typical organization, functions and activities do not change as frequently as identities.

[0282] 3.2 RBAC Permissions

[0283] Permission is the set of permissions granted to perform operations on protected objects. The protected objects here can refer to all the contents in the credit data management system, including data, modules, menus, pages, fields, operation functions, etc. At the same time, different RBAC models can be used for different permissions.

[0284] 3.3 Advantages of RBCA

[0285] One of the biggest advantages of RBAC is that it provides a systematic approach to defining and maintaining roles, enabling you to consistently grant access only as users need it, thereby reducing the risk of data breaches or data loss.

[0286] 3.4 Application of RBAC in Credit Data Management System

[0287] By creating roles and permissions, and adding permissions to roles, you can add permissions to roles. When a role accesses data or processes business, first determine whether the role has the relevant permissions. If not, access is prohibited or an error message is prompted; if there is permission, the role can continue to access data and process business.

[0288] During the specific implementation, please refer to the credit data operation record tracing process. Fig.11 As shown, the following contents may be included.

[0289] 1. Tracing algorithm

[0290] In this scenario example, the traceability algorithm used is a traceability algorithm that focuses on business logic. It abstracts the business and forms three parts: asset node, link flow, and link. The asset node is the subject to be traced and tracked, the link flow is the business logic that the asset node will perform, and the link is a specific step or link in the business logic. When tracing user operations, the user is regarded as an asset node, the business process is the link flow, and the business process clicked is each link.

[0291] 1.1 The whole process traceability starts with the creation of the link flow. After the link flow is created, it is necessary to add links to the link flow, which depends on the specific business logic. For example, the object of traceability in this solution, that is, the asset node, is the user object, the link flow is the business handled by the user, and the link is each step taken by the user, such as adding, deleting, querying, and modifying data records.

[0292] 1.2 Links are points that may be passed in the link flow. For example, in the user's link flow, links such as add, delete, query, and modify can be created, because these four types of links will be used in the link flow. Links can be set to be required or not required, and this setting can be changed by configuring the "mustLink" field.

[0293] 1.3 When creating a link, configure the link flow to the "belongLinkFlowId" field, and then add the link to the link flow so that the business logic can flow through each link in the link flow when the user uses the link flow.

[0294] 1.4 Create an asset node. This node configures the link flow that the node will use through the "linkFlowId" field, and the "name" field is the name of the asset node. In this solution, the asset node is the user of the credit data management system.

[0295] 1.5 If you need to modify the information after the asset node is generated, you can modify it through the relevant interface. If you do not need to modify it, you can put the asset node into the link flow, call the node in the link flow according to business needs, and fill in the specific information flowing through this link into the "passLinkMessage" field.

[0296] 1.6 When the asset node calls a link in the link flow, that is, the business logic is completed, you can call the relevant interface to view the specific information of the asset node flowing through each link. This specific information is the full process traceability information of the asset node, so that all user operation records can be obtained.

[0297] In specific implementation, the credit data audit process may include the following contents.

[0298] In this scenario example, a data decryption function can be provided to regulators, and regulatory agencies and auditing agencies can decrypt objects that use double trapdoor homomorphic encryption.

[0299] Specifically, in double trapdoor homomorphic encryption, a pair of encryption parameters of the master private key and the master public key will be generated first; for users of credit reporting agencies, a pair of sub-private keys and sub-public keys will be generated. When users upload sensitive information, they can use their own sub-public keys to encrypt it. At this time, the master private key of the regulatory agency or the sub-private key of the user can decrypt the ciphertext. For numerical ciphertext, homomorphic operations such as addition or multiplication can be performed on the ciphertext in an encrypted state.

[0300] Through the above scenario examples, the credit data processing method based on the alliance chain provided in this specification is verified. When the credit agency collects, saves, uses, and audits credit data, the credit data is effectively stored using the alliance chain technology, which technically ensures that the data cannot be tampered with. In conjunction with the existing access control technology, the credit data is more secure and reliable. Based on the alliance chain smart contract technology, the entire process of data access is recorded, and the data operation records are technically traceable, and the traceable operation record data cannot be tampered with, making the credit data access system more secure. Privacy computing technology encrypts the user's sensitive data, effectively protecting the privacy of user data, and combining multi-party and multi-regulatory technologies to make the data auditable and regulated in a safe manner.

[0301] Although the present specification provides 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 a unique execution order. When the device or client 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 device 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 device. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or device including the elements. The first, second, etc. words are used to represent the name, and do not represent any particular order.

[0302] Those skilled in the art also know that, in addition to implementing the controller in a purely computer-readable program code, the controller can be made to implement the same function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered as a hardware component, and the devices for implementing various functions included therein can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules for implementing the method and structures within the hardware component.

[0303] This 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, classes, etc. that perform specific tasks or implement specific abstract data types. This 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-readable storage media including storage devices.

[0304] Through the description of the above embodiments, it can be known that those skilled in the art can clearly understand that the present specification can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solution of the present specification can essentially be embodied in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a mobile terminal, a server, or a network device, etc.) to execute the methods described in each embodiment of the present specification or some parts of the embodiments.

[0305] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. This specification can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld devices or portable devices, tablet devices, multi-processor systems, microprocessor-based systems, set-top boxes, programmable electronic devices, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc.

[0306] Although the present specification is described through embodiments, those skilled in the art will appreciate that there are many modifications and changes to the present specification without departing from the spirit of the present specification, and it is intended that the appended claims include these modifications and changes without departing from the spirit of the present specification.

Claims

1. A credit data processing method based on alliance chain, characterized in that: A node server applied to a credit data management system, wherein the credit data management system is constructed based on a consortium chain, and the credit data management system is deployed with a corresponding smart contract, and the method includes: Receiving a target query request for the credit data of a target user initiated by a terminal device; wherein the target query request carries at least a target hash value corresponding to the credit data of the target user to be queried, and an identity identifier of the queryer; Call the smart contract to determine the role type of the inquirer based on the inquirer's identity; and obtain the target query rule that matches the target query request based on the inquirer's role type; Call the smart contract to interact with the regulatory server according to the target query rules; and respond to the target query request, query the alliance chain based on the target hash value, and obtain the corresponding ciphertext data of the target query result; wherein the regulatory server is deployed on the regulatory agency side; According to the target query rules, the target query results are delivered to the terminal device; and the corresponding access operation records are saved in the smart contract; wherein the access operation records are at least associated with the target hash value.

2. The method according to claim 1, characterized in that The role type of the inquirer includes at least one of the following: a target user, another user authorized by the target user, another institution authorized by the target user, a third-party institution, and a regulatory agency.

3. The method according to claim 2, characterized in that In the case where the role type of the inquirer is another user authorized by the target user, the smart contract is called to interact with the supervision server according to the target query rules; And respond to the target query request, query the alliance chain based on the target hash value, and obtain the corresponding ciphertext data of the target query result, including: Call the smart contract to detect whether the target query request carries the authorization certificate according to the target query rules; When it is determined that the target query request carries the authorization certificate, a target verification request is sent to the supervision server; wherein the target verification request carries at least the authorization certificate; the supervision server holds at least the backup private key of the target user; the supervision server uses the backup private key of the target user to verify the authenticity of the authorization certificate; Receive verification results fed back by the regulatory server; According to the verification result, when it is determined that the authorization credential has been verified, the inquirer's identity information is interacted with the supervision server to query and register the inquirer's identity information according to the inquirer's identity identification; Call the smart contract to query the alliance chain based on the target hash value to obtain the corresponding ciphertext data of the target query result.

4. The method according to claim 3, characterized in that According to the target query rules, the target query results are delivered to the terminal device, including: Generate a target decryption request for the ciphertext data of the target query result according to the target query rule; wherein the target decryption request carries at least the ciphertext data of the target query result and the authorization credential of the target user; Sending the target decryption request to the supervision server; wherein the supervision server responds to the target decryption request and uses the corresponding backup private key to decrypt the ciphertext data of the target query result to obtain the plaintext data of the target query result; Receive the plaintext data of the target query result fed back by the supervision server; According to the target query rules, the plaintext data of the target query results is sent to the terminal device through the corresponding secure data transmission channel.

5. The method according to claim 2, characterized in that: In the case where the role type of the inquirer is a third-party institution, the smart contract is called to interact with the regulatory server according to the target query rules; And respond to the target query request, query the alliance chain based on the target hash value, and obtain the corresponding ciphertext data of the target query result, including: Call the smart contract to detect whether the target query request carries the institution certificate of a third-party institution according to the target query rules; In the case where it is determined that the target query request carries an institution certificate, determining whether the institution certificate is valid through the supervision server; When it is determined that the institution's credentials are valid, the institution information database is queried through the regulatory server to determine the authority parameters of the third-party institution; Call the smart contract to query the alliance chain based on the target hash value and the permission parameters of the third-party agency to obtain the corresponding ciphertext data of the target query result.

6. The method according to claim 5, characterized in that The target query request also carries a usage purpose parameter of the target query result. Accordingly, according to the target query rule, the target query result is delivered to the terminal device, including: According to the target query rule, when the queryer's purpose of using the target query result does not involve the plaintext data of the target query result based on the purpose parameter, determine the operation call link of the matching homomorphic encryption operation module according to the purpose parameter; The ciphertext data of the target query result and the operation call link are sent to the terminal device; wherein the terminal device calls a matching homomorphic encryption operation module according to the operation call link, and uses the homomorphic encryption operation module to perform a homomorphic encryption operation using the ciphertext data of the target query result in a ciphertext state to obtain the target operation result.

7. The method according to claim 1, characterized in that The target query request also includes an attribute indication parameter; wherein the attribute indication parameter corresponds to at least one attribute data in the credit data of the target user.

8. The method according to claim 1, characterized in that The method further comprises: At every preset time period, the regulatory server queries the smart contract to obtain the access operation records of the current time period; The supervision server detects whether the inquirer has any risk of illegal operation in the process of inquiring the user's credit data based on the access operation records in the current time period; When it is determined that there is a risk of illegal operation, the supervision server determines the risk inquirer based on the access operation records in the current time period; and generates a risk tag for the risk inquirer.

9. The method according to claim 8, characterized in that After generating the risk mark for the risk inquirer, the method further includes: The supervision server detects whether the cumulative number of risk tags of the risk inquirer is greater than a preset risk tag number threshold; When it is determined that the cumulative number of risk marks of the risk inquirer is greater than a preset risk mark number threshold, the supervision server adds the identity of the risk inquirer to the supervision blacklist.

10. The method according to claim 9, characterized in that After receiving a target query request for credit information data of a target user initiated by a terminal device, the method further includes: Obtain the identity of the queryer in the target query request; Check whether the identity of the inquirer hits the regulatory blacklist; When it is determined that the identity of the inquirer hits the regulatory blacklist, an error message is generated to reject the query.

11. The method according to claim 1, characterized in that The method further comprises: Receive a credit data upload request initiated by a data collection terminal; wherein the credit data upload request carries at least updated data of the credit data of multiple users in the current time period; The request for uploading the credit data to the chain is sent to the supervision server; wherein the supervision server is deployed with a preset anomaly detection model; the supervision server uses the preset anomaly detection model to process the updated data of the credit data of multiple users in the current time period and the updated data of the credit data of multiple users in the historical time period, and detects whether the updated data of the credit data of multiple users has abnormal risks; and when it is determined that there is no abnormal risk, the supervision server feeds back a confirmation instruction that the detection has passed; Receive and respond to confirmation instructions, and according to the preset chain rules, add the updated credit data of multiple users in the current time period to the corresponding block of the alliance chain.

12. A credit data processing device based on alliance chain, characterized in that: A node server applied to a credit data management system, wherein the credit data management system is constructed based on a consortium chain and a corresponding smart contract is deployed in the credit data management system. The device comprises: A receiving module, configured to receive a target query request for the credit data of a target user initiated by a terminal device; wherein the target query request carries at least a target hash value corresponding to the credit data of the target user to be queried, and an identity identifier of the queryer; A determination module is used to call a smart contract to determine the role type of the inquirer according to the identity of the inquirer; and obtain a target query rule that matches the target query request according to the role type of the inquirer; The query module is used to call the smart contract to interact with the regulatory server according to the target query rules; and respond to the target query request, query the alliance chain based on the target hash value, and obtain the corresponding ciphertext data of the target query result; wherein the regulatory server is deployed on the regulatory agency side; A processing module is used to reach the target query result to the terminal device according to the target query rule; and save the corresponding access operation record in the smart contract; wherein the access operation record is at least associated with the target hash value.

13. A server, characterized in that: The method comprises a processor and a memory for storing processor-executable instructions, wherein the processor implements the steps of the method according to any one of claims 1 to 11 when executing the instructions.

14. A computer-readable storage medium, characterized in that: Computer instructions are stored thereon, and when the instructions are executed by a processor, the steps of the method according to any one of claims 1 to 11 are implemented.

15. A computer program product, characterized in that The invention comprises a computer program, which implements the steps of the method according to any one of claims 1 to 11 when being executed by a processor.

Images