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

Abstract

The invention discloses an identity authentication method and system, an electronic device, a storage medium and a program product, and relates to the technical field of security. Only when a legal user is determined for the first time, a key distribution center knows a real name corresponding to a client, a subsequent signature, a bill authorization bill generation process and a subsequent anonymous access process to a corresponding server; in the embodiment of the invention, the clients initiate with the artifacts, so that the key distribution center and the corresponding server do not know the association relationship between the artifacts and the clients, and the privacy of the user is guaranteed.

Description

TECHNICAL FIELD

[0001] The present application relates to the security field, in particular to an identity authentication method and system, an electronic device, a storage medium and a program product. BACKGROUND

[0002] The core of Kerberos (a network identity authentication protocol based on tickets) authentication system is Key Distribution Center (KDC, key distribution center), which acts as a central authority in the system. Although Kerberos provides strong security for network communication, the centralized feature also brings the risk of privacy leakage.

[0003] Specifically, in Kerberos, the client always applies and uses tickets in plaintext to the KDC, TGS (ticket authorization server) and service in the form of a real entity (principal, real name), that is, the KDC and the service can be associated with a specific user through logs or tickets. Therefore, the identity of the user cannot be avoided.

[0004] To sum up, how to realize identity authentication in an identity authentication system is a technical problem that needs to be solved by those skilled in the art. SUMMARY

[0005] The present application provides an identity authentication method and system, an electronic device, a storage medium and a program product, which can realize identity authentication in an identity authentication system and protect user privacy.

[0006] The first identity authentication method provided by the present application is applied to a client and includes: establishing a long-term key pair based on a real name and a secret; performing blind processing on a pseudonym based on a long-term public key of the long-term key pair to obtain a blinded pseudonym; sending a signature request of the blinded pseudonym to a key distribution center and receiving a blind signature fed back by the key distribution center; sending a ticket authorization request including the pseudonym, the blind signature and a temporary public key of a temporary key pair to the key distribution center, so that the key distribution center performs signature verification using the blind signature and performs encryption and decryption using the temporary key pair; receiving a random session key and a ticket authorization ticket with the pseudonym as the subject fed back by the key distribution center; and performing anonymous authentication at a corresponding service by combining the random session key and the ticket authorization ticket.

[0007] The second identity authentication method provided in the application is applied to a key distribution center, and includes: establishing a long-term key pair based on a real name of a client and the client; receiving a signature request of a blinded pseudonym sent by the client, verifying the signature request by using the long-term key pair; in the case of verification, signing the blinded pseudonym and feeding back a blind signature to the client; receiving a ticket authorization request sent by the client and including a pseudonym, the blind signature and a temporary public key of a temporary key pair; verifying the ticket authorization request based on the blind signature, and after verification, constructing a ticket authorization ticket with the subject being the pseudonym; feeding back a random session key and the ticket authorization ticket to the client; receiving an anonymous authentication request sent by the client in combination with the random session key and the ticket authorization ticket; verifying the anonymous authentication request, and in the case of verification, feeding back a symmetric key of the client and a corresponding service end to the client, so that the client anonymously accesses the corresponding service end based on the symmetric key.

[0008] The identity authentication system provided in the application includes: a client and a key distribution center; the client performs the steps of the first identity authentication method; and the key distribution center performs the steps of the second identity authentication method.

[0009] The application further 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 identity authentication methods.

[0010] The application further provides a computer readable storage medium, and the computer readable storage medium stores a computer program, wherein the computer program is executed by a processor to implement the steps of any of the identity authentication methods.

[0011] The application further provides a computer program product, including a computer program, and the computer program is executed by a processor to implement the steps of any of the identity authentication methods.

[0012] In the application, the client and the key distribution center only establish a long-term key pair based on a real name in an initial stage, and in subsequent signature, construction of a ticket authorization request and subsequent identity authentication with a service end, are all based on a pseudonym, so as to protect user privacy.

[0013] Specifically, the client first establishes a long-term key pair with the key distribution center based on the real name. Then, the pseudonym is blinded based on the long-term public key of the long-term key pair to obtain a blinded pseudonym. A signature request of the blinded pseudonym is sent to the key distribution center. Since the blinded pseudonym is blinded based on the long-term key pair between the client and the key distribution center, the key distribution center can determine that a pseudonym is sent by a legal user verified and a signature is requested, at which time the key distribution center can sign the pseudonym and feed back a blind signature to the client. When the client needs a ticket authorization ticket, the client can send a ticket authorization request including the pseudonym, the blind signature and the temporary public key of the temporary key pair to the key distribution center. The key distribution center can verify the signature by using the blind signature, and can encrypt and decrypt by using the temporary key pair. After verification, it can be determined that the pseudonym is previously signed, at which time a ticket authorization ticket with the pseudonym as the subject can be generated, and the ticket authorization ticket and the corresponding random session key are sent to the client. When the client needs to access a target service, the client can request identity authentication from the key distribution center by combining the random session key and the ticket authorization ticket, thereby realizing anonymous access to the target service of the server.

[0014] Technical effects of the present application: Only when a legal user is first determined, the key distribution center knows the real name of the client. In the subsequent signature, ticket authorization ticket generation process, and subsequent anonymous access to the corresponding server process, the client initiates with a pseudonym, so the key distribution center and the corresponding server do not know the association between the pseudonym and the client, thereby protecting user privacy. BRIEF DESCRIPTION OF DRAWINGS

[0015] In order to more clearly illustrate the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0016] Figure 1 An implementation schematic diagram of a first identity authentication method provided by the embodiments of the present application; Figure 2 An implementation schematic diagram of a second identity authentication method provided by the embodiments of the present application; Figure 3 A structure schematic diagram of an identity authentication system provided by the embodiments of the present application; Figure 4 A general flow schematic diagram of an identity authentication method provided by the embodiments of the present application; Figure 5 A blind signature timing diagram of an identity authentication method provided by the embodiments of the present application; Figure 6A timing diagram of the anonymous ticket application phase of an identity authentication method provided in an embodiment of the present application; Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application; Figure 8 A schematic diagram of the specific structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0017] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

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

[0019] To facilitate understanding, the technical terms involved in the embodiments of the present application, namely the Kerberos protocol, core components and concepts are explained below.

[0020] Realm: Represents an administrative domain for authentication. Its purpose is to define the boundaries within which an authentication server is authorized to authenticate a user, host, or service. Essentially, a user / service belongs to a realm only if they share a secret (password / key) with that realm's authentication server.

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

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

[0023] Ticket: A ticket (or called a credential) is something that a client presents to an application server to prove that its identity is authentic. Tickets are issued by the authentication server and encrypted using the secret key of the service they are targeted at. Since this key is only shared between the authentication server and the server providing the service, not even the client requesting the ticket can know it or change its contents.

[0024] The main information in a ticket includes: 1, the principal of the requesting user (usually a username); 2, the principal of the service the ticket is targeted at; 3, the IP address of the client machine that can use the ticket. 4, the date and time when the ticket validity starts (in timestamp format); 5, the maximum lifetime of the ticket; 6, the session key.

[0025] Encryption: Kerberos often needs to encrypt and decrypt messages (tickets and authenticators) passed between the various participants in the authentication process. It is worth noting that Kerberos only uses symmetric key encryption (in other words, the same key is used for encryption and decryption).

[0026] KDC: The authentication server in a Kerberos environment, based on its ticket distribution function for accessing services, is called the Key Distribution Center, or simply KDC. Since it is completely located on a physical server (it usually corresponds to a process), it can be logically considered to be divided into three parts: the database, the authentication server (Authentication Server, AS), and the ticket granting server (Ticket Granting Server, TGS).

[0027] Among them, the database is a container of entries associated with users and services. A principal is used to refer to an entry, and a principal can also be used to refer to an entry. Each entry contains the following information: 1, the principal associated with the entry; 2, the encryption key; 3, the maximum validity period of the ticket associated with the principal; 4, the attributes or flags that describe the behavior of the ticket; 5, the expiration date of the password; 6, the expiration date of the principal, after which no ticket will be issued.

[0028] AS: It is a part of KDC that responds to the initial authentication request from the client, at which time the user has not been authenticated and must enter a password. In response to the authentication request, the AS issues a special ticket called the ticket granting ticket, or simply TGT, whose associated principal is krbtgt / REALM@REALM. If the user successfully authenticates, they can use the TGT to obtain other service tickets without having to re-enter the password.

[0029] Ticket Granting Server (TGS): The Ticket Granting Server issues service tickets to clients that possess a valid TGT, ensuring the authenticity of the identity in order to obtain the requested resource on the application server. The TGS can be considered as an application server (given that access to it requires the presentation of a TGT), which provides the issuance of service tickets as a service.

[0030] Session Key: The user and the service share a secret with the KDC. For the user, this secret is a key derived from their password, while for the service, this secret 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. The user also needs to share a key with the service, at least for the time the client has a work session open on the server: this key, generated by the KDC when issuing the ticket, is called the session key.

[0031] Authenticator: The client adds another packet (the authenticator) to the request containing the ticket, which contains the user principal and a timestamp (the time when), and is encrypted with the session key; the server that must provide the service, upon receiving this request, unpacks the first ticket, extracts the session key, and if the user is actually the person he / she says he / she is, the server is able to decrypt the authenticator, extracting the timestamp. If the latter differs from the server's time by less than 2 minutes (this tolerance can be configured), the authentication is successful. This highlights the criticality of synchronization between machines belonging to the same domain.

[0032] In the embodiments of the present application, the improved ideas of blind signature and temporary key are introduced, so that the KDC cannot know the real identity when the client requests the Kerberos ticket, and cannot infer the identity according to the log or other information.

[0033] The core idea is in the blind signature stage: the client indicates to the KDC that it is a legitimate user at first time, and makes the KDC do blind signature for a randomly generated anonymous credential (pseudo-name). Since the blind signature is introduced, the KDC cannot see the real anonymous credential of the client in the signature process, and thus does not know which user the credential corresponds to in the future.

[0034] In the anonymous ticket application stage: the client holds the anonymous credential after blind signature and the corresponding private key, and requests TGT from the KDC, only exposes the anonymous credential itself, and uses the temporary Diffie-Hellman (DH) key to protect the ticket transmission. After the KDC verifies the blind signature, the KDC issues the TGT with the anonymous credential as the principal to the client, without writing any information directly corresponding to the real identity into the log or the ticket.

[0035] In the standard Kerberos procedure phase: the client uses the resulting TGT to request a Service Ticket from the TGS, and then uses the Service Ticket to initiate an AP_REQ to the application server, during which the KDC only sees the anonymous credential and does not see the real username.

[0036] In order for those skilled in the art to better understand the scheme of the present application, the present application will be further described in detail below from different clients and key distribution centers in combination with the drawings and specific embodiments.

[0037] Please refer to Figure 1 The method is applied to a client and includes the following steps.

[0038] S101, a long-term key pair is established based on a real name and a key distribution center.

[0039] The long-term key pair can be represented as a public key PKKDC and a private key SKKDC. SK (Session Key) refers to a session key.

[0040] The long-term key pair can be used for blind signature on the blinded pseudo name in the subsequent process, and RSA algorithm can be used. The RSA algorithm, i.e. asymmetric encryption, is based on the difficulty of large integer prime factorization. Its key pair generation: select two large prime numbers p, q, calculate modulus ; select a public key exponent e that is coprime with φ(N); calculate a 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 whether σ e mod N is equal to H(M).

[0041] Specifically, the first authentication between the client and the KDC (only used once in Enrollment (blind signature phase), verifying the identity of the user).

[0042] The Kerberos AS_REQ process can be followed, or a normal Kerberos verification can be performed in Enrollment using a username+password. That is, this step mainly implements that the KDC establishes trust in the real name between the KDC and the client. For example, trust in alice@EXAMPLE.COM.

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

[0044] The pseudonym is a false name different from the real name. The pseudonym can be specified by a user or randomly generated in a client.

[0045] In an embodiment of the present application, the pseudonym is generated by randomly generating a character string, concatenating the character string with a timestamp, and then truncating 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 obtained, and then truncated to a proper length (such as 128 or 160 bits). P is regarded as a large integer (padded to the same length as N (KDC RSA The modulus of the public key). For example, after padding according to PKCS#1 v1.5, an integer m is obtained.

[0046] Blind processing, that is, the pseudonym is masked so that the key distribution center signer signs without knowing the original text.

[0047] After the pseudonym is blindly processed, it is referred to as a blinded pseudonym.

[0048] In an embodiment of the present application, the pseudonym is blindly processed based on a long-term public key of a long-term key pair to obtain a blinded pseudonym, including: randomly generating an integer based on the long-term public key; determining a blind factor by combining a public key exponent of the long-term public key and the integer; padding the pseudonym, and blindly processing the padded pseudonym by using the blind factor to obtain the blinded pseudonym.

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

[0050] The blind factor is calculated as , where e is the public key exponent of the KDC RSA , and mod represents a modulus operation.

[0051] The blinded pseudonym is calculated as : , where m is the padded integer corresponding to the pseudonym of the client.

[0052] In S103, a signature request of the blinded pseudonym is sent to the key distribution center, and a blinded signature fed back by the key distribution center is received.

[0053] The blinded signature refers to blind processing of a message, and a signer signs without knowing the original text, and a receiver obtains a valid signature of the original text by blinding. The blinded signature can be used for anonymous credentials, and a user can obtain a certificate of approval of a signer without exposing the content of the certificate.

[0054] The implementation process of the blinded signature includes that a user generates a message M and a blind factor r, and calculates a blind text ;The signatory Perform a regular signature and return a blind signature result. The user uses r to deblind the original M and obtain a signature on it. The signer never knows the contents of M, ensuring that the message and the signer are unlinkable. Implementation algorithms include RSA blind signatures and elliptic curve-based blind signature schemes.

[0055] In a specific embodiment of the present application, sending a blinded pseudonym signature request 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. (i.e. the content to be signed The blinded result) is sent to the KDC along with the one-time random number Nonce1 (N1, to prevent replay). The message content is as follows: Msg_Enroll_REQ = { MessageType: ENROLL_BLIND_REQ, BlindData: , Nonce1: N1, ProofOfIdentity: <credentials completed using native Kerberos authentication (e.g. AS_REQ)> …. }.

[0056] In this embodiment, the Proof of Identity link here can allow the KDC to verify that it is indeed a legitimate user during enrollment, that is, the client must first run a standard Kerberos AS_REQ verification before the KDC accepts it. That is, the KDC only sees , it doesn't know which P this corresponds to and therefore cannot associate P with any real username.

[0057] After sending a signature request to the key distribution center, you can receive a blind signature from the key distribution center. Then, by unblinding the blind signature, you can get P's signature.

[0058] After the signature is verified, the client retains the pair (P,σ) and does not send it to the KDC again with the real user. The client can store (P,σ) securely locally, delete the intermediate blinding data and random number. The KDC never knows the unblinded P and does not store any mapping information; the client only keeps it locally. , which will be used as "anonymous credentials" when asking for TGT later. At this point, the KDC (authentication center) knows that "this client identity is legitimate" and "has signed a certain blinding value given by it", but the KDC does not know which P the blinding value is unblinded to.

[0059] Wherein, the RSA blind signature, its purpose: let the signer sign the message after blinding, do not know which message he signed. The specific implementation process includes: blinding: the user selects a blind factor r, generates , and then calculates the blind signature: ; Blind signature: the signer uses the private key d to sign ; Unblinding: the client calculates , and gets the legal signature of the original m . In this way, the signer can confirm that the message has been authorized, and cannot associate the signature with the original message, protecting user privacy.

[0060] In this embodiment, the signature can be represented as , or as (P, σ), and σ corresponds to the signature.

[0061] S104, send a ticket granting request including the pseudonym, the blind signature, and the temporary public key of the temporary key pair to the key distribution center, so that the key distribution center verifies the signature by using the blind signature, and performs encryption and decryption by using the temporary key pair.

[0062] After the client gets , in preparation for asking for a ticket granting ticket TGT (Ticket-Granting Ticket), a pair of temporary Diffie-Hellman key pairs (ga, a) can be generated, wherein g a is the Diffie-Hellman public key of the client, and a is the Diffie-Hellman private key of the client.

[0063] Then, the client sends the pseudonym P (plaintext), the blind signature σ of the KDC to the pseudonym P, and the Diffie-Hellman public key g a of the client to the key distribution center KDC.

[0064] That is, in the TGT asking stage, the client no longer uses the real username, but only carries (P, σ) and the one-time Diffie-Hellman public key to ask the KDC for the TGT. The KDC verifies the signature, and if the signature is legal, issues a TGT that is only bound to P. The KDC never knows which user it is throughout the process.

[0065] ​The client constructs an anonymous TGTREQ, and generates a temporary DH key pair: selects a secure DH group, generates a local random private key a, and calculates the corresponding public key g a , and g a are recorded as DHC. The TGT_Request message element is constructed, including: pseudonym P, KDC signature , which has been unblinded and can be directly verified, and the client DH public key DHC = ga, and a new random number (prevent request replay). Pack these contents with the necessary Kerberos fields: Msg_TGT_REQ = { MessageType: ANON_TGT_REQ, Pseudonym: P, SignatureSigma: σ, DH_Public: DHC = ga, Nonce2: N2 …. }.

[0066] At this time, the client no longer transmits any real username and does not need to carry any long-term symmetric key. The KDC only sees in the log that the client requests a TGT with P and signature σ, DH public key g a , and does not know the corresponding real name, such as alice@EXAMPLE.COM.

[0067] S105, receiving the random session key and the ticket-granting ticket with the subject as the pseudonym fed back by the key distribution center.

[0068] After receiving the ticket-granting request, the KDC can verify the signature using blind signature, perform encryption and decryption based on the temporary key pair, construct the ticket-granting ticket based on the pseudonym, and feed back the ticket-granting ticket.

[0069] The client can receive the random session key and the ticket-granting ticket with the subject as the pseudonym fed back by the key distribution center. In this way, the client obtains the random session key and the ticket-granting ticket based on the pseudonym.

[0070] In a specific embodiment of the present application, receiving the random session key and the ticket-granting ticket with the subject as the pseudonym fed back by the key distribution center includes: unblinding the blinded pseudonym in the ticket-granting ticket to obtain an unblinded result; determining whether the unblinded result corresponds to the pseudonym; if yes, determining that the blinded signature has not been tampered with, and retaining the data pair formed by the pseudonym and the ticket-granting ticket; and storing the data pair. That is, the client can obtain the random session key and the ticket-granting ticket TGT with the subject as P after unblinding the DH encryption.

[0071] Where TGT: ; KDC -> Client: When the client receives , it unblinds it with its own r: Here m is the integer after PKCS#1 padding is done on p. The client verifies that σ is the correct signature of m by KDC (with PK KDC verification) to ensure that the signature is not tampered: Should be equal to the original padded m.

[0072] The client decrypts to get , at this point the client has the TGT for principal P and the session key to communicate with the TGS, completing the anonymous TGT request. At this point the KDC does not know who P corresponds to because it did not know what P was when it did the blind signature during Enrollment. It only saw that (P, σ) were both legal -> issue TGT to P without any record of P corresponding to a real name like alice@EXAMPLE.COM.

[0073] S106, combining the random session key and the ticket authorization ticket to perform anonymous authentication at the corresponding service end.

[0074] The client requests a service ticket from the TGS, thereby realizing anonymous authentication and communication with the corresponding service end.

[0075] In a specific embodiment of the present application, anonymous authentication at the corresponding service end is combined with the random session key and the ticket authorization ticket, including: generating a new random number, determining a current timestamp; combining the random session key, the pseudonym, the new random number, and the current timestamp to construct an identity verifier; sending the ticket authorization ticket, the identity verifier, the target service, the new random number, and the current timestamp to the ticket authorization server of the key distribution center; receiving the response data fed back by the ticket authorization server; decrypting the response data using the random session key to obtain the symmetric key between the target service; verifying the symmetric key; after verification, using the symmetric key to communicate with the service end corresponding to the target service.

[0076] In the process of anonymous authentication of the application and the service end of the target service, the client can obtain and the TGT after the client constructs a TGSREQ of the standard Kerberos. Specifically, the client can generate a new random number Nonce4 (N4) and a current timestamp T4, and construct an identity verifier : .

[0077] Then, the information Msg_TGS_REQ = { MessageType: TGS_REQ, Ticket: <the TGT obtained in the previous step (wherein TGT.cname = P)>, Authenticator: Auth_tgs, SName: <the target service S@REALM>, Nonce4: N4, Timestamp4: T4, .... } is sent to the TGS.

[0078] Then, the client receiving the feedback of the TGS obtains the symmetric key between the client and the target service, and communicates with the service corresponding to the target service based on the symmetric key.

[0079] In the present application, the client and the key distribution center establish a long-term key pair based on the real name in the initial stage, and in the subsequent signature, construction of the ticket authorization request and the subsequent anonymous authentication with the service end, all are based on the pseudonym, so as to protect the user privacy.

[0080] Specifically, the client first establishes a long-term key pair with the key distribution center based on the real name. Then, the pseudonym is blind processed based on the long-term public key of the long-term key pair, and the blind pseudonym is obtained. The signature request of the blind pseudonym is sent to the key distribution center. Since the blind pseudonym is blind processed based on the long-term key pair between the client and the key distribution center, the key distribution center can clearly know that a pseudonym is sent by a legal user who passes the verification, at this time, the key distribution center can sign the pseudonym and feed back the blind signature to the client. When the client needs a ticket authorization ticket, the client can send a ticket authorization request including the pseudonym, the blind signature and the temporary public key of the temporary key pair to the key distribution center. The key distribution center can verify the signature by using the blind signature, and can encrypt and decrypt by using the temporary key pair. After passing the verification, the key distribution center can determine that the pseudonym is previously signed, at this time, the key distribution center can generate a ticket authorization ticket with the pseudonym as the subject, and send the ticket authorization ticket and the corresponding random session key to the client. When the client needs to access a target service, the client can request anonymous authentication from the key distribution center by combining the random session key and the ticket authorization ticket, so as to realize anonymous access to the service end of the target service.

[0081] The technical effects of the application are as follows: only when a legal user is determined for the first time, the key distribution center knows the real name of the client; in the subsequent signature, ticket authorization ticket generation process, and subsequent anonymous access to the corresponding server process, the client initiates with a pseudonym, so that the key distribution center and the corresponding server do not know the association between the pseudonym and the client, thereby protecting the user privacy.

[0082] Please refer to Figure 2 , applied to the key distribution center, the identity authentication method comprises the following steps.

[0083] S201, based on the real name of the client and the client to establish a long-term key pair.

[0084] This embodiment is an identity authentication method described from the perspective of the key distribution center, which corresponds to the identity authentication method described from the perspective of the client. Similar or same steps are not described in detail.

[0085] S202, receiving the signature request of the blinded pseudonym sent by the client, and verifying the signature request by using the long-term key pair.

[0086] S203, in the case of verification, signing the blinded pseudonym and feeding back the blind signature to the client.

[0087] In a specific embodiment of the application, signing the blinded pseudonym comprises: using the private key in the long-term key pair to sign the blinded pseudonym in the signature request.

[0088] After the KDC receives the signature request, the KDC uses its own RSA private key SK KDC directly signs the blinded message: , wherein d is the private key index of the KDC RSA.

[0089] The KDC returns a message to the client: Msg_Enroll_REP = { MessageType: ENROLL_BLIND_REP, BlindSignature: Nonce1Response: N1, / / corresponding to Nonce1 sent by the client … }.

[0090] That is, the KDC does not store the P plaintext anywhere, it can only know that a certain legal user submits a and signs it, but it does not know what pseudonym P will be obtained after unblinding.

[0091] S204, receiving a ticket authorization request sent by the client and including the pseudonym, the blind signature and the temporary public key of the temporary key pair.

[0092] S205, verifying the ticket authorization request based on the blind signature, and constructing a ticket authorization ticket with the principal being the pseudonym after verification.

[0093] In the embodiments of the present application, verifying the ticket authorization request based on the blind signature comprises: verifying whether the blind signature corresponds to the pseudonym; if yes, determining that the ticket authorization request passes the verification; if no, determining that the ticket authorization request fails the verification. That is, verifying the blind signature, that is, determining whether the signature is the signature made before, to ensure that the signature is not tampered with. For example, KDC verifies (P, σ), that is, verifies whether σ is If the verification fails, it is directly rejected and an error is returned; if the verification succeeds, a ticket authorization ticket with the principal being the pseudonym is constructed.

[0094] In a specific embodiment of the present application, constructing the ticket authorization ticket with the principal being the pseudonym comprises: determining the pseudonym as the principal of the ticket authorization ticket; the server principal in the ticket authorization ticket remains 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 ticket authorization server in the key distribution center; and writing the session key in the encrypted part of the ticket authorization ticket.

[0095] Specifically, KDC constructs TGT: the principal (Client Principal) of TGT is set to ; the ServerPrincipal (server principal) of TGT is still krbtgt / REALM (core service account).

[0096] TGT.enc-part (encryption) part: , wherein is the symmetric key shared between KDC and TGS, AuthTime (authentication time), EndTime (expiration time), etc. can refer to the Kerberos protocol.

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

[0098] S206, feeding back the random session key and the ticket authorization ticket to the client.

[0099] That is, feeding back the random session key and the ticket authorization ticket to the client, which can also be fed back by encryption to avoid data leakage.

[0100] In one specific embodiment in the present application, the client is fed back with a random session key and a ticket authorization ticket, including: packing the random session key, the random number of the client and the current timestamp to obtain packed data; symmetrically encrypting the packed data by using a symmetric key to obtain encrypted packed data; and feeding back the encrypted packed data and the ticket authorization ticket to the client.

[0101] Wherein, the symmetric encryption refers to that the sender and the receiver share the same key, the key is used to encrypt the plaintext, and the same key is used to decrypt the ciphertext. The encryption and decryption speed is fast, and is suitable for real-time protection of large data.

[0102] Specifically, the KDC generates its own DH private key X and the corresponding public key gx, so as to do DH key exchange with the client: a random number Nonce1 of the KDC is selected, and the DH shared key D is calculated as .

[0103] The KDC calculates the shared key D : , and the client calculates the shared key as , the KDC randomly generates a new client-TGS session key , which is used for subsequent communication.

[0104] The KDC constructs the encrypted response for the client: in addition to sending the above TGT to the client without change, the key used for the client to decrypt is encrypted by the shared key and then sent to the client. Specifically: the KDC-generated is first packed with the Nonce2 of the client and the current timestamp T3: , to obtain packed data.

[0105] The above Payload is symmetrically encrypted (such as AES-CBC+MAC) by using the symmetric key . In this way, the client can calculate the DH_shared by using the DH private key σ after receiving, and then decrypt C to obtain .

[0106] The message returned by the KDC to the client is as follows: Msg_TGT_REP = { MessageType: ANON_TGT_REP, TGT: <complete Kerberos TGT object, wherein cnmae=P>, DH_Pub_KDC: (g x ),​ EncryptedPart: C = …, Nonce3: N3 }。

[0107] wherein, DH_Pub_KDC = g x , the client receives and can do DH with the previous DH_Public = g a , to obtain the same .

[0108] S207, receiving an anonymous authentication request sent by the client in combination with the random session key and the ticket authorization ticket.

[0109] S208, verifying the anonymous authentication request, and feeding back the symmetric key of the client and the corresponding service end to the client in case of verification, so that the client anonymously accesses the corresponding service end based on the symmetric key.

[0110] In the process of processing the anonymous authentication request sent by the client, the processing process can refer to the processing flow corresponding to the real-name authentication request, that is, the pseudonym is equivalent to the real name.

[0111] In a specific embodiment of the present application, verifying the anonymous authentication request, and feeding back the symmetric key of the client and the corresponding service end to the client in case of verification, comprises: decrypting the ticket authorization ticket in the anonymous authentication request using the public key of the random session key, obtaining the random session key; decrypting the encrypted part in the ticket authorization ticket using the random session key, obtaining the timestamp and the 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 passed, generating a new session key with the corresponding service end using the shared key; constructing the symmetric key of the client and the corresponding service end using the new session key and the response server.

[0112] In this embodiment, the TGS operation is performed (the TGS shares K TGS with the KDC). Specifically, the TGS decrypts TGT.enc-part using K TGS , obtains K c-TGS , decrypts Authentica using K c-TGS , obtains (P || T4 || N4 ), and verifies whether the timestamp T4 and the nonce N4 are fresh (i.e., whether they are outdated / overdue).

[0113] After the pseudonym P is verified, the TGS generates a new session key Kc-s using the shared key Key S (shared with the service S).

[0114] constructing a Service Ticket: ST = { tkt-vno: 5, realm: REALM, sname: S@REALM, / / Service segment body cname: P, / / Still anonymous pseudonym P }.

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

[0116] TGS returns: Msg_TGS_REP = { MessageType: TGS_REP, Ticket: ST, EncPartToClient: Nonce_TGS: N5 }.

[0117] After receiving the Decrypt EncPartToClient and get as well as After verification, you can start communicating with the application server S.

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

[0119] structure .

[0120] Send the ServiceTicket (ST) and Authenticator to S: Msg_AP_REQ = { MessageType: AP_REQ, Ticket: ST, / / ST.cname = P Authenticator: Auth_cS, Nonce6: N6, Timestamp6: T6, … }.

[0121] Application server S uses the shared Decrypt ST.enc-part to get , then use Decrypt Authenticator and get .

[0122] S verifies the pseudonym P and the session key Once the timestamp matches and is valid, a secure session can be established with the client. Throughout the entire process, the application server only sees P and has no idea that alice@EXAMPLE.COM is behind it.

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

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

[0125] The embodiments of the present application further provide an identity authentication system, in which the steps of the above-mentioned identity authentication method can be implemented.

[0126] Please refer to Figure 3 The identity authentication system includes: a client 101 and a key distribution center 201; the client executes the following Figure 1 The steps of the identity authentication method shown in FIG. 1 are as follows: Figure 2 steps of the identity authentication method.

[0127] In this identity authentication system, Figure 4 The steps described in the above method embodiment can be implemented, and the method is described in detail below based on different stages.

[0128] like Figure 5 As shown in the figure, in Phase 1: Blind Signature Phase (Enrollment), the client (User) knows the "real identity" (e.g., alice@EXAMPLE.COM) and shares a long-term password with the KDC. The client generates a random pseudonym P = 256-bit hash value (or longer) locally and blinds it, then sends a request to the KDC: "Legal user, please sign the blinded pseudonym." After the KDC deblinds the "blinded data," it returns a blind signature (BlindSignature). The client deblinds and obtains the corresponding Real signature During this process, the KDC only knows that "an authenticated user sent a blinded value", but never knows the real identity used by the client (alice@EXAMPLE.COM), so it cannot retain any "P ↔ alice@EXAMPLE.COM" mapping.

[0129] Among them, the hash algorithm (digest algorithm), which calculates a fixed-length digest for an input message of any length, has one-way properties: the original text cannot be inferred from the digest; collision resistance: it is difficult to find different messages with the same digest; fixed-length output: no matter how long the input is, the output length is consistent.

[0130] Please refer to Figure 6 Phase 2: Anonymous Ticket Application (Anonymous TGT_Request). The Key Distribution Center (KDC) verifies whether the blind signature σ is valid for P (using the public key system). If the signature verification passes, it means that the "registered user" has a valid signature certificate and is granted a new TGT. At this time, when constructing the TGT, the KDC sets the TGT subject (Client_Principal) to P (the pseudonym mentioned above) and uses the shared key between the KDC and the TGS. Encrypt the enc-part of the TGT.

[0131] Since there is no shared long-term key between the client's P and KDC (because KDC does not know who the client is now, it cannot take out the symmetric key that originally belonged to the client), KDC needs to implicitly include the "TGT decryption material" given to the client in a key that is consistent with the client's DH public key. In other words, the KDC selects a random session key. , as the session key between the client and TGS, and write it into the enc-part (encrypted part) of the TGT; at the same time, the KDC uses the 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 together with the TGT.

[0132] Phase 3: Standard Kerberos TGS_Request and AP_Request, the client obtains a random session key , can be used to request a Service Ticket from TGS like a normal Kerberos client. TGS generates a service ticket for the pseudonym p for the client to communicate with the target server. Session key , use the enc-part of the Service Ticket encryption( It is a long-term symmetric key between KDC and S). The subject of the Service Ticket itself is also p. The client decrypts it after receiving it. , and performs AP_REQ with the server S (also a standard Kerberos process). At this time, the "client principal" seen by the server is P, and it does not know the real identity behind it.

[0133] As can be seen, the method steps described in the above embodiment of the identity authentication system can achieve identity authentication without the KDC knowing the identity of the user. Specifically, since the KDC never sees the real name during enrollment, and the client blinds the pseudo-P, the KDC directly blinds the blinded P. The KDC only sees the blinded P and does not know the true P. Blind signatures theoretically ensure that the signer (KDC) cannot access the original message content during the signing process. Therefore, the KDC's internal database only records "signed for a blinded entity" and never stores the P or its mapping to the real user.

[0134] The client obtains (P,σ) only after unblinding, and the KDC cannot reversely infer who P is when it encounters σ.

[0135] σ is just the signature result of KDC on P, but in the blind signature process, KDC does not know which P is signing. Because the blinding factor is unavailable, the original P cannot be recovered from this pair. Therefore, for the KDC, "after the blind signing phase, there is no usable information about P" -> it can no longer infer the original P from the σ sent by the client during the TGT_Request. This completely eliminates the KDC's ability to know "who a particular P is."

[0136] Subsequent communications (TGS and application server) also only show P but not the real user name.

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

[0138] In this way, even if someone gets a Service Tickeet in the middle, they will only see "pseudonym = P" and it will be impossible to reversely infer the real identity.

[0139] In summary, as long as the KDC blindly signs P, the mapping between P and the real user cannot be inferred, and the subsequent process will not know which real user is involved. This solution theoretically achieves the goal of preventing the KDC and application server nodes from obtaining or inferring the user's true identity.

[0140] In addition, if the application is completely used with symmetric key That is, the client shares a long-term symmetric key with the KDC, the KDC must know which key belongs to which username at the beginning, and the KDC uses the symmetric key to decrypt when checking the ticket: this makes the KDC connect "symmetric key" <-> "alice@example.com" easily afterwards, and the anonymity cannot be established.

[0141] Therefore, the client identity must be completely separated from the subsequent credential request. The blind signature stage makes the KDC know which pseudonym is signed even if the signature is made; the DH stage makes the "session key" sent by the KDC to the client not need to use the symmetric key system, but is temporarily negotiated with the client in the request.

[0142] After the combination of the two steps, the two responsibilities of the KDC are separated, that is, Enrollment: the KDC verifies that the request is legal and signs a blinded value carried in the request, but does not know what the value is after unblinding. Issue TGT: the KDC only issues a ticket for a pseudonym P according to "legal blind signature + client temporary DH", and transmits the session key to the client through DH.

[0143] From the perspective of key science, the combined scheme is effective in "anonymous credentials": blind signature ensures that the signer (KDC) does not know the signature content when signing; DH ensures that the session key can only be shared by the client / server, even if the KDC does not know the identity, the session key can be safely transmitted to the other party.

[0144] Therefore, the technical effect of the application is: the application realizes that the KDC does not know who when issuing the ticket, and cuts off the association between the identity and the authentication token. The effect of anonymity is achieved. Even if someone obtains a certain ticket, only sees the pseudonym P and the temporary session key, it is impossible to track back to the real username. Due to the blind signature process, unless the "blinding factor r" stored locally by the client is disclosed to the KDC, the KDC cannot track back P in the future. Diffie-Hellman ensures that "the session key K_(c-TGS) is only derived in the current session and is not associated with the long-term key of the KDC".

[0145] Corresponding to the above method embodiment, the application embodiment also provides an electronic device, and the electronic device described below can be mutually corresponding and referred to with the identity authentication method described above.

[0146] Referring to Figure 7 As shown in the figure, 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 identity authentication method of the above method embodiment.

[0147] The electronic device can be a client or a server corresponding to the KDC.

[0148] In particular, refer to Figure 8 The electronic device can have a large difference due to different configurations or performances, and can include one or more processors (central processing units, CPUs) (for example, one or more processors) and a memory 332 storing one or more computer programs 342 or data 344. The memory 332 can be temporary storage or persistent storage. The programs stored in the memory 332 can include one or more modules (not shown in the figure), and each module can include a series of instruction operations in the data processing device. Further, the processor 322 can be configured to communicate with the memory 332 and execute a series of instruction operations in the memory 332 on the electronic device 301.

[0149] The electronic device 301 can 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.

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

[0151] Corresponding to the above method embodiments, the embodiments of the present application also provide a readable storage medium. The readable storage medium described below can be correspondingly referred to the identity authentication method described above. The embodiments of the present application also provide a computer readable storage medium, and the computer readable storage medium stores a computer program, wherein the computer program is set to execute the steps in any of the above identity authentication method embodiments when running.

[0152] In an exemplary embodiment, the above computer readable storage medium can include, but is not limited to: a U disk, a read-only memory (Read-Only Memory, ROM), a random access memory (Random Access Memory, RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs.

[0153] The embodiments of the present application also provide a computer program product, and the above computer program product includes a computer program, and the computer program is executed by a processor to implement the steps in any of the above identity authentication method embodiments.

[0154] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned identity authentication method embodiments are implemented.

[0155] Those skilled in the art may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the composition and steps of each example according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

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

Claims

1. An identity authentication method, characterized in that: Applied to the client, including: Establish a long-term key pair based on real name and key distribution center; Blinding the 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 fed back by the key distribution center; Sending a ticket authorization request including the pseudonym, the blind signature, and the temporary public key of the temporary key pair to the key distribution center, so that the key distribution center can verify the signature using the blind signature and perform encryption and decryption using the temporary key pair; receiving a random session key and a ticket authorization ticket with the pseudonym as the subject fed back by the key distribution center; Anonymous authentication is performed on the corresponding service end in combination with the random session key and the ticket authorization ticket.

2. The method according to claim 1, characterized in that Receiving the random session key fed back by the key distribution center and the ticket authorization ticket with the subject being the pseudonym, including: Unblinding the blinded pseudonym in the bill authorization bill to obtain an unblinding result; Determining whether the unblinding result corresponds to the pseudonym; If yes, it is determined that the blinded signature has not been tampered with, and the data pair consisting of the pseudonym and the ticket authorization ticket is retained; The data pair is stored.

3. The method according to claim 1, characterized in that Blinding the pseudonym based on the long-term public key of the long-term key pair to obtain a blinded pseudonym, 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; The pseudonym is padded, and the padded pseudonym is blinded using the blinding factor to obtain the blinded pseudonym.

4. The method according to claim 1, wherein Generating the pseudonym includes: Generate a random string; The character string and the timestamp are concatenated and then intercepted to obtain the pseudonym.

5. The method according to claim 1, wherein Sending a signature request for the blinded pseudonym to the key distribution center includes: Generate a one-time random number; Adding the blinded pseudonym and the one-time random number to the signature request; Send the signature request to the identity verification server of the key distribution center.

6. The method according to any one of claims 1 to 5, characterized in that Performing anonymous authentication on the corresponding server by combining the random session key and the ticket authorization ticket includes: Generate a new random number and determine the current timestamp; constructing an authenticator by combining the random session key, the pseudonym, the new random number, and the current timestamp; Sending the ticket-granting ticket, the authenticator, the target service, the new random number, and the current timestamp to a ticket-granting server at the key distribution center; Receive response data fed back by the ticket authorization server; Decrypting the response data using the random session key to obtain a symmetric key between the target service and the target service; Verifying the symmetric key; After the verification is passed, the symmetric key is used to communicate with the server corresponding to the target service.

7. An identity authentication method, characterized in that: Applicable to key distribution centers, including: Establish a long-term key pair with the client based on the client's real name; Receive a blinded pseudonymous signature request sent by the client, and verify the signature request using the long-term key pair; In the case of verification, signing the blinded pseudonym and feeding back the blind signature to the client; receiving a ticket authorization request sent by the client, including a pseudonym, the blind signature, and a temporary public key of a temporary key pair; Verifying the bill authorization request based on the blind signature, and constructing a bill authorization bill with the pseudonym as the subject after verification; Feedback a random session key and the ticket-granting ticket to the client; receiving an anonymous authentication request sent by the client in combination with the random session key and the ticket-granting ticket; The anonymous authentication request is verified, and if the verification passes, 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 ticket authorization request based on the blind signature includes: Verifying whether the blind signature corresponds to the pseudonym; If yes, it is determined that the ticket authorization request passes the signature verification; If not, it is determined that the ticket authorization request fails the signature verification.

9. The method according to claim 7, characterized in that Constructing a bill authorization bill with the pseudonym as the subject, including: determining the pseudonym as the subject of the bill authorization bill; The server principal in the ticket authorization ticket remains consistent with the core service account corresponding to the real name; Obtaining a random session key, and determining the random session key as a session key between the client and the ticket authorization server in the key distribution center; The session key is written in the encrypted portion of the ticket granting ticket.

10. The method according to claim 9, characterized in that Feedback of a random session key and the ticket-granting ticket to the client includes: Packing the random session key, the random number of the client and the current timestamp to obtain packaged data; symmetrically encrypting the packaged data using a symmetric key to obtain encrypted packaged data; Feedback the encrypted packaged data and the ticket authorization ticket to the client.

11. The method according to any one of claims 7 to 10, characterized in that Verifying the anonymous authentication request and, if the verification is successful, feeding back to the client the symmetric key between the client and the corresponding server, including: Decrypting the ticket authorization ticket in the anonymous authentication request using the public key of the random session key to obtain the random session key; Decrypting the encrypted portion of the ticket authorization ticket 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 passed, a new session key is generated with the corresponding server using the shared key; The new session key and the response server are used to construct a symmetric key between the client and the corresponding server.

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

13. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the identity authentication method according to any one of claims 1 to 11 when executing the computer program.

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 identity authentication method according to 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, the steps of the identity authentication method according to any one of claims 1 to 11 are implemented.

Images