Anonymous credential registration methods, anonymous authentication methods, and electronic devices

Abstract

This invention discloses a method for registering anonymous credentials, an anonymous authentication method, and an electronic device, relating to the fields of computer and network security technology. The method includes: sending a request for public key information of users within a domain to the cloud, and receiving a list of public key information returned by the cloud; constructing a message to be signed, generating a ring signature by combining the message, a preset set of anonymous key pairs, and the list of public key information, and generating proof of the current user's ownership using a preset temporary anonymous key pair private key; generating an anonymous public key registration request based on the ring signature, the message to be signed, and the proof of ownership, and sending it to the cloud; the cloud completing the registration based on the request and generating an anonymous subject identifier for the temporary anonymous public key, and storing the mapping relationship between the identifier and the temporary anonymous public key in a public key repository. By introducing a ring signature as a group qualification certificate and completing the registration of the anonymous public key in the cloud, the problem of indistinguishability and difficulty in fine-grained management and auditing caused by all users sharing the same anonymous identity is solved.

Description

Technical Field

[0001] This invention relates to the fields of computer and network security technology, and in particular to methods for registering anonymous credentials, methods for anonymous authentication, and electronic devices. Background Technology

[0002] In today's distributed computing environment, a core prerequisite for ensuring secure service access is reliable user authentication. The Kerberos protocol, a widely used network authentication protocol, provides a means of mutual authentication for communicating parties in open networks through a ticket-based mechanism and symmetric cryptography.

[0003] In related technologies, the Kerberos community proposed an anonymous authentication mechanism that allows clients to use a unified, special anonymous entity to grant a limited-function ticket to a key distribution center. However, because all anonymous users share the same identity, this method results in anonymity but indistinguishability, making fine-grained authorization and auditing impossible, and its practicality is severely lacking, requiring urgent solutions. Summary of the Invention

[0004] This invention provides a method for registering anonymous credentials, an anonymous authentication method, and an electronic device to at least solve the problems of indistinguishability and difficulty in fine-grained management and auditing caused by all users sharing the same anonymous identity. This enables the authentication system to perform independent identity management, policy control, and access auditing for different anonymous users without exposing the user's real identity.

[0005] This invention provides a method for registering anonymous credentials, the method being applied to a client, wherein the method includes the following steps:

[0006] Send a request for the public key information of users within the domain to a preset cloud, and receive the response information sent by the preset cloud based on the request for the public key information of users within the domain;

[0007] Construct a message to be signed, select a target anonymous key pair corresponding to the current user from a preset set of anonymous key pairs, generate a ring signature based on the message to be signed, the target anonymous private key in the target anonymous key pair, and the public key information list in the response information, and generate the current user's holding proof through the temporary anonymous private key in the preset temporary anonymous key pair;

[0008] An anonymous public key registration request is generated based on the ring signature, the message to be signed, and the proof of possession. The anonymous public key registration request is then sent to the preset cloud. If the preset cloud completes the registration based on the anonymous public key registration request, an anonymous subject identifier for the temporary anonymous public key is generated. The mapping relationship between the anonymous subject identifier and the temporary anonymous public key is then stored in a preset public key library.

[0009] This invention provides an anonymous authentication method, which is applied to a server, and includes the following steps:

[0010] Receive an anonymous authentication request, the anonymous authentication request including signature information, the signature information being generated from a temporary anonymous private key;

[0011] If the signature information meets the second preset validity condition, a session key and a ticket granting ticket are generated based on preset key exchange information.

[0012] The session key is encrypted using a temporary anonymous public key, and the encrypted session key and the ticket granting ticket are encapsulated in an authentication response, which is then sent to the client.

[0013] The present invention provides an electronic device including a memory and a processor. The memory stores a computer program, and the processor is configured to run the computer program to execute the anonymous credential registration method or the anonymous authentication method described in the above embodiments.

[0014] This invention addresses the challenges of using a ring signature to register a public key for a user within a domain. By sending a request for public key information to the cloud and receiving a list of returned public key information, a message to be signed is constructed. This message, along with a pre-defined set of anonymous key pairs and the list of public key information, generates a ring signature. A proof of the current user's ownership is then generated using the private key from a pre-defined temporary anonymous key pair. Based on the ring signature, the message to be signed, and the proof of ownership, an anonymous public key registration request is generated and sent to the cloud. The cloud then completes the registration based on this request, generates an anonymous subject identifier for the target anonymous public key, and stores the mapping between the identifier and the target anonymous public key in a pre-defined public key repository. By introducing a ring signature as a group qualification certificate and completing the registration of anonymous public keys in the cloud, this invention solves the problems of indistinguishability and difficulty in fine-grained management and auditing caused by all users sharing the same anonymous identity. This allows the authentication system to perform independent identity management, policy control, and access auditing for different anonymous users without exposing their true identities. Attached Figure Description

[0015] To more clearly illustrate the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating a method for registering anonymous credentials as provided in an embodiment of the present invention;

[0017] Figure 2 This is a schematic diagram of the overall architecture of Kerberos in related technologies;

[0018] Figure 3 This is a schematic diagram illustrating the PKINIT (Public Key Cryptography for Initial Authentication in Kerberos) protocol in related technologies.

[0019] Figure 4 A schematic diagram illustrating the registration method for anonymous credentials provided in an embodiment of the present invention;

[0020] Figure 5 A timing diagram illustrating the list of user public key information within a request domain provided in an embodiment of the present invention;

[0021] Figure 6 A timing diagram illustrating the anonymous registration process provided in an embodiment of the present invention;

[0022] Figure 7 A schematic diagram of the anonymous authentication process based on PKINIT provided in an embodiment of the present invention;

[0023] Figure 8 A flowchart of an anonymous authentication method provided in an embodiment of the present invention;

[0024] Figure 9 A block diagram illustrating an anonymous credential registration device provided in an embodiment of the present invention;

[0025] Figure 10 A block diagram illustrating an anonymous authentication device provided in an embodiment of the present invention;

[0026] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0028] It should be noted that, in the description of this invention, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., used in this invention are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0029] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0030] The present invention provides a method for registering anonymous credentials, and the execution flow of the method is described in detail below.

[0031] Figure 1 This is a flowchart of an anonymous credential registration method according to an embodiment of the present invention.

[0032] Before introducing the anonymous credential registration method proposed in the embodiments of the present invention, let's briefly introduce the relevant technical background.

[0033] As is understandable, the Kerberos protocol is a network authentication protocol that relies on tickets. The standard Kerberos protocol (RFC 4120, Kerberos version 5 standard specification) is based on a symmetric encryption system. That is, the client shares a long-term key with the KDC (Key Distribution Center), and the KDC also shares keys with each service. The client obtains and uses tickets through three stages of interaction: AS (Authentication Server Exchange), TGS (Ticket Granting Service Exchange), and AP (Client / Server Authentication Exchange), thereby gaining access to services within the system. The architecture and interaction flow of the entire Kerberos system are as follows: Figure 2 As shown.

[0034] Subsequently, the industry introduced the Kerberos PKINIT extension protocol (RFC4556), which clarifies a way to enhance the security of the Kerberos protocol's initial authentication phase (AS) using public-key cryptography. Its core purpose is to replace or supplement traditional initial authentication based on symmetric keys (e.g., user passwords or KDC keys) with a more secure public key infrastructure (PKI).

[0035] Within the Kerberos community, an "anonymous" pre-authentication mechanism has also been proposed. This mechanism allows clients to omit their own identity in the initial AS-REQ (Authentication Service Request), or to use a special "anonymous" subject (e.g., WELLKNOWN / ANONYMOUS@REALM, a well-known / anonymous user @domain, a special subject name format used to represent an anonymous user in a domain). KDC can then issue a restricted TGT (Ticket Granting Ticket) for such requests.

[0036] Specifically, during the initial authentication phase (AS) of the Kerberos protocol, the interaction between the KDC and the client enables user identification and verification:

[0037] (1) The client initiates an AS-REQ request, which includes the declared username information and does not send password-related information;

[0038] (2) After receiving the request, the KDC looks up the long-term key corresponding to the user based on the username, and uses this key to encrypt the subsequent session key. Finally, it returns a response to the client, which includes the encrypted session key and the encrypted TGT;

[0039] (3) After receiving the Authentication Service Response (AS-REP), the client needs to use its own long-term key to decrypt the session key in the response before it can carry out the subsequent interaction process. This means that user authentication has been completed.

[0040] Regarding the PKINIT protocol, it integrates public-key cryptography into the Kerberos AS authentication phase, such as... Figure 3 As shown.

[0041] Client preparation phase: The client holds a certificate issued by a trusted Certificate Authority (CA) (containing a public key) and its corresponding private key. Additionally, the client needs to construct an AuthPack (authentication data packet) for subsequent authentication.

[0042] Key Exchange Phase: Diffie-Hellman (DH) key exchange is a widely used cryptographic protocol whose core purpose is to generate and share secure keys over insecure channels. In this mechanism, the client and the KDC each generate a DH public-private key pair. The client sends its DH public key along with a signed authentication data packet (AuthPack) to the KDC. The KDC uses its own DH private key and the client's DH public key to calculate a shared key, which will serve as the basis for subsequent Kerberos session keys.

[0043] Authentication Phase: The client digitally signs the AuthPack using its private key. The generated digital signature, the associated digital certificate, and information generated during key exchange (e.g., the DH public key) are then encapsulated in a PA (Policy Authority)-PK (Public Key)-AS-REQ pre-authentication data structure. This data is sent as part of the AS-REQ message to the KDC for subsequent authentication and key negotiation. Upon receiving the client's request, the KDC verifies the integrity and authenticity of the digital signature in the request. Subsequently, the KDC establishes a secure communication channel with the client through an encrypted negotiation mechanism. Throughout this process, the KDC confirms that the client indeed possesses the private key corresponding to the submitted certificate, further proving the client's legitimacy. Ultimately, the KDC successfully authenticates the client.

[0044] KDC Response Phase: First, the KDC generates a session key using the DH key exchange mechanism. This key is used to ensure secure communication between the client and server. Then, the KDC encapsulates the generated session key and other necessary ticket information (e.g., TGT) and includes it in the AS-REP message. To ensure secure communication, the KDC encrypts the session key using the client's public key (i.e., the client's certificate public key) to prevent unauthorized access during transmission. Finally, the encrypted AS-REP message is sent back to the client for decryption and use.

[0045] Client Completion Phase: After receiving the AS-REP response message from the KDC, the client uses its pre-configured private key to decrypt the encrypted portion of the message, obtaining the session key contained within. At this point, a shared, highly secure session key has been successfully established between the client and the KDC. When initiating a Ticket Granting Service Request (TGS-REQ) and receiving a Ticket Granting Service Response (TGS-REP), the client will rely entirely on this session key for data encryption and authentication. The entire process design and implementation are completely consistent with the interaction procedures and security requirements defined in the Kerberos protocol, ensuring the reliability of authentication exchanges and the confidentiality of communication.

[0046] Therefore, it is evident that Kerberos and its extensions at this stage lack support for anonymous authentication features, and community discussions are limited to specific "anonymous" subjects and restricted access permissions. Regardless of whether a traditional symmetric encryption system or a PKINIT public-key system is used, the KDC internally maintains a "user identifier - key / certificate" mapping. As long as this mapping exists, the KDC can technically or operationally associate any authentication request with a specific real identity. Even though the Kerberos community has proposed an "anonymous" pre-authentication mechanism, its design is relatively simple and lacks support for fine-grained management in different application scenarios. Once the system needs more granular access control, behavior tracking, or personalized services for different anonymous users, the existing anonymous pre-authentication mechanism proves inadequate, unable to effectively distinguish and handle the differences between different anonymous users, thus limiting its practical application in complex environments.

[0047] Based on the above problems, this invention proposes a method for registering anonymous credentials, such as... Figure 4 As shown, on top of the existing PKI infrastructure built on the PKINIT protocol, each user in the Kerberos authentication system holds their own key pair. Integrating ring signature functionality into the Kerberos system allows users to collect public key information from other users within the domain and generate a ring signature for specific authentication information. Subsequently, users can use this ring signature as credentials to authenticate their identity with the KDC and register anonymous public keys. During this process, because the credentials submitted by the user are ring signatures, the KDC cannot pinpoint the request to a specific user during authentication; therefore, the anonymous public key entity registered by the request cannot be mapped to a specific real user. Later, under the PKINIT architecture, when a user holding the private key information corresponding to the anonymous public key submits an initial authentication request to the KDC, the KDC completes the authentication and issues a TGT. However, given the use of anonymous public keys, the KDC cannot associate this request with a specific user within the domain, thus achieving the effect of anonymous authentication and request. It solves the problem of indistinguishability and difficulty in fine-grained management and auditing caused by all users sharing the same anonymous identity, enabling the authentication system to perform independent identity management, policy control and access auditing for different anonymous users without exposing the user's real identity.

[0048] Therefore, under the premise of compatibility with the existing Kerberos / PKINIT system, the present invention can fundamentally achieve "anonymization" of the public key library inside the KDC, that is, allow the KDC to only hold a set of public keys that can be verified but cannot be traced back to the real user, thereby achieving the expected anonymity characteristics.

[0049] Next, the registration method for anonymous credentials proposed in the embodiments of the present invention will be described in detail.

[0050] The registration method for this anonymous credential is applied to the client, for example, as follows: Figure 1 As shown, the method may include the following steps:

[0051] In step S101, a request for the public key information of users within the domain is sent to a preset cloud, and a response message is received from the preset cloud based on the request for the public key information of users within the domain.

[0052] It should be noted that, in this embodiment of the invention, the Kerberos domain can be built with reference to the PKINIT protocol, thus constructing a complete public-key cryptography infrastructure. In this architecture, the KDC not only acts as the centralized manager of the Kerberos domain but also assumes the functions of a CA, comprehensively managing the entire lifecycle of asymmetric keys for all users and service entities within the domain, including generation, distribution, updating, and revocation. Furthermore, each user in the Kerberos domain already possesses their own asymmetric key pair, including a public key and a private key.

[0053] To ensure that users within a Kerberos domain can generate valid ring signatures, Kerberos clients must engage in a series of request and response interactions with the KDC to obtain or update the public key information of the relevant users within the Kerberos domain.

[0054] Specifically, such as Figure 5 As shown, the client can send a request message (i.e., a Kerberos domain user public key information request PKYS_REQ) in plaintext to the preset cloud (i.e., KDC). This message can contain a request to obtain the public key data (i.e., a list of public key information) of users within a specified Kerberos domain. This list of public key information is defined and managed by the KDC and is a pre-existing, fixed set of public keys corresponding to user groups. To ensure the standardization and processability of the request, the request message can be organized according to the following structure:

[0055] PKYS_REQ={“REQUIRE”,…}.

[0056] The content and format of this request can be relatively simple and direct, without needing excessive details or complex structures. It only needs to clearly and explicitly express the core intent of obtaining public key information of users within the domain. Upon receiving the request for public key information of users within the domain, the KDC immediately begins processing. The KDC adds its own public key certificate to the response content, and simultaneously signs the hash value of the list of public key information of users within the domain using its own private key, adding the signature result to the response. Here, the public key information of users within the domain can be in dictionary form, i.e., a mapping between user entity names and public key content. Finally, the complete plaintext of the public key information of users within the domain (i.e., the list of public key information) is added to the response.

[0057] The format of public key information for a single user within the domain is defined as follows:

[0058] PKY_ENTITY={Domain User Principal Name: Public Key Information};

[0059] The format of the public key information list can be as follows:

[0060] PKYS_LIST={PKY_ENTITY_1,PKY_ENTITY_2,…};

[0061] The hash value of the public key information list is calculated as follows:

[0062] PKYS_LIST_HASH=H(PKYS_LIST);

[0063] Where H() represents the hash calculation operation;

[0064] The process of signing the hash value of the public key information list using the KDC's own private key is as follows:

[0065] PKYS_LIST_SIG=Sign_SK_KDC(PKYS_LIST_HASH);

[0066] Sign_SK_KDC() is used to perform a signature operation using the private key of the KDC itself;

[0067] Finally, the content format of the response message PKYS_REP can be as follows:

[0068] PKYS_REP={Certificate_KDC,PKYS_LIST_SIG,PKYS_LIST,…};

[0069] Among them, Certificate_KDC is the public key certificate of KDC.

[0070] Understandably, the format of this response message is designed to ensure that the list of public key information received by the client is accurate and tamper-proof. If only a plaintext list of public key information were responded to, this list would be easily altered, and the recipient would not be able to verify whether the message truly originated from the KDC. By signing the hash value of the public key information list and allowing the recipient to verify the signature, the goal of confirming the authenticity of the response content can be achieved.

[0071] In step S102, a message to be signed is constructed, and a target anonymous key pair corresponding to the current user is selected from a preset set of anonymous key pairs. A ring signature is generated based on the message to be signed, the target anonymous private key in the target anonymous key pair, and the public key information list in the response information. The current user's ownership certificate is generated using the temporary anonymous private key in the preset temporary anonymous key pair.

[0072] Understandably, the preset anonymous key pair set refers to the real anonymous key pairs of each real user (i.e., all legitimate users within the Kerberos domain) corresponding to the public key information list, and the current user's anonymous key pair also exists in this set. Each anonymous key pair in the preset anonymous key pair set consists of an anonymous private key (SK_anon) and an anonymous public key (PK_anon). The set of anonymous public keys constitutes the public key information list, while the anonymous private key portion is distributed among each user. For the currently operating client (i.e., the current user), what they hold is the anonymous private key (target anonymous private key) of the anonymous key pair (target anonymous key pair) in the preset anonymous key pair set that corresponds to their real identity.

[0073] Specifically, after receiving the response information, including a list of public key information, the client can create a message AuthPack (i.e., a message to be signed) with a specific format, containing necessary information, and designed to prevent replay attacks. This message serves as input for ring signing and subsequent processes. The content of this message to be signed can include a string declaring the anonymous registration request (i.e., an explicit operation type identifier) ​​and a timestamp (i.e., a value that changes over time to prevent attackers from intercepting and resending the request). The specific format can be as follows:

[0074] AuthPack={

[0075] "ANON_ENROLLMENT"; / / Indicates that this request is for anonymous registration.

[0076] PK_anon; / / Anonymous public key

[0077] Timestamp / / Timestamp, used to prevent replay ...;

[0079] }

[0080] Subsequently, a ring signature can be generated based on the AuthPack message to be signed, the target anonymous private key in the target anonymous key pair, and the list of public key information in the response information. When verifying the ring signature, the KDC can only confirm that it was generated by a member of the ring (user group within the domain), but cannot determine which member, thus achieving the core requirement of anonymity.

[0081] Furthermore, to prevent attackers from impersonating others' public keys for registration and to ensure that the anonymous identity to be registered is indeed controlled by the requester (the current user), a Proof of Possession (POP) can be generated for the current user. First, the client can call a local cryptography library to randomly generate an anonymous key pair (i.e., a preset temporary anonymous key pair) for the current user to register, following standard algorithms (such as RSA (Rivest Shamir Adleman, an asymmetric encryption algorithm) or ECC (Elliptic Curve Cryptography)): anonymous_entity={SK_anon',PK_anon'}. The encryption system specifications used must be completely consistent with the user's local configuration and the security settings within the Kerberos domain to ensure that the key generation process complies with the overall encryption strategy and compliance requirements of the system. The core meaning of PoP is that, as a cryptographic mechanism, it can effectively prove that the requester (the current user) truly possesses and controls the private key corresponding to the anonymous public key they invented and registered. To achieve this goal, the overall structure can typically be represented by using a temporary anonymous private key to digitally sign a specific, agreed-upon piece of content (data containing a temporary anonymous public key), thereby obtaining proof of the current user's ownership, as shown below:

[0082] PoP=Sig_{SK_anon'}(H("POP"||PK_anon'));

[0083] The content to be signed consists of a specific string and the hash value of a temporary anonymous public key.

[0084] Next, we will briefly introduce the ring signature calculation method in related technologies. The RST ring signature algorithm is a ring signature method based on the RSA public-key cryptosystem, and its calculation process is as follows:

[0085] (1) System settings: For each member i in the domain, there is a pair of RSA keys, namely the public key (N i ,e i ), private key d i .

[0086] Define a trapdoor function:

[0087]

[0088]

[0089] Define a combinatorial function (ring equation):

[0090]

[0091] in, For hash-based symmetric encryption operations, , This is a random glue value.

[0092] (2) Signing process (signer index is s): The input is the message to be signed m and the list of ring public keys. and the signer's private key d s The output is a signature. .

[0093] Step 1, Calculate the signature key:

[0094]

[0095] Step 2: Select a random integer v as the glue value;

[0096] Step 3: Generate input for other members within the domain, that is, for all members i≠s, randomly select parameter value x. i And calculate y i =g i (x i );

[0097] Step 4: Combine all previously generated y... i Substituting the parameters into the ring equation, the ring equation is now missing only one variable, y. s Therefore, y can be calculated. s ,Right now,

[0098]

[0099] Step 5: Calculate the final signature using the signer's private key to ensure the signature's uniqueness and unforgeability.

[0100]

[0101] Step 6: Output the signature, that is, .

[0102] (3) Verification process: The input is the message m to be signed and the corresponding signature σ. The output is accept or reject, indicating whether the signature is valid.

[0103] Step 1: For all users i, calculate y i =g i (x i );

[0104] Step 2: Hash value of message m to be signed:

[0105]

[0106] Step 3: Verify whether the ring equation holds, that is,

[0107]

[0108] If the ring equation verification passes, the signature is deemed valid and "Accept" is output; otherwise, the signature is deemed invalid and "Reject" is output.

[0109] Based on this, the following details how to generate a ring signature from the message to be signed, the target anonymous private key in the target anonymous key pair, and the list of public key information in the response information.

[0110] As one possible implementation, in some embodiments, generating a ring signature based on the message to be signed, the target anonymous private key in the target anonymous key pair, and the public key information list in the response information includes: determining at least one remaining anonymous public key in a preset set of anonymous key pairs other than the target anonymous public key, generating a random value for at least one remaining anonymous public key, and calculating a trapdoor function value for the target anonymous public key based on the random value of the at least one remaining anonymous public key; performing an inverse trapdoor function operation on the trapdoor function value of the target anonymous public key based on the target anonymous private key to obtain a random value for the target anonymous public key; and obtaining a ring signature based on the public key information list, a preset ring reference value, the random value of the target anonymous public key, and the random value of at least one remaining anonymous public key.

[0111] Specifically, from a pre-defined set of anonymous key pairs (which contains a list of public keys that can form a ring, including the public keys of all legitimate users within the domain (including the current user's own public key)), at least one remaining anonymous public key is determined, excluding the target anonymous public key (the current user's own public key). For each remaining anonymous public key, the current user can randomly generate a value for it. Its randomness ensures that each generated signature is unique. For each random value of the remaining anonymous public key, the trapdoor function value of the target anonymous public key can be calculated using the corresponding remaining anonymous public key. Subsequently, based on the target anonymous private key, the inverse trapdoor function operation is performed on the trapdoor function value of the target anonymous public key to obtain the random value of the target anonymous public key. ,Right now,

[0112]

[0113] At this point, based on the public key information list Preset ring reference value Random value of the target anonymous public key and at least one random value of the remaining anonymous public key Obtain the ring signature, that is,

[0114]

[0115] Thus, by using the asymmetric processing method of "randomly generating for others and calculating the solution for oneself", it is ensured that a real private key (i.e. the target anonymous private key) must be involved in the ring signature, thereby anchoring the legitimacy of the anonymous registration request to the existing trusted user group and realizing verifiable group anonymity.

[0116] As one possible implementation, in some embodiments, the trapdoor function value of the target anonymous public key is calculated based on the random value of at least one remaining anonymous public key, including: calculating the trapdoor function value of at least one remaining anonymous public key based on the random value of at least one remaining anonymous public key; performing a hash calculation on the message to be signed to obtain a ring equation encryption key, and obtaining the trapdoor function value of the target anonymous public key based on the ring equation encryption key, a preset ring base value, and the trapdoor function value of at least one remaining anonymous public key.

[0117] Specifically, firstly, the trapdoor function value of at least one remaining anonymous public key can be calculated based on the random value of at least one remaining anonymous public key, that is,

[0118]

[0119] in, For each remaining anonymous public key, the trapdoor function value is... A random value for each remaining anonymous public key.

[0120] Here, because this scheme employs the aforementioned ring signature algorithm based on the RST ring structure, its trapdoor function design shares the same logical basis as the public-key encryption function. This design feature requires that the public key information of all participants in the ring be obtained to complete the corresponding calculation process. That is, each public key in the public key information list must participate in the computation; otherwise, the ring signature cannot be effectively generated and verified.

[0121] Furthermore, by performing a hash calculation on the information to be signed, the ring equation encryption key can be obtained, that is,

[0122]

[0123] Where m represents the AuthPack information to be signed.

[0124] Finally, the trapdoor function value y of each remaining anonymous public key is... i By substituting the preset ring baseline value v and the ring equation encryption key k into the ring equation, the trapdoor function value y of the target anonymous public key can be calculated. s The preset baseline value is the glue value of the ring equation, which is an integer v randomly selected by the current user.

[0125] Therefore, by performing ring equation operations of "forward calculation and reverse solution", the random parameters of other members in the ring are chained and encrypted with the preset ring base value, and the trapdoor function value necessary for the signer's own position is accurately calculated. This ensures the mathematical closure and self-consistency of the ring signature structure, allowing the verifier to confirm the signer's group member identity by verifying whether the ring equation is closed. This achieves the unity of anonymity and verifiability at the algorithm level.

[0126] In step S103, an anonymous public key registration request is generated based on the ring signature, the message to be signed, and the proof of possession. The anonymous public key registration request is then sent to a preset cloud. If the registration is completed on the preset cloud based on the anonymous public key registration request, an anonymous subject identifier for a temporary anonymous public key is generated. The mapping relationship between the anonymous subject identifier and the temporary anonymous public key is then stored in a preset public key library.

[0127] Specifically, after obtaining the ring signature, the client can combine the ring signature (used to prove to the preset cloud that "the initiator of this request is a legitimate and authenticated user within the domain it manages, but will not reveal who it is."), the message to be signed, and the proof of possession (used to prove to the preset cloud that "the user who submitted this request does indeed possess the temporary anonymous private key corresponding to this 'temporary anonymous public key'.") into a structured request package, namely the anonymous public key registration request: ANON_ENROLL_REQ={AuthPack,σ,PoP,…}, and send the anonymous public key registration request to the preset cloud via a secure network channel.

[0128] Upon receiving the anonymous public key registration request, the cloud platform can perform a series of verification operations. These include extracting the message to be signed and the ring signature, checking whether each public key in the ring signature's public key information list truly belongs to a legitimate user within the current domain, and if all public keys pass this verification step. Based on these public keys and the content of the message to be signed, the cloud platform can then perform a signature verification process. Once the signature verification is successful, the cloud platform can confirm that the anonymous public key registration request was indeed initiated by a legitimate user within the domain.

[0129] For each anonymous public key entity in the ring public key list in the ring signature, perform a trapdoor function operation, that is,

[0130]

[0131] Perform a hash calculation on the message to be signed, that is,

[0132]

[0133] Use the results obtained in the above steps and Calculate the ring equations, i.e.,

[0134]

[0135] Finally, the calculated result was verified. With the received ring signature Check if they are equal. If they are equal, the verification passes.

[0136] Once verification is successful, the anonymous identity is created (registration is completed based on the anonymous public key registration request), and a temporary anonymous public key is generated as an anonymous subject identifier, enabling anonymity to be distinguishable. The system can subsequently manage, authorize, and audit different anonymous users based on this anonymous subject identifier, avoiding the indistinguishability issues that arise when all anonymous users share the same identifier. Finally, the cloud can store the mapping relationship between the anonymous subject identifier and the temporary anonymous public key in a pre-defined public key repository, thereby severing the direct link from the anonymous identity back to the real user. The format of the mapping relationship between the anonymous subject identifier and the temporary anonymous public key can be as follows:

[0137] AnonKeyDB_Entity = {

[0138] PK_anon; / / Anonymous public key

[0139] kid; / / The name of the entity corresponding to this anonymous public key

[0140] meta; / / Other related metadata ...

[0141] }

[0142] It should be noted that after verifying the ring signature, the cloud platform can preliminarily confirm the legitimacy of the requester's (current user's) identity. However, it cannot yet completely determine whether the requester actually possesses the temporary anonymous private key corresponding to the temporary anonymous public key they claimed. Therefore, to further verify the requester's true identity and permissions, the temporary anonymous public key provided in the anonymous public key registration request can be used to verify the proof of possession. This step will generate a hash value for {"POP"||PK_anon}. Simultaneously, the cloud platform also needs to manually calculate the hash value of the same string {"POP"||PK_anon}. By comparing whether these two hash values ​​match, it can be finally confirmed whether the requester actually possesses the corresponding private key, thus completing the entire identity verification process. If the two hash values ​​match, the proof of possession is valid; otherwise, it is invalid.

[0143] Therefore, by introducing a dual hash verification mechanism for proof of ownership, a mandatory verification of the ownership of anonymous public keys is added on the basis of ring signature verification of group eligibility. This constitutes a continuous authentication chain from "group member identity" to "individual key ownership", ensuring the accuracy and security of the anonymous credential issuance process and laying a solid foundation of trust for the entire anonymous authentication system.

[0144] Ultimately, as Figure 6 As shown, regardless of whether the anonymous public key registration request is accepted or not, the cloud can send response information to the client by default, including ANON_ENROLL_REP={kid,meta,ok=true / false}.

[0145] Furthermore, in some embodiments, before generating a ring signature based on the message to be signed, the target anonymous private key in the target anonymous key pair, and the public key information list in the response information, the method further includes: obtaining a public key certificate in the response information; if the public key certificate meets a first preset validity condition, obtaining a preset trusted public key in the cloud; and based on the trusted public key, identifying whether the public key information list is in a preset valid state, so that if the public key information list is in a preset valid state, a ring signature is generated based on the message to be signed, the preset set of anonymous key pairs, and the public key information list.

[0146] Specifically, after receiving the response information containing a list of public key information for users within the domain, the client can first verify the public key certificate provided by the KDC (i.e., the public key certificate of the KDC itself contained in the response information). This certificate is issued by an authoritative CA. Therefore, the client can be pre-configured to trust this CA, that is, to install and trust the root certificate or intermediate certificate of this CA to ensure that the authenticity and legitimacy of the KDC public key can be correctly verified. After the authenticity of the KDC public key is confirmed (i.e., the public key certificate meets the first preset validity condition and a preset trusted public key is obtained in the cloud), the client can use this trusted public key to identify whether the list of public key information in the response information is in a preset valid state (i.e., to verify whether the list of public key information in the response information is accurate and reliable). If the list of public key information is in a preset valid state, a ring signature can be generated based on the message to be signed, the preset set of anonymous key pairs, and the list of public key information.

[0147] Therefore, by introducing a dual security access mechanism based on public key certificate verification and data integrity check before generating the ring signature, it is ensured that the list of public key information used to construct the ring signature is trustworthy and tamper-proof. This prevents forged or contaminated group public key lists from being used for ring signatures at the source of the trust chain, prevents anonymous identity registration based on fake groups, thereby improving the security and robustness of the entire anonymous authentication system and ensuring strict control over anonymity qualifications.

[0148] As one possible implementation, in some embodiments, identifying whether the public key information list is in a preset valid state based on a trusted public key includes: using the trusted public key to verify the digital signature in the response information to obtain a first hash value, and using a preset hash algorithm to calculate the plaintext of the public key information list in the response information to obtain a second hash value; if the first hash value and the second hash value are the same, it is determined that the public key information list is in a preset valid state.

[0149] Specifically, the client can use a trusted public key to decrypt the encrypted hash field in the response message (i.e., verify the digital signature in the response message), obtaining a first hash value. The encrypted hash field in the response message is the signature result PKYS_LIST_SIG obtained by signing using the hash values ​​of the KDC's own private key public key information list. Simultaneously, the client can use a preset hash algorithm to calculate the hash value of the plaintext public key information (i.e., a second hash value). By comparing the first and second hash values ​​to ensure they are completely identical, the client can further confirm the integrity and correctness of the received public key information list. If the first and second hash values ​​are equal, it indicates that the public key information list has not been tampered with during transmission, and its reliability can be fully trusted; that is, the public key information list can be determined to be in a preset valid state.

[0150] Therefore, by comparing the first hash value obtained by decrypting the digital signature of the authentication server with the second hash value obtained by the client calculating the plaintext, an efficient and reliable data integrity self-verification mechanism is created. This ensures that the list of group public keys obtained by the client is not tampered with during transmission and is indeed from a trusted authentication server. It guarantees the security of subsequent ring signature generation and anonymous registration processes from the data source and effectively resists the risks of man-in-the-middle attacks and data tampering.

[0151] Furthermore, in some embodiments, after storing the mapping relationship between the anonymous subject identifier and the target anonymous public key in a preset public key library, the method further includes: constructing an anonymous authentication request and sending the anonymous authentication request to a preset cloud; receiving a ticket granting ticket corresponding to the anonymous subject identifier sent by the preset cloud based on the anonymous authentication request.

[0152] Specifically, once a user successfully completes the registration process for their anonymous public key, they can perform anonymous authentication within this improved Kerberos system, thereby gaining access to various protected service resources. Similar to the PKINIT protocol, the user first needs to send a structured anonymous authentication request to the pre-defined cloud. During the construction of this request, the client, to prove its legitimate anonymous identity, must digitally sign a specific message (AuthPack) using its anonymous private key. The AuthPack typically includes: a system-generated anonymous subject identifier, an optional random value (to enhance the randomness and uniqueness of the anonymous authentication request), and an optional timestamp (to effectively defend against potential replay attacks). The final anonymous authentication request will contain several key components: the public key certificate corresponding to the anonymous subject, the signed AuthPack payload, necessary parameters for key exchange, and the complete digital signature of the anonymous authentication request. Upon receiving the anonymous authentication request, the default cloud platform first verifies whether the anonymous public key provided in the request has been registered and is valid. Then, the default cloud platform uses this public key to verify the signature information in the request, confirming that the requester indeed possesses a private key matching the public key, thereby verifying their identity. If all verification steps are successful, the default cloud platform generates and returns a valid ticket grant ticket, along with key exchange information generated by the default cloud platform itself, to complete the subsequent session key negotiation process.

[0153] Therefore, after successful anonymous identity registration, an independent anonymous authentication process was designed, enabling clients to use this anonymous identity to request and obtain standard service access credentials (ticket authorization tickets) from the cloud. By decoupling the creation and use of anonymous identities, the entire system achieves true anonymity while being fully compatible with and integrated into existing, mature authentication and authorization systems, ensuring a smooth and standardized anonymous access process.

[0154] According to the anonymous credential registration method proposed in this embodiment of the invention, a request for public key information of users within a domain is sent to the cloud, and a list of public key information returned is received. A message to be signed is constructed, and a ring signature is generated by combining the message, a preset set of anonymous key pairs, and the list of public key information. A proof of ownership of the current user is generated using the private key in the preset temporary anonymous key pair. An anonymous public key registration request is generated based on the ring signature, the message to be signed, and the proof of ownership, and sent to the cloud. The cloud completes the registration based on the request and generates an anonymous subject identifier for the target anonymous public key, and stores the mapping relationship between the identifier and the target anonymous public key in a preset public key library. Thus, by introducing a ring signature as a group qualification proof and completing the registration of anonymous public keys in the cloud, the problem of indistinguishability and difficulty in fine-grained management and auditing caused by all users sharing the same anonymous identity is solved. This enables the authentication system to perform independent identity management, policy control, and access auditing for different anonymous users without exposing the user's real identity.

[0155] Through the above description of the embodiments, those skilled in the art can clearly understand that the system according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0156] Embodiments of the present invention also provide an anonymous authentication method applied to a server.

[0157] For example, such as Figure 7 As shown, this anonymous authentication method may include the following steps:

[0158] In step 701, an anonymous authentication request is received. The anonymous authentication request includes signature information, which is generated by a temporary anonymous private key.

[0159] Specifically, upon receiving an anonymous authentication request, the cloud-based system can retrieve the corresponding temporary anonymous public key based on the anonymous subject's identifier. It then cryptographically confirms, through signature verification, that the client indeed possesses the private key bound to the anonymous identity, thus authenticating its legitimacy. The core of this mechanism lies in its perfect reuse of the standard PKINIT authentication process framework. It simply replaces the core credential from a long-term certificate representing the real identity with a completely anonymous temporary key pair. This allows the cloud-based system to verify whether the requester is the legitimate controller of the anonymous identity. However, because the association with the real user has been severed through ring signature during the registration phase, it is ultimately impossible to trace back to any specific domain user. Thus, within a fully functional authentication system, truly distinguishable and manageable anonymous access is achieved.

[0160] In step 702, if the signature information meets the second preset validity condition, a session key and a ticket granting ticket are generated based on the preset key exchange information.

[0161] Specifically, after the cloud verifies the signature information in the anonymous authentication request and confirms that it meets the second preset validity condition (i.e., the signature is valid, proving that the client does indeed hold the private key corresponding to its declared anonymous identity), the entire process enters the substantive stage of establishing a secure session and issuing credentials. At this point, the cloud will generate a session key based on preset key exchange information (usually dynamically generated by the cloud during the request-response process when processing the client's authentication request).

[0162] Next, the pre-defined cloud can create a ticket granting certificate. This certificate not only encapsulates the newly generated session key, the client's anonymous subject identifier, timestamp, validity period, and other metadata, but is also ultimately encrypted using TGS's long-term key to ensure its integrity and authenticity. Thus, the pre-defined cloud successfully constructs a secure credential centered on the anonymous identity and bound to the session key, laying a trusted foundation for the client's subsequent access to network services in an anonymous state. The entire process ensures authentication strength while strictly maintaining the untraceability of the user's identity.

[0163] As one possible implementation, in some embodiments, generating a session key and a ticket granting ticket based on preset key exchange information includes: generating a temporary key pair according to the preset key exchange information, wherein the temporary key pair includes a server temporary public key and a server temporary private key; calculating a shared secret based on the temporary anonymous public key and the server temporary private key in the anonymous authentication request; and generating a session key based on the shared secret.

[0164] Specifically, the pre-defined cloud platform can randomly generate a temporary private key (a secret random number) for the server using pre-defined key exchange information. Then, through elliptic curve scalar multiplication, it can derive the corresponding temporary public key (a point on the curve) from this private key. Next, the pre-defined cloud platform can use the temporary anonymous public key from the anonymous authentication request and its own temporary private key to calculate a shared secret (a cryptographic secret value shared by both parties and not transmitted over the network) using a secure key negotiation algorithm (such as ECDH (Elliptic Curve Diffie-Hellman)). According to the Diffie-Hellman principle, the client, using its own temporary anonymous private key and the server's temporary public key subsequently returned by the pre-defined cloud platform, will also obtain the exact same shared secret. Then, based on this shared secret and the specific context information of this session, it is input into a cryptographically secure key derivation function to derive a strong random session key with forward security specific to this session. After receiving the response from the preset cloud (containing the server's temporary public key), the client will independently perform the exact same key negotiation and derivation steps, thereby securely sharing the same session key with the preset cloud without the need for plaintext transmission. This key is used for subsequent ticket granting, ticket encryption, and confidentiality protection of communications.

[0165] Therefore, by dynamically generating a temporary server key pair and negotiating with the client's temporary anonymous public key, the server independently calculates a session key that is shared with the client and is not transmitted over the network. This achieves forward security of the session key. Even if the client's long-term anonymous private key is leaked in the future, it will not be able to decrypt past communication sessions. At the same time, it avoids the risk of the session key being transmitted in plaintext over the network, greatly improving the overall confidentiality and security of the anonymous authentication process.

[0166] In step 703, the session key is encrypted using a temporary anonymous public key, and the encrypted session key and the ticket grant ticket are encapsulated in the authentication response, which is then sent to the client.

[0167] Specifically, the default cloud can encrypt the session key using a temporary anonymous public key, ensuring that only the client holding the corresponding temporary anonymous private key can successfully decrypt it and obtain the plaintext session key. The default cloud then encapsulates the encrypted session key with the ticket granting ticket, forming a structured authentication response message, which is sent to the client. Upon receiving this response, the client performs a reverse decryption operation, using the temporary anonymous private key to decrypt the plaintext session key. Once decryption is successful, the client shares the same session key with the default cloud and obtains the ticket granting ticket necessary to access the TGS. Thus, the initial anonymous authentication exchange is successfully completed, and the client obtains all the necessary credentials to enter the Kerberos system and issue service tickets without revealing its true identity.

[0168] Furthermore, in some embodiments, after issuing a ticket granting ticket corresponding to the anonymous subject identifier to the client, the method further includes: receiving a service ticket request, wherein the service ticket request is generated based on the ticket granting ticket; determining whether the service ticket request meets a preset third validity condition; and if the service ticket request meets the preset third validity condition, issuing a service ticket to the client for accessing the application server.

[0169] Specifically, once the client successfully obtains the ticket granting document corresponding to the anonymous subject identifier from the preset cloud, the client can obtain permission to access specific application services. That is, the preset cloud first receives the service ticket request from the client (including the ticket granting document; a verifier encrypted with a shared session key, containing the client's anonymous subject identifier and timestamp, used to prove its identity to the preset cloud in real time; and the identifier of the target application server the client wishes to access). Subsequently, the preset cloud can determine whether the service ticket request meets the preset third validity condition. Specifically, the preset cloud can use the TGS key to decrypt the received ticket granting document, verify its authenticity, check its validity period, and ensure it has not been revoked. Furthermore, it can use the session key obtained after decrypting the ticket granting document to decrypt the verifier provided by the client. This verifier checks whether the anonymous subject identifier in the verifier matches the identifier in the ticket granting document and checks the timestamp to prevent replay attacks. Ultimately, if the service ticket request meets the preset third validity condition, the preset cloud can issue a service ticket to the client for accessing the application server. This ticket is encrypted using the target application server's long-term key, making it unreadable and unalterable by the client. The ticket contains a newly generated client-server session key, the client's anonymous principal identifier, and the validity period. Simultaneously, the preset cloud will also encrypt this new client-server session key using the session key shared with the client and send it to the client as well. Thus, the client obtains the "ticket" to access the final service. Figure 8 As shown.

[0170] Therefore, after completing the initial anonymous authentication, the standard Kerberos service ticket granting process is extended to accept and verify service requests based on anonymous ticket authorization tickets, and finally issue anonymous service tickets. This seamlessly extends the anonymity feature from the initial authentication stage to the final service access stage, ensuring that users remain anonymous throughout the entire session lifecycle. This allows existing application servers to provide services to anonymous clients without any modifications, achieving a balance between privacy protection and system compatibility.

[0171] The anonymous authentication method proposed in this embodiment of the invention receives an anonymous authentication request. If the signature information in the anonymous authentication request meets a second preset validity condition, a session key and a ticket granting ticket are generated based on preset key exchange information. The session key is encrypted using a temporary anonymous public key, and the encrypted session key and ticket granting ticket are encapsulated in an authentication response, which is then sent to the client. Thus, the security and reliability of the authentication process are ensured through key exchange and ticket authorization mechanisms. Encrypting the session key using a temporary anonymous public key further enhances the security of data transmission, preventing the session key from being stolen or tampered with during transmission. This enables anonymous subjects to complete the authentication process securely and efficiently while protecting their own privacy information.

[0172] Through the above description of the embodiments, those skilled in the art can clearly understand that the system according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0173] This invention also provides a registration device for anonymous credentials, which is applied to a client, such as... Figure 9 As shown, the anonymous credential registration device 10 may include: a transceiver module 100, a processing module 200, and a first generation module 300.

[0174] The transceiver module 100 is used to send a request for public key information of users within the domain to a preset cloud, and to receive response information sent by the preset cloud based on the request for public key information of users within the domain.

[0175] The processing module 200 is used to construct a message to be signed, select a target anonymous key pair corresponding to the current user from a preset set of anonymous key pairs, generate a ring signature based on the message to be signed, the target anonymous private key in the target anonymous key pair and the public key information list in the response information, and generate the current user's holding proof through the temporary anonymous private key in the preset temporary anonymous key pair.

[0176] The first generation module 300 is used to generate an anonymous public key registration request based on the ring signature, the message to be signed, and the proof of possession, and send the anonymous public key registration request to a preset cloud. If the registration is completed on the preset cloud based on the anonymous public key registration request, an anonymous subject identifier of a temporary anonymous public key is generated, and the mapping relationship between the anonymous subject identifier and the temporary anonymous public key is stored in a preset public key library.

[0177] Optionally, in some embodiments, the processing module 200 includes:

[0178] The processing unit is used to determine at least one remaining anonymous public key in a preset set of anonymous key pairs other than the target anonymous public key, generate a random value for at least one remaining anonymous public key, and calculate the trapdoor function value of the target anonymous public key based on the random value of at least one remaining anonymous public key.

[0179] The computing unit is used to perform inverse trapdoor function operation on the trapdoor function value of the target anonymous public key based on the target anonymous private key, so as to obtain a random value of the target anonymous public key;

[0180] The first obtaining unit is used to obtain a ring signature based on a list of public key information, a preset ring baseline value, a random value of the target anonymous public key, and a random value of at least one remaining anonymous public key.

[0181] Optionally, in some embodiments, the processing unit is specifically used for:

[0182] Calculate the trapdoor function value of at least one remaining anonymous public key based on the random value of at least one remaining anonymous public key;

[0183] The ring equation encryption key is obtained by hashing the message to be signed, and the trapdoor function value of the target anonymous public key is obtained based on the ring equation encryption key, the preset ring base value, and the trapdoor function value of at least one remaining anonymous public key.

[0184] Optionally, in some embodiments, before generating a ring signature based on the list of public key information in the message to be signed, the target anonymous private key in the target anonymous key pair, and the response information, the processing module 200 further includes:

[0185] The acquisition unit is used to retrieve the public key certificate from the response information;

[0186] The second obtaining unit is used to obtain a trusted public key in the preset cloud when the public key certificate meets the first preset validity condition.

[0187] The generation unit is used to identify whether the public key information list is in a preset valid state based on the trusted public key, so as to generate a ring signature according to the message to be signed, the preset set of anonymous key pairs and the public key information list if the public key information list is in a preset valid state.

[0188] Optionally, in some embodiments, the generating unit is specifically used for:

[0189] The digital signature in the response message is verified using a trusted public key to obtain the first hash value. The plaintext of the public key information list in the response message is then calculated using a preset hash algorithm to obtain the second hash value.

[0190] If the first hash value and the second hash value are the same, the public key information list is determined to be in a preset valid state.

[0191] Optionally, in some embodiments, after storing the mapping relationship between the anonymous subject identifier and the target anonymous public key in a preset public key library, the first generation module 300 is further configured to:

[0192] Construct an anonymous authentication request and send it to the preset cloud;

[0193] Receives a pre-defined cloud-based ticket granting document corresponding to the anonymous subject identifier, sent based on an anonymous authentication request.

[0194] The anonymous credential registration device provided in this embodiment of the invention sends a request for public key information of users within a domain to the cloud and receives a list of public key information returned by the cloud. It then constructs a message to be signed, generates a ring signature by combining the message, a preset set of anonymous key pairs, and the list of public key information, and generates proof of the current user's ownership using the private key in a preset temporary anonymous key pair. Based on the ring signature, the message to be signed, and the proof of ownership, it generates an anonymous public key registration request and sends it to the cloud. The cloud completes the registration based on the request and generates an anonymous subject identifier for the target anonymous public key, storing the mapping relationship between the identifier and the target anonymous public key in a preset public key repository. Thus, by introducing a ring signature as a group qualification certificate and completing the registration of anonymous public keys in the cloud, the device solves the problems of indistinguishability and difficulty in fine-grained management and auditing caused by all users sharing the same anonymous identity. This enables the authentication system to perform independent identity management, policy control, and access auditing for different anonymous users without exposing their real identities.

[0195] This invention also provides an anonymous authentication device, which is applied to a server, such as... Figure 10 As shown, the anonymous authentication device 20 may include: a receiving module 400, a second generating module 500, and an encapsulation module 600.

[0196] The receiving module 400 is used to receive anonymous authentication requests, which include signature information generated by the target anonymous private key.

[0197] The second generation module 500 is used to generate a session key and a ticket granting ticket based on preset key exchange information, provided that the signature information meets the second preset validity conditions.

[0198] The encapsulation module 600 is used to encrypt the session key using a temporary anonymous public key, and encapsulate the encrypted session key and the ticket grant ticket into the authentication response, and send the authentication response to the client.

[0199] Optionally, in some embodiments, the second generation module 500 is specifically used for:

[0200] A temporary key pair is generated based on preset key exchange information, wherein the temporary key pair includes a server temporary public key and a server temporary private key;

[0201] Calculate the shared secret based on the temporary anonymous public key and the server's temporary private key from the anonymous authentication request;

[0202] Generate a session key based on the shared secret.

[0203] Optionally, in some embodiments, after sending the authentication response to the client, the encapsulation module 600 is further configured to:

[0204] Receive a service ticket request, wherein the service ticket request is generated based on the ticket grant ticket;

[0205] Determine whether the service ticket request meets the preset third validity condition;

[0206] If the service ticket request meets the preset third validity conditions, a service ticket for accessing the application server is issued to the client.

[0207] The anonymous authentication device proposed in this embodiment of the invention receives an anonymous authentication request. If the signature information in the anonymous authentication request meets a second preset validity condition, it generates a session key and a ticket granting ticket based on preset key exchange information. The session key is encrypted using a temporary anonymous public key, and the encrypted session key and ticket granting ticket are encapsulated in an authentication response, which is then sent to the client. Thus, the security and reliability of the authentication process are ensured through key exchange and ticket authorization mechanisms. Encrypting the session key using a temporary anonymous public key further enhances the security of data transmission, preventing the session key from being stolen or tampered with during transmission. This enables anonymous subjects to complete the authentication process securely and efficiently while protecting their own privacy information.

[0208] Figure 11 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. The electronic device may include:

[0209] The memory 1101, the processor 1102, and the computer program stored on the memory 1101 and executable on the processor 1102.

[0210] When the processor 1102 executes the program, it implements the anonymous credential registration method or the anonymous authentication method provided in the above embodiments.

[0211] Furthermore, electronic devices also include:

[0212] Communication interface 1103 is used for communication between memory 1101 and processor 1102.

[0213] The memory 1101 is used to store computer programs that can run on the processor 1102.

[0214] The memory 1101 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0215] If the memory 1101, processor 1102, and communication interface 1103 are implemented independently, then the communication interface 1103, memory 1101, and processor 1102 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0216] Optionally, in a specific implementation, if the memory 1101, processor 1102, and communication interface 1103 are integrated on a single chip, then the memory 1101, processor 1102, and communication interface 1103 can communicate with each other through an internal interface.

[0217] The processor 1102 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement embodiments of the present invention.

[0218] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the anonymous credential registration method, or the steps in any of the embodiments of the anonymous authentication method, when running.

[0219] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0220] Embodiments of the present invention also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described embodiments of the anonymous credential registration method or the steps in any of the embodiments of the anonymous authentication method.

[0221] Embodiments of the present invention also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above embodiments of the anonymous credential registration method, or the steps in any of the embodiments of the anonymous authentication method.

[0222] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0223] The foregoing has provided a detailed description of the anonymous credential registration method, anonymous authentication method, and electronic device provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this invention. It should be noted that those skilled in the art can make various improvements and modifications to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this invention.

Claims

1. A method for registering anonymous credentials, characterized in that, The method is applied to a client, and the method includes the following steps: Send a request for the public key information of users within the domain to a preset cloud, and receive the response information sent by the preset cloud based on the request for the public key information of users within the domain; Construct a message to be signed, select a target anonymous key pair corresponding to the current user from a preset set of anonymous key pairs, generate a ring signature based on the message to be signed, the target anonymous private key in the target anonymous key pair, and the public key information list in the response information, and generate the current user's holding proof through the temporary anonymous private key in the preset temporary anonymous key pair; An anonymous public key registration request is generated based on the ring signature, the message to be signed, and the proof of possession. The anonymous public key registration request is then sent to the preset cloud. If the preset cloud completes the registration based on the anonymous public key registration request, an anonymous subject identifier for a temporary anonymous public key is generated. The mapping relationship between the anonymous subject identifier and the temporary anonymous public key is then stored in a preset public key library. The step of generating a ring signature based on the message to be signed, the target anonymous private key in the target anonymous key pair, and the public key information list in the response information includes: determining at least one remaining anonymous public key in the preset anonymous key pair set other than the target anonymous public key, generating a random value for at least one of the remaining anonymous public keys, and calculating a trapdoor function value for the target anonymous public key based on the random value of the at least one remaining anonymous public key; performing an inverse trapdoor function operation on the trapdoor function value of the target anonymous public key based on the target anonymous private key to obtain a random value for the target anonymous public key; and obtaining the ring signature based on the public key information list, a preset ring baseline value, the random value of the target anonymous public key, and the random value of at least one of the remaining anonymous public keys.

2. The method for registering anonymous credentials according to claim 1, characterized in that, The step of calculating the trapdoor function value of the target anonymous public key based on a random value of at least one of the remaining anonymous public keys includes: Calculate at least one trapdoor function value for the remaining anonymous public key based on a random value of at least one of the remaining anonymous public keys; The ring equation encryption key is obtained by hashing the message to be signed, and the trapdoor function value of the target anonymous public key is obtained based on the ring equation encryption key, the preset ring base value, and the trapdoor function value of at least one of the remaining anonymous public keys.

3. The method for registering anonymous credentials according to claim 1 or 2, characterized in that, Before generating a ring signature based on the message to be signed, the target anonymous private key in the target anonymous key pair, and the list of public key information in the response information, the process further includes: Obtain the public key certificate from the response information; If the public key certificate meets the first preset validity condition, the preset trusted public key in the cloud is obtained; Based on the trusted public key, it is determined whether the public key information list is in a preset valid state, so that if the public key information list is in the preset valid state, the ring signature is generated according to the message to be signed, the preset set of anonymous key pairs, and the public key information list.

4. The method for registering anonymous credentials according to claim 3, characterized in that, The step of identifying whether the public key information list is in a preset valid state based on the trusted public key includes: The trusted public key is used to verify the digital signature in the response information to obtain a first hash value, and a preset hash algorithm is used to calculate the plaintext of the public key information list in the response information to obtain a second hash value. If the first hash value and the second hash value are the same, the public key information list is determined to be in the preset valid state.

5. The method for registering anonymous credentials according to claim 1, characterized in that, After storing the mapping relationship between the anonymous subject identifier and the temporary anonymous public key in the preset public key store, the method further includes: Construct an anonymous authentication request and send the anonymous authentication request to the preset cloud; Receive the ticket granting certificate corresponding to the anonymous subject identifier sent by the preset cloud based on the anonymous authentication request.

6. An anonymous authentication method, characterized in that, The method is applied to a server, and the method includes the following steps: Receive an anonymous authentication request, the anonymous authentication request including signature information, the signature information being generated from a temporary anonymous private key; If the signature information meets the second preset validity condition, a session key and a ticket granting ticket are generated based on preset key exchange information. The session key is encrypted using a temporary anonymous public key, and the encrypted session key and the ticket granting ticket are encapsulated in an authentication response, which is then sent to the client. The step of generating a session key and a ticket granting ticket based on preset key exchange information includes: generating a temporary key pair according to the preset key exchange information, wherein the temporary key pair includes a server temporary public key and a server temporary private key; calculating a shared secret based on the temporary anonymous public key in the anonymous authentication request and the server temporary private key; and generating the session key according to the shared secret.

7. The anonymous authentication method according to claim 6, characterized in that, After sending the authentication response to the client, the method further includes: Receive a service ticket request, wherein the service ticket request is generated based on the ticket grant ticket; Determine whether the service ticket request meets the preset third validity condition; If the service ticket request meets the preset third validity condition, a service ticket for accessing the application server is issued to the client.

8. An electronic device, characterized in that, include: It includes a memory and a processor, the memory storing a computer program, the processor being configured to run the computer program to perform a registration method for anonymous credentials as described in any one of claims 1-5, or an anonymous authentication method as described in any one of claims 6-7.

Images