Blacklist data sharing method and acquisition method
By hashing the identity of the blacklist user to generate a key, and using the signature identity data to accumulate to generate a symmetric key, encrypting and uploading the detailed data of the blacklist user, the problem of privacy and security of blacklist data on the blockchain is solved, and the implementation of the implementation of the Efficient sharing and mutual trust alliances have been improved to improve the utilization efficiency of blacklist data.
Patent Information
- Application Number
- CN202111447921.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-09-24
- Publication Date
- 2024-12-31
- Estimated Expiration
- 2041-09-24
AI Technical Summary
The existing blockchain blacklist data sharing method cannot guarantee the privacy and security of blacklist data, resulting in user identity identification and detailed data leaks, and efficient sharing cannot be achieved.
By hashing the blacklist user identity to generate a key, and accumulating the signature identity data to generate a symmetric key, encrypt and upload the blacklist user details data to ensure data privacy and security, and efficient sharing is achieved on the alliance chain.
It realizes the privacy and security protection of blacklist data on the blockchain, ensures that user identities are not leaked, and builds a mutual trust alliance through signed identity data, improving the efficiency of blacklist data utilization.
Smart Images
Figure CN114386086B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of information security technology, and in particular to a blacklist data sharing method and an acquisition method. Background Art
[0002] Blacklist data is a kind of valuable privacy data and belongs to each institution. At present, due to data security considerations, each institution is worried about data leakage and therefore holds its own data, which leads to insufficient sharing of existing blacklist data and serious island phenomenon.
[0003] The blacklist data includes two parts: the blacklist user identity (abbreviated as ID, such as ID number) and the blacklist user details data (abbreviated as data). Generally, the blacklist user identity is used as the blacklist key (key) on the chain, and the blacklist user details data is used as the value on the chain. The value can be retrieved through the key.
[0004] Most of the existing blockchain blacklist data sharing methods are to upload the blacklist data to the chain in plain text, that is, to save the key and value in plain text on the blockchain at the same time, which will directly leak the blacklist user identity and blacklist user details data, and cannot guarantee the privacy and security of the on-chain data. Summary of the invention
[0005] Based on this, it is necessary to provide a blacklist data sharing method and acquisition method to address the problem that the traditional blacklist data sharing method cannot guarantee the privacy and security of the blacklist data on the chain after it is uploaded to the chain.
[0006] The present application provides a blacklist data sharing method, the method comprising:
[0007] The client that sends the blacklist data upload request is regarded as the initiator client, and the blacklist user identity of the initiator client is read;
[0008] All clients in the alliance chain except the initiator client are regarded as the receiving clients. The initiator client hashes the blacklist user identity and generates a first key corresponding to each receiving client based on the remainder algorithm;
[0009] The initiator client sends the first key corresponding to each receiver client to each receiver client;
[0010] After receiving the first key, each receiving client extracts the locally stored private key to sign the first key, generates signed identity data and returns the signed identity data to the initiating client;
[0011] After receiving the signature identity data returned by all the receiving clients, the initiator client adds the signature identity data returned by all the receiving clients and the signature identity data of the initiator client, and uses the accumulated result as the symmetric key;
[0012] The initiator client performs a hash operation on the symmetric key and uses the result of the hash operation as the blacklist key;
[0013] The initiator client extracts the blacklist user detail data corresponding to the blacklist user identity identifier of the initiator client;
[0014] The initiator client uses the blacklist key to encrypt the blacklist user details data, uses the encrypted blacklist user details data as the value corresponding to the blacklist key, and synchronously uploads the blacklist key and value to the alliance chain.
[0015] The present application relates to a blacklist data sharing method, which protects the privacy and security of the data on the chain for the client that needs to upload the blacklist data to the chain. On the one hand, by hashing the blacklist user identity identifier to generate a first key and sending it to the receiving client, the receiving client can only obtain the first key after hashing, and cannot know the blacklist user identity identifier. During the transmission process, it can be ensured that the user's blacklist user identity identifier is not leaked. On the other hand, the initiator client generates a first key corresponding to each receiving client, and needs to receive each signature identity data returned by each receiving client, accumulate all the signature identity data to generate a blacklist key, and then perform the chain operation, so that the blacklist key contains the signature identity data of all institutions, which is not only conducive to building a mutual trust alliance between institutions, but also realizes the efficient sharing of blacklist data and improves the utilization efficiency of blacklist data.
[0016] The present application also provides a method for obtaining blacklist data, the method comprising:
[0017] The client receiving the blacklist data acquisition request is regarded as an acquisition client, and the acquisition client acquires the blacklist user identity to be queried contained in the blacklist data acquisition request;
[0018] All clients in the alliance chain except the acquiring client are regarded as collaborative clients. The acquiring client hashes the blacklist user identity to be queried, and generates a third key corresponding to each collaborative client based on the remainder algorithm;
[0019] The acquiring client sends the third key corresponding to each cooperating client to each cooperating client;
[0020] After receiving the third key, each collaborative client extracts the locally stored private key to sign the third key, generates signature identity data and returns the signature identity data to the acquiring client;
[0021] After receiving the signature identity data returned by all the collaborating clients, the acquiring client adds up the signature identity data returned by all the collaborating clients and the signature identity data of the acquiring client, and uses the accumulated result as the symmetric key;
[0022] The acquiring client performs a hash operation on the symmetric key and uses the result of the hash operation as the blacklist key;
[0023] The acquiring client uses the blacklist key as an index to obtain the value corresponding to the blacklist key on the consortium chain;
[0024] The acquiring client uses the blacklist key to decrypt the value and obtains the blacklist user detail data corresponding to the blacklist user identity to be queried.
[0025] The present application relates to a method for obtaining blacklist data, which protects the privacy and security of the data on the chain for clients that need to obtain blacklist data from the chain. On the one hand, by hashing the blacklist user identity to be queried to generate a third key and sending it to the collaborating client, the collaborating client can only obtain the hashed third key and cannot obtain the blacklist user identity, thus achieving the function of anonymous query. On the other hand, the initiating client generates a first key corresponding to each receiving client, and needs to receive each signature identity data returned by each receiving client, accumulate all the signature identity data to generate a blacklist key, and then perform an on-chain operation, so that the blacklist key contains the signature identity data of all institutions, which is not only conducive to building a trust alliance between institutions, but also realizes the efficient sharing of blacklist data and improves the utilization efficiency of blacklist data. BRIEF DESCRIPTION OF THE DRAWINGS
[0026] Figure 1 A flowchart of a blacklist data sharing method provided in an embodiment of the present application.
[0027] Figure 2 A flowchart of a method for obtaining blacklist data provided in an embodiment of the present application. DETAILED DESCRIPTION
[0028] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.
[0029] The present application provides a blacklist data sharing method. It should be noted that the blacklist data sharing method provided by the present application is applied to a blockchain chain group forming a consortium chain. There are multiple institutions in the consortium chain.
[0030] In addition, the blacklist data sharing method provided in this application does not limit its execution subject. Optionally, the execution subject of the blacklist data sharing method provided in this application can be a client controlled by any organization in the alliance chain.
[0031] The application scenario of this method is that an organization in the alliance chain has a need to upload data to the chain and needs to share the blacklist user details data of a certain user in the alliance chain. In this case, a request to upload the blacklist data to the chain is first initiated through the client of the organization, and then the blacklist data sharing method provided by this method is executed to realize the sharing of the blacklist data.
[0032] like Figure 1 As shown, in one embodiment of the present application, the blacklist data sharing method includes the following S100 to S930:
[0033] S100, the client that sends the blacklist data uplink request is used as the initiator client, and the blacklist user identity of the initiator client is read.
[0034] Specifically, in this embodiment, each organization controls a client. Each client holds blacklist user details data of one or more users. When an organization has a need to share blacklist user details data, it uses the client controlled by itself as the initiator client and issues a blacklist data on-chain request.
[0035] Further, the initiator client reads the blacklist user identity (ID) corresponding to the blacklist user details data that it wants to share. The blacklist user identity can be the user's ID number. User-blacklist user identity-blacklist user details data is a one-to-one correspondence.
[0036] S300, all clients in the alliance chain except the initiator client are regarded as receiving clients, the initiator client hashes the blacklist user identity, and generates a first key corresponding to each receiving client based on the remainder algorithm.
[0037] Specifically, in this step, the initiator client performs a hash algorithm on the blacklist user identity, and then generates a first key based on the remainder algorithm for the hashed structure. It should be noted that the initiator client generates a first key for each receiving client, but the blacklist user identity is unchanged and is held by the initiator client.
[0038] S500: The initiator client sends the first key corresponding to each recipient client to each recipient client.
[0039] Specifically, since the hash algorithm is irreversible, other receiving clients cannot decrypt and restore the blacklist user identity based on the first key, which ensures that the blacklist user identity contained in the first key will not be leaked.
[0040] S700, after receiving the first key, each receiving client extracts the locally stored private key to sign the first key, generates signed identity data and returns the signed identity data to the initiating client.
[0041] Specifically, based on the sharing mechanism of blockchain and to facilitate the establishment of a trust alliance between institutions, in this step, each receiving client extracts the locally stored private key to sign the first key, generates signed identity data and returns it to the initiating client.
[0042] S800, after receiving the signature identity data returned by all the receiving clients, the initiator client accumulates the signature identity data returned by all the receiving clients and the signature identity data of the initiator client, and uses the accumulated result as the symmetric key.
[0043] Specifically, it should be noted that the signature identity data of the initiator client must also be generated, and then the signature identity data of the initiator client and the signature identity data returned by all recipient clients are accumulated, and the accumulated result is used as the symmetric key (K).
[0044] S910, the initiator client performs a hash operation on the symmetric key, and uses a result of the hash operation as a blacklist key.
[0045] Specifically, the blacklist key is used as the key for uplinking in this embodiment.
[0046] S920: The initiator client extracts blacklist user detail data corresponding to the blacklist user identity identifier of the initiator client.
[0047] Specifically, it can be understood that the blacklist user details data can be used as the value corresponding to the key on the chain later.
[0048] S930, the initiator client uses the blacklist key to encrypt the blacklist user details data, uses the encrypted blacklist user details data as the value corresponding to the blacklist key, and synchronously uploads the blacklist key and value to the alliance chain.
[0049] Specifically, in this step, a mapping relationship is established between the blacklist key and the blacklist user details data, that is, the mapping relationship between key and value. After the blacklist key and value are uploaded to the alliance chain synchronously, other institutions can subsequently obtain the encrypted blacklist user details data on the chain through the alliance chain.
[0050] The blacklist data sharing method provided in this embodiment protects the privacy and security of the data on the chain for the client that needs to upload the blacklist data to the chain. On the one hand, by hashing the blacklist user identity identifier to generate a first key and sending it to the receiving client, the receiving client can only obtain the hashed first key and cannot know the blacklist user identity identifier. During the transmission process, it can be ensured that the user's blacklist user identity identifier is not leaked. On the other hand, the initiator client generates a first key corresponding to each receiving client, and needs to receive each signature identity data returned by each receiving client, accumulate all the signature identity data to generate a blacklist key, and then perform the chain operation, so that the blacklist key contains the signature identity data of all institutions, which is not only conducive to building a trust alliance between institutions, but also realizes the efficient sharing of blacklist data and improves the utilization efficiency of blacklist data.
[0051] In one embodiment of the present application, S300 includes the following S310 to S320:
[0052] S310: The initiator client generates a first random number.
[0053] Specifically, the first random number is recorded as r1. The first random number may be a positive integer.
[0054] S320, all clients in the alliance chain except the initiator client are regarded as receiving clients, and the initiator client generates a first key corresponding to each receiving client according to Formula 1.
[0055] P j =[r1 ej ×H(id i )]mod(n j ) Formula 1
[0056] Among them, P j is the first key of the receiving client with serial number j. r1 is the first random number. ej is the first public key element in the public key of the receiving client with serial number j. ej is the result of encrypting the first random number using the first public key element. j is the serial number of the receiving client. id i It is the blacklist identity of the initiator client. i ) is the hash value obtained by hashing the blacklist identity. mod is the remainder symbol. nj The second public key element in the public key of the recipient client with sequence number j.
[0057] Specifically, in this embodiment, each client holds and locally stores the public key and private key generated based on the RSA algorithm. The public key and private key held by each client correspond to its own client serial number. The public key held by each client includes a first public key element and a second public key element. That is, the public key held by each receiving client is (ej, nj), the private key is dj, and j is the serial number of the receiving client. The public key held by the initiator client is (ei, ni), the private key is di, and i is the serial number of the initiator client.
[0058] H(id i ) is a hash value obtained by hashing the blacklist identity. The blacklist identity is the blacklist identity of the initiator client. The hash algorithm may adopt a 256 hash algorithm. Optionally, all hash algorithms mentioned in this application may share the same hash algorithm, for example, all hash algorithms mentioned in this application may share a 256 hash algorithm.
[0059] r1 ej is the result of encrypting the first random number using the first public key element, that is, the result of encrypting r1 using ej. The encryption method can use the RSA algorithm. Since the public keys of all clients are public, the initiating client can obtain the ej of all receiving clients to calculate r1 ej Similarly, the initiator client can obtain the nj of all the receiver clients to execute the subsequent remainder algorithm. For example, if there are 11 organizations in the alliance chain, that is, there is 1 initiator client and 10 receiver clients, then the initiator client will eventually generate 10 first keys in this step.
[0060] In this embodiment, the hash value H(id i ), which increases the security of the first key during transmission. The first random number is encrypted using the first public key element, and the hash value H(id i ) is further blurred, further improving the security of the first key, and greatly increasing the difficulty for other receiving clients to crack the first key and obtain the blacklist identity.
[0061] In one embodiment of the present application, after S300, the method further includes:
[0062] S400, the initiator client extracts the private key of the initiator client, signs the first key corresponding to each recipient client according to Formula 2, and obtains the second key corresponding to each recipient client.
[0063] V j =[H(P j )] di Formula 2
[0064] Where: V j is the second key of the receiving client with serial number j. i is the serial number of the initiating client. di is the private key of the initiating client. j is the first key corresponding to the receiving client with serial number j. j ) is a hash value obtained by hashing the first key.
[0065] Specifically, in this embodiment, after generating a first key, the initiator client also signs the first key to obtain a second key. The second key is obtained by signing the first key using the private key di of the initiator client. Therefore, the initiator client has generated a first key and a second key for each receiving client. For example, if there are 11 institutions in the alliance chain, that is, there are 1 initiator client and 10 receiving clients, then the initiator client will eventually generate 10 first keys and 10 second keys in this step.
[0066] In this embodiment, by setting the second key containing the signature of the initiator client, the subsequent recipient client can verify the legitimacy of the initiator client according to the second key.
[0067] In one embodiment of the present application, when the initiator client sends the first key corresponding to each receiving client to each receiving client, the second key corresponding to each receiving client is also synchronously sent to each receiving client.
[0068] Specifically, a receiving client can thus receive two keys simultaneously.
[0069] In one embodiment of the present application, before S700, S610 to S640 are further included:
[0070] S610, the receiving client extracts the locally stored public key of the initiating client to decrypt the second key to obtain a decryption result.
[0071] S620: The receiving client hashes the first key to generate a hash result.
[0072] S630, the receiving client determines whether the decryption result is equal to the hash result.
[0073] S640, if the decryption result is equal to the hash result, the receiving client further executes the subsequent steps of extracting the locally stored private key to sign the first key, generating signature identity data and returning the signature identity data to the initiating client.
[0074] Specifically, after each receiving client receives the first key and the second key sent by the initiating client, and before the receiving client extracts the locally stored private key to sign the first key, this embodiment is executed.
[0075] This embodiment adds steps S610 to S640.
[0076] The S610 includes the following S611 to S613:
[0077] S611, the receiving client extracts the locally stored public key of the initiating client to decrypt the second key, and determines whether the decryption is successful;
[0078] S612: If the decryption is successful, the decryption result is obtained and the subsequent S620 is executed.
[0079] S613: If the decryption fails, an alarm message is issued and subsequent steps are terminated.
[0080] Since the second key is obtained by signing the first key with the private key di of the initiator client, and the public key of the initiator client is open to all clients, if the receiving client uses the public key of the initiator client to decrypt the second key and the decryption is successful, it indicates that the second key is indeed signed and issued by the legitimate initiator client. If the decryption fails, it indicates that the second key is illegal and the source is suspicious. An alarm message is issued to remind the operator.
[0081] In S620 to S640, the receiving client performs hashing on the first key to obtain H(P j The decryption result of S610 is also H(P j ). If both the first key and the second key are valid, the decryption result should be equal to the hash result.
[0082] If the decryption result is equal to the hash result, it indicates that the first key and the second key are both legal and complete and have not been tampered with, and the subsequent S700 is executed, that is, the receiving client can extract the locally stored private key dj to sign the first key to generate the signature identity data P j dj And return the signed identity data to the initiator client.
[0083] The S600 further includes: S650, if the decryption result is not equal to the hash result, discarding the first key and the second key, issuing an alarm message, and terminating subsequent steps. At this time, it can be considered that the data in the first key and the second key are likely to be tampered with, and the first key and the second key must be discarded.
[0084] In this embodiment, on the one hand, the receiver client extracts the locally stored public key of the initiator client to decrypt the second key, so as to verify the legitimacy of the initiator client. On the other hand, by comparing the decryption result and the hash result, the integrity of the first key and the second key can be verified, and the data in the first key and the second key can be verified without being tampered with during the transmission process.
[0085] In one embodiment of the present application, the S800 includes the following S810 to S830:
[0086] S810, after receiving the signature identity data returned by all the receiving clients, the initiator client calculates the signature identity data of the initiator client according to Formula 3.
[0087] Q i '=[H(id i )] di mod(n i ) Formula 3
[0088] Among them. Q i ' is the signature identity data of the initiator client with serial number i. i is the serial number of the initiator client. id i It is the blacklist identity of the initiator client. i ) is the hash value obtained by hashing the blacklist identity. mod is the remainder symbol. di is the private key of the initiator client with serial number i. i It is the second public key element in the public key of the initiator client with sequence number i.
[0089] Specifically, the above embodiment has explained that the receiving client extracts the locally stored private key dj to sign the first key to generate the signature identity data P j dj , and then returned to the initiating client.
[0090] Therefore, after the initiator client receives the signed identity data returned by all the recipient clients, before calculating the signed identity data of the initiator client according to Formula 3, similar to S610 to S640, the initiator client can use the public key of the recipient client to sign the identity data P j dj Decryption. If the decryption result is obtained successfully, it indicates that the receiving client is trustworthy.
[0091] Then the initiator client can compare the first secret key with the decrypted result. If they are consistent, it means that the decrypted result is indeed P j , indicating that the signature identity data is complete and has not been tampered with, and the subsequent steps of calculating the signature identity data of the initiator client according to Formula 3 can be performed.
[0092] Since the previous step did not calculate the signature identity data of the initiator client, this step calculates the signature identity data of the initiator client through formula 3. Note that since the signature identity data of the initiator client no longer needs to be transmitted to other clients, there is no need to add the first random number r1.
[0093] S820, the initiator client performs defuzzification processing on the signature identity data returned by each recipient client according to Formula 4.
[0094] Q j '=Q j / r1 Formula 4
[0095] Among them. Q j ' is the signature identity data of the recipient client with serial number j after defuzzification. Q j is the signature identity data of the receiving client with serial number j. r1 is the first random number.
[0096] Specifically, the signature identity data does not need to be transmitted anymore, so this step is to divide the signature identity data by r1 to remove the influence of the blurred r1.
[0097] S830, the initiator client accumulates the signature identity data returned by all the recipient clients and the signature identity data of the initiator client, and uses the accumulated result as the symmetric key.
[0098] Specifically, for example, there is 1 initiator client and 10 recipient clients, then the symmetric key is Q i 'Add 10 Qs j 'and.
[0099] In this embodiment, by accumulating all signature identity data as a symmetric key, the symmetric key contains the signature identity data of all institutions. When the blacklist key is generated subsequently, it is not only conducive to building a mutual trust alliance between institutions, which is equivalent to obtaining the consent and approval of all institutions on the chain, but also realizes the efficient sharing of blacklist data and improves the utilization efficiency of blacklist data.
[0100] The present application provides a method for obtaining blacklist data.
[0101] It should be noted that the blacklist data acquisition method provided in this application is applied to a blockchain chain group that forms a consortium chain. There are multiple institutions in the consortium chain.
[0102] In addition, the blacklist data acquisition method provided in this application does not limit its execution subject. Optionally, the execution subject of the blacklist data acquisition method provided in this application can be a client controlled by any organization in the alliance chain.
[0103] The application scenario of this method is that an organization in the alliance chain has the need to obtain the blacklist user details data of a certain user, and needs to query the blacklist user details data of the user in the alliance chain. Then, a blacklist data acquisition request is first initiated through the client of the organization, and then the blacklist acquisition sharing method provided by this method is executed.
[0104] Since the aforementioned content has introduced the blacklist data sharing method, which is used to share the blacklist user details data on the chain, the blacklist data acquisition method provided here is to obtain the blacklist user details data from the chain. The two methods cooperate with each other and are interdependent.
[0105] like Figure 2 As shown, in one embodiment of the present application, the blacklist data acquisition method includes the following W100 to W930:
[0106] W100, the client receiving the blacklist data acquisition request is regarded as the acquisition client, and the acquisition client obtains the blacklist user identity to be queried contained in the blacklist data acquisition request.
[0107] W300 regards all clients in the alliance chain except the acquiring client as the collaborating client. The acquiring client hashes the identity of the user on the blacklist to be queried, and generates a third key corresponding to each collaborating client based on the remainder algorithm.
[0108] W500, the acquiring client sends the third key corresponding to each cooperating client to each cooperating client.
[0109] W700, the acquiring client sends the third key corresponding to each cooperating client to each cooperating client.
[0110] W800, after receiving the signature identity data returned by all the collaborating clients, the acquiring client adds up the signature identity data returned by all the collaborating clients and the signature identity data of the acquiring client, and uses the accumulated result as the symmetric key.
[0111] W910, the acquiring client performs a hash operation on the symmetric key, and uses the result of the hash operation as the blacklist key.
[0112] W920, the acquiring client uses the blacklist key as an index to obtain the value corresponding to the blacklist key on the consortium chain.
[0113] W930, the acquiring client uses the blacklist key to decrypt the value and obtains the blacklist user detail data corresponding to the blacklist user identity to be queried.
[0114] Specifically, the principles of W100 to W800 in this method are the same as those of S100 to S800 in the aforementioned blacklist data sharing method, and will not be repeated here. Similarly, the acquiring client can be any client among all the clients in the alliance chain (the acquiring client is similar to the initiating client in the blacklist data sharing method, but the two methods are applied in different scenarios), and other clients exist as collaborative clients (collaborative clients are similar to the receiving clients in the aforementioned blacklist data sharing method).
[0115] The difference is that in W100 to W800, the acquiring client hashes the blacklist user identity to be queried, rather than the acquiring client's own blacklist user identity. In S100 to S800, the initiating client hashes the initiating client's own blacklist user identity.
[0116] The blacklist user identity to be queried is included in the blacklist data acquisition request. For example, if user A wants to query the blacklist user details data stored by user A on the chain, then user A's blacklist user identity (id) may not be originally held by the acquiring client, but user A can still obtain the blacklist user details data stored on the chain from the acquiring client. As long as user A establishes a blacklist data acquisition request and attaches user A's blacklist user identity in the blacklist data acquisition request, user A then sends the blacklist data acquisition request to the acquiring client.
[0117] It can be understood that through the blacklist data sharing method described above, many mapping pairs of blacklist keys and values are stored on the alliance chain. Then, through W910 to W930 of this method, the blacklist key can be used as an index to obtain the value corresponding to the blacklist key on the alliance chain. Then, the blacklist key is used to decrypt the value to obtain the blacklist user details data corresponding to the blacklist user identity to be queried.
[0118] This embodiment protects the privacy and security of the data on the chain for the client that needs to obtain the blacklist data from the chain. On the one hand, by hashing the blacklist user identity to be queried to generate a third key and sending it to the collaborating client, the collaborating client can only obtain the hashed third key and cannot learn the blacklist user identity, thus achieving the function of anonymous query. On the other hand, the initiating client generates a first key corresponding to each receiving client, and needs to receive each signature identity data returned by each receiving client, accumulate all the signature identity data to generate the blacklist key, and then perform the chain operation, so that the blacklist key contains the signature identity data of all institutions, which is not only conducive to building a trust alliance between institutions, but also realizes the efficient sharing of blacklist data and improves the utilization efficiency of blacklist data.
[0119] In one embodiment of the present application, W300 includes the following W310 to W320:
[0120] W310, the acquiring client generates a second random number.
[0121] W320, all clients in the alliance chain except the acquiring client are regarded as collaborating clients, and the acquiring client generates a third key corresponding to each collaborating client according to Formula 5.
[0122] P k =[r2 ek ×H(id)]mod(n k ) Formula 5
[0123] Among them, P k is the third key of the collaborative client with serial number k. r2 is the second random number. ek is the first public key element in the public key of the collaborative client with serial number k. ek is the result of encrypting the second random number using the first public key element. k is the serial number of the collaborative client. id is the blacklist user identity to be queried. H(id) is the hash value obtained by hashing the blacklist identity. mod is the remainder symbol. n k It is the second public key element in the public key of the collaborative client with sequence number k.
[0124] Specifically, the principles of W310 to W320 are consistent with the principles of S310 to S320 in the aforementioned blacklist data sharing method, and will not be repeated here. The difference is that the random number used in formula 5 is another random number, namely the second random number. The value of the second random number is not equal to the first random number. The id used in formula 5 is the blacklist user identity to be queried, rather than the blacklist identity of the acquiring client.
[0125] In this embodiment, the security of the third key during transmission is increased by setting a second random number to deobfuscate the hash value H(id). By encrypting the second random number using the first public key element, the hash value H(id) can be further obfuscated, further improving the security of the third key and greatly increasing the difficulty for other collaborative clients to crack the third key and obtain the blacklist identity to be queried.
[0126] In one embodiment of the present application, after W300, the method further includes:
[0127] W400, the acquiring client extracts the private key of the acquiring client, signs the third key corresponding to each collaborating client according to Formula 6, and obtains the fourth key corresponding to each collaborating client.
[0128] V k =[H(P k )] dm Formula 6
[0129] Where: V k is the fourth key of the cooperating client with serial number k. m is the serial number of the acquiring client. dm is the private key of the acquiring client with serial number m. k is the third key corresponding to the collaborative client with serial number k. k ) is the hash value obtained by hashing the third key. ,
[0130] Specifically, the principle of W400 is consistent with that of S300 in the aforementioned blacklist data sharing method, and will not be repeated here.
[0131] In this embodiment, by setting the fourth key containing the signature of the acquirer client, the subsequent receiving client can verify the legitimacy of the acquirer client according to the fourth key.
[0132] In one embodiment of the present application, when the acquirer client sends the third key corresponding to each cooperating client to each cooperating client, the acquirer client also synchronously sends the fourth key corresponding to each cooperating client to each cooperating client.
[0133] Specifically, the collaborating client can thus receive two keys simultaneously.
[0134] Optionally, after each collaborating client receives the third key and the fourth key sent by the acquiring client, before the collaborating client extracts the locally stored private key to sign the third key, steps similar to S610 to S640 in the blacklist data sharing method can be executed to verify the legitimacy of the acquiring client and the integrity of the third key and the fourth key. The details will not be repeated here, and the principle is the same as that of S610 to S640 in the blacklist data sharing method.
[0135] In one embodiment of the present application, W800 includes the following W810 to W830:
[0136] W810, after receiving the signature identity data returned by all the collaborating clients, the acquiring client calculates the signature identity data of the acquiring client according to Formula 7.
[0137] Q m '=[H(id)] dm mod(n m ) Formula 7
[0138] Among them. Q m ' is the signature identity data of the acquiring client with serial number m. m is the serial number of the acquiring client. id is the identity of the blacklist user to be queried. H(id) is the hash value obtained by hashing the blacklist user identity to be queried. mod is the remainder symbol. dm is the private key of the acquiring client with serial number m. n m It is the second public key element in the public key of the acquiring client with sequence number m.
[0139] W820, the acquiring client performs defuzzification processing on the signature identity data returned by each cooperating client according to Formula 8.
[0140] Q k '=Q k / r2 Formula 8
[0141] Among them. Q k ' is the signature identity data of the collaborative client with serial number k after defuzzification. Q k is the signature identity data of the collaborative client with serial number k. r2 is the second random number.
[0142] W830, the acquiring client adds up the signature identity data returned by all the collaborating clients and the acquiring client's signature identity data, and uses the accumulated result as the symmetric key.
[0143] Specifically, the principles of W810 to W830 in this embodiment are similar to those of S810 to S830 in the aforementioned blacklist data sharing method, and are not repeated here.
[0144] In this embodiment, by accumulating all signature identity data as a symmetric key, the symmetric key contains the signature identity data of all organizations. When a blacklist key key is subsequently generated, a blacklist key key that is exactly the same as the blacklist key key generated when uploading to the chain in the aforementioned blacklist data sharing method can be generated, and the blacklist user details data corresponding to the blacklist user identity identifier to be queried can be queried from the chain based on the blacklist key key. This embodiment also reflects the mutually coupled relationship between the blacklist data sharing method and the blacklist data acquisition method.
[0145] The technical features of the above-described embodiments may be arbitrarily combined, and the execution order of the method steps is not limited. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0146] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.
Claims
1. A blacklist data sharing method, characterized in that: The method comprises: The client that sends the blacklist data upload request is regarded as the initiator client, and the blacklist user identity of the initiator client is read; All clients in the alliance chain except the initiator client are regarded as the receiving clients. The initiator client hashes the blacklist user identity and generates a first key corresponding to each receiving client based on the remainder algorithm; The initiator client extracts the private key of the initiator client, signs the first key corresponding to each recipient client, and obtains the second key corresponding to each recipient client; The initiator client sends the first key and the second key corresponding to each recipient client to each recipient client; After each receiving client receives the first key and the second key, the receiving client extracts the public key of the initiating client stored locally to decrypt the second key to obtain a decryption result; The receiving client hashes the first key to generate a hash result; The receiving client determines whether the decryption result is equal to the hash result; If the decryption result is not equal to the hash result, the first key and the second key are discarded, an alarm message is issued, and subsequent steps are terminated; If the decryption result is equal to the hash result, the locally stored private key is extracted to sign the first key, signature identity data is generated and the signature identity data is returned to the initiator client; After receiving the signature identity data returned by all the receiving clients, the initiator client adds the signature identity data returned by all the receiving clients and the signature identity data of the initiator client, and uses the accumulated result as the symmetric key; The initiator client performs a hash operation on the symmetric key and uses the result of the hash operation as the blacklist key; The initiator client extracts the blacklist user detail data corresponding to the blacklist user identity identifier of the initiator client; The initiator client uses the blacklist key to encrypt the blacklist user details data, uses the encrypted blacklist user details data as the value corresponding to the blacklist key, and synchronously uploads the blacklist key and value to the alliance chain; All clients except the initiator client in the alliance chain are regarded as receiving clients. The initiator client hashes the blacklist user identity and generates a first key corresponding to each receiving client based on the remainder algorithm, including: The initiator client generates a first random number; All clients in the alliance chain except the initiator client are regarded as the receiver clients. The initiator client generates the first key corresponding to each receiver client according to Formula 1; P j =[r1 ej ×H(id i )]mod(n j ) Formula 1; Among them, P j is the first key of the receiving client with serial number j, r1 is the first random number, ej is the first public key element in the public key of the receiving client with serial number j, r1 ej is the result of encrypting the first random number using the first public key element, j is the serial number of the receiving client, id i is the blacklist identity of the initiator client, H (id i ) is the hash value obtained by hashing the blacklist identity, mod is the remainder symbol, n j The second public key element in the public key of the recipient client with sequence number j.
2. The blacklist data sharing method according to claim 1, characterized in that: The initiator client extracts the private key of the initiator client, signs the first key corresponding to each recipient client, and obtains the second key corresponding to each recipient client, including: The initiator client extracts the private key of the initiator client, signs the first key corresponding to each recipient client according to Formula 2, and obtains the second key corresponding to each recipient client; V j =[H(P j )] di Formula 2; Among them, V j is the second key of the receiving client with serial number j, i is the serial number of the initiating client, di is the private key of the initiating client, P j is the first key corresponding to the receiving client with serial number j, H(P j ) is a hash value obtained by hashing the first key.
3. The blacklist data sharing method according to claim 2, characterized in that: After receiving the signature identity data returned by all the receiving clients, the initiator client adds the signature identity data returned by all the receiving clients and the signature identity data of the initiator client, and uses the accumulated result as the symmetric key, including: After the initiator client receives the signature identity data returned by all the recipient clients, it calculates the signature identity data of the initiator client according to Formula 3; Q i '=[H(id i )] di mod(n i ) Formula 3; Among them, Q i ' is the signature identity data of the initiator client with serial number i, i is the serial number of the initiator client, id i is the blacklist identity of the initiator client, H (id i ) is the hash value obtained by hashing the blacklist identity, mod is the remainder symbol, di is the private key of the initiator client with serial number i, and n i The second public key element in the public key of the initiator client with sequence number i; The initiator client performs defuzzification processing on the signature identity data returned by each recipient client according to Formula 4; Q j '=Q j / r1 Formula 4; Among them, Q j ' is the signature identity data of the recipient client with serial number j after defuzzification, Q j is the signature identity data of the recipient client with serial number j, and r1 is the first random number; The initiator client accumulates the signature identity data returned by all the recipient clients and the signature identity data of the initiator client, and uses the accumulated result as the symmetric key.
4. A method for obtaining blacklist data, characterized in that: include: The client receiving the blacklist data acquisition request is regarded as an acquisition client, and the acquisition client acquires the blacklist user identity to be queried contained in the blacklist data acquisition request; All clients in the alliance chain except the acquiring client are regarded as collaborative clients. The acquiring client hashes the blacklist user identity to be queried, and generates a third key corresponding to each collaborative client based on the remainder algorithm; The acquiring client extracts the private key of the acquiring client, signs the third key corresponding to each coordinating client, and obtains the fourth key corresponding to each coordinating client; The acquiring client sends the third key and the fourth key corresponding to each cooperating client to each cooperating client; After receiving the third key and the fourth key, each collaborating client extracts the locally stored private key to sign the third key, generates signature identity data and returns the signature identity data to the acquiring client; after receiving the signature identity data returned by all collaborating clients, the acquiring client accumulates the signature identity data returned by all collaborating clients and the signature identity data of the acquiring client, and uses the accumulated result as the symmetric key; The acquiring client performs a hash operation on the symmetric key and uses the result of the hash operation as the blacklist key; The acquiring client uses the blacklist key as an index to obtain the value corresponding to the blacklist key on the consortium chain; The acquiring client uses the blacklist key to decrypt the value and obtains the blacklist user details data corresponding to the blacklist user identity to be queried; All clients in the alliance chain except the acquiring client are regarded as collaborative clients. The acquiring client hashes the identity of the blacklisted user to be queried, and generates a third key corresponding to each collaborative client based on the remainder algorithm, including: The acquiring client generates a second random number; All clients in the alliance chain except the acquirer client are regarded as collaborator clients. The acquirer client generates a third key corresponding to each collaborator client according to Formula 5. P k =[r2 ek ×H(id)]mod(n k ) Formula 5; Among them, P k is the third key of the collaborative client with serial number k, r2 is the second random number, ek is the first public key element in the public key of the collaborative client with serial number k, r2 ek is the result of encrypting the second random number using the first public key element, k is the serial number of the collaborative client, id is the blacklist user identity to be queried, H(id) is the hash value obtained by hashing the blacklist identity to be queried, mod is the remainder symbol, and n k It is the second public key element in the public key of the collaborative client with sequence number k.
5. The method for obtaining blacklist data according to claim 4, characterized in that: The acquiring client extracts the private key of the acquiring client, signs the third key corresponding to each coordinating client, and obtains the fourth key corresponding to each coordinating client, including: The acquiring client extracts the private key of the acquiring client, and signs the third key corresponding to each cooperating client according to Formula 6 to obtain the fourth key corresponding to each cooperating client; V k =[H(P k )] dm Formula 6; Among them, V k is the fourth key of the cooperating client with serial number k, m is the serial number of the acquiring client, dm is the private key of the acquiring client with serial number m, P k is the third key of the collaborating client with serial number k, H(P k ) is a hash value obtained by hashing the third key.
6. The method for obtaining blacklist data according to claim 5, characterized in that: After receiving the signature identity data returned by all the collaborating clients, the acquiring client adds up the signature identity data returned by all the collaborating clients and the signature identity data of the acquiring client, and uses the accumulated result as the symmetric key, including: After receiving the signature identity data returned by all the collaborating clients, the acquiring client calculates the signature identity data of the acquiring client according to Formula 7; Q m '=[H(id)] dm mod(n m ) Formula 7; Among them, Q m ' is the signature identity data of the acquiring client with serial number m, m is the serial number of the acquiring client, id is the identity of the blacklist user to be queried, H(id) is the hash value obtained by hashing the blacklist user identity to be queried, mod is the remainder symbol, dm is the private key of the acquiring client with serial number m, n m The second public key element in the public key of the acquiring client with sequence number m; The acquiring client performs defuzzification processing on the signature identity data returned by each cooperating client according to Formula 8; Q k =Q k / r2 Formula 8; Among them, Q k ' is the signature identity data of the collaborative client with serial number k after defuzzification, Q k is the signature identity data of the collaborative client with serial number k, and r2 is the second random number; The acquiring client accumulates the signature identity data returned by all the collaborating clients and the signature identity data of the acquiring client, and uses the accumulated result as the symmetric key.