Design and analysis of authentication protocol of identity authentication system

Abstract Authentication protocol is the most critical part of identity authentication system. Research and analysis of system authentication protocol are necessary conditions to ensure secure network communication. . Kerberos is a typical authentication protocol that uses a dedicated server for unified identity authentication and authority management. However, due to the original use environment, the public key system was not used, which affected the scalability and manageability of the system. This article describes the design idea of ??an identity authentication system authentication protocol, uses public keys to improve the Kerberos protocol, and uses BAN logic to analyze the security of the protocol. Keywords identity authentication, authentication protocol

Authentication protocol is the most critical part of the identity authentication system, which directly affects system efficiency, security, etc. Kerberos is a typical authentication protocol that uses a dedicated server for unified identity authentication and authority management. However, due to the original use environment, the public key system was not used, which affected the scalability and manageability of the system. This article describes the design idea of ??an authentication protocol for an identity authentication system, uses public keys to improve the Kerberos protocol, and uses BAN logic to prove that the protocol is highly secure. 1 Kerberos protocol analysis Kerberos is a typical network security authentication protocol, which uses symmetric keys to accurately authenticate client/server applications. Kerberos mainly provides an authentication mechanism for open systems that provides trusted third-party services for network communications. Whenever a user (Client) applies for the service of a certain service program (Server), the user and the service program will first ask Kerberos to authenticate each other's identity. Authentication is based on the trust of the user and the service program in Kerberos. When applying for authentication, both Client and Server can be regarded as users of the Kerberos authentication service. To distinguish them from users of other services, Kerberos refers to users and servers collectively as participants (Principle). Therefore, Principle can be either a user or a service. The relationship between the authentication parties and Kerberos is shown in Figure 1. Figure 1 Authentication relationship between Kerberos When a user logs in to the workstation, Kerberos performs initial authentication on the user. Users who pass the authentication can receive corresponding services throughout the login period. Kerberos neither relies on the terminal through which the user logs into the system, nor on the security mechanism of the service requested by the user. It relies on the authentication service it provides to complete the authentication of the user. Timestamp technology is used to resist possible replay attacks (Replay Attack). Kerberos establishes and saves a database of the name of each participant in this network domain and its private key, so that only the participant and the Kerberos database have the participant's private key. Using private keys, Kerberos can authenticate participants. In addition, Kerberos will also randomly generate a session key to encrypt the specific content of the communicating parties. Kerberos has the following limitations: 1) The original authentication service may be stored or replaced. Although the timestamp is specifically used to prevent replay attacks, it may still be effective within the validity period of the ticket, assuming that it is within a Kerberos authentication domain. All clocks are kept synchronized, and the message is considered new if the time when the message is received is within the specified range (assuming the specified value is 5 minutes). In fact, the attacker can prepare the forged message in advance and issue the forged ticket as soon as he gets the ticket. It is difficult to detect it within 5 minutes. 2) The correctness of the authentication ticket is based on the synchronization of all clocks in the network. If the host's time is wrong, the original authentication ticket may be replaced. Because most network time protocols are insecure, this can cause extremely serious problems in distributed computer systems. 3) Kerberos' ability to prevent password guessing attacks is very weak. Attackers can collect a large number of tickets through long-term monitoring and guess passwords through calculation and key analysis. When the password chosen by the user is not strong enough, password guessing attacks cannot be effectively prevented. 4) The secret shared by the Kerberos server and the user is the user's password. The server does not verify the user's authenticity when responding, but assumes that only legitimate users have the password. If an attacker records application response messages, it is easy to form a codebook attack. 5) In fact, the most serious attacks are malware attacks. The Kerberos authentication protocol relies on the absolute trustworthiness of the Kerberos software, and attackers can replace all users' Kerberos software with software that executes the Kerberos protocol and records user passwords to achieve the purpose of attack. Generally speaking, cryptographic software installed on insecure computers will face this problem. 6) In a distributed system, certification centers are dotted all over the place, and the number of session keys between domains is staggering. Key management, distribution, and storage are all serious problems.

2 Preliminary Design of Authentication Protocol Kerberos avoided using the public key system in its initial design because some conditions for applying the public key system were not fully mature at that time. However, with the passage of time and the advancement of technology, some conditions for using the public key system have been or are being met. Especially from the perspective of future development, it is a trend to integrate the public key system into the existing system. . From the analysis of the limitations of Kerberos, we can see that many of its flaws are caused by the use of symmetric key technology alone. If public key technology can be organically integrated into Kerberos, its shortcomings such as weak confidentiality and poor scalability can be overcome. Based on this consideration, an authentication protocol is designed here. In this protocol, the "*** shared variable" N representing the number of user visits is used to prevent replay.

Symbol representation description: ◆CA: Certification Center; ◆AA: Authentication Agent (Authentication Agent) ; ◆C: Client’s unique identifier; ◆S: Application server’s unique identifier; ◆PRIx: X’s private key; ◆PUBx: X’s public key; ◆CERTc: C’s certificate serial number; ◆( Info)SIGNx: Use X's private key to sign the information Info; ◆(Info)ENCpubx: Use X's public key to encrypt Info; ◆(Info)K: Use symmetric key K to encrypt Info; ◆Ts: The authentication agent is A ticket issued when user C accesses server S; ◆Nc: an integer saved by client C, recording the number of user visits; ◆Ns: the number of user visits saved by application server S, used to prevent replay; ◆N: protocol message The integer used in to prevent replay, its value is determined by Nc, which is called "synchronization variable" here. The specific workflow of the protocol is as follows: 1) Ticket request When client C wants to access server S, the client program requires it to enter the private key password in order to decrypt the private key file. If the private key password is incorrect, the user is prohibited from further operations. If correct, send the Ticket_req message to the authentication agent AA: C->AA: (C, S, N) SIGNc, CERTc. The specific construction process of the Ticket_req message is as follows: The user obtains the locally saved Nc, then sets N=Nc 1, and then User ID C and the application server S to be accessed are signed using C's private key. This signature can prove their identity. In order to facilitate identity authentication, the client also needs to transmit its own certificate serial number CERTc to the AA. The use of parameter N is mainly to keep the information sent by the user fresh. After the request is sent, in order to prepare for the next session, Nc=Nc 1 needs to be set. 2) Ticket issuance When the authentication proxy server AA receives the Ticket_req message, it first obtains the user certificate from the CA or local cache according to CERTc, and uses CRL to complete the check of certificate validity. If the certificate verification passes, the public key PUBc is obtained from the certificate of user terminal C, and this public key is used to verify C's signature of the information (C, S, N). If the signature verification fails, the verification failure is sent to the client. information. After the signature verification is passed, AA finds out the server S that C wants to access, and checks whether it has access rights to the information of server S. If the rights are met, a Ticket_rep message will be generated: AA->C:Ts,((Kcs,N) SIGNAA)ENCpubc where Ts=((C,S,Kcs,N)SIGNAA)ENCpubs is the ticket used by users to access services. The construction process of the Ticket_rep message is as follows: AA first generates a session key Kcs, which is used to construct the ticket Ts. The identification of user C must be added to Ts to indicate that this ticket is owned by user C and cannot be used by others; adding S indicates that the purpose of this ticket is to be used for access from C to S; and then N must be added to ensure the validity of the ticket freshness; then sign the information to prove that it was issued by AA, and others cannot counterfeit or tamper with it; finally, it is encrypted with S's public key so that others cannot view the session key Kcs. After Ts is constructed, the session key Kcs must be notified to user C. Similar to the processing of the note Ts, it is first signed with AA's private key, and then encrypted with C's public key to prevent others from viewing the session key Kcs. To keep it fresh, N is added to it. 3) Service request. After the user receives the Ticket_rep message, user C uses his private key to unlock ((Kcs,N)SIGNAA)ENCpubc. The user checks the obtained N to see whether N=Nc is true. If so, it is proved. Its freshness; if NNc, it is considered that an error has occurred in a certain program and it will exit. Then, C uses AA's certificate to verify AA's signature on the above data. If successful, it means that the information was indeed sent by AA and not forged by others. When the above verifications are passed, C saves the ticket Ts and session key Kcs and uses them to apply for services from the server.

The S_req message requesting service from server S is as follows: C->S:Ts,(C,S,N)Kcs The specific construction process of S_req is as follows: C encrypts its own identity C, server identity S and synchronization variable N with session key Kcs Finally, it is sent to server S together with Ts. Here we cannot simply send Ts directly to S, because if this is the case, the illegal user can intercept Ts in the second step and then go to the server for authentication. If (C, S, N) Kcs is added, it can be shown that this message is sent by a user with Kcs, and using N ensures its freshness. 4) After server identity authentication application server S receives the service request, it first checks the ticket Ts: it first decrypts it with its own private key. Checking C and S can know whether the ticket was issued by user C and whether it was issued by user C. to yourself; then obtain N, check whether N>Ns is true, and if it is true, the verification is passed, but if N<=Ns, the data is considered to be replay data, discarded, and an error message is sent back; after the above verification is passed, Use AA's certificate to verify its signature and send back an error message if the signature is incorrect. After checking the note itself, the note holder must also be checked: use Kcs to unlock (C, S, N) Kcs, and check whether C, S, N here are consistent with those in the note to prevent illegal attackers from Different combinations of Ts and (C,S,N)Kcs. When the verification is passed, Ns=N should be set to prevent replay. After the user is authenticated, server S sends an s_rep message to client C to prove its identity: S->C:(N 1)Kcs. When client C receives this message, it first uses Kcs to unblock it and checks N Is 1=Nc 1 true? If true, server S is considered legal, because only S can unlock the ticket Ts to obtain Kcs. After that, the two can use the session key Kcs to communicate. 3 Further improvement of the design idea of ??the authentication protocol In Kerberos, the method of issuing tickets is used to achieve centralized management of permissions. We also draw on this idea. The user confirms his identity to the authentication agent AA to obtain the ticket. At this time, the authentication agent can decide whether to issue a ticket to the user based on the user's permissions. When the application server S obtains the service request, S should be able to verify the identity of the issuer of the ticket and the holder of the ticket. Due to the adoption of the public key system, the user's identity is already included in the certificate; by using signatures, the authenticity, integrity and non-repudiation of the message source can be guaranteed; by using the recipient's public key encryption, it can be ensured that only the recipient Only in this way can the data be decrypted and the integrity and confidentiality of the data can be ensured; the freshness of the message can be ensured by using the locally saved synchronization variable N owned by all parties. In a network environment with large scale and scattered entities, it can be said to be very difficult to achieve time synchronization of various parts of the system. This system uses the synchronization variable N to replace the timestamp in Kerberos. For synchronization variable N, it should be an integer with a large enough number of digits. During initial use, since neither client C nor server S has local variable N, we can think that its value is null, and null is smaller than any integer. When the client transmits for the first time, it needs to take N=Nc 1, that is, N=null 1. At this time, a random number within an appropriate range can be taken as the N used in the first session. When the application server S receives N, it can set the value of the local variable N for this user. In the above protocol, the user must apply for a ticket from the authentication agent AA every time he interacts with the server, which is obviously inconvenient for the user and places a heavy burden on the authentication agent AA. Based on these two considerations, the ticket lifetime (lifetime) parameter can be introduced in the above protocol. During the lifetime, the user can reuse the ticket without having to apply to the authentication agent AA. The ticket lifetime can be specified by the application server itself or given by the authentication agent AA when issuing the ticket. This system adopts the latter method. It can be seen from the analysis that in the above protocol, the signature in the first step is not necessary, because the illegal user cannot obtain the session key at all, and cannot prove to the application server that he is the certificate holder, so we also include it Remove and reduce unnecessary calculations. The improved protocol is as follows: 1) Ticket request (Ticket_req), C->AA:C,S,N,CERTc 2) Ticket issuance (Ticket_rep), AA->C:Ts, ((Kcs,N) SIGNAA) ENCpubc Ts=((C,S,Kcs,N,lifetime)SIGNAA)ENCpubs 3) Service request (S_req), C->S:Ts, (N,ra,seq,opinion)Kcs 4) Server identity authentication (S_rep) , S->C:(ra)Kcs (optional determined by opinion) Symbol description is as follows:

◆Lifetime: ticket survival time, (starting from the first time the server receives a service request); ◆ ra: random session key; ◆seq: service request sequence number; ◆opinion: whether the user requires server verification, 1 means required, 0 means not required.

In the second step, the authentication agent AA adds the lifetime of the ticket to the ticket to indicate the lifetime of the ticket. In the third step, in addition to submitting the content in the original agreement to the application server S, user C also adds ra and seq, where ra is a random number generated by C. In the original protocol, Kcs is used as the session key, and ra is used as the session key here. Because user C can repeatedly access server S during the lifetime of the ticket, for security reasons, each session Use a different session key ra. In order to prevent attackers from replaying server request messages during the lifetime of the ticket, the request sequence number seq is introduced in the protocol. seq starts from 1 and increases by one each time. For server S, in addition to retaining the synchronization variable N, it also needs to save the expiration time Texp of the user's ticket and the sequence number seq of the user's last service request. When server S receives the user's service request message, the following three situations may occur when obtaining N in the ticket: 1) N>Ns, indicating that this request uses a new ticket. After all verifications of the request are passed, then Make Ns=N, set the expiration time Texp=Tnow lifetime, and make the locally saved seq the seq in this request; 2) N=Ns, indicating that this request is a re-login request, check Tnow>Texp at this time, To see whether the ticket has expired, after verifying the issuer and holder of the ticket, check whether the serial number seq in the request is greater than the serial number of the last request stored locally. If true, update the seq to this time. The requested sequence number, otherwise the message is considered a replay message. 3) If N

References ⑴Brian Tung.Public Key Cryptography for Initial Authentication in Kerberos.draft-ietf-cat- kerberos-pk-init- 15.txt ⑵Matthew Hur.Public Key Cryptography for Cross-Realm Authentication in Kerberos.draft-ietf-cat-kerberos - pk-cross- 08.txt ⑶ M. Sirbu, J. Chuang.Distributed Authentication in Kerberos Using Public KeyRFC 1510:The Kerberos Network Authentication Service (V5). 1993-09