Digital certificate verification method and system based on BBS signature

Abstract

The invention relates to the technical field of information security, in particular to a digital certificate verification method and system based on a BBS signature, and is used for solving the problem that the security is reduced due to the fact that a certificate system based on the BBS signature does not support certificate revocation defects in related technologies. Querying a certificate revocation list issued by the certificate issuing end, and obtaining a user identifier of a revoked certificate and a current accumulator value from the certificate revocation list; generating a certificate state proof based on the obtained user identifier of the revoked certificate, the current accumulator value and the user identifier of the holder, and sending the certificate state proof and the current accumulator value to a verification party, so that the verification party verifies the validity of the digital certificate of the holder; therefore, the validity of the digital certificate of the holder can be verified through the certificate state certification, so that the revoked certificate can be identified in time, the system security is improved, and the certificate verification reliability is improved.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a digital certificate verification method and system based on BBS signature. Background Technology

[0002] In traditional digital certificate systems, users typically need to present the entire certificate content to the verifier, leading to privacy breaches. BBS signatures (Boneh-Boyen Signatures) support displaying partial signature content, enabling BBS-signature-based certificate systems to show only parts of the certificate, thus improving privacy. Furthermore, this system easily implements certificate non-connectivity, ensuring that multiple certificate presentation sessions by a user cannot be linked.

[0003] However, existing BBS-based certificate systems have a flaw that does not support certificate revocation, making it impossible to revoke the certificates of users who have engaged in misconduct or whose certificates have been leaked, thus reducing the security of the system. Summary of the Invention

[0004] This application provides a digital certificate verification method and system based on BBS signatures to improve the certificate revocation mechanism of the BBS signature-based digital certificate system, promptly identify revoked certificates, enhance system security, and improve the reliability of digital certificate verification.

[0005] The specific technical solutions provided in this application are as follows: In a first aspect, embodiments of this application provide a digital certificate verification method based on BBS signatures, including: When the holder needs to provide a digital certificate to the verifier, the certificate revocation list published by the certificate issuer is queried, and the user ID of the revoked certificate and the current accumulator value are obtained from the certificate revocation list. Based on the user identifier of the revoked certificate, the current accumulator value, and the user identifier of the holder, a certificate status certificate is generated. The certificate status proof and the current accumulator value are sent to the verifier so that the verifier can verify the validity of the holder's digital certificate.

[0006] In one possible implementation, before querying the certificate revocation list published by the certificate issuer, the method further includes: Based on the baseline parameters generated and published by the certificate issuer and the digital certificate, as well as the attribute information to be displayed this time, a selective disclosure certificate is generated. The selective disclosure certificate is sent to the verifier so that the verifier can determine the holder's identity legitimacy based on the selective disclosure certificate. After the verification is passed, a challenge value is randomly generated and sent. Receive the challenge value and generate response information based on the challenge value.

[0007] In one possible implementation, sending the certificate status proof and the current accumulator value to the verifier, so that the verifier can verify the validity of the holder's digital certificate, includes: The certificate status certificate, the current accumulator value, and the response information are sent to the verifier so that the verifier can determine the authenticity of the holder's digital certificate based on the response information, and then verify the validity of the holder's digital certificate based on the certificate status certificate and the current accumulator value.

[0008] In one possible implementation, before sending the certificate status proof and the current accumulator value to the verifier, the method further includes: Based on the baseline parameters generated and published by the certificate issuer and the digital certificate, as well as the attribute information to be displayed, the statement information is determined. Based on the stated information and the digital certificate, a non-interactive zero-knowledge proof is generated.

[0009] In one possible implementation, the statement information includes a public parameter pp and a statement x, wherein pp = The Let p be a cyclic group of order p, where p is a large prime number with a preset security parameter λ bits. For system-generated elements, As a public element, corresponding to the attribute information to be displayed this time, statement x is the statement... With the The relationship between them, then the generation of a non-interactive zero-knowledge proof based on the stated information and the digital certificate, includes: Generate random numbers, and based on the random numbers and the... Generate commitment values; Based on the commitment value, the and stated A hash operation is performed to obtain a challenge value, and a response value is generated based on the challenge value, the random number, and the evidence w in the digital certificate corresponding to the statement x. The non-interactive zero-knowledge proof is obtained based on the commitment value and the response value.

[0010] In one possible implementation, sending the certificate status proof and the current accumulator value to the verifier includes: The non-interactive zero-knowledge proof, the statement information, the certificate status proof, and the current accumulator value are sent to the verifier so that the verifier can determine that the holder's identity legitimacy verification has passed based on the non-interactive zero-knowledge proof and the statement information, and verify the validity of the holder's digital certificate based on the certificate status proof and the current accumulator value.

[0011] In one possible implementation, the method further includes: Send a certificate issuance request to the certificate issuer, the certificate issuance request carrying hash data corresponding to multiple attribute information of the holder; Receive the original signature data sent by the certificate issuer; Based on the baseline parameters generated and published by the certificate issuer, the original signature data, and the multiple attribute information, the validity verification of the original signature data is confirmed to be successful. The hash data corresponding to the original signature data and the multiple attribute information is then stored to obtain the digital certificate.

[0012] In one possible implementation, the baseline parameters are generated based on a preset security parameter λ when the certificate issuer is initialized, including system parameters, issuer public key, accumulator public key, and a complete set of attributes containing all possible attributes. The issuer public key is determined based on the issuer private key, and the issuer private key is generated based on the system parameters. The certificate revocation list includes at least one user identifier of a revoked certificate and an accumulator value determined based on the user identifier of the revoked certificate and the accumulator private key. The accumulator private key is generated based on the system parameters, and the accumulator public key is determined based on the accumulator private key.

[0013] In one possible implementation, the certificate status proof includes first data and second data. Then, generating the certificate status proof based on the acquired user identifier of the revoked certificate, the current accumulator value, and the holder's user identifier includes: When there are multiple user identifiers in the certificate revocation list, the difference between the value corresponding to each of the multiple user identifiers and the value corresponding to the holder's user identifier is determined. Based on the product of the multiple differences and the system parameters, the first data is determined to characterize the degree of difference between the holder's user identifier and the multiple user identifiers. Based on the accumulator public key, the current accumulator value, and the multiple user identifiers, the second data is determined to characterize the degree of difference between the accumulator value corresponding to the holder's user identifier and the current accumulator value.

[0014] Secondly, embodiments of this application provide a digital certificate verification method based on BBS signatures, including: The system receives a certificate status certificate and a current accumulator value sent by the certificate holder. The certificate status certificate is generated by the certificate holder based on the user identifier of the revoked certificate and the current accumulator value, as well as the user identifier of the certificate holder. The user identifier of the revoked certificate and the current accumulator value are obtained by the certificate holder by querying the certificate revocation list published by the certificate issuer. The validity of the holder's digital certificate is verified based on the certificate status proof and the current accumulator value.

[0015] In one possible implementation, before receiving the certificate status proof and current accumulator value sent by the certificate holder, the method further includes: Receive the selective disclosure certificate sent by the holder, which is generated by the holder based on the baseline parameters generated and published by the certificate issuer, the digital certificate, and the attribute information to be displayed this time when the holder needs to provide a digital certificate to the verifier. Based on the selective disclosure proof, it is determined that the holder's identity legitimacy verification has passed, and a challenge value is randomly generated and sent to the holder, so that the holder can generate response information based on the received challenge value.

[0016] In one possible implementation, the certificate status proof and current accumulator value sent by the receiving holder include: Receive the certificate status certificate, the current accumulator value, and the response information sent by the holder; The step of verifying the validity of the holder's digital certificate based on the certificate status proof and the current accumulator value includes: Based on the response information, it is determined that the holder's digital certificate has passed the authenticity verification; The validity of the holder's digital certificate is verified based on the certificate status proof and the current accumulator value.

[0017] In one possible implementation, the certificate status proof and current accumulator value sent by the receiving holder include: The system receives a non-interactive zero-knowledge proof, a statement, a certificate status proof, and a current accumulator value sent by the certificate holder. The non-interactive zero-knowledge proof is generated by the certificate holder based on the statement and the digital certificate when the certificate needs to be provided to the verifier. The statement is determined based on the baseline parameters generated and published by the certificate issuer, the digital certificate, and the attribute information to be displayed. The certificate status proof is generated by the certificate holder based on the user identifiers of revoked certificates in the certificate revocation list published by the certificate issuer, the current accumulator value, and the certificate holder's user identifier.

[0018] In one possible implementation, verifying the validity of the holder's digital certificate based on the certificate status proof and the current accumulator value includes: Based on the non-interactive zero-knowledge proof and the stated information, it is determined that the holder's identity legitimacy verification has passed; The validity of the holder's digital certificate is verified based on the certificate status proof and the current accumulator value.

[0019] In one possible implementation, verifying the validity of the holder's digital certificate based on the certificate status proof and the current accumulator value includes: Query the certificate revocation list to determine whether the current accumulator value is included in the certificate revocation list; If not, then the holder's digital certificate is determined to be invalid; If so, obtain the user identifier and the latest accumulator value from the certificate revocation list. Based on the latest accumulator value, the baseline parameters generated and published by the certificate issuer, and the certificate status proof, verify the legality of the certificate status proof. If the certificate status proof passes verification, determine that the holder's digital certificate is valid. If the certificate status proof fails verification, determine that the holder's digital certificate is invalid.

[0020] Thirdly, embodiments of this application provide a digital certificate system based on BBS signatures, including a certificate issuing end, at least one user end, and at least one verification end: The certificate issuing end is used to maintain and publish a certificate revocation list through an accumulator. The certificate revocation list includes at least one user identifier of a revoked certificate and an accumulator value. The user terminal is configured to query the certificate revocation list when the holder needs to provide a digital certificate to the verifier, obtain the user identifier of the revoked certificate and the current accumulator value from the certificate revocation list; generate a certificate status certificate based on the obtained user identifier of the revoked certificate and the current accumulator value, as well as the user identifier of the holder; and send the certificate status certificate and the current accumulator value to the verifier. The verification terminal of the verifier is used to verify the validity of the holder's digital certificate based on the received certificate status proof and the current accumulator value.

[0021] Fourthly, embodiments of this application provide a digital certificate verification device based on BBS signatures, comprising: The acquisition module is used to query the certificate revocation list published by the certificate issuer when the holder needs to provide a digital certificate to the verifier, and obtain the user identifier of the revoked certificate and the current accumulator value from the certificate revocation list; The generation module is used to generate a certificate status certificate based on the user identifier of the revoked certificate, the current accumulator value, and the user identifier of the holder. The sending module is used to send the certificate status proof and the current accumulator value to the verifier so that the verifier can verify the validity of the holder's digital certificate.

[0022] Fifthly, embodiments of this application provide a digital certificate verification device based on BBS signatures, comprising: The receiving module is used to receive the certificate status certificate and the current accumulator value sent by the holder. The certificate status certificate is generated by the holder based on the user identifier of the revoked certificate and the current accumulator value, as well as the holder's user identifier. The user identifier of the revoked certificate and the current accumulator value are obtained by the holder by querying the certificate revocation list published by the certificate issuer. The verification module is used to verify the validity of the holder's digital certificate based on the certificate status proof and the current accumulator value.

[0023] Sixthly, embodiments of this application provide an electronic device, including: Memory is used to store computer programs or instructions; A processor for executing a computer program or instructions in the memory, such that the method described in either the first or second aspect above is performed.

[0024] In a seventh aspect, embodiments of this application provide a computer-readable storage medium that, when instructions in the storage medium are executed by a processor, enables the processor to perform the method described in either the first or second aspect described above.

[0025] Eighthly, embodiments of this application provide a computer program product comprising: computer program code, which, when executed on a computer, causes the computer to perform the method described in either the first or second aspect above.

[0026] In this embodiment, when the holder needs to provide a digital certificate to the verifier, the certificate revocation list published by the certificate issuer is queried. The user identifier and current accumulator value of the revoked certificate are obtained from the certificate revocation list. Based on the obtained user identifier and current accumulator value of the revoked certificate, as well as the holder's user identifier, a certificate status certificate is generated. The certificate status certificate and the current accumulator value are then sent to the verifier so that the verifier can verify the validity of the holder's digital certificate. In this way, by deploying an accumulator at the certificate issuer and maintaining and publishing the certificate revocation list through the accumulator, the BBS-signed digital certificate system supports certificate revocation without affecting the original certificate verification. Furthermore, by generating and sending a certificate status certificate based on the user identifier and current accumulator value of the revoked certificate in the certificate revocation list, as well as the holder's user identifier, the verifier can verify the validity of the digital certificate based on this certificate status certificate. This allows for timely identification of revoked certificates, improving system security and the reliability of digital certificate verification. Attached Figure Description

[0027] Figure 1 This is a schematic diagram illustrating an application scenario of an optional digital certificate verification method based on BBS signatures in this application embodiment; Figure 2 This is a flowchart illustrating a digital certificate verification method based on BBS signature in an embodiment of this application. Figure 3 This is a schematic diagram illustrating a process for applying for and issuing a digital certificate in an embodiment of this application; Figure 4 This is a schematic diagram of a process for generating a certificate status certificate in an embodiment of this application; Figure 5 This is a flowchart illustrating another digital certificate verification method based on BBS signature in an embodiment of this application; Figure 6 This is a schematic diagram of a certificate non-revocation verification process in an embodiment of this application; Figure 7 This is a flowchart illustrating another digital certificate verification method based on BBS signature in an embodiment of this application; Figure 8 This is a flowchart illustrating yet another digital certificate verification method based on BBS signature in this application embodiment; Figure 9This is an example of a digital certificate verification interaction process based on BBS signature in this application embodiment; Figure 10 This is a schematic diagram of the logical architecture of a digital certificate verification device based on BBS signature in an embodiment of this application; Figure 11 This is a schematic diagram of the logical architecture of another digital certificate verification device based on BBS signature in the embodiments of this application; Figure 12 This is a schematic diagram of the logical architecture of a digital certificate verification system based on BBS signature in an embodiment of this application; Figure 13 This is a schematic diagram of the physical architecture of an optional electronic device in an embodiment of this application. Detailed Implementation

[0028] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0029] It should be noted that the term "and / or" in the specification, claims, and drawings of this application describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the related objects before and after it are in an "or" relationship.

[0030] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in sequences other than those illustrated or described herein.

[0031] The data collection, dissemination, and use in this application all comply with relevant national laws and regulations.

[0032] Existing certificate systems based on BBS signatures have a flaw that does not support certificate revocation, making it impossible to revoke the certificates of users who have engaged in misconduct or whose certificates have been leaked, thus reducing the security of the system.

[0033] In view of this, in order to address the security issue caused by the lack of support for certificate revocation in BBS-signature-based certificate systems in related technologies, this application provides a digital certificate verification method based on BBS signatures. In this application embodiment, when the holder needs to provide a digital certificate to the verifier, the method queries the certificate revocation list published by the certificate issuer, obtains the user identifier and current accumulator value of the revoked certificate from the certificate revocation list, generates a certificate status certificate based on the obtained user identifier and current accumulator value of the revoked certificate, and the holder's user identifier, and sends the certificate status certificate and current accumulator value to the verifier so that the verifier can verify the validity of the holder's digital certificate.

[0034] In this way, by deploying an accumulator at the certificate issuing end and maintaining and publishing a certificate revocation list through the accumulator, the BBS-signed digital certificate system can support certificate revocation without affecting the verification of existing certificates. At the same time, by generating and sending a certificate status certificate based on the user identifier of the revoked certificate in the certificate revocation list, the current accumulator value, and the holder's user identifier, the verifier can verify the validity of the digital certificate based on the certificate status certificate. This allows for the timely identification of revoked certificates, improving system security and the reliability of digital certificate verification.

[0035] Figure 1 This diagram illustrates an application scenario of an optional BBS-signature-based digital certificate verification method as described in this application. (See also...) Figure 1 As shown, this application scenario includes a certificate issuer, at least one user, and at least one verifier. A digital certificate system based on BBS signatures is constructed using the certificate issuer, at least one user, and at least one verifier. The certificate issuing end is used to maintain and publish a certificate revocation list via an accumulator, the certificate revocation list including at least one user identifier of a revoked certificate and an accumulator value; On the user side, when the holder needs to provide a digital certificate to the verifier, the system queries the certificate revocation list, retrieves the user ID and current accumulator value of the revoked certificate from the revocation list, generates a certificate status certificate based on the retrieved user ID and current accumulator value of the revoked certificate, and the holder's user ID, and sends the certificate status certificate and current accumulator value to the verifier. The verification end of the aforementioned verification party is used to verify the validity of the holder's digital certificate based on the received certificate status proof and the current accumulator value.

[0036] In this embodiment of the application, the certificate issuer is also used to generate and publish benchmark parameters; it is also used to receive a certificate issuance request sent by the user terminal, and based on the certificate issuance request, issue a digital certificate based on BBS signature to the user of the user terminal (i.e. the aforementioned holder).

[0037] In some embodiments of this application, in verification scenarios where there is interaction between the user end and the verification end: On the user side, after obtaining a digital certificate issued by the certificate authority, when the user needs to provide the digital certificate to the verifier, it generates a selective disclosure certificate based on the aforementioned benchmark parameters, the digital certificate, and the attribute information to be displayed, and sends it to the verifier; after receiving the challenge value returned by the verifier, it generates response information based on the challenge value, and generates a certificate status certificate based on the obtained user identifier of the revoked certificate, the current accumulator value, and the holder's user identifier; and sends the certificate status certificate, the current accumulator value, and the response to the aforementioned verification end. The aforementioned verification terminal is also used to determine the validity of the holder's identity based on the received selective disclosure proof, randomly generate a challenge value, and send it to the holder; it is also used to verify the validity of the holder's digital certificate based on the received certificate status proof, the current accumulator value, and the response information corresponding to the challenge value.

[0038] In other embodiments of this application, in verification scenarios where there is no interaction between the user end and the verification end, i.e., in non-interactive verification scenarios: On the user side, after obtaining a digital certificate issued by the certificate authority, when the user needs to provide the digital certificate to the verifier, the user determines the statement information based on the aforementioned benchmark parameters, the digital certificate, and the attribute information to be displayed; based on the statement information and the digital certificate, the user generates a non-interactive zero-knowledge proof; and based on the user identifier of the revoked certificate and the current accumulator value, as well as the holder's user identifier, the user generates a certificate status proof; and sends the non-interactive zero-knowledge proof, the statement information, the certificate status proof, and the current accumulator value to the verifier. The aforementioned verification terminal is also used to determine whether the holder's identity legitimacy verification has passed based on the received non-interactive zero-knowledge proof and statement information; and to verify the validity of the holder's digital certificate based on the received certificate status proof and the current accumulator value.

[0039] In this embodiment, the certificate issuer, user, and verification end can be connected wirelessly. Of course, they can also be connected via a wired connection; this application does not limit the connection method.

[0040] It should be noted that, Figure 1 This paper provides an example of an application scenario for a digital certificate verification method based on BBS signatures provided in the embodiments of this application. However, the application scenarios applicable to the method in the embodiments of this application are not limited to this.

[0041] After introducing the application scenarios of the embodiments of this application, the functions of the certificate issuer, user end, and verification end will be explained below, taking the certificate issuer as the main line.

[0042] In this embodiment, the certificate issuer, as the certificate issuer of the BBS-based digital certificate system, is responsible for generating the aforementioned baseline parameters, issuing digital certificates, and publishing the certificate revocation list.

[0043] 1. Reference parameters

[0044] In this embodiment of the application, the baseline parameters generated and published by the certificate issuer are generated based on preset security parameters and may include system parameters, issuer public key, accumulator public key and a complete set of attributes containing all possible attributes, wherein the issuer public key is determined based on the issuer private key and the issuer private key is generated based on the system parameters.

[0045] In practice, the certificate issuer initializes the system and generates all the cryptographic parameters required for the operation of the digital certificate system based on BBS signature, namely the aforementioned baseline parameters. The baseline parameters include bilinear group parameters and system generators.

[0046] The system initialization process is described below using a specific example.

[0047] 1) Generate bilinear group parameters: In this embodiment of the application, the above-mentioned bilinear group parameters can be obtained by running a group generation algorithm.

[0048] In practice, by inputting the preset safety parameter λ into the running swarm generation algorithm, the bilinear group parameters in the above system parameters can be obtained, as shown below:

[0049] Where p is a large prime number with λ bits; Let e ​​be a cyclic group of order p (usually a point group on an elliptic curve); × → , is a bilinear mapping function.

[0050] 2) Select system-generated elements: In this embodiment of the application, the generator of the above-mentioned system is randomly selected from the above-mentioned bilinear group, as shown below:

[0051] in, , They represent from All elements after removing the identity element. For example, the mathematical representation is as follows:

[0052] in, It is the point at infinity of the elliptic curve (the identity element of the group).

[0053] 3) Generate attribute base (attribute generator): In this embodiment of the application, the maximum number of attributes supported by the system can be determined. Generate attribute basis vectors , representing the complete set of the above attributes:

[0054] Each of them (i∈(0, Independently and randomly generated, used to commit to the information of the i-th attribute; in other words, using... Perform cryptographic operations on the i-th attribute information to obtain the commitment value corresponding to the i-th attribute information.

[0055] In some embodiments of this application, it is assumed that Dedicated to unique identifiers for certificates The commitment. It is important to note that it is necessary to ensure... , The discrete logarithmic relationship between them is unknown, and can usually be achieved by hashing to a curve.

[0056] 4) Generate issuer key pair: In this embodiment of the application, the issuer's private key is randomly selected:

[0057] in, Let {0, 1, 2, ..., p-1} be the set of integers modulo p.

[0058] Then, based on the issuer's private key mentioned above, the issuer's public key is calculated using the following formula: .

[0059] 5) Generate accumulator key pairs: In this embodiment of the application, the accumulator private key is randomly selected: .

[0060] Then, the accumulator public key is calculated based on the accumulator private key mentioned above: , where q is the capacity of the certificate revocation list.

[0061] In the embodiments of this application, the above q can be dynamically adjusted according to actual needs, and this application does not limit it.

[0062] After initialization, the following baseline parameters are generated and exposed, denoted as par:

[0063] The aforementioned baseline parameters (or public parameter set) par constitute the trust foundation of the entire BBS-based digital certificate system and will be used for all subsequent certificate issuance, selective disclosure, and verification operations.

[0064] 2. Certificate Issuance

[0065] As the certificate user of a BBS-based digital certificate system, the user client possesses multiple attribute information. It obtains the digital certificate issued by the certificate issuer through interaction with the certificate authority. Subsequently, based on the digital certificate, it can selectively disclose certain attribute information when required to provide the digital certificate.

[0066] In this embodiment of the application, the user terminal hashes multiple attribute information based on parameters disclosed by the certificate issuer to obtain a corresponding attribute vector, which can be represented as: Then, the certificate issuance request carrying the attribute vector is sent to the certificate issuer.

[0067] The certificate issuer selects a globally unique identifier for the user on the client based on the certificate issuance request. and order The commitment value is calculated using the following formula:

[0068] in, For system generators; This represents the maximum number of attributes. This represents the attribute generator corresponding to the i-th attribute information; This represents the hash value corresponding to the i-th attribute information.

[0069] Certificate issuer selects random number ,calculate:

[0070] Where A represents the signature body; x is the issuer's private key.

[0071] It should be noted that after selecting e, you need to check that x + e ≠ 0 (mod p), otherwise select e again.

[0072] The certificate issuer sends the original signature data σ (σ=(m0, A, e)) to the user.

[0073] After receiving the σ sent by the certificate issuer, the client must immediately verify its validity to ensure the correctness and legality of the obtained certificate and prevent invalid certificates from being obtained due to errors in the certificate issuer or network transmission problems.

[0074] In practice, the user terminal will connect m0 and m u Connect (i.e., m = m0 || m) u This yields the complete attribute vector m. The complete verification process is as follows: 1) Data preparation: baseline parameter par, issuer public key ; complete attribute vector m, and σ = (m0, A, e) to be verified.

[0075] 2) Reconstruct the commitment value

[0076] In this embodiment of the application, the complete attribute vector m it possesses is used to recalculate the commitment value generated at the time of issuance using the above formula for calculating the commitment value C.

[0077] 3) Verification of core equations

[0078] Verify whether the following bilinear mapping equation holds:

[0079] Alternatively, using the properties of bilinear mappings, we can perform the following equivalence verification:

[0080] 4) Verification results: If the above equation holds, then σ=(m0, A, e) is confirmed to be valid for its attribute vector m, and the certificate cert=(A, e, m) is securely stored for later use, where m=(m0, m1, ..., m). ), m0=id.

[0081] If the equation does not hold true, the signature is invalid. The signature should be discarded, and appropriate measures should be taken, such as reporting the error to the certificate issuer and requesting a reissue.

[0082] 3. Certificate Revocation List

[0083] In this embodiment of the application, the certificate issuer publishes a certificate revocation list, which is built and maintained by an accumulator.

[0084] In this embodiment of the application, the list is publicly accessible and includes at least one user identifier with a revoked certificate (denoted as the id set RID), and accumulator values ​​determined based on the user identifier with the revoked certificate and the accumulator private key (denoted as the accumulator value set). ).

[0085] Assuming there are currently t IDs of users whose certificates have been revoked, then RID = {id} r’ : r'=1, 2, 3, ..., t}, and ={A1, A2, ..., A t},in, , .

[0086] When the certificate issuer needs to revoke the identifier id t+1 To obtain a certificate, simply perform the following steps: (1) RID = RID∪{id t+1}; (2) Calculation , = ∪{A t+1}

[0087] Thus, in this embodiment of the application, if the RID and the accumulator public key are known, the accumulated value can still be calculated even if κ is unknown, ensuring that the certificate issuer cannot publish an incorrect accumulated value.

[0088] In this embodiment, the verification end, as the certificate verification party of the BBS-based digital certificate system, can verify whether the certificate status proof provided by the user's holder is valid based on the benchmark parameters and certificate revocation list published by the certificate issuer. Detailed verification methods are described in the following process.

[0089] After introducing the generation of baseline parameters and the publication of certificate revocation lists by the certificate issuer, the following describes in detail, with reference to the accompanying drawings and different scenarios, the implementation of a digital certificate verification method based on BBS signatures provided in this application. It should be understood that the preferred embodiments described herein are only for illustration and explanation of this application and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0090] In verification scenarios where there is interaction between the user and the verification end, refer to Figure 2 As shown in the figure, this application provides a digital certificate verification method based on BBS signature, applied to the aforementioned user terminal. The specific process of this method may include, but is not limited to, the following steps: Step 200: When the holder needs to provide a digital certificate to the verifier, based on the baseline parameters and digital certificate generated and published by the certificate issuer, as well as the attribute information to be displayed, a selective disclosure proof is generated and sent to the verifier. After the verifier determines the holder's identity legitimacy based on the selective disclosure proof, a challenge value is randomly generated and sent.

[0091] In the embodiments of this application, see the following: Figure 3As shown, before executing step 200, the above digital certificate can be obtained by following the procedure: Step 300: Send a certificate issuance request to the certificate issuer, wherein the certificate issuance request carries hash data corresponding to multiple attribute information of the holder.

[0092] In this embodiment of the application, when executing step 300, the user terminal hashes multiple attribute information based on the parameters disclosed by the certificate issuer and maps them to... The corresponding attribute vector is obtained, and the certificate issuance request carrying the attribute vector is sent to the certificate issuer.

[0093] The certificate issuer selects a globally unique identifier for the user on the client based on the certificate issuance request. and order The commitment value C is calculated using the formula described above, and a random number is selected. First, calculate A (the main part of the signature); then, send the original signature data σ (σ=(m0, A, e)) to the user terminal.

[0094] Step 310: Receive the original signature data sent by the certificate issuer.

[0095] Step 320: Based on the above benchmark parameters, original signature data and multiple attribute information, the validity verification of the original signature data is confirmed to be successful. The original signature data and the hash data corresponding to the multiple attribute information are stored to obtain the above digital certificate.

[0096] In specific implementation, during step 320, the user terminal will connect m0 and m u Connect (m=m0||m u ), to obtain the complete attribute vector m; using the complete attribute vector m, recalculate the commitment value generated at the time of issuance using the above formula for calculating the commitment value C.

[0097] Then, obtain the baseline parameter 'par' from the certificate issuer, and based on the baseline parameter 'par' and the issuer's public key... And σ=(m0, A, e) to be verified, perform core equation verification, that is, verify whether the aforementioned bilinear mapping equation holds, or perform equivalence verification using the properties of bilinear mapping.

[0098] If the above equation is confirmed to hold or the equivalence verification passes, and it is confirmed that σ=(m0, A, e) is valid for its attribute vector m, i.e., the original signature data is valid, then store the certificate cert=(A, e, m), where m=(m0, m1, ..., ), m0=id.

[0099] After obtaining the digital certificate, the user needs to provide the digital certificate to the verifier to prove their identity. When the user wants to disclose only a part of their attribute vector m to the verifier and hide the rest of the attribute information, step 200 is executed.

[0100] Assume the attribute information to be displayed, i.e., the publicly disclosed attribute index set, is J. [ The hidden attribute index set is I=[ ]\J, index 0 corresponds to the ID of this certificate, which is usually hidden by default. Let I′=I∪{0}, and the attribute information (public information) to be displayed this time is m′, where, for j∈J, m′[j]=m[j]; for i∈I′, m′[i]= .

[0101] In specific implementation, during step 200, based on the baseline parameter par, the digital certificate cert, and the attribute information m′ to be displayed, the selective disclosure proof is obtained through the following processing method: First, select a random number. The rerandomized signature data is calculated according to the following formula to ensure the unlinkability of this presentation and session:

[0102] in, , These represent the main body of the signature after randomization.

[0103] Then, the commitment is constructed, which can be achieved through the following process: (1) Calculate the commitment value of the publicly disclosed portion: ,in, Right now , representing the j-th attribute; (2) Calculate the commitment value of the hidden part: a. Selecting a random mask factor And, for each hidden attribute i∈I′, choose ; b. Calculate the commitment value U, which can be calculated using the following formula in this embodiment:

[0104] c. Calculation ; Next, the proof is constructed as follows:

[0105] Finally, the above results ( This is sent to the verifier as a selective disclosure proof.

[0106] In this embodiment of the application, the verification end of the verification party performs the first round of verification after receiving the aforementioned selective disclosure proof.

[0107] In this embodiment of the application, the first round of verification operations includes, but is not limited to, the following:

[0108] in, That is, set The parameter corresponding to i=0 in the middle.

[0109] In some embodiments, if any of the above verifications fails, the verifier reports an error and exits. Otherwise, if all the above verifications pass, the next step 520 is executed. In step 520, the verifier generates a random challenge value. The challenge value c is sent to the holder on the user's end.

[0110] Step 210: Receive the challenge value and generate response information based on the challenge.

[0111] In this embodiment of the application, when the user receives the challenge value sent by the verification party, it indicates that the above selective disclosure proof has passed the identity legitimacy verification, and then step 210 is executed.

[0112] In specific implementation, when executing step 210, the response information corresponding to the challenge value, such as (s, t1), can be calculated using the following formula, and then step 220 can be executed: s=α+r c, t1=β-e c, i∈I′,u i =δ i +r m[i] c Step 220: Query the certificate revocation list published by the certificate issuer, and obtain the user ID and current accumulator value of the revoked certificate from the certificate revocation list.

[0113] This involves retrieving the user ID of the revoked certificate from the certificate revocation list, i.e., obtaining the RID; and the current accumulator value, i.e., the latest accumulator value A. t .

[0114] Step 230: Based on the user identifier of the revoked certificate obtained above, the current accumulator value above, and the user identifier of the holder, generate a certificate status certificate.

[0115] In this embodiment of the application, the certificate status proof includes first data and second data, wherein the first data is used to characterize the degree of difference between the holder's user identifier and each user identifier in the above-mentioned certificate revocation list, and the second data is used to characterize the degree of difference between the accumulator value corresponding to the holder's user identifier and the current accumulator value in the above-mentioned certificate revocation list.

[0116] In specific implementation, when performing step 230, refer to... Figure 4 As shown, the specific process is as follows to generate a certificate status certificate, representing the relationship between the holder's user identifier and the RID: Step 2301: If there are multiple user identifiers in the certificate revocation list, determine the difference between the value corresponding to each of the multiple user identifiers and the value corresponding to the holder's user identifier. Based on the product of the multiple differences and the above system parameters, determine the above first data. Step 2302: Determine the second data based on the above accumulator public key, the above current accumulator value, and multiple user identifiers.

[0117] In this embodiment of the application, the above certificate status proof can be denoted as: ),in, This refers to the first data mentioned above. This refers to the second data mentioned above.

[0118] For example, suppose the user identifier to be verified is id0. R, the generated certificate status proof, denoted as ,in, This refers to the first data mentioned above. This refers to the second data mentioned above. The specific steps are as follows: a. Calculation In this embodiment of the application, it can be achieved by the following formula:

[0119] b. Calculation (Or witness element), in this embodiment of the application, it can be implemented by the following formula:

[0120] in, It is a polynomial uniquely determined by the set R; in the current certificate revocation list, R = {id1, id2, ..., id...} n} Accumulator value: .

[0121] It is worth noting that although the accumulator private key κ is not public, , Both can be based on R, PKacc (Accumulator public key) Calculation and acquisition.

[0122] Step 240: Send the certificate status certificate, the current accumulator value, and the response information to the verifier so that the verifier can determine the authenticity of the holder's digital certificate based on the response information, and then verify the validity of the holder's digital certificate based on the certificate status certificate and the current accumulator value.

[0123] In this embodiment of the application, after the user terminal obtains the above certificate status proof, current accumulator value and response information, it executes step 240 and sends them to the verification party.

[0124] After receiving the above content, the verification end triggers the final verification. The specific verification process is as follows: (a) Restructuring public commitments: In this embodiment of the application, the commitment value is calculated using the following formula based on the attribute information to be displayed (public attribute m′):

[0125] (b) Verify the core signature relationship: In this embodiment, this can be achieved by verifying whether the following equation holds true:

[0126] This equation can verify the structural validity of the rerandomized signature (A, B).

[0127] (c) Verify attribute knowledge:

[0128] (d) Verify non-revoked relationships: First, check the certificate revocation list. If A t If the current accumulator value is falsified, an error will be reported and the program will exit; if A... t ∈ Then, we further verify whether the following equation holds true. If it does, the holder's digital certificate is valid; otherwise, the holder's digital certificate is invalid:

[0129] In this embodiment of the application, it is assumed that the current The latest accumulated value in is A t′ And A t′ ≠A t Therefore, after confirming the above-mentioned level, further verification is required. Specifically, the RID is obtained through the certificate revocation list. incr ={id i:i=t+1,…,t′}, id i ∈RID incr ,if If the error message is not cleared, the system will exit; otherwise, it indicates that the holder's digital certificate is valid.

[0130] In this embodiment of the application, if all the above verifications pass, it can be proven that the holder of the user terminal does indeed hold a valid certificate, and the hidden attribute {m[i]} bound to the certificate signature... i∈I′ With public attribute C J Together they constitute a complete commitment, and the certificate has not been revoked.

[0131] Using the example above, we will explain the verification process of certificate status proof.

[0132] Assume the verification end receives (s, t1, {u i}i∈I′, A t ). So, based on (id0, , According to R, PK acc Perform the verification. The verification process is as follows: First, check If id0 is ≠0, it means that id0 is included in the certificate revocation list. In this case, an invalid certificate message will be output immediately, and no services or assistance will be provided to the holder. For example, in a bank loan scenario, the loan application will be rejected.

[0133] In determining After ≠0, verify the following bilinear mapping equation:

[0134] id0 is confirmed only if the above verification passes. The "R" indicates that the holder's digital certificate is valid.

[0135] In this embodiment of the application, by verifying the above certificate status proof, if id0 R, then ≠0 and there exists a valid one Verification ensures completeness; at the same time, based on the q-StrongDiffie-Hellman Assumption (q-SDH), the probability of any adversary forging non-member witnesses in multinomial time is negligible, thus improving the reliability of verification.

[0136] The following explanation addresses the aforementioned q-strong Diffie-Hellman assumption. Specifically, if id0∈R, then (id0+κ)|fR (κ), but For any v id0 ≠0; any successful forgery can be reduced to the solution of the q-strong DH problem.

[0137] The above describes a digital certificate verification method based on BBS signature in this application embodiment from the user's perspective. The following describes the above method in this application embodiment from the verification perspective.

[0138] See Figure 5 As shown in the figure, this application provides a digital certificate verification method based on BBS signature, applied to the above-mentioned verification terminal. The specific process of this method may include, but is not limited to, the following steps: Step 500: Receive the selective disclosure certificate sent by the holder.

[0139] The selective disclosure proof is generated by the holder when they need to provide a digital certificate to the verifier, based on the baseline parameters and digital certificate generated and published by the certificate issuer, as well as the attribute information to be displayed. For details on the generation method, please refer to the aforementioned description of step 200, which will not be repeated here.

[0140] Step 510: Based on the selective disclosure proof, confirm that the holder's identity and legitimacy have been verified.

[0141] For details regarding step 510, please refer to the explanation of the first round of verification for the verification end after step 200 above, which will not be repeated here.

[0142] Step 520: Randomly generate and send a challenge value to the holder, so that the holder can generate a response message based on the received challenge value.

[0143] In practice, during step 520, the verification end generates a random challenge value. The challenge value c is sent to the holder on the user's end.

[0144] Step 530: Receive the certificate status certificate, current accumulator value, and response information of the challenge value sent by the holder.

[0145] The certificate status proof is generated by the holder based on the user identifier and current accumulator value of the revoked certificate, as well as the holder's user identifier. The user identifier and current accumulator value of the revoked certificate are obtained by the holder by querying the certificate revocation list published by the certificate issuer. For details, please refer to the above description of steps 210 to 230, which will not be repeated here.

[0146] Step 540: Based on the response information, determine that the holder's digital certificate has passed the authenticity verification.

[0147] For details regarding step 540, please refer to the core relationship and attribute knowledge of the signature verification during the final verification process at the aforementioned verification end; these details will not be repeated here.

[0148] Step 550: Verify the validity of the holder's digital certificate based on the certificate status proof and the current accumulator value.

[0149] In this embodiment of the application, when performing step 550, refer to... Figure 6 As shown, the specific process is as follows: Step 5501: Query the above certificate revocation list.

[0150] Step 5502: Determine whether the current accumulator value is included in the certificate revocation list. If not, proceed to step 5503; if yes, proceed to step 5504.

[0151] Step 5503: Determine that the holder's digital certificate is invalid.

[0152] Step 5504: Obtain the user identifier and latest accumulator value from the certificate revocation list. Based on the latest accumulator value, baseline parameters, and certificate status proof, verify the legality of the certificate status proof. If the certificate status proof passes verification, determine that the holder's digital certificate is valid. If the certificate status proof fails verification, determine that the holder's digital certificate is invalid.

[0153] For details regarding the verification of the certificate revocation list in steps 5502 to 5504, please refer to the content on verifying non-revocation relationships during the final verification at the aforementioned verification end, which will not be repeated here.

[0154] In verification scenarios where there is no interaction between the user and the verification end, this application provides a non-interactive zero-knowledge proof process. It is called a non-interactive zero-knowledge proof because proof and verification are completed through a single message.

[0155] See Figure 7 As shown in the figure, this application provides a digital certificate verification method based on BBS signature, applied to the aforementioned user terminal. The specific process of this method may include, but is not limited to, the following steps: Step 700: When the holder needs to provide a digital certificate to the verifier, the statement information is determined based on the benchmark parameters and digital certificate generated and published by the certificate issuer, as well as the attribute information to be displayed.

[0156] In practice, if the user wants to hide the actual attribute information to be displayed, and the statement meets the verification conditions, then step 700 is executed.

[0157] The aforementioned information includes the disclosed parameter pp and statement x; , Let p be a cyclic group of order p, where p is a large prime number of λ bits. For system-generated elements, This is a public element, corresponding to the attribute information that needs to be displayed this time; 'x' is used for description. and The relationship between them, such as x being a publicly stated " yes "a certain power of".

[0158] It should be noted that the evidence w (discrete logarithm) corresponding to statement x in the digital certificate: w = α, satisfies .

[0159] Step 710: Based on the above-described information and digital certificate, generate a non-interactive zero-knowledge proof.

[0160] In this embodiment of the application, when performing step 710, firstly, a random number is generated, and based on the random number and the system generator... Generate a commitment value; then, based on this commitment value, public elements... and system generator A hash operation is performed to obtain the challenge value, and a response value is generated based on the challenge value, a random number, and the evidence w; thus, based on the commitment value and the response value, the aforementioned non-interactive zero-knowledge proof is obtained.

[0161] For example, for holder P, when executing step 710, based on the above (public parameters pp, statement x, and evidence w), the proof generation algorithm is invoked to output a non-interactive zero-knowledge proof π, which includes: π = ( , The specific process for generating the proof is as follows: (1) Select a random number: ; (2) Calculate the commitment value: = ; (3) Generate challenge values: ; (4) Calculate the response value: =r+c αmod p; So, .

[0162] Step 720: Query the certificate revocation list published by the certificate issuer, and obtain the user ID and current accumulator value of the revoked certificate from the certificate revocation list.

[0163] For an explanation of step 720, please refer to the explanation of step 220, which will not be repeated here.

[0164] Step 730: Based on the user identifier of the revoked certificate obtained above, the current accumulator value above, and the user identifier of the holder, generate a certificate status certificate.

[0165] For an explanation of step 730, please refer to the explanation of step 230, which will not be repeated here.

[0166] Step 740: Send the non-interactive zero-knowledge proof, statement information, certificate status proof, and current accumulator value to the verifier so that the verifier can determine the legitimacy of the holder's identity based on the non-interactive zero-knowledge proof and statement information, and verify the validity of the holder's digital certificate based on the certificate status proof and current accumulator value.

[0167] In this embodiment of the application, after the user terminal obtains the above-mentioned non-interactive zero-knowledge proof, statement information, certificate status proof and current accumulator value, it executes step 740 and sends them to the verifier, which triggers the verifier to verify the identity of the holder and the validity of the certificate.

[0168] See Figure 8 As shown in the figure, this application provides a digital certificate verification method based on BBS signature, applied to the above-mentioned verification terminal. The specific process of this method may include, but is not limited to, the following steps: Step 800: Receive the non-interactive zero-knowledge proof, statement information, certificate status proof, and current accumulator value sent by the holder.

[0169] Among them, the non-interactive zero-knowledge proof, statement information, certificate status proof and current accumulator value are generated by the user terminal by executing steps 700 to 730, which will not be described in detail here.

[0170] Step 810: Based on non-interactive zero-knowledge proofs and stated information, verify the holder's identity legitimacy.

[0171] In this embodiment of the application, when the verification end performs proof verification, the verification party V uses the same statement information, namely the public parameter pp and the statement x, to prove π=( , To verify, the following verification process will be performed: (1) From the proof of π, we can deduce and ; (2) Recalculate the challenge value: ; (3) Verify the equation: ; This process can be represented as: {0, 1} ← Verify(π).

[0172] If the above equation is found to be true, the holder's identity verification is successful (step 810). Then, step 820 is executed to verify the validity of the holder's digital certificate. Conversely, if the listing equation is found to be false, the holder's identity verification fails, and the holder is rejected.

[0173] Step 820: Verify the validity of the holder's digital certificate based on the certificate status proof and the current accumulator value.

[0174] In this embodiment of the application, when performing step 820, the aforementioned steps 5501 to 5504 can be executed, which will not be repeated here.

[0175] By using the non-interactive zero-knowledge proof verification method described above, which sends the non-interactive zero-knowledge proof, statement information, certificate status proof, and current accumulator value to the verifier all at once, the interaction with the verifier can be reduced. Compared with the aforementioned verification scenarios involving interaction, this can reduce the risk of certificate theft or leakage and also improve interaction efficiency.

[0176] In this embodiment, when the holder needs to provide a digital certificate to the verifier, the holder's client constructs a certificate status proof of its own certificate's validity through a certificate revocation list, and sends it along with the current accumulator value in the obtained certificate revocation list to the verifier's client. The verifier verifies the validity of the holder's digital certificate based on the certificate status proof and the current accumulator value, using the certificate revocation list. This allows for timely identification of revoked certificates, improving system security and the reliability of digital certificate verification.

[0177] Figure 9 A flowchart illustrating a digital certificate verification interaction based on BBS signatures, as shown in an embodiment of this application, is presented. Figure 9 As shown, including but not limited to the following steps: Step 901: When the holder needs to provide a digital certificate to the verifier, the user client queries the certificate revocation list published by the certificate issuer and obtains the user ID of the revoked certificate and the current accumulator value from the certificate revocation list.

[0178] Step 902: The client generates a certificate status certificate based on the user identifier of the revoked certificate, the current accumulator value, and the holder's user identifier.

[0179] Step 903: The client sends the certificate status proof and the current accumulator value to the verifier.

[0180] Step 904: The verifier's verification end verifies the validity of the holder's digital certificate based on the received certificate status proof and the current accumulator value.

[0181] For explanations of steps 901 to 904, please refer to the foregoing descriptions; they will not be repeated here.

[0182] In related technologies, BBS signatures also support the display and verification of complete attributes. This will be explained below.

[0183] When a holder wishes to fully disclose all attributes of their digital certificate to a verifier, they should follow this procedure. This procedure is simpler than partial disclosure, but still ensures session unlinkability through re-randomization.

[0184] First, based on the aforementioned baseline parameter PP, the user terminal verifies the public key X2 and the certificate cert=(A, e, m), and performs a re-randomization operation, i.e., selects a random number. The re-randomized signature data is calculated, and the specific method is detailed in the aforementioned calculation method, which will not be repeated here. This step is crucial for ensuring unlinkability, ensuring that a different signature is generated for each display. , )right.

[0185] Then, construct the commitment: select a random number. Calculate commitment In this embodiment of the application, it can be achieved using the following formula:

[0186] The user will ( , , Send it to the verifier.

[0187] The verifier received ( , , After that, a random challenge is generated. Challenge c will be sent to the user's device.

[0188] After receiving c, the user calculates the corresponding response based on c: s = α + r c, t=β-e c; Send the response (s, t) to the verifier.

[0189] Upon receiving the response, the verifier reconstructs the public commitment. In this embodiment, the commitment C is calculated based on the attribute vector m claimed by the user, as detailed in the aforementioned commitment calculation formula; the core relationship of the signature is verified as follows:

[0190] In this embodiment of the application, the structural correctness of the rerandomized signature is verified by this equation.

[0191] Further verification of attribute knowledge is shown in the following formula:

[0192] Through the above verification, it is possible to achieve digital certificate verification based on BBS signature that discloses complete attributes, thus ensuring the unlinkability of the session.

[0193] Based on the same inventive concept, see [reference] Figure 10 As shown, this application provides a digital certificate verification device based on BBS signature, comprising: The acquisition module 1010 is used to query the certificate revocation list published by the certificate issuer when the holder needs to provide a digital certificate to the verifier, and obtain the user identifier of the revoked certificate and the current accumulator value from the certificate revocation list. The generation module 1020 is used to generate a certificate status certificate based on the user identifier of the revoked certificate, the current accumulator value, and the user identifier of the holder. The sending module 1030 is used to send the certificate status proof and the current accumulator value to the verifier so that the verifier can verify the validity of the holder's digital certificate.

[0194] In one possible implementation, before querying the certificate revocation list published by the certificate issuer, the acquisition module 1010 further includes: Based on the baseline parameters generated and published by the certificate issuer and the digital certificate, as well as the attribute information to be displayed this time, a selective disclosure certificate is generated. The selective disclosure certificate is sent to the verifier so that the verifier can determine the holder's identity legitimacy based on the selective disclosure certificate. After the verification is passed, a challenge value is randomly generated and sent. Receive the challenge value and generate response information based on the challenge value.

[0195] In one possible implementation, the sending module 1030 is specifically used for: The certificate status certificate, the current accumulator value, and the response information are sent to the verifier so that the verifier can determine the authenticity of the holder's digital certificate based on the response information, and then verify the validity of the holder's digital certificate based on the certificate status certificate and the current accumulator value.

[0196] In one possible implementation, before sending the certificate status proof and the current accumulator value to the verifier, the generation module 1020 is further configured to: Based on the baseline parameters generated and published by the certificate issuer and the digital certificate, as well as the attribute information to be displayed, the statement information is determined. Based on the stated information and the digital certificate, a non-interactive zero-knowledge proof is generated.

[0197] In one possible implementation, the statement information includes a public parameter pp and a statement x, wherein pp = The Let p be a cyclic group of order p, where p is a large prime number with a preset security parameter λ bits. For system-generated elements, As a public element, corresponding to the attribute information to be displayed this time, statement x is used to state the... With the The generation module 1020 is specifically used for: (Regarding the relationship between them) Generate random numbers, and based on the random numbers and the... Generate commitment values; Based on the commitment value, the and stated A hash operation is performed to obtain a challenge value, and a response value is generated based on the challenge value, the random number, and the evidence w in the digital certificate corresponding to the statement x. The non-interactive zero-knowledge proof is obtained based on the commitment value and the response value.

[0198] In one possible implementation, the sending module 1030 is specifically used for: The non-interactive zero-knowledge proof, the statement information, the certificate status proof, and the current accumulator value are sent to the verifier so that the verifier can determine that the holder's identity legitimacy verification has passed based on the non-interactive zero-knowledge proof and the statement information, and verify the validity of the holder's digital certificate based on the certificate status proof and the current accumulator value.

[0199] In one possible implementation, the acquisition module 1010 is further configured to: Send a certificate issuance request to the certificate issuer, the certificate issuance request carrying hash data corresponding to multiple attribute information of the holder; Receive the original signature data sent by the certificate issuer; Based on the baseline parameters generated and published by the certificate issuer, the original signature data, and the multiple attribute information, the validity verification of the original signature data is confirmed to be successful. The hash data corresponding to the original signature data and the multiple attribute information is then stored to obtain the digital certificate.

[0200] In one possible implementation, the baseline parameters are generated based on a preset security parameter λ when the certificate issuer is initialized, including system parameters, issuer public key, accumulator public key, and a complete set of attributes containing all possible attributes. The issuer public key is determined based on the issuer private key, and the issuer private key is generated based on the system parameters. The certificate revocation list includes at least one user identifier of a revoked certificate and an accumulator value determined based on the user identifier of the revoked certificate and the accumulator private key. The accumulator private key is generated based on the system parameters, and the accumulator public key is determined based on the accumulator private key.

[0201] In one possible implementation, the certificate status proof includes first data and second data, then the generation module 1020 is specifically used for: When there are multiple user identifiers in the certificate revocation list, the difference between the value corresponding to each of the multiple user identifiers and the value corresponding to the holder's user identifier is determined. Based on the product of the multiple differences and the system parameters, the first data is determined to characterize the degree of difference between the holder's user identifier and the multiple user identifiers. Based on the accumulator public key, the current accumulator value, and the multiple user identifiers, the second data is determined to characterize the degree of difference between the accumulator value corresponding to the holder's user identifier and the current accumulator value.

[0202] Based on the same inventive concept, see [reference] Figure 11 As shown, this application provides a digital certificate verification device based on BBS signature, comprising: The receiving module 1110 is used to receive the certificate status certificate and the current accumulator value sent by the holder. The certificate status certificate is generated by the holder based on the user identifier of the revoked certificate and the current accumulator value, as well as the holder's user identifier. The user identifier of the revoked certificate and the current accumulator value are obtained by the holder by querying the certificate revocation list published by the certificate issuer. The verification module 1120 is used to verify the validity of the holder's digital certificate based on the certificate status proof and the current accumulator value.

[0203] In one possible implementation, before receiving the certificate status proof and current accumulator value sent by the receiving holder, the receiving module 1110 is further configured to: Receive the selective disclosure certificate sent by the holder, which is generated by the holder based on the baseline parameters generated and published by the certificate issuer, the digital certificate, and the attribute information to be displayed this time when the holder needs to provide a digital certificate to the verifier. Based on the selective disclosure proof, it is determined that the holder's identity legitimacy verification has passed, and a challenge value is randomly generated and sent to the holder, so that the holder can generate response information based on the received challenge value.

[0204] In one possible implementation, the receiving module 1110 is specifically used for: Receive the certificate status certificate, the current accumulator value, and the response information sent by the holder; The verification module 1120 is specifically used for: Based on the response information, it is determined that the holder's digital certificate has passed the authenticity verification; The validity of the holder's digital certificate is verified based on the certificate status proof and the current accumulator value.

[0205] In one possible implementation, the receiving module 1110 is specifically used for: The system receives a non-interactive zero-knowledge proof, a statement, a certificate status proof, and a current accumulator value sent by the certificate holder. The non-interactive zero-knowledge proof is generated by the certificate holder based on the statement and the digital certificate when the certificate needs to be provided to the verifier. The statement is determined based on the baseline parameters generated and published by the certificate issuer, the digital certificate, and the attribute information to be displayed. The certificate status proof is generated by the certificate holder based on the user identifiers of revoked certificates in the certificate revocation list published by the certificate issuer, the current accumulator value, and the certificate holder's user identifier.

[0206] In one possible implementation, the verification module 1120 is specifically used for: Based on the non-interactive zero-knowledge proof and the stated information, it is determined that the holder's identity legitimacy verification has passed; The validity of the holder's digital certificate is verified based on the certificate status proof and the current accumulator value.

[0207] In one possible implementation, the verification module 1120 is specifically used for: Query the certificate revocation list to determine whether the current accumulator value is included in the certificate revocation list; If not, then the holder's digital certificate is determined to be invalid; If so, obtain the user identifier and the latest accumulator value from the certificate revocation list. Based on the latest accumulator value, the baseline parameters generated and published by the certificate issuer, and the certificate status proof, verify the legality of the certificate status proof. If the certificate status proof passes verification, determine that the holder's digital certificate is valid. If the certificate status proof fails verification, determine that the holder's digital certificate is invalid.

[0208] Based on the same inventive concept, see [reference] Figure 12 As shown in the figure, this application provides a digital certificate verification system based on BBS signature, including a certificate issuing terminal 1210, at least one user terminal 1220, and at least one verification terminal 1230: The certificate issuing terminal 1210 is used to maintain and publish a certificate revocation list through an accumulator. The certificate revocation list includes at least one user identifier of a revoked certificate and an accumulator value. The user terminal 1220 is configured to query the certificate revocation list when the holder needs to provide a digital certificate to the verifier, obtain the user identifier of the revoked certificate and the current accumulator value from the certificate revocation list; generate a certificate status certificate based on the obtained user identifier of the revoked certificate and the current accumulator value, as well as the user identifier of the holder; and send the certificate status certificate and the current accumulator value to the verifier. The verification terminal 1230 of the verification party is used to verify the validity of the holder's digital certificate based on the received certificate status proof and the current accumulator value.

[0209] See Figure 13 As shown, this application provides an electronic device that can implement the aforementioned digital certificate verification method based on BBS signatures, as well as the functions of a certificate issuing end. (Refer to...) Figure 13 The electronic device includes: At least one processor 131 and a memory 132 connected to the at least one processor 131, the memory 132 storing instructions executable by the at least one processor 131, the at least one processor 131 executing the methods described above by executing the instructions stored in the memory 132. The processor 131 can implement the functions of a BBS signature-based digital certificate verification device and a certificate issuing end.

[0210] In this embodiment, the specific connection medium between the processor 131 and the memory 132 is not limited. Figure 13 The example shown is the connection between processor 131 and memory 132 via bus 130. Bus 130 is... Figure 13The connections between other components are indicated by thick lines and are for illustrative purposes only, not as limiting information. Bus 130 can be divided into address bus, data bus, control bus, etc., for ease of representation. Figure 13 The term is represented by a single thick line, but this does not imply that there is only one bus or one type of bus. Alternatively, processor 131 can also be called controller; there is no restriction on the name.

[0211] In one possible design, processor 131 may include one or more processing units. Processor 131 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into processor 131. In some embodiments, processor 131 and memory 132 may be implemented on the same chip; in some embodiments, they may also be implemented on separate chips.

[0212] Processor 131 can be a general-purpose processor, such as a Central Processing Unit (CPU), a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0213] Memory 132, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 132 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 132 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 132 may also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0214] By designing and programming the processor 131, the code corresponding to the methods described in the foregoing embodiments can be embedded into the chip, enabling the chip to execute the steps of the methods described in the foregoing embodiments during operation. How to design and program the processor 131 is a technique well-known to those skilled in the art and will not be elaborated upon here.

[0215] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium that, when instructions in the storage medium are executed by a processor, enables the processor to perform any of the methods described in the above embodiments.

[0216] In some possible implementations, various aspects of the methods provided in this application may also be implemented as a program product comprising program code that, when the program product is run on a device, causes the device to perform the steps of the methods described above according to the various exemplary embodiments of this application.

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

[0218] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0219] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flows in a flowchart and / or one or more blocks in a block diagram.

[0220] These computer program instructions may 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 one or more processes in the flowchart and / or one or more blocks in the block diagram.

[0221] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A digital certificate verification method based on BBS signatures, characterized in that, include: When the holder needs to provide a digital certificate to the verifier, the certificate revocation list published by the certificate issuer is queried, and the user ID of the revoked certificate and the current accumulator value are obtained from the certificate revocation list. Based on the user identifier of the revoked certificate, the current accumulator value, and the user identifier of the holder, a certificate status certificate is generated. The certificate status proof and the current accumulator value are sent to the verifier so that the verifier can verify the validity of the holder's digital certificate.

2. The method as described in claim 1, characterized in that, Before querying the certificate revocation list published by the certificate issuer, the following is also included: Based on the baseline parameters generated and published by the certificate issuer and the digital certificate, as well as the attribute information to be displayed this time, a selective disclosure certificate is generated. The selective disclosure certificate is sent to the verifier so that the verifier can determine the holder's identity legitimacy based on the selective disclosure certificate. After the verification is passed, a challenge value is randomly generated and sent. Receive the challenge value and generate response information based on the challenge value.

3. The method as described in claim 2, characterized in that, Sending the certificate status proof and the current accumulator value to the verifier so that the verifier can verify the validity of the holder's digital certificate includes: The certificate status certificate, the current accumulator value, and the response information are sent to the verifier so that the verifier can determine the authenticity of the holder's digital certificate based on the response information, and then verify the validity of the holder's digital certificate based on the certificate status certificate and the current accumulator value.

4. The method as described in claim 1, characterized in that, Before sending the certificate status proof and the current accumulator value to the verifier, the method further includes: Based on the baseline parameters generated and published by the certificate issuer and the digital certificate, as well as the attribute information to be displayed, the statement information is determined. Based on the stated information and the digital certificate, a non-interactive zero-knowledge proof is generated.

5. The method as described in claim 4, characterized in that, The statement information includes the public parameter pp and the statement x, where pp = The Let p be a cyclic group of order p, where p is a large prime number with a preset security parameter λ bits. For system-generated elements, As a public element, corresponding to the attribute information to be displayed this time, statement x is used to state the... With the The relationship between them, then the generation of a non-interactive zero-knowledge proof based on the stated information and the digital certificate, includes: Generate random numbers, and based on the random numbers and the... Generate commitment values; Based on the commitment value, the and stated A hash operation is performed to obtain a challenge value, and a response value is generated based on the challenge value, the random number, and the evidence w in the digital certificate corresponding to the statement x. The non-interactive zero-knowledge proof is obtained based on the commitment value and the response value.

6. The method as described in claim 4, characterized in that, Sending the certificate status proof and the current accumulator value to the verifier includes: The non-interactive zero-knowledge proof, the statement information, the certificate status proof, and the current accumulator value are sent to the verifier so that the verifier can determine that the holder's identity legitimacy verification has passed based on the non-interactive zero-knowledge proof and the statement information, and verify the validity of the holder's digital certificate based on the certificate status proof and the current accumulator value.

7. The method as described in claim 1, characterized in that, The method further includes: Send a certificate issuance request to the certificate issuer, the certificate issuance request carrying hash data corresponding to multiple attribute information of the holder; Receive the original signature data sent by the certificate issuer; Based on the baseline parameters generated and published by the certificate issuer, the original signature data, and the multiple attribute information, the validity verification of the original signature data is confirmed to be successful. The hash data corresponding to the original signature data and the multiple attribute information is then stored to obtain the digital certificate.

8. The method according to any one of claims 2-7, characterized in that, The baseline parameters are generated based on preset security parameters λ when the certificate issuer is initialized. They include system parameters, issuer public key, accumulator public key, and a complete set of attributes containing all possible attributes. The issuer public key is determined based on the issuer private key, and the issuer private key is generated based on the system parameters. The certificate revocation list includes at least one user identifier of a revoked certificate and an accumulator value determined based on the user identifier of the revoked certificate and the accumulator private key. The accumulator private key is generated based on the system parameters, and the accumulator public key is determined based on the accumulator private key.

9. The method as described in claim 8, characterized in that, The certificate status proof includes first data and second data. The step of generating the certificate status proof based on the obtained user identifier of the revoked certificate, the current accumulator value, and the holder's user identifier includes: When there are multiple user identifiers in the certificate revocation list, the difference between the value corresponding to each of the multiple user identifiers and the value corresponding to the holder's user identifier is determined. Based on the product of the multiple differences and the system parameters, the first data is determined to characterize the degree of difference between the holder's user identifier and the multiple user identifiers. Based on the accumulator public key, the current accumulator value, and the multiple user identifiers, the second data is determined to characterize the degree of difference between the accumulator value corresponding to the holder's user identifier and the current accumulator value.

10. A digital certificate system based on BBS signatures, characterized in that, Includes a certificate issuing end, at least one user end, and at least one verification end: The certificate issuing end is used to maintain and publish a certificate revocation list through an accumulator. The certificate revocation list includes at least one user identifier of a revoked certificate and an accumulator value. The user terminal is used to query the certificate revocation list when the holder needs to provide a digital certificate to the verifier, and obtain the user identifier of the revoked certificate and the current accumulator value from the certificate revocation list. Based on the user identifier of the revoked certificate, the current accumulator value, and the user identifier of the holder, a certificate status certificate is generated. Send the certificate status proof and the current accumulator value to the verifier; The verification terminal of the verifier is used to verify the validity of the holder's digital certificate based on the received certificate status proof and the current accumulator value.

Images