Mobile-cloud collaborative anonymous authentication method and system supporting general access policy

Abstract

This invention relates to a mobile-cloud collaborative anonymous authentication method and system supporting general access policies. The method includes: an issuer selecting a zero-knowledge-friendly collision-resistant hash function to generate a public reference string for an arithmetic circuit description, and generating public parameters and an issuance key pair; a mobile terminal generating a user key pair and submitting a certificate request to the issuer based on a private attribute set; the issuer using a structure-based signature mechanism on equivalence classes to sign the certificate, generating an anonymous certificate; the mobile terminal randomizing the user's public key and the anonymous certificate, generating partial proof information and sending it to a cloud server; the cloud server generating a zero-knowledge proof and returning it to the mobile terminal; and the mobile terminal generating a display token based on the proof result; and the verifier receiving the display token and verifying the validity of the zero-knowledge proof. This method achieves efficient proof and verification of complex general access control policies while ensuring user privacy and non-associability.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a mobile-cloud collaborative anonymous authentication method and system that supports universal access policies. Background Technology

[0002] Anonymous certificates are a type of cryptographic technology used to achieve privacy-preserving authentication and fine-grained access control. The basic idea is that a user holds a legitimate certificate issued by a trusted issuer based on their attribute information. When authenticating with a verifier, the user can present a proof token derived from this certificate in a non-associative manner. The verifier can verify the validity of this proof token and determine whether the user's hidden attributes meet the predetermined access control policy, without needing to know the user's true identity or the specific values ​​of the undisclosed attributes. In recent years, with the rapid development of the digital economy, internet services, and data element circulation, anonymous certificate technology has been extensively researched and applied in scenarios such as identity management, fintech, smart cities, e-government, healthcare, and education services. Related research has publicly proposed various anonymous certificate schemes, such as randomized certificates, decentralized or threshold certificates, multi-institutional certificates, delegated certificates, keyed verification certificates, issuer-hidden certificates, functional certificates, and certificates based on zero-knowledge proofs. Existing anonymous certificate technologies have played a significant role in improving the security, privacy, and flexibility of digital services.

[0003] From the perspective of access control capabilities, existing anonymous certificate schemes can be broadly categorized as follows: The first category is selective disclosure certificates, typically built upon digital signatures and efficient zero-knowledge proof protocols. These allow users to disclose only a subset of attributes during authentication, hiding the rest. This is a relatively mature implementation suitable for basic selective disclosure scenarios, but its access control capabilities are usually limited to attribute display or simple conditional verification, making it difficult to natively support more complex and flexible access control logic. The second category is functional certificates, generally built upon cryptographic tools such as predicate encryption. This allows certificate issuance and verification to revolve around specific predicates, thus supporting richer access policy expressions than selective disclosure certificates. This represents a further advancement in functional expression compared to selective disclosure certificates, but existing practical solutions support limited policies. The types are still limited, and they are generally unable to cover more general complex logic, arbitrary computational relationships, or access policies in the form of general circuits. At the same time, some solutions still have shortcomings in terms of interaction rounds, system efficiency, and engineering deployment. The third type is zkSNARK-based certificates, which use zero-knowledge concise non-interactive knowledge proof technology to enable users to prove that hidden attributes satisfy complex relationships represented by circuits without revealing sensitive attributes. Therefore, they have the potential to support advanced access control policies and are stronger in terms of access control expression capabilities, and can support more general policy forms. However, they usually rely on a heavy proof generation process and have high requirements for computing resources, memory resources, and implementation environment. Most existing solutions are designed for servers, blockchain nodes, or high-performance devices and have not been specifically optimized for mobile terminals.

[0004] However, existing technologies still have the following problems and shortcomings: most existing anonymous certificate schemes only support basic selective disclosure or relatively simple predicate policies, making it difficult to support complex, flexible, and scalable general access control policies; existing zkSNARK-based certificate schemes that support complex policies usually have high computational overhead and are not suitable for direct deployment on resource-constrained mobile devices; the signature algorithms, hash algorithms, and protocol structures commonly used in existing anonymous certificate schemes are not necessarily suitable for zero-knowledge circuit implementations, further increasing the cost of proof generation on mobile devices; existing technologies lack anonymous certificate mechanisms for collaborative computing between mobile terminals and the cloud; and existing technologies still have significant shortcomings in balancing privacy, security, support for complex policies, and practical deployability in mobile scenarios.

[0005] Therefore, traditional anonymous certificate schemes can only support selective disclosure of basic attributes or simple predicate policies, and schemes that support complex policies have high computational overhead. At the same time, they lack computational task decomposition and privacy protection mechanisms, and often have insufficient support for complex access policies and cannot balance privacy and efficiency. Summary of the Invention

[0006] Based on this, in order to solve the above-mentioned technical problems, a mobile-cloud collaborative anonymous authentication method and system that supports general access policies is provided. Under the premise of ensuring user privacy, security and non-association, it can achieve efficient proof and verification of complex general access control policies.

[0007] A mobile-cloud collaborative anonymous authentication method supporting a universal access policy, the method comprising:

[0008] The issuer selects a zero-knowledge-friendly collision-resistant hash function to generate a common reference string for the arithmetic circuit description, and generates common parameters based on the input security parameters; the issuer then generates a private key and a public key based on the common parameters.

[0009] The user identifier, private attribute set, and public parameters are input into the mobile terminal, which generates the user's private key and public key, and submits a certificate request to the issuer based on the private attribute set.

[0010] The issuer verifies the legitimacy of the certificate request and uses a structure-based signature mechanism on equivalence classes to sign the user attributes and generate an anonymous certificate.

[0011] The mobile terminal randomizes the user's public key and anonymous certificate, generates partial proof information, and sends it to the cloud server. Based on the partial proof information and a predefined access control policy, the cloud server generates a zero-knowledge proof as the proof result and returns it to the mobile terminal. The mobile terminal generates a display token based on the proof result.

[0012] The verifier receives the display token and verifies the validity of the zero-knowledge proof, confirming that the anonymous certificate is valid and that the user hiding attributes satisfy the access control policy.

[0013] In one embodiment, the issuer selects a zero-knowledge-friendly collision-resistant hash function to generate a common reference string for the arithmetic circuit description, and generates common parameters based on the input security parameters, including:

[0014] The issuer generates a type III bilinear group based on the input security parameters. The type III bilinear group includes a bilinear mapping, prime order, and generator.

[0015] The issuer selects the Poseidon hash function as the zero-knowledge friendly collision-resistant hash function and configures the input length, output length, and number of permutation rounds of the Poseidon hash function.

[0016] The issuer obtains the arithmetic circuit description transformed by the access control policy and generates a zero-knowledge proof public reference string for the arithmetic circuit description;

[0017] The common parameter is a combination of the type III bilinear group, the Poseidon hash function, and the zero-knowledge proof common reference string.

[0018] In one embodiment, the issuer generates an issuance private key and an issuance public key based on the public parameters, including:

[0019] The issuer selects a prime number order from the public parameters and generates an issuance private key based on the prime number order.

[0020] The issuer selects a generator from the public parameters and generates an issuance public key based on the generator.

[0021] The issuer verifies the legitimacy of the private and public keys through the bilinear mapping. If the verification fails, the issuer regenerates the key pair.

[0022] In one embodiment, a user identifier, a private attribute set, and the public parameters are input to a mobile terminal. The mobile terminal generates a user private key and a user public key, and submits a certificate request to the issuer based on the private attribute set, including:

[0023] The mobile terminal randomly selects a user's private key based on the public parameters, and calculates the user's public key according to the public parameters;

[0024] The zero-knowledge friendly collision-resistant hash function is used to process the private attribute set to generate attribute values, and a certificate request message is constructed based on the user's public key and the attribute values.

[0025] Generate a zero-knowledge proof to prove that the mobile terminal possesses the user's private key corresponding to the user's public key;

[0026] The mobile terminal combines the certificate request message and the zero-knowledge proof of the user's private key into a certificate request and sends it to the issuer.

[0027] In one embodiment, the issuer verifies the legitimacy of the certificate request and signs the user attributes using a structure-based signature mechanism on equivalence classes to generate an anonymous certificate, including:

[0028] The issuer receives the certificate request submitted by the mobile terminal, queries the registration list to confirm that the user identifier in the certificate request has not been used, and verifies the validity of the zero-knowledge proof of the user's private key in the certificate request.

[0029] The issuer extracts the configuration parameters of the structure-preserving signature mechanism on the equivalence class from the public parameters, and initializes the signature runtime environment of the signature mechanism based on the issued private key;

[0030] The issuer performs hash and aggregation operations on the private attribute set using the zero-knowledge friendly collision-resistant hash function to obtain the attribute aggregation hash value, and combines the user public key and the attribute aggregation hash value according to the specification to generate a signature message vector that is compatible with the structure to maintain the signature mechanism.

[0031] The issuer performs a structure-based signature operation on the signed message vector to generate a core signature;

[0032] The issuer integrates the user identifier, attribute aggregate hash value, user public key, core signature, and issuance private key to generate an anonymous certificate.

[0033] In one embodiment, the mobile terminal randomizes the user's public key and anonymous certificate, generates partial proof information, and sends it to the cloud server, including:

[0034] The mobile terminal selects a random transformation factor from the public parameters, and performs a bilinear group operation on the user public key using the random transformation factor to generate a randomized user public key;

[0035] The mobile terminal uses the random transformation factor to randomize the anonymous certificate based on the structure-preserving signature mechanism on equivalence classes, and generates a randomized anonymous certificate.

[0036] The mobile terminal calculates a randomized user private key based on the user's private key and a random transformation factor, and generates a lightweight zero-knowledge proof.

[0037] The mobile terminal integrates the randomized user public key, randomized anonymous certificate, randomized user private key, and lightweight zero-knowledge proof to generate partial proof information without privacy leakage and sends it to the cloud server.

[0038] In one embodiment, the cloud server, based on the partial proof information and a predefined access control policy, generates a zero-knowledge proof as the proof result and returns it to the mobile terminal. The mobile terminal generates a display token based on the proof result, including:

[0039] The cloud server receives partial proof information sent by the mobile terminal and verifies the partial proof information;

[0040] The cloud server constructs public statements and witnesses based on the verified partial proof information and access control policies, and runs a zero-knowledge proof generation algorithm to generate zero-knowledge proofs.

[0041] The cloud server returns the zero-knowledge proof and the public statement as proof results to the mobile terminal;

[0042] The mobile terminal confirms that the public statement is consistent with the partial proof information, verifies that the zero-knowledge proof passes the verification algorithm, and generates a display token after the verification is successful.

[0043] In one embodiment, the verifier receives the display token and verifies the validity of the zero-knowledge proof, confirming that the anonymity certificate is valid and the user hiding attributes satisfy the access control policy, including:

[0044] The verifier receives the display token and verifies the validity of the zero-knowledge proof in the display token;

[0045] The verifier verifies the validity of the anonymous certificate using a bilinear pairing operation;

[0046] The verifier obtains a public reference string of zero-knowledge proofs corresponding to the access control policy, runs a zero-knowledge proof verification algorithm, and verifies whether the user's hidden attributes satisfy the access control policy.

[0047] A mobile-cloud collaborative anonymous authentication system supporting a universal access policy, the system comprising:

[0048] The issuer is used to select a zero-knowledge-friendly collision-resistant hash function, generate a public reference string for the arithmetic circuit description, and generate public parameters based on the input security parameters; the issuer generates a private key and a public key based on the public parameters.

[0049] A mobile terminal is used to receive a user identifier, a private attribute set, and the public parameters, generate a user private key and a user public key, and submit a certificate request to the issuer based on the private attribute set.

[0050] The issuer also uses this to verify the legitimacy of the certificate request and employs a structure-based signature mechanism on equivalence classes to sign user attributes and generate an anonymous certificate.

[0051] The mobile terminal is also used to randomize the user's public key and anonymous certificate, generate partial proof information and send it to the cloud server. The cloud server generates a zero-knowledge proof based on the partial proof information and a predefined access control policy, and returns the proof result to the mobile terminal. The mobile terminal generates a display token based on the proof result.

[0052] The verifier receives the display token and verifies the validity of the zero-knowledge proof, confirming that the anonymous certificate is valid and that the user-hidden attributes satisfy the access control policy.

[0053] The aforementioned mobile-cloud collaborative anonymous authentication method and system supporting general access policies converts access control policies into arithmetic circuit descriptions and, based on zero-knowledge proof technology, enables the verifier to verify whether a user's hidden attributes satisfy any complex access policy that can be converted into circuit form. By collaborating with mobile terminals and cloud servers, the highly complex zero-knowledge proof generation task is offloaded to the cloud server, and the mobile terminal only needs to perform local lightweight computation, reducing the computational overhead, energy consumption, and response latency of the mobile terminal. Through the structure-preserving signature mechanism on equivalence classes and certificate randomization processing, multiple authentication processes of the same user based on the same certificate cannot be associated with each other, protecting the user's privacy and anonymity. Attached Figure Description

[0054] Figure 1 This is a schematic diagram of the application environment and system architecture of a mobile-cloud collaborative anonymity authentication method that supports a general access policy in one embodiment.

[0055] Figure 2 This is a flowchart illustrating a mobile-cloud collaborative anonymous authentication method that supports a general access policy in one embodiment.

[0056] Figure 3 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0058] The mobile-cloud collaborative anonymous authentication method supporting universal access policies provided in this application embodiment can be applied to, for example... Figure 1 The application environment shown. For example... Figure 1As shown, the application environment includes an interconnected publisher 110, a mobile terminal 120, a cloud server 130, and a verifier 140. Issuer 110 selects a zero-knowledge-friendly collision-resistant hash function to generate a common reference string for the arithmetic circuit description and generates common parameters based on the input security parameters. Issuer 110 generates a private key and a public key based on the common parameters. The user identifier, private attribute set, and common parameters are input to mobile terminal 120. Mobile terminal 120 generates the user's private key and public key and submits a certificate request to issuer 110 based on the private attribute set. Issuer 110 verifies the legality of the certificate request and uses a structure-based signature mechanism on equivalence classes to sign the user attributes, generating an anonymous certificate. Mobile terminal 120 randomizes the user's public key and anonymous certificate, generates partial proof information, and sends it to cloud server 130. Cloud server 130 generates a zero-knowledge proof based on the partial proof information and a predefined access control policy, and returns the proof result to mobile terminal 120. Mobile terminal 120 generates a display token based on the proof result. Verifier 140 receives the display token and verifies the validity of the zero-knowledge proof, confirming that the anonymous certificate is valid and the user's hidden attributes meet the access control policy.

[0059] In one embodiment, such as Figure 2 As shown, a mobile-cloud collaborative anonymous authentication method supporting a universal access policy is provided, including the following steps:

[0060] Step 202: The issuer selects a zero-knowledge friendly collision-resistant hash function to generate a public reference string for the arithmetic circuit description, and generates public parameters based on the input security parameters; the issuer generates the private key and public key based on the public parameters.

[0061] During the initialization phase, the issuer needs to generate common parameters upon which the entire anonymous certificate system depends for operation. The issuer also uses these parameters to verify user attributes and issue anonymous certificates.

[0062] In one embodiment, a mobile-cloud collaborative anonymous authentication method supporting a universal access policy may further include a process for generating public parameters. This process includes: the issuer generating a Type III bilinear group based on input security parameters, whereby the Type III bilinear group includes a bilinear mapping, prime order, and generator; selecting the Poseidon hash function as a zero-knowledge-friendly collision-resistant hash function and configuring its input length, output length, and number of permutation rounds; obtaining the arithmetic circuit description transformed by the access control policy and generating a zero-knowledge proof public reference string for the arithmetic circuit description; and combining the Type III bilinear group, the Poseidon hash function, and the zero-knowledge proof public reference string into public parameters. The issuer can then execute the algorithm. Enter security parameters and output common parameters. .

[0063] Specifically, the issuer first needs to obtain preset security parameters. These parameters determine the security strength of the cryptographic primitives and are used to control the size of the Type III bilinear group, the output length of the hash function, and the reliability of the zero-knowledge proof. The issuer needs to select a collision-resistant hash function that is friendly to zero-knowledge proofs from a predefined family of hash functions. In this embodiment, the issuer selects the Poseidon hash function as a zero-knowledge-friendly collision-resistant hash function. Poseidon is a hash function based on a sponge structure design, and its underlying operations are mainly based on simple algebraic operations on prime fields, making it highly compatible with arithmetic circuits. The issuer can determine the input length, output length, and number of permutation rounds of the Poseidon hash function based on the security parameters.

[0064] Specifically, Poseidon is a zero-knowledge proof-friendly cryptographic hash function, specifically designed for efficient implementation in zero-knowledge proof systems, and defines it in... The string mapping on is defined in Fixed-length strings on: ,in For the output length, and in The number of elements in the middle is used to measure (usually) Poseidon employs a sponge structure and a specific permutation layer built upon simple algebraic operations on prime fields, making it highly compatible with arithmetic circuits. Compared to traditional hash functions (such as...), it... and Compared to [previous design], this design significantly reduces circuit complexity, thus achieving [better performance] than [previous design]. When used in combination, they can significantly reduce the data overhead of proofs and improve the efficiency of proof generation. Therefore, Especially suitable for It is applicable because it reduces the overhead of both proof generation and verification.

[0065] To reduce the size of the zero-knowledge proof circuit corresponding to complex access strategies, a hash function suitable for zero-knowledge proof circuit processing is used to process the user attribute set to generate attribute commitment values. The Poseidon hash function requires fewer constraints in the zero-knowledge proof circuit, thus effectively reducing the circuit size in the proof generation process and improving the overall system operating efficiency. It is particularly suitable for application scenarios where mobile terminals and cloud servers collaborate.

[0066] In this embodiment, the issuer converts the access control policy defined by the service provider into an arithmetic circuit description and generates a public reference string required for zero-knowledge proof based on this description. Specifically, the issuer receives the access control policy defined by the service provider or system administrator. The access control policy may contain complex logical expressions, numerical comparisons, combination conditions, etc. The issuer converts these policies into equivalent arithmetic circuit descriptions, where the circuit descriptions represent the computational logic of the policies using arithmetic gates over finite fields. The issuer can then run the trusted setup algorithm of the zero-knowledge proof protocol, taking the arithmetic circuit description as input and outputting a public reference string. This public reference string is part of the public parameters and is subsequently used in the proof generation and verification process. Finally, the issuer can combine the Type III bilinear group, the Poseidon hash function, and the zero-knowledge proof public reference string into public parameters.

[0067] Among them, let For a relation generator (e.g., an arithmetic circuit description), for the description A zero-knowledge concise non-interactive knowledge argument (zkSNARK) consists of the following probabilistic multinomial-time (PPT) algorithm: Input Relationship Output the Common Reference String (CRS). and simulated trapdoor ; Enter the common reference string And witness statements Output proof ; Enter the common reference string Statement and proof ,like If valid, output 1; otherwise, output 0. Enter the common reference string Statement and simulated trapdoor Output proof If a A scheme is considered secure if it satisfies both reliability and simulation extractability; Groth16 is a trusted setting. Solution. To instantiate this solution, the following is adopted: The protocol is used to construct zero-knowledge proofs for general access strategies.

[0068] In one embodiment, a mobile-cloud collaborative anonymous authentication method supporting a universal access policy may further include a process for generating an issuance key, specifically including: the issuer selecting a prime order from public parameters and generating an issuance private key based on the prime order; the issuer selecting a generator from public parameters and generating an issuance public key based on the generator; and the issuer securely storing the issuance private key and publicly disclosing the issuance public key.

[0069] After completing system initialization, the issuer can also generate the key pair required for subsequent certificate issuance. The issuer keeps the private key secret and uses it to sign user certificates; the issuer's public key is made public so that mobile terminals and verifiers can verify the legitimacy of certificates and tokens.

[0070] The issuer can obtain the generated public parameters, randomly select two secret values ​​from a finite field of prime order as the private key, and calculate the corresponding public key based on the selected secret values ​​and the generator of the bilinear group, thus forming a complete issuance key pair. The private key is then securely stored, and the public key is distributed to a public directory or embedded in the system's public parameters for access by mobile terminals, cloud servers, and verifiers. The issuer can execute the algorithm. Input common parameters Then output the private / public key pair used for issuance. Publishers can also execute algorithms. The input includes common parameters. Issuing private / public key pairs and user certificate request If successful, the algorithm outputs the user certificate. If it fails, output the failure identifier. During the key generation process The publisher can randomly select For all ,calculate ;set up , .

[0071] In this embodiment, the algorithm Generate common parameters Choose a zero-knowledge proof-friendly collision-resistant hash function: Then by running generate The common parameters, and by running For a given arithmetic circuit description Generate a common reference string; finally, set... and output . The algorithm runs Generate a pair of private / public keys for issuance. And output it.

[0072] The issuer also generates bilinear pairs. ; for a given arithmetic circuit description calculate ;set up .set up and For prime numbers of order 1 Let be a cyclic group. and They are respectively and generators, mappings A mapping is called a bilinear mapping if it satisfies the following three properties: Bilinear: for any , as well as ,have Non-degenerative properties: Computability: Mapping It can be computed efficiently. In this embodiment, based on type III pairing, this means that in and There is no efficiently computed homomorphic mapping between them. In this embodiment, the generation process of the type III bilinear group can be defined as: in, For safety parameters.

[0073] Step 204: Input the user identifier, private attribute set, and public parameters into the mobile terminal. The mobile terminal generates the user's private key and user's public key, and submits a certificate request to the issuer based on the private attribute set.

[0074] As a trusted device held and controlled by the user, the mobile terminal is responsible for performing local privacy calculations and generating certificate requests. Its primary function is to generate and store the user's private key, public key, and related attribute information.

[0075] In one embodiment, a mobile-cloud collaborative anonymous authentication method supporting a universal access policy may further include a process in which a mobile terminal submits a certificate request. The specific process includes: the mobile terminal randomly selecting a user's private key based on public parameters and calculating a user's public key based on the public parameters; performing commitment processing on a private attribute set using a zero-knowledge-friendly collision-resistant hash function to generate attribute commitment values, and constructing a certificate request message based on the user's public key and the attribute commitment values; generating a zero-knowledge proof to demonstrate that the mobile terminal possesses a user's private key corresponding to the user's public key; and the mobile terminal combining the certificate request message and the zero-knowledge proof of the user's private key into a certificate request and sending it to the issuer.

[0076] Mobile terminals can obtain input parameters that include public parameters, user identifiers, and private attribute sets. The user identifier is a unique identifier for the user, and the private attribute set is a collection of user attributes containing several attribute value pairs. This private attribute set represents the user's private information and is only disclosed to the issuer during the certificate request phase; the specific values ​​will be hidden during subsequent authentication processes.

[0077] The mobile terminal randomly selects a secret value from a finite field of prime order as the user's private key, which is securely stored by the mobile terminal. Next, the mobile terminal can calculate the corresponding user public key based on the user's private key and the generator. The user public key is a group element and will be submitted to the issuer in the certificate request for subsequent certificate issuance and verification. The mobile terminal securely stores the generated user key pair locally. The mobile terminal can run the algorithm. The input includes common parameters. User identifier and a set of private properties Generate a private / public key pair And a certificate request Specific mobile terminals can run algorithms. The input includes common parameters. User private key / public key pair The issuer's public key and issued certificates If certificate verification passes, the algorithm outputs 1; otherwise, it outputs 0. This involves generating a certificate request. During the process, the mobile terminal can randomly select and calculate ;Calculate Schnorr and prove: ;set up .

[0078] Next, to reduce the size of subsequent zero-knowledge proof circuits, the mobile terminal uses the Poseidon hash function to perform commitment processing on the private attribute set. This involves hashing the entire attribute set to calculate the attribute commitment value. This commitment value is used to prove to the issuer that the user holds a specific attribute set, without exposing individual attribute values. The certificate request message constructed by the mobile terminal may include: a user identifier for the issuer to identify the user; a user public key for binding to the attribute; and an attribute commitment value, a hash commitment of the attribute.

[0079] To prevent malicious users from impersonating others' public keys to initiate certificate requests, the mobile terminal generates a zero-knowledge proof demonstrating that it possesses the user's private key corresponding to the user's public key. Specifically, the mobile terminal can run a zero-knowledge proof protocol to generate a zero-knowledge proof, then assemble it into a certificate request and send it to the issuer via a secure channel.

[0080] In this embodiment, the algorithm To have attribute set (in (Total number of user attributes) Generate user private / public key pairs and certificate request By running Generate user private / public key pairs and run... Compute zero-knowledge proofs; finally, let and output .

[0081] Step 206: The issuer verifies the legitimacy of the certificate request and uses a structure-based signature mechanism on equivalence classes to sign the user attributes and generate an anonymous certificate.

[0082] Upon receiving a certificate request from a mobile terminal, the issuer verifies the request's legitimacy and issues anonymous certificates to legitimate users. As a trusted global participant, the issuer is responsible for verifying user identity and issuing certificates after binding user attributes with the user's public key.

[0083] In one embodiment, a mobile-cloud collaborative anonymous authentication method supporting a universal access policy may further include a certificate issuance process, specifically comprising: the issuer receiving a certificate request submitted by a mobile terminal, querying the registration list to confirm that the user identifier in the certificate request is not used, and verifying the validity of the zero-knowledge proof of the user's private key in the certificate request; the issuer extracting configuration parameters of the structure-preserving signature mechanism on the equivalence class from public parameters; the issuer performing hash and aggregation operations on the private attribute set using a zero-knowledge-friendly collision-resistant hash function to obtain an attribute aggregation hash value, and combining the user's public key and the attribute aggregation hash value according to the specification to generate a signature message vector adapted to the structure-preserving signature mechanism; the issuer performing a structure-preserving signature operation on the signature message vector to generate a core signature; and the issuer integrating the attribute aggregation hash value and the core signature to generate an anonymous certificate.

[0084] In this embodiment, the mobile terminal generates a private key and a public key through an updatable public key mechanism, and sends a certificate request to the issuer with the public key and attribute information. After completing the user qualification review, the issuer binds the user attributes with the user's public key and generates a corresponding anonymous certificate. The updatable public key mechanism is conducive to realizing key management and dynamic updates in a multi-user environment, and enhances the flexibility and scalability of the system in mobile scenarios.

[0085] Issuers can receive input information containing public parameters, the private key, the public key, and a certificate request, and perform multi-dimensional verification on the received certificate request to ensure the legality and authenticity of the request.

[0086] Specifically, the issuer can check if the user identifier already exists in the system's registration list. That is, it queries the registration list to confirm whether the user identifier has already been used by another user. If the user identifier already exists, the request is rejected, and a failure flag is returned. If the user identifier is unique, subsequent verification steps continue. Next, the issuer verifies the zero-knowledge proof submitted by the mobile terminal to confirm that the requester indeed possesses the user's private key corresponding to the user's public key. If all the above verification steps pass, the certificate request is valid, and the issuer enters the certificate issuance stage; otherwise, a failure flag is returned.

[0087] The issuer uses the same Poseidon hash function as the mobile terminal to process user attributes, obtains the approved attribute set, calculates the hash value of each attribute, and uses each attribute hash value as a message vector to be signed. Next, a structure-preserving signature algorithm can be run to sign the attribute hash message vector. This is mainly achieved by obtaining a secret value randomly selected during the issuance key generation process, the Poseidon hash value of each attribute, and the bilinear group parameter, and randomly selecting a random factor from a finite field of prime order to ensure the randomization capability of the signature. Subsequently, the mobile terminal can randomize the certificate display, calculate the signature component, and assemble the message vector, signature component, and other auxiliary information into a complete anonymous certificate. After the issuer completes the certificate issuance, it can update the registration list and send the generated anonymous certificate to the mobile terminal.

[0088] In this embodiment, the issuer can use a structure-preserving signature mechanism on equivalence classes to sign user attribute messages to obtain an anonymous certificate. This signature mechanism supports certificate randomization and presentation token randomization, making it difficult for multiple authentication processes of the same user based on the same certificate to be correlated, thereby improving anonymity and uncorrelatedness. At the same time, the structure-preserving signature mechanism can also guarantee the authenticity and unforgeability of the certificate, preventing malicious users from constructing fake attribute certificates or forging authentication results.

[0089] In this embodiment, the algorithm Validation request and for users Certificate Issuance ,verify The uniqueness of the evidence should be verified offline, if necessary, for any additional supporting materials. Then return Otherwise, by running Create a certificate, where and Finally, output Among them, issuing certificates During the process, if If verification fails, return [return] The publisher can calculate the hash value of the attribute: , , Random selection ,calculate .

[0090] The Updatable Public Key (UPK) consists of the following probabilistic multinomial-time (PPT) algorithm: Enter security parameters Output parameters In one embodiment, the system common parameters are: ,in, prime order cyclic group Let A be the generator of the cyclic group. This is a hash function. Input common parameters Random selection And output the private key and public key ; Enter public key and a random conversion factor Output the updated public key In one embodiment, the updated public key satisfies... . Enter your private key Public key And news Output an efficient zero-knowledge proof about the private key: In one embodiment, random selection calculate and output . Input zero-knowledge proof Public key and messages ,calculate And verify Check if the condition is true; if true, output 1, otherwise output 0. Because... Therefore, the output is 1 if the proof was generated by a valid private key; otherwise, the output is 0. If a A scheme is considered secure if it satisfies the properties of being unforgeable and indistinguishable. Among these, It is a non-interactive zero-knowledge proof (NIZK) that satisfies the security properties of zero-knowledge proofs, such as reliability and simulated extractability.

[0091] The Structure Preserving Signature (SPS-EQ) over equivalence classes consists of the following probabilistic multinomial-time (PPT) algorithm: Enter security parameters Output bilinear group in, For prime numbers of order 1 cyclic group They are generators, It is a bilinear mapping. Input bilinear group and message vector length , And output the signing private key and public key in ; Enter the signing private key and message vector Random selection ,calculate and output signature ; Input message vector ,sign and random transformation factor Output the updated message-signature pair In one embodiment, let And calculate the updated signature accordingly. ; Input message vector ,sign and public key Verify whether the following relation is satisfied: If true, output 1; otherwise, output 0. As can be seen from the signature generation formula, Therefore, And because Therefore, we can obtain Therefore, the verification algorithm outputs 1. Furthermore, for the transformed message vector and signature, we have... Under the premise that equivalence class transformation preserves structural relationships, the updated message-signature pair still maintains verifiability. If a A scheme is considered secure if it satisfies Existence Unforgeability-CMA (EUF-CMA) under chosen-message attacks and has perfect signature compatibility. To maximize the efficiency of mobile user computation, this scheme design uses... and To construct a user certificate.

[0092] Step 208: The mobile terminal randomizes the user's public key and anonymous certificate, generates partial proof information, and sends it to the cloud server. Based on the partial proof information and a predefined access control policy, the cloud server generates a zero-knowledge proof as the proof result and returns it to the mobile terminal. The mobile terminal generates a display token based on the proof result.

[0093] The mobile terminal can perform local lightweight computations related to the user's private key, random number, and attribute binding; it is responsible for randomizing the user's public key and anonymous certificate, generating publicly available intermediate values, constructing partial zero-knowledge proofs, and then securely sending this information to the cloud server so that the cloud server can complete the highly complex proof generation task.

[0094] In one embodiment, a mobile-cloud collaborative anonymity authentication method supporting a universal access policy may further include a mobile terminal processing procedure, specifically including: the mobile terminal selecting a random transformation factor from public parameters, performing calculations on the user's public key using the random transformation factor to generate a randomized user public key; the mobile terminal maintaining a signature mechanism based on equivalence classes, using the random transformation factor to randomize the anonymity certificate, generating a randomized anonymity certificate; the mobile terminal calculating the randomized user private key based on the user's private key and the random transformation factor, and generating a first zero-knowledge proof to prove ownership of the randomized user private key; generating a second zero-knowledge proof based on a private attribute set to prove that the attributes are consistent with the commitments in the randomized anonymity certificate; and the mobile terminal integrating the randomized user public key, the randomized anonymity certificate, the issuing public key, the first zero-knowledge proof, and the second zero-knowledge proof to generate partial proof information and sending it to the cloud server.

[0095] The mobile terminal can obtain input parameters including public parameters, issuing public key, user private key, user public key, anonymous certificate, private attribute set, and access control policy. It then performs randomization transformations on the user public key and anonymous certificate to generate a randomized version that cannot be associated with the original certificate. Specifically, the mobile terminal can randomly select two random transformation factors from a finite field of prime order for the randomization of the public key and certificate. The access control policy defined by the service provider is transformed into a constraint relation or arithmetic circuit that can be processed by a zero-knowledge proof system. The access control policy can be a complex, multi-conditional, and composable logical expression that can be converted into access rules in a zero-knowledge proof-compatible constraint form. During certificate presentation, the user does not need to expose the underlying attribute values; they only need to prove that the hidden attributes satisfy the above access control policy, thereby achieving fine-grained privacy access control.

[0096] In this embodiment, the mobile terminal can randomize the user's public key based on an updatable public key mechanism to calculate a randomized user public key. This operation ensures that public keys used by the same user in different authentication sessions cannot be associated. Next, the mobile terminal can randomize the anonymous certificate based on a structure-based signature mechanism on equivalence classes. First, each component in the attribute hash message vector is randomized, then the signature component is randomized, and finally, the randomized components are assembled into a randomized anonymous certificate.

[0097] The mobile terminal can prepare the input information required for proof generation for the cloud server. Specifically, the mobile terminal can perform commitment processing on the private attribute set in the same way as the issuer, calculating the hash value and attribute commitment vector of each attribute; then, it can obtain the access control policy required by the verifier, prepare the corresponding arithmetic circuit description, and construct the statement to be published to the cloud server; finally, the mobile terminal can calculate the randomized private key and the first zero-knowledge proof, proving that the mobile terminal knows the randomized private key, and can also construct the proof target, generate a locally computable second zero-knowledge proof involving the consistency verification of attribute values ​​and commitments, assemble it into partial proof information, and send it to the cloud server through a secure channel.

[0098] In one embodiment, a mobile-cloud collaborative anonymity authentication method supporting a universal access policy may further include a cloud server processing procedure, specifically including: the cloud server receiving partial proof information sent by the mobile terminal and verifying the partial proof information; the cloud server constructing a public statement and a witness based on the verified partial proof information and access control policy, and running a zero-knowledge proof generation algorithm to generate a zero-knowledge proof; the cloud server returning the zero-knowledge proof and the public statement as proof results to the mobile terminal; the mobile terminal confirming that the public statement is consistent with the partial proof information, passing the zero-knowledge proof through the verification algorithm, and generating a display token after successful verification.

[0099] The cloud server is used to assist in the generation of highly complex zero-knowledge proofs corresponding to complex access control policies without directly obtaining the user's complete private input. The cloud server receives partial proof information sent by the mobile terminal, generates a complete zero-knowledge proof based on a predefined access control policy, and returns the proof result to the mobile terminal. After receiving the proof result, the mobile terminal assembles and generates the final display token and submits it to the verifier for verification.

[0100] The cloud server can obtain public parameters, the issued public key, and partial proof information as input parameters. Before generating a complete proof, it first verifies the validity of the partial proof information provided by the mobile terminal. Specifically, the cloud server can run a zero-knowledge proof verification algorithm to verify the first zero-knowledge proof, proving that the mobile terminal knows the randomized user's private key. If the verification fails, it returns an error flag and terminates. Next, it can run a partial proof verification algorithm to verify the second zero-knowledge proof, proving the validity of the attribute consistency proof fragment provided by the mobile terminal and confirming the correspondence between the private attribute set and the message vector in the randomized certificate. If the verification fails, it returns an error flag and terminates. Then, it also needs to confirm that the access control policy has been converted into an arithmetic circuit description and confirm that the public reference string matches the circuit description. If the policy format is invalid or the circuit does not match, it returns an error flag and terminates. Finally, based on the public statement provided by the mobile terminal and the verified proof, the cloud server constructs a complete zero-knowledge proof, encapsulates the generated zero-knowledge proof as a proof result, and returns it to the mobile terminal.

[0101] The mobile terminal can obtain public parameters, the issuing public key, a locally stored randomized certificate, a locally stored randomized public key, one-time challenge information, and the proof result returned by the cloud server as input. Before assembling the display token, it verifies the validity of the zero-knowledge proof returned by the cloud server. Specifically, the mobile terminal can verify the matching between the proof and the request, the validity of the zero-knowledge proof, and the consistency between the proof and local data. It then assembles the verified proof and related information into the final display token and submits it to the verifier through a secure channel. To prevent the authentication token from being reused, one-time challenge information is introduced during the display token generation process. This challenge information can be a random number, a timestamp, a salt value, or a one-time random number (nonce) generated by the verifier, and this challenge information is used as part of the input to the display token and the zero-knowledge proof.

[0102] Mobile terminals and cloud servers can work together to execute algorithms. The input includes common parameters. User private key / public key pair ,Certificate A set of private attributes Complex access strategies And a random salt value (a random number or timestamp generated and signed by the validator) to generate a presentation token. , used to prove Effective and satisfy (Right now ).

[0103] The cloud server employs the Groth16 protocol to generate and verify zero-knowledge proofs that satisfy complex access control policies. Specifically, the mobile terminal is responsible for local computations related to user private keys, random messages, and certificate randomization. The cloud server, based on necessary intermediate values ​​and access control policy constraints provided by the mobile terminal, performs auxiliary generation of complex zero-knowledge proofs. Finally, the mobile terminal or a combination of the mobile terminal and the cloud server generates a display token and submits it to the verifier. The verifier verifies the display token to confirm that the certificate is valid, the display is effective, and the user's hidden attributes satisfy the predetermined access control policy. This achieves efficient privacy proof under complex access policies without requiring the verifier to know the user's true identity or underlying attribute values.

[0104] In this embodiment, the algorithm verify The correctness, if ,in and If the result is positive, return 1; otherwise, return 0. Algorithm To satisfy attribute-based access strategies (i.e. Certificate Generate a display token The mobile computing component includes: selecting a random transformation factor. and by running and Using the same random number The public key and certificate are randomized separately, where Then compute an efficient zero-knowledge proof. Final settings , ,in express cryptographic commitments, and Send to the cloud server. The server-side content includes: calculating a privacy-preserving zkSNARK proof. When the mobile terminal receives data from the cloud server... And when verification is successful, set and output .

[0105] Among them, the verification certificate During the process, the hash value of the attribute can be calculated: , , ;if and Output 1 if the condition is met, otherwise output 0. Show certificate. During the process, the mobile terminal can randomly select ,calculate ;calculate ;Calculate Schnorr and prove: ;set up,{ Using the zkSaaS framework, witnesses are... To conduct secret sharing, each share is transmitted only to an arbitrary server committee, while simultaneously sending statements... Publicly available to the committee. Groth16 proof of privacy protection for cloud server computing: When the mobile client receives from the cloud server Then, it was validated within the zkSaaS framework; it sets... and output .

[0106] Step 210: The verifier receives the display token and verifies the validity of the zero-knowledge proof, confirming that the anonymous certificate is valid and the user's hidden attributes meet the access control policy.

[0107] The authenticator receives and verifies the display token submitted by the user to determine whether the user meets the predetermined access control policy. Upon receiving the display token from the mobile terminal, the authenticator can verify the legitimacy of the user's certificate, the user's attributes' compliance with the access control policy, and the authenticity and validity of the token. As a representative of the service provider, the authenticator is responsible for executing access control decisions without needing to know the user's true identity or the specific values ​​of undisclosed attributes. During the verification process, the authenticator checks the validity of the challenge information and whether it has been reused, thereby preventing malicious users or servers from replaying historical authentication results in new authentication sessions.

[0108] In one embodiment, a mobile-cloud collaborative anonymous authentication method supporting a general access policy may further include a verification process performed by the verifier. The specific process includes: the verifier receiving a display token and verifying the validity of the one-time challenge information in the token; the verifier verifying the validity of the anonymous certificate through a bilinear pairing operation; the verifier obtaining a zero-knowledge proof public reference string corresponding to the access control policy, running a zero-knowledge proof verification algorithm, and verifying whether the user's hidden attributes satisfy the access control policy.

[0109] The verifier can obtain public parameters, issue a public key, display a token, and access control policies as input parameters. Before verifying the zero-knowledge proof, it first checks the integrity and format of the display token. Specifically, the verifier can check if the display token contains all required fields; if any field is missing or the format is invalid, the token is rejected and 0 is returned. Next, it can check the validity and uniqueness of the challenge information. Specifically, if the verifier has digitally signed the challenge information, it verifies the validity of the signature to confirm that the challenge information was indeed generated by the verifier, preventing forgery. It also checks if the timestamp is within a valid time window; if the timestamp has expired, the token is rejected and 0 is returned. It can also query local or shared challenge information history. The verifier can then execute the algorithm. The input includes common parameters. Issuer public key And show the token If the user's hidden attributes meet the access policy required by the validator... And token If the verification passes, output 1; otherwise, output 0.

[0110] The verifier can also verify the legitimacy of the randomized certificate, ensuring that the certificate is issued by a legitimate issuer and has not been tampered with. Specifically, it runs a structure-preserving signature verification algorithm to verify the validity of the randomized certificate's signature. It can also verify whether the randomized certificate is bound to the randomized public key, that is, check whether the certificate contains the hash value or binding information of the user's public key. If the certificate contains public key binding, it verifies the consistency of the binding relationship. If the binding verification fails, it rejects the token.

[0111] The verifier can run a zero-knowledge proof verification algorithm to confirm that the user's hidden attributes satisfy the access control policy. Specifically, it obtains the corresponding zero-knowledge proof public reference string based on the arithmetic circuit description corresponding to the access control policy. If the system uses a unified public reference string, it is used directly. If different policies correspond to different public reference strings, it is located based on the policy identifier. The verifier caches the public reference string locally to improve verification efficiency. It can also extract public information from the display token to construct the public statement required for verification.

[0112] Finally, the verifier combines all the verification results and makes the final access control decision. If all the above verifications pass, the verifier outputs a verification success flag, confirming that the anonymous certificate is valid and the user's hidden attributes meet the access control policy.

[0113] In this embodiment, the verifier executes the algorithm. This can be verified by checking the following equation. Correctness: ; ; If all the above equations are successfully verified, output 1; otherwise, output 0. This includes verifying the token presentation. During the process, if the salinity If it has appeared in the history before, return 0; otherwise... If verification fails, return 0; if or If, then return 0; if If the condition is met, return 1; otherwise, return 0.

[0114] In one embodiment, during the registration or certificate issuance phase, tracking information associated with the certificate is generated, and the issuer or system administrator maintains a registration list and a revocation list. During the verification phase, the verifier can determine whether the corresponding certificate has been revoked based on the relevant tracking information in the displayed token, without knowing the user's true identity.

[0115] This application provides a mobile-cloud collaborative anonymous authentication method supporting general access policies. By converting access control rules into zero-knowledge proof-compatible constraints, it overcomes the limitations of existing anonymous certificate technologies that only support simple policies or limited predicate proofs. This method supports complex, multi-condition, composable, and scalable general access control policies, significantly improving the expressiveness and applicability of the solution. Employing a mobile terminal and cloud server collaborative computing architecture, it securely partially offloads the high-complexity zero-knowledge proof generation task to the cloud, retaining only the lightweight local computation closely related to the user's private key, user attributes, and random numbers on the mobile terminal. This significantly reduces the computational overhead, energy consumption, and response latency of the mobile terminal, making it suitable for resource-constrained device deployments. Under the mobile-cloud collaborative architecture, effective protection of user identity, attributes, and witness information is achieved through zero-knowledge proofs, structure-preserving signatures, and local private computation mechanisms. The verifier can only know that the user meets a certain access control policy, but cannot know the user's true identity and underlying attribute content. Although the cloud server participates in auxiliary computation, it cannot independently recover the user's complete privacy input. It also avoids generating legitimate display tokens independently of the user, thus balancing privacy protection and system security. By employing zero-knowledge-friendly hash functions and efficient zero-knowledge proof protocols, it reduces the number of proof circuit constraints, lowers proof construction overhead, and improves proof generation and verification efficiency. Combined with modular cryptographic component design, it has good engineering feasibility, facilitating deployment in mobile applications, cloud service platforms, and other practical business systems. By introducing one-time challenge information during the authentication process, it effectively prevents display token replay attacks. Furthermore, by setting up registration and revocation lists to support anonymous certificate revocation management, the system is more suitable for practical scenarios with high security and manageability requirements, such as medical, financial, government, education, enterprise, and blockchain identity authentication. The efficient electronic ticketing system supporting attribute tickets has many applications in practical scenarios, such as allowing students, soldiers, and disabled people to purchase discounted tickets without exposing any private information (e.g., specific school, military unit, and illness). It also supports security attributes such as non-linkability, non-transferability, and non-framing, and can detect double-spending users and provide efficient tracking algorithms.

[0116] This application addresses the shortcomings of existing anonymous certificate technologies, such as insufficient support for complex access control policies, difficulty in efficient deployment on resource-constrained mobile terminals, the challenge of balancing privacy and efficiency in cloud-assisted computing, and the lack of replay protection and revocation management. It proposes a mobile-cloud collaborative anonymous certificate technology. By constructing a system architecture that enables collaborative work among mobile terminals, issuers, cloud servers, and verifiers, and employing an updatable public key mechanism, a structure-preserving signature mechanism, zero-knowledge-friendly hash functions, and a zero-knowledge proof protocol, it achieves privacy-preserving authentication under complex access control policies. This technology not only effectively reduces the computational burden on mobile terminals but also ensures the unforgeability of certificates, the non-correlation of the presentation process, and the security and reliability of the system. It possesses good engineering deployment feasibility and broad application prospects.

[0117] It should be understood that although the steps in the flowcharts above are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts above may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0118] In one embodiment, such as Figure 1 As shown, a mobile-cloud collaborative anonymous authentication system supporting a universal access policy is provided, including:

[0119] Issuer 110 is used to select a zero-knowledge friendly collision-resistant hash function, generate a common reference string for the arithmetic circuit description, and generate common parameters based on the input security parameters; Issuer 110 generates a private key and a public key based on the common parameters.

[0120] Mobile terminal 120 is used to receive user identifier, private attribute set and public parameters, generate user private key and user public key, and submit certificate request to issuer 110 based on private attribute set.

[0121] Issuer 110 is also used to verify the legitimacy of certificate requests and to sign user attributes using a structure-based signature mechanism on equivalence classes to generate anonymous certificates;

[0122] Mobile terminal 120 is also used to randomize the user's public key and anonymous certificate, generate partial proof information and send it to cloud server 130;

[0123] Cloud server 130 is used to generate zero-knowledge proof based on partial proof information and predefined access control policies, and return the proof result to mobile terminal 120. Mobile terminal 120 generates display token based on the proof result.

[0124] Verifier 140 is used to receive the display token and verify the validity of the zero-knowledge proof, confirming that the anonymous certificate is valid and that the user's hidden attributes meet the access control policy.

[0125] In one embodiment, issuer 110 is further configured to generate a type III bilinear group based on input security parameters, wherein the type III bilinear group includes a bilinear mapping, prime order, and generator; select a Poseidon hash function as a zero-knowledge-friendly collision-resistant hash function, and configure the input length, output length, and number of permutation rounds of the Poseidon hash function; obtain an arithmetic circuit description transformed by the access control policy, and generate a zero-knowledge proof common reference string for the arithmetic circuit description; and combine the type III bilinear group, the Poseidon hash function, and the zero-knowledge proof common reference string into common parameters.

[0126] In one embodiment, issuer 110 is further configured to select a prime order from public parameters, generate an issuance private key based on the prime order; select a generator from public parameters, generate an issuance public key based on the generator; securely store the issuance private key, and publicly disclose the issuance public key.

[0127] In one embodiment, the mobile terminal 120 is further configured to randomly select a user's private key based on public parameters, and calculate a user's public key based on the public parameters; perform commitment processing on the private attribute set using a zero-knowledge friendly collision-resistant hash function to generate an attribute commitment value, and construct a certificate request message based on the user's public key and the attribute commitment value; generate a zero-knowledge proof to prove that the mobile terminal possesses a user's private key corresponding to the user's public key; combine the certificate request message and the zero-knowledge proof of the user's private key into a certificate request, and send it to the issuer 110.

[0128] In one embodiment, the issuer 110 is further configured to receive a certificate request submitted by the mobile terminal 120, query the registration list to confirm that the user identifier in the certificate request is not used, and verify the validity of the zero-knowledge proof of the user's private key in the certificate request; extract the configuration parameters of the structure-preserving signature mechanism on the equivalence class from the public parameters; perform hash and aggregation operations on the private attribute set using a zero-knowledge friendly collision-resistant hash function to obtain the attribute aggregation hash value, combine the user's public key and the attribute aggregation hash value according to the specification to generate a signature message vector adapted to the structure-preserving signature mechanism; perform structure-preserving signature operations on the signature message vector to generate the core signature; and integrate the attribute aggregation hash value and the core signature to generate an anonymous certificate.

[0129] In one embodiment, the mobile terminal 120 is further configured to select a random transformation factor from public parameters, perform calculations on the user's public key using the random transformation factor, and generate a randomized user public key; based on the structure-preserving signature mechanism on equivalence classes, randomize the anonymous certificate using the random transformation factor to generate a randomized anonymous certificate; calculate the randomized user private key based on the user's private key and the random transformation factor, and generate a first zero-knowledge proof to prove ownership of the randomized user private key; generate a second zero-knowledge proof based on the private attribute set to prove that the attributes are consistent with the commitments in the randomized anonymous certificate; integrate the randomized user public key, the randomized anonymous certificate, the issuing public key, the first zero-knowledge proof, and the second zero-knowledge proof to generate partial proof information and send it to the cloud server 130.

[0130] In one embodiment, the cloud server 130 is further configured to receive partial proof information sent by the mobile terminal and verify the partial proof information; construct a public statement and a witness based on the verified partial proof information and access control policy, and run a zero-knowledge proof generation algorithm to generate a zero-knowledge proof; return the zero-knowledge proof and the public statement as proof results to the mobile terminal 120; the mobile terminal 120 confirms that the public statement is consistent with the partial proof information, passes the zero-knowledge proof through the verification algorithm, and generates a display token after the verification is passed.

[0131] In one embodiment, the verifier 140 is further configured to receive a display token, verify the validity of the one-time challenge information in the token, verify the validity of the anonymous certificate through a bilinear pairing operation, obtain a zero-knowledge proof public reference string corresponding to the access control policy, run a zero-knowledge proof verification algorithm, and verify whether the user's hidden attributes satisfy the access control policy.

[0132] In one embodiment, such as Figure 1 As shown, Issuer 110 is a trusted global participant responsible for establishing the system (step ①), generating the private / public key pair for issuance (step ②), and providing certificate issuance services to any legitimate user (step ④). Mobile terminal 120, where users with private attribute sets deploy and use their own certificates on mobile devices such as smartphones, must first request an attribute-based certificate from the issuer (steps ③ and ⑤). Afterward, the user can anonymously present the certificate to the verifier to prove that their attributes satisfy complex access control policies (step ⑥). Cloud server 130's role is to assist mobile users in completing the certificate presentation protocol (step ⑥). Mobile users outsource time-consuming zero-knowledge proofs regarding advanced access policies to multiple cloud servers in a privacy-preserving manner (i.e., hiding user attributes). Verifier 140 provides certificate verification services to each user (step ⑦). Although the verifier can verify the presented token and check whether the user's hidden attributes satisfy the specified access policy, it cannot identify the user's true identity or access any other information about the hidden attributes.

[0133] In one embodiment, a computer device is provided that can be used to represent a certificate issuer, a mobile terminal, a cloud server, and a verifier, and its internal structure diagram can be as follows: Figure 3 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When executed by the processor, the computer program implements a mobile-cloud collaborative anonymous authentication method supporting a universal access policy. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0134] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0135] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement steps of a mobile-cloud collaborative anonymous authentication method supporting a universal access policy.

[0136] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program being executed by a processor to implement the steps of a mobile-cloud collaborative anonymity authentication method supporting a universal access policy.

[0137] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0138] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0139] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A mobile-cloud collaborative anonymous authentication method supporting a universal access policy, characterized in that, The method includes: The issuer selects a zero-knowledge-friendly collision-resistant hash function to generate a common reference string for the arithmetic circuit description, and generates common parameters based on the input security parameters; the issuer then generates a private key and a public key based on the common parameters. The user identifier, private attribute set, and public parameters are input into the mobile terminal, which generates the user's private key and public key, and submits a certificate request to the issuer based on the private attribute set. The issuer verifies the legitimacy of the certificate request and uses a structure-based signature mechanism on equivalence classes to sign the user attributes and generate an anonymous certificate. The mobile terminal randomizes the user's public key and anonymous certificate, generates partial proof information, and sends it to the cloud server. Based on the partial proof information and a predefined access control policy, the cloud server generates a zero-knowledge proof as the proof result and returns it to the mobile terminal. The mobile terminal generates a display token based on the proof result. The verifier receives the display token and verifies the validity of the zero-knowledge proof, confirming that the anonymous certificate is valid and that the user hiding attributes satisfy the access control policy.

2. The mobile-cloud collaborative anonymous authentication method supporting universal access policies according to claim 1, characterized in that, The publisher selects a zero-knowledge-friendly collision-resistant hash function to generate a common reference string for the arithmetic circuit description, and generates common parameters based on the input security parameters, including: The issuer generates a type III bilinear group based on the input security parameters. The type III bilinear group includes a bilinear mapping, prime order, and generator. The issuer selects the Poseidon hash function as the zero-knowledge friendly collision-resistant hash function and configures the input length, output length, and number of permutation rounds of the Poseidon hash function. The issuer obtains the arithmetic circuit description transformed by the access control policy and generates a zero-knowledge proof public reference string for the arithmetic circuit description; The common parameter is a combination of the type III bilinear group, the Poseidon hash function, and the zero-knowledge proof common reference string.

3. The mobile-cloud collaborative anonymous authentication method supporting a universal access policy according to claim 2, characterized in that, The issuer generates a private key and a public key based on the public parameters, including: The issuer selects a prime number order from the public parameters and generates an issuance private key based on the prime number order. The issuer selects a generator from the public parameters and generates an issuance public key based on the generator. The issuer securely stores the private key and publicly discloses the public key.

4. The mobile-cloud collaborative anonymous authentication method supporting a universal access policy according to claim 1, characterized in that, The user identifier, private attribute set, and public parameters are input into the mobile terminal. The mobile terminal generates a user private key and a user public key, and submits a certificate request to the issuer based on the private attribute set, including: The mobile terminal randomly selects a user's private key based on the public parameters, and calculates the user's public key according to the public parameters; The zero-knowledge friendly collision-resistant hash function is used to perform commitment processing on the private attribute set to generate attribute commitment values, and a certificate request message is constructed based on the user's public key and the attribute commitment values. Generate a zero-knowledge proof to prove that the mobile terminal possesses the user's private key corresponding to the user's public key; The mobile terminal combines the certificate request message and the zero-knowledge proof of the user's private key into a certificate request and sends it to the issuer.

5. The mobile-cloud collaborative anonymous authentication method supporting a universal access policy according to claim 1, characterized in that, The issuer verifies the legitimacy of the certificate request and uses a structure-based signature mechanism on equivalence classes to sign the user attributes, generating an anonymous certificate, including: The issuer receives the certificate request submitted by the mobile terminal, queries the registration list to confirm that the user identifier in the certificate request has not been used, and verifies the validity of the zero-knowledge proof of the user's private key in the certificate request. The issuer extracts the configuration parameters of the structure-preserving signature mechanism on the equivalence class from the public parameters; The issuer performs hash and aggregation operations on the private attribute set using the zero-knowledge friendly collision-resistant hash function to obtain the attribute aggregation hash value, and combines the user public key and the attribute aggregation hash value according to the specification to generate a signature message vector that is compatible with the structure to maintain the signature mechanism. The issuer performs a structure-based signature operation on the signed message vector to generate a core signature; The issuer integrates the attribute aggregation hash value and core signature to generate an anonymous certificate.

6. The mobile-cloud collaborative anonymous authentication method supporting a universal access policy according to claim 1, characterized in that, The mobile terminal randomizes the user's public key and anonymous certificate, generates partial proof information, and sends it to the cloud server, including: The mobile terminal selects a random conversion factor from the public parameters, and performs calculations on the user public key using the random conversion factor to generate a randomized user public key; The mobile terminal uses the random transformation factor to randomize the anonymous certificate based on the structure-preserving signature mechanism on equivalence classes, and generates a randomized anonymous certificate. The mobile terminal calculates a randomized user private key based on the user private key and a random conversion factor, and generates a first zero-knowledge proof to prove ownership of the randomized user private key; it also generates a second zero-knowledge proof based on the private attribute set to prove that the attributes are consistent with the commitments in the randomized anonymous certificate. The mobile terminal integrates the randomized user public key, randomized anonymous certificate, issuing public key, first zero-knowledge proof, and second zero-knowledge proof to generate partial proof information and send it to the cloud server.

7. The mobile-cloud collaborative anonymous authentication method supporting a universal access policy according to claim 1, characterized in that, Based on the partial proof information and a predefined access control policy, the cloud server generates a zero-knowledge proof as the proof result and returns it to the mobile terminal. The mobile terminal generates a display token based on the proof result, including: The cloud server receives partial proof information sent by the mobile terminal and verifies the partial proof information; The cloud server constructs public statements and witnesses based on the verified partial proof information and access control policies, and runs a zero-knowledge proof generation algorithm to generate zero-knowledge proofs. The cloud server returns the zero-knowledge proof and the public statement as proof results to the mobile terminal; The mobile terminal confirms that the public statement is consistent with the partial proof information, passes the zero-knowledge proof through the verification algorithm, and generates a display token after successful verification.

8. The mobile-cloud collaborative anonymous authentication method supporting a universal access policy according to claim 1, characterized in that, The verifier receives the display token and verifies the validity of the zero-knowledge proof, confirming that the anonymous certificate is valid and the user-hidden attributes satisfy the access control policy, including: The verifier receives the display token and verifies the validity of the one-time challenge information in the token; The verifier verifies the validity of the anonymous certificate using a bilinear pairing operation; The verifier obtains a public reference string of zero-knowledge proofs corresponding to the access control policy, runs a zero-knowledge proof verification algorithm, and verifies whether the user's hidden attributes satisfy the access control policy.

9. A mobile-cloud collaborative anonymous authentication system supporting a universal access policy, characterized in that, The system includes: The issuer is used to select a zero-knowledge-friendly collision-resistant hash function, generate a public reference string for the arithmetic circuit description, and generate public parameters based on the input security parameters; the issuer generates a private key and a public key based on the public parameters. A mobile terminal is used to receive a user identifier, a private attribute set, and the public parameters, generate a user private key and a user public key, and submit a certificate request to the issuer based on the private attribute set. The issuer is also used to verify the legitimacy of the certificate request and to sign the user attributes using a structure-based signature mechanism on equivalence classes to generate an anonymous certificate. The mobile terminal is also used to randomize the user's public key and anonymous certificate, generate partial proof information, and send it to the cloud server. The cloud server is used to generate a zero-knowledge proof based on the partial proof information and a predefined access control policy, and return the proof result to the mobile terminal. The mobile terminal generates a display token based on the proof result. The verifier receives the display token and verifies the validity of the zero-knowledge proof, confirming that the anonymous certificate is valid and that the user-hidden attributes satisfy the access control policy.

Images