CN1658553B - A Strong Authentication Method Using Public Key Cryptography Algorithm Encryption Mode - Google Patents

Abstract

This invention discloses a strong distinguishing method adopting open code key calculation encryption mode. The process is:found wireless chain-channel, the identifier sends the identification request to the user, and return the identification information to the server, the server find the user open code key and the information integrality code key from the database to found the dialog with the user, the server and the user produce the random numbers, encode the open code key for each other, decode the code key through the identifier, compare self random number with the random number changed by the opposite side and judge whether the identification is successful. Repeat this process for three times, and the server and the user calculate the whole identification and exchange integrality value through encoding and decoding code key and the information integrality code key and the relative information. The identifier judges whether the identification is successful, decides whether the user can get into the network and realizes the online communication of users and the broadcasting of the base station. The strong points are that it realizes the insurance of the identification of the user and the server and the safety of the communication.

Description

A strong authentication method using public key cryptography algorithm encryption mode

technical field

The invention relates to an authentication method for verifying the legal identities of both the user and the server to ensure that legal users access network resources and prevent them from being deceived by false servers in a communication network. the

Background technique

In the field of network communication, the most common use is to transmit data through point-to-point links through the PPP protocol, and use the CHAP protocol (Challenge Handshake Authentication Protocol) to complete the identity authentication of the PPP link. This CHAP protocol is a challenge-handshake authentication protocol. Both parties of the link configure and test the PPP link through negotiation of the point-to-point scalable link control protocol, PPPLCP for short. After the PPP link is established, the identity of the connecter must be authenticated first, and then based on the authentication result, it is decided whether to allow the link to enter the NCP (Network Control Protocol) stage of negotiation. CHAP conducts a "three-way handshake" between the two parties of the PPP link to complete the identification of the other party. The authentication is that after the PPPLCP protocol enters the open state (opened), the authenticator initiates CHAP authentication on the peer end, and the process is roughly as follows: 

① The authentication direction sends a CHAP challenge to the authenticated party, and the challenge data is a random number or a pseudo-random number. the

②After the authenticated party receives the CHAP challenge, it calculates a one-way hash value based on certain calculation rules based on the challenge data, shared password and other information as a response to the challenge and sends it to the authenticating party. the

③After receiving the response, the authenticator calculates an expected hash value locally based on the same calculation rules, using the shared key, challenge data and other information, and compares the CHAP response result with the expected hash result. If they are consistent, then The authenticated party passes the identity authentication, otherwise, the authentication fails. the

The CHAP protocol is mainly applicable to the network access server NAS (Network Access Server) to identify the identity of the circuit switched connection, dial-in connection or private connection from the public switched telephone network PSTN or integrated services digital network ISDN. the

Because the CHAP protocol is only a one-way authentication protocol, that is, it only authenticates the user, rather than a two-way authentication protocol between the user and the server, so it cannot prevent replay attacks. Moreover, the CHAP protocol does not extract identity authentication separately, so it cannot be used in a roaming environment. And the CHAP protocol does not support session key derivation and cannot be used for subsequent secure communication. the

Another most widely used communication transmission protocol in the field of network communication is the RADIUS protocol. the

Due to the network access server NAS, it is connected to the outside world through the Moden pool or other interfaces. When users enter the network through these interfaces to share information and resources, it is necessary to authenticate the users who enter the network through these interfaces to complete the authorized access to users. RADIUS (Remote Authentication Dial-up User Service) is designed for this need. It is a specification for communicating between a network access server and a shared authentication server. According to this communication specification, the network server authenticates the users accessing it through the shared authentication server. NAS and authentication server exchange their authentication information, authorization information and configuration information according to the specifications. RADIUS also provides information processing specifications for the authentication server and authentication client (namely NAS or authenticator), through which the authentication, authorization and configuration of clients accessing the NAS are completed. the

In a nutshell, the RADIUS authentication protocol has the following main features:

1), client/server model

RADIUS uses the NAS as a client. The main task of the client is to complete the interaction with the visiting user (the purpose is to collect user authentication information), send the collected authentication information to the server and respond to the authentication result sent back by the server. The authentication server is called the RADIUS authentication server, which authenticates the user identity according to the user authentication request data sent by the client, and returns the authentication result. the

2), network security

A pair of secret keys are shared between the RADIUS server and the NAS. All communication between them is protected by the authentication of this pair of keys, while providing some integrity protection. Sensitive data (such as user passwords) passed between the server and the NAS is also protected with confidentiality. The RADIUS protocol also provides state attributes and an authenticator (Authenticator) to prevent denial attacks and spoofing attacks on the client or server. RFC3162 defines that RADIUS uses IPSEC, that is, the IP security protocol stack, but the support for IPSEC is not required. the

3), scalable protocol design

A RADIUS data packet is composed of a relatively fixed message header and a series of attributes. Attributes are composed of "attribute type, length, attribute value" triplet, and users can define other attributes by themselves to extend the RADIUS authentication protocol. the

4), flexible identification mechanism

The RADIUS protocol supports different authentication protocols to implement authentication on users who need to be authenticated. The authentication protocols include PAP, CHAP, MS-CHAP, etc., and the EAP authentication protocol is also defined in RFC2869RADIUS Extensions. the

RADIUS implements the process of identity authentication:

When a user dials in to the NAS, the NAS requests the RADIUS server for user identity authentication, and after obtaining the RADIUS access response, the user obtains the desired service. The general process is as follows:

① The dial-in user establishes a PPP (or other protocol, such as SLIP) connection with the NAS, and the NAS requires the user to present authentication information. The mode required to be presented may be a self-defined login notification, and the user is required to key in the user name and password, or the authentication protocol of the PPP protocol, such as link framing protocols such as CHAP, to transmit the user's name information and password information. the

② The dial-in user presents the identification information to the NAS. the

③ NAS constructs a RADIUS message called "Access-Request" (that is, access request) based on these identification information, and sends it to the RADIUS server. The Access-Request message should include the following content: user name, user password, NAS name information (used as the basis for which shared key is used by RADIUS), port number accessed by the user, and other information. The user password shall be protected by confidentiality. the

④ For a NAS, it is often equipped with a main RADIUS server and several backup RADIUS servers. If the NAS still cannot receive a response after sending the Access-Request for a certain period of time, the NAS can consider the master server to be unreachable. So the NAS can choose to contact the second backup server. The selection rules are not given in the RADIUS protocol: the implementation of the protocol can select the second server after a certain number of failed NAS retransmission requests, and can also select the server in a loop. For example, after waiting for the failure of the main server to reply, immediately select the second one, and after waiting for the failure of the second response, immediately select the third one... 

⑤ After the RADIUS server receives the Access-Request, it first finds the shared key between the server and the NAS based on the name information of the NAS. If it cannot be found (for example, the NAS name is invalid), the access request should be discarded; if it can be found, the integrity and legitimacy of the data will be verified using the shared key. Then look up the corresponding user entry in the RADIUS authentication database according to the user name in the request. This entry gives the resources that the user can access, and the conditions that must be met in order to access these resources, such as the password information that must be presented. RADIUS verifies whether the user meets all the authentication conditions one by one according to the authentication information. the

⑥If the user cannot pass all the verifications, RADIUS sends back an "Access-Reject" (access rejection) message to the NAS, indicating that the user cannot pass the verification. Based on this message, the NAS refuses to provide the required service to the user. the

⑦If all verifications pass, RADIUS sends an "Access-Accept" message to the NAS or another round of queries to the user. If another round of queries is required, the RADIUS server sends an "Access-Accept" message to the NAS "(Access-Challenge) message, a set of data is given in this message, and the user is required to encrypt the data with the corresponding key. After receiving the challenge, the NAS sends the challenge information to the dial-in user, and the user encrypts the data accordingly. And send the result to NAS. NAS constructs a new "access" request according to the user's return result, and sends it to the RADIUS server. The server verifies the challenge response. If the verification is passed, it sends a "access acceptance" message to NAS .

⑧ The access acceptance message should include the type of service (such as PPP or Telnet service) that can be provided to the user, and the corresponding configuration information (such as the IP address for PPP, subnet mask, etc.). After receiving this message, the NAS configures the local environment and starts corresponding services for dial-in users. The communication specifications of the RADIUS authentication protocol will not be specifically introduced here. You can refer to RFC2856, RFC2866, RFC2867, RFC2868, RFC2869, RFC2809 and other standards. the

RADIUS is mainly used for dial-up PPP and terminal server access. Over time, the ever-growing Internet and the introduction of new access technologies, including wireless, DSL, mobile IP, and Ethernet, routers, and network servers (NAS) have increased complexity and density. The simple RADIUS protocol can no longer meet the new requirements of the AAA server in terms of authentication, authorization, and accounting. the

The problems with the RADIUS protocol are:

Error recovery problem: The RADIUS protocol does not support the error recovery failover mechanism. As a result, different implementations have different failovers. the

Transport-level security issues: RADIUS defines schemes that require application-layer authentication and integrity in response packets. An additional authentication and integrity mechanism is defined in the RADIUS extension protocol, and it is only required in the Extended Authentication Protocol (EAP) session. Although attribute hiding is supported, RADIUS does not provide per-packet confidentiality. When accounting, RADIUS accounting assumes that replay protection is provided by the billing server in the backend, not in the protocol itself. the

Reliable transport issues: RADIUS runs over UDP and does not define retransmission behavior; as a result, reliability varies from implementation to implementation. This will be a problem when billing, and the loss of the group will directly lead to the loss of revenue. the

Proxy support issues: RADIUS does not provide explicit support for proxies, including proxies, redirects, and relays. Because the desired behavior is not defined and differs between implementations. the

Messages initiated by the server: As mentioned above, RADIUS adopts the client/server model. Although the message initiated by the RADIUS server is defined in dynamic authentication, support is optional. This is difficult to achieve with things like unsolicited disconnection or on-demand re-authentication/re-authentication across heterogeneous networks. the

Auditability issues: RADIUS does not define data object security mechanisms, as a result, untrusted agents can modify attributes or packet headers without being discovered. Along with support for capacity negotiation, this can be difficult to determine in the event of a dispute.

Capability negotiation issues: RADIUS does not support error handling, capability negotiation, or required/not required flags for attributes. Because RADIUS clients and servers do not know each other's capabilities, they cannot successfully negotiate acceptable services between them, or in some cases, cannot even know which services are implemented. the

Peer discovery and configuration issues: RADIUS implementations typically require manual configuration of server or client names and addresses, along with corresponding shared secrets. This would result in a large administrative load, and create templates to reuse RADIUS shared secrets, which would lead to security vulnerabilities. the

In summary, simply using the CHAP protocol for identity authentication and the RADIUS protocol for information transmission cannot solve the problem of two-way authentication between users and the network in mobile communications, and cannot effectively prevent physical layer eavesdropping, replay attacks, and dictionary attacks. There are communication security risks between users and the access server NAS. the

Contents of the invention

In a modern communication network, if a user wants to access network resources, he must first authenticate the user into the network. The authentication process is to verify the legitimacy of the user's identity. Manage billing. Generally speaking, the authentication process is completed by three entities: mobile node MN or user, authenticator (Authenticator, implemented in the access network access server NAS), AAA server (Authentication, Authorization and Accounting, authentication, authorization and accounting) fee server). The user MN and the authenticator are connected by a wireless channel; the authenticator and the AAA server are connected by a wired channel, and the communication transmission protocol between the two is the RADIUS protocol. the

The purpose of the present invention is to: provide the existing AAA server to identify the legality of the user MN's network access identity, prevent physical layer eavesdropping, replay attacks, and resist dictionary attacks, and also have the user MN to authenticate the AAA server for effective self-protection. A strong authentication method using the encryption mode of the public key cryptography algorithm to realize the secure communication between the user and the access server or authenticator in the third generation mobile communication. the

The purpose of the present invention is achieved by implementing the following technical identification process:

A strong authentication method using public key cryptographic algorithm encryption mode, including that the user MN has a public cryptographic key pair, the secret key is stored safely by the user MN, and the public key is stored in the AAA server. If there is an intermediate AAA The server, the public key is stored in the belonging AAA server, and the AAA server has a public cryptographic key pair, the secret key of which is safely stored by the AAA server, and the public key must be owned by the user MN; the user MN shares with the AAA server The message integrity key for message integrity processing, the generation of the public encryption key pair and the distribution process of the public key are an out-of-band process; the communication between the user MN and the authenticator is a wireless channel; the communication between the authenticator and the AAA server The communication protocol between adopts the RADIUS protocol; it is characterized in that: the authentication process is carried out according to the following steps in turn:

1. The user MN starts up within the coverage of a sector SC of a base station controller, and obtains wireless transmission channel resources through the wireless link establishment process;

2. The authenticator sends an identity request to the user MN, requesting the user MN to return its identity information;

3. The user MN returns its own IMSI information to the authenticator, and establishes an authentication session;

4. The authenticator sends an authentication request/IMSI to the corresponding AAA server according to the IMSI identity information of the user MN;

5. After receiving the authentication request/IMSI, the AAA server finds the public key and the message integrity key of the user MN from the corresponding database, and establishes an authentication session with the MN; the AAA server generates a random number RandA, and uses the user MN's Encrypt with the public key to get En(RandA), and then send a response/En(RandA) to the authenticator;

6. The authenticator receives the response/En(RandA) sent from the AAA server, and then sends an authentication request/En(RandA) to the user MN;

7. The user MN receives the authentication request /En(RandA) sent by the AAA server through the authenticator, decrypts it with its own secret key, and obtains the random number RandA, and transforms RandA into T to obtain the random number Rand_A. Generate a random number RandC, concatenate RandC and Rand_A and encrypt with the public key of the AAA server to get En(RandC+Rand_A), and then send a response/En(RandC+Rand_A) to the authenticator;

8. The authenticator receives the response /En(RandC+Rand_A) sent by the user MN, and then sends an authentication request /En(RandC+Rand_A) to the AAA server;

9. The AAA server receives the authentication request /En(RandC+Rand_A) sent by the authenticator, first decrypts it with its own secret key, obtains the random number RandC and the random number response Rand_A, compares whether RandA and Rand_A are consistent, if not, The authentication fails; if the authentication is successful, the AAA server obtains Rand_C from RandC through T transformation, and encrypts it with MN's public key to obtain En(Rand_C), and then obtains the session key through K transformation of the user's identity information IMSI, random number RandA, and RandC SK; and IMSI, RandA, RandC and the message integrity key are calculated by MAC to obtain the entire authentication exchange integrity value HASH(m), and then the response/En(Rand_C)+SK+HASH(m) is sent to the authenticator ;

10. The authenticator receives the response /En(Rand_C)+SK+HASH(m) sent by the AAA server, extracts the session key SK and HASH(m); encrypts the broadcast key BK with the session key SK, and sends User MN sends authentication request/En(Rand_C)+En(BK);

11. After receiving the authentication request /En(Rand_C)+En(BK) sent by the authenticator, the user MN first decrypts En(Rand_C) with its own private key to obtain Rand_C, and compares whether RandC and Rand_C are consistent. If they are consistent, Then the authentication is successful; then according to the identity information IMSI of oneself, the random number RandA generated by the AAA server, and the random number RandC generated by the user himself, the session key SK is obtained through K transformation, and the broadcast key BK is obtained by decrypting En(BK); then according to the ISMI , RandA, RandC and the message integrity key, calculate the entire authentication exchange integrity value HASH(M) through MAC, and then send the response HASH(M) to the authenticator; the authenticator receives the response HASH sent by the user MN After (M), compare HASH(M) and HASH(m). If they are consistent, the authentication process is successful, and subsequent processing can be performed. the

The invention has the advantages of realizing the authentication process of the AAA authentication system, and can be used for user MN access services. Although the public key cryptographic algorithm is adopted, because the AAA authentication system only needs to authenticate between the user and the server, the PKI architecture can be omitted. The system can even have a dedicated key pair for each user's authentication in the AAA server, and only needs to define the identifier of the key pair. Adopting this method in the AAA authentication system will make system management easy, and its key management complexity is O(n). The identification method of the present invention is a two-way identification, which includes both the user's identification of the AAA server and the AAA server's identification of the user, which can protect itself, prevent physical layer eavesdropping, prevent replay attacks, and resist dictionary attacks. Generate session keys or distribute session keys for secure communication between users and the access server NAS. the

Description of drawings

Fig. 1 is the two-way identification process diagram of the present invention

Fig. 2 is a flow chart of the communication process of the present invention

In the figure, the mark dead means that the physical connection does not exist; the mark established means the link establishment state; the mark authentication means the authentication process or authentication success or authentication failure; the mark network means that the network resources can be used; the mark end means the communication termination state . the

Detailed ways

The content in this section mainly describes the specific application of the authentication method of the present invention in the PPP protocol. the

In order to establish communication over a point-to-point link, each end of the PPP link must first send an LCP packet to set up and test the data link. After the link is established, the peer can be identified. PPP must then send NCP packets to select and configure one or more network layer protocols. Once each selected network layer protocol is configured, packets from each network layer protocol can be sent on the link. The link will remain in the communication configuration until direct LCP and NCP packets close the link, or when some external event occurs (inactivity timer expires or network administrator intervenes). In the process of setting up, maintaining and terminating a point-to-point link, a PPP link goes through several distinct stages, as shown in Figure 2. This diagram does not show all state transitions. the

Link dead (physical connection does not exist)

Links must start and end at this stage. When an external event (such as carrier sense or network administrator settings) indicates that the physical layer is ready, PPP will enter the link establishment phase. In this phase, the LCP automaton will be in the initial state, and the transition to the link establishment phase will signal the LCP automaton an UP start event. NOTE: After disconnecting from the modem, the link will automatically return to this stage. In a hardware-implemented link, this phase is rather short - just long enough to detect the presence of the device. the

link establishment phase

LCP is used to exchange configuration information packets (Configure packets) and establish connections. Once a configuration is successful, the information packet (Configure-Ack packet) is sent and received, the exchange is completed and the LCP is turned on. All configuration options assume default values unless changed by configuration exchanges. One thing to note: only configuration options that do not depend on a particular network layer protocol are configured by the LCP. In the network layer protocol stage, the configuration of the independent network layer protocol is handled by the independent network control protocol (NCP). Any non-LCP packets received during this phase MUST be silently discarded. Receiving an LCP Configure-Request (LCP configuration request) can make the link return from the network layer protocol phase or authentication phase to the link establishment phase. the

identification stage

On some links, one end of the link may require the peer to be authenticated before network layer protocol packets are allowed to be exchanged. The default authentication is not enforced. If an implementation expects peers to authenticate according to a particular authentication protocol, it MUST require that authentication protocol be used during link establishment. Authentication should be performed as soon as possible after link establishment. And the link quality check can happen at the same time. In an implementation, the practice of postponing authentication indefinitely due to the exchange of link quality check packets is prohibited. Proceeding from the authentication phase to the network layer protocol phase is prohibited until authentication is complete. If the authentication fails, the authenticated party shall transition to the link termination phase. In this phase, only packets of link control protocol, authentication protocol, and link quality monitoring protocol are allowed. Other packets received during this phase MUST be silently discarded. NOTE: An implementation SHOULD NOT fail authentication simply because of a timeout or no response. Authentication should allow some kind of retransmission, and only enter the link termination phase as a last resort after several failed authentication attempts. In authentication, which party rejects the other party's authentication, which party will be responsible for starting the link termination phase. The identification method of the present invention is used at this stage. the

Network Layer Protocol Phase

Once PPP has completed the previous phases, each network layer protocol (such as IP, IPX, or AppleTalk) must be configured separately with the appropriate Network Control Protocol (NCP). Each NCP can be turned on and off at any time. Note: Because an implementation may initially take a significant amount of time for link quality checks, implementations SHOULD avoid using fixed timeouts while waiting for peers to set NCP. When an NCP is in the Opened state, PPP will carry the corresponding network layer protocol grouping. When the corresponding NCP is not in the Opened state, any supported network layer protocol packets received will be silently discarded. Note: When the LCP is in the Opened state, any protocol packets not supported by the implementation MUST be returned in Protocol-Reject. Only supported protocols are quietly dropped. At this stage, link traffic consists of any possible combination of LCP, NCP, and network layer protocol packets. the

link termination phase

PPP can terminate the link at any time. Link termination can occur for a number of reasons: carrier loss, authentication failure, link quality failure, idle period timer expiration, or administrator shutting down the link. the

The LCP terminates the link by exchanging Terminate (terminate) packets. PPP notifies the network layer protocols when the link is being closed so they can take the correct action. After exchanging Terminate packets, the implementation SHOULD notify the physical layer of disconnection in order to force link termination, especially if authentication fails. The sender of the Terminate-Request should disconnect after receiving the Terminate-Ack (terminate-allow), or after the restart counter expires. The party that receives the Terminate-Request should wait for the other end to cut it off. After sending the Terminate-Request, at least one Restart time (restart time) must pass before disconnection is allowed. PPP should proceed to link death phase. Any non-LCP packets received during this phase MUST be silently discarded. It is sufficient for the LCP to close the link, it is not necessary for each NCP to send a terminate packet. On the contrary, closing of an NCP is not enough to cause the termination of the PPP link, even if that NCP is currently the only one in the Opened state. the

Claims (1)

1. A strong authentication method that adopts the public key cryptographic algorithm encryption mode, including that the user MN has a public cryptographic key pair, the secret key is kept safely by the user MN, and the public key is stored in the AAA server. If there is The intermediate AAA server, the public key is stored in the AAA server, and the AAA server has a public encryption key pair, the secret key of which is safely stored by the AAA server, and the public key must be owned by the user MN; the user MN and the AAA The server shares the message integrity key for message integrity processing. The generation of the public encryption key pair and the distribution of the public key are an out-of-band process; the communication between the user MN and the authenticator is a wireless channel; the authenticator and the AAA The communication protocol between the servers adopts the RADIUS protocol; it is characterized in that: the authentication process is carried out according to the following steps successively: a. The user MN starts up within the coverage of a certain sector SC of a certain base station controller, and obtains wireless transmission channel resources through the process of establishing a wireless link; b. The authenticator sends an identity request to the user MN, requesting the user MN to return its identity information; c. The user MN returns its own IMSI information to the authenticator, and establishes an authentication session; d. The authenticator sends an authentication request/IMSI to its corresponding AAA server according to the IMSI identity information of the user MN; e. After the AAA server receives the authentication request/IMSI, it finds the public key and the message integrity key of the user MN from the corresponding database, and establishes an authentication session with the MN; the AAA server generates a random number RandA, and uses the user MN's Encrypt with the public key to get En(RandA), and then send a response/En(RandA) to the authenticator; f. The authenticator receives the response/En(RandA) sent from the AAA server, and then sends an authentication request/En(RandA) to the user MN; g. The user MN receives the authentication request /En(RandA) sent by the AAA server through the authenticator, decrypts it with its own secret key, obtains the random number RandA, and performs T transformation on RandA to obtain the random number response Rand_A, and generates A random number RandC, concatenate RandC and Rand_A and encrypt with the public key of the AAA server to get En(RandC+Rand_A), and then send a response /En(RandC+Rand_A) to the authenticator; h. The authenticator receives the response/En(RandC+Rand_A) sent by the user MN, and then sends an authentication request/En(RandC+Rand_A) to the AAA server; i. The AAA server receives the authentication request /En(RandC+Rand_A) sent by the authenticator, first decrypts it with its own secret key, obtains the random number RandC and the random number response Rand_A, compares whether RandA and Rand_A are consistent, if not, The authentication fails; if the authentication is successful, the AAA server obtains Rand_C from RandC through T transformation, and encrypts it with MN's public key to obtain En(Rand_C), and then obtains the session key through K transformation of the user's identity information IMSI, random number RandA, and RandC SK; and IMSI, RandA, RandC and the message integrity key are calculated by MAC to obtain the entire authentication exchange integrity value HASH(m), and then the response/En(Rand_C)+SK+HASH(m) is sent to the authenticator ; j. The authenticator receives the response /En(Rand_C)+SK+HASH(m) sent by the AAA server, extracts the session key SK and HASH(m); encrypts the broadcast key BK with the session key SK, and then Send an authentication request/En(Rand_C)+En(BK) to the user MN; k. After receiving the authentication request /En(Rand_C)+En(BK) sent by the authenticator, the user MN first decrypts En(Rand_C) with its own private key to obtain Rand_C, and compares whether RandC and Rand_C are consistent. If they are consistent, Then the authentication is successful; then according to the identity information IMSI of oneself, the random number RandA generated by the AAA server, and the random number RandC generated by the user himself, the session key SK is obtained through K transformation, and the broadcast key BK is obtained by decrypting En(BK); then according to the ISMI , RandA, RandC and the message integrity key, calculate the entire authentication exchange integrity value HASH(M) through MAC, and then send the response HASH(M) to the authenticator, and the authenticator receives the response HASH from the user MN After (M), compare HASH(M) and HASH(m), if they are consistent, the authentication process is successful.

Images