Identity authentication method and system, electronic device, storage medium and program product

Abstract

The application discloses an identity authentication method and system, an electronic device, a storage medium and a program product, relates to the technical field of security, and only when a legal user is determined for the first time, a key distribution center knows a real name corresponding to a client, a signature, a ticket authorization ticket generation process and a subsequent anonymous access process of a corresponding server are all initiated by the client in a pseudonym, therefore, the key distribution center and the corresponding server do not know the association between the pseudonym and the client, so that the user privacy is protected.

Description

Technical Field

[0001] This application relates to the field of security technology, and in particular to authentication methods, systems, electronic devices, storage media, and program products. Background Technology

[0002] The core of the Kerberos (Ticket-Based Network Authentication Protocol) authentication system is the Key Distribution Center (KDC), which acts as the central authority in the system. While Kerberos provides strong security for network communications, its centralized nature also introduces risks of privacy breaches.

[0003] Specifically, in Kerberos, clients always request and use tickets in plaintext as the real entity (Principal, real name) to the KDC, TGS (Ticket Authorization Server), and server. This means that the KDC and server can trace the user's identity through logs or tickets. Therefore, it is impossible to avoid exposing the user's identity.

[0004] In conclusion, how to implement identity authentication in an identity verification system is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] This application provides authentication methods, systems, electronic devices, storage media, and program products that can achieve authentication in an identity verification system and protect user privacy.

[0006] The first authentication method provided in this application, applied to a client, includes: establishing a long-term key pair based on a real name and a password; performing blinding processing on a pseudonym based on the long-term public key of the long-term key pair to obtain a blinded pseudonym; sending a signature request for the blinded pseudonym to the key distribution center and receiving a blind signature from the key distribution center; sending a ticket authorization request to the key distribution center including the pseudonym, the blind signature, and a temporary public key of a temporary key pair, so that the key distribution center can verify the signature using the blind signature and encrypt / decrypt using the temporary key pair; receiving a random session key and a ticket authorization ticket with the pseudonym as the subject from the key distribution center; and performing anonymous authentication on the corresponding server by combining the random session key and the ticket authorization ticket.

[0007] The second authentication method provided in this application, applied to a key distribution center, includes: establishing a long-term key pair with the client based on the client's real name; receiving a signature request for a blinded pseudonym sent by the client, and verifying the signature request using the long-term key pair; signing the blinded pseudonym and sending the blind signature back to the client if verified; receiving a ticket authorization request from the client including the pseudonym, the blind signature, and a temporary public key of the temporary key pair; verifying the ticket authorization request based on the blind signature, and constructing a ticket authorization ticket with the pseudonym as the subject after successful verification; sending a random session key and the ticket authorization ticket back to the client; receiving an anonymous authentication request from the client combining the random session key and the ticket authorization ticket; verifying the anonymous authentication request, and sending the symmetric key between the client and the corresponding server back to the client if successful, so that the client can anonymously access the corresponding server based on the symmetric key.

[0008] This application provides an identity authentication system, comprising: a client and a key distribution center; the client performs the steps of the first identity authentication method described above; and the key distribution center performs the steps of the second identity authentication method described above.

[0009] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described authentication methods.

[0010] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described authentication methods.

[0011] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described authentication methods.

[0012] In this application, the client and the key distribution center establish a long-term key pair based on real names only in the initial stage. In subsequent stages such as signing, constructing ticket authorization requests, and subsequent identity authentication with the server, pseudonyms are used to protect user privacy.

[0013] Specifically, the client first establishes a long-term key pair with the key distribution center based on its real name. Then, it blinds the pseudonym using the long-term public key of the long-term key pair, obtaining a blinded pseudonym. The client then sends a signature request for the blinded pseudonym to the key distribution center. Since this blinded pseudonym is based on the long-term key pair between the client and the key distribution center, the key distribution center can clearly identify that a verified legitimate user sent a pseudonym and requested a signature. The key distribution center can then sign the pseudonym and send the blind signature back to the client. When the client needs a ticket authorization document, it sends a ticket authorization request to the key distribution center, including the pseudonym, the blind signature, and the temporary public key of the temporary key pair. The key distribution center can verify the signature using the blind signature, encrypt and decrypt it using the temporary key pair, and after verification, determine that the pseudonym was previously used to sign. At this point, it can generate a ticket authorization document with the pseudonym as the subject and send the ticket authorization document and the corresponding random session key to the client. When a client needs to access a target service, it can combine a random session key and a ticket authorization ticket to request authentication from the key distribution center, thereby enabling anonymous access to the target service server.

[0014] The technical effect of this application is that the key distribution center only knows the client's real name when the legitimate user is first identified. In the subsequent processes of signing, ticket authorization, ticket generation, and anonymous access to the corresponding server, the client initiates the process with a pseudonym. Therefore, neither the key distribution center nor the corresponding server knows the association between the pseudonym and the client, thus protecting user privacy. Attached Figure Description

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

[0016] Figure 1 A schematic diagram illustrating the implementation of the first identity authentication method provided in this application embodiment;

[0017] Figure 2 A schematic diagram illustrating the implementation of the second identity authentication method provided in this application embodiment;

[0018] Figure 3 This is a schematic diagram of the structure of an identity authentication system provided in an embodiment of this application;

[0019] Figure 4 A schematic diagram illustrating the overall process of an identity authentication method provided in this application embodiment;

[0020] Figure 5A blinded signature timing diagram for an identity authentication method provided in this application embodiment;

[0021] Figure 6 A timing diagram of the anonymous ticket application stage of an identity authentication method provided in this application embodiment;

[0022] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0023] Figure 8 This is a schematic diagram of the specific structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0025] It should be noted that, in the description of this application, 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., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0026] For ease of understanding, the technical terms, namely the Kerberos protocol, core components and concepts involved in the embodiments of this application are explained below.

[0027] Realm: Represents an authentication management domain. Its purpose is to define the boundaries by which an authentication server has the authority to authenticate users, hosts, or services. Essentially, a user / service belongs to that domain only if they share a secret (password / key) with the domain's authentication server.

[0028] Principal: A principal is the name used to refer to an entry in the authentication server's database. Each user, host, or service in a given domain is associated with a principal.

[0029] Client: A user or system that uses the Kerberos protocol to communicate with other entities (such as services).

[0030] Ticket: A ticket (or credential) is something a client presents to an application server to prove its identity. Tickets are issued by authentication servers and encrypted using a secret key specific to the service they represent. Because this key is shared only between the authentication server and the server providing the service, even the client requesting the ticket cannot know it or alter its contents.

[0031] The main information in a ticket includes: 1. The requesting user's entity (usually a username); 2. The entity to which the ticket applies for the service; 3. The IP address of the client machine that can use the ticket; 4. The date and time when the ticket's validity begins (in timestamp format); 5. The maximum lifespan of the ticket; 6. The session key.

[0032] Encryption: Kerberos often requires encrypting and decrypting messages (tickets and validators) transmitted between authenticated participants. It's important to note that Kerberos uses only symmetric-key encryption (in other words, encryption and decryption use the same key).

[0033] Key Distribution Center (KDC): In a Kerberos environment, the authentication server, based on its ticket distribution function for access services, is called the Key Distribution Center, or simply KDC. Since it resides entirely on a single physical server (which typically corresponds to a single process), it can logically be divided into three parts: the database, the Authentication Server (AS), and the Ticket Granting Server (TGS).

[0034] The database is a container for entries associated with users and services. An entry is referenced using a subject, and often the subject can also be used to refer to the entry itself. Each entry contains the following information: 1. The subject associated with the entry; 2. The encryption key; 3. The maximum validity period of the ticket associated with the subject; 4. Attributes or flags describing the ticket's behavior; 5. The password's expiration date; 6. The subject's expiration date, after which no more tickets will be issued.

[0035] The Authentication Server (AS) is part of the KDC. It responds to initial authentication requests from clients, at which point the user has not yet been authenticated and must enter a password. In response to the authentication request, the AS issues a special ticket called a Ticket Authorization Ticket, or TGT for short, associated with the principal krbtgt / REALM@REALM. If the user successfully authenticates, they can use the TGT to obtain tickets for other services without having to re-enter their password.

[0036] Ticket Authorization Server (TGS): The Ticket Authorization Server distributes service tickets to clients with valid TGTs, ensuring the authenticity of their identities so that they can obtain the requested resources on the application server. The TGS can be viewed as an application server (given that accessing it requires presenting a TGT), and it provides the issuance of service tickets as a service.

[0037] Session Key: Users and services share a secret with the KDC. For users, this secret is a key derived from their password, while for services, it is their secret key (set by the administrator). These keys are called long-term keys because they do not change when the work session changes. Users also need to share a key with the service, at least for the duration of a work session opened by the client on the server: this key, generated by the KDC when issuing a ticket, is called the session key.

[0038] Authenticator: The client adds another data packet (authenticator) to the request containing the ticket. This packet contains the user's identity and a timestamp (the current time), encrypted using the session key. The server, which must provide the service, upon receiving this request, unpacks the first ticket, extracts the session key, and if the user is indeed who they claim to be, the server is able to decrypt the authenticator and extract the timestamp. Authentication succeeds if the time difference between the latter and the server is less than 2 minutes (this tolerance is configurable). This emphasizes the criticality of synchronization between machines belonging to the same domain.

[0039] In this embodiment of the application, an improved approach of blind signature and temporary key is introduced, so that when the client requests a Kerberos ticket, the KDC cannot know the real identity, nor can it deduce the identity from logs or other information.

[0040] The core idea lies in the blind signature phase: when the client initially demonstrates its legitimacy to the KDC, the KDC performs a blind signature on a randomly generated anonymous credential (pseudonym). Because of the blind signature, the KDC cannot see the client's actual anonymous credential during the signing process, and therefore does not know which user the credential will later be associated with.

[0041] During the anonymous ticket request phase: When the client, holding the blind-signed anonymous credential and corresponding private key, requests the TGT from the KDC, it only exposes the anonymous credential itself and uses a temporary Diffie-Hellman (DH) key to protect the ticket transmission. After verifying the blind signature, the KDC issues the TGT to the client with the anonymous credential as the principal, without writing any information directly corresponding to the real identity to the log or ticket.

[0042] In the standard Kerberos process: the client uses the obtained TGT to request a Service Ticket from the TGS, and then uses the Service Ticket to initiate an AP_REQ to the application server. Throughout the process, the KDC only sees the anonymous credentials and not the real username.

[0043] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments, focusing on different clients and key distribution centers.

[0044] Please refer to Figure 1 This method is applied to the client and includes the following steps.

[0045] S101. Establish a long-term key pair based on real-name authentication and the key distribution center.

[0046] In this context, a long-term key pair can be represented as a public key PKKDC and a private key SKKDC. Here, SK (Session Key) refers to the session key.

[0047] This long-term key pair can be used later to blindly sign the blinded pseudonym, using the RSA algorithm. The RSA algorithm, or asymmetric encryption, is based on the difficult problem of factoring large integers into their prime factors. Its key pair generation involves selecting two large prime numbers p and q, and calculating their modulus. Choose a public key exponent e, which is coprime to φ(N); calculate the private key exponent d such that e∙d≡1 mod φ(N); encryption / decryption: encryption: C=M e mod N; Decryption: M=C d mod N; Signature / Verification: Signature: Verification: Verify σ e Does mod N equal H(M)?

[0048] Specifically, the initial authentication between the client and the KDC is used only once during the Enrollment (blind signature phase) to verify the user's identity.

[0049] You can either use the Kerberos AS_REQ procedure or perform a regular Kerberos authentication using username and password in the Enrollment. Essentially, this step establishes trust between the KDC and the client regarding the verified identity. For example, it confirms trust in alice@EXAMPLE.COM.

[0050] S102. The pseudo-name is blinded based on the long-term public key of the long-term key pair to obtain the blinded pseudo-name.

[0051] A pseudonym is a name that is distinct from the real name. It can be specified by the user or randomly generated in the client.

[0052] In one specific embodiment of this application, generating a pseudonym includes: randomly generating a string; concatenating the string with a timestamp and then truncating the string to obtain the pseudonym. Let P represent the pseudonym. P is generated as follows: first, a 256-bit random string R is randomly generated, and P = SHA256(R∥Timestamp) is set, then truncated to an appropriate length (e.g., 128 or 160 bits). P is considered a large integer (padding to N (KDC)). RSA The modulus of the public key is the same as the length. For example, after padding with PKCS#1 v1.5, the integer m is obtained.

[0053] Blinding is a process of masking pseudonyms so that the signer at the key distribution center signs the pseudonym without knowing the original text.

[0054] After the pseudo-names are made blind, they are called blinded pseudo-names.

[0055] In one specific embodiment of this application, a pseudo-name is blinded based on the long-term public key of a long-term key pair to obtain a blinded pseudo-name, including: randomly generating an integer based on the long-term public key; determining a blinding factor by combining the public key exponent of the long-term public key and the integer; filling the pseudo-name, and using the blinding factor to blind the filled pseudo-name to obtain a blinded pseudo-name.

[0056] The client can randomly generate a large integer locally. , where N is the modulus of the KDC_RSA public key.

[0057] Calculate the blinding factor , where e is KDC RSA The public key exponent, mod represents the modulo operation.

[0058] Computational blinding pseudo-names : , where m is the padded integer corresponding to the pseudonym of the client.

[0059] S103. Send a blind pseudo-signature request to the key distribution center and receive the blind signature from the key distribution center.

[0060] Blind signature refers to the process of making a message invisible, where the signer signs the message without knowing the original text, and the recipient then deblinds the message to obtain a valid signature. It can be used for anonymous credentials, allowing users to obtain the signer's approval without revealing the credential content.

[0061] The implementation process of blind signatures includes user-generated message M and blind factor r, and calculation of the Braille. The signatory Perform a regular signature and return a blind signature result; the user uses r to blindly obtain the signature of the original M; the signer is unaware of the content of M, ensuring the message and the signer are uncorrelated. Implementation algorithms include RSA blind signatures and elliptic curve-based blind signature schemes.

[0062] In one specific embodiment of this application, sending a signature request with a blinded pseudonym to a key distribution center includes: generating a one-time random number; adding the blinded pseudonym and the one-time random number to the signature request; and sending the signature request to the authentication server of the key distribution center. That is, the client... (i.e., the content to be signed) The blinding result, along with a one-time random number Nonce1 (N1, to prevent replay), is sent to the KDC. The message content is as follows:

[0063] Msg_Enroll_REQ = {

[0064] MessageType: ENROLL_BLIND_REQ,

[0065] BlindData: ,

[0066] Nonce1: N1,

[0067] ProofOfIdentity: <credentials already completed using the original Kerberos authentication (e.g., AS_REQ)>

[0068] …

[0069] }

[0070] In this embodiment, the ProofOfIdentity step can be implemented during Enrollment by having the KDC verify that the user is indeed legitimate. That is, the client must first perform a standard Kerberos AS_REQ verification before the KDC accepts the application. In other words, KDC only sees It doesn't know which P corresponds to, so it can't associate P with any real username.

[0071] After sending a signature request to the key distribution center, you can receive a blind signature from the key distribution center. Then, by deblinding the blind signature, you can obtain the signature of P.

[0072] After successful signature verification, the client retains a pair (P, σ) and does not resend it to the KDC along with the real user. The client can securely store (P, σ) locally, deleting intermediate pairs of blinded data and random numbers. KDC has never known about the unblinded P, nor does it store any mapping information; the client only retains it locally. These will be used as "anonymous credentials" when requesting the TGT later. Up to this point, the KDC (Certificate Authority) knows that "this client is legitimate" and "has signed a certain blinded value it gave", but the KDC does not know which P it is after the blinded value is deblinded.

[0073] RSA blind signature aims to prevent the signer from knowing which message they are signing when signing a blinded message. The specific implementation process includes: Blinding: The user selects a blinding factor r, and generates... Then calculate the blinded signature: Blind signature: The signer uses their private key d to... sign: Deblinding: Client-side computation Obtain the valid signature of the original m. In this way, the signer can confirm that the message has been authorized, but cannot associate the signature with the original message, thus protecting user privacy.

[0074] In this embodiment, it can be used This represents the signature, or it can be represented as (P, σ), where σ corresponds to the signature.

[0075] S104. Send a ticket authorization request to the key distribution center, which includes a pseudonym, a blind signature, and a temporary key pair, so that the key distribution center can use the blind signature for verification and the temporary key pair for encryption and decryption.

[0076] Get it from the client Then, in preparing to request the Ticket-Granting Ticket (TGT), a temporary Diffie-Hellman key pair (ga, a) can be generated, where g a 'a' is the client's DH public key, and 'a' is the client's DH private key.

[0077] Then, the client will use the pseudonym P (plaintext) and the KDC to blindly sign P σ= and the client's DH public key g a Send them together to the Key Distribution Center (KDC).

[0078] In other words, during the TGT request phase, the client no longer uses its real username, but only sends (P, σ) and a one-time Diffie-Hellman public key to the KDC to request the TGT. The KDC verifies the signature; if the signature is valid, it issues a TGT bound only to P. Throughout the entire process, the KDC remains completely unaware of the TGT. Which user is it?

[0079] In the specific implementation process, the client constructs an anonymous TGTREQ and generates a temporary DH key pair: a secure DH group is selected, a local random private key 'a' is generated, and the corresponding public key 'g' is calculated. a , will g a This is denoted as DHC. Construct the TGT_Request message elements, including: pseudonym P, KDC signature. This signature has been deblinded and can be directly verified, along with the client's DH public key DHC=ga and a new random number. (To prevent this request from being replayed). Package this content and add the necessary Kerberos fields: Msg_TGT_REQ = {

[0080] MessageType: ANON_TGT_REQ,

[0081] Pseudonym: P,

[0082] SignatureSigma: σ,

[0083] DH_Public: DHC = ga,

[0084] Nonce2: N2 …

[0085] }

[0086] At this point, the client no longer transmits any real username or long-term symmetric key. The KDC will only see the client's signature σ and DH public key g in the logs. a The request to TGT does not reveal the corresponding real name behind it, such as alice@EXAMPLE.COM.

[0087] S105. Receive the random session key and the ticket authorization ticket with a pseudonym as the subject from the key distribution center.

[0088] After receiving the authorization request for the bill, the KDC can verify the signature using blind signature, encrypt and decrypt it based on the temporary key pair, construct the authorization bill based on the pseudonym, and send feedback.

[0089] The client can receive a random session key and a ticket authorization ticket with a pseudonym as the subject from the key distribution center. In this way, the client obtains the random session key and the ticket authorization ticket based on the pseudonym.

[0090] In one specific embodiment of this application, receiving a random session key and a ticket authorization document with a pseudonym as the subject from a key distribution center includes: deblinding the pseudonym in the ticket authorization document to obtain a deblinding result; determining whether the deblinding result corresponds to the pseudonym; if so, confirming that the blinded signature has not been tampered with, retaining the data pair consisting of the pseudonym and the ticket authorization document; and storing the data pair. In other words, the client can obtain the random session key by decrypting the DH encryption. And the authorized note TGT with the subject being P.

[0091] Among them, TGT: KDC -> Client: When the client receives Use the r value you retain to unblind: Here, m is the integer obtained by padding p with PKCS#1. The client verifies whether σ is the correct signature of m by KDC (using PK). KDC Verification is required to ensure that the signature has not been tampered with. It should be equal to the original filled m.

[0092] After client decryption, obtain At this point, the client already possesses the TGT corresponding to subject P and the session key for communicating with the TGS. The anonymous TGT request is completed. At this point, KDC doesn't know who is behind P because it didn't know what P was during the blind signature process in Enrollment. In this step, it only sees that (P, σ) are both valid -> issues a TGT to P, without any record of P corresponding to a real name, such as alice@EXAMPLE.COM.

[0093] S106. Combine the random session key and the ticket authorization ticket to perform anonymous authentication on the corresponding server.

[0094] The client requests a Service Ticket from the TGS to enable anonymous authentication and communication with the corresponding server.

[0095] In one specific embodiment of this application, anonymous authentication is performed on the corresponding server using a random session key and a ticket authorization ticket, including: generating a new random number and determining the current timestamp; constructing an authenticator by combining the random session key, pseudonym, new random number, and current timestamp; sending the ticket authorization ticket, authenticator, target service, new random number, and current timestamp to the ticket authorization server of the key distribution center; receiving response data from the ticket authorization server; decrypting the response data using the random session key to obtain a symmetric key with the target service; verifying the symmetric key; and, after successful verification, communicating with the server corresponding to the target service using the symmetric key.

[0096] During the anonymous authentication process between the client and the target service server, the client can obtain... Following TGT, the client constructs a standard Kerberos TGSREQ. Specifically, the client can generate a new random number Nonce4 (N4) and the current timestamp T4, and construct the authenticator. : .

[0097] Then, the information Msg_TGS_REQ = {

[0098] MessageType: TGS_REQ,

[0099] Ticket: <TGT obtained in the previous step (where TGT.cname = P)>,

[0100] Authenticator:Auth_tgs,

[0101] SName: <Target Service S@REALM>,

[0102] Nonce4: N4,

[0103] Timestamp 4: T4, ...

[0104] Send it to TGS together.

[0105] Then, the client receives the symmetric key between the client and the target service from the TGS feedback, and communicates with the server corresponding to the target service based on the symmetric key.

[0106] In this application, the client and the key distribution center establish a long-term key pair based on real names only in the initial stage. In the subsequent stages of signing, constructing ticket authorization requests, and subsequent anonymous authentication with the server, pseudonyms are used to protect user privacy.

[0107] Specifically, the client first establishes a long-term key pair with the key distribution center based on its real name. Then, it blinds the pseudonym using the long-term public key of the long-term key pair, obtaining a blinded pseudonym. The client then sends a signature request for the blinded pseudonym to the key distribution center. Since this blinded pseudonym is based on the long-term key pair between the client and the key distribution center, the key distribution center can clearly identify that a verified legitimate user sent a pseudonym and requested a signature. The key distribution center can then sign the pseudonym and send the blind signature back to the client. When the client needs a ticket authorization document, it sends a ticket authorization request to the key distribution center, including the pseudonym, the blind signature, and the temporary public key of the temporary key pair. The key distribution center can verify the signature using the blind signature, encrypt and decrypt it using the temporary key pair, and after verification, determine that the pseudonym was previously used to sign. At this point, it can generate a ticket authorization document with the pseudonym as the subject and send the ticket authorization document and the corresponding random session key to the client. When a client needs to access a target service, it can combine a random session key and a ticket authorization ticket to request anonymous authentication from the key distribution center, thereby enabling anonymous access to the target service server.

[0108] The technical effect of this application is that the key distribution center only knows the client's real name when the legitimate user is first identified. In the subsequent processes of signing, ticket authorization, ticket generation, and anonymous access to the corresponding server, the client initiates the process with a pseudonym. Therefore, neither the key distribution center nor the corresponding server knows the association between the pseudonym and the client, thus protecting user privacy.

[0109] Please refer to Figure 2 This authentication method, applied to key distribution centers, includes the following steps.

[0110] S201. Establish a long-term key pair with the client based on the client's real name.

[0111] This embodiment describes the authentication method from the perspective of the key distribution center. It corresponds to the authentication method described from the perspective of the client and can be referred to accordingly. Similar or identical steps will not be described in detail.

[0112] S202. Receive the signature request for the blinded pseudonym sent by the client, and verify the signature request using the long-term key pair.

[0113] S203. Sign the blinded pseudonym under verification and return the blind signature to the client.

[0114] In one specific embodiment of this application, signing a blinded pseudonym includes: signing the blinded pseudonym in the signature request using the private key in a long-term key pair.

[0115] After receiving the signature request, KDC verifies that the client has passed the first Kerberos verification, and then uses its own RSA private key SK. KDC Sign the blinded message directly: , where d is the private key index of KDCRSA.

[0116] KDC returns a message to the client: Msg_Enroll_REP = {

[0117] MessageType: ENROLL_BLIND_REP,

[0118] BlindSignature:

[0119] Nonce1Response: N1, / / Corresponds to the Nonce1 sent by the client

[0120] …

[0121] }

[0122] In other words, KDC does not store the plaintext P anywhere; it can only know that a legitimate user has submitted a P. It was signed, but it doesn't know what pseudonym P it will get after unblinding.

[0123] S204. Receive a ticket authorization request from the client, which includes a pseudonym, a blind signature, and a temporary public key for a temporary key pair.

[0124] S205. Verify the authorization request for the negotiable instrument based on blind signature. After successful verification, construct a negotiable instrument authorization document with a pseudonym as the subject.

[0125] In this embodiment, verifying a bill authorization request based on a blind signature includes: verifying whether the blind signature corresponds to a pseudonym; if so, determining that the bill authorization request has passed verification; if not, determining that the bill authorization request has failed verification. That is, verifying a blind signature determines whether the signature is a previously created signature to ensure that the signature has not been tampered with. For example, KDC verification of (P,σ) verifies whether σ is... If the signature verification fails, the document is rejected and an error is returned; if the signature verification succeeds, a document authorization document with a pseudonym is constructed.

[0126] In one specific embodiment of this application, constructing a bill authorization document with a pseudonym as the subject includes: determining the pseudonym as the subject of the bill authorization document; ensuring that the server subject in the bill authorization document is consistent with the core service account corresponding to the real name; obtaining a random session key and determining the random session key as the session key between the client and the bill authorization server in the key distribution center; and writing the session key into the encrypted portion of the bill authorization document.

[0127] Specifically, KDC constructs the TGT: the TGT's principal (Client Principal) is set to... The ServerPrincipal of TGT remains krbtgt / REALM (core service account).

[0128] TGT.enc-part (encrypted) section: ,in It is a symmetric key shared between KDC and TGS. AuthTime (authentication time), EndTime (expiration time), etc., can be found in the Kerberos protocol.

[0129] Therefore, TGT itself can be written as: .

[0130] S206. Feedback the random session key and ticket authorization ticket to the client.

[0131] That is, it can send a random session key and ticket authorization ticket back to the client, and can also use encrypted feedback to avoid data leakage.

[0132] In one specific embodiment of this application, feeding back a random session key and a ticket authorization ticket to the client includes: packaging the random session key, the client's random number, and the current timestamp into packaged data; symmetrically encrypting the packaged data using a symmetric key to obtain encrypted packaged data; and feeding back the encrypted packaged data and the ticket authorization ticket to the client.

[0133] Symmetric encryption refers to a method where the sender and receiver share the same key. This key is used to encrypt plaintext and decrypt ciphertext. It offers fast encryption and decryption speeds, making it suitable for real-time protection of large datasets.

[0134] Specifically, the KDC generates its own DH private key X and corresponding public key gx for DH key exchange with the client: a random key can be selected. ,calculate .

[0135] KDC calculates the shared key D : The client calculates the shared key as follows: KDC randomly generates a new client-TGS session key. This key will be used for subsequent... communication.

[0136] The encrypted response that KDC constructs for the client includes: sending the TGT (Trusted Token) verbatim to the client, and also providing the client with the information for decryption. The key uses a shared key. Encrypt and send to the client. Specifically: First, the KDC-generated... Packaged together with the client's Nonce2 and current timestamp T3: , and obtain the packaged data.

[0137] Using symmetric keys Perform symmetric encryption (e.g., AES-CBC + MAC) on the above payload: Thus, once the client receives the data, it can use its DH private key σ to calculate DH_shared, and then decrypt C to obtain the data. .

[0138] The message that KDC returns to the client is as follows:

[0139] Msg_TGT_REP = {

[0140] MessageType: ANON_TGT_REP,

[0141] TGT: <a complete Kerberos TGT object, where cnmae=P>,

[0142] DH_Pub_KDC: (g x ),

[0143] EncryptedPart: C = …,

[0144] Nonce3: N3

[0145] }

[0146] Wherein, DH_Pub_KDC = g x After receiving it, the client can combine it with the previously set DH_Public=g a Doing DH yields the same result .

[0147] S207. Receive an anonymous authentication request sent by the client in combination with a random session key and a ticket authorization ticket.

[0148] S208. Verify the anonymous authentication request. If the verification is successful, return the symmetric key between the client and the corresponding server to the client so that the client can anonymously access the corresponding server based on the symmetric key.

[0149] When processing anonymous authentication requests sent by clients, the processing procedure can refer to the processing flow for real-name authentication requests, that is, equating pseudonyms with real names.

[0150] In one specific embodiment of this application, the anonymous authentication request is verified, and if the verification is successful, the symmetric key between the client and the corresponding server is fed back to the client. This includes: decrypting the ticket authorization document in the anonymous authentication request using the public key of the random session key to obtain a random session key; decrypting the encrypted part of the ticket authorization document using the random session key to obtain a timestamp and a random number; verifying whether the anonymous authentication request is outdated using the timestamp and the random number; if not, verifying the pseudonym; after the pseudonym verification is successful, generating a new session key with the corresponding server using the shared key; and constructing a symmetric key between the client and the corresponding server using the new session key and the response server.

[0151] In this embodiment, during TGS operation (TGS and KDC share K), TGS Specifically, TGS uses K. TGS Decrypt TGT.enc-part to obtain K c-TGS , using K c-TGS Decrypt Authentica to obtain (P∥T4∥N4), and verify whether the timestamp T4 and Nonce N4 are fresh (i.e., whether they are outdated / expired).

[0152] After the pseudonym P is verified, TGS uses the shared key Key S (Shared with service S) Generate a new session key Kc-s.

[0153] Constructing a Service Ticket:

[0154] ST = {

[0155] tkt-vno: 5,

[0156] realm: REALM,

[0157] sname: S@REALM, / / Server segment main body

[0158] cname: P, / / Still the anonymous pseudonym P

[0159]

[0160] }

[0161] Construct the encrypted segment for the client: .in It can be equal to N4 sent by the client, or a new Nonce (random number) generated by TGS.

[0162] TGS returned: Msg_TGS_REP = {

[0163] MessageType: TGS_REP,

[0164] Ticket: ST,

[0165] EncPartToClient:

[0166] Nonce_TGS: N5

[0167] }

[0168] After the client receives it, it uses Decrypt EncPartToClient and obtain as well as Once verified, communication with the application server S can begin.

[0169] Specifically, the client sends an AP_REQ to the application server S, and the client generates a new random number. With timestamp .

[0170] structure .

[0171] Send the ServiceTicket(ST) along with the Authenticator to S:

[0172] Msg_AP_REQ = {

[0173] MessageType: AP_REQ,

[0174] Ticket: ST, / / ST.cname = P

[0175] Authenticator: Auth_cS,

[0176] Nonce6: N6,

[0177] Timestamp 6: T6,

[0178] …

[0179] }

[0180] Application server S uses its own shared resources with KDC Decrypting ST.enc-part yields Then use Decrypt Authenticator to obtain .

[0181] S verifies the pseudonym P and the session key it holds. Once a match is found and the timestamp is valid, a secure session can be established with the client. Throughout the process, the application server only sees the P and has no idea that it is connected to alice@EXAMPLE.COM.

[0182] At this point, KDC, TGS, and the application server only know that they see a pseudonym named P using Kerberos, but no node knows who is behind P.

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

[0184] Embodiments of this application also provide an identity authentication system in which the steps of the above-described identity authentication method can be implemented.

[0185] Please refer to Figure 3 The identity authentication system includes: client 101 and key distribution center 201; the client performs actions such as... Figure 1 The steps of the authentication method shown are as follows; the key distribution center performs the following... Figure 2 The steps of the identity authentication method.

[0186] In this identity authentication system, such as Figure 4 The steps described in the above method embodiments can be implemented. The method will be described in detail below based on different stages.

[0187] like Figure 5 As shown, in Phase 1: Enrollment, the client (User) knows its "real identity" (e.g., alice@EXAMPLE.COM) and shares a long-term password with the KDC. The client generates a random pseudonym P=256 bits hash value (or longer) locally and blinds it, then sends a request to the KDC: "Legitimate user, please sign the blinded pseudonym." After deblinding the "blinded data," the KDC returns a blind signature. The client then removes the blind signature to obtain the correct signature. Real signature During this process, KDC only knows that "a verified user sent a blind value", but never knows the real identity used by the client (alice@EXAMPLE.COM), and therefore cannot retain any "P ↔alice@EXAMPLE.COM" mapping.

[0188] Among them, hash algorithms (digest algorithms) calculate a fixed-length digest for input messages of arbitrary length. They have one-way property: it is impossible to deduce the original text from the digest; collision resistance: it is difficult to find different messages with the same digest; and fixed-length output: the output length is consistent regardless of the length of the input.

[0189] Please refer to Figure 6 Phase Two: Anonymous TGT_Request Phase. The Key Distribution Center (KDC) verifies whether the blind signature σ is valid for P (by calling the public key system). If the verification passes, it means that "a registered user" possesses a valid signature credential, and a new TGT is granted. At this time, when constructing the TGT, the KDC sets the principal (Client_Principal) of the TGT to P (the pseudonym mentioned above) and uses the shared key between the KDC and the TGS. Enc-part encryption of TGT.

[0190] Since there is no shared long-term key between P and KDC on the client (because KDC currently does not know who the client is, and therefore cannot retrieve the symmetric key that originally belonged to the client), KDC needs to implicitly embed the "TGT decryption material" given to the client within a key shared with the client's DH public key. Under the corresponding shared key. In other words, the KDC selects a random session key. This serves as the session key between the client and the TGS, and is written into the enc-part (encrypted part) of the TGT; simultaneously, the KDC uses a shared key derived from the Diffie-Hellman public key. (where x is the KDC's DH private key) After encryption, it is sent to the client along with the TGT.

[0191] Phase 3: Standard Kerberos TGS_Request and AP_Request, the client obtains a random session key. It can be used like a regular Kerberos client to request a Service Ticket from TGS. TGS generates a ticket for the pseudonym 'p' for the client to use with the target service. Session key Use the enc-part of the Service Ticket encryption( (This is the long-term symmetric key between KDC and S), and the main body of the Service Ticket is also p. The client decrypts it upon receipt. When the client performs an AP_REQ with the server S (which is also a standard Kerberos process), the server sees the "client subject" as P and does not know its true identity.

[0192] As can be seen, the method steps described in the above embodiment of the identity authentication system allow the KDC to be unaware of the user's identity, thus achieving identity authentication. Specifically, since the KDC never sees the real name during enrollment, and the client blinds the pseudo-P, the KDC directly performs a blind signature on the blinded P. The KDC only sees the blinded P and does not know what the real P is. Blind signatures theoretically guarantee that the signer (KDC) cannot know the original message content during the signing process. Therefore, the KDC's internal database only records "signed for a blinded entity" and never stores P or the mapping between P and the real user.

[0193] The client obtains (P,σ) only after unblinding, while KDC cannot deduce who P is when it encounters σ.

[0194] σ is merely the signature result of P by KDC, but during the blind signature process, KDC does not know which P is being signed. Even if KDC retains the signature afterward... "This pair, because the blinding factor cannot be obtained, cannot recover the original P. Therefore, for KDC, "after the blind signature phase ends, there is no usable information about P" -> it can no longer deduce the original P from σ sent by the client during TGT_Request. This completely cuts off KDC's ability to know "who a certain P is".

[0195] Subsequent communications (between TGS and the application server) only show the 'P' and not the actual username.

[0196] All intermediate roles (TGS, Service S) will only see the ticket with "Subject = P" and will never see alice@EXAMPLE.COM.

[0197] In this way, even if someone gets a Service Tickeet in the middle, they will only see "fake name = P" and will not be able to deduce the real identity.

[0198] In summary, once the KDC blindly signs P, it cannot deduce the mapping relationship between P and the real user, and will therefore be unaware of which real user is involved in subsequent processes. This scheme theoretically achieves the goal of preventing the KDC and application server nodes from obtaining or speculating on the user's true identity.

[0199] Furthermore, if this application uses a symmetric key entirely... (That is, the client and KDC share a long-term symmetric key), KDC must know from the beginning which key belongs to which username. KDC will use this symmetric key to decrypt when verifying tickets: This makes it easy for KDC to connect "symmetric key" <-> "alice@EXAMPLE.COM" afterwards, and anonymity cannot be established.

[0200] Therefore, the client's identity must be completely separated from subsequent credential requests. The blind signature phase ensures that even if the KDC performs a signature, it does not know which pseudonym it has signed; the DH phase ensures that the "session key" sent by the KDC to the client does not need to use a symmetric key system, but is instead negotiated with the client temporarily in this request.

[0201] After these two steps are combined, the two responsibilities of the KDC are separated: Enrollment: The KDC verifies the validity of the request and signs a blinded value carried in the request, but does not know what this value is after deblinding. Issuance of TGT: The KDC only issues a pseudonym P invoice based on "valid blind signature + client temporary DH" and transmits the session key to the client via DH.

[0202] From a cryptographic perspective, this combination scheme is very effective for "anonymous credentials": blind signatures ensure that the signer (KDC) is unaware of the content being signed; DH guarantees that the session key can only be shared between the client and the server, and can securely hand over the session key to the other party even if the KDC does not know the identity.

[0203] Therefore, the technical effect of this application is as follows: This application enables the KDC to be completely unaware of who issued the ticket, severing the association between identity and authentication token. This achieves anonymity. Even if someone obtains a ticket and only sees the pseudonym P and the temporary session key, they cannot trace back the real username. Due to the blind signature process, unless the "blinding factor r" stored locally on the client is leaked to the KDC, the KDC cannot reverse-engineer P in the future. Diffie-Hellman ensures that "the session key K_(c-TGS) is only derived within the current session and is not associated with the KDC's long-term key."

[0204] Corresponding to the above method embodiments, this application also provides an electronic device. The electronic device described below can be referred to in correspondence with the identity authentication method described above.

[0205] See Figure 7 As shown, the electronic device includes: a memory 332 for storing a computer program; and a processor 322 for executing the computer program to implement the steps of the authentication method described in the above method embodiment.

[0206] This electronic device can be a client or a server corresponding to the KDC.

[0207] For details, please refer to Figure 8 The electronic device can vary considerably depending on its configuration or performance. It may include one or more central processing units (CPUs) (e.g., one or more processors) and memory 332, which stores one or more computer programs 342 or data 344. Memory 332 may be temporary or permanent storage. The program stored in memory 332 may include one or more modules (not shown in the figure), each module including a series of instruction operations on the data processing device. Furthermore, processor 322 may be configured to communicate with memory 332 and execute the series of instruction operations stored in memory 332 on electronic device 301.

[0208] Electronic device 301 may also include one or more power supplies 326, one or more wired or wireless network interfaces 350, one or more input / output interfaces 358, and / or one or more operating systems 341.

[0209] The steps in the authentication method described above can be implemented by the structure of an electronic device.

[0210] Corresponding to the above method embodiments, this application also provides a readable storage medium. The readable storage medium described below corresponds to the identity authentication method described above. This application also provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps of any of the above identity authentication method embodiments at runtime.

[0211] 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.

[0212] Embodiments of this application 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 identity authentication method embodiments.

[0213] Embodiments of this application 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-described authentication method embodiments.

[0214] 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 implementation should not be considered beyond the scope of this application.

[0215] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the methods and core ideas of this application. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. An identity authentication method, characterized in that, Applied to the client side, including: Establish long-term key pairs based on real-name authentication and key distribution centers; The pseudo-name is blinded based on the long-term public key of the long-term key pair to obtain a blinded pseudo-name. Send a signature request for the blinded pseudonym to the key distribution center, and receive the blind signature returned by the key distribution center; Send a ticket authorization request to the key distribution center, including the pseudonym, the blind signature, and a temporary public key for the temporary key pair, so that the key distribution center can use the blind signature for verification and the temporary key pair for encryption and decryption; Receive the random session key and the ticket authorization ticket with the pseudonym as the subject from the key distribution center; Anonymous authentication is performed on the corresponding server by combining the random session key and the ticket authorization ticket.

2. The method according to claim 1, characterized in that, Receiving the random session key and the ticket authorization ticket with the pseudonym as the subject from the key distribution center, including: The blinded pseudonyms in the authorized negotiable instrument are deblinded to obtain the deblinding result; Determine whether the unblinding result corresponds to the pseudo-name; If so, it is determined that the blinded signature has not been tampered with, and the data pair consisting of the pseudo-name and the authorized bill is retained; Store the data pairs.

3. The method according to claim 1, characterized in that, The pseudonym is blinded based on the long-term public key of the aforementioned long-term key pair, resulting in a blinded pseudonym, including: Randomly generate an integer based on the long-term public key; The blinding factor is determined by combining the public key exponent of the long-term public key and the integer. The pseudo-names are filled in, and the blinding factor is used to blind the filled pseudo-names to obtain the blinded pseudo-names.

4. The method according to claim 1, characterized in that, Generating the pseudonym includes: Randomly generate strings; The pseudo-name is obtained by concatenating the string with the timestamp and then truncating it.

5. The method according to claim 1, characterized in that, Sending a signature request for the blinded pseudonym to the key distribution center includes: Generate a one-time random number; Add the blinded pseudonym and the one-time random number to the signature request; The signature request is sent to the authentication server of the key distribution center.

6. The method according to any one of claims 1 to 5, characterized in that, Anonymous authentication is performed on the corresponding server using the random session key and the ticket authorization ticket, including: Generate a new random number and determine the current timestamp; An authenticator is constructed by combining the random session key, the pseudonym, the new random number, and the current timestamp; The ticket authorization ticket, the authenticator, the target service, the new random number, and the current timestamp are sent to the ticket authorization server of the key distribution center; Receive response data from the ticket authorization server; The response data is decrypted using the random session key to obtain a symmetric key between the server and the target service. Verify the symmetric key; After successful verification, the symmetric key is used to communicate with the server corresponding to the target service.

7. An identity authentication method, characterized in that, Applications in key distribution centers include: Establish a long-term key pair with the client based on the client's real name; Receive a signature request for a blinded pseudonym sent by the client, and verify the signature request using the long-term key pair; The blinded pseudo-name is signed upon verification, and the blind signature is fed back to the client. Receive a ticket authorization request sent by the client, which includes the pseudonym, the blind signature, and the temporary public key of the temporary key pair; The blind signature is used to verify the authorization request of the bill. After the verification is successful, a bill authorization bill with the pseudo-name as the subject is constructed. The random session key and the ticket authorization ticket are fed back to the client; Receive the anonymous authentication request sent by the client in combination with the random session key and the ticket authorization ticket; The anonymous authentication request is verified, and if the verification is successful, the symmetric key between the client and the corresponding server is fed back to the client, so that the client can anonymously access the corresponding server based on the symmetric key.

8. The method according to claim 7, characterized in that, Verifying the authorization request for the negotiable instrument based on the blind signature includes: Verify whether the blind signature corresponds to the pseudo-name; If so, then the document authorization request is confirmed to have passed the signature verification. If not, then the document authorization request has failed the signature verification.

9. The method according to claim 7, characterized in that, Constructing a bill authorization document with the pseudonym as the subject includes: The pseudonym is identified as the subject of the authorized negotiable instrument; The server entity in the authorized invoice must be consistent with the core service account corresponding to the real name; Obtain a random session key and determine the random session key as the session key between the client and the ticket authorization server in the key distribution center; The session key is written into the encrypted portion of the ticket authorization ticket.

10. The method according to claim 9, characterized in that, The system returns a random session key and the ticket authorization ticket to the client, including: The random session key, the client's random number, and the current timestamp are packaged together to obtain packaged data; The packaged data is symmetrically encrypted using a symmetric key to obtain encrypted packaged data; The encrypted packaged data and the ticket authorization ticket are then fed back to the client.

11. The method according to any one of claims 7 to 10, characterized in that, The anonymous authentication request is verified, and if the verification is successful, the symmetric key between the client and the corresponding server is returned to the client, including: The random session key is obtained by decrypting the ticket authorization ticket in the anonymous authentication request using the public key of the random session key; The encrypted portion of the ticket authorization document is decrypted using the random session key to obtain a timestamp and a random number; The timestamp and random number are used to verify whether the anonymous authentication request is outdated; If not, then verify the pseudonym; After the pseudonym verification is successful, a new session key is generated with the corresponding server using the shared key; The client and the corresponding server's symmetric key are constructed using the new session key and the response server.

12. An identity authentication system, characterized in that, include: Clients and key distribution centers; The client performs the steps of the authentication method as described in any one of claims 1 to 6; The key distribution center performs the steps of the authentication method as described in any one of claims 7 to 11.

13. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the authentication method as described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the authentication method as described in any one of claims 1 to 11.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the authentication method as described in any one of claims 1 to 11.

Images