Service request verification method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a service request verification method and device, electronic equipment and storage medium. The method comprises: based on the service application request of a user, signing a set data packet using a user private key to generate a first target signature; sending the first target signature to an authorized end to enable the authorized end to verify the first target signature, and in the case where the verification is passed, signing the identity label, set commitment protocol parameters and proof type label using an authorized end private key to generate a second target signature; based on the service application request, generating range proof information according to a ring signature range proof protocol, signing the identity label and range proof information using a user private key to generate a third target signature, and sending the third target signature to a service provider end to enable the service provider end to verify the third target signature based on the second target signature through an identity verification end. The present application has high security.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information security, and particularly relates to a service request verification method and device, electronic equipment and a storage medium. BACKGROUND

[0002] In the existing permission management method, a permission management institution issues a permission-containing credential to a user, and when the user needs to access a service, the credential is submitted to a service provider. The service provider verifies the validity of the credential and confirms the permission match, and then provides the service to the user. In this process, sensitive information (such as income, age, occupation, etc.) in the user credential is transmitted to the service provider in plaintext form, resulting in direct exposure of user privacy and low security. SUMMARY

[0003] The present application provides a service request verification method, device, electronic equipment and storage medium, which has high security.

[0004] In a first aspect, the present application provides a service request verification method applied to a client, and the method comprises the following steps.

[0005] Based on a service application request of a user, a user private key is used to perform a signature operation on a set data packet to generate a first target signature. The set data packet includes an identity, a set commitment protocol parameter, a zero-knowledge proof parameter, and plaintext information corresponding to the service application request. The set commitment protocol parameter is used to hide the plaintext information from the outside.

[0006] The first target signature is sent to an authorized end, so that the authorized end verifies the first target signature. If the verification is passed, the authorized end private key is used to perform a signature operation on the identity, the set commitment protocol parameter, and a proof type label to generate a second target signature. The second target signature is used to be stored in an identity verification end.

[0007] Based on the service application request, a range proof information is generated according to a ring signature range proof protocol. The user private key is used to perform a signature operation on the identity and the range proof information to generate a third target signature. The third target signature is sent to a service provider, so that the service provider verifies the third target signature based on the second target signature through the identity verification end.

[0008] Optionally, the first target signature is sent to the authorized end to make the authorized end verify the first target signature, and the method comprises the following steps.

[0009] The first target signature is sent to an authorized end, so that the authorized end obtains a public key of the user at an identity verification end, and verifies the first target signature according to the public key of the user.

[0010] Optionally, before the signing operation on the set data packet using the user private key based on the service application request of the user, the method further comprises:

[0011] generating a target random number;

[0012] generating set commitment protocol parameters and zero-knowledge proof parameters according to the target random number;

[0013] determining a set data packet based on the identity, the set commitment protocol parameters, the zero-knowledge proof parameters, and plaintext information corresponding to the service application request.

[0014] Optionally, the set commitment protocol parameters are Pedersen commitment parameters.

[0015] In a second aspect, an embodiment of the present application provides a service request verification device, applied to a client, and the device comprises:

[0016] a first signature module, configured to perform a signing operation on a set data packet using a user private key based on a service application request of the user, to generate a first target signature, wherein the set data packet comprises an identity, set commitment protocol parameters, zero-knowledge proof parameters, and plaintext information corresponding to the service application request, and the set commitment protocol parameters are used to hide the plaintext information from the outside;

[0017] a verification module, configured to send the first target signature to an authorized end, so that the authorized end verifies the first target signature, and performs a signing operation on the identity, the set commitment protocol parameters, and a proof type label using an authorized end private key in a case where the verification is passed, to generate a second target signature, wherein the second target signature is used to be stored to an identity verification end;

[0018] a second signature module, configured to generate range proof information according to a ring signature range proof protocol based on the service application request, perform a signing operation on the identity and the range proof information using the user private key, generate a third target signature, and send the third target signature to a service providing end, so that the service providing end verifies the third target signature based on the second target signature through the identity verification end.

[0019] Optionally, the verification module is configured to send the first target signature to an authorized end, so that the authorized end obtains a public key of the user at an identity verification end, and verifies the first target signature according to the public key of the user.

[0020] Optionally, the apparatus further comprises:

[0021] The determining module is configured to generate a target random number, generate a commitment protocol parameter and a zero-knowledge proof parameter according to the target random number, and determine a setting data packet based on the identity, the commitment protocol parameter, the zero-knowledge proof parameter, and the plaintext information corresponding to the service application request.

[0022] Optionally, the commitment protocol parameter is a Pedersen commitment parameter.

[0023] In a third aspect, an electronic device is provided, and the electronic device comprises a memory, a processor, and a communication interface. The memory stores executable code. When the executable code is executed by the processor, the processor performs the method in the first aspect.

[0024] In a fourth aspect, a non-transitory machine-readable storage medium is provided, and the non-transitory machine-readable storage medium stores executable code. When the executable code is executed by a processor of an electronic device, the processor performs the method in the first aspect.

[0025] In a fifth aspect, a computer program product is provided, and the computer program product comprises a computer program. When the computer program is executed by a processor of an electronic device, the processor performs the method in the first aspect.

[0026] In the embodiment of the present application, by using the user private key to sign the identity, the commitment protocol parameter, the zero-knowledge proof parameter, and the plaintext information corresponding to the service application request, a first target signature is generated, and the first target signature is sent to the authorized end. The authorized end can verify the first target signature, and in the case of passing the verification, the identity, the commitment protocol parameter, and the proof type label are signed by the private key of the authorized end to generate a second target signature, and the second target signature is stored in the identity verification end. It is ensured that the identity verification end finally stores only the identity, the commitment protocol parameter, and the proof type label, and does not need to store the plaintext information corresponding to the service application request. Then, the user generates range proof information according to the ring signature range proof protocol based on the service application request, signs the identity and the range proof information by using the user private key to generate a third target signature, and sends the third target signature to the service provider, so that the service provider verifies the third target signature based on the second target signature through the identity verification end (verifies the user's authority independently after the identity verification end obtains the zero-knowledge proof parameter). The whole process does not directly provide its own authority to the service provider, and at the same time successfully completes the verification of the service request, avoids privacy exposure (that is, avoids exposure of plaintext information), and has high security. BRIEF DESCRIPTION OF DRAWINGS

[0027] The drawings described herein are used to provide further understanding of the present application, and form a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application, and do not constitute an improper limitation on the present application. In the drawings:

[0028] Figure 1 A flowchart of a service request verification method provided for an exemplary embodiment of the present application;

[0029] Figure 2 An application schematic diagram of a service request verification method provided for an exemplary embodiment of the present application;

[0030] Figure 3 A structural schematic diagram of a service request verification device provided for an exemplary embodiment of the present application;

[0031] Figure 4 A structural schematic diagram of an electronic device provided for an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0032] In order to make the purposes, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be described clearly and completely below in combination with specific embodiments of the present application and corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0033] In the existing permission management method, the permission management mechanism issues a permission-containing credential to the user, and when the user needs to access the service, the credential is submitted to the service provider. The service provider verifies the validity of the credential and confirms the permission match, and then provides the service to the user. In this process, the sensitive information (such as income, age, occupation, etc.) in the user credential is transmitted to the service provider in plaintext form, resulting in direct exposure of user privacy and low security.

[0034] In view of this, the embodiments of the present application provide a service request verification method, Figure 1 A flowchart of a service request verification method provided by the embodiments of the present application is shown in FIG. 1. The method is applied to a client, such as a user terminal, and the method includes the following steps. Figure 1

[0035] Step 101, based on the service application request of the user, using the user private key to sign the set data packet, generating the first target signature, the set data packet includes the identity, the set commitment protocol parameter, the zero-knowledge proof parameter, and the plaintext information corresponding to the service application request, the set commitment protocol parameter is used to hide the plaintext information to the outside.

[0036] Step 102, the first target signature is sent to the authorized end, so that the authorized end verifies the first target signature, and in the case of passing the verification, the identity, the set commitment protocol parameter, and the proof type label are signed by the private key of the authorized end, to generate the second target signature, the second target signature is used to store to the identity verification end.

[0037] Step 103, based on the service application request, generating range proof information according to the ring signature range proof protocol, using the user private key to sign the identity and the range proof information, generating the third target signature, and sending the third target signature to the service provider, so that the service provider verifies the third target signature based on the second target signature through the identity verification end.

[0038] ​It should be noted that the authorization end, the identity verification end and the service providing end can be respectively deployed on different servers, wherein the identity verification end can be a decentralized identifier (DID) platform, which is an identity management system based on a block chain or a distributed ledger technology, and is used for generating, storing and managing a DID identifier of a user and associated metadata (DID Document) thereof. Its core goal is to realize decentralized identity control and avoid relying on a single authority.

[0039] For ease of understanding, the following will be combined with Figure 2 The present scheme will be specifically illustrated by taking the identity verification end as a DID platform as an example.

[0040] In actual application, a user pre-generates an identity (also referred to as a DID identifier) of the user through a DID platform, and stores a metadata document (also referred to as a DID Document) bound with the DID identifier in the DID platform, wherein the DID Document contains a public key list for verifying a user signature and encrypted communication, and the public key list can be used to retrieve the public key of the user based on the DID identifier.

[0041] Suppose the application scenario is as follows:

[0042] User A (DID identifier did A , public key PK A ) has an annual income of n A = 50w, and needs to apply for an income certificate to a salary line B (i.e. the authorization end), the salary line B issues an income certificate, and sends the income certificate to the DID platform. Then, user A applies for a loan to bank C (i.e. the service providing end), and bank C requires that the annual income of the user is not less than n C = 40w, and bank C performs verification after obtaining the Pedersen commitment parameter and the zero-knowledge proof parameter of user A through the DID platform.

[0043] In specific implementation, user A generates a target random number r through a client, wherein r∈Z n . According to the target random number, set commitment protocol parameters (i.e. Pedersen commitment parameters) and zero-knowledge proof parameters are generated, and the specific formula is as follows:

[0044] Pedersen commitment parameter: commit = n A H + rG.

[0045] wherein n AThe actual annual income of user A (i.e., the plaintext information corresponding to the service application request described above), r is a target random number, H and G are public base points of an elliptic curve, H = bG, b is unknown to any entity, that is, the calculation relationship of H and G is unknown.

[0046] By using the Pedersen commitment, the actual annual income n of the user can be hidden A and the target random number r, so that an external party cannot directly deduce sensitive information from the commit. At the same time, the actual annual income n of user A is bound to the target random number r, ensuring the uniqueness and unforgeability of subsequent verification.

[0047] Zero-knowledge proof parameter: zk_prove(rG, r) = (R, z).

[0048] In specific implementation, the generation of the proof includes the following steps:

[0049] S1, calculate R = aG according to the random number a.

[0050] S2, calculate the challenge value c, c = Hash(R, rG).

[0051] S3, generate the response z, z = a + c x r.

[0052] S4, output the proof (R, z).

[0053] After that, the salary line B needs to calculate c = Hash(R, commit-n A H) first, and then verify whether the following equation is true: zG = R + c(commit-n A H), if the equation is true, it proves that the user knows the random number r, and the commit correctly binds n A = 50w.

[0054] It should be noted that the zero-knowledge proof is a non-interactive Schnorr zero-knowledge proof, and user A generates a zero-knowledge proof through the non-interactive Schnorr protocol, that is, through (R, z), proves to the salary line B that he knows the target random number r used to generate the commit, but does not need to disclose the specific value of the target random number r, so that the generation process of the commit is ensured to be legal, and the user from faking a false commitment.

[0055] After that, according to the identity identifier did A , the commitment protocol parameter commit, the zero-knowledge proof parameter (R, z), and the plaintext information n A corresponding to the service application request, the setting data packet is determined. And use the user private key sk A to sign the setting data packet to generate the first target signature and sends the first target signature and the setting data packet to the bank B (i.e. the authorized end).

[0056] After receiving the first target signature and the setting data packet, the bank B verifies the first target signature according to the public key of the user. The specific process is as follows:

[0057] The bank B verifies the DID identifier did A of the user A in the first target signature according to the DID Document of the user A. A After that, the integrity of the DID Document is verified (such as checking the blockchain transaction hash or the platform signature) to ensure that the public key PK A of the user A is not tampered with.

[0058] The did A , commit, (R, z), n A in the first target signature is spliced and reorganized according to the order when the signature is generated (the splicing order must be exactly the same as when the user A generates the first target signature, otherwise the hash value will not match). After that, according to the protocol agreement (such as SHA-256 or an elliptic curve-based hash function), the reorganized data is hashed, and the first target signature is verified according to the Schnorr signature verification rule. If the verification is passed, the actual annual income n A of the user A is determined by searching the database of the bank B. It should be noted that in the embodiments of the present application, in addition to using the Schnorr signature algorithm, the Edwards-curve Digital Signature Algorithm (EdDSA) algorithm and the like can also be used, which are not limited herein.

[0059] After that, the bank B verifies the zero-knowledge proof zk_verify(commit-n A ×H, R, z), i.e. verifies that the user A holds the secret value (i.e. the target random number) r, which satisfies rG = commit-n A ×H. If the verification is passed, it means that the commitment of the user A is legal. At this time, the bank B uses the private key of the authorized end to sign the identity identifier did A , the setting commitment protocol parameter commit, and the proof type label annualsalary, to generate the second target signature sign B , and sends the second target signature sign B and the signed data to the DID platform, and the DID platform uses the public key of the authorized party to verify sign Bthe effectiveness of the second target signature sign B and the signed data record is stored.

[0060] annualsalary, which can be a string label indicating that the type of this certificate is "annual salary". By using annualsalary, different types of permission certificates (such as income certificates and educational certificates) can be distinguished, which facilitates the organization of data by the DID platform. In addition, when bank C verifies the user's qualifications later, it can directly locate the required certificate through the label, improving efficiency.

[0061] It should be noted that in addition to the above verification operation, it is also necessary to confirm that the attribute value submitted by user A (i.e., user A's annual income is 50w) is consistent with reality. In specific implementation, bank B can query the internal server for user A's salary record to determine whether the annual income data submitted by user A is consistent with the salary record of user A recorded in the internal server of bank B. If they are consistent, it is confirmed that the attribute value submitted by user A is consistent with reality. At this time, bank B signs the identity identifier did B the identity identifier did A , sets the commitment protocol parameter commit, and signs the proof type label annualsalary to ensure that the data submitted to the DID platform has not been tampered with. If any part is modified, the signature verification will fail.

[0062] After that, user A needs to prove his actual annual income n A (50w) is greater than the minimum income requirement n C (40w). To do this, first, calculate the difference commitment: commit diff = commit-n C ×H=(50H+rG)-40H=10H+rG. The commit diff represents the encrypted form of the difference between user A's income and the minimum requirement, which can represent the difference (10w) between user A's actual income value (50w) and the minimum requirement (40w) in encrypted form (10H+rG), avoiding exposure of the actual value. Subsequently, the range proof (range_prove) can be used to verify whether the difference is non-negative (i.e., n A ≥n C ) without revealing the specific value of n A .

[0063] Subsequently, according to the ring signature range proof protocol, generate range proof information proof, proof=range_prove(commit-n C H,n A -nC , and the identity didAis signed by the user private key skA. A , range proof information proof, loan income requirement n C , and the identity didAis signed by the user private key skA. A2 , The third target signature sign A2 and the signed data are sent to bank C (the service provider).

[0064] Bank C obtains the public key PK A of user A and the income proof record (i.e., the second target signature sign B and the signed data) through the DID platform, verifies the validity of sign A2 based on the same method as above, and exits and outputs false if the verification fails. If the verification is successful, it is confirmed that the service application of user A has not been tampered with. At this time, range_verify(commit C H, proof) is performed to check whether commit diff = commit-40H is equal to the cumulative sum of all PKS i[0] in the range proof, and the validity of the ring signature σ i is verified for each PKS 0 (e.g., PKS0corresponds to 2 1 = 1, PKS1corresponds to 2 i = 2, etc.), to ensure that each bit b i ∈{0,1}. If all the verifications pass, it is proved that the income of user A is ≥40w, and bank C can approve the loan and perform the mortgage operation.

[0065] It should be noted that in the range proof, each binary bit i corresponds to a public key set PKS i , which specifically includes two elements:

[0066] PKS i[0] : represents the possible commitment value of the binary bit. If b i = 1, then PKS i[0] = 2 i H + r i G; if b i = 0, then PKS i[0] = r i G.

[0067] PKS i[1] : a supplementary item for verifying the legality of the binary bit, such as PKS i[1] = PKS i[0] - 2 i H.

[0068] By checking whether the accumulation of all PKSs i[0] equals commit diff , the correctness of binary decomposition is ensured. If all verifications pass, it proves that the income of user A is ≥ 40w, and bank C can approve the loan, and execute the mortgage operation.

[0069] As for ring signature σi, its generation process mainly includes:

[0070] S1, decompose the difference v between n A and n C into k-bit binary data, that is:

[0071]

[0072] where bi∈{0,1}, assuming v=10, k=4, it can be decomposed into b3b2b1b0=1010.

[0073] S2, generate the corresponding Pedersen commitment for each binary bit b i :

[0074] m i = b i ·2 i ·H + r i ·G

[0075] where r i is a random number, and satisfies

[0076] S3, define two possible commitments for each binary bit i:

[0077] PKS i = {m i , m i - 2 i ·H}

[0078] If b i = 0, then m i = 0×2 i ×H + r i ×G = r i ×G.

[0079] If b i = 1, then m i = 2 i ×H + r i ×G, and m i - 2 i ×H = r i ×G.

[0080] S4, for each binary bit i, generate a ring signature σ using a ring signature protocol i :

[0081] σ i = ring_sign(m i , r i , PKS i )

[0082] S5, the final proof contains all (PKS i , σ i ):

[0083] proof = {(PKS i , σ i ) | i = 0, 1,..., k-1}

[0084] Based on the above, in the embodiments of the present application, the content sent by user A to bank B includes n A and Bank B holds the actual income of user A, and bank B cannot see r in the commit, bank C only verifies whether the income of user A satisfies ≥ 40w, without needing to know the specific value (50w). The embodiments of the present application solve the core problem of privacy leakage in the existing permission management by combining Pedersen commitment with zero-knowledge proof. The user permission is stored and verified in an encrypted form, and the service provider can only confirm the permission compliance, and cannot obtain sensitive information. For example, when the user applies for a loan, the bank only verifies whether the income of the user meets the standard, without knowing the specific value, thereby realizing real privacy protection. Moreover, all the above operations are stored through digital signature and on-chain storage, thereby ensuring the data integrity.

[0085] The service request verification method provided by the embodiment of the application can make the authorization end verify the first target signature, and in the case of verification passing, use the private key of the authorization end to perform signature operation on the identity identifier, the commitment protocol parameter, and the proof type label, generate a second target signature, and store the second target signature to the identity identifier verification end, so that the identity identifier verification end finally stores only the identity identifier, the commitment protocol parameter, and the proof type label, and does not need to store the plaintext information corresponding to the service application request. Then, the user generates range proof information according to the ring signature range proof protocol based on the service application request, performs signature operation on the identity identifier and the range proof information using the private key of the user, generates a third target signature, and sends the third target signature to the service providing end, so that the service providing end verifies the third target signature based on the second target signature through the identity identifier verification end (verifies the user permission independently after the identity identifier verification end obtains the zero-knowledge proof parameter). The whole process does not directly provide the permission of the user to the service providing end, and at the same time, successfully completes the verification of the service request, avoids privacy exposure, and has high security.

[0086] Figure 3 A structural schematic diagram of a service request verification device provided by the embodiment of the application is shown in the figure, and the device is applied to a client end. Figure 3 As shown in the figure, the device comprises a first signature module 31, a verification module 32, and a second signature module 33.

[0087] The first signature module 31 is configured to perform signature operation on a set data packet using a private key of a user based on a service application request of the user, generate a first target signature, the set data packet comprises an identity identifier, a commitment protocol parameter, a zero-knowledge proof parameter, and plaintext information corresponding to the service application request, and the commitment protocol parameter is used to hide the plaintext information to the outside.

[0088] The verification module 32 is configured to send the first target signature to an authorization end, so that the authorization end verifies the first target signature, and in the case of verification passing, performs signature operation on the identity identifier, the commitment protocol parameter, and the proof type label using a private key of the authorization end, generates a second target signature, and stores the second target signature to an identity identifier verification end.

[0089] The second signature module 33 is configured to generate range proof information according to a ring signature range proof protocol based on the service application request, perform signature operation on the identity and the range proof information using the private key of the user, generate a third target signature, and send the third target signature to the service provider, so that the service provider verifies the third target signature based on the second target signature through the identity verification end.

[0090] Optionally, the verification module 32 is configured to send the first target signature to an authorization end, so that the authorization end acquires the public key of the user through the identity verification end and verifies the first target signature according to the public key of the user.

[0091] Optionally, the apparatus further includes a determination module configured to generate a target random number, generate set commitment protocol parameters and zero-knowledge proof parameters according to the target random number, and determine a set data packet based on the identity, the set commitment protocol parameters, the zero-knowledge proof parameters, and plaintext information corresponding to the service application request.

[0092] Optionally, the set commitment protocol parameters are Pedersen commitment parameters.

[0093] Figure 3 The apparatus can perform the steps in the foregoing embodiments, and the detailed execution process and technical effects are described in the foregoing embodiments, which will not be described here.

[0094] Embodiments of the present application also provide an electronic device, as shown in the figure, which can include a processor 41, a memory 42, and a communication interface 43. The memory 42 stores executable code, which, when executed by the processor 41, causes the processor 41 to implement the service request verification method as described in the foregoing embodiments. Figure 4

[0095] In addition, embodiments of the present application provide a non-transitory machine-readable storage medium, which stores executable code. When the executable code is executed by a processor of an electronic device, the processor can at least implement the service request verification method as described in the foregoing embodiments.

[0096] Embodiments of the present application provide a computer program product, which includes a computer program. When the computer program is executed by a processor of an electronic device, the processor performs the service request verification method as described in the foregoing embodiments.

[0097] ​Those skilled in the art will appreciate that embodiments of the application can be readily used as software, hardware, or a combination of software and hardware. In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0098] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more functions specified in the flowchart block or blocks. Figure 1 one or more functions specified in the flowchart block or blocks.

[0099] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. Figure 1 one or more functions specified in the flowchart block or blocks. Figure 1 one or more functions specified in the flowchart block or blocks.

[0100] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more functions specified in the flowchart block or blocks. Figure 1 one or more functions specified in the flowchart block or blocks.

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

[0102] The memory can include non-persistent memory and / or persistent memory, such as flash memory, readonly memory (ROM), or similar storage elements, in a computer readable medium. Memory is an example of computer readable media.

[0103] Computer-readable media includes permanent and non-permanent, movable and non-movable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer-readable media does not include transitory media such as modulated data signals and carriers.

[0104] It should also be noted that the terms "comprising", "containing", or any other variant thereof are intended to cover non-exclusive inclusions, so that a process, method, article or apparatus that includes a list of elements does not only include those elements, but also includes other elements not explicitly listed, or further includes elements inherent in such a process, method, article or apparatus. Without more limitations, the element defined by the statement "comprising a" does not exclude the presence of additional identical elements in the process, method, article or apparatus that includes the element.

[0105] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application shall be included in the scope of claims of the present application.

Claims

1. A service request verification method characterized by, The method applied to a client comprises: Based on the service application request of the user, using the user private key to sign the setting data packet, generating the first target signature, the setting data packet including the identity identifier, the setting commitment protocol parameter, the zero-knowledge proof parameter, and the plaintext information corresponding to the service application request, the setting commitment protocol parameter being used to hide the plaintext information from the outside; The first target signature is sent to the authorized end to make the authorized end verify the first target signature, and in the case of passing the verification, the identity identifier, the setting commitment protocol parameter, and the proof type label are signed using the authorized end private key to generate the second target signature, the second target signature being used to be stored to the identity identifier verification end; Based on the service application request, the range proof information is generated according to the ring signature range proof protocol, the identity identifier and the range proof information are signed using the user private key to generate the third target signature, and the third target signature is sent to the service provider end to make the service provider end verify the third target signature based on the second target signature through the identity identifier verification end.

2. The method of claim 1, wherein, The first target signature is sent to the authorized end to make the authorized end verify the first target signature, and in the case of passing the verification, the identity identifier, the setting commitment protocol parameter, and the proof type label are signed using the authorized end private key to generate the second target signature, the second target signature being used to be stored to the identity identifier verification end; The first target signature is sent to the authorized end to make the authorized end verify the first target signature, and in the case of passing the verification, the identity identifier, the setting commitment protocol parameter, and the proof type label are signed using the authorized end private key to generate the second target signature, the second target signature being used to be stored to the identity identifier verification end.

3. The method of claim 1, wherein, Before the method based on the service application request of the user, using the user private key to sign the setting data packet, the method further comprises: Generating a target random number; According to the target random number, the setting commitment protocol parameter and the zero-knowledge proof parameter are generated; Based on the identity identifier, the setting commitment protocol parameter, the zero-knowledge proof parameter, and the plaintext information corresponding to the service application request, the setting data packet is determined.

4. The method according to any one of claims 1 to 3, characterized in that, The setting commitment protocol parameter is Pedersen commitment parameter.

5. A service request verification apparatus characterized by comprising: The device applied to a client comprises: A first signature module is configured to generate a first target signature by signing a setting data packet using a user private key based on a service application request of the user, the setting data packet including an identity identifier, a setting commitment protocol parameter, a zero-knowledge proof parameter, and plaintext information corresponding to the service application request, the setting commitment protocol parameter being used to hide the plaintext information from the outside; A verification module is configured to send the first target signature to an authorized end to make the authorized end verify the first target signature, and in the case of passing the verification, sign the identity identifier, the setting commitment protocol parameter, and a proof type label using an authorized end private key to generate a second target signature, the second target signature being used to be stored to an identity identifier verification end; A second signature module is configured to generate a third target signature by signing the identity identifier and range proof information using the user private key based on the service application request according to a ring signature range proof protocol, and send the third target signature to a service provider end to make the service provider end verify the third target signature based on the second target signature through the identity identifier verification end. A second signature module is configured to generate range proof information according to a ring signature range proof protocol based on the service application request, perform a signature operation on the identity and the range proof information using the user private key, generate a third target signature, and send the third target signature to the service provider, so that the service provider verifies the third target signature based on the second target signature through the identity verification end.

6. The apparatus of claim 5, wherein, The verification module is configured to send the first target signature to the authorization end, so that the authorization end acquires the public key of the user at the identity verification end and verifies the first target signature according to the public key of the user.

7. The apparatus of claim 6, wherein, The device further comprises: A determination module is configured to generate a target random number, generate set commitment protocol parameters and zero-knowledge proof parameters according to the target random number, and determine a set data packet based on the identity, the set commitment protocol parameters, the zero-knowledge proof parameters, and the plaintext information corresponding to the service application request.

8. The device of any one of claims 5-7, wherein, The set commitment protocol parameters are Pedersen commitment parameters.

9. A non-transitory machine-readable storage medium, comprising: The non-transitory machine-readable storage medium stores executable code, and when the executable code is executed by the processor of the electronic device, the processor executes the service request verification method according to any one of claims 1 to 4.

10. A computer program product, characterised in that, It comprises: The computer program, when executed by the processor of the electronic device, causes the processor to execute the service request verification method according to any one of claims 1 to 4.

Images