Identity authentication method and apparatus, and device, chip, storage medium and program

This application claims priority to Chinese Patent Application No. 202011569233.5, filed on Dec. 26, 2020 and entitled “IDENTITY AUTHENTICATION METHOD AND APPARATUS. AND DEVICE, CHIP, STORAGE MEDIUM AND PROGRAM”, the disclosure of which is hereby incorporated by reference in its entirety.

The present application relates to the field of network communication security technologies, and in particular, to an identity authentication method and apparatus, and a device, a chip, a storage medium and a program.

In a communication network, a Requester (REQ) may access a network through an Authentication Access Controller (AAC). In some cases requiring high security, the AAC needs to perform authentication on the identity of the REQ, and the REQ also needs to perform authentication on the identity of the AAC, so as to ensure that the REQ accessing the network belongs to a legal user, and the network to which the REQ accesses belongs to a legal network. In addition, for node-to-node transmission in a blockchain technology, a trust relationship also needs to be established between different nodes, such that it is also very important for identity authentication for the nodes.

During the process of performing Mutual Identity Authentication (MIA) between the REQ and the AAC, both the REQ and the AAC need to provide self-identity information for identity authentication. However, such identity information usually carries private and sensitive information, such as ID numbers, home addresses, bank card information, geographical location information, and affiliated institution information. In addition, during a practical application process, identity information of the REQ and identity information of the AAC are generally included in a physical digital certificate, and the digital certificate is used as a physical identity certificate.

If, during MIA of the REQ and the AAC, the identity information of the REQ or the AAC is intercepted by an attacker for illegal use, a great security risk is caused to the AAC, the REQ and the network.

The present application provides an identity authentication method and apparatus, and a device, a chip, a storage medium and a program. By means of involving an authentication server, MIA between the AAC and the REQ is achieved while the confidentiality of entity identity related information is guaranteed.

According to a first aspect, an embodiment of the present application provides an identity authentication method. The method includes the following operations.

An AAC acquires an identity ciphertext message sent by an REQ. The identity ciphertext message includes identity information ciphertext of the REQ, and the identity information ciphertext is generated by encrypting, using a public key of an encryption certificate, to-be-encrypted data including a digital certificate of the REQ and a second key.

The AAC sends a first authentication request message to a first Authentication Server (AS) which is trusted by the AAC. The first authentication request message includes the identity information ciphertext of the REQ and a digital certificate of the AAC.

The AAC receives a first authentication response message sent by the first AS. The first authentication response message includes first authentication result information, a first digital signature, second authentication result information ciphertext and a second digital signature. The first authentication result information includes a first verification result for the digital certificate of the AAC. The first digital signature is a digital signature which is generated by a second AS trusted by the REQ performing calculation on to-be-signed data including the first authentication result information. The second authentication result information ciphertext is obtained by encrypting, using the second key, information including second authentication result information. The second authentication result information includes a second verification result for the digital certificate of the REQ; and the second digital signature is a digital signature which is generated by the first AS performing calculation on to-be-signed data including the second authentication result information ciphertext.

The AAC verifies the second digital signature by using a public key of the first AS. If the verification of the second digital signature is successful, the AAC sends a third authentication response message to the REQ. The third authentication response message includes authentication result information ciphertext. The authentication result information ciphertext is generated by encrypting, using a message encryption key, to-be-encrypted data including the first authentication result information and the first digital signature.

The REQ decrypts the authentication result information ciphertext using the message encryption key, so as to obtain the first authentication result information and the first digital signature.

The REQ verifies the first digital signature by using a public key of the second AS. If the verification is successful, the REQ determines an identity authentication result of the AAC according to an first verification result in the first authentication result information. If the REQ determines that the identity authentication result of the AAC is legal, the REQ sends a fourth authentication response message to the AAC.

Or the REQ verifies the first digital signature by using the public key of the second AS If the verification is successful, the REQ sends the fourth authentication response message to the AAC, and determines the identity authentication result of the AAC according to the first verification result in the first authentication result information.

Or the REQ verifies the first digital signature by using the public key of the second AS. If the verification of the first digital signature is successful, the REQ determines the identity authentication result of the AAC according to the first verification result in the first authentication result information; and the REQ sends the fourth authentication response message to the AAC.

The fourth authentication response message includes second key ciphertext, and the second key ciphertext is obtained by encrypting, using the message encryption key, information including the second key.

After receiving the fourth authentication response message, the AAC decrypts the second key ciphertext using the message encryption key, so as to obtain the second key, decrypts the second authentication result information ciphertext using the second key, so as to obtain the second authentication result information, and determines an identity authentication result of the REQ according to the second verification result in the second authentication result information.

According to a second aspect, an embodiment of the present application provides an AAC. The AAC includes an acquisition portion, a first sending portion, a first receiving portion, a first verification portion, a second sending portion, a second receiving portion, a decryption portion, and a first determination portion.

The acquisition portion is configured to acquire an identity ciphertext message sent by an REQ. The identity ciphertext message includes identity information ciphertext of the REQ, and the identity information ciphertext is generated by encrypting, using a public key of an encryption certificate, to-be-encrypted data including a digital certificate of the REQ and a second key.

The first sending portion is configured to send a first authentication request message to a first AS which is trusted by the AAC. The first authentication request message includes the identity information ciphertext of the REQ and a digital certificate of the AAC.

The first receiving portion is configured to receive a first authentication response message sent by the first AS. The first authentication response message includes first authentication result information, a first digital signature, second authentication result information ciphertext and a second digital signature; the first authentication result information includes a first verification result for the digital certificate of the AAC; the first digital signature is a digital signature which is generated by a second AS trusted by the REQ performing calculation on to-be-signed data including the first authentication result information; the second authentication result information ciphertext is obtained by encrypting, using the second key, information including second authentication result information: the second authentication result information includes a second verification result for the digital certificate of the REQ; and the second digital signature is a digital signature which is generated by the first AS performing calculation on to-be-signed data including the second authentication result information ciphertext.

The first verification portion is configured to verify the second digital signature by using a public key of a first AS.

The second sending portion is configured to send a third authentication response message to the REQ when the verification of the second digital signature is successful. The third authentication response message includes authentication result information ciphertext; and the authentication result information ciphertext is generated by encrypting, using a message encryption key, to-be-encrypted data including the first authentication result information and the first digital signature.

The second receiving portion is configured to receive a fourth authentication response message sent by the REQ. The fourth authentication response message includes second key ciphertext; and the second key ciphertext is obtained by encrypting, using the message encryption key, information including the second key.

The decryption portion is configured to decrypt the second key ciphertext using the message encryption key, so as to obtain the second key, and decrypt the second authentication result information ciphertext using the second key, so as to obtain the second authentication result information.

The first determination portion is configured to determine an identity authentication result of the REQ according to the second verification result in the second authentication result information.

According to a third aspect, an embodiment of the present application provides an REQ. The REQ includes a first sending portion, a first receiving portion, a first decryption portion, and a first verification portion.

The first sending portion is configured to send an identity ciphertext message to an AAC. The identity ciphertext message includes identity information ciphertext of the REQ; and the identity information ciphertext is generated by encrypting, using a public key of an encryption certificate, to-be-encrypted data including a digital certificate of the REQ and a second key.

The first receiving portion is configured to receive a third authentication response message sent by the AAC. The third authentication response message includes authentication result information ciphertext; and the authentication result information ciphertext is generated by encrypting, using a message encryption key, to-be-encrypted data including the first authentication result information and the first digital signature.

The first decryption portion is configured to decrypt, using the message encryption key, the authentication result information ciphertext, so as to obtain the first authentication result information and the first digital signature.

The first verification portion is configured to verify the first digital signature by using a public key of the second AS. The first determination portion is further configured to determine an identity authentication result of the AAC according to the first verification result in the first authentication result information if the verification of the first digital signature is successful, and the second sending portion is further configured to send a fourth authentication response message to the AAC when the first determination portion determines that the identity authentication result of the AAC is legal.

Or the first verification portion is configured to verify the first digital signature by using the public key of the second AS. The second sending portion is further configured to send the fourth authentication response message to the AAC if the verification of the first digital signature is successful, and the first determination portion is further configured to determine the identity authentication result of the AAC according to the first verification result in the first authentication result information.

Or the first verification portion is configured to verify the first digital signature by using the public key of the second AS, the first determination portion is further configured to determine the identity authentication result of the AAC according to the first verification result in the first authentication result information if the verification of the first digital signature is successful; and the second sending portion is further configured to send a fourth authentication response message to the AAC.

The fourth authentication response message includes second key ciphertext, and the second key ciphertext is obtained by encrypting, using the message encryption key, information including the second key.

According to a fourth aspect, an embodiment of the present application provides a first Authentication Server (AS). The first AS is an AS trusted by an AAC, and includes a first receiving portion and a first sending portion.

The first receiving portion is configured to receive a first authentication request message sent by the AAC. The first authentication request message includes identity information ciphertext of an REQ and a digital certificate of the AAC, and the identity information ciphertext is generated by encrypting, using a public key of an encryption certificate, to-be-encrypted data including a digital certificate of the REQ and a second key.

The first sending portion is configured to send a first authentication response message to the AAC. The first authentication response message includes first authentication result information, a first digital signature, second authentication result information ciphertext and a second digital signature; the first authentication result information includes a first verification result for the digital certificate of the AAC; the first digital signature is a digital signature which is generated by a second AS trusted by the REQ performing calculation on to-be-signed data including the first authentication result information; the second authentication result information ciphertext is obtained by encrypting, using the second key, information including second authentication result information; the second authentication result information includes a second verification result for the digital certificate of the REQ; and the second digital signature is a digital signature which is generated by the first AS performing calculation on to-be-signed data including the second authentication result information ciphertext.

According to a fifth aspect, an embodiment of the present application provides a second Authentication Server (AS). The second AS is an AS trusted by an REQ. In a case that a first AS trusted by an AAC and the second AS trusted by the REQ are two different ASs, the second AS includes a receiving portion, a verification portion, a decryption portion, a generation portion, and a sending portion.

The receiving portion is configured to receive a second authentication request message sent by the first AS. The second authentication request message includes first authentication result information, identity information ciphertext of the REQ, and a third digital signature; the third digital signature is a digital signature, which is generated by the first AS performing calculation on to-be-signed data including the first authentication result information and the identity information ciphertext of the REQ; and the identity information ciphertext is generated by encrypting, using a public key of an encryption certificate, to-be-encrypted data including a digital certificate of the REQ and a second key.

The verification portion is configured to verify the third digital signature by using a public key of the first AS.

The decryption portion is configured to decrypt the identity information ciphertext of the REQ by using the private key corresponding to the encryption certificate when the verification of the third digital signature is successful, so as to obtain the digital certificate of the REQ and the second key.

The verification portion is further configured to perform legality verification on the digital certificate of the REQ, so as to obtain a second verification result.

The generation portion is configured to generate a second authentication result information according to information including the second verification result, generate second authentication result information ciphertext by encrypting, using the second key, information including the second authentication result information, generate a first digital signature by performing calculation on to-be-signed data including the first authentication result information, and generate a fourth digital signature by performing calculation on to-be-signed data including the second authentication result information ciphertext to.

The sending portion is configured to send a second authentication response message to the first AS. The second authentication response message includes the first authentication result information, the first digital signature, the second authentication result information ciphertext, and the fourth digital signature.

According to a sixth aspect, an embodiment of the present application provides an AAC. The AAC includes a processor and a memory. The memory is configured to store a computer program; and the processor is configured to call and run the computer program stored in the memory, so as to execute steps, which are executed by the AAC in the identity authentication method as described in the first aspect.

According to a seventh aspect, an embodiment of the present application provides an REQ. The REQ includes a processor and a memory. The memory is configured to store a computer program; and the processor is configured to call and run the computer program stored in the memory, so as to execute steps, which are executed by the REQ in the identity authentication method as described in the first aspect.

According to an eighth aspect, an embodiment of the present application provides a first AS. The first AS is an AS trusted by an AAC, and includes a processor and a memory. The memory is configured to store a computer program; and the processor is configured to call and run the computer program stored in the memory, so as to execute steps, which are executed by the first AS in the identity authentication method as described in the first aspect.

According to a ninth aspect, an embodiment of the present application provides a second AS. The second AS is an AS trusted by an REQ. If a first AS trusted by an AAC and the second AS trusted by the REQ are two different ASs, the second AS includes a processor and a memory. The memory is configured to store a computer program; and the processor is configured to call and run the computer program stored in the memory, so as to execute steps, which are executed by the second AS in the identity authentication method as described in the first aspect.

According to a tenth aspect, an embodiment of the present application provides a chip. The chip includes: a processor, configured to call and run a computer program from a memory, to enable:

an AAC having the chip mounted to execute steps, which are executed by the AAC in the identity authentication method as described in the first aspect. or an REQ having the chip mounted to execute steps, which are executed by the REQ in the identity authentication method as described in the first aspect. or a first AS having the chip mounted to execute steps, which are executed by the AS-AAC in the identity authentication method as described in the first aspect. or a second AS having the chip mounted to execute steps, which are executed by the AS-REQ in the identity authentication method as described in the first aspect.

According to an eleventh aspect, an embodiment of the present application provides a computer storage medium. The computer storage medium is configured to store a computer program. The computer program enables an AAC to execute steps, which are executed by the AAC in the identity authentication method as described in the first aspect.

Or the computer program enables an REQ to execute steps, which are executed by the REQ in the identity authentication method as described in the first aspect.

Or the computer program enables a first AS to execute steps, which are executed by the AS-AAC in the identity authentication method as described in the first aspect.

Or the computer program enables a second AS to execute steps, which are executed by the second AS in the identity authentication method as described in the first aspect.

According to a twelfth aspect, an embodiment of the present application provides a computer program. The computer program enables an AAC to execute steps, which are executed by the AAC in the identity authentication method as described in the first aspect.

Or the computer program enables an REQ to execute steps, which are executed by the REQ in the identity authentication method as described in the first aspect.

Or the computer program enables a first AS to execute steps, which are executed by the AS-AAC in the identity authentication method as described in the first aspect.

Or the computer program enabling a second AS to execute steps, which are executed by the second AS in the identity authentication method as described in the first aspect.

From the above technical solutions, it can be seen that, identify information of the REQ is subjected to confidential processing during identity authentication, and when the identify information is transmitted between the REQ and the AAC, the identify information of the AAC is subjected to confidential processing, so as to prevent the identify information of the REQ and the AAC from being exposed during a transmission process, thereby ensuring that an attacker cannot obtain private and sensitive information. Moreover, by means of involving an authentication server, real-time mutual identity authentication between the REQ and the AAC is achieved while the confidentiality of entity identity related information is guaranteed, such that the foundation that only a legal user can access a legal network is laid.

In order to make the above purposes, features and advantages of the present disclosure more obvious and easier to understand, detailed descriptions of preferred embodiments are made below with reference to the drawings.

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the related art, the drawings used in the description of the embodiments or the related art will be briefly described below. It is apparent that the drawings in the following descriptions are merely some embodiments of the present application. Other drawings can be obtained from those skilled in the art according to these drawings without any creative work.

FIG. 1 is a schematic diagram of an identity authentication method according to an embodiment of the present application.

FIG. 2 is a schematic diagram of a method for negotiating a message encryption key between a Requester (REQ) and an Authentication Access Controller (AAC) according to an embodiment of the present application.

FIG. 3 is a schematic diagram of an identity authentication method in a non-roaming case according to an embodiment of the present application.

FIG. 4 is a schematic diagram of another identity authentication method in a non-roaming case according to an embodiment of the present application.

FIG. 5 is a schematic diagram of an identity authentication method in a roaming case according to an embodiment of the present application.

FIG. 6 is a schematic diagram of another identity authentication method in a roaming case according to an embodiment of the present application.

FIG. 7 is a schematic diagram of still another identity authentication method in a non-roaming case according to an embodiment of the present application, wherein “*” represents an optional field or an optional operation.

FIG. 8 is a schematic diagram of yet another identity authentication method in a non-roaming case according to an embodiment of the present application, wherein “*” represents an optional field or an optional operation.

FIG. 9 is a schematic diagram of still another identity authentication method in a roaming case according to an embodiment of the present application, wherein “*” represents an optional field or an optional operation.

FIG. 10 is a schematic diagram of yet another identity authentication method in a roaming case according to an embodiment of the present application, wherein “*” represents an optional field or an optional operation.

FIG. 11 is a structural block diagram of an AAC according to an embodiment of the present application.

FIG. 12 is a structural block diagram of an REQ according to an embodiment of the present application.

FIG. 13 is a structural block diagram of a first AS (AS-AAC) according to an embodiment of the present application.

FIG. 14 is a structural block diagram of a second AS (AS-REQ) according to an embodiment of the present application.

FIG. 15 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

FIG. 16 is a schematic structural diagram of a chip according to an embodiment of the present application.

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. It is apparent that the described embodiments are only part of the embodiments of the present application, not all the embodiments. All other embodiments obtained by those of ordinary skill in the art on the basis of the embodiments in the present application without creative work all fall within the scope of protection of the present application.

The technical solutions described in the embodiments of the present application may be arbitrarily combined without conflict.

In a communication network, an REQ may access a network through an AAC. In order to ensure that the REQ accessing the network belongs to a legal user, the AAC needs to perform identity authentication on the REQ. Likewise, in order to ensure that the network which is accessed by the REQ belongs to a legal network, the REQ also needs to perform identity authentication on the AAC.

By using a current wireless communication and mobile communication scenario as an example, in a scenario that the REQ accesses a wireless network through the AAC, the REQ may be a terminal device such as a mobile phone, a Personal Digital Assistant (PDA) and a tablet computer, and the AAC may be a network-side device such as a wireless access node and a wireless router. In a scenario that the REQ accesses a wired network through the AAC, the REQ may be the terminal device such as a desktop computer and a notebook computer; and the AAC may be the network-side device such as a switch or a router. In a scenario that the REQ accesses a 4th/5th Generation mobile communication technology (4G/5G) network through the AAC, the REQ may be the terminal device such as the mobile phone and the tablet computer, and the AAC may be the network-side device such as a base station. Definitely, the present application is also suitable for various data communication scenarios such as other wired networks and short-range communication networks.

However, during the process of performing MIA between the REQ and the AAC, both the REQ and the AAC need to provide self-identity information for identity authentication. The identity information may generally be included in a physical digital certificate, and usually carries private and sensitive information. If, during identity authentication, the identity information is intercepted by an attacker for illegal use, a great security risk is caused to the AAC, the REQ and even the network.

In order to solve the above technical problems, an embodiment of the present application provides an identity authentication method. The method includes the following operations. An AAC acquires an identity ciphertext message sent by an REQ, where the identity ciphertext message includes identity information ciphertext of the REQ, and the identity information ciphertext is generated by using a public key of an encryption certificate to encrypt to-be-encrypted data including a digital certificate of the REQ and a second key; The AAC sends a first authentication request message to a first AS which is trusted by the AAC, where the first authentication request message includes the identity information ciphertext of the REQ and a digital certificate of the AAC. The AAC receives a first authentication response message sent by the first AS, where the first authentication response message includes first authentication result information, a first digital signature, second authentication result information ciphertext and a second digital signature, the first authentication result information includes a first verification result for the digital certificate of the AAC, the first digital signature is a digital signature which is generated by performing calculation on, by a second AS trusted by the REQ, to-be-signed data including the first authentication result information, the second authentication result information ciphertext is obtained by using the second key to encrypt information including second authentication result information, and the second digital signature is a digital signature which is generated by performing calculation on, by the first AS, to-be-signed data including the second authentication result information ciphertext. The AAC verifies the second digital signature by using a public key of the first AS, and sends a third authentication response message to the REQ if the verification is successful, where the third authentication response message includes authentication result information ciphertext; and the authentication result information ciphertext is generated by using a message encryption key to encrypt to-be-encrypted data including the first authentication result information and the first digital signature. The REQ uses the message encryption key to decrypt the authentication result information ciphertext, so as to obtain the first authentication result information and the first digital signature, verifies the first digital signature by using the public key of the second AS, and if the verification is successful, determines the identity authentication result of the AAC according to the first verification result in the first authentication result information; when determining that the AAC is legal, the REQ sends a fourth authentication response message to the AAC, where the fourth authentication response message includes second key ciphertext, and the second key ciphertext is obtained by using the message encryption key to encrypt information including the second key. The AAC uses the message encryption key to decrypt the second key ciphertext, so as to obtain the second key, uses the second key to decrypt the second authentication result information ciphertext, so as to obtain the second authentication result information, and determines an identity authentication result of the REQ according to the second verification result in the second authentication result information.

It is understandable that, the first authentication result information in this embodiment of the present application is obtained by performing, by the AS-AAC trusted by the AAC, legality verification on the digital certificate of the AAC; the second authentication result information is obtained by performing, by the AS-REQ trusted by the REQ, legality verification on the digital certificate of the REQ. The AS-AAC and the AS-REQ may be two independent servers for identity authentication, or the same server for identity authentication. The above are only some examples of the REQ, the AAC and AS, and shall not be understood as limitations to the REQ, the AAC and the AS. In other possible implementations of the embodiments of the present application, the REQ, the AAC and the AS may be other devices.

The identity authentication method provided in the embodiments of the present application is to implement MIA between the REQ and the AAC.

For ease of introduction, in the embodiments of the present application, the identity authentication method of the present application is introduced by using the REQ, the AAC and the AS as examples.

The AS trusted by the AAC is called the AS-AAC, and the AS trusted by the REQ is called the AS-REQ. The AS-AAC has the capability of verifying the legality of the digital certificate of the AAC; and the AS-AAC holds the digital certificate complying with regulations of ISO/IEC 9594-8/ITU X.509, other standards or other technical systems, and a private key corresponding to the digital certificate. The AS-REQ has the capability of verifying the legality of the digital certificate of the REQ; and the AS-REQ holds the digital certificate complying with regulations of ISO/IEC 9594-8/ITU X.509, other standards or other technical systems, and a private key corresponding to the digital certificate. A Certificate Sever-Decrypt (CS-DEC) holds an encryption certificate complying with regulations of ISO/IEC 9594-8/ITU X.509, other standards or other technical systems, and a private key corresponding to the encryption certificate. The AS-AAC and the AS-REQ have the capability of transmitting the digital certificate to other ASs for verification, and also have the capability of transmitting verification result information of the digital certificate to other ASs. When the AS-AAC is different from the AS-REQ, the AS-AAC and the AS-REQ are trusted with each other, and know each other's digital certificate or the public key in the digital certificate.

The REQ may be an endpoint involved in the identity authentication process, establishes a connection with the AAC, so as to access services provided by the AAC, and accesses the AS through the AAC. The REQ holds a digital certificate complying with regulations of ISO/IEC 9594-8/ITU X.509, other standards or other technical systems, and a private key corresponding to the digital certificate, knows a digital certificate of the AS-REQ or a public key in AS-REQ's digital certificate, and knows a encryption certificate of the CS-DEC or a public key in the encryption certificate. The CS-DEC may be an independent server, or may reside in the AS-REQ. The AAC may be the other endpoint involved in the identity authentication process, establishes a connection with the REQ, so as to provide services, communicates with the REQ, and may directly access the AS-AAC. The AAC holds a digital certificate complying with regulations of ISO/IEC 9594-8/ITU X.509, other standards or other technical systems, and a private key corresponding to the digital certificate, and knows the digital certificate of the AS-AAC or the public key in AS-AAC's digital certificate.

In combination with FIG. 1 , an identity authentication method provided in the embodiments of the present application is described below. The method includes the following operations.

At S 101 , an AAC acquires an identity ciphertext message REQInit sent by a REQ.

The REQInit includes identity information ciphertext EncPub AS of the REQ. The EncPub AS is generated by the REQ using a public key of an encryption certificate of the CS-DEC to encrypt to-be-encrypted data including the digital certificate Cert REQ of the REQ and a second key. Therefore, during the identity authentication process, the identity information of the REQ is subjected to confidential processing, so as to prevent the identity information of the REQ from being exposed during transmission. In the present application, an object to be encrypted is called the to-be-encrypted data.

At S 102 , the AAC sends a first authentication request message AACVeri to an AS-AAC trusted by the AAC.

The AACVeri includes the digital certificate Cert AAC of the AAC and the EncPub AS .

At S 103 , the AAC receives a first authentication response message ASVeri sent by the AS-AAC.

The ASVeri includes a first authentication result information, a first digital signature, a second authentication result information ciphertext and a second digital signature. The first authentication result information includes a first verification result Res AAC for the Cert AAC . The first digital signature is a digital signature which is generated by an AS-REQ trusted by the REQ performing calculation on to-be-signed data including the first authentication result information. The second authentication result information ciphertext is obtained by using the second key to encrypt information including second authentication result information. The second authentication result information includes a second verification result Res REQ for the Cert REQ . The second digital signature is a digital signature which is generated by the AS-AAC performing calculation on to-be-signed data including the second authentication result information ciphertext. In the present application, an object to be signed is called the to-be-signed data.

It is to be noted that, if the AS-REQ trusted by the REQ and the AS-AAC trusted by the AAC are the same AS, that is, the REQ and the AAC commonly trust the same AS, in this case, the AS commonly trusted by the REQ and the AAC may be represented by the AS-AAC (or the AS-REQ). In this case, the AS-AAC (or the AS-REQ) may be used to perform legality verification on the Cert AAC to obtain the Res AAC , and perform legality verification on the Cert REQ obtained by decrypting the EncPub AS , so as to obtain the Res REQ . The AS-AAC (or the AS-REQ) may decrypt the EncPub AS by using the private key corresponding to the encryption certificate of the CS-DEC resided in the AS-AAC (or the AS-REQ), or the AS-AAC (or the AS-REQ) may send the EncPub AS to the CS-DEC having an interaction and trust relationship with the AS-AAC (or the AS-REQ) for decryption, and acquire the Cert REQ obtained by means of decryption. Then, the AS-AAC (or the AS-REQ) may generate the first authentication result information according to the information including the Res AAC , generate the second authentication result information according to the information including the Res REQ , use the second key obtained by decrypting the EncPub AS to encrypt the information including the second authentication result information, so as to generate the second authentication result information ciphertext, perform calculation on the to-be-signed data including the first authentication result information to generate the first digital signature Sig AS_AAC1 (or Sig AS_REQ1 ), perform calculation on the to-be-signed data including the second authentication result information ciphertext to generate the second digital signature Sig AS_AAC2 (or Sig AS_REQ2 ), and generate the first authentication response message ASVeri according to the information including the first authentication result information, the first digital signature Sig AS_AAC1 (or Sig AS_REQ1 ), the second authentication result information ciphertext, and the second digital signature Sig AS_AAC2 (or Sig AS_REQ2 ).

If the AS-REQ trusted by the REQ and the AS-AAC trusted by the AAC are two different ASs, the AS-AAC performs legality verification on the Cert AAC to obtain the Res AAC , and the AS-REQ performs legality verification on the Cert REQ obtained by decrypting the EncPub AS , so as to obtain the Res REQ . Therefore, after generating the first authentication result information, the AS-AAC sends a second authentication request message AS-AACVeri to the AS-REQ. The AS-AACVeri includes the first authentication result information, the EncPub AS , and a third digital signature Sig AS_AAC3 . The Sig AS_AAC3 is generated by the AS-AAC performing calculation for to-be-signed data including the first authentication result information and the EncPub AS . The AS-REQ verifies the Sig AS_AAC3 by using the public key of the AS-AAC; if the verification is successful, the AS-REQ performs legality verification on the Cert REQ obtained by decrypting the EncPub AS , so as to obtain the Res REQ , and generates the second authentication result information according to the information including the Res REQ . The AS-REQ decrypts the EncPub AS by using the private key corresponding to the encryption certificate of the CS-DEC resided in the AS-REQ; or the AS-REQ may send the EncPub AS to the CS-DEC having an interaction and trust relationship with the AS-REQ for decryption, and acquire the Cert REQ obtained by means of decryption. The AS-REQ uses the second key obtained by decrypting the EncPub AS to encrypt the information including the second authentication result information, so as to generate the second authentication result information ciphertext, and sends the second authentication response message AS-REQVeri to the AS-AAC. The AS-REQVeri includes the first authentication result information ciphertext, the Sig AS_REQ1 , the second authentication result information ciphertext and the Sig AS_REQ4 . The Sig AS_REQ1 is generated by the AS-REQ performing calculation for the to-be-signed data including the first authentication result information; and the Sig AS_REQ4 is generated by the AS-REQ performing calculation on the to-be-signed data including the second authentication result information ciphertext. After receiving the AS-REQVeri, the AS-AAC verifies the Sig AS_REQ4 by using the public key of the AS-REQ. If the verification is successful, the AS-AAC performs calculation on the to-be-signed data including the second authentication result information ciphertext, so as to generate the Sig AS_AAC2 , and generates the first authentication response message ASVeri according to the information including the first authentication result information, the Sig AS_REQ1 , the second authentication result information ciphertext and the Sig AS_AAC2 .

At S 104 , the AAC verifies the second digital signature by using the public key of the AS-AAC.

If the verification is successful, the AAC executes the following operations.

At S 105 , the AAC sends a third authentication response message AACAuth to the REQ.

The AACAuth includes authentication result information ciphertext EncData AAC . The EncData AAC is generated by the AAC using the message encryption key to encrypt to-be-encrypted data including the first authentication result information and the first digital signature.

At S 106 , the REQ decrypts the EncData AAC by using the message encryption key, so as to obtain the first authentication result information and the first digital signature.

The message encryption key may be obtained by means of negotiation between the REQ and the AAC, or may be shared by the REQ and the AAC in advance. Since the AAC uses the message encryption key to encrypt the to-be-encrypted data including the first authentication result information and the first digital signature via a symmetric encryption algorithm, so as to obtain the EncData AAC , after receiving the AACAuth, the AAC may decrypt the EncData AAC by using the message encryption key, so as to obtain the first authentication result information and the first digital signature.

At S 107 , the REQ verifies the first digital signature by using the public key of the AS-REQ.

At S 108 , the REQ determines the identity authentication result of the AAC according to the Res AAC in the first authentication result information.

At S 109 , the REQ sends a fourth authentication response message REQAuth to the AAC.

The REQAuth includes second key ciphertext, and the second key ciphertext is obtained by the REQ using the message encryption key to encrypt information including the second key.

It is to be noted that, the order of execution of S 107 to S 109 does not affect the implementation of the present application, and in practical applications, the order of execution of S 107 to S 109 may be set according to requirements. Preferably, it is recommended that S 107 is executed first. When the verification for first digital signature by the REQ is failed, the AACAuth is discarded. When the REQ has verified the first digital signature. S 108 is then executed. When the REQ determines that the AAC is legal, S 109 is then executed. When the REQ determines that the AAC is illegal, the REQ determines according to a local policy, whether to execute S 109 . Considering the efficiency, the preferred solution is not to perform and terminate this authentication process.

At S 110 , the AAC uses the message encryption key to decrypt the second key ciphertext, so as to obtain the second key, and uses the second key to decrypt the second authentication result information ciphertext, so as to obtain the second authentication result information.

At S 111 , the AAC determines an identity authentication result of the REQ according to the Res REQ in the second authentication result information.

From the above technical solutions, it can be seen that, identify information of the REQ is subjected to confidential processing during authentication, and when the identify information is transmitted between the REQ and the AAC, the identify information of the AAC is subjected to confidential processing, so as to prevent the identify information of the REQ and the AAC from being exposed during a transmission process, thereby ensuring that an attacker cannot obtain private and sensitive information. Moreover, by means of involving an AS, MIA between the REQ and the AAC is achieved while the confidentiality of entity identity related information is guaranteed, such that the foundation that only a legal user can communicate with a legal network is laid.

In some embodiments, the REQInit of S 101 may further include a digital signature Sig REQ of the REQ; and the to-be-signed data of the Sig REQ includes other fields before the Sig REQ in the REQInit. Before S 111 , the AAC further needs to determine whether the verification of the Sig REQ is successful, and S 111 can only be executed when the verification is successful. It is to be noted that, if the AS-REQ and the AS-AAC are the same AS, the Sig REQ may be verified by the AS-AAC (which may also be represented as the AS-REQ), or may be verified by the AAC; and if the AS-REQ and the AS-AAC are two different ASs, the Sig REQ may be verified by the AS-REQ, or may be verified by the AAC. The AAC determines, by means of the following manners, whether the verification of the Sig REQ is successful in a manner including any of the following manners.

As an embodiment in which the AS verifies the Sig REQ , in a case that the AS-REQ and the AS-AAC are the same AS (non-roaming), when the AS-AAC (which may also be represented as the AS-REQ) verifies the Sig REQ , the Sig REQ may be carried in the AACVeri of S 102 and transmitted to the AS-AAC (which may also be represented as the AS-REQ), and the AS-AAC (which may also be represented as the AS-REQ) verifies the Sig REQ by using the Cert REQ obtained by decrypting the EncPub AS in the AACVeri; if the verification is successful, steps of generating and sending the first authentication response message ASVeri, etc. are continued to be executed; and if the verification is failed, the steps of generating and sending the first authentication response message ASVeri, etc. are not executed. Therefore, the AAC may determine, according to whether the first authentication response message ASVeri can be received, whether the verification of the Sig REQ is successful; and if the AAC can receive the ASVeri of S 103 , the AAC may determine that the verification of the Sig REQ is successful.

As another embodiment in which the Sig REQ is verified by the AS, in a case that the AS-REQ and the AS-AAC are two different ASs (roaming), when the AS-REQ verifies the Sig REQ , the Sig REQ may be carried in the AACVeri of S 102 and the second authentication request message AS-AACVeri sent by the AS-AAC to the AS-REQ and transmitted to the AS-REQ, and the AS-REQ verifies the Sig REQ by using the Cert REQ obtained by decrypting the EncPub AS in the AS-AACVeri; if the verification is successful, steps of generating and sending the second authentication response message AS-REQVeri and generating and sending the subsequent ASVeri are continued to be executed; and if the verification is failed, the steps of generating and sending the AS-REQVeri and generating and sending the subsequent ASVeri are not executed. Therefore, the AAC may determine, according to whether the ASVeri can be received, whether the verification of the Sig REQ is successful; and if the AAC can receive the ASVeri of S 103 , the AAC may determine that the verification of the Sig REQ is successful.

As an embodiment in which the Sig REQ is verified by the AAC, the second authentication result information generated by the AS not only includes the Res REQ , but also includes the Cert REQ . After the AAC receives the REQAuth of S 109 , the second authentication result information obtained by using the second key to decrypt the second authentication result information ciphertext further includes the Cert REQ and the Sig REQ is verified by using the Cert REQ in the second authentication result information, such that whether the verification of the Sig REQ is successful is determined.

In some other embodiments, the REQAuth of S 109 may further include a digital signature Sig REQ of the REQ. The to-be-signed data of the Sig REQ includes other fields before the Sig REQ in the REQAuth. In this case, in S 110 , the second authentication result information obtained by the AAC using the second key to decrypt the second authentication result information ciphertext further includes the Cert REQ . Before S 111 , the AAC further needs to verify the Sig REQ by using the Cert REQ in the second authentication result information, to determine whether the verification of the Sig REQ is successful according to the verification result; and S 111 can only be executed when the verification is successful.

In some embodiments, the AACVeri of S 102 may further include a digital signature Sig AAC of the AAC. The to-be-signed data of the Sig AAC includes other fields before the Sig AAC in the AACVeri. Then before S 108 , the REQ further needs to determine whether the verification of the Sig AAC is successful, and S 108 can only be executed when the verification is successful. The REQ determines whether the verification of the Sig AAC is successful in the following manner: the AS-AAC trusted by the AAC verifies the Sig AAC by using the Cert AAC in the AACVeri, and subsequent processes are continued to be executed after the verification is successful, such that if the REQ can receive the AACAuth of S 105 , the REQ determines that the verification of the Sig AAC has passed.

In some other embodiments, the AACAuth of S 105 may further include the Sig AAC of the AAC. The to-be-signed data of the Sig AAC includes other fields before the Sig AAC in the AACAuth. Correspondingly, in the AACAuth, the first authentication result information in the to-be-encrypted data of the EncData AAC further includes the Cert AAC . Then before S 108 , the REQ further needs to determine whether the verification of the Sig AAC is successful, and S 108 can only be executed when the verification is successful. The REQ determines whether the verification of the Sig AAC is successful in the following manner: The REQ verifies the Sig AAC by using the Cert AAC in the first authentication result information that is obtained by decrypting the EncData AAC , to determine whether the verification of the Sig AAC is successful according to the verification result.

Referring to FIG. 1 , messages transmitted among the REQ, the AAC and the AS may further include parameter information such as random numbers generated by the AAC and/or the REQ, and identity identifiers. Normally, during identity authentication, these random numbers and/or identity identifiers should remain unchanged during the process of being transmitted through the messages, but in the event of network jitter or attacks, etc., this may result in the loss or tampering of the parameter information in messages. Therefore, the consistency of the identity identifiers and/or the random numbers in the messages may further be verified during identity authentication, so as to guarantee the reliability of authentication results. Examples are as follows.

For example, in the REQInit of S 101 , the to-be-encrypted data when the REQ generates identity information ciphertext EncPub AS may further include an identity identifier ID REQ of the REQ and a third key Nonce REQID . The Nonce REQID is used for encrypting the ID REQ . The AACVeri of S 102 may further include an identity identifier ID AAC of the AAC. Correspondingly, the ASVeri of S 103 further includes identity identifier ciphertext of the REQ and the ID AAC . The to-be-encrypted data of the EncData AAC in the AACAuth of S 105 further includes the identity identifier ciphertext of the REQ. The identity identifier ciphertext of the REQ is obtained by using the Nonce REQID to encrypt the ID REQ . For example, an exclusive or operation (XOR) is performed on the Nonce REQID and the ID REQ , that is, the ID REQ ⊕Nonce REQID is used as the identity identifier ciphertext of the REQ. Therefore, before S 108 , the REQ uses the message encryption key to decrypt the EncData AAC , so as to further obtain the identity identifier ciphertext of the REQ. The REQ further needs to verify, according to the self ID REQ and the Nonce REQID , the identity identifier ciphertext of the REQ that is obtained by decrypting the EncData AAC . For example, the verification may include the following. The REQ uses the Nonce REQID to encrypt the information including the self ID REQ of the REQ, so as to generate the identity identifier ciphertext of the REQ, and verifies consistency of the generated identity identifier ciphertext of the REQ and the identity identifier ciphertext of the REQ that is obtained by decrypting the EncData AAC . Alternatively, the REQ uses the Nonce REQID to decrypt the identity identifier ciphertext of the REQ, so as to obtain the ID REQ , and verifies consistency of the ID REQ obtained by means of decryption and the self ID REQ of the REQ. After the verification is successful, the REQ then executes S 108 . Before S 111 , the AAC may verify the consistency of the ID AAC in the ASVeri and the self-identity identifier ID AAC (which is the ID AAC sent by the AAC through the AACVeri) of the AAC. After the verification is successful, the AAC then executes S 111 .

Similar to the identity identifier, the REQInit of S 101 may further include a second random number Nonce REQ generated by the REQ; the AACVeri of S 102 may further include the Nonce REQ and a first random number Nonce AAC generated by the AAC. Then the ASVeri of S 103 may further include the Nonce REQ and the Nonce AAC and the to-be-encrypted data of the EncData AAC in the AACAuth of S 105 may further include the Nonce REQ . Before S 108 , the REQ decrypts the EncData AAC to further obtain the Nonce REQ , and verifies the consistency of the Nonce REQ obtained by means of decryption and the Nonce REQ generated by the REQ. After the verification is successful. S 108 is then executed. Before S 111 , the AAC may verify the consistency of the Nonce AAC in the ASVeri and the Nonce AAC generated by the AAC. After the verification is successful. S 111 is then executed.

In some other embodiments, in order to guarantee the reliability of the authentication results, the AAC may generate a message integrity check code. The AACAuth of S 105 may further include a first message integrity check code MacTag AAC . The MacTag AAC is generated by the AAC using a message integrity check key to perform calculation on fields, other than the MacTag AAC , in the AACAuth. Correspondingly, before S 108 , the REQ further needs to verify the MacTag AAC . After the verification is successful. S 108 is then executed. When verifying the MacTag AAC , the REQ should use the message integrity check key to perform calculation on the fields, other than the MacTag AAC , in the AACAuth, so as to generate the MacTag AAC , and compare the calculated MacTag AAC with the MacTag AAC in the received AACAuth. If the MacTag AAC s are consistent, the verification is successful. If the MacTag AAC s are not consistent, the verification is failed.

Likewise, the REQ may also generate the message integrity check code. The REQAuth of S 109 may further include a second message integrity check code MacTag REQ . The MacTag REQ is generated by the REQ using the message integrity check key to perform calculation on fields, other than the MacTag REQ , in the REQAuth. Correspondingly, before S 111 , the AAC further needs to verify the MacTag REQ . After the verification is successful. S 111 is then executed. When verifying the MacTag REQ , the AAC should use the message integrity check key to perform calculation on the fields, other than the MacTag REQ , in the REQAuth, so as to generate a MacTag REQ , and compare the calculated MacTag REQ with the MacTag REQ in the received REQAuth. If the MacTag REQ s are consistent, the verification is successful. If the MacTag AAC s are not consistent, the verification is failed. The manner of generating the message integrity check key used by the REQ and the AAC is described in the next embodiment.

In the above embodiments, the message encryption keys used by the REQ and the AAC may be obtained by means of negotiation between the REQ and the AAC. Therefore, this embodiment further provides a method for negotiating the message encryption key between the REQ and the AAC. Referring to FIG. 2 , the method includes the following operations.

At S 201 , the AAC sends a key request message AACInit to the REQ.

The AACInit includes a key exchange parameter KeyInfo AAC of the AAC. The KeyInfo AAC includes a temporary public key of the AAC. Key exchange refers to a key exchange algorithm such as Diffie-Hellman (DH). The AACInit may further include the Nonce AAC generated by the AAC.

The AACInit may further include Security capabilities AAC . The Security capabilities AAC represents security capability parameter information supported by the AAC, including an identity authentication suite (which includes one or more identity authentication methods) supported by the AAC, one or more symmetric encryption algorithms, one or more integrity checking algorithms and/or one or more key derivation algorithms, so as to allow the REQ to select a specific security policy for use. Therefore, the REQ may select, according to the Security capabilities AAC , the specific security policy Security capabilities REQ used by the REQ. The Security capabilities REQ indicates an identity authentication method, a symmetric encryption algorithm, an integrity checking algorithm and/or a key derivation algorithm the REQ correspondingly determines to use.

At S 202 , the REQ performs key exchange calculation according to information including a temporary private key corresponding to a key exchange parameter KeyInfo REQ of the REQ and a temporary public key included in the KeyInfo AAC , so as to generate a first key, and calculates the message encryption key by using the key derivation algorithm according to the information including the first key.

If the AACInit in S 201 further includes the Nonce AAC generated by the AAC, the REQ may perform key exchange calculation according to information including the temporary private key corresponding to the KeyInfo REQ and the temporary public key included in the KeyInfo AAC , so as to generate the first key K 1 , combines the K 1 with the information including the Nonce AAC and the Nonce REQ generated by the REQ, to calculate the message encryption key using the negotiated or preset key derivation algorithm. The negotiated key derivation algorithm may be a key derivation algorithm that the REQ selects to use according to the Security capabilities AAC sent by the AAC. The KeyInfo REQ is a key exchange parameter generated by the REQ, the key exchange parameter includes the temporary public key of the REQ. The temporary private key corresponding to the KeyInfo REQ is a temporary private key that is generated by the REQ and corresponds to the temporary public key of the REQ. That is, the temporary public key and the temporary private key are a temporary public-private key pair.

At S 203 , the REQ sends an identity ciphertext message REQInit to the AAC.

The REQInit includes the KeyInfo REQ , such that the AAC obtains the message encryption key by perform calculation according to information including the temporary private key corresponding to the KeyInfo AAC and the temporary public key included in the KeyInfo REQ . The temporary private key corresponding to the KeyInfo AAC is a temporary private key that is generated by the AAC and corresponds to the temporary public key of the AAC. That is, the temporary public key and the temporary private key are a temporary public-private key pair.

The REQInit may further include the Security capabilities REQ . The REQInit may further include the Nonce REQ , such that the AAC obtains the message encryption key by perform calculation according to information including the temporary private key corresponding to the KeyInfo AAC , the temporary public key included in the KeyInfo REQ , the Nonce AAC and the Nonce REQ .

The REQInit may further include the Nonce AAC , such that before performing the calculation for obtaining the message encryption key, the AAC may verify the consistency of the Nonce AAC in the REQInit and the Nonce AAC generated by the AAC, so as to ensure that the REQInit received by the AAC is a response message for the AACInit.

At S 204 , the AAC performs key exchange calculation according to information including the temporary private key corresponding to the KeyInfo AAC and the temporary public key included in the KeyInfo REQ , so as to generate the first key, and calculates the message encryption key by using the key derivation algorithm according to the information including the first key.

If the REQInit further includes the Nonce REQ , the AAC may perform key exchange calculation according to information including the temporary private key corresponding to the KeyInfo AAC and the temporary public key included in the KeyInfo REQ , so as to generate the first key K 1 , combines the K 1 with the information including the Nonce AAC and the Nonce REQ , to calculate the message encryption key by means of the negotiated or preset key derivation algorithm. The negotiated key derivation algorithm may be a key derivation algorithm that the AAC selects to use according to the Security capabilities REQ sent by the REQ.

It is to be noted that, in the embodiment of FIG. 2 , the REQ and the AAC may also generate the message integrity check key. The implementations of the REQ and the AAC to respectively generate the message integrity check key are the same as the implementations of the REQ and the AAC to respectively generate the message encryption key in the embodiment of FIG. 2 . For example, the AAC may derive a string of key data by using the key derivation algorithm in the manner of the embodiment of FIG. 2 . The key data may be used as the message encryption key and may also be the message integrity check key. Alternatively, one portion of the key data is used as the message encryption key, and the other portion of the key data is used as the message integrity check key. The AAC may also derive two same or different strings of key data in batches by using the key derivation algorithm in the manner of the embodiment of FIG. 2 , one string is used as the message encryption key, and the other one string is used as the message integrity check key. The REQ may derive a string of key data by using the key derivation algorithm in the manner of the embodiment of FIG. 2 . The key data may be used as the message encryption key and may also be the message integrity check key. Alternatively, one portion of the key data is used as the message encryption key, and the other portion of the key data is used as the message integrity check key. The REQ may also derive two same or different strings of key data in batches by using the key derivation algorithm in the manner of the embodiment of FIG. 2 , one string is used as the message encryption key, and the other one string is used as the message integrity check key.

An embodiment of the present application further provides a method for determining the first authentication server AS-AAC and/or the second authentication server AS-REQ used during the current authentication process by using an information interaction between the AAC and the REQ.

Referring to FIG. 2 , the AAC adds, in the AACInit of S 201 , the identity identifier ID AS_AAC of at least one authentication server AS trusted by the AAC. Then the REQ determines, according to the ID AS_AAC , the ID AS_REQ of at least one authentication server AS trusted by the REQ. During implementation, the REQ selects, from the ID AS_AAC , at least one authentication server AS that is trusted by the REQ as the ID AS_REQ . If the selection is failed, the REQ uses the at least one authentication server that is trusted by the REQ as the ID AS_REQ (successful selection corresponds to a non-roaming case, and failed selection corresponds to a roaming case), and add the ID AS_REQ into the REQInit of S 203 and send it to the AAC. Therefore, the AAC may determine the first authentication server according to the ID AS_AAC and the ID AS_REQ . For example, the AAC may determine whether there is at least one same identity identifier of authentication server in the ID AS_REQ and the ID AS_AAC . If yes (that is the non-roaming case), the AAC determines the first authentication server involved in identity authentication from the identity identifier of the at least one authentication server that is commonly trusted by the REQ and the AAC. If no (that is the roaming case), the AAC needs to determine, according to the ID AS_AAC , the first authentication server AS-AAC involved in identity authentication, and sends the ID AS_REQ to the AS-AAC, such that the AS-AAC determines the second authentication server AS-REQ according to the ID AS_REQ .

As another implementation, the AAC may not have to send the ID AS_AAC to the REQ, and the REQ adds, in the REQInit of S 203 , the identity identifier ID AS_REQ of at least one authentication server AS that is trusted by the REQ. The determination of the first authentication server AS-AAC and/or the second authentication server AS-REQ involved in the identity authentication process according to the ID AS_REQ and the ID AS_AAC of the AS trusted by the AAC is implemented as in the previous implementation.

Since the AS trusted by the REQ and the AS trusted by the AAC may be the same or different, when the AS trusted by the REQ and the AS trusted by the AAC are the same, it is the non-roaming case, and when the AS trusted by the REQ and the AS trusted by the AAC are different, it is the roaming case.

FIG. 3 is an embodiment of the identity authentication method in the non-roaming case. An AS-AAC (or an AS-REQ) may be used to represent an AS commonly trusted by a REQ and an AAC, and a digital signature Sig REQ of the REQ may also be verified during identity authentication. Before this embodiment is executed, the REQ and the AAC both have held a message encryption key. The message encryption key may be shared in advance by both parties, or may be obtained by means of negotiation by the method shown in FIG. 2 . The identity authentication method for verifying the Sig REQ by the AAC includes the following operations.

At S 301 , the AAC acquires the identity ciphertext message REQInit sent by the REQ.

The REQInit includes the identity information ciphertext EncPub AS of the REQ and the digital signature Sig REQ of the REQ.

At S 302 , the AAC sends a first authentication request message AACVeri to the AS-AAC.

The AACVeri includes the EncPub AS and the Cert AAC of the AAC.

At S 303 , the AS-AAC decrypts the EncPub AS by using the private key corresponding to the encryption certificate, so as to obtain the Cert REQ of the REQ and the second key Nonce REQ , respectively performs legality verification on the Cert AAC and the Cert REQ , so as to obtain the first verification result Res AAC of the Cert AAC and the second verification result Res REQ of the Cert REQ , generates the first authentication result information according to the information including the Cert AAC and the Res AAC , generates the second authentication result information according to the information including the Cert REQ and the Res REQ , generates the first digital signature Sig AS_AAC1 by perform calculation on the to-be-signed data including the first authentication result information, generates the second authentication result information ciphertext by encrypting the information including the second authentication result information using the Nonce REQPub , and generates the second digital signature Sig AS_AAC2 by performing calculation on the to-be-signed data including the second authentication result information ciphertext.

At S 304 , the AAC receives a first authentication response message ASVeri sent by the AS-AAC.

The ASVeri includes the first authentication result information, the first digital signature Sig AS_AAC1 , the second authentication result information ciphertext and the second digital signature Sig AS_AAC2 .

At S 305 , the AAC verifies the Sig AS_AAC2 by using the public key of the AS-AAC. If the verification is successful, the AAC uses the message encryption key to encrypt the to-be-encrypted data including the first authentication result information and the Sig AS_AAC1 , so as to generate the authentication result information ciphertext EncData AAC , and generates the digital signature Sig AAC of the AAC by performing calculation for he to-be-signed data including the EncData AAC .

At S 306 , the AAC sends a third authentication response message AACAuth to the REQ.

The AACAuth includes the EncData AAC and the Sig AAC .

At S 307 , the REQ uses the message encryption key to decrypt the EncData AAC , so as to obtain the first authentication result information and the Sig AS_AAC1 .

At S 308 , the REQ verifies the Sig AS_AAC1 by using the public key of the AS-AAC, and verifies the Sig AAC by using the Cert AAC in the first authentication result information.

If the verifications all pass. S 309 is then executed.

At S 309 , the REQ determines the identity authentication result of the AAC according to the Res AAC in the first authentication result information.

When the REQ determines that the AAC is legal. S 310 is executed; and when the REQ determines that the AAC is illegal, the current authentication process is terminated.

At S 310 , the REQ uses the message encryption key to encrypt the information including the second key Nonce REQPub , so as to obtain second key ciphertext EncData REQ .

At S 311 , the REQ sends a fourth authentication response message REQAuth to the AAC.

The REQAuth includes the EncData REQ .

At S 312 , the AAC uses the message encryption key to decrypt the EncData REQ , so as to obtain the Nonce REQPub , and uses the Nonce REQPub to decrypt the second authentication result information ciphertext, so as to obtain the second authentication result information.

At S 313 , the AAC verifies the Sig REQ of the REQ by using the Cert REQ in the second authentication result information that is obtained by means of decryption.

If the verification is successful. S 314 is then executed.

At S 314 , the AAC determines an identity authentication result of the REQ according to the Res REQ in the second authentication result information that is obtained by means of decryption.

It is to be noted that, (1) the REQInit of S 301 may not include the Sig REQ , while the Sig REQ is added in the REQAuth of S 311 . That is to say, in S 311 , the REQ first generates the Sig REQ by performing calculation on the to-be-signed data including the EncData REQ in the REQAuth. In this case, the Sig REQ verified by the AAC in S 313 is the Sig REQ in the REQAuth. (2) The operation of calculating the Sig AAC in S 305 may also be changed to be previously executed in S 302 . That is, in S 302 , the AAC first generates the Sig AAC by performing calculation for the to-be-signed data including the EncPub AS in the AACVeri and the Cert AAC , and then the AACVeri of S 302 further includes the Sig AAC . In S 303 , the AS-AAC further needs to verify the Sig AAC ; and then executes follow-up operations after the verification is successful. In this case, the AAC in S 305 does not need to calculate the Sig AAC . Correspondingly, the AACAuth of S 306 does not include the Sig AAC , the REQ in S 308 does not verify the Sig AAC , and in this case, the first authentication result information may not include the Cert AAC .

FIG. 4 is another embodiment of the identity authentication method in the non-roaming case. An AS-AAC (or an AS-REQ) may be used to represent an AS commonly trusted by a REQ and an AAC, and the Sig REQ of the REQ may also be verified during identity authentication. Before this embodiment is executed, the REQ and the AAC both have held a message encryption key. The message encryption key may be shared in advance by both parties, or may be obtained by means of negotiation by the method shown in FIG. 2 . The identity authentication method for verifying the Sig REQ by the AS-AAC includes the following operations.

At S 401 , the AAC acquires an identity ciphertext message REQInit sent by the REQ.

The REQInit includes identity information ciphertext EncPub AS of the REQ and a digital signature Sig REQ of the REQ.

At S 402 , the AAC sends a first authentication request message AACVeri to the AS-AAC.

The AACVeri includes the REQInit and the Cert AAC of the AAC.

At S 403 , the AS-AAC uses the private key corresponding to the encryption certificate to decrypt the EncPub AS in the REQInit, so as to obtain the Cert REQ of the REQ and the second key Nonce REQPub , and verifies the Sig REQ by using the Cert REQ .

If the verification is successful, S 404 is then executed.

At S 404 , the AS-AAC performs legality verification on the Cert AAC and the Cert REQ , so as to obtain the first verification result Res AAC of the Cert AAC and the second verification result Res REQ of the Cert REQ , generates a first authentication result information according to the information including the Cert AAC and the Res AAC , generates a second authentication result information according to the information including the Res REQ , generates a first digital signature Sig AS_AAC1 by performing calculation on the to-be-signed data including the first authentication result information, generates a second authentication result information ciphertext by encrypting the information including the second authentication result information using the Nonce REQPub , and generates a second digital signature Sig AS_AAC2 by performing calculation on the to-be-signed data including the second authentication result information ciphertext.

At S 405 , the AAC receives a first authentication response message ASVeri sent by the AS-AAC.

The ASVeri includes the first authentication result information, the first digital signature Sig AS_AAC1 , the second authentication result information ciphertext and the second digital signature Sig AS_AAC2 .

At S 406 , the AAC verifies the Sig AS_AAC2 by using the public key of the AS-AAC. After the verification is successful, the AAC uses the message encryption key to encrypt the to-be-encrypted data including the first authentication result information and the Sig AS_AAC1 , so as to generate the authentication result information ciphertext EncData AAC , and generates the digital signature Sig AAC of the AAC by performing calculation on the to-be-signed data including the EncData AAC .

At S 407 , the AAC sends a third authentication response message AACAuth to the REQ.

The AACAuth includes the EncData AAC and the Sig AAC .

At S 408 , the REQ uses the message encryption key to decrypt the EncData AAC , so as to obtain the first authentication result information and the Sig AS_AAC1 .

At S 409 , the REQ verifies the Sig AS_AAC1 by using the public key of the AS-AAC, and verifies the Sig AAC by using the Cert AAC in the first authentication result information.

If the verifications all pass, S 410 is then executed.

At S 410 , the REQ determines the identity authentication result of the AAC according to the Res AAC in the first authentication result information.

When the REQ determines that the AAC is legal. S 411 is executed. When the REQ determines that the AAC is illegal, the current authentication process is terminated.

At S 411 , the REQ uses the message encryption key to encrypt the information including the second key Nonce REQPub , so as to obtain second key ciphertext EncData REQ .

At S 412 , the REQ sends a fourth authentication response message REQAuth to the AAC.

The REQAuth includes the EncData REQ .

At S 413 , the AAC uses the message encryption key to decrypt the EncData REQ , so as to obtain the Nonce REQPub , and uses the Nonce REQPub to decrypt the second authentication result information ciphertext, so as to obtain the second authentication result information.

At S 414 , the AAC determines an identity authentication result of the REQ according to the Res REQ in the second authentication result information that is obtained by means of decryption.

It is to be noted that, the operation of calculating the Sig AAC in S 406 may also be changed to be previously executed in S 402 . That is, in S 402 , the AAC first generates the Sig AAC by performing calculation on the to-be-signed data including the REQInit in the AACVeri and the Cert AAC , and the AACVeri of S 402 further includes the Sig AAC . In S 403 , the AS-AAC further needs to verify the Sig AAC ; and then executes follow-up operations after the verification is successful. In this case, the AAC in S 406 does not need to calculate the Sig AAC . Correspondingly, the AACAuth of S 407 does not include the SigAAC, the REQ in S 409 does not verify the Sig AAC , and in this case, the first authentication result information may not include the Cert AAC .

FIG. 5 is an embodiment of the identity authentication method in the roaming case. In this case, an AS-AAC and an AS-REQ are trusted with each other, know each other's digital certificate or a public key in a digital certificate, and a digital signature Sig REQ of a REQ may also be verified during identity authentication. Before this embodiment is executed, the REQ and an AAC both have held a message encryption key. The message encryption key may be shared in advance by both parties, or may be obtained by means of negotiation by the method shown in FIG. 2 . The identity authentication method for verifying the Sig REQ by the AAC includes the following operations.

At S 501 , the AAC acquires an identity ciphertext message REQInit sent by the REQ.

The REQInit includes identity information ciphertext EncPub AS of the REQ, the identity identifier ID AS_REQ of at least one AS trusted by the REQ, and a digital signature Sig REQ of the REQ.

At S 502 , the AAC sends a first authentication request message AACVeri to the AS-AAC.

The AACVeri includes the EncPub AS , a Cert AAC of the AAC, and the ID AS_REQ , such that the AS-AAC performs legality verification on the Cert AAC , so as to obtain a Res AAC , generates first authentication result information according to the information including the Cert AAC and the Res AAC , and then determines, according to the ID AS_REQ , the AS-REQ used during the current authentication process.

At S 503 , the AS-AAC sends a second authentication request message AS-AACVeri to the AS-REQ.

The AS-AACVeri includes the first authentication result information, the EncPub AS and a third digital signature Sig AS_AAC3 . The Sig AS_AAC3 is generated by the AS-AAC performing calculation on to-be-signed data including the first authentication result information and the EncPub AS .

At S 504 , the AS-REQ verifies the Sig AS_AAC by using the public key of the AS-AAC.

If the verification is successful. S 505 is then executed.

At S 505 , the AS-REQ uses a private key corresponding to an encryption certificate to decrypt the EncPub AS , so as to obtain a Cert REQ and a second key Nonce REQPub .

At S 506 , the AS-REQ performs legality verification on the Cert REQ to obtain a Res REQ , so as to obtain the second authentication result information according to the information including the Cert REQ and the Res REQ , uses the Nonce REQPub to encrypt the information including the second authentication result information, so as to generate the second authentication result information ciphertext, generates a first digital signature Sig AS_REQ1 by performing calculation on to-be-signed data including the first authentication result information, and generates a fourth digital signature Sig AS_REQ4 by performing calculation on to-be-signed data including the second authentication result information ciphertext.

At S 507 , the AS-REQ sends a second authentication response message AS-REQVeri to the AS-AAC.

The AS-REQVeri includes the first authentication result information, the first digital signature Sig AS_REQ1 , the second authentication result information ciphertext and the fourth digital signature Sig AS_REQ4 .

At S 508 , the AS-AAC verifies the Sig AS_REQ4 by using the public key of the AS-REQ.

If the verification is successful. S 509 is executed.

At S 509 , the AS-AAC generate a second digital signature Sig AS_AAC2 by performing calculation on to-be-signed data including the second authentication result information ciphertext, and generates a first authentication response message ASVeri according to the information including the first authentication result information, the first digital signature Sig AS_REQ1 , the second authentication result information ciphertext and the second digital signature Sig AS_AAC2 .

At S 510 , the AS-AAC sends a first authentication response message ASVeri to the AAC.

At S 511 , the AAC verifies the Sig AS_AAC2 by using the public key of the AS-AAC. After the verification is successful, the AAC uses the message encryption key to encrypt the to-be-encrypted data including the first authentication result information and the Sig AS_REQ1 , so as to generate authentication result information ciphertext EncData AAC , and generates a digital signature Sig AAC of the AAC by performing calculation on to-be-signed data including the EncData AAC .

At S 512 , the AAC sends a third authentication response message AACAuth to the REQ.

The AACAuth includes the EncData AAC and the Sig AAC .

At S 513 , the REQ decrypts the EncData AAC by using the message encryption key, so as to obtain the first authentication result information and the Sig AS_REQ1 .

At S 514 , the REQ verifies the Sig AS_REQ1 by using the public key of the AS-REQ, and verifies the Sig AAC by using the Cert AAC in the first authentication result information.

If the verification is successful, S 515 is then executed.

At S 515 , the REQ determines an identity authentication result of the AAC according to the Res AAC in the first authentication result information.

When the REQ determines that the AAC is legal, S 516 is executed. When the REQ determines that the AAC is illegal, the current authentication process is terminated.

At S 516 , the REQ uses the message encryption key to encrypt the information including a second key Nonce REQPub , so as to obtain second key ciphertext EncData REQ .

At S 517 , the REQ sends a fourth authentication response message REQAuth to the AAC.

The REQAuth includes the EncData REQ .

At S 518 , the AAC uses the message encryption key to decrypt the EncData REQ , so as to obtain the Nonce REQPub , and uses the Nonce REQPub to decrypt the second authentication result information ciphertext, so as to obtain the second authentication result information.

At S 519 , the AAC verifies the digital signature Sig REQ of the REQ by using the Cert REQ in the second authentication result information that is obtained by means of decryption.

If the verification is successful, S 520 is executed.

At S 520 , the AAC determines an identity authentication result of the REQ according to the Res REQ in the second authentication result information that is obtained by means of decryption.

It is to be noted that. (1) the REQInit of S 501 may not include the Sig REQ , while the Sig REQ is added in the REQAuth of S 517 . That is to say, in S 517 , the REQ first generates the Sig REQ by performing calculation on the to-be-signed data including the EncData REQ in the REQAuth. In this case, the Sig REQ verified by the AAC in S 519 is the Sig REQ in the REQAuth. (2) The operation of calculating the Sig AAC in S 511 may also be changed to be previously executed in S 502 . That is, in S 502 , the AAC first generates the Sig AAC by performing calculation on the to-be-signed data including the EncPub AS in the AACVeri, the Cert AAC and the ID AS_REQ , and the AACVeri of S 502 further includes the Sig AAC . In S 503 , the AS-AAC further needs to verify the Sig AAC , and then executes follow-up operations after the verification is successful. In this case, the AAC in S 511 does not need to calculate the Sig AAC . Accordingly, the AACAuth of S 512 does not include the Sig AAC , the REQ in S 514 does not verify the Sig AAC , and in this case, the first authentication result information may not include the Cert AAC .

FIG. 6 is another embodiment of the identity authentication method in the roaming case. In this case, an AS-AAC and an AS-REQ are trusted with each other, know each other's digital certificate or a public key in a digital certificate, and a digital signature Sig REQ of a REQ may also be verified during identity authentication. Before this embodiment is executed, the REQ and a AAC both have held a message encryption key. The message encryption key may be shared in advance by both parties, or may be obtained by means of negotiation by the method shown in FIG. 2 . The identity authentication method for verifying the Sig REQ by the AS-REQ includes the following operations.

At S 601 , the AAC acquires an identity ciphertext message REQInit sent by the REQ.

The REQInit includes identity information ciphertext EncPub AS of the REQ, the identity identifier ID AS_REQ of at least one AS trusted by the REQ, and a digital signature Sig REQ of the REQ.

At S 602 , the AAC sends a first authentication request message AACVeri to the AS-AAC.

The AACVeri includes the REQInit and the Cert AAC , such that the AS-AAC performs legality verification on the Cert AAC , so as to obtain the Res AAC , generates first authentication result information according to the information including the Cert AAC and the Res AAC .

At S 603 , the AS-AAC sends a second authentication request message AS-AACVeri to the AS-REQ.

The AS-AAC determines, according to the ID AS_REQ in the REQInit, the AS-REQ used during the current authentication process, and sends the AS-AACVeri to the AS-REQ. The AS-AACVeri includes the REQInit, the first authentication result information, and a third digital signature Sig AS_AAC3 . The Sig AS_AAC3 is generated by the AS-AAC performing calculation on to-be-signed data including the REQInit and the first authentication result information.

At S 604 , the AS-REQ verifies the Sig AS_AAC3 by using the public key of the AS-AAC.

If the verification is successful, S 605 is then executed.

At S 605 , the AS-REQ uses a private key corresponding to an encryption certificate to decrypt the EncPub AS in the REQInit, so as to obtain a Cert REQ and a second key Nonce REQPub .

At S 606 , the AS-REQ verifies the Sig REQ of the REQ by using the Cert REQ .

If the verification is successful, S 607 is then executed.

At S 607 , the AS-REQ verifies the legality of the Cert REQ , so as to obtain a Res REQ , generates second authentication result information according to the information including the Res REQ , uses the Nonce REQPub to encrypt the information including the second authentication result information, so as to generate second authentication result information ciphertext, generates a first digital signature Sig AS_REQ1 by performing calculation on to-be-signed data including the first authentication result information, and generates the a fourth digital signature Sig AS_REQ4 by performing calculation on to-be-signed data including the second authentication result information ciphertext.

At S 608 , the AS-REQ sends a second authentication response message AS-REQVeri to the AS-AAC.

The AS-REQVeri includes the first authentication result information, the first digital signature Sig AS_REQ1 , the second authentication result information ciphertext and the fourth digital signature Sig AS_REQ4 .

At S 609 , the AS-AAC verifies the Sig AS_REQ4 by using the public key of the AS-REQ.

If the verification is successful, S 610 is executed.

At S 610 , the AS-AAC generate a second digital signature Sig AS_AAC2 by performing calculation on to-be-signed data including the second authentication result information ciphertext, and generates a first authentication response message ASVeri according to the information including the first authentication result information, the first digital signature Sig AS_REQ1 , the second authentication result information ciphertext and the second digital signature Sig AS_AAC2 .

At S 611 , the AS-AAC sends the first authentication response message ASVeri to the AAC.

At S 612 , the AAC verifies the Sig AS_AAC2 by using the public key of the AS-AAC. After the verification is successful, the AAC uses the message encryption key to encrypt the to-be-encrypted data including the first authentication result information and the Sig AS_REQ1 , so as to generate authentication result information ciphertext EncData AAC , and generates a digital signature Sig AAC of the AAC by performing calculation on to-be-signed data including the EncData AAC .

At S 613 , the AAC sends a third authentication response message AACAuth to the REQ.

The AACAuth includes the EncData AAC and the Sig AAC .

At S 614 , the REQ decrypts the EncData AAC by using the message encryption key, so as to obtain the first authentication result information and the Sig AS_REQ1 .

At S 615 , the REQ verifies the Sig AS_REQ1 by using the public key of the AS-REQ, and verifies the Sig AAC by using the Cert AAC in the first authentication result information.

If the verifications all pass. S 616 is executed.

At S 616 , the REQ determines an identity authentication result of the AAC according to the Res AAC in the first authentication result information.

When the REQ determines that the AAC is legal. S 617 is executed; and when the REQ determines that the AAC is illegal, the current authentication process is terminated.

At S 617 , the REQ uses the message encryption key to encrypt the information including the second key Nonce REQPub , so as to obtain second key ciphertext EncData REQ .

At S 618 , the REQ sends a fourth authentication response message REQAuth to the AAC.

The REQAuth includes the EncData REQ .

At S 619 , the AAC uses the message encryption key to decrypt the EncData REQ , so as to obtain the Nonce REQPub , and uses the Nonce REQPub to decrypt the second authentication result information ciphertext, so as to obtain the second authentication result information.

At S 620 , the AAC determines an identity authentication result of the REQ according to the Res REQ in the second authentication result information that is obtained by means of decryption.

It is to be noted that, the operation of calculating the Sig AAC in S 612 may also be changed to be previously executed in S 602 . That is, in S 602 , the AAC first generates the Sig AAC by performing calculation on the to-be-signed data including the REQInit in the AACVeri and the Cert AAC , and the AACVeri of S 602 further includes the Sig AAC . In S 603 , the AS-AAC further needs to verify the Sig AAC , and then executes follow-up operations after the verification is successful. In this case, the AAC in S 612 does not need to calculate the Sig AAC . Accordingly, the AACAuth of S 613 does not include the Sig AAC , the REQ in S 615 does not verify the Sig AAC , and in this case, the first authentication result information may not include the Cert AAC .

For ease of description, in the embodiments of FIG. 7 to FIG. 10 , the first authentication result information may be represented by the field Pub AAC , and the second authentication result information may be represented by the field Pub REQ .

FIG. 7 is still another embodiment of the identity authentication method in the non-roaming case. In this case, an AS-AAC (or an AS-REQ) may be used to represent an AS commonly trusted by a REQ and an AAC. In this embodiment, the process of negotiating a message encryption key between the REQ and the AAC is fused in the identity authentication process in parallel, better facilitating project Implementation. A digital signature Sig REQ of the REQ is verified by the AAC. The method includes the following operations.

At S 701 , the AAC generates a Nonce AAC and a KeyInfo AAC , and generates Security capabilities AAC according to requirements.

At S 702 , the AAC sends a key request message AACInit to the REQ.

The AACInit includes the Nonc ACC , the KeyInfo AAC and the Security capabilities AAC . The Security capabilities AAC is an optional field and represents security capability parameter information supported by the AAC, including an identity authentication suite, one or more symmetric encryption algorithms, one or more integrity checking algorithms and/or one or more key derivation algorithms (same as the entire text) supported by the AAC.

At S 703 , the REQ generates a Nonce REQ , a KeyInfo REQ , a Nonce REQID and a Nonce REQPub , generates Security capabilities REQ according to requirements, and performs key exchange calculation according to information including a temporary private key corresponding to a KeyInfo REQ and a temporary public key included in the KeyInfo AAC , so as to generate a first key K 1 . Then the REQ combines the K 1 with the Nonce AAC , the Nonce REQ and other information (other information used by the REQ and the AAC being the same and optional, for example, a specific string), to calculate a message encryption key and a message integrity check key by using a negotiated or preset key derivation algorithm (this step may also be executed when the message integrity check key and/or the message integrity check key needs to be used later), calculates identity information ciphertext EncPub AS of the REQ by using a public key of an encryption certificate, and calculates a Sig REQ .

The Security capabilities REQ is an optional field, and indicates the selection of the specific security policy made by the REQ according to the Security capabilities AAC . That is, an identity authentication method, a symmetric encryption algorithm, an integrity checking algorithm and/or a key derivation algorithm which the REQ determines to use (same as the entire text). Whether the REQ generates the Security capabilities REQ depends on whether the Security capabilities AAC is carried in the AACInit sent from the AAC to the REQ.

At S 704 , the REQ sends an identity ciphertext message REQInit to the AAC.

The REQInit includes the Nonce AAC , the Nonce REQ , the Security capabilities REQ , the KeyInfo REQ , the EncPub AS and the Sig REQ . The Nonce AAC and the Security capabilities REQ are optional fields. The Nonce AAC shall be equal to the Nonce AAC in the AACInit. The to-be-encrypted data of the EncPub AS includes an ID REQ , a Cert REQ , the Nonce REQID and the Nonce REQPub . The to-be-signed data of the Sig REQ includes other fields before the Sig REQ in the REQInit. For example, when the REQInit successively includes the Nonce AAC , the Nonce REQ , the Security capabilities REQ , the KeyInfo REQ , the EncPub AS and the Sig REQ , to-be-signed data of the Sig REQ includes the Nonce AAC , the Nonce REQ , the Security capabilities REQ , the KeyInfo REQ and the EncPub AS . In addition, when the REQInit does not include the Nonce AAC , the to-be-signed data of the Sig REQ further includes the Nonce AAC in the AACInit.

At S 705 , after receiving the REQInit, the AAC executes the following operations (if there is no special explanation or logical relationship, actions numbered with (1), (2), . . . , in this specification do not necessarily have a sequential order due to their numbering, same as the entire text).

(1) If there is the Nonce AAC in the REQInit, whether the Nonce AAC is the same as the Nonce AAC generated by the AAC is checked. If the Nonce AAC is different from the Nonce AAC generated by the AAC, the REQInit is discarded.

(2) The first key K 1 is generated by performing key exchange calculation according to information including the temporary private key corresponding to the KeyInfo AAC and the temporary public key included in the KeyInfo REQ . The K 1 is combined with the Nonce AAC , the Nonce REQ and other information (other information used by the AAC and the REQ being the same and optional, for example, a specific string), to calculate the message encryption key and the message integrity check key by using the negotiated or preset key derivation algorithm. Definitely, the calculation may be executed when the message integrity check key and/or the message integrity check key needs to be used by the AAC.

At S 706 , the AAC sends a first authentication request message AACVeri to the AS-AAC.

The AACVeri includes the EncPub AS , the Nonce REQ , the ID AAC , the Cert AAC and the Nonce AAC . The EncPub AS and the Nonce REQ shall be respectively equal to corresponding fields in the REQInit. The Nonce AAC shall be equal to the Nonce AAC generated by the AAC.

At S 707 , after receiving the AACVeri, the AS-AAC executes the following operations.

(1) The private key corresponding to the encryption certificate is used to decrypt the EncPub AS , so as to obtain the Cert REQ , the ID REQ , the Nonce REQPub and the Nonce REQID .

(2) The legality of the Cert AAC and the legality of the Cert REQ are respectively verified to obtain the Res AAC and the Res REQ . A Pub AAC is generated according to information including the Cert AAC and the Res AAC . A Pub REQ is generated according to information including the Cert REQ and the Res REQ . An XOR is performed on the ID REQ and the Nonce REQID , so as to generate the ID REQ Nonce REQID . The XOR is performed on the Pub REQ and the Nonce REQPub , so as to generate the Pub REQ Nonce REQPub .

(3) Signature calculation is performed on information including the ID REQ Nonce REQID , the Nonce REQ and the Pub AAC , so as to generate a first digital signature Sig AS_AAC1 . Signature calculation is performed on information including the ID AAC , the Nonce AAC and the Pub REQ Nonce REQPub , so as to generate a second digital signature Sig AS_AAC2 .

At S 708 , the AS-AAC sends a first authentication response message ASVeri to the AAC.

The ASVeri includes the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC , the Sig AS_AAC1 , the ID AAC , the Nonce AAC , the Pub REQ Nonce REQPub and the Sig AS_AAC2 . The ID REQ , the Nonc REQID , the Nonce REQ , the ID AAC , the Nonce AAC and the Nonce REQPub shall respectively be equal to corresponding fields in the AACVeri.

At S 709 , after receiving the ASVeri, the AAC executes the following operations.

(1) Whether the ID AAC and the Nonce AAC are respectively the same as the self ID AAC of the AAC and the Nonce AAC generated by the AAC.

(2) The Sig AS_AAC2 is verified by using the public key of the AS-AAC.

(3) If the checking and the verification all pass, an EncData AAC is calculated by using the message encryption key. If any one of the checking and verification operations is failed, the ASVeri is immediately discarded.

(4) A Sig AAC is calculated.

(5) A MacTag AAC is calculated according to requirements.

At S 710 , the AAC sends a third authentication response message AACAuth to the REQ.

The AACAuth includes the Nonce REQ , the Nonce AAC , the EncData AAC , the Sig AAC and the MacTag AAC . The Nonce REQ and the Nonce AAC are optional fields, and shall respectively be equal to the Nonce REQ in the REQInit and the Nonce AAC generated by the AAC. The to-be-encrypted data of the EncData AAC includes the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC and Sig AS_AAC1 , where the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC and the Sig AS_AAC1 shall respectively be equal to corresponding fields in the ASVeri. To-be-signed data of the Sig AAC includes other fields before the Sig AAC in the AACAuth. The MacTag AAC is an optional field; and a calculation process of the MacTag AAC includes: performing calculating on the fields, other than the MacTag AAC , in the AACAuth using the message integrity check key via the integrity checking algorithm, so as to generate the MacTag AAC .

At S 711 , after receiving the AACAuth, the REQ executes the following operations.

(1) If there is the Nonce REQ in the AACAuth, whether the Nonce REQ is the same as the Nonce REQ generated by the REQ is checked. If there is the Nonce AAC in the AACAuth, whether the Nonce AAC is the same as the Nonce AAC in the AACInit is checked.

(2) If there is the MacTag AAC in the AACAuth, the MacTag AAC is verified.

A verification process is that: the REQ uses the message integrity check key to locally perform calculation on the fields, other than the MacTag AAC , in the AACAuth by using the integrity checking algorithm, so as to generate the MacTag AAC (the calculation manner is the same as the manner in which the AAC calculates the MacTag AAC ), and compares the calculated MacTag AAC with the received MacTag AAC in the AACAuth.

(3) The message encryption key is used to decrypt the EncData AAC by using the symmetric encryption algorithm, so as to obtain the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC and the Sig AS_AAC1 .

(4) The XOR is performed on the ID REQ Nonce REQ and the Nonce REQID , so as to recover the ID REQ ; whether the recovered ID REQ and the self ID REQ of the REQ are the same is verified; and whether the Nonce REQ is the same as the Nonce REQ generated by the REQ is verified.

(5) The Sig AS_AAC1 is verified by using the public key of the AS-AAC, and the Sig AAC is verified by using the Cert AAC in the Pub AAC that is obtained by means of decryption.

(6) If any one of the above checking and verification steps is failed, the AACAuth is immediately discarded; if the above checking and verification all pass, the identity authentication result of the REQ is determined according to the Res AAC in the Pub AAC ; and if it is determined that the AAC is illegal, the current authentication process is terminated.

(7) The message encryption key is used to calculate an EncData REQ .

(8) An MacTag REQ is calculated.

At S 712 , the REQ sends a fourth authentication response message REQAuth to the AAC.

The AACAuth includes the Nonce AAC , the Nonce REQ the EncData REQ , and the MacTag REQ . The Nonce REQ and the Nonce AAC are optional fields, and shall respectively be equal to the Nonce REQ generated by the REQ and the Nonce AAC in the AACInit. The to-be-encrypted data of the EncData REQ includes Nonce REQPub , and the Nonce REQPub shall be equal to the Nonce REQPub generated by the REQ. The calculation process of the MacTag REQ includes: using the message integrity check key to perform calculation on the fields, other than the MacTag REQ , in the REQAuth by using the integrity checking algorithm, so as to generate the MacTag REQ .

At S 713 , after receiving the REQAuth, the AAC executes the following operations.

(1) If there is the Nonce REQ in the REQAuth, whether the Nonce REQ is the same as the Nonce REQ in the received REQInit is checked. If there is the Nonce AAC in the REQAuth, whether the Nonc ACC is the same as the Nonce AAC generated by the AAC is checked.

(2) The MacTag REQ is verified.

A verification process is as follows: the AAC uses the message integrity check key to locally performing calculation on the fields, other than the MacTag REQ , in the REQAuth by using the integrity checking algorithm, so as to generate the MacTag REQ (the calculation manner is the same as the manner in which the REQ calculates the MacTag REQ ), and the calculated MacTag REQ is compared with the MacTag REQ in the received REQAuth.

(3) The message encryption key is used to decrypt the EncData REQ by using the symmetric encryption algorithm, so as to obtain the Nonce REQPub .

(4) The XOR is performed on the Nonce REQPub and the Pub REQ Nonce REQPub , so as to recover the Pub REQ .

(5) The Sig REQ is verified by using the Cert REQ in the Pub REQ .

(6) After the above checking and the verification all pass, the identity authentication result of the REQ is determined according to the Res REQ in the Pub REQ ; and if any one of the above checking and verification is failed, the REQAuth is immediately discarded.

It is to be noted that, (1) the REQInit of S 704 may not include the Sig REQ , while the Sig REQ is added in the REQAuth of S 712 . That is to say, in S 712 , the REQ first generates the Sig REQ by performing signature calculation on information including the Nonce AAC , the Nonce REQ and the EncData REQ . In this case, the Sig REQ verified by the AAC in S 713 is the Sig REQ in the REQAuth. (2) The operation of calculating the Sig AAC in S 709 may also be changed to be first executed in S 706 . That is, in S 706 , the AAC first generates the Sig AAC by performing signature calculation on the information including the EncPub AS in the AACVeri, the Nonce REQ , the ID AAC , the Cert AAC , and the Nonce AAC , and then the AACVeri of S 706 further includes the Sig AAC . In S 707 , the AS-AAC further needs to verify the Sig AAC ; and then executes follow-up operations after the verification is successful. In this case, the AAC in S 709 does not need to calculate the Sig AAC . Correspondingly, the AACAuth of S 710 does not include the Sig AAC , the REQ in S 711 is does not verify the Sig AAC , and in this case, the Pub AAC may not include the Cert AAC .

FIG. 8 is yet another embodiment of the identity authentication method in the non-roaming case. In this case, the AS-AAC (or the AS-REQ) may be used to represent an authentication server commonly trusted by a REQ and an AAC. In this embodiment, the process of negotiating the message encryption key between the REQ and the AAC is fused in the identity authentication process in parallel, better facilitating project implementation. The Sig REQ is verified by the AS-AAC. The method includes the following operations.

At S 801 , the AAC generates a Nonce AAC and a KeyInfo AAC , and generates Security capabilities AAC according to requirements.

At S 802 , the AAC sends a key request message AACInit to the REQ.

The AACInit includes the Nonce AAC , the KeyInfo AAC and the Security capabilities AAC . The Security capabilities AAC is an optional field.

At S 803 , the REQ generates a Nonce REQ , a KeyInfo REQ , a Nonce REQID , and a Nonce REQPub , generates Security capabilities REQ according to requirements, and performs key exchange calculation according to information including a temporary private key corresponding to the KeyInfo REQ and a temporary public key included in the KeyInfo AAC , so as to generate the first key K 1 . Then the REQ combines the K 1 with the Nonce AAC , the Nonce REQ and other information (other information used by the REQ and the AAC being the same and optional, for example, a specific string), so as to calculate a message encryption key and a message integrity check key by using a negotiated or preset key derivation algorithm, calculates identity information ciphertext EncPub AS of the REQ by using a public key of an encryption certificate; and calculates a Sig REQ .

At S 804 , the REQ sends an identity ciphertext message REQInit to the AAC.

The REQInit includes the Nonce AAC , the Nonce REQ , the Security capabilities REQ , the KeyInfo REQ , the EncPub AS and the Sig REQ . The Security capabilities REQ is an optional field; the to-be-encrypted data of the EncPub AS includes the ID REQ , the Cert REQ , the Nonce REQID and the Nonce REQPub . To-be-signed data of the Sig REQ includes other fields before the Sig REQ in the REQInit.

At S 805 , after receiving the REQInit, the AAC executes the following operations.

(1) Whether the Nonce AAC in the REQInit is the same as the Nonce AAC generated by the AAC is checked. If the Nonce AAC in the REQInit is different from the Nonce AAC generated by the AAC, the REQInit is discarded.

(2) the first key K 1 is generated by performing Key exchange calculation according to information including the temporary private key corresponding to the KeyInfo AAC and the temporary public key included in the KeyInfo REQ . The K 1 is combined with the Nonce AAC , the Nonce REQ and other information (other information used by the AAC and the REQ being the same and optional, for example, a specific string), so as to calculate the message encryption key and the message integrity check key by using the negotiated or preset key derivation algorithm.

At S 806 , the AAC sends a first authentication request message AACVeri to the AS-AAC.

The AACVeri includes the REQInit, the ID AAC , and the Cert AAC .

At S 807 , after receiving the AACVeri, the AS-AAC executes the following operations.

(1) The private key corresponding to the encryption certificate is used to decrypt the EncPub AS in the REQInit, so as to obtain the Cert REQ , the ID REQ , the Nonce REQID , the and Nonce REQPub .

(2) The Sig REQ in the REQInit is verified by using the Cert REQ obtained by means of decryption.

(3) After the legality of the Cert AAC and the legality of the Cert REQ is respectively verified to obtain the Res AAC and the Res REQ , a Pub AAC is generated according to information including the Cert AAC and the Res AAC . Then, a Pub REQ is generated according to the information including the Res REQ ; an XOR is performed on the ID REQ and the Nonce REQID , so as to generate the ID REQ Nonce REQID ; and the XOR is performed on the Pub REQ and the Nonce REQPub , so as to generate the Pub REQ Nonce REQPub .

(4) Signature calculation is performed on the information including the ID REQ Nonce REQID , the Nonce REQ and the Pub AAC , so as to generate a first digital signature Sig AS_AAC1 ; and signature calculation is performed on the information including the ID AAC , the Nonce AAC and the Pub REQ Nonce REQPub , so as to generate a second digital signature Sig AS_AAC2 .

At S 808 , the AS-AAC sends a first authentication response message ASVeri to the AAC.

The ASVeri includes the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC , the Sig AS_AAC1 , the ID AAC , the Nonce AAC , the Pub REQ Nonce REQ r and the Sig AS_AAC2 . The ID REQ , the Nonce REQID , the Nonce REQ , the ID AAC , the Nonce AAC and the Nonce REQPub shall respectively be equal to corresponding fields in the AACVeri.

At S 809 , after receiving the ASVeri, the AAC executes the following operations.

(1) Whether the ID AAC and the Nonce AAC are respectively the same as the self ID AAC of the AAC and the Nonce AAC generated by the AAC.

(2) The Sig AS_AAC2 is verified by using the public key of the AS-AAC.

(3) If the above checking and the verification all pass, the EncData AAC is calculated by using the message encryption key; and if any one of the above checking and verification is failed, the ASVeri is immediately discarded.

(4) A Sig AAC is calculated.

(5) A MacTag AAC is calculated according to requirements.

At S 810 , the AAC sends a third authentication response message AACAuth to the REQ.

The AACAuth includes the Nonce REQ , the Nonce AAC , the EncData AAC , the Sig AAC and the MacTag AAC . The Nonce REQ and the Nonce AAC are optional fields, and shall respectively be equal to the Nonce REQ in the REQInit and the Nonce AAC generated by the AAC. The to-be-encrypted data of the EncData AAC includes the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC and Sig AS_AAC1 ; and the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC and the Sig AS_AAC1 shall respectively be equal to corresponding fields in the ASVeri. The to-be-signed data of the Sig AAC includes other fields before the Sig AAC in the AACAuth. The MacTag AAC is an optional field, and the calculation thereof is described as above.

At S 811 , after receiving the AACAuth, the REQ executes the following operations.

(1) If there is the Nonce REQ in the AACAuth, whether the Nonce REQ is the same as the Nonce REQ generated by the REQ is checked. If there is the Nonce AAC in the AACAuth, whether the Nonce AAC is the same as the Nonce AAC in the AACInit is checked.

(2) If there is the MacTag AAC in the AACAuth, the MacTag AAC is verified. The verification process is described in the embodiment of FIG. 7 .

(3) The message encryption key is used to decrypt the EncData AAC by using the symmetric encryption algorithm, so as to obtain the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC and the Sig AS_AAC1 .

(4) The XOR is performed on the ID REQ Nonce REQID and the Nonce REQID , so as to recover the ID REQ ; whether the recovered ID REQ and the self ID REQ of the REQ are the same is verified; and whether the Nonce REQ is the same as the Nonce REQ generated by the REQ is verified.

(5) The Sig AS_AAC1 is verified by using the public key of the AS-AAC, and the Sig AAC is verified by using the Cert AAC in the Pub AAC that is obtained by means of decryption.

(6) If any one of the above checking and verification is failed, the AACAuth is immediately discarded. If the above checking and verification all pass, the identity authentication result of the AAC is determined according to the Res AAC in the Pub AAC , and if it is determined that the AAC is illegal, the current authentication process is terminated.

(7) The message encryption key is used to calculate the EncData REQ .

(8) The MacTag REQ is calculated, and a calculation process is described in the embodiment of FIG. 7 .

At S 812 , the REQ sends a fourth authentication response message REQAuth to the AAC.

The AACAuth includes the Nonce AAC , the Nonce REQ , the EncData REQ , and the MacTag REQ . The Nonce REQ and the Nonce AAC are optional fields, and shall respectively be equal to the Nonce REQ generated by the REQ and the Nonce AAC in the AACInit. The to-be-encrypted data of the EncData REQ includes the Nonce REQPub ; and the Nonce REQPub shall be equal to the Nonce REQPub generated by the REQ.

At S 813 , after receiving the REQAuth, the AAC executes the following operations.

(1) If there is the Nonce REQ in the REQAuth, whether the Nonce REQ is the same as the Nonce REQ in the received REQInit is checked. If there is the Nonce AAC in the REQAuth, whether the Nonce AAC is the same as the Nonce AAC generated by the AAC is checked.

(2) The MacTag REQ is verified; and a verification process is described in the embodiment of FIG. 7 .

(3) The message encryption key is used to decrypt the EncData REQ by using the symmetric encryption algorithm, so as to obtain the Nonce REQPub .

(4) The XOR is performed on the Nonce REQPub and the Pub REQ Nonce REQPub , so as to recover the Pub REQ .

(5) After the above checking and the verification all pass, an identity authentication result of the REQ is determined according to the Res REQ in the Pub REQ ; and if any one of the above checking and verification is failed, the REQAuth is immediately discarded.

It is to be noted that, the operation of calculating the Sig AAC in S 809 may also be changed to be preciously executed in S 806 . That is, in S 806 , the AAC first generates the Sig AAC by performing signature calculation on the REQInit, the ID AAC and the Cert AAC , and the AACVeri of S 806 further includes the Sig AAC . In S 807 , the AS-AAC further needs to verify the Sig AAC , and then executes follow-up operations after the verification is successful. In this case, the AAC in S 809 does not need to calculate the Sig AAC . Correspondingly, the AACAuth of S 810 does not include the Sig AAC , the REQ in S 811 does not verify the Sig AAC , and in this case, the Pub AAC may not include the Cert AAC .

FIG. 9 is yet another embodiment of the identity authentication method in the roaming case. In this embodiment, the process of negotiating a message encryption key between a REQ and an AAC is fused in the identity authentication process in parallel, better facilitating project implementation. A Sig REQ of the REQ is verified by the AAC. The method includes the following steps.

At S 901 , the AAC generates a Nonce AAC and a KeyInfo AAC , and generates Security capabilities AAC according to requirements.

At S 902 , the AAC sends a key request message AACInit to the REQ.

The AACInit includes the Nonce AAC , the KeyInfo AAC , the Security capabilities AAC , and an ID AS_AAC . The Security capabilities AAC is an optional field. The ID AS_AAC is an optional field and represents the identity identifier of at least one authentication server AS trusted by the AAC, so that the REQ determines, according to the ID AS_AAC , whether there is a commonly trusted authentication server AS (hereinafter the same).

At S 903 , the REQ generates a Nonce REQ , a KeyInfo REQ , a Nonce REQID , and a Nonce REQPub , generates the Security capabilities REQ and the ID AS_REQ according to requirements, and performs key exchange calculation according to information including a temporary private key corresponding to the KeyInfo REQ and a temporary public key included in the KeyInfo AAC , so as to generate the first key K 1 . Then the REQ combines the K 1 with the Nonce AAC , the Nonce REQ and other information (other information used by the REQ and the AAC being the same and optional, for example, a specific string), so as to calculate a message encryption key and a message integrity check key by using a negotiated or preset key derivation algorithm; calculates identity information ciphertext EncPub AS of the REQ by using a public key of the encryption certificate, and calculates a Sig REQ .

At S 904 , the REQ sends an identity ciphertext message REQInit to the AAC.

The REQInit includes the Nonce AAC , the Nonce REQ , the ID AS_REQ , the KeyInfo REQ , the EncPub AS , the Security capabilities REQ , and the Sig REQ . The Nonce AAC , the ID AS_REQ and the Security capabilities REQ are optional fields. The Nonce AAC shall be equal to a corresponding field in the AACInit. The to-be-encrypted data of the EncPub AS includes the ID REQ , the Cert REQ , the Nonce REQID , and the Nonce REQPub . The to-be-signed data of the Sig REQ includes other fields before the Sig REQ in the REQInit. When the REQInit does not include the Nonce AAC , the to-be-signed data of the Sig REQ further includes the Nonce AAC field in the AACInit. The ID AS_REQ represents the identity identifier of at least one authentication server trusted by the REQ. When there is the ID AS_AAC in the AACInit, the REQ tries to select, from the trusted ASs, at least one AS same as that in the ID AS_AAC as the ID AS_REQ . If the selection is failed, the REQ uses at least one authentication server trusted by the REQ as the ID AS_REQ . When there is no ID AS_AAC in the AACInit, the REQ uses the at least one AS trusted by the REQ as the ID AS_REQ (same as the entire text).

At S 905 , after receiving the REQInit, the AAC executes the following operations.

(1) If there is the Nonce AAC in the REQInit, whether the Nonce AAC is the same as the Nonce AAC generated by the AAC is checked. If the Nonce AAC is different from the Nonce AAC generated by the AAC, the REQInit is discarded.

(2) The first key K 1 is generated by performing key exchange calculation according to information including the temporary private key corresponding to the KeyInfo AAC and the temporary public key included in the KeyInfo REQ . The K 1 is combined with the Nonce AAC , the Nonce REQ and other information (other information used by the AAC and the REQ being the same and optional, for example, a specific string), so as to calculate the message encryption key and the message integrity check key by using the negotiated or preset key derivation algorithm. The calculation may be executed when the message integrity check key and/or the message integrity check key needs to be used by the AAC.

(3) If the REQInit carries the ID AS_REQ , and the AACInit carries the ID AS_AAC , the AAC determines whether there is the identity identifier of at least one same AS in the ID AS_REQ and the ID AS_AAC . If yes, that is the non-roaming case. The AAC determines a first authentication server involved in identity authentication from the identity identifier of the at least one AS that is commonly trusted by REQ and the AAC. If no, that is the roaming case. The AAC needs to determine, according to the ID AS_AAC , a first authentication server AS-AAC involved in identity authentication, and sends the ID AS_REQ to the AS-AAC, such that the AS-AAC determines a second first authentication server AS-REQ according to the ID AS_REQ .

Alternatively, if the REQInit carries the ID AS_REQ , but the AACInit does not carry the ID AS_AAC , the AAC determines whether there is the identity identifier of at least one same AS in the ASs trusted by the ID AS_REQ and the AAC. If yes, that is the non-roaming case. The AAC determines a first authentication server involved in identity authentication from the identity identifier of the at least one authentication server that is commonly trusted by REQ and the AAC. If no, that is the roaming case. The AAC needs to determine, according to the AS trusted by the ACC, a first authentication server involved in identity authentication, and sends the ID AS_REQ to the AS-AAC, such that the AS-AAC determines a second authentication server AS-REQ according to the ID AS_REQ .

It is to be noted that, in this embodiment, the result of the determination is the roaming case.

At S 906 , the AAC sends a first authentication request message AACVeri to the AS-AAC.

The AACVeri includes the EncPub AS , the Nonce REQ , the ID AS_REQ , the ID AAC , the Cert AAC , and the Nonce AAC . The ID AS_REQ is an optional field. The Nonce REQ and the ID AS_REQ shall be respectively equal to corresponding fields in the REQInit. The Nonce AAC shall be equal to the Nonce AAC generated by the AAC.

At S 907 , after receiving the AACVeri, the AS-AAC executes the following operations.

(1) The legality of the Cert AAC is verified to obtain the Res AAC , and a Pub AAC is generated according to information including the Cert AAC and the Res AAC .

(2) If there is the ID AS_REQ in the AACVeri, the AS-AAC determines the second authentication server AS-REQ according to the ID AS_REQ . If there is no ID AS_REQ in the AACVeri, it indicates that the AS-REQ has been known by the AS-AAC.

(3) A third digital signature Sig AS_AAC3 is calculated.

At S 908 , the AS-AAC sends a second authentication response message the AS-AACVeri to the AS-REQ.

The AS-AACVeri includes the EncPub AS , the Nonce REQ , the ID AAC , the Nonce AAC , the Pub AAC , and the Sig AS_AAC3 . The EncPub AS , the Nonce REQ , the ID AAC , and the Nonce AAC shall be respectively equal to corresponding fields in the AACVeri. To-be-signed data of the Sig AS_AAC3 includes other fields before the Sig AS_AAC in the AS-AACVeri.

At S 909 , after receiving the AS-AACVeri, the AS-REQ verifies the Sig AS_AAC3 by using the public key of the AS-AAC.

If the verification is successful. S 910 is executed.

At S 910 , the AS-REQ sends a decryption request message AS-REQReq to the CS-DEC.

The AS-REQReq includes the EncPub AS . The EncPub AS shall be equal to the corresponding field in the AS-AACVeri.

At S 911 , the CS-DEC decrypts the EncPub AS , so as to obtain the Cert REQ , the ID REQ , the Nonce REQID , and the Nonce REQPub .

At S 912 , the CS-DEC sends a decryption response message CS-DECRep to the AS-REQ.

The CS-DECRep includes the Cert REQ , the ID REQ , the Nonce REQ and the Nonce REQPub , which are obtained by means of decryption. The Cert REQ , the ID REQ , the Nonce REQID , and the Nonce REQPub shall respectively be equal to corresponding fields in the AS-AACVeri.

At S 913 , after receiving the CS-DECRep, the AS-REQ executes the following operations.

(1) The legality of the Cert REQ is verified to obtain the Res REQ . A Pub REQ is generated according to information including the Cert REQ and the Res REQ . An XOR is performed on the ID REQ and the Nonce REQID , so as to generate the ID REQ Nonce REQID ; and the XOR is performed on the Pub REQ and the Nonce REQPub , so as to generate the Pub REQ Nonce REQPub .

(2) Signature calculation is performed on information including the ID REQ Nonce REQID , the Nonce REQ and the Pub AAC , so as to generate a first digital signature Sig AS_REQ1 and signature calculation is performed on information including the ID AAC , the Nonce AAC and the Pub REQ Nonce REQPub , so as to generate a fourth digital signature Sig AS_REQ4 .

At S 914 , the AS-REQ sends a second authentication response message AS-REQVeri to the AS-AAC.

The AS-REQVeri includes the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC , the Sig AS_REQ1 , the ID AAC , the Nonce AAC , the Pub REQ Nonce REQPub and the Sig AS_REQ4 . The ID REQ , the Nonce REQID and the Nonce REQPub shall be respectively equal to corresponding fields in the CS-DECRep. The Nonce REQ , the ID AAC , the Nonce AAC , and the Pub AAC shall be respectively equal to corresponding fields in the AS-AACVeri.

At S 915 , the AS-AAC verifies the Sig AS_REQ4 by using the public key of the AS-REQ. If the verification is successful, the AS-AAC generates a second digital signature Sig AS_AAC by performing signature calculation on information including the ID AAC , the Nonce AAC , and the Pub REQ Nonce REQPub .

At S 916 , the AS-AAC sends a first authentication response message ASVeri to the AAC.

The ASVeri includes the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC , the Sig AS_REQ1 , the ID AAC , the Nonce AAC , the Pub REQ Nonce REQPub , and the Sig AS_AAC2 . The ID REQ Nonce REQID , the Nonce REQ , the Pub AAC , the Sig AS_REQ1 , the ID AAC the Nonce AAC , and the Pub REQ Nonce REQPub are all obtained from the AS-REQVeri.

At S 917 , after receiving the ASVeri, the AAC executes the following operations.

(1) Whether the ID AAC and the Nonce AAC are respectively the same as the self ID AAC of the AAC and the Nonce AAC generated by the AAC.

(2) The Sig AS_AAC2 is verified by using the public key of the AS-AAC.

(3) If the above checking and the verification all pass, the EncData AAC is calculated by using the message encryption key If any one of the above checking and verification is failed, the ASVeri is immediately discarded.

(4) The Sig AAC is calculated.

(5) The MacTag AAC is calculated according to requirements.

At S 918 , the AAC sends a third authentication response message AACAuth to the REQ.

The AACAuth includes the Nonce REQ , the Nonce AAC , the EncData AAC , the Sig AAC and the MacTag AAC . The to-be-signed data of the Sig AAC includes other fields before the Sig AAC in the AACAuth. The Nonce REQ and the Nonce AAC are optional fields, and shall respectively be equal to the Nonce REQ in the REQInit and the Nonce AAC generated by the AAC. The to-be-encrypted data of the EncData AAC includes the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC and Sig AS_REQ1 , where the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC and the Sig AS_REQ1 shall respectively be equal to corresponding fields in the ASVeri. The MacTag AAC is an optional field, and the calculation of which is as described in the embodiment of FIG. 7 .

At S 919 , after receiving the AACAuth, the REQ executes the following operations.

(1) If there is the Nonce REQ in the AACAuth, whether the Nonce REQ is the same as the Nonce REQ generated by the REQ is checked. If there is the Nonce AAC in the AACAuth, whether the Nonc ACC is the same as the Nonce AAC in the AACInit is checked.

(2) If there is the MacTag AAC in the AACAuth, the MacTag AAC is verified; and a verification process is as described in the embodiment of FIG. 7 .

(3) The message encryption key is used to decrypt the EncData AAC by using the symmetric encryption algorithm, so as to obtain the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC and the Sig AS_REQ1 .

(4) The XOR is performed on the ID REQ Nonce REQID and the Nonce REQID , so as to recover the ID REQ ; whether the recovered ID REQ and the self ID REQ of the REQ are the same is verified; and whether the Nonce REQ is the same as the Nonce REQ generated by the REQ is verified.

(5) The Sig AS_REQ1 is verified by using the public key of the AS-REQ, and the Sig AAC is verified by using the Cert AAC in the Pub AAC that is obtained by means of decryption.

(6) If any one of the above checking and verification is failed, the AACAuth is immediately discarded. If the above checking and verification all pass, the identity authentication result of the AAC is determined according to the Res AAC in the Pub AAC . If it is determined that the AAC is illegal, the current authentication process is terminated.

(7) The message encryption key is used to calculate an EncData REQ .

(8) The MacTag REQ is calculated, and a calculation process is as described in the embodiment of FIG. 7 .

At S 920 , the REQ sends a fourth authentication response message REQAuth to the AAC.

The AACAuth includes the Nonce AAC , the Nonc REQ , the EncData REQ , and the MacTag REQ . The Nonce REQ and the Nonce AAC are optional fields, and shall respectively be equal to the Nonce REQ generated by the REQ and the Nonce AAC in the AACInit. The to-be-encrypted data of the EncData REQ includes the Nonce REQPub , and the Nonce REQPub shall be equal to the Nonce REQPub generated by the REQ.

At S 921 , after receiving the REQAuth, the AAC executes the following operations.

(1) If there is the Nonce REQ in the REQAuth, whether the Nonce REQ is the same as the Nonce REQ in the received REQInit is checked. If there is the Nonc ACC in the REQAuth, whether the Nonce AAC is the same as the Nonce AAC generated by the AAC is checked.

(2) The MacTag REQ is verified; and a verification process is described in the embodiment of FIG. 7 .

(3) The message encryption key is used to decrypt the EncData REQ by using the symmetric encryption algorithm, so as to obtain the Nonce REQPub .

(4) The XOR is performed on the Nonce REQPub and the Pub REQ Nonce REQPub , so as to recover the Pub REQ .

(5) The Sig REQ is verified by using the Cert REQ in the Pub REQ .

(6) After the above checking and the verification all pass, the identity authentication result of the REQ is determined according to the Res REQ in the Pub REQ . If any one of the above checking and verification is failed, the REQAuth is immediately discarded.

It is to be noted that, (1) the REQInit of S 904 may not include the Sig REQ , while the Sig REQ is added in the REQAuth of S 920 . That is to say, in S 920 , the REQ first generates the Sig REQ by performing signature calculation on information including the Nonce AAC , the Nonce REQ and the EncData REQ . In this case, the Sig REQ verified in S 921 is the Sig REQ in the REQAuth. (2) The operation of calculating the Sig AAC in S 917 may also be changed to be previously executed in S 906 . That is, in S 906 , the AAC first generates the Sig AAC by performing signature calculation on the information including the EncPub AS , the Nonce REQ , the ID AS_REQ , the ID AAC , the Cert AAC , and the Nonce AAC , and the AACVeri of S 906 further includes the Sig AAC . In S 907 , the AS-AAC further needs to verify the Sig AAC ; and then executes follow-up operations after the verification is successful. In this case, the AAC in S 917 does not need to calculate the Sig AAC . Correspondingly, the AACAuth of S 918 does not include the Sig AAC , the REQ in S 919 does not verify the Sig AAC , and in this case, the Pub AAC may not include the Cert AAC .

FIG. 10 is still another embodiment of the identity authentication method in the roaming case. In this embodiment, the process of negotiating a message encryption key between a REQ and an AAC is fused in the identity authentication process in parallel, better facilitating project implementation. The Sig REQ is verified by the AS-REQ. The method includes the following steps.

At S 1001 , the AAC generates a Nonce AAC and a KeyInfo AAC , and generates Security capabilities AAC according to requirements.

At S 1002 , the AAC sends a key request message AACInit to the REQ.

The AACInit includes the Nonce AAC , the KeyInfo AAC , the Security capabilities AAC , and an ID AS_AAC . The Security capabilities AAC and the ID AS_AAC are optional fields.

At S 1003 , the REQ generates a Nonce REQ , a KeyInfo REQ , a Nonce REQID , and a Nonce REQPub , generates Security capabilities REQ and an ID AS_REQ according to requirements, and performs key exchange calculation according to information including a temporary private key corresponding to the KeyInfo REQ and a temporary public key included in the KeyInfo AAC , so as to generate the first key K 1 . Then the REQ combines the K 1 with the Nonce AAC , the Nonce REQ and other information (other information used by the REQ and the AAC being the same and optional, for example, a specific string), so as to calculate a message encryption key and a message integrity check key by using a negotiated or preset key derivation algorithm; calculates identity information ciphertext EncPub AS of the REQ by using the public key of the encryption certificate; and calculates the Sig REQ .

At S 1004 , the REQ sends an identity ciphertext message REQInit to the AAC.

The REQInit includes the EncPub AS , the Nonce AAC , the Nonce REQ , the ID AS_REQ , the KeyInfo REQ , the Security capabilities REQ , and the Sig REQ . The Nonce AAC shall be equal to a corresponding field in the AACInit. The Security capabilities REQ and the ID AS_REQ are optional fields. The to-be-encrypted data of the EncPub AS includes the ID REQ , the Cert REQ , the Nonce REQID , and the Nonce REQPub . To-be-signed data of the Sig REQ includes other fields before the Sig REQ in the REQInit.

At S 1005 , after receiving the REQInit, the AAC executes the following operations.

(1) Whether the Nonce AAC in the REQInit is the same as the Nonce AAC generated by the AAC is checked; and if the Nonce AAC in the REQInit is different from the Nonce AAC generated by the AAC, the REQInit is discarded.

(2) Key exchange calculation is performed according to information including the temporary private key corresponding to the KeyInfo AAC and the temporary public key included in the KeyInfo REQ , so as to generate a first key K 1 ; the K 1 is combined with the Nonce AAC , the Nonce REQ and other information (other information used by the AAC and the REQ being the same and optional, for example, a specific string), so as to calculate the message encryption key and the message integrity check key by using the negotiated or preset key derivation algorithm. The calculation of the message integrity check key and/or the message integrity check key may also be executed when needed later.

(3) The determination of a first authentication server AS-AAC refers to the related description in the embodiment of FIG. 9 .

It is to be noted that, in this embodiment, the result of the determination is the roaming case.

At S 1006 , the AAC sends a first authentication request message AACVeri to the AS-AAC.

The AACVeri includes the REQInit, the ID AAC , and the Cert AAC .

At S 1007 , after receiving the AACVeri, the AS-AAC executes the following operations.

(1) The legality of the Cert AAC is verified to obtain the Res AAC , and a Pub AAC is generated according to information including the Cert AAC and the Res AAC .

(2) The determination of the AS-REQ refers to related description in the embodiment of FIG. 9 .

(3) The Sig AS_AAC is calculated.

At S 1008 , the AS-AAC sends a second authentication response message AS-AACVeri to the AS-REQ.

The AS-AACVeri includes the REQInit, the ID AAC , the Pub AAC , and the Sig AS_AAC3 . The REQInit and the ID AAC shall respectively be equal to the REQInit and the ID AAC in the AACVeri. To-be-signed data of the Sig AS_AAC3 includes other fields before the Sig AS AAC in the AS-AACVeri.

At S 1009 , after receiving the AS-AACVeri, the AS-REQ verifies the Sig AS_AAC3 by using the public key of the AS-AAC.

If the verification is successful, S 1010 is executed.

At S 1010 , the AS-REQ sends a decryption request message AS-REQReq to the CS-DEC.

The AS-REQReq includes the EncPub AS . The EncPub AS shall be equal to the corresponding field in the AS-AACVeri.

At S 1011 , the CS-DEC decrypts the EncPub AS , so as to obtain the Cert REQ , the ID REQ , the Nonce REQID , and the Nonce REQPub .

At S 1012 , the CS-DEC sends a decryption response message CS-DECRep to the AS-REQ.

The CS-DECRep includes the Cert REQ , the ID REQ , the Nonce REQID , and the Nonce REQPub , which are obtained by means of decryption. The Cert REQ , the ID REQ , the Nonce REQID , and the Nonce REQPub shall respectively be equal to corresponding fields in the AS-AACVeri.

At S 1013 , after receiving the CS-DECRep, the AS-REQ executes the following operations.

(1) The Sig REQ is verified by using the Cert REQ ; and if the verification is failed, the CS-DECRep is discarded.

(2) The legality of the Cert REQ is verified to obtain the Res REQ . A Pub REQ is generated according to information including the Res REQ . An XOR is performed on the ID REQ and the Nonce REQID , so as to generate the ID REQ Nonce REQID ; and the XOR is performed on the Pub REQ and the Nonce REQPub , so as to generate the Pub REQ Nonce REQPub .

(3) Signature calculation is performed on information including the ID REQ Nonce REQID , the Nonce REQ and the Pub AAC , so as to generate a first digital signature Sig AS_REQ1 ; and signature calculation is performed on information including the ID AAC , the Nonce AAC and the Pub REQ Nonce REQPub , so as to generate a fourth digital signature Sig AS_REQ4 .

At S 1014 , the AS-REQ sends a second authentication response message AS-REQVeri to the AS-AAC.

The AS-REQVeri includes the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC , the Sig AS_REQ1 , the ID AAC , the Nonce AAC , the Pub REQ Nonce REQ and the Sig AS_REQ4 . The ID REQ , the Nonce REQID and the Nonce REQPub shall be respectively equal to corresponding fields in the CS-DECRep; and the Nonce REQ , the ID AAC , the Nonce AAC , and the Pub AAC shall be respectively equal to corresponding fields in the AS-AACVeri.

At S 1015 , the AS-AAC verifies the Sig AS_REQ4 by using the public key of the AS-REQ If the verification is successful, the AS-AAC generates a second digital signature Sig AS_AAC2 by performing signature calculation on information including the ID AAC , the Nonce AAC , and the Pub REQ Nonce REQPub .

At S 1016 , the AS-AAC sends a first authentication response message ASVeri to the AAC.

The ASVeri includes the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC , the Sig AS_REQ1 , the ID AAC , the Nonce AAC , the Pub REQ Nonce REQPub , and the Sig AS_AAC2 . The ID REQ Nonce REQID , the Nonce REQ , the Pub AAC , the Sig AS_REQ1 , the ID AAC , the Nonce AAC , and the Pub REQ Nonce REQPub are all obtained from the AS-REQVeri.

At S 1017 , after receiving the ASVeri, the AAC executes the following operations.

(1) Whether the ID AAC and the Nonce AAC are respectively the same as the self ID AAC of the AAC and the Nonce AAC generated by the AAC.

(2) The Sig AS_AAC2 is verified by using the public key of the AS-AAC.

(3) If the above checking and the verification all pass, the EncData AAC is calculated by using the message encryption key. If any one of the above checking and verification is failed, the ASVeri is immediately discarded.

(4) The Sig AAC is calculated.

(5) The MacTag AAC is calculated according to requirements.

At S 1018 , the AAC sends a third authentication response message AACAuth to the REQ.

The AACAuth includes the Nonce REQ , the Nonce AAC , the EncData AAC , the Sig AAC and the MacTag AAC . To-be-signed data of the Sig AAC includes other fields before the Sig AAC in the AACAuth. The Nonce REQ and the Nonce AAC are optional fields, and shall respectively be equal to the Nonce REQ in the REQInit and the Nonce AAC generated by the AAC, to-be-encrypted data of the EncData AAC includes the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC and Sig AS_REQ1 , where the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC and the Sig AS_REQ1 shall respectively be equal to corresponding fields in the ASVeri. The MacTag AAC is an optional field, and the calculation of which is as described in the embodiment of FIG. 7 .

At S 1019 , after receiving the AACAuth, the REQ executes the following operations.

(1) If there is the Nonce REQ in the AACAuth, whether the Nonce REQ is the same as the Nonce REQ generated by the REQ is checked. If there is the Nonce AAC in the AACAuth, whether the Nonce AAC is the same as the Nonce AAC in the AACInit is checked.

(2) If there is the MacTag AAC in the AACAuth, the MacTag AAC is verified; and a verification process is as described in the embodiment of FIG. 7 .

(3) The message encryption key is used to decrypt the EncData AAC by using the symmetric encryption algorithm, so as to obtain the ID REQ Nonce REQID , the Nonce REQ , the Pub AAC and the Sig AS_REQ1 .

(4) The XOR is performed on the ID REQ Nonce REQID and the Nonce REQID , so as to recover the ID REQ ; whether the recovered ID REQ and the self ID REQ of the REQ are the same is verified; and whether the Nonce REQ is the same as the Nonce REQ generated by the REQ is verified.

(5) The Sig AS_REQ1 is verified by using the public key of the AS-REQ, and the Sig AAC is verified by using the Cert AAC in the Pub AAC that is obtained by means of decryption.

(6) If any one of the above checking and verification is failed, the AACAuth is immediately discarded. If the above checking and verification all pass, the identity authentication result of the ACC is determined according to the Res AAC in the Pub AAC . If it is determined that the AAC is illegal, the current authentication process is terminated.

(7) The message encryption key is used to calculate an EncData REQ .

(8) The MacTag REQ is calculated, and a calculation process is as described in the embodiment of FIG. 7 .

At S 1020 , the REQ sends a fourth authentication response message REQAuth to the AAC.

The AACAuth includes the Nonce AAC , the Nonce REQ , the EncData REQ , and the MacTag REQ . The Nonce REQ and the Nonce AAC are optional fields, and shall respectively be equal to the Nonce REQ generated by the REQ and the Nonce AAC in the AACInit. The to-be-encrypted data of the EncData REQ includes the Nonce REQPub ; and the Nonce REQPub shall be equal to the Nonce REQPub generated by the REQ.

At S 1021 , after receiving the REQAuth, the AAC executes the following operations.

(1) If there is the Nonce REQ in the REQAuth, whether the Nonce REQ is the same as the Nonce REQ in the received REQInit is checked. If there is the Nonce AAC in the REQAuth, whether the Nonce AAC is the same as the Nonce AAC generated by the AAC is checked.

(2) The MacTag REQ is verified; and a verification process is as described in the embodiment of FIG. 7 .

(3) The message encryption key is used to decrypt the EncData REQ by using the symmetric encryption algorithm, so as to obtain the Nonce REQPub .

(4) The XOR is performed on the Nonce REQPub and the Pub REQ Nonce REQPub , so as to recover the Pub REQ .

(5) After the above checking and the verification all pass, the identity authentication result of the REQ is determined according to the Res REQ in the Pub REQ . If any one of the above checking and verification is failed, the REQAuth is immediately discarded.

It is to be noted that, the operation of calculating the Sig AAC in S 1017 may also be changed to be previously executed in S 1006 . That is, in S 1006 , the AAC first generates the Sig AAC by performing signature calculation on the REQInit in the AACVeri, the ID AAC and the Cert AAC , and the AACVeri of S 1006 further includes the Sig AAC . In S 1007 , the AS-AAC further needs to verify the Sig AAC ; and then executes follow-up operations after the verification is successful. In this case, the AAC in S 1017 does not need to calculate the Sig AAC . Correspondingly, the AACAuth of S 1018 does not include the Sig AAC , the REQ in S 1019 is no longer verify the Sig AAC , and in this case, the Pub AAC may not include the Cert AAC .

In the above embodiments, each message may further carry a hash value HASH X_Y . The hash value HASH X_Y is obtained by a sender entity X of the message performing calculation on the received latest preamble message sent by an opposite-end entity Y using a HASH algorithm. The hash value HASH X_Y is used for the opposite-end entity Y to verify whether the entity X receives the whole latest preamble message. The HASH REQ_AAC represents a hash value that is calculated by the REQ for the received latest preamble message sent by the AAC. The HASH AAC_REQ represents a hash value that is calculated by the AAC for the received latest preamble message sent by the REQ. The HASH AAC_AS-AAC represents a hash value that is calculated by the AAC for the received latest preamble message sent by the AS-AAC. The HASH AS-AAC_AAC represents a hash value that is calculated by the AS-AAC for the received latest preamble message sent by the AAC, the HASH AS-AAC_AS-REQ represents a hash value that is calculated by the AS-AAC for the received latest preamble message sent by the AS-REQ. The HASH AS-REQ_AS-AAC represents a hash value that is calculated by the AS-REQ for the received latest preamble message sent by the AS-AAC. If a message currently sent by the sender entity X is the first message of the interaction between the entity X and the entity Y, which means that the entity X has not received any preamble message sent by the opposite-end entity Y. Therefore, the HASH X_Y in the message may be non-existent or meaningless.

Correspondingly, after the opposite-end entity Y receives the message sent by the entity X, if the message includes the HASH X_Y , the entity Y ignores the HASH X_Y when the entity Y has not sent any preamble message to the entity X. When the entity Y has sent a preamble message to the entity X, the entity Y uses the hash algorithm to locally calculate the hash value for the latest preamble message sent to the entity X, and compares the hash value with the HASH X_Y carried in the received message. If the hash value is consistent with the HASH X_Y , the entity Y executes the follow-up operations. Otherwise, the entity Y discards or ends the current authentication process.

In the present invention, for the entity X, the preamble message sent by the opposite-end entity Y to the entity X refers to the message, which is sent to the entity X by the opposite-end entity Y and received by the entity X before the entity X sends the message M to the opposite-end entity Y. The latest preamble message sent by the opposite-end entity Y to the entity X refers to the latest message, which is sent to the entity X by the opposite-end entity Y and received by the entity X before the entity X sends the message M to the opposite-end entity Y. If the message M sent by the entity X to the opposite-end entity Y is the first message of the interaction between the entity X and the entity Y, then before the entity X sends the message M to the opposite-end entity Y, the preamble message sent by the opposite-end entity Y to the entity X does not exist.

The optional fields and the optional operations in the corresponding embodiments in FIG. 7 , FIG. 8 , FIG. 9 and FIG. 10 are represented by “*” in FIG. 7 , FIG. 8 , FIG. 9 and FIG. 10 of the drawings of the specification. The sequence of the content included in the messages involved in all of the above embodiments is not limited. In addition, the sequence in which the message receiver operates the relevant messages after receiving the messages, and the sequence in which the message receiver processes the content included in the messages are not limited unless otherwise specified.

On the basis of the embodiments corresponding to FIG. 1 to FIG. 10 , referring to FIG. 11 , an embodiment of the present application provides an AAC 1100 . The AAC includes an acquisition portion 1101 , a first sending portion 1102 , a first receiving portion 1103 , a first verification portion 1104 , a second sending portion 1105 , a second receiving portion 1106 , a decryption portion 1107 , and a first determination portion 1108 .

The acquisition portion 1101 is configured to acquire an identity ciphertext message sent by an REQ. The identity ciphertext message includes identity information ciphertext of the REQ, and the identity information ciphertext is generated by encrypting using a public key of an encryption certificate, to-be-encrypted data including a digital certificate of the REQ and a second key.

The first sending portion 1102 is configured to send a first authentication request message to a first AS which is trusted by the AAC. The first authentication request message includes the identity information ciphertext of the REQ and a digital certificate of the AAC.

The first receiving portion 1103 is configured to receive a first authentication response message sent by the first AS. The first authentication response message includes first authentication result information, a first digital signature, second authentication result information ciphertext and a second digital signature; the first authentication result information includes a first verification result for the digital certificate of the AAC; the first digital signature is a digital signature which is generated by a second AS trusted by the REQ performing calculation on to-be-signed data including the first authentication result information, the second authentication result information ciphertext is obtained by encrypting, using the second key, information including second authentication result information: the second authentication result information includes a second verification result for the digital certificate of the REQ; and the second digital signature is a digital signature which is generated by the first AS performing calculation on to-be-signed data including the second authentication result information ciphertext.

The first verification portion 1104 is configured to verify, using a public key of a first AS, the second digital signature.

The second sending portion 1105 is configured to send, when the verification of the second digital signature is successful, a third authentication response message to the REQ. The third authentication response message includes authentication result information ciphertext. The authentication result information ciphertext is generated by encrypting, using a message encryption key, to-be-encrypted data including the first authentication result information and the first digital signature.

The second receiving portion 1106 is configured to receive a fourth authentication response message sent by the REQ. The fourth authentication response message includes second key ciphertext. The second key ciphertext is obtained by encrypting, using the message encryption key, information including the second key.

The decryption portion 1107 is configured to decrypt, using the message encryption key, the second key ciphertext, so as to obtain the second key, and decrypt, using the second key, the second authentication result information ciphertext, so as to obtain the second authentication result information.

The first determination portion 1108 is configured to determine, according to the second verification result in the second authentication result information, an identity authentication result of the REQ.

In some embodiments, the AAC further includes a third sending portion and a calculation portion.

The third sending portion is configured to send a key request message to the REQ. The key request message includes a key exchange parameter of the AAC, and the identity ciphertext message acquired by the acquisition portion 1101 further includes a key exchange parameter of the REQ.

The calculation portion, configured to perform key exchange calculation according to information including the temporary private key corresponding to the key exchange parameter of the AAC and the temporary public key included in the key exchange parameter of the REQ, so as to generate the first key, and calculate, according to the information including the first key, the message encryption key by using the key derivation algorithm.

In some embodiments, the key request message sent by the third sending portion further includes a first random number generated by the AAC; the identity ciphertext message acquired by the acquisition portion 1101 further includes a second random number generated by the REQ. The calculation portion is further configured to calculate, according to information including the first key, the first random number and the second random number, the message encryption key.

In some embodiments, the identity ciphertext message acquired by the acquisition portion 1101 further includes the first random number. The AAC further includes a second verification portion.

The second verification portion is configured to verify consistency of the first random number in the identity ciphertext message and the first random number generated by the AAC. The calculation portion is further configured to calculates the message encryption key if the verification is successful.

In some embodiments, the key request message sent by the third sending portion further includes security capability parameter information supported by the AAC, the identity ciphertext message acquired by the acquisition portion 1101 further includes a specific security policy, and the specific security policy is determined by the REQ according to the security capability parameter information supported by the AAC.

In some embodiments, the key request message sent by the third sending portion further includes the identity identifier of at least one AS trusted by the AAC; and the identity ciphertext message acquired by the acquisition portion 1101 further includes the at least one identity identifier of the at least one AS trusted by the REQ. The AAC further includes a second determination portion.

The second determination portion is configured to determine the first AS according to the at least one identity identifier of the at least one AS trusted by the REQ in the identity ciphertext message and the at least one identity identifier of the at least one AS trusted by the AAC in the key request message.

In some embodiments, the identity ciphertext message acquired by the acquisition portion 1101 further includes the identity identifier of at least one AS trusted by the REQ. The AAC further includes a third determination portion.

The third determination portion is configured to determine the first AS according to the the identity identifier of at least one AS trusted by the REQ and the identity identifier of at least one AS trusted by the AAC.

In some embodiments, the first authentication request message sent by the first sending portion 1102 further includes an identity identifier of the AAC and/or a first random number generated by the AAC; correspondingly, the first authentication response message received by the first receiving portion 1103 further includes the identity identifier of the AAC and/or the first random number.

The AAC further includes a third verification portion.

The third verification portion is configured to verify consistency of the identity identifier of the AAC in the first authentication response message and a self-identity identifier of the AAC, and/or verify consistency of the first random number in the first authentication response message and the first random number generated by the AAC. The first determination portion 1108 is configured to determine the identity authentication result of the REQ after the verification is successful.

In some embodiments, the identity ciphertext message acquired by the acquisition portion 1101 further includes a digital signature of the REQ, and the first determination portion 1108 is further configured to determine whether a verification of the digital signature of the REQ is successful, and, then determine, if it is determined that the verification of the digital signature of the REQ is successful, the identity authentication result of the REQ according to the second verification result.

In some implementations, the first determination portion 1108 is further configured to perform the following operations.

When the second authentication result information that is obtained by the decryption portion 1107 decrypting the second authentication result information ciphertext further includes the digital certificate of the REQ, and the digital signature of the REQ is verified by using the digital certificate of the REQ, whether the verification of the digital signature of the REQ is successful is determined according to a verification result.

And/or, in a case that the second AS verifies the digital signature of the REQ by using the digital certificate of the REQ that is obtained by decrypting the identity information ciphertext of the REQ, if the first receiving portion 1103 receives the first authentication response message, it is determined that the verification of the digital signature of the REQ has passed.

In some implementations, the fourth authentication response message received by the second receiving portion 1106 further includes a digital signature of the REQ, the second authentication result information decrypted by the decryption portion 1107 using the second key further includes a digital certificate of the REQ; and before the first determination portion 1108 determines the identity authentication result of the REQ, the first determination portion 1108 is further configured to verify the digital signature of the REQ by using the digital certificate of the REQ in the first authentication result information, and determine, if the verification is successful, the identity authentication result of the REQ according to the second verification result.

In some implementations, the third authentication response message sent by the second sending portion 1105 further includes a first message integrity check code, and the first message integrity check code is generated by the AAC performing calculation on fields, other than the first message integrity check code, in the third authentication response message using a message integrity check key.

And/or, the fourth authentication response message received by the second receiving portion 1106 further includes a second message integrity check code. The second message integrity check code is generated by the REQ perform calculation on fields, other than the second message integrity check code, in the fourth authentication response message using the message integrity check key, and the AAC further includes a fourth verification portion.

The fourth verification portion is configured to verify the second message integrity check code by using the message integrity check key. The first determination portion 1108 is further configured to determines, according to the second verification result, the identity authentication result of the REQ after the verification is successful.

In some implementations, a message sent to the REQ by the AAC further includes a hash value, which is calculated by the AAC for a received latest preamble message sent by the REQ; and a message sent to the AS-AAC by the AAC further includes a hash value, which is calculated by the AAC for a received latest preamble message sent by the AS-AAC.

Referring to FIG. 12 , an embodiment of the present application provides an REQ 1200 . The REQ includes a first sending portion 1201 , a first receiving portion 1202 , a first decryption portion 1203 , and a first verification portion 1204 .

The first sending portion 1201 is configured to send an identity ciphertext message to an AAC. The identity ciphertext message includes identity information ciphertext of the REQ. The identity information ciphertext is generated by encrypting, using a public key of an encryption certificate, to-be-encrypted data including a digital certificate of the REQ and a second key.

The first receiving portion 1202 is configured to receive a third authentication response message sent by the AAC. The third authentication response message includes authentication result information ciphertext. The authentication result information ciphertext is generated by encrypting, using a message encryption key, to-be-encrypted data including the first authentication result information and the first digital signature.

The first decryption portion 1203 is configured to decrypt, using the message encryption key, the authentication result information ciphertext, so as to obtain the first authentication result information and the first digital signature.

The first verification portion 1204 is configured to verify the first digital signature by using a public key of the second AS, the first determination portion 1205 is further configured to determine, according to the first verification result in the first authentication result information, an identity authentication result of the AAC if the verification of the first digital signature is successful and the second sending portion 1206 is further configured to send a fourth authentication response message to the AAC when the first determination portion 1205 determines that the identity authentication result of the AAC is legal.

Or, the first verification portion 1204 is configured to verify the first digital signature by using a public key of the second AS. The second sending portion 1206 is further configured to send a fourth authentication response message to the AAC if the verification of the first digital signature is successful. The first determination portion 1205 is further configured to determine, according to the first verification result in the first authentication result information, an identity authentication result of the AAC.

Or, the first verification portion 1204 is configured to verify the first digital signature by using a public key of the second AS. The first determination portion 1205 is further configured to determine, according to the first verification result in the first authentication result information, the identity authentication result of the AAC if the verification of the first digital signature is successful. The second sending portion 1206 is configured to send a fourth authentication response message to the AAC.

The fourth authentication response message includes second key ciphertext, and the second key ciphertext is obtained by encrypting, using the message encryption key, information including the second key.

In some embodiments, the REQ further includes a second receiving portion and a first calculation portion.

The second receiving portion is configured to receive a key request message sent by the AAC. The key request message includes a key exchange parameter of the AAC.

The first calculation portion is configured to perform key exchange calculation according to information including a temporary private key corresponding to a key exchange parameter of the REQ and a temporary public key included in the key exchange parameter of the AAC, so as to generate a first key, and calculate, according to information including the first key, the message encryption key by using a key derivation algorithm.

The identity ciphertext message sent by the first sending portion 1201 further includes a key exchange parameter of the REQ.

In some embodiments, the key request message received by the second receiving portion further includes a first random number generated by the AAC.

The calculation portion is further configured to calculate, according to information including the first key, the first random number and a second random number generated by the REQ, the message encryption key.

The identity ciphertext message sent by the first sending portion 1201 further includes the second random number.

In some embodiments, the key request message received by the second receiving portion further includes security capability parameter information supported by the AAC. The REQ further includes a second determination portion.

The second determination portion is configured to determine, according to the security capability parameter information, a specific security policy used by the REQ.

The identity ciphertext message sent by the first sending portion 1201 further includes the specific security policy.

In some embodiments, the key request message received by the second receiving portion further includes the identity identifier of at least one AS trusted by the AAC. The REQ further includes a third determination portion.

The third determination portion is configured to determine, according to the at least one identity identifier of the at least one AS trusted by the AAC, the identity identifier of at least one AS trusted by the REQ. The identity ciphertext message sent by the first sending portion 1201 further includes the at least one identity identifier of the at least one AS trusted by the REQ.

In some embodiments, the identity ciphertext message sent by the first sending portion 1201 further includes a second random number generated by the REQ, and/or the to-be-encrypted data of the identity information ciphertext in the identity ciphertext message further includes an identity identifier of the REQ and a third key.

Encrypted data of the authentication result information ciphertext in the third authentication response message received by the first receiving portion 1202 further includes the second random number and/or the identity identifier ciphertext of the REQ.

The first decryption portion 1203 is further configured to decrypt, using the message encryption key, the authentication result information ciphertext, so as to obtain the second random number and/or the identity identifier ciphertext of the REQ.

The REQ further includes a second verification portion.

The second verification portion is configured to verify consistency of the second random number obtained by means of decryption and the second random number generated by the REQ, and/or verify, according to the self-identity identifier of the REQ and the third key, the identity identifier ciphertext of the REQ. The first determination portion 1205 is further configured to determine the identity authentication result of the AAC if the verification is successful.

In some embodiments, the first determination portion 1205 is further configured to determine whether verification of A digital signature of the AAC is successful before determining the identity authentication result of the AAC, and determine, according to the first verification result, the identity authentication result of the AAC if it is determined that the verification of the digital signature of the AAC is successful.

In some implementations, the first determination portion 1205 is further configured to perform the following operations.

When a first authentication request message sent by the AAC to a first AS trusted by the AAC further includes a digital signature of the AAC, verifies the digital signature of the AAC is verified by the first AS using the digital certificate of the AAC in the first authentication request message, and if the third authentication response message is received by the first receiving portion 1202 , it is determined that the verification of the digital signature of the AAC has passed.

And/or, when the third authentication response message further includes a digital signature of the AAC, and the first authentication result information further includes a digital certificate of the AAC, the first determination portion 1205 verifies, using the digital certificate of the AAC in the first authentication result information, the digital signature of the AAC, and determines, according to a verification result, whether the verification of the digital signature of the AAC is successful.

In some implementations, the third authentication response message received by the first receiving portion 1202 further includes a first message integrity check code, and the first message integrity check code is generated by the AAC, using a message integrity check key, performing calculation on fields, other than the first message integrity check code, in the third authentication response message. The REQ further includes a third verification portion.

The third verification portion is configured to verify, using the message integrity check key, the first message integrity check code. The first determination portion 1205 is configured to determine, according to the first verification result, the identity authentication result of the AAC after the verification of the first message integrity check code is successful.

And/or, the fourth authentication response message sent by the second sending portion 1206 further includes a second message integrity check code, and the second message integrity check code is generated by the REQ, using the message integrity check key, performing calculation on fields, other than the second message integrity check code, in the fourth authentication response message.

In some implementations, a message sent by the REQ to the AAC further includes a hash value, which is calculated by the REQ for a received latest preamble message sent by the AAC.

Referring to FIG. 13 , an embodiment of the present application provides an first authentication server AS-AAC 1300 . The first authentication server AS-AAC 1300 is an AS trusted by an AAC, and includes a first receiving portion 1301 and a first sending portion 1302 .

The first receiving portion 1301 is configured to receive a first authentication request message sent by the AAC. The first authentication request message includes identity information ciphertext of an REQ and a digital certificate of the AAC. The identity information ciphertext is generated by encrypt, using a public key of an encryption certificate, to-be-encrypted data including a digital certificate of the REQ and a second key.

The first sending portion 1302 is configured to send a first authentication response message to the AAC. The first authentication response message includes first authentication result information, a first digital signature, second authentication result information ciphertext and a second digital signature. The first authentication result information includes a first verification result for the digital certificate of the AAC. The first digital signature is a digital signature which is generated by a second AS trusted by the REQ performing calculation on to-be-signed data including the first authentication result information. The second authentication result information ciphertext is obtained by encrypting, using the second key, information including second authentication result information. The second authentication result information includes a second verification result for the digital certificate of the REQ. The second digital signature is a digital signature which is generated by the first AS performing calculation on to-be-signed data including the second authentication result information ciphertext.

In some implementations, the AS-AAC trusted by the AAC and the AS-REQ trusted by the REQ are the same AS. The AS-AAC further includes a first decryption portion, a first verification portion, and a first generation portion.

The first decryption portion is configured to decrypt, using a private key corresponding to the encryption certificate, the identity information ciphertext of the REQ, so as to obtain the digital certificate of the REQ and the second key.

The first verification portion is configured to perform legality verification on the digital certificate of the AAC, so as to obtain the first verification result, and perform legality verification on the digital certificate of the REQ, so as to obtain a second verification result.

The first generation portion is configured to generate, according to information including the first verification result, the first authentication result information, generate, according to information including the second verification result, the second authentication result information, generate the second authentication result information ciphertext by encrypting, using the second key, the information including the second authentication result information, generate the first digital signature by performing calculation on to-be-signed data including the first authentication result information, generate the second digital signature by performing calculate on to-be-signed data including the second authentication result information ciphertext, and generate, according to information including the first authentication result information, the first digital signature, the second authentication result information ciphertext and the second digital signature, the first authentication response message.

In some implementations, the first AS trusted by the AAC and the second AS trusted by the REQ are two different ASs. The AS-AAC further includes a second verification portion, a second generation portion, a second sending portion, a second receiving portion, a third verification portion, and a third generation portion.

The second verification portion is configured to perform legality verification on the digital certificate of the AAC, so as to obtain the first verification result.

The second generation portion is configured to generate, according to information including the first verification result, the first authentication result information, and generate a third digital signature by performing calculation on to-be-signed data including the first authentication result information and the identity information ciphertext of the REQ.

The second sending portion is configured to send a second authentication request message to the second AS. The second authentication request message includes the first authentication result information, the identity information ciphertext of the REQ and the third digital signature.

The second receiving portion is configured to receive a second authentication response message sent by the second AS. The second authentication response message includes the first authentication result information, the first digital signature, the second authentication result information ciphertext and a fourth digital signature. The fourth digital signature is a digital signature, which is generated by the second AS performing calculation on to-be-signed data including the second authentication result information ciphertext.

The third verification portion is configured to verify, using a public key of the second AS, the fourth digital signature.

The third generation portion is configured to generate the second digital signature by performing calculation on to-be-signed data including the second authentication result information ciphertext and generate, according to the first authentication result information, the first digital signature, the second authentication result information ciphertext and the second digital signature, the first authentication response message when the verification of the fourth digital signature is successful.

In some implementations, a message sent by the first AS to the AAC further includes a hash value, which is calculated by the first AS for a received latest preamble message sent by the AAC; and a message sent by the first AS to the second AS further includes a hash value, which is calculated by the first AS for a received latest preamble message sent by the second AS.

Referring to FIG. 14 , an embodiment of the present application provides a second authentication server AS-REQ (i.e. a second AS) 1400 . The second authentication server AS-REQ 1400 is an authentication server trusted by an REQ. If a first authentication server (i.e. a first AS) trusted by an AAC and the second authentication server trusted by the REQ are two different ASs, the second authentication server AS-REQ 1400 includes a receiving portion 1401 , a verification portion 1402 , a decryption portion 1403 , a generation portion 1404 , and a sending portion 1405 .

The receiving portion 1401 is configured to receive a second authentication request message sent by the first AS. The second authentication request message includes first authentication result information, identity information ciphertext of the REQ, and a third digital signature, the third digital signature is a digital signature, which is generated by the first AS performing calculation on to-be-signed data including the first authentication result information and the identity information ciphertext of the REQ. The identity information ciphertext is generated by encrypting, using a public key of an encryption certificate, to-be-encrypted data including a digital certificate of the REQ and a second key.

The verification portion 1402 is configured to verify the third digital signature by using a public key of the first AS.

The decryption portion 1403 is configured to decrypt, using the private key corresponding to the encryption certificate, the identity information ciphertext of the REQ when the verification of the third digital signature is successful, so as to obtain the digital certificate of the REQ and the second key.

The verification portion 1402 is further configured to perform legality verification on the digital certificate of the REQ, so as to obtain a second verification result.

The generation portion 1404 is configured to: generate a second authentication result information according to information including the second verification result; generate second authentication result information ciphertext by encrypting, using the second key; information including the second authentication result information; generate a first digital signature by performing calculation on to-be-signed data including the first authentication result information; and generate a fourth digital signature by performing calculation on to-be-signed data including the second authentication result information ciphertext.

The sending portion 1405 is configured to send a second authentication response message to the first AS. The second authentication response message includes the first authentication result information, the first digital signature, the second authentication result information ciphertext, and the fourth digital signature.

In some implementations, a message sent to the AS-AAC by the AS-REQ further includes a hash value, which is calculated by the AS-REQ for a received latest preamble message sent by the AS-AAC.

FIG. 15 is a schematic structural diagram of an electronic device according to an embodiment of the present application. As shown in FIG. 15 , the electronic device 1500 may be the AAC, the REQ, the AS-AAC, or the AS-REQ. The electronic device 1500 includes a processor 1501 and a memory 1502 . The memory 1502 is configured to store a computer program. The processor 1501 is configured to call and run the computer program stored in the memory 1502 , so as to execute steps in any one of the above embodiments executed by the AAC, the REQ, the AS-AAC, or the AS-REQ. The processor 1501 and the memory 1502 of the electronic device 1500 may respectively be the processor 1501 and the memory 1502 of the AAC, the REQ, the AS-AAC, or the AS-REQ.

In combination with FIG. 15 , the AAC, the REQ, the AS-AAC, or the AS-REQ is respectively exemplarily described below.

An embodiment of the present application further provides an AAC. The AAC includes a processor and a memory. The memory is configured to store a computer program; and the processor is configured to call and run the computer program stored in the memory, so as to execute steps, which are executed by the AAC, in any one of the above embodiments.

It should be understood that, the AAC may implement corresponding flows implemented by the AAC in each method of the embodiments of the present application. For simplicity, elaborations are omitted herein.

An embodiment of the present application further provides an REQ. The REQ includes a processor and a memory. The memory is configured to store a computer program; and the processor is configured to call and run the computer program stored in the memory, so as to execute steps, which are executed by the REQ, in any one of the above embodiments.

It should be understood that, the REQ may implement corresponding flows implemented by the REQ in each method of the embodiments of the present application. For simplicity, elaborations are omitted herein.

An embodiment of the present application further provides an AS-AAC. The AS-AAC is an AS trusted by the AAC, and includes a processor and a memory. The memory is configured to store a computer program; and the processor is configured to call and run the computer program stored in the memory, so as to execute steps, which are executed by the AS-AAC, in any one of the above embodiments.

It should be understood that, the AS-AAC may implement corresponding flows implemented by the AS-AAC, in each method of the embodiments of the present application. For simplicity, elaborations are omitted herein.

An embodiment of the present application further provides an AS-REQ. The AS-REQ is an AS trusted by the REQ. If the AS-AAC trusted by the AAC and the AS-REQ trusted by the REQ are two different ASs, the AS-REQ includes a processor and a memory. The memory is configured to store a computer program; and the processor is configured to call and run the computer program stored in the memory, so as to execute steps, which are executed by the AS-REQ, in any one of the above embodiments.

It should be understood that, the AS-REQ may implement corresponding flows implemented by the AS-REQ in each method of the embodiments of the present application. For simplicity, elaborations are omitted herein.

It is to be noted that, the processor in the AAC, the REQ, the AS-AAC, or the AS-REQ in the embodiments of the present application may further execute the method in other embodiments, for example, other methods in the above method embodiments, and the embodiments of the present application are not limited thereto.

FIG. 16 is a schematic structural diagram of a chip according to an embodiment of the present application. As shown in FIG. 16 , the chip 1600 includes a processor 1601 and a memory 1602 . The processor 1601 is configured to call and run a computer program from a memory 1602 , to enable:

an AAC having the chip 1600 mounted to execute steps, which are executed by the AAC, in any one of the above embodiments; or a REQ having the chip 1600 mounted to execute steps, which are executed by the REQ in any one of the above embodiments; or an AS-AAC having the chip 1600 mounted to execute steps, which are executed by the AS-AAC in any one of the above embodiments. or an AS-REQ having the chip 1600 mounted to execute steps, which are executed by the AS-REQ in any one of the above embodiments.

The memory 1602 may be included in the chip 1600 , or the memory 1602 may be provided outside the chip 1600 .

An embodiment of the present application further provides a computer storage medium. The computer storage medium is configured to store a computer program. The computer program enables an AAC to execute steps, which are executed by the AAC in any one of the above embodiments.

Or the computer program enables an REQ to execute steps, which are executed by the REQ in any one of the above embodiments.

Or the computer program enables an AS-AAC to execute steps, which are executed by the AS-AAC in any one of the above embodiments.

Or the computer program enables an AS-REQ execute steps, which are executed by the AS-REQ in any one of the above embodiments.

An embodiment of the present application further provides a computer program. The computer program enables an AAC to execute steps, which are executed by the AAC in any one of the above embodiments.

Or the computer program enables an REQ to execute steps, which are executed by the REQ in any one of the above embodiments.

Or the computer program enables an AS-AAC to execute steps, which are executed by the AS-AAC in any one of the above embodiments.

Or the computer program enables an AS-REQ to execute steps, which are executed by the AS-REQ in any one of the above embodiments.

Those of ordinary skill in the art should know that all or part of the steps of the method embodiment may be implemented by related hardware instructed by means of a program, the program may be stored in a computer storage medium, and the program is executed to execute the steps of the method embodiment. The computer storage medium may be at least one of the following media: a Read-Only Memory (ROM), a Random Access Memory (RAM) and various media that can store program codes, such as a magnetic disk, or an optical disk.

Each component, the chip or the processor in the embodiments of the present application may be an integrated circuit chip and has a signal processing capacity. During implementation, each step of the above method embodiments may be completed by an integrated logical circuit of hardware in the processor or an instruction in a software form. Each component, the chip or the processor may include the integration of any one or at least two of the following: a general processor, an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a Programmable Logic Device (PLD), a Field Programmable Gate Array (FPGA), a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Neural-network Processing Unit (NPU), a controller, a microcontroller, a microprocessor, a programmable logic device, a discrete gate or transistor logic device, and a discrete hardware component.

It is to be noted that, each embodiment in this specification is described in a progressive manner, and reference may be made to each other for the same and similar parts among the various embodiments, and each embodiment focuses on the differences from other embodiments. In particular, for the device and system embodiments, since the device and system embodiments are consistent with and correspond to the method embodiments, the description is relatively simple, and related parts refer to the partial descriptions of the method embodiments. The above described device and system embodiments are merely exemplary. The parts described as separate components may or may not be physically separated. The components displayed as parts may or may not be physical parts, that is, the components may be located in one place, or may be distributed on the plurality of network parts. Part or all of the modules may be selected according to actual requirements to achieve the purposes of the solutions of this embodiment. It can be understood and implemented by those of ordinary skill in the art without creative labor.

The above is only the exemplary implementations of the present application and not intended to limit the scope of protection of the present application. Any variations or replacements apparent to those skilled in the art within the technical scope disclosed by the present application shall fall within the scope of protection of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

The embodiments of the present disclosure disclose an identity authentication method and apparatus, and a device, a chip, a storage medium and a program. Identify information of the REQ is subjected to confidential processing during identity authentication, and when the identify information is transmitted between the REQ and the AAC, the identify information of the AAC is subjected to confidential processing, so as to prevent the identify information of the REQ and the AAC from being exposed during a transmission process, thereby ensuring that an attacker cannot obtain private and sensitive information. Moreover, by means of involving an authentication server, real-time mutual identity authentication between the REQ and the AAC is achieved while the confidentiality of entity identity related information is guaranteed, such that the foundation that only a legal user can access a legal network is laid.