WO2018045817A1 - 移动网络的认证方法、终端设备、服务器和网络认证实体 - Google Patents

移动网络的认证方法、终端设备、服务器和网络认证实体 Download PDF

Info

Publication number
WO2018045817A1
WO2018045817A1 PCT/CN2017/092429 CN2017092429W WO2018045817A1 WO 2018045817 A1 WO2018045817 A1 WO 2018045817A1 CN 2017092429 W CN2017092429 W CN 2017092429W WO 2018045817 A1 WO2018045817 A1 WO 2018045817A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal device
server
message
terminal
public key
Prior art date
Application number
PCT/CN2017/092429
Other languages
English (en)
French (fr)
Inventor
康鑫
王海光
杨艳江
雷中定
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP17847990.3A priority Critical patent/EP3493502B1/en
Publication of WO2018045817A1 publication Critical patent/WO2018045817A1/zh
Priority to US16/297,231 priority patent/US11026084B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0433—Key management protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols

Definitions

  • the present application relates to the field of communications, and in particular, to an authentication method, a terminal device, a server, and a network authentication entity of a mobile network in the field of communications.
  • the Internet of Things is an important application scenario for the next generation mobile communication network 5G.
  • the Internet of Things is cost sensitive, with higher security and stability requirements.
  • the traditional Subscriber Identity Module (SIM) is difficult to meet the requirements of IoT devices.
  • Embedded Subscriber Identity Module (eSIM) with remote credential configuration (eSIM) came into being. It can be soldered directly to IoT devices to ensure stability. It can be downloaded remotely when the terminal device is activated. The trust of the operator.
  • eSIM's remote configuration technology and specifications require that the terminal device have an initial Credential at the factory.
  • the terminal device When the terminal device activates the network access, it uses the initial temporary credential and the operator's credential remote configuration server to establish a secure channel, and downloads the trust provided by the operator for later access to the network.
  • the IoT device is not configured with any initial credentials at the factory. None of the existing technologies and specifications can meet the need for such remote download operator credentials for IoT devices that do not hold the pre-issued credentials of the operator.
  • the embodiment of the present application provides a method for authenticating a mobile network, a terminal device, a server, and a network authentication entity, which can enable the terminal device to hold the certificate without the pre-distribution of the operator network.
  • a credential terminal device that obtains the credentials of the carrier network.
  • a method for authenticating a mobile network comprising:
  • the first terminal device receives the Duffy Herman DH public key and the first identity ID sent by the at least one second terminal device, where the first terminal device is a device that has a shared key, and the at least one second The terminal device is a device that does not hold a shared key; the first terminal device sends a first message to the server, where the first message includes a DH public of each second terminal device of the at least one second terminal device And a first ID of each of the second terminal devices; the first terminal device receives a second message sent by the server based on the first message, and the second message includes a DH public key of the server And the second ID of each of the second terminal devices generated by the server for each of the second terminal devices, where the second ID is used to identify a subscriber; the first terminal device to each of the The second terminal device sends the second ID of each of the second terminal devices and the DH public key of the server, so that each of the second terminal devices is configured according to the second ID of each of the second terminal devices And the DH public key of the server
  • the terminal device can establish a channel for key negotiation with the server for the terminal device that does not hold the certificate pre-issued by the operator based on the trust of the operator that the operator has already held, so that the terminal does not have the operator pre-issued.
  • the credential terminal device can also obtain a shared key for authentication with the operator network from the server to be able to access the network.
  • the first message further includes indication information, where the indication information is used to indicate that the first message is used to request, for each of the second terminal devices, a shared key of each of the second terminal devices. And the second ID of each of the second terminal devices.
  • the indication information may be, for example, a flag bit, which may indicate whether the trust certificate issued by the operator is requested by the second terminal device or the trust issued by the operator for the plurality of second terminal devices. shape.
  • the first terminal device may add the indication information to the first message sent to the server.
  • the second ID may be, for example, an IMSI number assigned by the operator to the subscriber.
  • the method further includes: the first terminal device generating the first message for the first message according to the second shared key a message verification code MAC of a message, the second shared key being used for authentication between the first terminal device and the server; wherein the first terminal device sends a first message to the server, including The first terminal device sends the first message and the MAC of the first message to the server.
  • the receiving, by the first terminal device, the second message sent by the server based on the first message that: the first terminal device receives the second message sent by the server, and the server a MAC of the second message generated by the second shared key according to the second shared key, where the first terminal device sends the second terminal device to each of the second terminal devices
  • the second ID and the DH public key of the server include: the first terminal device verifies the MAC of the second message according to the second shared key; if the first terminal device is to the second message Passing the MAC authentication, the first terminal device sends the second ID of each of the second terminal devices and the DH public key of the server to each of the second terminal devices.
  • the server and the terminal device can ensure the source of the message is reliable and the transmission process is not falsified by verifying the message, thereby improving the security of the key exchange process.
  • the receiving, by the first terminal device, the second message sent by the server based on the first message that: the first terminal device receives the second message sent by the server, the server pair a signature message of each of the second terminal devices obtained by signing the second ID of each second terminal device and the DH public key of the server, and a signature message with each of the second terminal devices Corresponding to the verification information of each of the second terminal devices, where the first terminal device sends the second message to each of the second terminal devices, including: the first terminal device to each of the The second terminal device sends the second ID of each of the second terminal devices, the DH public key of the server, the signature message of each of the second terminal devices, and the verification information of each of the second terminal devices.
  • the verification message includes a certificate of the server or an ID of the server.
  • the verification information may be a certificate of the server, that is, a certificate corresponding to a private key used by the server to encrypt the second message, so that the second terminal device can The certificate verifies the signature; if the server uses an identity-based key system, the verification information may be the ID of the server, so that the second terminal device can verify the signature according to the ID of the server.
  • the DH public key is sent to the server of the terminal device that does not hold the credential and is generated for the terminal device.
  • the identifier used to identify the signing user is signed by the server, thereby improving the security of the key exchange process, and the middleman attack cannot be initiated even if the terminal device is controlled by the attack.
  • the method further includes: the first terminal device, according to the second shared key, to each of the second terminal devices Encrypting the DH public key and the first ID of each of the second terminal devices; wherein, the DH of each of the second terminal devices in the first message sent by the first terminal device to the server
  • the public key and the first ID of each of the second terminal devices are encrypted by the first terminal device.
  • the second ID of each of the second terminal devices and the DH public key of the server in the second message received by the first terminal device from the server are encrypted by the server
  • the method further includes: before the first terminal device sends the second ID of each of the second terminal devices to the second terminal device, and the DH public key of the server, the method further includes: Decrypting the encrypted second ID of each second terminal device and the DH public key of the server according to the second shared key; the first terminal device to each of the Transmitting, by the second terminal device, the second ID of each of the second terminal devices, and the DH public key of the server, the first terminal device sending the decrypted location to each of the second terminal devices The second ID of each second terminal device and the DH public key of the server.
  • the security of the key exchange process of the server and the terminal device is improved by encrypting the message.
  • the server comprises a home subscriber server HSS.
  • a terminal device where the terminal device is a first terminal device, and the terminal device can be used to perform the foregoing first aspect and the authentication method of the mobile network in the foregoing implementation manners by the first terminal device.
  • the first terminal device is a device that has a shared key, and the first terminal device includes:
  • a receiving module configured to receive a Dieffie Herman DH public key and a first identity ID sent by the at least one second terminal device, where the at least one second terminal device is a device that does not hold the shared key;
  • the first message is sent to the server, where the first message includes a DH public key of each second terminal device of the at least one second terminal device and a first ID of each of the second terminal devices;
  • the receiving module is further configured to receive a second message that is sent by the server based on the first message, where the second message includes a DH public key of the server, and the server is the second terminal device Generating the second ID of each of the second terminal devices, the second ID is used to identify the subscriber, and the sending module is further configured to send the second to each of the second terminal devices a second ID of the terminal device and a DH public key of the server, such that each of the second terminal devices is determined to be used according to the second ID of each of the second terminal devices and the DH public key of the server Said to authenticate with
  • another terminal device is provided, where the terminal device is a first terminal device, the first terminal device is a device that has a shared key, and the first terminal device includes a processor and a receiver. , transmitter and memory.
  • the memory unit is operative to store instructions for executing the memory stored instructions, and when the processor executes the memory stored instructions, the executing causes the processor to perform any of the first aspect or the first aspect The method in the implementation.
  • the receiver is configured to receive a Dieffie Herman DH public key and a first identity ID sent by the at least one second terminal device, where the at least one second terminal device is a device that does not hold the shared key;
  • the transmitter is configured to send a first message to the server, where the first message includes a DH public key of each second terminal device of the at least one second terminal device, and a second of each of the second terminal devices An ID;
  • the receiver is further configured to receive the service
  • the second message sent by the first message, the second message includes a DH public key of the server, and each of the second terminal devices generated by the server for each of the second terminal devices a second ID, the second ID is used to identify the subscriber;
  • the sender is further configured to send, to each of the second terminal devices, the second ID of each second terminal device and the server a DH public key, such that each of the second terminal devices determines each of the authentications for authentication with the server according to the second ID of each of the second terminal devices and the DH public key of
  • a fourth aspect provides a method for authenticating a mobile network, where the method includes:
  • the second terminal device Determining, by the second terminal device, a Dieffie Herman DH public key of the second terminal device, where the second terminal device is a device that does not hold a shared key; and the second terminal device sends a a message to the first terminal device, where the first message includes a DH public key of the second terminal device and a first identity identifier of the second terminal device, where the first terminal device is already held a device for sharing a key; the second terminal device receives a second message that is sent by the first terminal device based on the first message, the second message includes a DH public key of the server, and the server is the a second ID generated by the second terminal device, where the second ID is used to identify the subscriber; the second terminal device determines the first shared key according to the first random number and the DH public key of the server. The second terminal device performs mutual authentication with the server according to the first shared key and the second ID.
  • the terminal device that does not have the credential pre-issued by the operator can obtain the shared key for authenticating with the operator network from the server by means of DH key exchange by using other terminal devices that have the credential.
  • Ability to access the network can obtain the shared key for authenticating with the operator network from the server by means of DH key exchange by using other terminal devices that have the credential.
  • the shared key is only known by the second terminal device and the server, and the first terminal device does not know, therefore, the second terminal device can use the shared secret key and the second ID of the second terminal device, and The servers are authenticated to access the carrier network.
  • the second terminal device receives the second message sent by the first terminal device, where the second terminal device receives the second message sent by the first terminal device, and the server pair a signature message obtained after the second message is signed, and verification information corresponding to the signature message; the second terminal device determines the first share according to the first random number and the DH public key of the server
  • the key includes: the second terminal device verifies the second message according to the second message, the signature message, and the verification information; if the second terminal device is to the second message After the verification is passed, the second terminal device determines the first shared key according to the first random number and the DH public key of the server.
  • the verification message includes a certificate of the server or an ID of the server.
  • the verification information may be a certificate of the server, that is, a certificate corresponding to a private key used by the server to encrypt the second message, so that the second terminal device can The signature is verified according to the certificate; if the server adopts an identity-based key system, the verification information may be an ID of the server, so that the second terminal device can verify the signature according to the ID of the server.
  • the method further includes: the second terminal device generates, according to the first shared key, a message verification code MAC of the second ID for the second ID; the second terminal device The server sends the MAC of the second ID and the second ID; the second terminal device receives a configuration completion message sent by the server based on the MAC of the second ID and the second ID, and The server is the MAC of the configuration completion message generated by the configuration completion message; the second terminal device verifies the MAC of the configuration completion message according to the first shared key; wherein, the second The terminal device performs mutual authentication with the server according to the first shared key and the second ID, including: if the second terminal device passes the MAC verification of the configuration completion message, the second terminal The device performs mutual authentication with the server according to the first shared key and the second ID.
  • the second terminal device can ensure that the first shared key determined by the server is consistent with the first shared key determined by the second terminal device.
  • the fifth aspect provides a terminal device, where the terminal device is a second terminal device, and the terminal device can be used to perform the foregoing fourth aspect, and the second terminal device is used in the authentication method of the mobile network in various implementation manners.
  • the second terminal device is a device that does not hold a shared key, and the second terminal device includes:
  • a determining module configured to determine a Diffie Hermann DH public key of the second terminal device according to the first random number
  • a sending module configured to send the first message to the first terminal device, where the first message includes The DH public key of the second terminal device and the first identity ID of the second terminal device, the first terminal device is a device that has a shared key
  • the receiving module is configured to receive the first The second message sent by the terminal device based on the first message, the second message includes a DH public key of the server, and a second ID generated by the server for the second terminal device, where the second ID is used Identifying a subscriber;
  • the determining module is further configured to: determine, according to the first random number, a DH public key of the server, a first shared key; and an authentication module, configured to use, according to the first shared key, The second ID is mutually authenticated with the server.
  • another terminal device is provided, where the terminal device is a second terminal device, the second terminal device is a device that does not hold a shared key, and the second terminal device includes a processor and a receiver. , transmitter and memory.
  • the memory unit is operative to store instructions for executing the instructions stored by the memory, and when the processor executes the instructions stored by the memory, the executing causes the processor to perform any of the fourth or fourth aspects The method in the implementation.
  • the processor is configured to determine a Duffy Herman DH public key of the second terminal device according to the first random number, and send a first message to the first terminal device, where the first The message includes a DH public key of the second terminal device and a first identity ID of the second terminal device, where the first terminal device is a device that has a shared key, and a receiver is configured to receive the The first terminal device sends a second message based on the first message, where the second message includes a DH public key of the server, and a second ID generated by the server for the second terminal device, the second ID
  • the processor is further configured to: determine, according to the first random number, a DH public key of the server, a first shared key; the processor is further configured to: according to the first A shared key and the second ID are mutually authenticated with the server.
  • a method for authenticating a mobile network comprising:
  • the server receives, by the server, the first message sent by the first terminal device, where the first message includes each of the first terminal devices received by each second terminal device of the at least one second terminal device
  • Two terminal equipment a DH public key and a first ID of each of the second terminal devices
  • the first terminal device is a device that already holds a shared key
  • the at least one second terminal device is a device that does not hold a shared key
  • the server determines a DH public key of the server according to a second random number, and generates a second ID of each second terminal device for each second terminal device, where the second ID is used Identifying a subscriber; the server determining, according to the DH public key of each second terminal device and the second random number, each of the second terminals for performing authentication with each of the second terminal devices a first shared key of the device; the server sends a second message to the first terminal device, where the second message includes a DH public key of the server and a second ID of each second terminal device.
  • the server can provide a shared key for authenticating with the operator network for the terminal device that does not have the credential pre-issued by the operator, based on the DH key exchange manner, by the terminal device that already holds the credential. It can access the network.
  • the shared key is only known by the second terminal device and the server, and the first terminal device does not know, therefore, the second terminal device can use the shared secret key and the second ID of the second terminal device, and The servers are authenticated to access the carrier network.
  • the method includes: the first message further includes indication information, where the indication information is used to indicate that the first message is used to request the second terminal device for each second terminal device a shared key and a second ID of the second terminal device.
  • the indication information may be, for example, a flag bit, which may indicate whether the trust certificate issued by the operator is requested by the second terminal device or the trust issued by the operator for the plurality of second terminal devices. shape.
  • the first terminal device may add the indication information to the first message sent to the server.
  • the second ID may be, for example, an IMSI number assigned by the operator to the subscriber.
  • the receiving, by the server, the first message sent by the first terminal device that: the server receives the first message sent by the first terminal device, and the first terminal device according to the second
  • the shared key is a message authentication code MAC of the first message generated by the first message
  • the second shared key is used for authentication between the first terminal device and the server
  • Determining, by the server, the first shared key of each second terminal device for performing authentication with each of the second terminal devices according to the second random number and the DH public key of the server including: The server verifies the MAC of the first message according to the second shared key; if the server verifies the MAC of the first message, the server is configured according to the second random number, and the server
  • the DH public key determines a first shared key for each second terminal device that is authenticated with each of the second terminal devices.
  • the method before the sending, by the server, the second message to the first terminal device, the method further includes: The server generates a MAC of the second message for the second message according to the second shared key, where the server sends the second message to the first terminal device, including: the server to the The first terminal device sends the MAC of the second message and the second message.
  • the method before the sending, by the server, the second message to the first terminal device, the method further includes: the second ID of the second terminal device by the server, and the DH of the server The key is signed; wherein the server sends the second message to the first terminal device, where the server sends the second message to the first terminal device, and the server pairs the second message After signing the second ID of the terminal device and the DH public key of the server, the signature message of each second terminal device and each of the first messages corresponding to the signature message of each second terminal device are obtained. The verification message of the second terminal device.
  • the server can employ an asymmetric key system (such as a certificate-based cryptographic mechanism or an identity-based cryptographic mechanism), the DH public key of the server to be sent and the identity generated for the terminal device for identifying the subscriber are signed.
  • an asymmetric key system such as a certificate-based cryptographic mechanism or an identity-based cryptographic mechanism
  • the verification message includes a certificate of the server or an ID of the server.
  • the verification information may be a certificate of the server, that is, a certificate corresponding to a private key used by the server to encrypt the second message, so that the second terminal device can The certificate verifies the signature; if the server uses an identity-based key system, the verification information may be the ID of the server, so that the second terminal device can verify the signature according to the ID of the server.
  • the method before the sending, by the server, the second message to the first terminal device, the method further includes: the server, according to the second shared key, the DH public key of the server and each of the Encrypting the second ID of the second terminal device; wherein the DH public key of the server and the second terminal device of the second message sent by the server to the first terminal device
  • the second ID is encrypted by the server.
  • the method further includes: the server receiving, by the second terminal device, the second ID of each second terminal device, and each of the second terminal devices is the a message authentication code MAC generated by the second ID of the second terminal device; the server verifies the MAC of the second ID of each second terminal device according to the first shared key; if the server Successfully verifying the MAC of the second ID of each of the second terminal devices, the server transmitting a configuration completion message to each of the second terminal devices, and the configuration generated by the server for the configuration completion message Complete the MAC of the message.
  • a server is provided, where the server may be used to perform various processes performed by a server in the authentication method of the mobile network in the foregoing seventh aspect and various implementation manners, where the server includes:
  • a receiving module configured to receive a first message sent by the first terminal device, where the first message includes a location that the first terminal device receives from each of the at least one second terminal device a DH public key of each second terminal device and a first ID of each of the second terminal devices, where the first terminal device is a device that has a shared key, and the at least one second terminal device is a device that does not hold the shared key; a determining module, configured to determine a DH public key of the server according to the second random number, and generate a second of each second terminal device for each second terminal device ID, the second ID is used to identify the subscriber; the determining module is further configured to determine, according to the DH public key and the second random number of each second terminal device, a first shared key of each of the second terminal devices that is authenticated by the second terminal device; a sending module, configured to send a second message to the first terminal device, where the second message includes the DH of the server Public key and each of the second terminal devices The second ID.
  • another server comprising a processor, a receiver, a transmitter and a memory.
  • the memory unit is operative to store instructions for executing the memory stored instructions, and when the processor executes the memory stored instructions, the executing causes the processor to perform any of the seventh or seventh aspects The method in the implementation.
  • the receiver is configured to: receive the first message sent by the first terminal device, where the first message includes the first terminal device receiving from each second terminal device of the at least one second terminal device
  • the DH public key of each of the second terminal devices and the first ID of each of the second terminal devices the first terminal device is a device that already holds a shared key, and the at least one second terminal
  • the device is a device that does not hold the shared key
  • the processor is configured to: determine a DH public key of the server according to the second random number, and generate, for each of the second terminal devices, the second terminal device a second ID, the second ID is used to identify the subscriber, and is determined to perform authentication with each of the second terminal devices according to the DH public key of each second terminal device and the second random number.
  • the first shared key of each of the second terminal devices the transmitter, configured to send a second message to the first terminal device, where the second message includes a DH public key of the server and the The second ID of each second terminal device.
  • a tenth aspect provides a method for authenticating a mobile network, the method comprising:
  • the first terminal device receives the Duffy Herman DH public key and the first identity ID sent by the at least one second terminal device, where the first terminal device is a device that has a shared key, and the at least one second The terminal device is a device that does not hold the shared key; the first terminal device sends an attach request message to the network authentication entity, where the attach request message includes the first message and the identity identifier of the first terminal device, The first message includes a DH public key of each of the at least one second terminal device and a first ID of each of the second terminal devices; the first terminal device receives the network a user authentication request message sent by the authentication entity based on the attach request message, where the user authentication request message includes a second message and authentication data, the second message includes a DH public key of the server, and the server is the a second ID of each of the second terminal devices generated by each second terminal device, the second ID is used to identify a subscriber; the first terminal device is to each of the second terminals End device transmitting a DH public key of the server and
  • the terminal device can establish a channel for key agreement with the server for the terminal device that does not hold the credential pre-issued by the operator in the process of authenticating with the operator network according to the credential that it has already held.
  • a terminal device that does not have a credential pre-issued by the operator can also be obtained from the server for use with the carrier network.
  • the authenticated shared key is thus connected to the network.
  • the method further includes: the first terminal device receives the second ID of each second terminal device that is sent by each second terminal device, and each of the second terminal devices is a message verification code MAC generated by the second ID of each second terminal device; the first terminal device sends the second ID of each of the second terminal devices to the network authentication entity, and each of the a MAC of the second ID of the second terminal device; the first terminal device receiving the network authentication entity based on the second ID of each of the second terminal devices and the second ID of each of the second terminal devices a configuration completion message sent by the MAC; the first terminal device sends the configuration completion message to each of the second terminal devices.
  • the first terminal device receives the second ID of each second terminal device that is sent by each second terminal device, and each of the second terminal devices is a message verification code MAC generated by the second ID of each second terminal device
  • the first terminal device sends the second ID of each of the second terminal devices to the network authentication entity, and each of the a MAC of the second ID of the second terminal device
  • the first terminal device receiving
  • the method further includes: the first terminal device sends a user authentication response message to the network authentication entity according to the user authentication request message; the first terminal device receives the network authentication entity based on the The authentication success message sent by the authentication response message.
  • the server comprises a home subscriber server HSS.
  • the network authentication entity includes a mobility management entity MME.
  • a terminal device where the terminal device is a first terminal device, and the terminal device can be used to execute the first terminal in the foregoing tenth aspect and the authentication method of the mobile network in various implementation manners.
  • the first terminal device is a device that has a shared key, and the first terminal device includes:
  • a receiving module configured to receive a Dieffie Herman DH public key and a first identity ID sent by the at least one second terminal device, where the at least one second terminal device is a device that does not hold the shared key;
  • the first message is sent to the server, where the first message includes a DH public key of each second terminal device of the at least one second terminal device and a first ID of each of the second terminal devices;
  • the receiving module is further configured to receive a second message that is sent by the server based on the first message, where the second message includes a DH public key of the server, and the server is the second terminal device Generating the second ID of each of the second terminal devices, the second ID is used to identify the subscriber, and the sending module is further configured to send the second to each of the second terminal devices a second ID of the terminal device and a DH public key of the server, such that each of the second terminal devices is determined to be used according to the second ID of each of the second terminal devices and the DH public key of the server Said to authenticate with
  • another terminal device is provided, where the terminal device is a first terminal device, the first terminal device is a device that has a shared key, and the first terminal device includes a processor and receives , transmitter and memory.
  • the memory unit is operative to store instructions for executing the memory stored instructions, and when the processor executes the memory stored instructions, the executing causes the processor to perform any of the tenth or tenth aspects The method in the implementation.
  • the receiver is configured to receive a Dieffie Herman DH public key and a first identity ID sent by the at least one second terminal device, where the at least one second terminal device is a device that does not hold the shared key;
  • the transmitter is configured to send a first message to the server, where the first message includes a DH public key of each second terminal device of the at least one second terminal device, and a second of each of the second terminal devices An ID, the receiver receiving a second message sent by the server based on the first message, the second message includes a DH public key of the server, and the server is each of the second terminal devices Generating a second ID of each of the second terminal devices, where the second ID is used to identify a subscriber; the transmitter sends the second terminal device to each of the second terminal devices a second ID and a DH public key of the server, such that each of the second terminal devices determines to be used with the server according to the second ID of each of the second terminal devices and the DH public key of the server Each of the second to be authenticated
  • a method for authenticating a mobile network comprising:
  • the network authentication entity receives an attach request message sent by the first terminal device, where the attach request message includes a first message and an identity identifier of the first terminal device, where the first message includes the at least one second terminal a DH public key of each second terminal device in the device and a first ID of each of the second terminal devices, the first terminal device being a device that already holds a shared key, and the at least one second terminal
  • the device is a device that does not hold a shared key;
  • the network authentication entity sends an authentication data request message to the server according to the attach request message;
  • the network authentication entity receives the authentication sent by the server based on the authentication data request message a data response message, wherein the authentication data response message includes a second message and an authentication vector, the second message including a DH public key of the server, and a location generated by the server for each of the second terminal devices a second ID of each second terminal device, where the second ID is used to identify a subscriber;
  • the network authentication entity sends the first terminal device And the second message and
  • the network authentication entity can provide a channel for the key agreement between the server and the server that does not hold the certificate pre-issued by the operator, so that the network authentication entity can
  • a terminal device that does not have a credential pre-issued by the operator can also obtain a shared key for authentication with the operator network from the server to access the network.
  • the method further includes: the network authentication entity receiving, by the first terminal device, a second ID of each of the second terminal devices, where each of the second terminal devices is the each a message verification code MAC generated by the second ID of the second terminal device, and a user authentication response message sent by the first terminal device based on the user authentication request message; the network authentication entity sends the each to the server a second ID of the second terminal device and a MAC of the second ID of each of the second terminal devices; the network authentication entity receiving the server based on the second ID of each of the second terminal devices and the each a configuration completion message sent by the MAC of the second ID of the second terminal device; the network authentication entity sends an authentication success message to the first terminal device according to the user authentication response message, and sends the message to the first terminal device And sending the configuration completion message, so that the first terminal device sends the configuration completion message to each of the second terminal devices.
  • a network authentication entity configured to perform the processes performed by the network authentication entity in the authentication method of the mobile network in the foregoing thirteenth aspect and various implementation manners,
  • the network authentication entity includes:
  • a receiving module configured to receive an attach request message sent by the first terminal device, where the attach request message includes a first message and an identity identifier of the first terminal device, where the first message includes the at least one a DH public key of each of the second terminal devices and a first ID of each of the second terminal devices, where the first terminal device is a device that has a shared key, the at least one The second terminal device is a device that does not hold the shared key, and the sending module is configured to send an authentication data request message to the server according to the attach request message, where the receiving module is further configured to receive the server based on the authentication data.
  • An authentication data response message sent by the request message wherein the authentication data response message includes a second message and an authentication vector, the second message includes a DH public key of the server, and the server is each of the second a second ID of each of the second terminal devices generated by the terminal device, where the second ID is used to identify the subscriber; the sending module is further configured to: go to the first terminal The device sends the second message and the authentication data in the authentication vector, so that the first terminal device sends the DH public key of the server and each of the second terminals to each of the second terminal devices The second ID of the device.
  • another network authentication entity comprising a processor, a receiver, a transmitter, and a memory.
  • the memory unit is configured to store an instruction for executing the memory stored instruction, and when the processor executes the memory stored instruction, the executing causes the processor to perform any of the thirteenth aspect or the thirteenth aspect The method in the possible implementation.
  • the receiver is configured to receive an attach request message sent by the first terminal device, where the attach request message includes a first message and an identity identifier of the first terminal device, where the first message includes the a DH public key of each of the at least one second terminal device and a first ID of each of the second terminal devices, where the first terminal device is a device that already holds a shared key,
  • the at least one second terminal device is a device that does not hold the shared key
  • the sender is configured to send an authentication data request message to the server according to the attach request message
  • the receiver is further configured to receive the server based An authentication data response message sent by the authentication data request message, where the authentication data response message includes a second message and an authentication vector, the second message includes a DH public key of the server, and the server is the a second ID of each of the second terminal devices generated by the second terminal device, the second ID is used to identify the subscriber
  • the transmitter is further configured to: And transmitting the second message and the authentication data in the authentication vector, so that the first terminal device send
  • a method for authenticating a mobile network comprising:
  • an authentication data request message sent by the network authentication entity where the authentication data request message includes a first message and an identity identifier of the first terminal device, where the first message includes each second of the at least one second terminal device a DH public key of the terminal device and a first ID of each of the second terminal devices, the at least one second terminal device being a device not holding a shared key; the server determining a DH public key of the server, And generating, for each of the second terminal devices, a second ID of each of the second terminal devices, where the second ID is used to identify a subscriber; the server determines an authentication vector based on the authentication data request message Transmitting, by the server, a user authentication response message to the network authentication entity, where the user authentication response message includes the second message and the authentication vector, and the second message includes a DH public key of the server, and The second ID of each second terminal device.
  • the method includes: the server receiving, by the network authentication entity, a second ID of each second terminal device, and each of the second terminal devices is each of the second terminals a message authentication code MAC generated by the second ID of the device; the server verifies the MAC of the second ID of each second terminal device according to the first shared key; if the server pairs the The MAC authentication of the second ID of the second terminal device passes, and the server sends a configuration completion message to the network authentication entity.
  • the server can provide the terminal device without the pre-issued credential of the operator for performing with the carrier network in the process of authenticating with the terminal device that holds the credential, based on the DH key exchange.
  • the authenticated shared key is thus allowed to access the network.
  • a server is provided, and the server may be used to perform the processes performed by the server in the authentication method of the mobile network in the foregoing sixteenth aspect and various implementation manners, where the server includes:
  • a receiving module configured to receive an authentication data request message sent by the network authentication entity, where the authentication data request message includes a first message and an identity identifier of the first terminal device, where the first message includes at least one second terminal device a DH public key of each second terminal device and a first ID of each of the second terminal devices, the at least one second terminal device being a device not holding a shared key; a determining module, configured to determine the a DH public key of the server, and for each of the second terminal devices, generating a second ID of each of the second terminal devices, where the second ID is used to identify the subscriber; the determining module is further configured to: Determining an authentication vector based on the authentication data request message; a sending module, configured to send a user authentication response message to the network authentication entity, where the user authentication response message includes the second message and the authentication vector, and the second message includes a DH public key of the server, And a second ID of each of the second terminal devices.
  • another server comprising a processor, a receiver, a transmitter, and a memory.
  • the memory unit is configured to store an instruction for executing the memory stored instruction, and when the processor executes the memory stored instruction, the executing causes the processor to perform any of the sixteenth aspect or the sixteenth aspect The method in the possible implementation.
  • the receiver is configured to receive an authentication data request message sent by the network authentication entity, where the authentication data request message includes a first message and an identity identifier of the first terminal device, where the first message includes at least one second terminal. a DH public key of each second terminal device in the device and a first ID of each of the second terminal devices, the at least one second terminal device being a device not holding a shared key; a determining module, configured to: Determining a DH public key of the server, and generating, for each of the second terminal devices, a second ID of each of the second terminal devices, where the second ID is used to identify a subscriber; the processor is configured to: And determining, according to the authentication data request message, an authentication vector, where the transmitter is configured to send a user authentication response message to the network authentication entity, where the user authentication response message includes the second message and the authentication vector,
  • the second message includes a DH public key of the server and a second ID of each of the second terminal devices.
  • a nineteenth aspect a computer readable medium for storing a computer program, the computer program comprising instructions for performing the method of the first aspect or any of the possible implementations of the first aspect.
  • a computer readable medium for storing a computer program comprising instructions for performing the method of any of the fourth aspect or any of the possible implementations of the fourth aspect.
  • a twenty-first aspect a computer readable medium for storing a computer program, the computer program comprising instructions for performing the method of any of the seventh aspect or any of the possible implementations of the seventh aspect.
  • a twenty-second aspect a computer readable medium for storing a computer program, the computer program comprising instructions for performing the method of any of the tenth or tenth aspects of the tenth aspect.
  • a twenty-third aspect a computer readable medium for storing a computer program, the computer program comprising instructions for performing the method of the thirteenth aspect or any of the possible implementations of the thirteenth aspect.
  • a twenty-fourth aspect a computer readable medium for storing a computer program comprising instructions for performing the method of the sixteenth aspect or any of the possible implementations of the sixteenth aspect.
  • the terminal device that does not have the credential pre-issued by the operator can be obtained from the server by using the DH key exchange mode by using other terminal devices that have the credential.
  • the carrier network authenticates the shared key to access the network.
  • FIG. 1 is a schematic diagram of an application scenario of an embodiment of the present application.
  • FIG. 2 is a schematic diagram of a digital signature and verification process.
  • Figure 3 is a schematic diagram of an identity based cryptographic mechanism.
  • FIG. 4 is a schematic diagram of a Diffie-Hellman key exchange process.
  • FIG. 5 is a schematic diagram of a conventional entity SIM card based two-way authentication process.
  • FIG. 6 is a schematic diagram of a two-way authentication process based on eUICC.
  • FIG. 7 is a schematic structural diagram of a method for authenticating a mobile network according to an embodiment of the present application.
  • FIG. 8 is a flow diagram of a process of an authentication method of a mobile network according to an embodiment of the present application.
  • FIG. 9 is a flow diagram of a process for verifying a shared secret key in an embodiment of the present application.
  • FIG. 10 is a flow diagram of a process of an authentication method of a mobile network according to an embodiment of the present application.
  • FIG. 11 is a flow diagram of a process of an authentication method of a mobile network according to an embodiment of the present application.
  • FIG. 12 is a schematic flow chart of an AKA-based authentication method in the prior art.
  • FIG. 13 is a flow diagram of a process of an authentication method of a mobile network according to an embodiment of the present application.
  • FIG. 14 is a flow diagram of a process of an authentication method of a mobile network according to an embodiment of the present application.
  • FIG. 15 is a schematic block diagram of a terminal device according to an embodiment of the present application.
  • FIG. 16 is a schematic block diagram of a terminal device according to an embodiment of the present application.
  • 17 is a schematic block diagram of a server in an embodiment of the present application.
  • FIG. 18 is another schematic block diagram of a terminal device according to an embodiment of the present application.
  • FIG. 19 is another schematic block diagram of a terminal device according to an embodiment of the present application.
  • FIG. 20 is another schematic block diagram of a server according to an embodiment of the present application.
  • FIG. 21 is a schematic block diagram of a terminal device according to another embodiment of the present application.
  • FIG. 22 is a schematic block diagram of a network authentication entity according to another embodiment of the present application.
  • FIG. 23 is a schematic block diagram of a server according to another embodiment of the present application.
  • FIG. 24 is another schematic block diagram of a terminal device according to another embodiment of the present application.
  • FIG. 25 is another schematic block diagram of a network authentication entity according to another embodiment of the present application.
  • FIG. 26 is another schematic block diagram of a server according to another embodiment of the present application.
  • a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer.
  • an application running on a computing device and a computing device can be a component.
  • One or more components can reside within a process and/or execution thread, and the components can be located on one computer and/or distributed between two or more computers.
  • these components can execute from various computer readable media having various data structures stored thereon.
  • a component may, for example, be based on signals having one or more data packets (eg, data from two components interacting with another component between the local system, the distributed system, and/or the network, such as the Internet interacting with other systems) Communicate through local and/or remote processes.
  • data packets eg, data from two components interacting with another component between the local system, the distributed system, and/or the network, such as the Internet interacting with other systems
  • GSM Global System of Mobile communication
  • CDMA Code Division Multiple Access
  • WCDMA Wideband Code Division Multiple Access
  • GPRS General Packet Radio Service
  • LTE Long Term Evolution
  • LTE-A Advanced Long Term Evolution
  • UMTS Universal Mobile Telecommunication System
  • the terminal device may also refer to a user equipment (User Equipment, UE), Access terminal, subscriber unit, subscriber station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent or user device.
  • the access terminal may be a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA), with wireless communication.
  • the network device in the embodiment of the present application may be a device for communicating with the terminal device, for example, may be a base station (Base Transceiver Station, BTS) in a GSM system or a CDMA system, or a base station (NodeB in a WCDMA system. NB), which may also be an evolved base station (Evolutional Node B, eNB or eNodeB) in the LTE system, or the network device may be a relay station, an access point, an in-vehicle device, a wearable device, and a network side device in a future 5G network. Or network devices in a future evolved PLMN network, and the like.
  • BTS Base Transceiver Station
  • NodeB base station
  • NB evolved base station
  • the network device may be a relay station, an access point, an in-vehicle device, a wearable device, and a network side device in a future 5G network.
  • network devices in a future evolved PLMN network and the like
  • FIG. 1 is a schematic diagram of an application scenario of an embodiment of the present application.
  • the communication system may include a network device 10, a terminal device 20, a terminal device 30, a terminal device 40, and a server 50.
  • the arrows shown in Figure 1 may represent the connection between the device and the device.
  • the terminal device 30 and the terminal device 40 may be IoT devices, and the terminal device 40 may directly connect to the network device 10 and access the core network, and the terminal device 30 may pass through the partner device, that is, the terminal device 20, and The network device 10 connects and accesses the core network.
  • the certificate issued by the operator, Credential is the International Mobile Subscriber Identity (IMSI) and the pre-shared key.
  • IMSI International Mobile Subscriber Identity
  • the IoT device needs its own Credential.
  • a conventional device such as a mobile phone or the like can acquire a 3GPP Credential through a physical Subscriber Identity Module (SIM) card.
  • SIM Subscriber Identity Module
  • the physical SIM card does not apply to the physical SIM card.
  • eSIM Embedded Subscriber Identity Module
  • soft SIM will be a better choice for IoT devices.
  • IoT communication since the manufacturer does not know where the final IoT device will be used in that operator's network, there is a great possibility that the IoT device is not configured with any initial configuration at the factory. Trust.
  • the present application proposes that the terminal device obtains the remote access operator credential through the partner device that already holds the shared key, so that the acquired operator credential can be used for mutual authentication with the corresponding network, and the network is accessed and used. .
  • FIG. 1 is only intended to help those skilled in the art to better understand the embodiments of the present application, and does not limit the scope of the embodiments of the present application.
  • a greater number of IoT devices can access the network through the partner device and the access network, and more The number of partner devices is used to enable access to different IoT devices.
  • the present application does not limit the type of the terminal device.
  • the partner device in the embodiment of the present application may also be referred to as a pairing device, a guarantee device, a card-equipped device, an intermediate device, etc., and the partner device has a pre-issued trust certificate and has an operation.
  • the shared key pre-issued by the commerce network can borrow the shared key and complete the authentication itself.
  • the partner device may be a device holding a SIM card of a 2G network, or a device such as a USIM card or an ISIM card holding a 3, 4G network, or may be held in the future 5G.
  • a device having another user identification module for identifying a user identity or a device having a pre-made certificate with high security capability or high security pre-released by the network, or a strong shared key (for example, a user) A device such as a password, etc.).
  • the terminal device that does not have the credential pre-issued by the operator network in the embodiment of the present application cannot complete the authentication process by itself during the authentication process of requesting access to the network, and must rely on manual participation and through human-computer interaction. Complete the certification.
  • the terminal device that does not have the credential pre-issued by the operator network may acquire the shared key authenticated by the server and the identity identifier used for identifying the subscription, such as an international mobile user, through the partner device paired with the network.
  • IMSI International Mobile Subscriber Identification Number
  • the credential in the embodiment of the present application may include a shared key and an identifier for identifying the subscriber, such as an IMSI, and may also include other useful information, which is not limited herein.
  • Asymmetric encryption is a type of cryptographic algorithm in which a pair of keys is required, one for the private key and the other for the public key. These two keys are mathematically related.
  • the information obtained by encrypting with a user key can only be decrypted by using the decryption key of the user. If you know one of them, you can't figure out another one. Therefore, if one of a pair of keys is disclosed, it does not endanger the secret nature of the other.
  • the private key is held by the key pair owner and cannot be advertised.
  • the public key is the key pair issued to the holder by the holder, so the public key is called the public key; the undisclosed key is the private key.
  • the encryption key is public, this is used by the client to upload the encrypted data to the private key owner.
  • This is called public key encryption.
  • the data encrypted with the public key can only be decrypted using the private key.
  • the private key is used to decrypt the public.
  • Key encrypted data Common public key encryption algorithms are: RSA, ElGamal, backpack algorithm, Rabin (RSA special case), Elliptic Curve Cryptography (ECC).
  • RSA Rivest, Shmir, and Adleman
  • ECC Elliptic Curve Cryptography
  • the decryption key is public
  • the information encrypted with the private key can be decrypted with the public key, and the client can verify that the data or file published by the party holding the private key is complete and accurate, and the recipient can know the information. It does come from someone who owns a private key.
  • This is called a digital signature.
  • the public key is in the form of a digital certificate.
  • an installer downloaded from the Internet generally has a digital signature of the program creator, which can prove that the program was indeed published by the author (company) and not forged by a third party and has not been tampered with (identification/verification). .
  • Figure 2 is a schematic diagram of digital signature and verification.
  • the sender encrypts the digest that needs to transmit text by using the private key, and the obtained ciphertext is called a digital signature (referred to as “signature”) of the transmission process, wherein the abstract of the transmitted text is Hash calculations such as SHA1 and SHA2 are performed on the text to be transmitted.
  • signature digital signature
  • Hash calculations such as SHA1 and SHA2 are performed on the text to be transmitted.
  • the receiving party that is, the party receiving the data, after obtaining the transmitted text, needs to confirm whether the text is the content sent by the sender, and has been tampered with in the middle. Therefore, the receiver can decrypt the signature with the public key it holds (the data encrypted by one key in the key pair must be decrypted using another key), and the extracted text is extracted. Then, use the same HASH algorithm as the sender to calculate the digest value, and then compare it with the decrypted digest. If the two are found to be identical, the transmitted text has not been tampered with.
  • a public certificate of all senders can be managed by a unified certificate authority, and these public keys are authenticated and encrypted.
  • This institution is also known as the Certificate Agency (CA).
  • the encrypted public key is the certificate, also known as the CA certificate.
  • the certificate contains a lot of information, the most important is the applicant's public key.
  • the certificate needs to be decrypted to obtain the certificate.
  • Public key decryption needs to use the public key in the CA's "unified key pair". This public key is also the CA root certificate we often say. Usually we need to go to the certificate authority to download and install the corresponding data. The client, such as the browser above. This public key only needs to be installed once. With this public key, you can decrypt the certificate, get the sender's public key, then decrypt the signature sent by the sender, get the digest, recalculate the digest, and compare to verify the integrity of the data content.
  • Identity-Based Cryptography includes Identity Based Signature (IBS) and Identity Based Encryption (IBE).
  • Each user has its own public-private key pair, where the public key is a meaningful string (identity), such as an email address, phone number, etc.; the user's private key is determined by the Private Key Generator (PKG) based on the user ID. And the PKG's primary private key is generated. PKG participation is not required in the signature process.
  • Signature verification only requires signature, message, identity and master public key.
  • the difference between the traditional public key infrastructure (PKI) mechanism and the IBC is that the user in the PKI has a pair of different public and private keys.
  • the public key is a random string.
  • the certificate center needs to sign the public key to confirm a public key. It belongs to a user, and the certificate needs to be verified during the signing or encryption process.
  • users Alice and Bob each have their own public-private key pair.
  • PKG generates Alice's private key SK Alice according to Alice's ID Alice and PKG's primary private key. Alice uses his private. The key signs the message that needs to be transmitted.
  • the PKG is not involved in the signature process.
  • Bob only needs the signature, message, ID Alice and the master public key GPK to verify the signature sent by Alice .
  • the earliest proposed protocol is based on an integer modulo n multiplicative group with a prime p and its original root g, which is explained below (including the mathematical part of the algorithm):
  • FIG. 5 is a schematic diagram of a conventional entity SIM card based two-way authentication process.
  • the terminal device and the server are two-way authentication based on a pre-shared key.
  • the pre-shared key is to pre-place the symmetric key in the SIM card of the terminal and in the Home Subscriber Server (HSS) of the core network.
  • HSS Home Subscriber Server
  • the protocol adopted is the Authentication and Key Agreement (AKA) described in 3GPP TS 33.401.
  • AKA Authentication and Key Agreement
  • the Credential required for authentication is the IMSI and the pre-shared key, and the information is stored.
  • SIM card In the SIM card.
  • SIM card manufacturers In the traditional credential configuration process, operators need to provide input and customization files to SIM card manufacturers, including IMSI numbers, user and carrier profiles.
  • the SIM card manufacturer After receiving the data, the SIM card manufacturer generates a corresponding key for each IMSI number, and writes the IMSI number and the corresponding key Ki to the physical SIM card.
  • the IMSI number, key, and their correspondence are saved to the physical CD.
  • the SIM card is then returned to the operator along with the CD.
  • the operator saves the obtained IMSI number, key, and its corresponding relationship to its HSS.
  • the SIM card is then issued to the user when the user signs up.
  • the IMSI number and the pre-shared key stored in the SIM can be mutually authenticated with the carrier network to access and use the network.
  • SIM card-based two-way authentication method The main disadvantage of this SIM card-based two-way authentication method is that the whole process is carried out offline, with long chain, many links, long cycle, high transportation and maintenance costs; Credential is issued to the user through the physical SIM card, and the user changes Operators need to replace physical SIM cards; due to their own characteristics, in many cases, it is not advisable to use physical SIM cards.
  • industrial IoT devices need to work in extreme environments, high temperature, humidity, dust. , severe vibration, etc. will make the SIM card bad contact, or easily damaged; and because of the huge number of IoT devices, a load needs to replace the SIM card, the workload is very large; in addition, IoT devices are usually small devices such as sensors Using a traditional SIM card will limit the space and design of IoT devices.
  • FIG. 6 is a schematic diagram of a two-way authentication process based on eUICC.
  • the most important of the existing two-way authentication process is the remote configuration standard established by the GSMA. Based on the standard, the remote configuration process is implemented to achieve mutual authentication between the terminal device and the server.
  • FIG. 6 illustrates a process of remote configuration based on an Embedded Universal Integrated Circuit Card (eUICC) developed by the Global System for Mobile Communications Alliance (GSMA).
  • eUICC Embedded Universal Integrated Circuit Card
  • GSMA Global System for Mobile Communications Alliance
  • SM-DP Subscription Manager Data Preparation
  • SM Subscription Manager Secure Routing
  • the main role of -SR is responsible for secure execution of platform management commands and secure transfer of text management commands.
  • the process of remote configuration based on this architecture is as follows:
  • the Certificate Issuer (CI) issues certificates to SM-DP and SM-SR.
  • CI produces a series of certificates for the eUICC Manufacturer (EUM).
  • EUM places the certificate into the eUICC when it produces the eUICC.
  • MNO Mobile Network Operator
  • the SM-DP and SM-SR are typically deployed by the MNO, so there is a secure path between the MNO and the MNO.
  • the MNO's Credential is then downloaded to the eUICC via SM-DP and SM-SR. After obtaining the Credential provided by the MNO, the eUICC can then use this Credential to directly access and use the MNO network.
  • This two-way authentication method based on the existing GSMA specification requires the use of the initial Credential and the operator mutual authentication and establishes a secure channel. Therefore, the eUICC must have an initial credential (certificate or pre-shared secret) built in, but in the Internet of Things.
  • the vendor since the vendor does not know where the final IoT device will be used in that carrier's network, there is a great possibility that the IoT device is not configured with any initial Credential at the factory. Therefore, existing technologies and specifications cannot meet the needs of the remote access operator Credential, which has no initial Credential IoT device.
  • operators need to deploy SM-DP and SM-SR Server and obtain certificates from CIs, which will increase operators' operating and maintenance costs.
  • FIG. 7 is a schematic structural diagram of a method for authenticating a mobile network according to an embodiment of the present application.
  • the leftmost side is two second terminal devices
  • the middle is the first terminal device
  • the rightmost end is the provisioning server (Provision Server) for network authentication of the carrier network, which will be referred to as a server.
  • Provision Server Provision Server
  • Two second terminal devices are shown here, but in actual application, the second terminal device may have one or more, and these second terminal devices do not have an initial trust for authentication with the carrier network. shape. Therefore, the embodiment of the present application provides that the second terminal device can access the cellular network through the first terminal device, or directly connect to the cellular network.
  • the server in the figure can be an entity, the entity can be HSS (ie the server function can be implemented by HSS), or the HSS and server can be two separate entities. If it is two separate entities, it is assumed that there is a secure channel between the HSS and the server (because they belong to the same carrier domain and belong to the same security domain). Moreover, it is assumed here that the second terminal device can establish a secure channel with the first terminal device through other short-distance methods. For example, a common secure channel establishment method uses Bluetooth pairing technology and the same wireless fidelity (WiFi) LAN encryption. Access control technology, or use wired or other means.
  • WiFi wireless fidelity
  • the second terminal device may be a terminal device that does not have a credential pre-issued by the operator network, such as a shared key and an identity identifier for identifying the subscriber, and other related information, such as the terminal device 30 in FIG.
  • the first terminal device may be a partner device that already holds the shared key, such as the terminal device 20 in FIG.
  • the second terminal device may acquire, by using the first terminal device paired with the first terminal device, a credential for authenticating with the configuration server from the configuration server, for example, the server 50.
  • the terminal and the carrier network, or the core network (CN) (for example, The communication between the core network authentication entity and the configuration server can be forwarded through an Access Network (AN), such as a base station.
  • AN Access Network
  • FIG. 8 shows a first terminal device, a second terminal device, and a server.
  • At least one second terminal device may acquire a shared key for performing authentication with the server by using the first terminal device, thereby accessing the carrier network.
  • the following is an example of a second terminal device.
  • the second terminal device can obtain a credential for performing mobile network authentication from the server, that is, a shared key with the server. It is used to identify the identity of the subscriber, but the application is not limited to this.
  • FIG. 8 is a flow diagram of a process of an authentication method of a mobile network according to an embodiment of the present application. As shown in Figure 8, the mobile network
  • the authentication methods of the network include:
  • the second terminal device determines a Diffie-Hellman (DH) public key of the second terminal device according to the first random number.
  • DH Diffie-Hellman
  • the second terminal device is a device that does not hold a shared key. That is to say, the second terminal device does not have the trust certificate issued by the operator in advance, and cannot be authenticated between the servers to access the carrier network.
  • the shared key can be negotiated between the second terminal device and the server by using the Diffie-Hellmann method. That is, the shared key for network authentication is negotiated with the server according to the DH key exchange method by using the condition that the first terminal device has the operator's credential.
  • the second terminal device sends the DH public key of the second terminal device and the first ID of the second terminal device to the first terminal device.
  • the first terminal device is a device that already holds a shared key.
  • the second terminal device may establish a secure channel with the first terminal device, such as a Bluetooth pairing technology, an encrypted access control technology of a WiFi local area network, or a short-distance communication method such as a wired network to establish a secure channel, and set its own in the secure channel.
  • a secure channel such as a Bluetooth pairing technology, an encrypted access control technology of a WiFi local area network, or a short-distance communication method such as a wired network to establish a secure channel, and set its own in the secure channel.
  • An ID and the generated public key are sent to the first terminal device.
  • the first terminal device receives the DH public key and the first ID sent by the second terminal device.
  • the first terminal device receives the DH public key of the second terminal device, for example, A and the first ID of the second terminal device, sent by the second terminal device in the secure channel.
  • the first terminal device may receive each of the plurality of second terminal devices at this time.
  • the first terminal device sends a first message to the server.
  • the first message includes a DH public key of the second terminal device and a first ID of the second terminal device.
  • the first message may further include indication information, where the indication information is used to indicate that the first message is used to request a shared key of the second terminal device and a second ID of the second terminal device, the second ID Used to identify the subscriber.
  • the indication information is used to indicate that the first message is used to request the second terminal device device to request the second terminal device for the second terminal device
  • the trust may include the second terminal device.
  • the second ID may be, for example, an IMSI.
  • the indication information may be, for example, a flag bit, which may indicate whether the second terminal device requests the certificate issued by the operator for a second terminal device or the trust certificate issued by the operator for the plurality of second terminal devices.
  • the first terminal device may add the indication information to the first message sent to the server. .
  • the first terminal device receives the first ID of each second terminal device and the DH public key of each second terminal device sent by each of the plurality of second terminal devices, then The first terminal device needs to send the first ID of each second terminal device and the DH public key of each second terminal device to the server.
  • the indication information may indicate that the first message is requested for a plurality of second terminal devices for entering with the server.
  • the server receives the first message sent by the first terminal device.
  • the server may obtain the second ID of the second terminal device and the DH public key of the second terminal device from the first message, to generate, for generating, with the second terminal device.
  • the shared key for authentication may be obtained by the server.
  • the server determines a DH public key of the server according to the second random number, and generates a second ID of the second terminal device for the second terminal device.
  • the server determines the DH public key of the server, so that it can be generated for performing with the second terminal device according to the second random number of the generated public key and the received DH public key of the second terminal device.
  • the first shared secret of the authenticated second terminal device may transfer the self-public key to the second terminal device, so that the second terminal device may determine, according to the DH public key of the server and the first random number used by the second terminal device to generate the own public key, The same first shared secret that the server authenticates.
  • the generator of group G, where g and p can be pre-agreed in the protocol, and the terminal device is maintained together with the server.
  • the second ID is used to identify the subscriber.
  • the second ID may be an IMSI number assigned by the operator to the user.
  • the second ID is an ID generated by the operator for the second terminal device to access the operator. It should be understood that the second ID may include information of other IDs in addition to the ID for identifying the subscriber.
  • the server may be each of the plurality of second terminal devices.
  • the second terminal device generates a second ID of each second terminal device such that each second terminal device authenticates with the server using the second ID of each second terminal device.
  • the server determines, according to the DH public key of the second terminal device, and the second random number of the server, a first shared key of the second terminal device used for performing authentication with the second terminal device.
  • the server may determine, according to the DH public key of the second terminal device in the first message, and the second random number of the server, The first shared secret key (which may also be the root key) of the second terminal device authenticated by the terminal device.
  • the server sends a second message to the first terminal device.
  • the second message includes a DH public key of the server and a second ID of the second terminal device.
  • the second message includes the server as each of the plurality of second terminal devices.
  • the first terminal device receives a second message that is sent by the server based on the first message.
  • the first terminal device sends the second ID of the second terminal device and the DH public key of the server to the second terminal device.
  • the first terminal device may send the second ID of the second terminal device and the DH public key of the server in the first message to the second terminal device.
  • the first terminal device separately sends the second ID of each second terminal device to each second terminal device.
  • the DH public key of the server so that each second terminal device can receive its own second ID and the DH public key of the server; or the first terminal device can directly send the second terminal to each second terminal device.
  • the second ID of all the second terminal devices in the message and the DH public key of the server so that each second terminal device determines the second ID belonging to itself after receiving the second ID of all the second terminal devices. .
  • the second terminal device receives the second ID of the second terminal device and the DH public key of the server that are sent by the first terminal device.
  • the second terminal device determines the first shared key according to the first random number of the second terminal device and the DH public key of the server.
  • the second terminal device may be based on the DH public key of the server in the first message, and the second terminal device.
  • the first random number used when generating the own DH public key determines the first shared secret key of the second terminal device for authentication with the server.
  • the server is configured according to The second random number of the server and the shared secret key determined by the DH public key of the different second terminal device for authenticating with different second terminal devices are also different, and the server is generated for the different second terminal device.
  • the second ID is also different. That is to say, when the authentication is performed between any one of the second terminal devices and the server, the shared secret key and the second ID used are unique.
  • the second terminal device performs mutual authentication with the server according to the first shared key and the second ID of the second terminal device.
  • the shared key is only known by the second terminal device and the server, and therefore, the second terminal device can use the shared secret key and the second ID of the second terminal device to authenticate with the server to access the operation. Business network.
  • the terminal device that does not have the credential pre-issued by the operator may be obtained from the server for use with the carrier network by using other trusted device devices.
  • the authenticated shared key is thus able to access the network.
  • the authentication between the second terminal device and the server may also be referred to as authentication between the second terminal device and the carrier network (or the core network, the network, etc.), and the server key may also be referred to as the network side. Public key.
  • Different operators' networks have different IDs, and multiple servers under any one of the carrier networks also have their own IDs or multiple servers can share one ID.
  • Each server is used to provide services to its network operators. For example, to achieve certification related work.
  • the second terminal device can pass the signed first terminal device according to the DH secret when there is no pre-issued credential such as the shared secret key and the ID for identifying the subscribed user.
  • a credential for authentication with the carrier network is obtained from the server.
  • the server Before the first terminal device sends the first message to the server, that is, before execution 104, and/or before the server sends the second message to the first terminal device, the server may also perform all or part of the content in the first message, and/or Or all or part of the content of the second message, a certain process to improve the security of the transmission process.
  • the server may also perform all or part of the content in the first message, and/or Or all or part of the content of the second message, a certain process to improve the security of the transmission process.
  • the method may further include 1401 before the first terminal device sends the first message 104 to the server, at which time 104 may be replaced by 1042.
  • the first terminal device generates a message authentication code (MAC) of the first message according to the second shared key.
  • MAC message authentication code
  • the first terminal device sends the first message and the MAC of the first message to the server.
  • the second shared key is used for authentication between the first terminal device and the server. That is, the second shared key is a shared key (which may also be referred to as a session key) that the first terminal device uses to authenticate with the server.
  • the second shared key is a shared key (which may also be referred to as a session key) that the first terminal device uses to authenticate with the server.
  • the first terminal device may generate a message verification code MAC for the first message according to the second shared key when the first terminal device sends the first message to the server. For example, MAC1 K , if the server verifies the MAC1 K after receiving the first message, the server will trust the first message.
  • 105 can be replaced by 1051, and the method further includes 1052.
  • the server receives a first message sent by the first terminal device, and a message verification code MAC of the first message generated by the first terminal device according to the second shared key as the first message.
  • the server verifies the MAC of the first message according to the second shared key.
  • the server verifies the MAC of the first message according to the second shared key, and if the server passes the MAC verification of the first message, indicating that the first message is from a reliable source point and has not been tampered with, the server accepts The first message can be executed 106.
  • the method further includes 1081 before the server sends the second message to the first terminal device, ie, 108, at which time 108 can be replaced by 1082.
  • the server generates a MAC of the second message for the second message according to the second shared key.
  • the server sends a second message and a MAC of the second message to the first terminal device.
  • the second shared key is used for authentication between the first terminal device and the server.
  • the server may generate a message verification code MAC for the second message according to the second shared key when the server sends the second message to the first terminal device.
  • MAC2 K example, if the first terminal device receives the verification by the MAC2 K, then the server will trust the second message, and continues to send the second message to the second terminal device.
  • 109 can be replaced by 1091, and the method further includes 1092.
  • the first terminal device receives the second message sent by the server, and the MAC of the second message generated by the server according to the second shared key as the second message.
  • the first terminal device verifies the MAC of the second message according to the second shared key.
  • the first terminal device verifies the MAC address of the second message according to the second shared key, and if the first terminal device passes the MAC verification of the second message, indicating that the second message is from a reliable source point and is not After the tampering, the first terminal device accepts the first message and executes 110.
  • the server and the terminal device perform message verification on the message in the process of information interaction, thereby ensuring that the source of the message is reliable and the transmission process is not falsified, thereby improving the security of the key exchange process.
  • the method may further include 1083 before the server sends a second message to the first terminal device, ie, 108, at which point 108 may be replaced by 1084.
  • the server signs the second message.
  • the server sends a second message to the first terminal device, a signature message obtained by the server after signing the second message, and a verification message corresponding to the signature message.
  • the server signs the second message with its own private key, and sends a second message to the first terminal device, and the signature obtained by the server after signing the second message.
  • the message, and the verification message corresponding to the signature message can not initiate a man-in-the-middle attack even if the first terminal device is compromised or controlled.
  • mode one and mode two can be performed simultaneously, that is, the server can simultaneously sign the second message and generate a message verification code for the second message, but in order to save signaling, if mode 2 is performed, then mode one is also Can no longer be executed.
  • 109 to 111 may be replaced by 1111 to 1113, and the method may further include 1114.
  • the first terminal device receives a second message sent by the server, a signature message obtained by the server after signing the second message, and verification information corresponding to the signature message.
  • the first terminal device sends a second message, the signature message, and the verification information to the second terminal device.
  • the second terminal device receives a second message sent by the first terminal device, a signature message obtained by the server after signing the second message, and verification information corresponding to the signature message.
  • the second terminal device verifies the second message according to the second message, the signature message, and the verification information.
  • the second terminal device verifies the second message according to the second message, the signature message, and the verification information. If the second terminal device verifies that the second message passes, indicating that the authenticity of the second message originates from the server and the content of the second information is complete, the second terminal device accepts the second message and performs 112.
  • the verification information may include a certificate of the server or an ID of the server.
  • the verification information may be a certificate of the server, that is, a certificate corresponding to a private key used by the server to encrypt the second message, so that the second terminal device can The signature is verified according to the certificate; if the server adopts an identity-based key system, the verification information may be an ID of the server, so that the second terminal device can verify the signature according to the ID of the server.
  • the server may adopt an asymmetric key system (for example, a certificate-based crypto mechanism or an identity-based crypto mechanism), a DH public key of the server to be sent, and a second-party generated for the terminal device to identify the subscriber.
  • the identity is signed, thereby improving the security of the key exchange process, and it is impossible to initiate a man-in-the-middle attack even if the terminal device is compromised.
  • the method may further include 1403 before the first terminal device sends the first message 104 to the server.
  • the first terminal device encrypts the DH public key of the second terminal device and the first ID of the second terminal device according to the second shared key.
  • the second shared key is used for authentication between the first terminal device and the server. That is, the second shared key is a shared key used by the first terminal device to authenticate with the server.
  • the DH public key of the second terminal device and the first ID of the second terminal device in the first message sent by the first terminal device to the server in 104 are encrypted by the first terminal device with the second shared key.
  • the first ID of the second terminal device and the first ID of the second terminal device in the first message received by the server from the first terminal device are encrypted by the first terminal device.
  • the method further includes 1061, and 106 can be replaced by 1062.
  • the server decrypts the encrypted DH public key of each second terminal device and the first ID of each second terminal device according to the second shared key.
  • the server determines, according to the decrypted second DH public key of the second terminal device, and the DH public key of the server, the first shared key of the second terminal device that is used for authentication with the second terminal device, and is the second terminal.
  • the device generates a second ID of the second terminal device.
  • the method may further include 1081 before the server sends the second message 108 to the first terminal device.
  • the server encrypts the DH public key of the second terminal device and the second ID of the second terminal device according to the second shared key.
  • the second shared key is used for authentication between the first terminal device and the server.
  • the DH public key of the second terminal device and the second ID of the second terminal device in the first message sent by the server to the first terminal device in 108 are encrypted by the server using the second shared key, and The second ID of the second terminal device in the second message received by the first terminal device from the server in 109, and the DH public key of the server are encrypted by the server.
  • the method further includes 1101, and 110 may have 1102 replacement.
  • the first terminal device decrypts the encrypted second ID of the second terminal device and the DH public key of the server according to the second shared key.
  • the first terminal device sends the decrypted second ID of the second terminal device and the DH public key of the server to the second terminal device.
  • the security of the key exchange process of the server and the terminal device is improved by encrypting the message.
  • a second terminal device that does not have a credential pre-issued by the operator network, after obtaining the credential for accessing the operator network according to the authentication method of the mobile network, in order to ensure the first shared key determined by the server
  • the first shared key determined by the second terminal device is consistent, and the first shared key may be verified between the second terminal device and the server.
  • the process interaction diagram for verifying the shared key in the embodiment of the present application may further include 114 to 118 before 113.
  • the second terminal device generates a message verification code MAC for the second ID of the second terminal device according to the first shared key.
  • the second terminal device sends the second ID and the MAC of the second ID to the server.
  • the server receives the second ID and the MAC of the second ID, and verifies the MAC of the second ID of the second terminal device according to the first shared key. If the verification is successful, execute 117.
  • the server sends a configuration completion message to the second terminal device, and a MAC of the configuration completion message generated by the server for the configuration completion message.
  • the second terminal device receives the configuration completion message sent by the server and the MAC of the configuration completion message, and verifies the MAC of the configuration completion message according to the first shared key. If the verification is successful, you can execute 113.
  • FIG. 10 is a method for authenticating a mobile network according to an embodiment of the present application
  • FIG. 10 shows a process for a second terminal device to obtain an operator's credential through the first terminal device.
  • the method includes:
  • the first terminal device uses its 3GPP Credential to perform mutual authentication with the carrier network, for example, based on the AKA (Authentication and Key Agreement) protocol.
  • the embodiment of the present application does not limit the authentication mode, for example, the Companion UE further
  • the mutual authentication can be performed with the carrier network through the authentication method in the future 5G network, and the session key K is generated.
  • the second terminal device such as an Internet of Things device (IoT Device)
  • IoT Device generates a random number such as RAND 1
  • the generators of group G, g and p may be published in advance or in plain text.
  • the IoT Device establishes a secure channel with the Companion UE, and sends its own ID (Device ID) and the generated DH public key (A) to the Companion UE in the secure channel.
  • the format of the sent message is, for example, (Device ID, A). .
  • the Companion UE After receiving the message, the Companion UE adds a flag bit (PType), which is used to indicate that the message is used to request the IoT Device for 3GPP Credential.
  • PType can be represented by a specific value (for example, 1) as a single device request.
  • Companion UE using the key K is then generated for the entire message a message authentication code MAC1 K, then sends a message to the server (Provision Server), which sends a message format (Ptype, Device ID, A, MAC1 K).
  • This server can be an HSS.
  • Access ID Access Identity
  • the message received by the Provision Server is an encrypted message (Ptype, m1, MAC1 K ), then it needs to be decrypted according to K to obtain the Device ID and A.
  • Provision Server sends a message to the Companion UE, the message format, for example (Access ID, B, A, MAC2 K), wherein, Access ID for operators to IoT Device generated access operator ID, or is the operator identification The ID of the signing user.
  • B is its DH public key
  • A is the DH public key of the IoT Device returned by it
  • MAC2 K uses the key K to generate a message verification code for the entire message.
  • Provision Server can also sign the message, then, Provision Server Companion UE transmits the message to the message format, for example (Access ID, B, A, MAC2 K, Sig CN), where its use Sig CN Its private key signs the message.
  • the Provision Server may also encrypt the message sent to the Companion UE.
  • the Companion UE verifies the MAC2 K .
  • the Companion UE If the message received by the Companion UE is the encrypted message (m2, MAC2 K ), the Companion UE also needs to decrypt it according to K to obtain the Access ID, B and A.
  • Companion UE verified the MAC2 K, the DH public key B Access ID and is transmitted to the network side in the IoT Device secure channel, which, for example, the message format (Access ID, B).
  • the Companion UE also sends the signature and the verification information corresponding to the signature (such as the certificate of the server or the ID of the server) to the IoT Device.
  • the shared secret key K D can be generated from the server's DH public key B.
  • the IoT Device sends the Access ID to the Provision Server, and uses the key K D to generate a message verification code MAC3 KD for the entire message.
  • the message format is, for example, (Access ID, MAC3 KD ).
  • the Provision Server After the Provision Server receives this message, it verifies the MAC3 KD .
  • the Provision Server sends a configuration complete message (Provision Complete) to the IoT device, and uses the shared key K D to generate a message verification code MAC4K D for the entire message.
  • the message format is, for example, (configuration completed, MAC4) KD ) (Provision Complete, MAC4 KD ).
  • the IoT Device After receiving the message, the IoT Device verifies the MAC4 KD . After the verification is passed, the entire process ends.
  • the main purpose of the method is to verify whether the key generated by the IoT Device is consistent with the key generated by the server. After confirming that the key K D is consistent, the IoT Device can use the shared key K D . Authenticate with the carrier network to access the network.
  • the first terminal device uses its 3GPP Credential to perform mutual authentication with the carrier network, for example, the authentication is performed based on the AKA (Authentication and Key Agreement) protocol.
  • AKA Authentication and Key Agreement
  • the embodiment of the present application does not limit the authentication mode, for example, the Companion UE further
  • the mutual authentication can be performed with the carrier network through the authentication method in the future 5G network, and the session key K is generated.
  • IoT Devices respectively generates a random number and uses the random number to generate its DH public key, wherein:
  • IoT Device 2 Internet of Things Device 2
  • IoT Devices sends its own ID, generated DH public key, to the Companion UE in a secure channel, where:
  • the message sent by IoT Device 1 is (Device ID1, A1), where Device ID1 is the ID of IoT Device 1, and A1 is its DH public key;
  • the message sent by IoT Device 2 is (Device ID2, A2), where Device ID2 is the ID of IoT Device 2, and A2 is its DH public key.
  • the Companion UE After receiving the message, the Companion UE adds a flag bit PType, which is used to indicate that the purpose of the message is to request the IoT Device for 3GPP Credential.
  • PType can be represented by a specific value (for example, 0) for multiple device requests.
  • Companion UE using the key K is then generated for the entire message a message authentication code MAC1 K, and then send a message to Provision Server, which sends a message format, for example (Ptype, Device ID1, Device ID2 , A1, A2, MAC1 K).
  • the Companion UE may also encrypt the message sent to the Provision Server, and the message sent by the Companion UE to the Provision Server is, for example, (Ptype, m1, MAC1 K ), where m1 is encrypted with the key K.
  • Ptype, m1, MAC1 K the message sent by the Companion UE to the Provision Server is, for example, (Ptype, m1, MAC1 K ), where m1 is encrypted with the key K.
  • the following Device ID and A ciphertext, ie m1 En (Device ID 1, Device ID 2, A1, A2, K).
  • the message received by the Provision Server is an encrypted message (Ptype, m1, MAC1 K ), then it needs to be decrypted according to K to obtain Device ID 1, Device ID 2, A1 and A2.
  • the Provision Server sends a message to the Companion UE, for example, (Access ID 1, Access ID 2, B, A1, A2, MAC2 K ), wherein the Access ID 1 and the Access ID 2 are the IoT Device 1 and the IoT Device respectively.
  • 2 Generated ID for identifying the subscriber
  • B is its DH public key
  • A1 and A2 are the DH public keys of IoT Device 1 and IoT Device 2 respectively
  • MAC2 K uses the key K as the whole message.
  • Generate a message verification code for example, (Access ID 1, Access ID 2, B, A1, A2, MAC2 K ), wherein the Access ID 1 and the Access ID 2 are the IoT Device 1 and the IoT Device respectively.
  • 2 Generated ID for identifying the subscriber
  • B is its DH public key
  • A1 and A2 are the DH public keys of IoT Device 1 and IoT Device 2 respectively
  • MAC2 K uses the key K as the whole message.
  • the Provision Server may also sign the message.
  • the message sent by the HSS/Provision Server to the Companion UE is, for example, (Access ID 1, B, A1, Sig1 CN , Access ID 2, B, A2, Sig2 CN , MAC2 K ), where Sig1 CN is the signature of (Access ID1, B, A1), and Sig2 CN is the signature of (Access ID2, B, A2).
  • the Provision Server may further encrypt the message sent to the Companion UE, for example, the message format is (m2, MAC2 K ), where m2 is the Access ID 1 and Access ID 2 encrypted by the key K.
  • the ciphertext of A1 and A2, that is, m2 En (Access ID 1, Access ID 2, B, A1, A2, K).
  • the Companion UE needs to decrypt it according to K to obtain Access ID 1, Access ID 2, B, A1, and A2.
  • DH will send a public key B Access ID and the network side, respectively, in a secure channel to the corresponding IoT Device, are transmitted to the IoT Device IoT Device 1 and 2, for example, message:
  • the Companion UE also sends the signature and the verification information corresponding to the signature (such as the certificate of the server or the ID of the server) to the IoT Device, for example, 1109(a) IoT Device 1 sends (Access ID 1, B, A1, Sig1 CN ), and 1109(b) sends it to IoT Device 2 (Access ID 2, B, A2, Sig2 CN ).
  • the IoT Device After receiving the message, the IoT Device generates a shared key by using the received DH public key on the network side, where:
  • IoT Device1 and IoT Device 2 respectively receive the signature of the server for the message and the authentication information format corresponding to the signature, for example, (Access ID 1, B, A1, Sig1 CN ) and (Access ID 2, B, A2, Sig2 CN ), then the IoT Device1 and the IoT Device 2 need to verify the signatures Sig1 CN and Sig2 CN respectively according to the verification information.
  • the shared key K D1 and the shared key K D1 can be generated respectively according to the DH public key B of the server. K D2 .
  • the IoT Device sends the Access ID to the HSS/Provision Server, and uses its key to generate a message verification code for the entire message.
  • the messages sent by IoT Device 1 and IoT Device 2 are respectively:
  • IoT Device 1 sends (Access ID 1, MAC3 KD1 ) to Provision Server;
  • IoT Device 2 sends (Access ID 2, MAC4 KD2 ) to Provision Server.
  • the Provision Server verifies the MAC3 KD1 and the MAC4 KD2 .
  • the Provision Server After verifying the message verification code, the Provision Server sends a Provision Complete message to the IoT device, and uses the key to generate a message verification code for the entire message.
  • the message sent to the IoT Device 1 and the IoT Device 2 is respectively:
  • the IoT Device After receiving the message, the IoT Device verifies the message verification code, and after the verification is passed, the entire process ends, where:
  • IoT Device 1 verifies MAC5 KD1 .
  • IoT Device 2 verifies MAC6 KD2 .
  • 1110 to 1113 are optional, and the main purpose is to verify whether the key generated by IoT Device 1 and IoT Device 2 is consistent with the key generated by the server. After confirming that the key K D is consistent, IoT Device 1 and IoT Device 2 can authenticate with the carrier network using its shared keys K D1 and K D2 to access the network.
  • the second terminal device obtains the trust of the operator from the server by using the first terminal device, and is based on the first terminal device being successfully authenticated with the server, that is, the first terminal device is already held. A device that shares a secret key with a network session. Considering another situation, if the first terminal device has not authenticated with the server at this time, how should the second terminal device obtain the operator's credential from the server through the first terminal device.
  • the second terminal device in the process of performing authentication by the first terminal device in the server, the second terminal device is provided with the possibility of obtaining the network operator's trust. That is, the second terminal device can be in the first terminal device and the service In the process of authenticating the server, obtain the trust of the operator.
  • FIG. 12 is a schematic flow chart of an AKA-based authentication method in the prior art.
  • the UE, the Mobility Management Entity (MME), and the HSS are taken as an example.
  • the method includes:
  • the UE sends an access request message to the MME.
  • the MME obtains an authentication vector (or authentication data) from the HSS according to the access request message, where the authentication vector includes a random number (Random Number, RAND), an expected response (Expeded Response, XRES), and an authentication token (Authentication Token). , AUTN), the authentication vector can also be called an authentication vector.
  • RAND Random Number
  • XRES Expected Response
  • AUTN authentication token
  • the MME sends the RAND and the AUTN in the foregoing authentication vector to the UE, and reserves the XRES, and waits for the response (Response, RES) of the UE.
  • RES Response
  • the MME considers the UE authentication. success;
  • the UE authenticates the network based on the received RAND and AUTN.
  • the UE verifies the AUTN based on the shared key K pre-issued by the network, and the UE calculates an Anonymity Key (AK) through RAND and K, and then uses AK to recover the sequence number (SQN) and verify. Whether the SQN is legal. Then, an eXpected Message Authentication Code (XMAC) is calculated by using the obtained Authentication Management Field (AMF) in the legal SQN, RAND, and ISIM, if the XMAC is obtained from the AUTN by the HSS. If the calculated message authentication code MAC is consistent, the verification succeeds and the authentication data is sent from the home network.
  • AK Anonymity Key
  • SQN sequence number
  • XMAC eXpected Message Authentication Code
  • the UE After the UE successfully authenticates the network, the UE calculates a response (Response, RES) through RAND and Key0, and sends the RES to the MME.
  • RES Response
  • the MME verifies the received RES and the expected response (eXpected RES, XRES) saved by itself. If the two parameters are consistent, the authentication of the terminal is considered successful.
  • the network authentication entity may be a Mobility Management Entity (MME), and the server may be a Home Subscriber Server (HSS).
  • MME Mobility Management Entity
  • HSS Home Subscriber Server
  • the MME and the HSS are only one example of the network authentication entity and the server.
  • the application does not exclude other core network elements having the same or similar functions defined in the future 5G for performing the authentication method in the embodiment of the present application.
  • FIG. 13 is a flow diagram of a process of an authentication method of a mobile network according to an embodiment of the present application.
  • a first terminal device, a second terminal device, a network authentication entity, and a server are shown in FIG. Taking a second terminal device as an example, as shown in FIG. 13, the method includes:
  • the second terminal device determines a DH public key of the second terminal device.
  • the second terminal device is a device that does not hold a shared key. That is to say, the second terminal device does not have the trust certificate issued by the operator in advance, and cannot be authenticated between the servers to access the carrier network.
  • the first terminal device, the second terminal device and the server may obtain the shared key by using Dieffi Herman key negotiation. That is, the shared key for network authentication is negotiated with the server according to the DH key exchange method by using the condition that the first terminal device has the operator's credential.
  • the second terminal device sends the DH public key and the first ID of the second terminal device to the first terminal device.
  • the format of the message sent by the second terminal device to the first terminal device may be (Device ID, A), where Device ID is the first ID of the second terminal device, and A is the random number generated by the second terminal device according to itself.
  • the second terminal device may establish a secure channel with the first terminal device, such as a Bluetooth pairing technology, an encrypted access control technology of a WiFi local area network, or a short-distance communication method such as a wired network to establish a secure channel, and set its own in the secure channel.
  • a secure channel such as a Bluetooth pairing technology, an encrypted access control technology of a WiFi local area network, or a short-distance communication method such as a wired network to establish a secure channel, and set its own in the secure channel.
  • An ID and the generated public key are sent to the first terminal device.
  • the first terminal device receives the DH public key and the first ID of the second terminal device that are sent by the second terminal device.
  • the format of the received message sent by the first terminal device to the second terminal device is, for example, (Device ID, A). Further, the first terminal device may receive, in the secure channel, the DH public key of the second terminal device and the first ID of the second terminal device that are sent by the second terminal device.
  • the first terminal device sends an attach request message, or an authentication request message, to the network authentication entity.
  • the attach request message includes a first message and an identity ID of the first terminal device, where the first message includes a DH public key of the second terminal device and a first ID of the second terminal device.
  • the first message further includes indication information, where the indication information is used to indicate that the first message is used to request, for the second terminal device, the shared key of the second terminal device and the second ID of the second terminal device.
  • the ID of the first terminal device is the ID of the first terminal device that is used by the server to identify the subscriber. For example, it may be the IMSI number of the first terminal device.
  • the indication information is used to indicate that the first message is used to request the second terminal device device for a credential for authentication between the second terminal device and the server, for example, the credential may include the second terminal.
  • the second ID may be, for example, an IMSI.
  • the indication information may be, for example, a flag bit, which may indicate whether the second terminal device requests the certificate issued by the operator for a second terminal device or the trust certificate issued by the operator for the plurality of second terminal devices.
  • the first terminal device may add the first message sent to the network authentication entity. Instructions.
  • the message format of the first terminal device to initiate an authentication request to the network authentication entity, such as the MME, is, for example, (Ptype, IMSI, Device ID, A), where PType is a flag bit, which is used to indicate that the purpose of the message is to give the IoT Device requests 3GPP Credential.
  • the network authentication entity receives an attach request message sent by the first terminal device.
  • the format of the attach request message sent by the network authentication entity to the first terminal device is, for example, (Ptype, IMSI, Device ID, A).
  • the network authentication entity sends an authentication data request message (Authentication Data Request) to the server.
  • Authentication Data Request an authentication data request message
  • the attach request message includes a first message and an identity ID of the first terminal device, where the first message includes a DH public key of the second terminal device and a first ID of the second terminal device.
  • the format of the authentication data request message sent by the network authentication entity to the server for example (Ptype, IMSI, SN ID, Network Type, Device ID, A), where SN ID is the ID of the service network, and Network Type is the network type.
  • the server receives an authentication data request message sent by a network authentication entity.
  • the format of the authentication data request message sent by the network authentication entity received by the server is, for example, (Ptype, IMSI, SN ID, Network Type, Device ID, A).
  • the server determines a DH public key of the server according to the second random number, and generates a second ID of the second terminal device for the second terminal device, and determines the first shared key.
  • the server may generate a second random number, and determine a DH public key of the server according to the second random number, so that the second random number and the received DH public key of the second terminal device may be generated. And a first shared secret key of the second terminal device that authenticates with the second terminal device. And, the server can transfer the self-public key to the second terminal device, so that the second terminal device can determine the same number for authenticating with the server according to the DH public key of the server and the DH public key of the second terminal device. A shared secret key.
  • the server determines an authentication vector based on the authentication data request message.
  • the server can generate another random number such as RAND 3, and at the same time determine an authentication vector (Auth.Vector), which includes authentication related authentication data.
  • Auth.Vector an authentication vector
  • the server sends an authentication data response message to the network authentication entity.
  • the authentication data response message includes the second message and the authentication vector, and the second message includes a DH public key of the server and a second ID of the second terminal device generated by the server for the second terminal device.
  • the format in which the server sends the authentication data response message to the network authentication entity is, for example, (EPS Auth.Vector, Access ID, B, A).
  • the network authentication entity receives the authentication data response message sent by the server.
  • the format of the authentication data response message sent by the server received by the network authentication entity is, for example, (EPS Auth.Vector, Access ID, B, A).
  • the network authentication entity sends a user authentication request message to the first terminal device.
  • the user authentication request message includes the second message and the authentication data in the authentication vector.
  • the network authentication entity sends a format of the user authentication request message to the first terminal device, for example, (RAND 3, AUTN HSS , Access ID, B, A), where the AUTN HSS is an Authentication Token.
  • the first terminal device receives a user authentication request message sent by the network authentication entity.
  • the first terminal device sends the second ID of the second terminal device and the DH public key of the server to the second terminal device.
  • the first terminal device After receiving the user authentication request message sent by the network authentication entity, the first terminal device sends the second ID of the second terminal device and the DH public key of the server in the second message in the user authentication request message to the second terminal device.
  • the format of the second message is, for example, (Access ID, B).
  • the second terminal device receives the second ID of the second terminal device and the DH public key of the server that are sent by the first terminal device.
  • the second terminal device determines the first shared key according to the first random number of the second terminal device and the DH public key of the server.
  • the second terminal device may be based on the DH public key of the server in the first message, and the second terminal device.
  • the first random number used when generating the own DH public key determines the first shared secret key of the second terminal device used for authentication with the server.
  • the second terminal device g RAND 2 mod p
  • determines the shared key used for authentication with the server, ie K D B RAND 1 mod p.
  • the shared key is only known by the second terminal device and the server. Therefore, the second terminal device can use the shared key and the second ID of the second terminal device to perform authentication and access with the server. Operator network.
  • the second terminal device can use the shared key K D to authenticate with the server on the condition that the first terminal device and the server are successfully authenticated, and can perform the authentication on the first terminal in the network authentication entity. During the device authentication process, the obtained first shared secret key is verified.
  • the process interaction diagram of the authentication method of the mobile network in the embodiment of the present application may further include 316 to 325.
  • the second terminal device is a MAC generated by the second ID of the second terminal device.
  • the second terminal device may initiate an authentication process for the first shared key to ensure that the first shared secret key determined by the server is consistent with the shared key determined by the server. .
  • the second terminal device can generate a message verification code MAC for the second ID using the first shared key K D .
  • the second terminal device sends, to the first terminal device, a second ID of the second terminal device and a MAC of the second ID.
  • the message format of the MAC of the second ID and the second ID sent by the second terminal device to the first terminal device is, for example, (Access ID, MAC).
  • the first terminal device receives the second ID of the second terminal device sent by the second terminal device and the MAC generated for the second terminal, and sends a user authentication response message to the network authentication entity according to the user authentication request message. ).
  • the first terminal device After receiving the second ID of the second terminal device and the MAC address generated by the second terminal, the first terminal device sends a user authentication response message to the network authentication entity, where the format of the user authentication response message is, for example, (Access ID, MAC, RES.).
  • the network authentication entity receives the user authentication response message sent by the first terminal device, and determines, according to the authentication response message, whether the authentication is successful.
  • the format of the user authentication response message sent by the network authentication entity to the first terminal device is, for example, (Access ID, MAC, RES.), after which the network authentication entity compares whether RES and XRES are equal. If they are equal, the network authentication entity completes the authentication of the first terminal device, generates an authentication success message (Auth.Success), and executes 320.
  • the network authentication entity sends, to the server, a second ID of the second terminal device and a MAC of the second ID of the second terminal device.
  • the second ID of the second terminal device and the MAC address of the second ID of the second terminal device are sent to the server, and the message format is, for example, (Access ID, MAC).
  • the server authenticates the MAC of the second ID of the second terminal device according to the first shared key.
  • the server may authenticate the MAC address of the second ID according to the first shared secret key.
  • the format of the message received by the server is, for example, (Access ID, MAC), and then the MAC can be verified according to the first shared key K D . If the server passes the MAC verification of the second ID of the second terminal device, perform 320.
  • the server sends a configuration complete message (Provision Complete) to the network authentication entity.
  • the network authentication entity receives the configuration completion message sent by the server, and sends a configuration completion message and a 318-based authentication success message to the first terminal device.
  • the network authentication entity After receiving the configuration completion message, the network authentication entity sends the configuration completion message together with the authentication success message generated in the 318 to the second terminal device, and the format of the message sent by the network authentication entity to the first terminal device is, for example, (Provision Complete, Auth.Success).
  • the first terminal device receives a configuration completion message and an authentication success message sent by the network authentication entity, and sends a configuration completion message to the second terminal device.
  • the first terminal device After receiving the configuration completion message and the authentication success message, the first terminal device determines that the first terminal device is successfully authenticated according to the authentication success message, and sends a configuration completion message to the second terminal device, and the first terminal device receives the message from the network authentication entity.
  • the format is, for example, (Provision Complete, Auth. Success), and the entire process ends after the Provision Complete is sent to the second terminal device.
  • the second terminal device performs authentication with the operator network according to the first shared secret key and the second ID of the second terminal device.
  • the authentication method of the mobile network in the embodiment of the present application the terminal device that does not hold the operator and the pre-issued credential can be obtained from the server by the first terminal device in the process of authenticating the first terminal device and the server.
  • the size of the sequence number of each process does not mean the order of execution sequence, and the execution order of each process should be determined by its function and internal logic, and should not be taken by the embodiment of the present application.
  • the implementation process constitutes any qualification.
  • the authentication method of the mobile network according to the embodiment of the present application has been described in detail above with reference to FIGS. 7 to 14.
  • a terminal device, a service, and a network authentication entity according to an embodiment of the present application will be described in detail with reference to FIGS. 15 through 26.
  • the network device and the terminal device in the embodiments of the present application may perform various methods in the foregoing embodiments of the present application, that is, For the specific working process of the following various devices, reference may be made to the corresponding process in the foregoing method embodiments.
  • FIG. 15 shows a schematic block diagram of a terminal device 1500 according to an embodiment of the present application.
  • the terminal device 1500 is the first terminal device in the foregoing method embodiment of FIG. 7 to FIG. 11 , where the first terminal device is a device that has a shared key, and the first terminal device 1500 is configured.
  • a receiving module 1501 and a transmitting module 1502 are included.
  • the receiving module 1501 is configured to receive a Dieffie Herman DH public key and a first identity ID sent by the at least one second terminal device, where the at least one second terminal device is a device that does not hold the shared key;
  • the sending module 1502 is configured to send a first message to the server, where the first message includes a DH public key of each second terminal device of the at least one second terminal device, and a second of each of the second terminal devices An ID;
  • the receiving module 1501 is further configured to receive a second message that is sent by the server based on the first message, where the second message includes a DH public key of the server, and the server is the second one of the second a second ID of each of the second terminal devices generated by the terminal device, where the second ID is used to identify the subscriber;
  • the sending module 1502 is further configured to send, to each of the second terminal devices, the second ID of each second terminal device and the DH public key of the server, so that each of the second terminal devices Determining, according to the second ID of each second terminal device and the DH public key of the server, a first shared key and each of the each second terminal device for authenticating with the server The second ID of the second terminal device.
  • the first message further includes indication information, where the indication information is used to indicate that the first message is used to request, for each of the second terminal devices, a shared key of each of the second terminal devices. And the second ID of each of the second terminal devices.
  • the first terminal device before the first terminal device sends the first message to the server, the first terminal device further includes:
  • a generating module configured to generate, according to the second shared key, a message verification code MAC of the first message, where the second shared key is used by the first terminal device and the server Between certifications;
  • the sending module 1502 is specifically configured to: send the first message and the MAC of the first message to the server.
  • the receiving module 1501 is specifically configured to: receive the second message sent by the server, and the MAC of the second message that is generated by the server according to the second shared key as the second message. ;
  • the sending module 1502 is specifically configured to: the first terminal device verifies the MAC of the second message according to the second shared key; if the first terminal device sends the MAC of the second message After the verification is passed, the first terminal device sends the second ID of each second terminal device and the DH public key of the server to each of the second terminal devices.
  • the receiving module 1501 is specifically configured to: receive the second message sent by the server, perform, by the server, the second ID of each second terminal device, and the DH public key of the server. a signature message of each of the second terminal devices obtained after the signature, and verification information of each of the second terminal devices corresponding to the signature message of each of the second terminal devices;
  • the sending module 1502 is specifically configured to: send, to each of the second terminal devices, the second ID of each second terminal device and the DH public key of the server, and each of the second terminal devices The signature message and the verification information of each of the second terminal devices.
  • the verification message includes a certificate of the server or an ID of the server.
  • the terminal device before the sending module 1502 sends the first message to the server, the terminal device further includes:
  • An encryption module configured to encrypt, according to the second shared key, the DH public key of each second terminal device and the first ID of each of the second terminal devices;
  • the DH public key of each of the second terminal devices and the first ID of each of the second terminal devices in the first message sent by the sending module 1502 to the server are after the The first terminal device is encrypted.
  • the second ID of each of the second terminal devices and the DH public key of the server in the second message received by the receiving module 1501 from the server are encrypted by the server.
  • the terminal device further includes: before the sending module 1502 sends the second ID of each second terminal device and the DH public key of the server to each of the second terminal devices, the terminal device further includes:
  • a decrypting module configured to decrypt the encrypted second ID of each second terminal device and the DH public key of the server according to the second shared key
  • the sending module 1502 is specifically configured to: send, to each of the second terminal devices, the decrypted second ID of each second terminal device and the DH public key of the server.
  • the server comprises a home subscriber server HSS.
  • the terminal device 1500 may correspond to the first terminal device in the authentication method according to the embodiment of the present application in FIGS. 7 to 11, and each module in the terminal device 1500 and the other operations described above and/or For the sake of brevity, the functions of the respective methods in FIG. 7 to FIG. 11 are not described here.
  • the terminal device in the embodiment of the present application can establish a channel for key negotiation with the server for the terminal device that does not hold the certificate pre-issued by the operator based on the trust of the operator that the operator has already held.
  • a terminal device that does not have a credential pre-issued by the operator can also acquire a shared key for authentication with the operator network from the server to be able to access the network.
  • FIG. 16 shows a schematic block diagram of a terminal device 1600 of an embodiment of the present application.
  • the terminal device 1600 is the second terminal device in the foregoing method embodiment of FIG. 7 to FIG. 11, the second terminal device is a device that does not hold a shared key, and the second terminal device 1600 is A determination module 1601, a sending module 1602, a receiving module 1603, and an authentication module 1604 are included.
  • a determining module 1601 configured to determine a Dieffi Herman DH public key of the second terminal device according to the first random number
  • the sending module 1602 is configured to send the first message to the first terminal device, where the first message includes a DH public key of the second terminal device and a first identity identifier of the second terminal device, where The first terminal device is a device that already holds a shared key;
  • the receiving module 1603 is configured to receive a second message that is sent by the first terminal device according to the first message, where the second message includes a DH public key of the server, and the server generates the second terminal device a second ID, where the second ID is used to identify a subscriber;
  • the determining module 1601 is further configured to determine, according to the first random number, a DH public key of the server, a first shared key;
  • the authentication module 1604 is configured to perform mutual authentication with the server according to the first shared key and the second ID.
  • the receiving module 1603 is specifically configured to: receive the second message sent by the first terminal device, a signature message obtained by the server after signing the second message, and the signature message Corresponding verification information;
  • the determining module 1601 is specifically configured to: verify, according to the second message, the signature message, and the verification information, the second message; if the second message is verified, the second terminal The device determines the first shared key according to the first random number and a DH public key of the server.
  • the verification message includes a certificate of the server or an ID of the server.
  • the terminal device further includes a generating module and a verification module, where the generating module is configured to: generate, according to the first shared key, a message verification code MAC of the second ID for the second ID;
  • the sending module 1602 is further configured to send, to the server, the MAC of the second ID and the second ID;
  • the receiving module 1603 is further configured to receive a configuration completion message sent by the server based on the MAC of the second ID and the second ID, and the configuration completion message generated by the server for the configuration completion message MAC;
  • the verification module is configured to verify, according to the first shared key, the MAC of the configuration completion message
  • the authentication module 1604 is specifically configured to: if the verification module passes the MAC verification of the configuration completion message, the second terminal device according to the first shared key and the second ID, The server performs mutual authentication.
  • the terminal device 1600 may correspond to the second terminal device in the authentication method according to the embodiment of the present application in FIGS. 7 to 11, and each module in the terminal device 1600 and the other operations described above and/or For the sake of brevity, the functions of the respective methods in FIG. 7 to FIG. 11 are not described here.
  • the terminal device that does not have the credential pre-issued by the operator may be obtained from the server for use with the carrier network by using other trusted device devices.
  • the authenticated shared key is thus able to access the network.
  • FIG. 17 shows a schematic block diagram of a server 1700 of an embodiment of the present application.
  • the server 1700 is the server in the method embodiment of the above-described FIGS. 7 to 11.
  • the server 1700 includes a receiving module 1701, a determining module 1702, and a transmitting module 1703.
  • the receiving module 1701 is configured to receive the first message sent by the first terminal device, where the first message includes that the first terminal device receives from each second terminal device of the at least one second terminal device a DH public key of each of the second terminal devices and a first ID of each of the second terminal devices, where the first terminal device is a device that has a shared key, and the at least one second terminal device a device that does not hold a shared key;
  • a determining module 1702 configured to determine a DH public key of the server according to the second random number, and generate a second ID of each second terminal device for each second terminal device, where the second ID is used by For identifying the signing user;
  • the determining module 1702 is further configured to: determine, according to the DH public key of each second terminal device and the second random number, each of the foregoing for performing authentication with each of the second terminal devices a first shared key of the second terminal device;
  • the sending module 1703 is configured to send a second message to the first terminal device, where the second message includes a DH public key of the server and a second ID of each second terminal device.
  • the first message further includes indication information, where the indication information is used to indicate that the first message is used to request, for each of the second terminal devices, a shared key of the second terminal device and The second ID of the second terminal device.
  • the receiving module 1701 is specifically configured to: receive the first message sent by the first terminal device, and generate, by the first terminal device, the first message according to the second shared key. a message verification code MAC of the first message, where the second shared key is used for authentication between the first terminal device and the server;
  • the determining module 1702 is specifically configured to: verify, according to the second shared key, the MAC of the first message; if the MAC verification of the first message passes, according to the second random number and the server DH
  • the public key determines a first shared key for each second terminal device that is authenticated with each of the second terminal devices.
  • the server before the sending module 1703 sends the second message to the first terminal device, the server further includes: a generating module, configured to generate, according to the second shared key, the second message MAC of the second message;
  • the sending module 1703 is specifically configured to: send, to the first terminal device, the MAC of the second message and the second message.
  • the server before the sending module 1703 sends the second message to the first terminal device, the server further includes:
  • a signing module configured to sign a second ID of each of the second terminal devices and a DH public key of the server
  • the sending module 1703 is specifically configured to: send the second message to the first terminal device, and the server performs the second ID of each second terminal device and the DH public key of the server. After the signature, the signature message of each of the second terminal devices and the verification message of each of the second terminal devices corresponding to the signature message of each of the second terminal devices are obtained.
  • the verification message includes a certificate of the server or an ID of the server.
  • the DH public key of each of the second terminal devices in the first message received by the receiving module 1701 from the first terminal device, and the first of each second terminal device The ID is encrypted by the first terminal device;
  • the determining module 1702 determines, according to the DH public key of each second terminal device, and the second random number, each second terminal used for performing authentication with each of the second terminal devices.
  • the server further includes: a decrypting module, configured to, according to the second shared key, the encrypted DH public key of each of the second terminal devices and each of the second Decryption of the first ID of the terminal device;
  • the determining module 1702 is specifically configured to: determine, according to the decrypted DH public key of each second terminal device, and the second random number, for performing authentication with each of the second terminal devices The first shared key of each second terminal device.
  • the server before the sending module 1703 sends the second message to the first terminal device, the server further includes: an encryption module, configured to: perform DH public key on the server according to the second shared key The second ID of each second terminal device is encrypted;
  • the DH public key of the server and the second ID of each second terminal device in the second message sent by the sending module 1703 to the first terminal device are encrypted by the server. of.
  • the server further includes a verification module, where the receiving module 1701 is further configured to: receive the second ID of each of the second terminal devices that is sent by each of the second terminal devices, and a message authentication code MAC generated by each second terminal device for the second ID of each of the second terminal devices;
  • the verification module is configured to verify, according to the first shared key, a MAC of a second ID of each second terminal device;
  • the sending module 1703 is further configured to: if the verification module successfully performs MAC verification on the second ID of each second terminal device, send a configuration completion message to each of the second terminal devices, and the server The MAC of the configuration completion message generated for the configuration completion message.
  • the server 1700 may correspond to a server in the authentication method according to the embodiment of the present application in FIGS. 7 to 11, and each module in the server 1700 and the other operations and/or functions described above are respectively implemented
  • the corresponding processes of the methods in FIG. 7 to FIG. 11 are not described herein again for the sake of brevity.
  • the server of the embodiment of the present application can provide the terminal device that does not have the credential pre-issued by the operator for authentication with the operator network, based on the DH key exchange mode, by the terminal device that has the credential.
  • the shared key thus enables it to access the network.
  • FIG. 18 is another schematic block diagram of a terminal device 1800 according to an embodiment of the present application.
  • the terminal device 1800 is the first terminal device in the foregoing method embodiment.
  • the terminal device 1800 includes a receiver 1810, a transmitter 1820, a processor 1830, and a memory 1840.
  • Receiver 1810 and transmitter 1820 may be collectively referred to as a transceiver.
  • the receiver 1810, the transmitter 1820, the processor 1830, and the memory 1840 are interconnected by an internal connection path.
  • the memory 1840 is configured to store instructions, and the processor 1830 is configured to execute instructions stored in the memory 1840 to control the receiver 1810.
  • the signal is received and the transmitter 1820 is controlled to transmit a signal.
  • the receiver 1810 is configured to receive a Dieffie Herman DH public key and a first identity ID sent by the at least one second terminal device, where the at least one second terminal device is a device that does not hold the shared key.
  • the sender 1820 is configured to send a first message to the server, where the first message includes a DH public key of each second terminal device of the at least one second terminal device, and a first one of each of the second terminal devices ID;
  • the receiver 1810 is further configured to receive a second message that is sent by the server based on the first message, where the second message includes a DH public key of the server, and the server is the second terminal device Generating a second ID of each of the second terminal devices, where the second ID is used to identify the subscriber;
  • the transmitter 1820 is further configured to send, to each of the second terminal devices, the second ID of each of the second terminal devices and the DH public key of the server, so that each of the second terminal devices is configured according to the Determining a second ID of each second terminal device and a DH public key of the server, determining a first shared key and each of the second terminals of each of the second terminal devices for authenticating with the server The second ID of the second terminal device.
  • the terminal device 1800 according to the embodiment of the present application may correspond to the first terminal device in the authentication method of the mobile network according to the embodiment of the present application shown in FIG. 7 to FIG. 11, and the terminal device 1500 according to the embodiment of the present application, and
  • the modules in the terminal device 1800 and the other operations and/or functions described above are used to implement the corresponding processes of the methods in FIG. 7 to FIG. 11 , and are not described herein again for brevity.
  • FIG. 19 is another schematic block diagram of a terminal device 1900 according to an embodiment of the present application.
  • the terminal device 1900 is the second terminal device in the foregoing method embodiment.
  • the terminal device 1900 includes a receiver 1910, a transmitter 1920, a processor 1930, and a memory 1940.
  • Receiver 1910 and transmitter 1920 may be collectively referred to as a transceiver.
  • the receiver 1910, the transmitter 1920, the processor 1930, and the memory 1940 are interconnected by an internal connection path for storing instructions for executing the instructions stored by the memory 1940 to control the receiver 1910.
  • the signal is received and the transmitter 1920 is controlled to transmit a signal.
  • the processor 1930 is configured to determine a Dieffi Herman DH public key of the second terminal device according to the first random number
  • the sender 1920 is configured to send the first message to the first terminal device, where the first message includes a DH public key of the second terminal device and a first identity identifier of the second terminal device, where The first terminal device is a device that already holds a shared key;
  • the receiver 1910 is configured to receive a second message that is sent by the first terminal device according to the first message, where the second message includes a DH public key of the server, and the server generates the second terminal device a second ID, where the second ID is used to identify a subscriber;
  • the processor 1930 is further configured to: determine, according to the first random number, a DH public key of the server, a first shared key; and the server according to the first shared key and the second ID Perform mutual authentication.
  • the terminal device 1900 according to the embodiment of the present application may correspond to the embodiment of the present application according to FIG. 7 to FIG. a second terminal device in the authentication method of the mobile network, and the terminal device 1600 according to an embodiment of the present application, and each module in the terminal device 1900 and the other operations and/or functions described above are implemented in FIGS. 7 to 11
  • the corresponding processes of the various methods are not described here for brevity.
  • FIG. 20 is another schematic block diagram of a server 2000 according to an embodiment of the present application.
  • the server 2000 is the second terminal device in the foregoing method embodiment.
  • the server 2000 includes a receiver 2010, a transmitter 2020, a processor 2030, and a memory 2040.
  • Receiver 2010 and transmitter 2020 may be collectively referred to as a transceiver.
  • the receiver 2010, the transmitter 2020, the processor 2030, and the memory 2040 are mutually connected by an internal connection path.
  • the memory 2040 is configured to store instructions, and the processor 2030 is configured to execute instructions stored by the memory 2040 to control the receiver 2010.
  • the signal is received and the transmitter 2020 is controlled to transmit a signal.
  • a receiver 2010, configured to receive a first message sent by the first terminal device, where the first message includes, by the first terminal device, from each second terminal device of the at least one second terminal device a DH public key of each of the second terminal devices and a first ID of each of the second terminal devices, where the first terminal device is a device that has a shared key, and the at least one second terminal device a device that does not hold a shared key;
  • the processor 2030 is configured to determine a DH public key of the server according to the second random number, and generate a second ID of each second terminal device for each second terminal device, where the second ID is used by Determining a subscription user; determining, according to the DH public key of each second terminal device and the second random number, each of the second terminal devices for performing authentication with each of the second terminal devices First shared key;
  • the transmitter 2020 is configured to send a second message to the first terminal device, where the second message includes a DH public key of the server and a second ID of each second terminal device.
  • the server 2000 according to the embodiment of the present application may correspond to a server in the authentication method of the mobile network according to the embodiment of the present application shown in FIG. 7 to FIG. 11, and the server 1700 according to the embodiment of the present application, and the server 2000
  • the modules and the other operations and/or functions described above are used to implement the corresponding processes of the methods in FIG. 7 to FIG. 11 , and are not described herein again for brevity.
  • FIG. 21 shows a schematic block diagram of a terminal device 2100 of another embodiment of the present application.
  • the terminal device 2100 is the first terminal device in the foregoing method embodiment of FIG. 13, where the first terminal device is a device that already holds a shared key, and the first terminal device 2100 includes a receiving module. 2101 and a sending module 2102.
  • the receiving module 2101 is configured to receive a Dieffie Herman DH public key and a first identity ID sent by the at least one second terminal device, where the at least one second terminal device is a device that does not hold the shared key;
  • the sending module 2102 is configured to send an attach request message to the network authentication entity, where the attach request message includes a first message and an identity identifier of the first terminal device, where the first message includes the at least one second a DH public key of each second terminal device in the terminal device and a first ID of each of the second terminal devices;
  • the receiving module 2101 is further configured to receive a user authentication request message that is sent by the network authentication entity according to the attach request message, where the user authentication request message includes a second message and authentication data, where the second message includes a DH public key of the server, and a second ID of each of the second terminal devices generated by the server for each of the second terminal devices, where the second ID is used to identify the subscriber;
  • the sending module 2102 is further configured to send, to each of the second terminal devices, a DH public key of the server and a second ID of each second terminal device, so that each of the second terminal devices Determining, according to the second ID of each second terminal device and the DH public key of the server, a first shared key and each of the each second terminal device for authenticating with the server The second ID of the second terminal device.
  • the terminal device in the embodiment of the present application can enter the carrier network according to the credentials that it already holds.
  • the terminal device that does not hold the pre-issued credential of the operator establishes a channel for the key negotiation with the server, so that the terminal device that does not have the credential pre-issued by the operator can also be the slave server.
  • a shared key for authentication with the carrier network is obtained to be able to access the network.
  • the receiving module 2101 is further configured to: receive the second ID of each of the second terminal devices that is sent by each of the second terminal devices, and each of the second terminal devices is the a message verification code MAC generated by the second ID of the second terminal device;
  • the sending module 2102 is further configured to send, to the network authentication entity, the second ID of each second terminal device, and the MAC of the second ID of each second terminal device;
  • the receiving module 2101 is further configured to receive a configuration completion message that is sent by the network authentication entity based on the second ID of each second terminal device and the MAC address of the second ID of each second terminal device;
  • the sending module 2102 is further configured to send the configuration completion message to each of the second terminal devices.
  • the sending module 2102 is further configured to: send, according to the user authentication request message, a user authentication response message to the network authentication entity;
  • the receiving module 2101 is further configured to receive an authentication success message sent by the network authentication entity based on the authentication response message.
  • the server is characterized in that the server comprises a home subscriber server HSS.
  • the network authentication entity includes a mobility management entity MME.
  • the terminal device 2100 may correspond to the first terminal device in the authentication method according to the embodiment of the present application in FIG. 13, and each module in the terminal device 2100 and the other operations and/or functions described above are respectively In order to implement the corresponding processes of the various methods in FIG. 13, for brevity, no further details are provided herein.
  • FIG. 22 shows a schematic block diagram of a network authentication entity 2200 of another embodiment of the present application.
  • the network authentication entity 2200 is the network authentication entity in the foregoing method embodiment of FIG. 13, and the network authentication entity 2200 includes a receiving module 2201 and a sending module 2202.
  • the receiving module 2201 is configured to receive an attach request message sent by the first terminal device, where the attach request message includes a first message and an identity identifier of the first terminal device, where the first message includes the at least one a DH public key of each of the second terminal devices and a first ID of each of the second terminal devices, the first terminal device being a device that has a shared key, the at least one The second terminal device is a device that does not hold a shared key;
  • the sending module 2202 is configured to send an authentication data request message to the server according to the attach request message.
  • the receiving module 2201 is further configured to receive an authentication data response message sent by the server according to the authentication data request message, where the authentication data response message includes a second message and an authentication vector, where the second message includes a DH public key of the server, and a second ID of each of the second terminal devices generated by the server for each second terminal device, where the second ID is used to identify a subscriber;
  • the sending module 2202 is further configured to send the second message and the authentication data in the authentication vector to the first terminal device, so that the first terminal device sends the second terminal device to each of the second terminal devices.
  • the network authentication entity can provide a key with the server for the terminal device that does not hold the credential pre-issued by the operator in the process of authenticating the terminal device that holds the credential.
  • the negotiated channel is such that a terminal device that does not have a credential pre-issued by the operator can also obtain a shared key for authentication with the operator network from the server to be able to access the network.
  • the receiving module 2201 is further configured to: receive the second ID of each second terminal device that is sent by the first terminal device, and each of the second terminal devices is the second one a message authentication code MAC generated by the second ID of the terminal device, and a user authentication response message sent by the first terminal device based on the user authentication request message;
  • the sending module 2202 is further configured to send, to the server, the second ID of each second terminal device and the MAC of the second ID of each second terminal device;
  • the receiving module 2201 is further configured to receive a configuration completion message that is sent by the server based on the second ID of each second terminal device and the MAC address of the second ID of each second terminal device;
  • the sending module 2202 is further configured to: send an authentication success message to the first terminal device according to the user authentication response message, and send the configuration completion message to the first terminal device, so that the first The terminal device sends the configuration completion message to each of the second terminal devices.
  • the network authentication entity 2200 may correspond to a network authentication entity in the authentication method according to the embodiment of the present application in FIG. 13, and each module in the network authentication entity 2200 and the other operations and/or functions described above In order to implement the corresponding processes of the various methods in FIG. 13, for brevity, no further details are provided herein.
  • FIG. 23 shows a schematic block diagram of a server 2300 of another embodiment of the present application.
  • the server 2300 is the server in the foregoing method embodiment of FIG. 13, and the server 2300 includes a receiving module 2301, a determining module 2302, and a sending module 2303.
  • the receiving module 2301 is configured to receive an authentication data request message sent by the network authentication entity, where the authentication data request message includes a first message and an identity identifier of the first terminal device, where the first message includes at least one second terminal device a DH public key of each second terminal device and a first ID of each of the second terminal devices, the at least one second terminal device being a device not holding the shared key;
  • a determining module 2302 configured to determine a DH public key of the server, and generate, for each of the second terminal devices, a second ID of each second terminal device, where the second ID is used to identify the subscriber Determining an authentication vector based on the authentication data request message;
  • the sending module 2303 is configured to send a user authentication response message to the network authentication entity, where the user authentication response message includes the second message and the authentication vector, and the second message includes a DH of the server. a key, and a second ID of each of the second terminal devices.
  • the server of the embodiment of the present application can provide a terminal device that does not have a credential pre-issued by the operator, in a DH key exchange manner, in the process of performing authentication with the terminal device that already holds the credential.
  • the server further includes a verification module, where the receiving module 2301 is configured to: receive a second ID of each of the second terminal devices sent by the network authentication entity, and each of the second a message authentication code MAC generated by the terminal device for the second ID of each of the second terminal devices;
  • the verification module is configured to verify, according to the first shared key, a MAC of a second ID of each second terminal device;
  • the sending module is configured to send a configuration completion message to the network authentication entity if the verification module passes the MAC verification of the second ID of each second terminal device.
  • the server 2300 may correspond to a server in the authentication method according to the embodiment of the present application in FIG. 13, and each module in the server 2300 and the other operations and/or functions described above are used to implement each of FIG. The corresponding process of the method is not repeated here for the sake of brevity.
  • FIG. 24 is another schematic block diagram of a terminal device 2400 according to another embodiment of the present application.
  • the terminal device 2400 is the first terminal device in the foregoing method embodiment of FIG.
  • the terminal device 2400 includes a receiver 2410, a transmitter 2420, a processor 2430, and a memory 2440.
  • Receiver 1810 and transmitter 1820 may be collectively referred to as a transceiver.
  • the receiver 2410, the transmitter 2420, the processor 2430, and the memory 2440 are interconnected by an internal connection path.
  • the memory 2440 is configured to store instructions
  • the processor 2430 is configured to execute instructions stored by the memory 2440 to control the receiver 2410.
  • the signal is received and the transmitter 2420 is controlled to transmit a signal.
  • the receiver 2410 is configured to receive a Dieffie Herman DH public key and a first identity ID sent by the at least one second terminal device, where the at least one second terminal device is a device that does not hold the shared key.
  • the sender 2420 is configured to send an attach request message to the network authentication entity, where the attach request message includes a first message and an identity identifier of the first terminal device, where the first message includes the at least one second a DH public key of each second terminal device in the terminal device and a first ID of each of the second terminal devices;
  • the receiver 2410 is further configured to receive a user authentication request message that is sent by the network authentication entity according to the attach request message, where the user authentication request message includes a second message and authentication data, where the second message includes a DH public key of the server, and a second ID of each of the second terminal devices generated by the server for each of the second terminal devices, where the second ID is used to identify the subscriber;
  • the transmitter 2420 is further configured to send, to each of the second terminal devices, a DH public key of the server and a second ID of each second terminal device, so that each of the second terminal devices Determining, according to the second ID of each second terminal device and the DH public key of the server, a first shared key and each of the each second terminal device for authenticating with the server The second ID of the second terminal device.
  • the terminal device 2400 according to the embodiment of the present application may correspond to the first terminal device in the authentication method of the mobile network according to the embodiment of the present application shown in FIG. 13, and the terminal device 2100 according to the embodiment of the present application, and the terminal
  • the modules in the device 2400 and the other operations and/or functions described above are used to implement the corresponding processes of the various methods in FIG. 13, and are not described herein for brevity.
  • FIG. 25 is another schematic block diagram of a network authentication entity 2500 according to another embodiment of the present application.
  • the network authentication entity 2500 is the network authentication entity in the method embodiment of FIG. 13 described above.
  • the network authentication entity 2500 includes a receiver 2510, a transmitter 2520, a processor 2530, and a memory 2540.
  • Receiver 2510 and transmitter 2520 may be collectively referred to as a transceiver.
  • the receiver 2510, the transmitter 2520, the processor 2530, and the memory 2540 are interconnected by an internal connection path.
  • the memory 2540 is configured to store instructions, and the processor 2530 is configured to execute instructions stored by the memory 2540 to control the receiver 2510.
  • the signal is received and the transmitter 2520 is controlled to transmit a signal.
  • the receiver 2510 is configured to receive an attach request message sent by the first terminal device, where the attach request message includes a first message and an identity identifier of the first terminal device, where the first message includes the a DH public key of each of the at least one second terminal device and a first ID of each of the second terminal devices, where the first terminal device is a device that already holds a shared key, At least one second terminal device is a device that does not hold a shared key;
  • the sender 2520 is configured to send an authentication data request message to the server according to the attach request message.
  • the receiver 2510 is further configured to receive an authentication data response message sent by the server based on the authentication data request message, where the authentication data response message includes a second message and an authentication vector, where the second message includes a DH public key of the server, and a second ID of each of the second terminal devices generated by the server for each second terminal device, where the second ID is used to identify a subscriber;
  • the transmitter 2520 is further configured to send the second message and the authentication data in the authentication vector to the first terminal device, so that the first terminal device sends the second terminal device to each of the second terminal devices.
  • the network authentication entity 2500 according to the embodiment of the present application may correspond to the first terminal device in the authentication method of the mobile network according to the embodiment of the present application shown in FIG. 13, and the network authentication entity 2200 according to the embodiment of the present application, and
  • the modules in the network authentication entity 2500 and the other operations and/or functions described above are used to implement the corresponding processes of the methods in FIG. 13 , and are not described herein for brevity.
  • FIG. 26 is another schematic block diagram of a server 2600 according to another embodiment of the present application.
  • the server 2600 is a server in the above method embodiment.
  • the server 2600 includes a receiver 2610, a transmitter 2620, a processor 2630, and a memory 2640.
  • Receiver 2610 and transmitter 2620 may be collectively referred to as a transceiver.
  • the receiver 2610, the transmitter 2620, the processor 2630, and the memory 2640 are interconnected by an internal connection path.
  • the memory 2640 is used to store instructions, and the processor 2630 is configured to execute instructions stored in the memory 2640 to control the receiver 2610.
  • the signal is received and the transmitter 2620 is controlled to transmit a signal.
  • the receiver 2610 is configured to receive an authentication data request message sent by the network authentication entity, where the authentication data request message includes a first message and an identity identifier of the first terminal device, where the first message includes at least one second terminal. a DH public key of each second terminal device in the device and a first ID of each of the second terminal devices, the at least one second terminal device being a device not holding the shared key;
  • the processor 2630 is configured to determine a DH public key of the server, and generate, for each of the second terminal devices, a second ID of each second terminal device, where the second ID is used to identify the subscriber Determining an authentication vector based on the authentication data request message;
  • the transmitter 2620 is configured to send a user authentication response message to the network authentication entity, where the user authentication response message includes the second message and the authentication vector, and the second message includes a DH of the server. a key, and a second ID of each of the second terminal devices.
  • the server 2600 according to the embodiment of the present application may correspond to a server in the authentication method of the mobile network according to the embodiment of the present application shown in FIG. 13, and the server 2300 according to the embodiment of the present application, and each module in the server 2600 And the other operations and/or functions described above are used to implement the corresponding processes of the various methods in FIG. 13, and are not described herein for brevity.
  • the processor in the embodiment of the present application may be an integrated circuit chip with signal processing capability.
  • each step of the foregoing method embodiment may be completed by an integrated logic circuit of hardware in a processor or an instruction in a form of software.
  • the processor may be a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a Field Programmable Gate Array (FPGA), or the like. Programming logic devices, discrete gates or transistor logic devices, discrete hardware components.
  • the methods, steps, and logical block diagrams disclosed in the embodiments of the present application can be implemented or executed.
  • the general purpose processor may be a microprocessor or the processor or any conventional processor or the like.
  • the steps of the method disclosed in the embodiments of the present application may be directly implemented by the hardware decoding processor, or may be performed by a combination of hardware and software modules in the decoding processor.
  • the software module can be located in a conventional storage medium such as random access memory, flash memory, read only memory, programmable read only memory or electrically erasable programmable memory, registers, and the like.
  • the storage medium is located in the memory, and the processor reads the information in the memory and combines the hardware to complete the steps of the above method.
  • the memory in the embodiment of the present application may be a volatile memory or a non-volatile memory, or may be Both volatile and non-volatile memory are included.
  • the non-volatile memory may be a read-only memory (ROM), a programmable read only memory (PROM), an erasable programmable read only memory (Erasable PROM, EPROM), or an electric Erase programmable read only memory (EEPROM) or flash memory.
  • the volatile memory can be a Random Access Memory (RAM) that acts as an external cache.
  • RAM Random Access Memory
  • many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (Synchronous DRAM).
  • SDRAM Double Data Rate SDRAM
  • DDR SDRAM Double Data Rate SDRAM
  • ESDRAM Enhanced Synchronous Dynamic Random Access Memory
  • SLDRAM Synchronous Connection Dynamic Random Access Memory
  • DR RAM direct memory bus random access memory
  • system and “network” are used interchangeably herein.
  • the term “and/or” in this context is merely an association describing the associated object, indicating that there may be three relationships, for example, A and / or B, which may indicate that A exists separately, and both A and B exist, respectively. B these three situations.
  • the character "/" in this article generally indicates that the contextual object is an "or" relationship.
  • B corresponding to A means that B is associated with A, and B can be determined according to A.
  • determining B from A does not mean that B is only determined based on A, and that B can also be determined based on A and/or other information.
  • the disclosed systems, devices, and methods may be implemented in other manners.
  • the device embodiments described above are merely illustrative.
  • the division of the unit is only a logical function division.
  • there may be another division manner for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not executed.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, and may be in an electrical, mechanical or other form.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the functions may be stored in a computer readable storage medium if implemented in the form of a software functional unit and sold or used as a standalone product.
  • the technical solution of the present application which is essential or contributes to the prior art, or a part of the technical solution, may be embodied in the form of a software product, which is stored in a storage medium, including Several instructions to make a computer device (can It is a personal computer, server, or network device, etc.) that performs all or part of the steps of the methods described in various embodiments of the present application.
  • the foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like, which can store program codes. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本申请公开了一种移动网络的认证方法、终端设备、服务器和网络认证实体。该方法包括：第一终端设备接收至少一个第二终端设备发送的DH公钥和第一ID；所述第一终端设备向服务器发送第一消息，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID；所述第一终端设备接收所述服务器发送的第二消息，所述第二消息包括所述服务器的DH公钥以及所述服务器生成的所述每个第二终端设备的第二ID；所述第一终端设备向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥。这样，能够使终端设备在不具有运营商网络预发放的信任状时也能获取运营商网络的信任状。

Description

移动网络的认证方法、终端设备、服务器和网络认证实体
本申请要求于2016年09月09日提交中国专利局、申请号为201610814492.7、发明名称为“移动网络的认证方法、终端设备、服务器和网络认证实体”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信领域，尤其涉及通信领域中的移动网络的认证方法、终端设备、服务器和网络认证实体。
背景技术
物联网(Internet of Things，IoT)是下一代移动通信网络5G的一大重要应用场景。物联网成本敏感，安全性和稳定性要求更高，传统的订购者身份模块(Subscriber Identity Module，SIM)难以满足物联网设备的要求。具有远程信任状(Credential)配置功能的嵌入式订购者身份模块(Embedded Subscriber Identity Module，eSIM)应运而生，其可直接焊接在物联网设备中以保证稳定性，可在终端设备激活时远程下载运营商的信任状。目前，eSIM的远程配置技术和规范中，都要求终端设备在出厂时具有一个初始的信任状(Initial Credential)。终端设备在激活入网时，利用这个初始的临时信任状和运营商的信任状远程配置服务器建立安全通道，并下载运营商提供的信任状以便以后入网。然而，在物联网的场景下，有极大的可能性，物联网设备在出厂并未配置任何初始的信任状。现有的技术和规范都无法满足这种没有持有运营商预发放的信任状的物联网设备的远程下载运营商信任状的需求。
发明内容
有鉴于此，本申请实施例提供了一种移动网络的认证方法、终端设备、服务器和网络认证实体，能够使终端设备在不具有运营商网络预发放的信任状的情况下，通过已持有信任状的终端设备，获取运营商网络的信任状。
第一方面，提供了一种移动网络的认证方法，所述方法包括：
第一终端设备接收至少一个第二终端设备发送的迪菲赫尔曼DH公钥和第一身份标识ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；所述第一终端设备向服务器发送第一消息，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID；所述第一终端设备接收所述服务器基于所述第一消息发送的第二消息，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；所述第一终端设备向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥，以使得所述每个第二终端设备根据所述每个第二终端设备的第二ID和所述服务器的DH公钥，确定用于与所述服务器进行认证的所述每个第二终端设备的第一共享密钥和所述每个第二终端设备的第二ID。
因此，终端设备基于自身已持有的运营商的信任状，能够对未持有运营商预发放的信任状的终端设备建立与服务器之间的密钥协商的通道，使不具有运营商预先发放的信任状的终端设备，也能够从服务器获取用于与运营商网络进行认证的共享密钥从而能够接入网络。
可选地，所述第一消息还包括指示信息，所述指示信息用于指示所述第一消息用于为所述每个第二终端设备请求所述每个第二终端设备的共享密钥和所述每个第二终端设备第二ID。
例如，该指示信息例如可以为一个标志位，该标志位可以用不同值表示是为个一个第二终端设备请求运营商颁发的信任状，还是为多个第二终端设备请求运营商颁发的信任状。当第一终端设备接收到第二终端设备发送的第二终端设备的第一ID和第二终端设备的DH公钥时，第一终端设备可以在向服务器发送的第一消息中添加该指示信息。该第二ID例如可以为运营商为签约用户分配的IMSI号码。
可选地，在所述第一终端设备向所述服务器发送第一消息之前，所述方法还包括：所述第一终端设备根据第二共享密钥，为所述第一消息生成所述第一消息的消息验证码MAC，所述第二共享密钥用于所述第一终端设备与所述服务器之间的认证；其中，所述第一终端设备向所述服务器发送第一消息，包括：所述第一终端设备向所述服务器发送所述第一消息和所述第一消息的MAC。
可选地，所述第一终端设备接收所述服务器基于所述第一消息发送的第二消息，包括：所述第一终端设备接收所述服务器发送的所述第二消息，和所述服务器根据第二共享密钥为所述第二消息生成的所述第二消息的MAC；其中，所述第一终端设备向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥，包括：所述第一终端设备根据第二共享密钥，对所述第二消息的MAC进行验证；如果所述第一终端设备对所述第二消息的MAC验证通过，所述第一终端设备向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥。
这样，服务器和终端设备在信息交互的过程中，通过对消息进行消息验证，能够确保消息的来源可靠且传输过程仲未被篡改，提高了密钥交换过程的安全性。
可选地，所述第一终端设备接收所述服务器基于所述第一消息发送的第二消息，包括：所述第一终端设备接收所述服务器发送的所述第二消息、所述服务器对所述每个第二终端设备的第二ID和所述服务器的DH公钥进行签名后得到的所述每个第二终端设备的签名消息、以及与所述每个第二终端设备的签名消息对应的所述每个第二终端设备的验证信息；其中，所述第一终端设备向所述每个第二终端设备发送所述第二消息，包括：所述第一终端设备向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥、所述每个第二终端设备的签名消息和所述每个第二终端设备的验证信息。
可选地，所述验证消息包括所述服务器的证书或者所述服务器的ID。
其中，如果服务器采用的是基于证书的密钥机制，那么该验证信息可以为该服务器的证书，即与服务器加密第二消息所使用的私钥相对应的证书，从而第二终端设备能够根据该证书对该签名进行验证；如果服务器采用的是基于身份的密钥体制，那么该验证信息可以为服务器的ID，从而第二终端设备能够根据该服务器的ID对该签名进行验证。
这样，由于发送给未持有信任状的终端设备的服务器的DH公钥以及为终端设备生 成的用于标识签约用户的标识，是经过服务器进行签名的，从而提高了密钥交换过程的安全性，在即使终端设备被攻破控制的情况下，也无法发起中间人攻击。
可选地，在所述第一终端设备向所述服务器发送第一消息之前，所述方法还包括：所述第一终端设备根据第二共享密钥，对所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID进行加密；其中，所述第一终端设备向所述服务器发送的所述第一消息中的所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，是经过所述第一终端设备加密的。
可选地，所述第一终端设备从所述服务器接收的所述第二消息中的所述每个第二终端设备的第二ID和所述服务器的DH公钥，是经过所述服务器加密的；其中，在所述第一终端设备向所述每个第二终端设备发送所述每个第二终端设备的第二ID，和所述服务器的DH公钥之前，所述方法还包括：所述第一终端设备根据第二共享密钥，对加密后的所述每个第二终端设备的第二ID和所述服务器的DH公钥进行解密；所述第一终端设备向所述每个第二终端设备发送所述每个第二终端设备的第二ID，和所述服务器的DH公钥，包括：所述第一终端设备向所述每个第二终端设备发送解密后的所述每个第二终端设备的第二ID和所述服务器的DH公钥。
这样，在服务器和终端设备在信息交互的过程中，通过对消息进行加密，提高了服务器和终端设备的密钥交换过程的安全性。
可选地，所述服务器包括归属用户服务器HSS。
第二方面，提供了一种终端设备，所述终端设备为第一终端设备，该终端设备可以用于执行前述第一方面及各种实现方式中的移动网络的认证方法中由第一终端设备执行的各个过程，所述第一终端设备为已持有共享密钥的设备，所述第一终端设备包括：
接收模块，用于接收至少一个第二终端设备发送的迪菲赫尔曼DH公钥和第一身份标识ID，所述至少一个第二终端设备为未持有共享密钥的设备；发送模块，用于向服务器发送第一消息，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID；所述接收模块还用于，接收所述服务器基于所述第一消息发送的第二消息，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；所述发送模块还用于，向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥，以使得所述每个第二终端设备根据所述每个第二终端设备的第二ID和所述服务器的DH公钥，确定用于与所述服务器进行认证的所述每个第二终端设备的第一共享密钥和所述每个第二终端设备的第二ID。
第三方面，提供了另一种终端设备，所述终端设备为第一终端设备，所述第一终端设备为已持有共享密钥的设备，所述第一终端设备包括处理器、接收器、发送器和存储器。该存储单元用于存储指令，该处理器用于执行该存储器存储的指令，并且当该处理器执行该存储器存储的指令时，该执行使得该处理器执行第一方面或第一方面的任意可能的实现方式中的方法。
其中，该接收器，用于接收至少一个第二终端设备发送的迪菲赫尔曼DH公钥和第一身份标识ID，所述至少一个第二终端设备为未持有共享密钥的设备；该发送器，用于向服务器发送第一消息，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID；该接收器还用于，接收所述服务 器基于所述第一消息发送的第二消息，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；该发送器还用于，向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥，以使得所述每个第二终端设备根据所述每个第二终端设备的第二ID和所述服务器的DH公钥，确定用于与所述服务器进行认证的所述每个第二终端设备的第一共享密钥和所述每个第二终端设备的第二ID。
第四方面，提供了一种移动网络的认证方法，所述方法包括：
第二终端设备根据第一随机数确定所述第二终端设备的迪菲赫尔曼DH公钥，所述第二终端设备为未持有共享密钥的设备；所述第二终端设备发送第一消息至第一终端设备，其中，所述第一消息包括所述第二终端设备的DH公钥和所述第二终端设备的第一身份标识ID，所述第一终端设备为已持有共享密钥的设备；所述第二终端设备接收所述第一终端设备基于所述第一消息发送的第二消息，所述第二消息包括服务器的DH公钥，和所述服务器为所述第二终端设备生成的第二ID，所述第二ID用于标识签约用户；所述第二终端设备根据所述第一随机数，和所述服务器的DH公钥，确定第一共享密钥；所述第二终端设备根据所述第一共享密钥和所述第二ID，与所述服务器进行相互认证。
因此，不具有运营商预先发放的信任状的终端设备，可以通过其他已持有信任状的终端设备，基于DH密钥交换的方式从服务器获取用于与运营商网络进行认证的共享密钥从而能够接入网络。
举例来说，第二终端设备可以产生一个随机数例如RAND 1，该第二终端设备根据RAND 1计算该第二终端设备的DH公钥，这里记作A，A＝gRAND 1 mod p，并将该公钥A通过第一终端设备发送给服务器。同样，服务器也可以根据一个随机数RAND 2计算服务器的DH公钥，这里记作B，B＝gRAND 2 mod p，并将该公钥B发送给第二终端设备。第二终端设备从第一终端设备接收到的服务器的DH公钥B＝gRAND 2 mod p后，就能够根据自己的随机数RAND 1和公钥B，确定用于与服务器进行认证的共享秘钥KD，其中KD＝ARAND 2 mod p。
可以看出，服务器确定的共享秘钥KD＝ARAND 2 mod p，第二终端设备确定的共享秘钥KD＝BRAND 1 mod p是相同的，即K＝Ab mod p＝(ga mod p)b mod p＝gab mod p＝(gb mod p)a＝Ba mod p。并且，该共享密钥仅该第二终端设备与服务器知道，而第一终端设备并不知道，因此，该第二终端设备可以使用该共享秘钥和该第二终端设备的第二ID，与服务器之间进行认证从而接入运营商网络。
可选地，所述第二终端设备接收所述第一终端设备发送的第二消息，包括：所述第二终端设备接收所述第一终端设备发送的所述第二消息、所述服务器对所述第二消息签名后得到的签名消息、和与所述签名消息对应的验证信息；所述第二终端设备根据所述第一随机数，和所述服务器的DH公钥，确定第一共享密钥，包括：所述第二终端设备根据所述第二消息、所述签名消息和所述验证信息，对所述第二消息进行验证；如果所述第二终端设备对所述第二消息验证通过，所述第二终端设备根据所述第一随机数和所述服务器的DH公钥，确定所述第一共享密钥。
可选地，所述验证消息包括所述服务器的证书或者所述服务器的ID。
其中，如果服务器采用的是基于证书的密钥机制，那么该验证信息可以为该服务器的证书，即与服务器加密第二消息所使用的私钥相对应的证书，从而第二终端设备能够 根据该证书对该签名进行验证；如果服务器采用的是基于身份的密钥体制，那么该验证信息可以为服务器的ID，从而第二终端设备能够根据该服务器的ID对该签名进行验证。
可选地，所述方法还包括：所述第二终端设备根据所述第一共享密钥，为所述第二ID生成所述第二ID的消息验证码MAC；所述第二终端设备向所述服务器发送所述第二ID和所述第二ID的MAC；所述第二终端设备接收所述服务器基于所述第二ID和所述第二ID的MAC发送的配置完成消息，以及所述服务器为所述配置完成消息生成的所述配置完成消息的MAC；所述第二终端设备根据所述第一共享密钥，对所述配置完成消息的MAC进行验证；其中，所述第二终端设备根据所述第一共享密钥和所述第二ID，与所述服务器进行相互认证，包括：如果所述第二终端设备对所述配置完成消息的MAC验证通过，所述第二终端设备根据所述第一共享密钥和所述第二ID，与所述服务器进行相互认证。
这样，第二终端设备能够确保服务器确定的第一共享密钥与第二终端设备确定的第一共享密钥是一致的。
第五方面，提供了一种终端设备，所述终端设备为第二终端设备，该终端设备可以用于执行前述第四方面及各种实现方式中的移动网络的认证方法中由第二终端设备执行的各个过程，所述第二终端设备为未持有共享密钥的设备，所述第二终端设备包括：
确定模块，用于根据第一随机数确定所述第二终端设备的迪菲赫尔曼DH公钥；发送模块，用于发送第一消息至第一终端设备，其中，所述第一消息包括所述第二终端设备的DH公钥和所述第二终端设备的第一身份标识ID，所述第一终端设备为已持有共享密钥的设备；接收模块，用于接收所述第一终端设备基于所述第一消息发送的第二消息，所述第二消息包括服务器的DH公钥，和所述服务器为所述第二终端设备生成的第二ID，所述第二ID用于标识签约用户；所述确定模块还用于，根据所述第一随机数，和所述服务器的DH公钥，确定第一共享密钥；认证模块，用于根据所述第一共享密钥和所述第二ID，与所述服务器进行相互认证。
第六方面，提供了另一种终端设备，所述终端设备为第二终端设备，所述第二终端设备为未持有共享密钥的设备，所述第二终端设备包括处理器、接收器、发送器和存储器。该存储单元用于存储指令，该处理器用于执行该存储器存储的指令，并且当该处理器执行该存储器存储的指令时，该执行使得该处理器执行第四方面或第四方面的任意可能的实现方式中的方法。
其中，处理器，用于根据第一随机数确定所述第二终端设备的迪菲赫尔曼DH公钥；发送器，用于发送第一消息至第一终端设备，其中，所述第一消息包括所述第二终端设备的DH公钥和所述第二终端设备的第一身份标识ID，所述第一终端设备为已持有共享密钥的设备；接收器，用于接收所述第一终端设备基于所述第一消息发送的第二消息，所述第二消息包括服务器的DH公钥，和所述服务器为所述第二终端设备生成的第二ID，所述第二ID用于标识签约用户；所述处理器还用于，根据所述第一随机数，和所述服务器的DH公钥，确定第一共享密钥；所述处理器还用于，根据所述第一共享密钥和所述第二ID，与所述服务器进行相互认证。
第七方面，提供了一种移动网络的认证方法，所述方法包括：
服务器接收所述第一终端设备发送的第一消息，其中，所述第一消息包括所述第一终端设备从至少一个第二终端设备中的每个第二终端设备接收的所述每个第二终端设备 的DH公钥和所述每个第二终端设备的第一ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；所述服务器根据第二随机数确定所述服务器的DH公钥，并为所述每个第二终端设备生成所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；所述服务器根据所述每个第二终端设备的DH公钥和所述第二随机数，确定用于与所述每个第二终端设备进行认证的所述每个第二终端设备的第一共享密钥；所述服务器向所述第一终端设备发送第二消息，所述第二消息包括所述服务器的DH公钥和所述每个第二终端设备的第二ID。
因此，服务器能够通过已持有信任状的终端设备，基于DH密钥交换的方式，为不具有运营商预先发放的信任状的终端设备提供用于与运营商网络进行认证的共享密钥从而使其能够接入网络。
举例来说，第二终端设备可以产生一个随机数例如RAND 1，该第二终端设备根据RAND 1计算该第二终端设备的DH公钥，这里记作A，A＝gRAND 1 mod p，第二终端设备还将该DH公钥B通过第一终端设备发送给服务器。同样，服务器也可以根据一个随机数RAND 2计算服务器的DH公钥，这里记作B，B＝gRAND 2 mod p，服务器还将该DH公钥B通过第一终端设备发送给第二终端设备。服务器从第一终端设备接收到的第二终端设备的DH公钥A＝gRAND 1 mod p后，就能够根据自己的随机数RAND 2和公钥A，确定用于与第二终端设备进行认证的共享秘钥KD，其中KD＝ARAND 2 mod p。
可以看出，服务器确定的共享秘钥KD＝ARAND 2 mod p，第二终端设备确定的共享秘钥KD＝BRAND 1 mod p是相同的，即K＝Ab mod p＝(ga mod p)b mod p＝gab mod p＝(gb mod p)a＝Ba mod p。并且，该共享密钥仅该第二终端设备与服务器知道，而第一终端设备并不知道，因此，该第二终端设备可以使用该共享秘钥和该第二终端设备的第二ID，与服务器之间进行认证从而接入运营商网络。
可选地，所述方法包括：所述第一消息还包括指示信息，所述指示信息用于指示所述第一消息用于为所述每个第二终端设备请求所述第二终端设备的的共享密钥和所述第二终端设备的第二ID。
例如，该指示信息例如可以为一个标志位，该标志位可以用不同值表示是为个一个第二终端设备请求运营商颁发的信任状，还是为多个第二终端设备请求运营商颁发的信任状。当第一终端设备接收到第二终端设备发送的第二终端设备的第一ID和第二终端设备的DH公钥时，第一终端设备可以在向服务器发送的第一消息中添加该指示信息。该第二ID例如可以为运营商为签约用户分配的IMSI号码。
可选地，所述服务器接收所述第一终端设备发送的第一消息，包括：所述服务器接收所述第一终端设备发送的所述第一消息，和所述第一终端设备根据第二共享密钥为所述第一消息生成的所述第一消息的消息验证码MAC，所述第二共享密钥用于所述第一终端设备与所述服务器之间的认证；其中，所述服务器根据所述第二随机数，和所述服务器的DH公钥，确定用于与所述每个第二终端设备进行认证的每个第二终端设备的第一共享密钥，包括：所述服务器根据第二共享密钥，对所述第一消息的MAC进行验证；如果所述服务器对所述第一消息的MAC验证通过，所述服务器根据所述第二随机数，和所述服务器的DH公钥，确定用于与所述每个第二终端设备进行认证的每个第二终端设备的第一共享密钥。
可选地，在所述服务器向所述第一终端设备发送第二消息之前，所述方法还包括： 所述服务器根据第二共享密钥，为所述第二消息生成所述第二消息的MAC；其中，所述服务器向所述第一终端设备发送第二消息，包括：所述服务器向所述第一终端设备发送所述第二消息和所述第二消息的MAC。
可选地，在所述服务器向所述第一终端设备发送第二消息之前，所述方法还包括：所述服务器对所述每个第二终端设备的第二ID和所述服务器的DH公钥进行签名；其中，所述服务器向所述第一终端设备发送第二消息，包括：所述服务器向所述第一终端设备发送所述第二消息、所述服务器对所述每个第二终端设备的第二ID和所述服务器的DH公钥进行签名后得到所述每个第二终端设备的签名消息、和与所述每个第二终端设备的签名消息对应的所述每个第二终端设备的验证消息。
这样，由于服务器可以采用非对称钥体制(例如基于证书的密码机制或基于身份的密码机制)，通过对待发送的服务器的DH公钥以及为终端设备生成的用于标识签约用户的标识进行签名，从而提高了密钥交换过程的安全性，在即使终端设备被攻破控制的情况下，也无法发起中间人攻击。
可选地，所述验证消息包括所述服务器的证书或者所述服务器的ID。
其中，如果服务器采用的是基于证书的密钥机制，那么该验证信息可以为该服务器的证书，即与服务器加密第二消息所使用的私钥相对应的证书，从而第二终端设备能够根据该证书对该签名进行验证；如果服务器采用的是基于身份的密钥体制，那么该验证信息可以为服务器的ID，从而第二终端设备能够根据该服务器的ID对该签名进行验证。
可选地，所述服务器从所述第一终端设备接收的所述第一消息中的所述每个第二终端设备的DH公钥，和所述每个第二终端设备的第一ID，是经过所述第一终端设备加密的；其中，在所述服务器根据所述每个第二终端设备的DH公钥，和所述第二随机数，确定用于与所述每个第二终端设备进行认证的每个第二终端设备的第一共享密钥之前，所述方法还包括：所述服务器根据第二共享密钥，对加密后的所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID进行解密；所述服务器根据所述每个第二终端设备的DH公钥，和所述第二随机数，确定用于与所述每个第二终端设备进行认证的所述每个第二终端设备的第一共享密钥，包括：所述服务器根据解密后的所述每个第二终端设备的DH公钥，和所述第二随机数，确定用于与所述每个第二终端设备进行认证的所述每个第二终端设备的第一共享密钥。
可选地，在所述服务器向所述第一终端设备发送第二消息之前，所述方法还包括：所述服务器根据第二共享密钥，对所述服务器的DH公钥和所述每个第二终端设备的第二ID进行加密；其中，所述服务器向所述第一终端设备发送的所述第二消息中的所述服务器的DH公钥和所述每个第二终端设备的第二ID，是经过所述服务器加密的。
可选地，所述方法还包括：所述服务器接收所述每个第二终端设备发送的所述每个第二终端设备的第二ID，和所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC；所述服务器根据所述第一共享密钥，对所述每个第二终端设备的第二ID的MAC进行验证；如果所述服务器对所述每个第二终端设备的第二ID的MAC验证成功，所述服务器向所述每个第二终端设备发送配置完成消息，以及所述服务器为所述配置完成消息生成的所述配置完成消息的MAC。
第八方面，提供了一种服务器，所述服务器可以用于执行前述第七方面及各种实现方式中的移动网络的认证方法中由服务器执行的各个过程，所述服务器包括：
接收模块，用于接收所述第一终端设备发送的第一消息，其中，所述第一消息包括所述第一终端设备从至少一个第二终端设备中的每个第二终端设备接收的所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；确定模块，用于根据第二随机数确定所述服务器的DH公钥，并为所述每个第二终端设备生成所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；所述确定模块还用于，根据所述每个第二终端设备的DH公钥和所述第二随机数，确定用于与所述每个第二终端设备进行认证的所述每个第二终端设备的第一共享密钥；发送模块，用于向所述第一终端设备发送第二消息，所述第二消息包括所述服务器的DH公钥和所述每个第二终端设备的第二ID。
第九方面，提供了另一种服务器，所述服务器包括处理器、接收器、发送器和存储器。该存储单元用于存储指令，该处理器用于执行该存储器存储的指令，并且当该处理器执行该存储器存储的指令时，该执行使得该处理器执行第七方面或第七方面的任意可能的实现方式中的方法。
其中，该接收器用于：接收所述第一终端设备发送的第一消息，其中，所述第一消息包括所述第一终端设备从至少一个第二终端设备中的每个第二终端设备接收的所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；该处理器用于：根据第二随机数确定所述服务器的DH公钥，并为所述每个第二终端设备生成所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；根据所述每个第二终端设备的DH公钥和所述第二随机数，确定用于与所述每个第二终端设备进行认证的所述每个第二终端设备的第一共享密钥；该发送器，用于向所述第一终端设备发送第二消息，所述第二消息包括所述服务器的DH公钥和所述每个第二终端设备的第二ID。
第十方面，提供了一种移动网络的认证方法，该方法包括：
第一终端设备接收至少一个第二终端设备发送的迪菲赫尔曼DH公钥和第一身份标识ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；所述第一终端设备向网络认证实体发送附着请求消息，其中，所述附着请求消息包括第一消息和所述第一终端设备的身份标识ID，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID；所述第一终端设备接收所述网络认证实体基于所述附着请求消息发送的用户认证请求消息，其中，所述用户认证请求消息包括第二消息和认证数据，所述第二消息包括服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；所述第一终端设备向所述每个第二终端设备发送所述服务器的DH公钥和所述每个第二终端设备的第二ID，以使得所述每个第二终端设备根据所述每个第二终端设备的第二ID和所述服务器的DH公钥，确定用于与所述服务器进行认证的所述每个第二终端设备的第一共享密钥和所述每个第二终端设备的第二ID。
因此，终端设备能够在根据自身已持有的信任状与运营商网络进行认证的过程中，对未持有运营商预发放的信任状的终端设备建立与服务器之间的密钥协商的通道，使不具有运营商预先发放的信任状的终端设备，也能够从服务器获取用于与运营商网络进行 认证的共享密钥从而接入网络。
可选地，所述方法还包括：所述第一终端设备接收所述每个第二终端设备发送的所述每个第二终端设备的第二ID，和所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC；所述第一终端设备向所述网络认证实体发送所述每个第二终端设备的第二ID，和所述每个第二终端设备的第二ID的MAC；所述第一终端设备接收所述网络认证实体基于所述每个第二终端设备的第二ID和所述每个第二终端设备的第二ID的MAC发送的配置完成消息；所述第一终端设备向所述每个第二终端设备发送所述配置完成消息。
可选地，所述方法还包括：所述第一终端设备基于所述用户认证请求消息，向所述网络认证实体发送用户认证响应消息；所述第一终端设备接收所述网络认证实体基于所述认证响应消息发送的认证成功消息。
可选地，所述服务器包括归属用户服务器HSS。
可选地，所述网络认证实体包括移动性管理实体MME。
第十一方面，提供了一种终端设备，所述终端设备为第一终端设备，该终端设备可以用于执行前述第十方面及各种实现方式中的移动网络的认证方法中由第一终端设备执行的各个过程，所述第一终端设备为已持有共享密钥的设备，所述第一终端设备包括：
接收模块，用于接收至少一个第二终端设备发送的迪菲赫尔曼DH公钥和第一身份标识ID，所述至少一个第二终端设备为未持有共享密钥的设备；发送模块，用于向服务器发送第一消息，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID；所述接收模块还用于，接收所述服务器基于所述第一消息发送的第二消息，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；所述发送模块还用于，向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥，以使得所述每个第二终端设备根据所述每个第二终端设备的第二ID和所述服务器的DH公钥，确定用于与所述服务器进行认证的所述每个第二终端设备的第一共享密钥和所述每个第二终端设备的第二ID。
第十二方面，提供了另一种终端设备，所述终端设备为第一终端设备，所述第一终端设备为已持有共享密钥的设备，所述第一终端设备包括处理器、接收器、发送器和存储器。该存储单元用于存储指令，该处理器用于执行该存储器存储的指令，并且当该处理器执行该存储器存储的指令时，该执行使得该处理器执行第十方面或第十方面的任意可能的实现方式中的方法。
其中，该接收器，用于接收至少一个第二终端设备发送的迪菲赫尔曼DH公钥和第一身份标识ID，所述至少一个第二终端设备为未持有共享密钥的设备；该发送器，用于向服务器发送第一消息，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID；该接收器，接收所述服务器基于所述第一消息发送的第二消息，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；该发送器，向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥，以使得所述每个第二终端设备根据所述每个第二终端设备的第二ID和所述服务器的DH公钥，确定用于与所述服务器进行认证的所述每个第二 终端设备的第一共享密钥和所述每个第二终端设备的第二ID。
第十三方面，提供了一种移动网络的认证方法，该方法包括：
网络认证实体接收第一终端设备发送的附着请求消息，其中，所述附着请求消息包括第一消息和所述第一终端设备的身份标识ID，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；所述网络认证实体根据所述附着请求消息，向服务器发送认证数据请求消息；所述网络认证实体接收所述服务器基于所述认证数据请求消息发送的认证数据响应消息，其中，所述认证数据响应消息包括第二消息和认证向量，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；所述网络认证实体向所述第一终端设备发送所述第二消息和所述认证向量中的认证数据，以使得所述第一终端设备向所述每个第二终端设备发送所述服务器的DH公钥和所述每个第二终端设备的第二ID。
因此，网络认证实体在对已持有信任状的终端设备进行认证的过程中，能够为未持有运营商预发放的信任状的终端设备提供与服务器之间的密钥协商的通道，以使不具有运营商预先发放的信任状的终端设备，也能够从服务器获取用于与运营商网络进行认证的共享密钥从而接入网络。
可选地，所述方法还包括：所述网络认证实体接收所述第一终端设备发送的所述每个第二终端设备的第二ID、所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC，以及所述第一终端设备基于所述用户认证请求消息发送的用户认证响应消息；所述网络认证实体向所述服务器发送所述每个第二终端设备的第二ID和所述每个第二终端设备的第二ID的MAC；所述网络认证实体接收所述服务器基于所述每个第二终端设备的第二ID和所述每个第二终端设备的第二ID的MAC发送的配置完成消息；所述网络认证实体根据所述用户认证响应消息，向所述第一终端设备发送认证成功消息，并向所述第一终端设备发送所述配置完成消息，以使得所述第一终端设备向所述每个第二终端设备发送所述配置完成消息。
第十四方面，提供了一种网络认证实体，所述网络认证实体可以用于执行前述第十三方面及各种实现方式中的移动网络的认证方法中由网络认证实体备执行的各个过程，所述网络认证实体包括：
接收模块，用于接收第一终端设备发送的附着请求消息，其中，所述附着请求消息包括第一消息和所述第一终端设备的身份标识ID，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；发送模块，用于根据所述附着请求消息，向服务器发送认证数据请求消息；所述接收模块还用于，接收所述服务器基于所述认证数据请求消息发送的认证数据响应消息，其中，所述认证数据响应消息包括第二消息和认证向量，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；所述发送模块还用于，向所述第一终端设备发送所述第二消息和所述认证向量中的认证数据，以使得所述第一终端设备向所述每个第二终端设备发送所述服务器的DH公钥和所述每个第二终端设备的第二ID。
第十五方面，提供了另一种网络认证实体，所述网络认证实体包括处理器、接收器、发送器和存储器。该存储单元用于存储指令，该处理器用于执行该存储器存储的指令，并且当该处理器执行该存储器存储的指令时，该执行使得该处理器执行第十三方面或第十三方面的任意可能的实现方式中的方法。
其中，该接收器，用于接收第一终端设备发送的附着请求消息，其中，所述附着请求消息包括第一消息和所述第一终端设备的身份标识ID，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；该发送器，用于根据所述附着请求消息，向服务器发送认证数据请求消息；该接收器还用于，接收所述服务器基于所述认证数据请求消息发送的认证数据响应消息，其中，所述认证数据响应消息包括第二消息和认证向量，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；该发送器还用于，向所述第一终端设备发送所述第二消息和所述认证向量中的认证数据，以使得所述第一终端设备向所述每个第二终端设备发送所述服务器的DH公钥和所述每个第二终端设备的第二ID。
第十六方面，提供了一种移动网络的认证方法，该方法包括：
服务器接收网络认证实体发送的认证数据请求消息，所述认证数据请求消息包括第一消息和第一终端设备的身份标识ID，所述第一消息包括至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述至少一个第二终端设备为未持有共享密钥的设备；所述服务器确定所述服务器的DH公钥，并为所述每个第二终端设备，生成所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；所述服务器基于所述认证数据请求消息，确定认证向量；所述服务器向所述网络认证实体发送用户认证响应消息，所述用户认证响应消息包括所述第二消息和所述认证向量，所述第二消息包括所述服务器的DH公钥，以及所述每个第二终端设备的第二ID。
可选地，所述方法包括：所述服务器接收所述网络认证实体发送的所述每个第二终端设备的第二ID，和所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC；所述服务器根据所述第一共享密钥，对所述每个第二终端设备的第二ID的MAC进行验证；如果所述服务器对所述每个第二终端设备的第二ID的MAC验证通过，所述服务器向所述网络认证实体发送配置完成消息。
因此，该服务器能够在与已持有信任状的终端设备进行认证的过程中，基于DH密钥交换的方式，为不具有运营商预先发放的信任状的终端设备提供用于与运营商网络进行认证的共享密钥从而使其接入网络。
第十七方面，提供了一种服务器，所述服务器可以用于执行前述第十六方面及各种实现方式中的移动网络的认证方法中由服务器执行的各个过程，所述服务器包括：
接收模块，用于接收网络认证实体发送的认证数据请求消息，所述认证数据请求消息包括第一消息和第一终端设备的身份标识ID，所述第一消息包括至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述至少一个第二终端设备为未持有共享密钥的设备；确定模块，用于确定所述服务器的DH公钥，并为所述每个第二终端设备，生成所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；所述确定模块还用于，基于所述认证数据请求消息，确定认证向量；所 述发送模块，用于向所述网络认证实体发送用户认证响应消息，所述用户认证响应消息包括所述第二消息和所述认证向量，所述第二消息包括所述服务器的DH公钥，以及所述每个第二终端设备的第二ID。
第十八方面，提供了另一种服务器，所述服务器包括处理器、接收器、发送器和存储器。该存储单元用于存储指令，该处理器用于执行该存储器存储的指令，并且当该处理器执行该存储器存储的指令时，该执行使得该处理器执行第十六方面或第十六方面的任意可能的实现方式中的方法。
其中，该接收器，用于接收网络认证实体发送的认证数据请求消息，所述认证数据请求消息包括第一消息和第一终端设备的身份标识ID，所述第一消息包括至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述至少一个第二终端设备为未持有共享密钥的设备；确定模块，用于确定所述服务器的DH公钥，并为所述每个第二终端设备，生成所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；该处理器用于：基于所述认证数据请求消息，确定认证向量；该发送器，用于向所述网络认证实体发送用户认证响应消息，所述用户认证响应消息包括所述第二消息和所述认证向量，所述第二消息包括所述服务器的DH公钥，以及所述每个第二终端设备的第二ID。
第十九方面，提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。
第二十方面，提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第四方面或第四方面的任意可能的实现方式中的方法的指令。
第二十一方面，提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第七方面或第七方面的任意可能的实现方式中的方法的指令。
第二十二方面，提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第十方面或第十方面的任意可能的实现方式中的方法的指令。
第二十三方面，提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第十三方面或第十三方面的任意可能的实现方式中的方法的指令。
第二十四方面，提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第十六方面或第十六方面的任意可能的实现方式中的方法的指令。
基于本申请实施例的移动网络的认证方法，不具有运营商预先发放的信任状的终端设备，可以通过其他已持有信任状的终端设备，基于DH密钥交换的方式从服务器获取用于与运营商网络进行认证的共享密钥从而接入网络。
附图说明
图1是本申请实施例的应用场景的示意图。
图2是是数字签名和验证过程的示意图。
图3是基于身份的密码机制的示意图。
图4是迪菲-赫尔曼密钥交换过程的示意图。
图5是传统的基于实体SIM卡的双向认证过程的示意图。
图6是基于eUICC的双向认证过程的示意图。
图7是本申请实施例的移动网络的认证方法的示意架构图。
图8是本申请实施例的移动网络的认证方法的流程交互图。
图9是本申请实施例的验证共享秘钥的流程交互图。
图10是本申请实施例的移动网络的认证方法的流程交互图。
图11是本申请实施例的移动网络的认证方法的流程交互图。
图12是现有技术中基于AKA的认证方法的示意性流程图。
图13是本申请实施例的移动网络的认证方法的流程交互图。
图14是本申请实施例的移动网络的认证方法的流程交互图。
图15是本申请实施例的终端设备的示意性框图。
图16是本申请实施例的终端设备的示意性框图。
图17是本申请实施例的服务器的示意性框图。
图18是本申请实施例的终端设备的另一示意性框图
图19是本申请实施例的终端设备的另一示意性框图。
图20是本申请实施例的服务器的另一示意性框图。
图21是本申请另一实施例的终端设备的示意性框图。
图22是本申请另一实施例的网络认证实体的示意性框图。
图23是本申请另一实施例的服务器的示意性框图。
图24是本申请另一实施例的终端设备的另一示意性框图。
图25是本申请另一实施例的网络认证实体的另一示意性框。
图26是本申请另一实施例的服务器的另一示意性框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。
在本说明书中使用的术语“部件”、“模块”、“系统”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。例如，部件可以是但不限于，在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。通过图示，在计算设备上运行的应用和计算设备都可以是部件。一个或多个部件可驻留在进程和/或执行线程中，部件可位于一个计算机上和/或分布在2个或更多个计算机之间。此外，这些部件可从在上面存储有各种数据结构的各种计算机可读介质执行。部件可例如根据具有一个或多个数据分组(例如来自与本地系统、分布式系统和/或网络间的另一部件交互的二个部件的数据，例如通过信号与其它系统交互的互联网)的信号通过本地和/或远程进程来通信。
应理解，本申请的技术方案可以应用于各种通信系统，例如：全球移动通讯(Global System of Mobile communication，GSM)系统、码分多址(Code Division Multiple Access，CDMA)系统、宽带码分多址(Wideband Code Division Multiple Access，WCDMA)系统、通用分组无线业务(General Packet Radio Service，GPRS)、长期演进(Long Term Evolution，LTE)系统、先进的长期演进(Advanced long term evolution，LTE-A)系统、通用移动通信系统(Universal Mobile Telecommunication System，UMTS)、以及5G通信系统等。
还应理解，在本申请实施例中，终端设备也可以指用户设备(User Equipment，UE)、 接入终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置。接入终端可以是蜂窝电话、无绳电话、会话启动协议(Session Initiation Protocol，SIP)电话、无线本地环路(Wireless Local Loop，WLL)站、个人数字处理(Personal Digital Assistant，PDA)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备，未来5G网络中的终端设备或者未来演进的PLMN网络中的终端设备等。
本申请实施例中的网络设备可以是用于与终端设备进行通信的设备，例如，可以是GSM系统或CDMA中的基站(Base Transceiver Station，BTS)，也可以是WCDMA系统中的基站(NodeB，NB)，还可以是LTE系统中的演进型基站(Evolutional Node B，eNB或eNodeB)，或者该网络设备可以为中继站、接入点、车载设备、可穿戴设备以及未来5G网络中的网络侧设备或未来演进的PLMN网络中的网络设备等。
图1示出了本申请实施例的一种应用场景的示意图。如图1所示，该通信系统可以包括网络设备10、终端设备20、终端设备30、终端设备40和服务器50。图1中所示出的箭头可以表示设备与设备之间的连接。针对物联网场景有两种接入蜂窝网络的方式：一种是终端设备直接接入蜂窝网络；另外一种是终端设备通过伙伴设备接入蜂窝网络。例如图1所示，终端设备30和终端设备40可以为物联网设备，终端设备40可以直接与网络设备10进行连接并接入核心网，而终端设备30可以通过伙伴设备即终端设备20，与网络设备10进行连接并接入核心网。
应注意，通过伙伴设备接入蜂窝网络这种场景，要求物联网设备也要和蜂窝网络进行端到端的双向认证。在认证时需要用到运营商颁发的信任状(Credential)，即移动用户身份(International Mobile Subscriber Identity，IMSI)和预共享密钥。
因此，以上两种场景，都需要物联网设备具有自己的Credential。传统的设备例如手机等可以通过实体的订购者身份模块(Subscriber Identity Module，SIM)卡获取3GPP Credential。但是物联网设备由于其自身特点，实体的SIM卡并不适用。另外一方面，嵌入式订购者身份模块(Embedded Subscriber Identity Module，eSIM)或者软SIM等将是物联网设备的较好选择。但是在物联网通信的场景下，由于厂商不知道最终物联网设备会被用在哪里用在那个运营商的网络里，因此有极大的可能性，物联网设备在出厂并未配置任何初始的信任状。
因此，现有的技术和规范无法满足这种没有持有运营商预发放的信任状的终端设备的远程获取运营商信任状的需求。为了解决这个问题，本申请提出终端设备通过已持有共享密钥的伙伴设备来获取远程获取运营商信任状，从而可以利用获取的运营商信任状与相应网络进行双向认证，接入并使用网络。
应注意，图1的例子只是为了帮助本领域技术人员更好地理解本申请实施例，而非限制本申请实施例的范围。例如，图1中虽然只描述了一个物联网设备通过伙伴设备与接入网络，但本申请实施例中可以有更多数目的物联网设备通过该伙伴设备与接入网络，还可以有更多数目的伙伴设备用于实现不同物联网设备的接入。且本申请对终端设备的类型不做任何限定。
应理解，本申请实施例中的伙伴设备(Companion UE)，也可以称为配对设备、担保设备、有卡设备、中间设备等，该伙伴设备已持有运营商预先发放的信任状，具有运营商网络预发放的共享密钥，可以借用该共享密钥，自身完成认证，在认证的全过程中 无需人工或者其他设备的参与，例如，该伙伴设备可以是持有2G网络的SIM卡的设备，或者是持有3、4G网络的USIM卡或ISIM卡等的设备，又或者是未来5G中持有用于识别用户身份的其他用户识别模块的设备，还可以是持有网络预发放的具有高安全能力或者具有高安全性的预制证书的设备，或者还可以是具有强共享密钥(例如用户名口令等)接入能力的设备。
以上所列举的伙伴设备所持有的卡的具体内容仅为示例性说明，不应对本申请构成任何限定，本申请也不应限于此。所有通过用户识别模块与运营商完成认证的设备都可以为本申请实施例中的伙伴设备。
还应理解，本申请实施例中不具有运营商网络预发放的信任状的终端设备，在请求接入网络的认证过程中，无法自身完成认证流程，必须依赖人工的参与，通过人机交互来完成认证。在本申请实施例中，不具有运营商网络预发放的信任状的终端设备，可以通过与其配对的伙伴设备获取与服务器进行认证的共享密钥和用于标识签约用的身份标识例如国际移动用户标识码(International Mobile Subscriber Identification Number，IMSI)。
还应理解，本申请实施例中的信任状，可以包括共享密钥和用于标识签约用户的身份标识例如IMSI，还可以包括其他有用信息，这里不做限定。
为方便理解，下面结合图1至图4说明本申请实施例中涉及的相关技术。
1、非对称加密(asymmetric cryptography)
非对称加密是一种密码学算法类型，在这种密码学方法中，需要一对密钥，一个是私人密钥，另一个则是公开密钥。这两个密钥是数学相关，用某用户密钥加密后所得的信息，只能用该用户的解密密钥才能解密。如果知道了其中一个，并不能计算出另外一个。因此如果公开了一对密钥中的一个，并不会危害到另外一个的秘密性质。私钥是密钥对所有者持有，不可公布，公钥是密钥对持有者公布给他人的，因此称公开的密钥为公钥；不公开的密钥为私钥。
如果加密密钥是公开的，这用于客户给私钥所有者上传加密的数据，这被称作为公开密钥加密，用公钥加密的数据只能使用私钥解密，私钥用来解密公钥加密的数据。常见的公钥加密算法有：RSA、ElGamal、背包算法、Rabin(RSA的特例)、椭圆曲线加密算法(英语：Elliptic Curve Cryptography，ECC)。使用最广泛的是RSA算法(由发明者Rivest、Shmir和Adleman姓氏首字母缩写而来)，是著名的公开金钥加密算法。
如果解密密钥是公开的，用私钥加密的信息，可以用公钥对其解密，用于客户验证持有私钥一方发布的数据或文件是完整准确的，接收者由此可知这条信息确实来自于拥有私钥的某人，这被称作数字签名，公钥的形式就是数字证书。例如，从网上下载的安装程序，一般都带有程序制作者的数字签名，可以证明该程序的确是该作者(公司)发布的而不是第三方伪造的且未被篡改过(身份认证/验证)。
2、数字签名及其验证
图2是数字签名和验证的示意图。如图2所示，发送方使用私钥对需要传输文本的摘要进行加密，得到的密文即被称为该次传输过程的数字签名(简称为“签名”)，其中，传输文本的摘要是对需要传输的文本做HASH计算例如SHA1和SHA2后得到的。
接收方，即收到数据的一方拿到该传输文本后，需要确认该文本是否就是发送方所发出的内容，中途是否曾经被篡改。因此接收方可以拿自己持有的公钥对签名进行解密(密钥对中的一种密钥加密的数据必定能使用另一种密钥解密)，得到了传输文本的摘 要，然后使用与发送方同样的HASH算法计算摘要值，再与解密得到的摘要做对比，如果发现二者完全一致，则说明传输文本没有被篡改过。
在签名的过程中，接收方需要自己保管好公钥，但是每一个发送方都有一个公钥，那么接收方需要保存非常多的公钥，这根本就管理不过来。并且本地保存的公钥有可能被篡改替换，无从发现。那么为了解决这个问题，可以由一个统一的证书管理机构来管理所有发送方的公钥，并对这些公钥进行认证和加密。这个机构也就是我们常说的证书代理机构(Certificate Agency，CA)。认证加密后的公钥，即是证书，又称为CA证书，证书中包含了很多信息，最重要的是申请者的公钥。CA机构在给公钥加密时，用的是一个统一的密钥对，在加密公钥时，用的是其中的私钥。这样，申请者拿到证书后，在发送数据时，用自己的私钥生成签名，将签名、证书和发送内容一起发给对方，对方拿到了证书后，需要对证书解密以获取到证书中的公钥，解密需要用到CA机构的“统一密钥对”中的公钥，这个公钥也就是我们常说的CA根证书，通常需要我们到证书颁发机构去下载并安装到相应的收取数据的客户端，如浏览器上面。这个公钥只需要安装一次。有了这个公钥之后，就可以解密证书，拿到发送方的公钥，然后解密发送方发过来的签名，获取摘要，重新计算摘要，作对比，以验证数据内容的完整性。
3、基于身份的密码机制
基于身份的密码机制(Identity-Based Cryptography，IBC)包括基于身份的签名技术(Identity Based Signature，IBS)和基于身份的加密技术(Identity Based Encryption，IBE)。每个用户拥有自己的公私钥对，其中公钥为有意义的字符串(身份)，例如Email地址、电话号码等；用户的私钥由私钥生成中心(Private Key Generator，PKG)根据用户ID和PKG的主私钥生成，签名过程中无需PKG参与，签名验证只需要签名、消息、身份和主公钥。传统公钥基础设施(Public Key Infrastructure，PKI)机制与IBC的不同在于，PKI中用户拥有一对不同的公私钥，公钥为随机字符串，需要证书中心对公钥签名来确认某个公钥是属于某个用户的，签名或加密过程中需要验证证书。
如图3所示的基于身份的密码机制的示意图，用户Alice和Bob分别拥有自己的公私钥对，PKG根据Alice的IDAlice和PKG的主私钥生成Alice的私钥SKAlice，Alice使用其私钥对需要传输的消息进行签名，签名过程中无需PKG参与，Bob对Alice发送的签名进行验证时只需要签名、消息、IDAlice和主公钥GPK。
4、迪菲-赫尔曼密钥交换(Diffie-Hellman Key Exchange)
如图4所示，迪菲-赫尔曼通过公共信道交换一个信息，就可以创建一个可以用于在公共信道上安全通信的共享秘密(shared secret)。最早提出的这个协议基于用一个素数p的整数模n乘法群以及其原根g，以下解释它的过程(包括算法的数学部分)：
(1)Alice和Bob写上一个有限循环群G和它的一个生成元生成元g。
这通常在协议开始很久以前就已经规定好；其中g是公开的，并可以被所有的攻击者看到。
(2)Alice选择一个随机自然数a，并且将A＝g^{a}mod p发送给Bob。
(3)Bob选择一个随机自然数b，并且将B＝g^{b}mod p发送给Alice。
(4)Alice计算B^{a}mod p。
(5)Bob计算A^{b}mod p。
(6)Alice和Bob就同时协商出群元素K＝g^{ab}mod p，它可以被用作共享秘密。
其中，mod表示取模运算。
基于上面的相关描述，下面介绍现有技术中终端设备和服务器进行双向认证的两种方式。
图5是传统的基于实体SIM卡的双向认证过程的示意图。如图5所示，在现有的移动通信网络(3G网络/LTE网络)中，终端设备和服务器是基于预共享密钥的双向认证。预共享密钥是将对称密钥预先放置在终端的SIM卡中和核心网的归属用户服务器(Home Subscriber Server，HSS)中。在认证时，采用的协议是3GPP TS 33.401中所描述的认证和密钥协议(Authentication and Key Agreement，AKA)，在认证时需要用到的Credential是IMSI和预共享密钥，而这些信息是储存在SIM卡中的。
传统的信任状配置过程中，运营商需要向SIM卡生产商提供输入和定制文件，包括IMSI号码(IMSI number)，用户和运营商档案(Profile)。SIM卡生产商在收到这些资料后，为每个IMSI number生成一个对应的密钥，并将IMSI number，对应的密钥Ki写入到实体的SIM卡中。并将IMSI number、密钥、及其对应关系保存到实体的光盘中。然后将SIM卡和CD一同返回给运营商。运营商将获取到的IMSI number、密钥、及其对应关系保存到其HSS中。然后在用户签约时，将SIM卡发放给用户。用户将SIM卡插入手机后，便可以利用SIM中储存的IMSI number和预共享密钥与运营商网络相互认证，从而接入和使用网络。
这种基于SIM卡的双向认证方式的主要缺点是：整个过程都是线下进行的，链条长，环节多，周期长，运输和维护成本高；Credential通过实体的SIM卡发放给用户，用户更改运营商需更换实体SIM卡；物联网设备由于其自身的特点，在很多情况下，使用实体的SIM卡是不可取的，例如工业物联网设备需要工作在极端的环境里，高温，潮湿，灰尘，剧烈震动等都会使SIM卡接触不良，或极易损坏；而且由于物联网设备的数量巨大，一担需要更换SIM卡，工作量就十分巨大；另外物联网设备通常都是一些传感器等小型设备，使用传统的SIM卡将限制物联网设备的空间和设计。
图6是基于eUICC的双向认证过程的示意图。现有的双向认证过程最主要的就是GSMA制定的远程配置标准，基于该标准进行远程配置过程从而实现终端设备与服务器之间的双向认证。图6示出了全球移动通信系统协会(Global System for Mobile Communications Alliance，GSMA)制定的基于嵌入式通用集成电路卡(Embedded Universal Integrated Circuit Card，eUICC)的远程配置的过程。其中，订阅管理器数据准备(Subscription Manager Data Preparation，SM-DP)的主要作用是负责安全的执行平台管理的命令和安全的传输文本管理的命令，订阅管理器安全路由(Subscription Manager Secure Routing，SM-SR)的主要作用是负责安全的执行平台管理的命令和安全的传输文本管理的命令。基于这种的架构的远程配置的过程如下：证书颁发机构(Certificate Issuer，CI)向SM-DP和SM-SR颁发证书。CI为eUICC的生产商(eUICC Manufacturer，EUM)产生一系列的证书。EUM在生产eUICC时将证书置入eUICC内。eUICC需要远程获取运营商(Mobile Network Operator，MNO)提供的Credential时，使用其证书和SM-SR、SM-DP相互认证，然后建立安全通道。SM-DP和SM-SR一般由MNO部署，因此和MNO之间有安全通道。然后MNO的Credential经由SM-DP和SM-SR下载到eUICC。获得MNO提供的Credential后，eUICC之后便可以使用这个Credential直接接入和使用MNO的网络。
这种基于现有的GSMA规范的双向认证方式由于需要使用初始的Credential和运营商相互认证并建立安全通道，因此要求eUICC必须内置一个initial credential(证书或者pre-shared secret)，但是在物联网的场景下，由于厂商不知道最终物联网设备会被用在哪里用在那个运营商的网络里，因此有极大的可能性，物联网设备在出厂并未配置任何初始的Credential。因此，现有的技术和规范无法满足这种没有初始Credential的物联网设备的远程获取运营商Credential的需求。要使用这种技术，运营商需要部署SM-DP和SM-SR Server，并需向CI获取证书，这将增加运营商的运营和维护成本。
为便于区分和理解，本申请中将“基于”和“根据”区分使用，“基于”用于表示触发条件，“根据”表示用于计算的参量。为了简洁，后文中省略对相同或者相似情况的说明。
图7是本申请实施例的移动网络的认证方法的示意架构图。在图7中，最左边是两个第二终端设备，中间是第一终端设备，最右端是运营商网络的用于网络认证的配置服务器(Provision Server)，后面简称为服务器。这里示出了两个第二终端设备，但是实际应用时，该第二终端设备可以有一个也可以为多个，这些第二终端设备都不具备用于与运营商网络进行认证的初始的信任状。因此，本申请实施例提出，这些第二终端设备可以通过第一终端设备接入蜂窝网络，也可以直接连接蜂窝网络。图中的服务器可以是一个实体，该实体可以为HSS(即该服务器功能可以由HSS实现)，或者HSS和服务器也可以是两个分开的实体。如果是两个分开的实体，这里假设HSS和服务器之间存在有安全通道(因为他们同属于运营商网络，属于同一个安全域)。并且，这里假设第二终端设备可以和第一终端设备通过其他短距离方式建立安全通道，例如常见的安全通道建立方法有使用蓝牙配对技术，同一个无线保真(Wireless Fidelity，WiFi)局域网的加密访问控制技术，或者使用有线等方式。
其中，该第二终端设备可以为不具有运营商网络预发放的信任状(例如共享密钥和用于标识签约用户的身份标识以及其他相关信息)的终端设备，例如图1中的终端设备30，该第一终端设备可以为已持有共享密钥的伙伴设备例如图1中的终端设备20。在本申请实施例中，该第二终端设备可以通过与其配对的第一终端设备，从配置服务器例如服务器50获取用于与该配置服务器进行认证的信任状。
需要说明的是，在图8至图13示出的本申请实施例的移动网络的认证方法的示意性流程图中，终端与运营商网络，或称为核心网(Core Network，CN)(例如，核心网认证实体、配置服务器)之间的通信可以通过接入网(Access Network，AN)(例如基站)来转发。以下，对相同的情况不再作特别说明。
应理解，图8至图13示出的本申请实施例的移动网络的认证方法可以应用于图1示出的应用场景，也可以应用于其他场景，下面以图1所示的应用场景为例进行说明。图8示出了第一终端设备、第二终端设备和服务器。
还应理解，本申请实施例中，可以有至少一个第二终端设备通过该第一终端设备获取用于与服务器进行认证的共享密钥，从而接入运营商网络。下面仅是以一个第二终端设备为例进行说明，该第二终端设备通过该第一终端设备，可以从服务器获取用于进行移动网络认证的信任状，即与服务器之间的共享密钥和用于标识签约用户的身份标识，但本申请不限于此。
图8是本申请实施例的移动网络的认证方法的流程交互图。如图8所示，该移动网 络的认证方法包括：
101，第二终端设备根据第一随机数确定该第二终端设备的迪菲赫尔曼(Diffie-Hellman，DH)公钥。
其中，该第二终端设备为未持有共享密钥的设备。也就是说，该第二终端设备不具有运营商预先发放的信任状，无法实现于服务器之间的认证从而接入运营商网络。
具体地说，通过第一终端设备，第二终端设备与服务器之间可以采用迪菲赫尔曼方式协商共享密钥。即利用第一终端设备具有运营商的信任状的条件，根据DH密钥交换的方法，与服务器协商出用于网络认证的共享密钥。
例如，第二终端设备可以产生一个随机数例如RAND 1，该第二终端设备根据RAND1计算该第二终端设备的DH公钥，这里记作A，A＝gRAND 1mod p，其中，p为一个素数，g是一个有限循环群G的生成元，g和p可以提前公开，也可以以明文形式发送。mod为取余运算。
102，第二终端设备向第一终端设备发送第二终端设备的DH公钥和第二终端设备的第一ID。
其中，该第一终端设备为已持有共享密钥的设备。
进一步地，第二终端设备可以与该第一终端设备建立安全通道，例如蓝牙配对技术，WiFi局域网的加密访问控制技术或有线等短距离通信方式建立安全通道，并在安全通道内将自己的第一ID和生成的公钥发送给第一终端设备。
103，第一终端设备接收第二终端设备发送的DH公钥和第一ID。
第一终端设备在安全通道内接收第二终端设备发送的第二终端设备的DH公钥例如A和第二终端设备的第一ID。
应理解，如果多个第二终端设备需要同时通过该第一终端设备从服务器获取用于与服务器进行认证的信任状时，第一终端设备这时会收到多个第二终端设备中的每个第二终端设备的第一ID和每个第二终端设备的DH公钥。
104，第一终端设备向服务器发送第一消息。
其中，该第一消息包括第二终端设备的DH公钥和第二终端设备的第一ID。可选地，该第一消息中还可以包括指示信息，该指示信息用于指示该第一消息用于请求第二终端设备的共享密钥和第二终端设备的第二ID，该第二ID用于标识签约用户。
具体地说，该指示信息用来表示该第一消息的用途是为了给第二终端设备设备请求用于为第二终端设备请求第二终端设备的信任状，该信任状可以包括第二终端设备与服务器之间的共享密钥，以及服务器为第二终端设备生成的用于标识签约用户的第二ID，该第二ID例如可以是IMSI。该指示信息例如可以为一个标志位，该标志位可以用不同值表示是为个一个第二终端设备请求运营商颁发的信任状，还是为多个第二终端设备请求运营商颁发的信任状。当第一终端设备接收到第二终端设备发送的第二终端设备的第一ID和第二终端设备的DH公钥时，第一终端设备可以在向服务器发送的第一消息中添加该指示信息。
应理解，如果第一终端设备接收到多个第二终端设备中的每个第二终端设备发送的每个第二终端设备的第一ID和每个第二终端设备的DH公钥，这时，第一终端设备需要将每个第二终端设备的第一ID和每个第二终端设备的DH公钥，发送给服务器。
这时，该指示信息可以指示该第一消息是为多个第二终端设备请求用于与服务器进 行认证的共享秘钥和第二ID。
105，服务器接收第一终端设备发送的第一消息。
服务器接收第一终端设备发送的第一消息后，就可以从该第一消息中获取第二终端设备的第二ID和第二终端设备的DH公钥，以生成用于与第二终端设备进行认证的共享密钥。
106，服务器根据第二随机数确定该服务器的DH公钥，并为第二终端设备生成第二终端设备的第二ID。
具体地说，服务器确定该服务器的DH公钥，从而可以根据用于生成的自己公钥的第二随机数和接收到的第二终端设备的DH公钥，生成用于与第二终端设备进行认证的第二终端设备的第一共享秘钥。并且，服务器可以将自已的公钥传递给第二终端设备，以使得第二终端设备可以根据服务器的DH公钥和第二终端设备用于生成自己公钥的第一随机数，确定用于与服务器进行认证的相同的第一共享密钥。
举例来说，服务器可以生成一个随机数例如RAND 2，服务器根据RAND 2计算服务器的DH公钥，这里记作B，B＝gRAND 2mod p，其中，p为一个素数，g是一个有限循环群G的生成元，这里的g和p可以是协议中预先约定的，且终端设备与服务器共同维护的。
其中，该第二ID用于标识签约用户，例如该第二ID可以为运营商为用户分配的IMSI号码(IMSI number)。或者说该第二ID为运营商为第二终端设备生成的用于访问该运营商的ID。应理解，该第二ID中，除了包括用于标识签约用户的ID之外，还可以包括其他ID的信息。
应理解，如果服务器接收到的该第一消息中包括多个第二终端设备的第二ID和多个第二终端设备的DH公钥，该服务器会为多个第二终端设备中的每个第二终端设备生成每个第二终端设备的第二ID，从而使每个第二终端设备使用每个第二终端设备的第二ID，与服务器之间进行认证。
107，服务器根据第二终端设备的DH公钥，和该服务器的第二随机数，确定用于与第二终端设备进行认证的第二终端设备的第一共享密钥。
具体地说，服务器接收第一终端设备发送的第一消息后，可以根据该第一消息中的第二终端设备的DH公钥，以及该服务器的第二随机数，确定用于与该第二终端设备进行认证的第二终端设备的第一共享秘钥(也可以成为根密钥)。
例如，服务器根据收到的第二终端设备的DH公钥即A＝gRAND 1mod p，和服务器生成DH公钥即B＝gRAND 2mod p所使用的随机数RAND 2，生成用于与第二终端设备之间进行认证的共享密钥，即KD＝ARAND 2mod p。
108，服务器向第一终端设备发送第二消息。
其中，该第二消息包括服务器的DH公钥和第二终端设备的第二ID。
如果存在多个第二终端设备需要同时通过该第一终端设备从服务器获取用于与服务器进行认证的信任状时，这时，该第二消息中包括服务器为多个第二终端设备中的每个第二终端设备生成的每个第二终端设备的第二ID，以及服务器的DH公钥。
109，第一终端设备接收该服务器基于第一消息发送的第二消息。
110，第一终端设备向第二终端设备发送第二终端设备的第二ID和服务器的DH公钥。
该第一终端设备接收服务器发送的第二消息后，可以将该第一消息中的第二终端设备的第二ID和服务器的DH公钥，发送给第二终端设备。
如果该第二消息中包括多个第二终端设备中每个第二终端设备的第二ID，那么第一终端设备会向每个第二终端设备分别发送每个第二终端设备的第二ID和服务器的DH公钥，从而每个第二终端设备可以接收到自己的第二ID和服务器的DH公钥；或者，该第一终端设备也可以向每个第二终端设备直接发送该第二消息中的所有第二终端设备的第二ID和服务器的DH公钥，从而每个第二终端设备在接收到所有第二终端设备的第二ID后，在其中自行确定属于自己的第二ID。
111，第二终端设备接收第一终端设备发送的第二终端设备的第二ID和服务器的DH公钥。
112，第二终端设备根据第二终端设备的第一随机数，和服务器的DH公钥，确定第一共享密钥。
具体地说，第二终端设备接收第一终端设备发送的服务器的DH公钥和第二终端设备的第二ID后，可以根据该第一消息中的服务器的DH公钥，以及第二终端设备生成自己的DH公钥时使用的第一随机数，确定用于与该服务器进行认证的第二终端设备的第一共享秘钥。
例如，第二终端设备根据收到的服务器的DH公钥，即B＝gRAND 2mod p，和第二终端设备生成DH公钥即A＝gRAND 1mod p时使用的随机数RAND 1，生成用于与服务器之间进行认证的共享密钥，即KD＝BRAND 1mod p。
应理解，如果是多个第二终端设备通过第一终端设备从服务器获取用于网络认证的共享秘钥和第二ID，由于不同的第二终端设备各自的公钥是不同的，因此服务器根据该服务器的第二随机数和不同第二终端设备的DH公钥确定的用于与不同第二终端设备进行认证的共享秘钥，也是不同的，另外，服务器为不同的第二终端设备生成的第二ID也不同。也就是说，任意一个第二终端设备与服务器之间进行认证时，所使用的共享秘钥和第二ID都是唯一的。
113，第二终端设备根据第二终端设备的第一共享密钥和第二ID，与服务器进行相互认证。
可以看出，服务器在107中确定共享秘钥即KD＝ARAND 2mod p，与112中第二终端设备确定的共享秘钥KD＝BRAND 1mod p是相同的，即K＝Ab mod p＝(ga mod p)b mod p＝gab mod p＝(gb mod p)a＝Ba mod p。并且，该共享密钥仅该第二终端设备与服务器知道，因此，该第二终端设备可以使用该共享秘钥和该第二终端设备的第二ID，与服务器之间进行认证从而接入运营商网络。
因此，本申请实施例中，不具有运营商预先发放的信任状的终端设备，可以通过其他已持有信任状的终端设备，基于DH密钥交换的方式从服务器获取用于与运营商网络进行认证的共享密钥从而能够接入网络。
应理解，第二终端设备与服务器之间的认证，也可以称为第二终端设备与运营商网络(或称核心网、网络等)之间的认证，服务器的密钥也可以称网络侧的公钥。不同运营商网络具有不同的ID，且任意一个运营商网络下的多个服务器也都具有各自的ID或者也可以多个服务器共用一个ID，每个服务器用于为其所属的网络运营商提供服务，例如实现认证相关工作等。
根据上面描述的移动网络的认证方法，第二终端设备在没有运营商预发放的信任状例如共享秘钥和用于标识签约用户的ID时，能够通过已签约的第一终端设备，根据DH密钥交换的方式，从服务器获取用于与运营商网络进行认证的信任状。
第一终端设备在向服务器发送第一消息即执行104之前，和/或服务器向第一终端设备发送第二消息即执108之前，还可以对该第一消息中的全部或部分内容，和/或第二消息中的全部或部分内容，进行一定的处理以提高传输过程的安全性。本申请实施例描述以下三种方式。
方式一
对于第一消息，在第一终端设备向服务器发送第一消息即104之前，该方法还可以包括1401，这时104可以由1042替代。
1401，第一终端设备根据第二共享密钥，为该第一消息生成该第一消息的消息验证码(Message Authentication Code，MAC)。
1042，第一终端设备向服务器发送第一消息和该第一消息的MAC。
其中，该第二共享密钥用于所述第一终端设备与所述服务器之间的认证。也就是说，该第二共享密钥是第一终端设备用于与服务器进行验证的共享密钥(也可以称为会话密钥)。
具体地说，为了证实第一消息来自可靠源点且未被篡改过，第一终端设备向服务器发送第一消息时，可以根据第二共享密钥为该第一消息生成一个消息验证码MAC，例如MAC1K，如果服务器接收到该第一消息后对该MAC1K验证通过，那么服务器才会信任该第一消息。
这时，105可以由1051替代，且该方法还包括1052。
1051，服务器接收第一终端设备发送的第一消息，和第一终端设备根据第二共享密钥为第一消息生成的第一消息的消息验证码MAC。
1052，服务器根据该第二共享密钥，对第一消息的MAC进行验证。
具体地说，服务器根据第二共享密钥对第一消息的MAC进行验证，如果服务器对该第一消息的MAC验证通过，说明该第一消息来自可靠源点且未被篡改过，那么服务器接受该第一消息，并可以执行106。
对于第二消息，在服务器向第一终端设备发送第二消息，即执行108之前，该方法还包括1081，这时108可以由1082替代。
1081，服务器根据第二共享密钥，为第二消息生成该第二消息的MAC。
1082，服务器向第一终端设备发送第二消息和该第二消息的MAC。
其中该第二共享密钥用于所述第一终端设备与所述服务器之间的认证。
具体地说，为了证实第二消息来自可靠源点且未被篡改过，服务器向第一终端设备发送第二消息时，可以根据第二共享密钥为该第二消息生成一个消息验证码MAC，例如MAC2K，如果第一终端设备接收到该MAC2K的验证通过，那么服务器才会信任该第二消息，并将该第二消息继续发送给第二终端设备。
这时，109可以由1091替代，且该方法还包括1092。
1091，第一终端设备接收服务器发送的第二消息，和服务器根据第二共享密钥为第二消息生成的该第二消息的MAC。
1092，第一终端设备根据第二共享密钥，对该第二消息的MAC进行验证。
具体地说，第一终端设备根据第二共享密钥对第二消息的MAC进行验证，如果第一终端设备对该第二消息的MAC验证通过，说明该第二消息来自可靠源点且未被篡改过，那么第一终端设备接受该第一消息，并执行110。
因此，在方式一中，服务器和终端设备在信息交互的过程中，通过对消息进行消息验证，能够确保消息的来源可靠且传输过程仲未被篡改，提高了密钥交换过程的安全性。
方式二
在服务器向第一终端设备第二消息，即执行108之前，该方法还可以包括1083，这时108可以由1084替代。
1083，服务器对第二消息进行签名。
1084，服务器向第一终端设备发送第二消息、服务器对第二消息签名后得到的签名消息、和与该签名消息对应的验证消息。
具体而言，为了提高第二消息传输过程的安全性，服务器用自己的私钥对该第二消息进行签名，并向第一终端设备发送第二消息、服务器对第二消息签名后得到的签名消息、和该签名消息对应的验证消息，从而在即使第一终端设备被攻破或控制的情况下，也无法发起中间人攻击。
应理解，方式一和方式二可以同时执行，即服务器可以同时对该第二消息进行签名并为该第二消息生成消息验证码，但是为了节省信令，如果执行了方式二，那么方式一也可以不再执行。
这时，109至111可以由1111至1113替代，且该方法还可以包括1114。
1111，第一终端设备接收服务器发送的第二消息、服务器对第二消息签名后得到的签名消息和与该签名消息对应的验证信息。
1112，第一终端设备向第二终端设备发述第二消息、该签名消息和该验证信息。
1113，第二终端设备接收第一终端设备发送的第二消息、服务器对所述第二消息签名后得到的签名消息、和与该签名消息对应的验证信息。
1114，第二终端设备根据第二消息、该签名消息和该验证信息，对第二消息进行验证。
具体而言，第二终端设备根据第二消息、该签名消息和该验证信息，对第二消息进行验证。如果第二终端设备对第二消息验证通过，说明该第二消息的真实可靠第来源于服务器且该第二信息的内容完整，那么第二终端设备接受该第二消息，并执行112。
可选地，该验证信息可以包括服务器的证书或服务器的ID。
具体地说，如果服务器采用的是基于证书的密钥机制，那么该验证信息可以为该服务器的证书，即与服务器加密第二消息所使用的私钥相对应的证书，从而第二终端设备能够根据该证书对该签名进行验证；如果服务器采用的是基于身份的密钥体制，那么该验证信息可以为服务器的ID，从而第二终端设备能够根据该服务器的ID对该签名进行验证。
因此，该方式二中，服务器可以采用非对称钥体制(例如基于证书的密码机制或基于身份的密码机制)，通过对待发送的服务器的DH公钥以及为终端设备生成的用于标识签约用户的标识进行签名，从而提高了密钥交换过程的安全性，在即使终端设备被攻破控制的情况下，也无法发起中间人攻击。
方式三
对于第一消息，在第一终端设备向服务器发送第一消息即104之前，该方法还可以包括1403。
1403，第一终端设备根据第二共享密钥，对第二终端设备的DH公钥和第二终端设备的第一ID进行加密。
其中，该第二共享密钥用于所述第一终端设备与所述服务器之间的认证。也就是说，该第二共享密钥是第一终端设备用于与服务器进行验证的共享密钥。
这时，在104中第一终端设备向服务器发送的第一消息中的第二终端设备的DH公钥和第二终端设备的第一ID，是第一终端设备用第二共享密钥加密过的，且105中服务器从第一终端设备接收的第一消息中的第二终端设备的DH公钥和第二终端设备的第一ID，是经过第一终端设备加密的。
这时，在106之前，该方法还包括1061，且106可以由1062替换。
1061，服务器根据第二共享密钥，对加密后的所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID进行解密。
1062，服务器根据解密后的第二终端设备的DH公钥，和服务器的DH公钥，确定用于与第二终端设备进行认证的第二终端设备的第一共享密钥，并为第二终端设备生成第二终端设备的第二ID。
对于第二消息，在服务器向第一终端设备发送第二消息即108之前，该方法还可以包括1081。
1081，服务器根据第二共享密钥，对第二终端设备的DH公钥和第二终端设备的第二ID进行加密。
其中该第二共享密钥用于所述第一终端设备与所述服务器之间的认证。
这时，在108中服务器向第一终端设备发送的第一消息中的第二终端设备的DH公钥和第二终端设备的第二ID，是服务器使用第二共享密钥加密后的，且109中第一终端设备从服务器接收的第二消息中的第二终端设备的第二ID，和服务器的DH公钥，是经过服务器加密的。
这时，在110之前，该方法还包括1101，且110可以有1102替换。
1101，第一终端设备根据第二共享密钥，对加密后的第二终端设备的第二ID和服务器的DH公钥进行解密。
1102，第一终端设备向第二终端设备发送解密后的第二终端设备的第二ID和服务器的DH公钥。
因此，在方式三中，对服务器和终端设备在信息交互的过程中，通过对消息进行加密，提高了服务器和终端设备的密钥交换过程的安全性。
不具有运营商网络预发放的信任状的第二终端设备，在根据上述的移动网络的认证方法，获取了用于接入运营商网络的信任状后，为了确保服务器确定的第一共享密钥与第二终端设备确定的第一共享密钥是一致的，第二终端设备与服务器之间还可以对该第一共享密钥进行验证。可选地，如图9所示的本申请实施例的验证共享秘钥的流程交互图，在113之前，该方法还可以包括114至118。
114，第二终端设备根据第一共享密钥，为第二终端设备的第二ID生成消息验证码MAC。
115，第二终端设备向服务器发送第二ID和该第二ID的MAC。
116，服务器接收该第二ID和该第二ID的MAC，并根据第一共享密钥，对第二终端设备的第二ID的MAC进行验证。如果验证成功，则执行117。
117，服务器向第二终端设备发送配置完成消息，和服务器为该配置完成消息生成的配置完成消息的MAC。
118，第二终端设备接收服务器发送的配置完成消息和该配置完成消息的MAC，并根据第一共享密钥，对配置完成消息的MAC进行验证。如果验证成功，可以执行113。
因此，第二终端设备与服务器之间通过进行消息认证，能够确保服务器确定的第一共享密钥与第二终端设备确定的第一共享密钥是一致的。
下面结合图10和图11，详细地描述本申请实施例的移动网络的认证方法。图10是本申请一个实施例的移动网络的认证方法，图10中示出了一个第二终端设备通过第一终端设备获取运营商的信任状的过程。该方法包括：
1001，第一终端设备(Companion UE)使用其3GPP Credential与运营商网络进行相互认证，例如基于AKA(Authentication and Key Agreement)协议进行认证，本申请实施例对认证方式不做限定，例如Companion UE还可以通过未来5G网络中的认证方式与运营商网络进行相互认证，并产生会话密钥K。
1002，第二终端设备例如物联网设备(IoT Device)产生随机数例如RAND 1，IoT Device利用RAND 1计算其DH公钥A＝gRAND 1mod p，其中p为一个素数，g是一个有限循环群G的生成元，g和p可以提前公开，也可以以明文形式发送。
1003，IoT Device与Companion UE建立安全通道，并在安全通道内将自己的ID(Device ID)和生成的DH公钥(A)发送给Companion UE，其发送消息格式例如为(Device ID，A)。
1004，Companion UE收到这条消息后，添加一个标志位(PType)，这个标志位用来表示这个消息的用途是为了给IoT Device请求3GPP Credential。其中，PType可以用特定值(例如1)表示是为个单个设备请求。然后Companion UE使用密钥K为整条消息产生消息验证码MAC1K，然后将消息发送给服务器(Provision Server)，其发送消息格式为(Ptype，Device ID，A，MAC1K)。该服务器可以为HSS。
可选地，Companion UE还可以对向Provision Server发送的该消息进行加密，例如该消息格式为(Ptype，m1，MAC1K)，其中m1为用密钥K加密后的Device ID和A的密文，即m1＝En(Device ID，A，K)。
1005，Provision Server在收到消息后，首先验证其MAC1K。验证通过后，产生网络侧随机数例如RAND 2，从而生成网络侧的DH公钥B＝gRAND 2mod p，并利用收到IoT Device的DH公钥即A，生成共享密钥KD，KD＝ARAND 2mod p，同时为IoT Device产生用于标识签约用户的接入标识(Access Identity，简称为Access ID)。
如果Provision Server收到的消息为加密后的消息即(Ptype，m1，MAC1K)，那么还需要根据K对其进行解密，以获取Device ID和A。
1006，Provision Server发送消息给Companion UE，该消息格式例如为(Access ID，B，A，MAC2K)，其中，Access ID为运营商为IoT Device生成的访问运营商的ID，也就是运营商标识签约用户的ID。B为其DH公钥，A为其返回的IoT Device的DH公钥，MAC2K为其使用密钥K为整条消息产生消息验证码。
可选地，Provision Server还可以对该消息进行签名，这时，Provision Server发送消 息给Companion UE的消息格式例如为(Access ID，B，A，MAC2K，SigCN)，其中SigCN为其使用其私钥对该消息的签名。
可选地，Provision Server还可以对向Companion UE发送的该消息进行加密，这时Provision Server发送的消息格式例如为(m2，MAC2K)，其中m2为用密钥K加密后的Access ID、B和A的密文，即m2＝En(Access ID，A，B，A，K)。
1007，Companion UE收到此消息后，验证MAC2K。
如果Companion UE收到的消息为加密后的消息即(m2，MAC2K)，那么Companion UE还需要根据K对其进行解密，以获取Access ID、B和A。
1008，Companion UE在完成验证MAC2K后，将Access ID和网络侧的DH公钥B在安全通道内发送给IoT Device，其该消息格式例如为(Access ID，B)。
如果该消息中还包括Provision Server对该消息的签名，那么Companion UE将该签名以及该签名对应的验证信息(例如服务器的证书或者服务器的ID)也发送给IoT Device。
1009，IoT Device收到服务器的DH公钥B后生成共享密钥KD＝BRAND 1mod p，并保存Access ID。
如果IoT Device同时还收到服务器为该消息的签名和该签名对应的验证信息例如为(Access ID，B，SigCN)，那么IoT Device根据该验证信息对该签名SigCN进行验证，验证成功时可以根据服务器的DH公钥B生成共享秘钥KD。
1010，IoT Device将Access ID发送给Provision Server，并使用密钥KD为整条消息产生消息验证码MAC3KD，该消息格式例如为(Access ID，MAC3KD)。
1011，Provision Server收到此消息后，验证MAC3KD。
1012，Provision Server验证完MAC3KD后，发送配置完成消息(Provision Complete)给IoT device，并使用共享密钥KD为整条消息产生消息验证码MAC4KD，该消息格式例如为(配置完成，MAC4KD)即(Provision Complete，MAC4KD)。
1013，IoT Device收到此消息后，验证MAC4KD，验证通过后，整个过程结束。
其中1010至1013为可选的，其主要目的为验证IoT Device的产生的密钥与服务器所产生的密钥是否一致，当确认该密钥KD一致之后，IoT Device可以使用共享密钥KD与运营商网络进行之间进行认证，从而接入网络。
上面描述的是一个IoT Device通过Companion UE获取运营商的信任状的过程，下面结合图11所示的本申请实施例的移动网络的认证方法的流程交互图，来描述多个IoT Device通过Companion UE获取运营商的信任状的过程，这里以两个IoT Device为例进行描述。图11中示出的方法可以用于多个第二终端设备通过第一终端设备获取运营商的信任状。该方法包括：
1101，第一终端设备(Companion UE)使用其3GPP Credential与运营商网络进行相互认证，例如基于AKA(Authentication and Key Agreement)协议进行认证，本申请实施例对认证方式不做限定，例如Companion UE还可以通过未来5G网络中的认证方式与运营商网络进行相互认证，并产生会话密钥K。
1102，IoT Devices分别产生随机数，并利用该随机数产生其DH公钥，其中：
1102(a)，一个终端设备例如物联网设备1(IoT Device 1)产生随机数1例如RAND1，并利用RAND 1计算其DH公钥A1＝gRAND 1mod p；
1102(b)，另一个终端设备例如物联网设备2(IoT Device 2)产生随机数2例如RAND 2，并利用RAND 2计算其DH公钥A2＝gRAND 2mod p。
1103，IoT Devices将自己的ID，生成的DH公钥，在安全通道内发送给Companion UE，其中：
1103(a)，IoT Device 1发送的消息为(Device ID1，A1)，其中Device ID1为IoT Device 1的ID，A1为其DH公钥；
1103(b)，IoT Device 2发送的消息为(Device ID2，A2)，其中Device ID2为IoT Device 2的ID，A2为其DH公钥。
1104，Companion UE收到消息后，添加一个标志位PType，这个标志位用来表示这个消息的用途是为了给IoT Device请求3GPP Credential。这里PType可以用特定值(例如0)表示是为个多个设备请求。然后Companion UE使用密钥K为整条消息产生消息验证码MAC1K，然后将消息发送给Provision Server，其发送消息格式例如为(Ptype，Device ID1，Device ID2，A1，A2，MAC1K)。
可选地，这时Companion UE还可以对向Provision Server发送的该消息进行加密，Companion UE向Provision Server发送的消息这时例如为(Ptype，m1，MAC1K)，其中m1为用密钥K加密后的Device ID和A的密文，即m1＝En(Device ID 1，Device ID 2，A1，A2，K)。
1105，Provision Server在收到消息后，首先验证其MAC1K。验证通过后，产生网络侧随机数RAND 3，生成网络侧的DH公钥B＝gRAND 3mod p，并利用收到IoT Device的DH公钥生成共享密钥，即KD1＝A1RAND 3mod p和KD2＝A2RAND 3mod p，同时为IoT Device1和IoT Device2分别产生Access ID 1和Access ID 2。
如果Provision Server收到的消息为加密后的消息即(Ptype，m1，MAC1K)，那么还需要根据K对其进行解密，以获取Device ID 1，Device ID 2，A1和A2。
1106，Provision Server发送消息给Companion UE，该消息例如(Access ID 1，Access ID 2，B，A1，A2，MAC2K)，其中Access ID 1和Access ID 2为运营商分别为IoT Device1和IoT Device 2生成的用于标识签约用户的ID，B为其DH公钥，A1和A2分别为其返回的IoT Device 1和IoT Device 2的DH公钥，MAC2K为其使用密钥K为整条消息产生消息验证码。
可选地，Provision Server还可以对该消息进行签名，这时，HSS/Provision Server发送消息给Companion UE的消息例如为(Access ID 1，B，A1，Sig1CN，Access ID 2，B，A2，Sig2CN，MAC2K)，其中Sig1CN是对(Access ID1，B，A1)的签名，Sig2CN是对(Access ID2，B，A2)的签名。
可选地，Provision Server还可以对向Companion UE发送的该消息进行加密，例如该消息格式例如为(m2，MAC2K)，其中m2为用密钥K加密后的Access ID 1、Access ID2、B、A1、A2的密文，即m2＝En(Access ID 1，Access ID 2，B，A1，A2，K)。
1107，Companion UE收到此消息后，验证MAC2K。
如果Companion UE收到的消息为加密后的消息即(m2，MAC2K)，那么Companion UE还需要根据K对其进行解密，以获取Access ID 1、Access ID 2、B、A1、A2。
1108，Companion UE完成验证MAC2K后，将Access ID和网络侧的DH公钥B在安全通道内分别发送给对应的IoT Device，分别发送给IoT Device 1和IoT Device 2的消 息例如为：
1108(a)，向IoT Device 1发送(Access ID 1，B)；
1108(b)，向IoT Device 2发送(Access ID 2，B)。
如果该消息中还包括Provision Server对该消息的签名，那么Companion UE将该签名以及该签名对应的验证信息(例如服务器的证书或者服务器的ID)也发送给IoT Device，例如1109(a)中向IoT Device 1发送(Access ID 1，B，A1，Sig1CN)，1109(b)中向IoT Device 2发送(Access ID 2，B，A2，Sig2CN)。
1109，IoT Device在收到消息后，利用收到的网络侧的DH公钥生成共享密钥，其中：
1109(a)，IoT Device 1生成会话密钥KD1＝BRAND 1mod p。
1109(b)，IoT Device 2生成会话密钥KD2＝BRAND 2mod p。
这时，如果IoT Device1和IoT Device 2还分别接收到了服务器为该消息的签名和该签名对应的验证信息格式例如为(Access ID 1，B，A1，Sig1CN)和(Access ID 2，B，A2，Sig2CN)，那么IoT Device1和IoT Device 2还需要根据该验证信息对分别对签名Sig1CN和Sig2CN进行验证，验证成功时可以根据服务器的DH公钥B分别生成共享秘钥KD1和KD2。
1110，IoT Device将Access ID发送给HSS/Provision Server，并使用其密钥为整条消息产生消息验证码，IoT Device 1和IoT Device 2分别发送的消息例如为：
1110(a)，IoT Device 1发送(Access ID 1，MAC3KD1)给Provision Server；
1110(b)，IoT Device 2发送(Access ID 2，MAC4KD2)给Provision Server。
1111，Provision Server收到消息后，验证MAC3KD1和MAC4KD2。
1112，Provision Server验证完消息验证码后，发送Provision Complete消息给IoT device，并使用密钥为整条消息产生消息验证码，其向IoT Device 1和IoT Device 2分别发送的该消息例如为：
1112(a)，向IoT Device 1发送(Provision Complete，MAC5KD1)；
1112(b)，向IoT Device 2发送(Provision Complete，MAC6KD2)。
1113，IoT Device收到此消息后，验证消息验证码，验证通过后整个过程结束，其中：
1113(a)，IoT Device 1验证MAC5KD1。
1113(b)，IoT Device 2验证MAC6KD2。
其中1110至1113为可选的，其主要目的为验证IoT Device 1和IoT Device 2的产生的密钥与服务器所产生的密钥是否一致，当确认该密钥KD一致之后，IoT Device 1和IoT Device 2可以分别使用其共享密钥KD1和KD2与运营商网络进行之间进行认证，从而接入网络。
上面描述的移动网络的认证方法，第二终端设备通过第一终端设备，从服务器获取运营商的信任状，是基于第一终端设备为已经与服务器成功认证，即第一终端设备为已持有与网络进行会话的共享秘钥的设备。现在考虑另一种情况，第一终端设备此时如果还没有与服务器进行认证，那么第二终端设备应该如何通过第一终端设备，从服务器获取运营商的信任状。
本申请实施例中提出在第一终端设备于服务器进行认证的过程中，为第二终端设备提供获取网络运营商信任状的可能。也就是说，第二终端设备可以在第一终端设备与服 务器进行认证的过程中，获取运营商的信任状。
首先简单说明现有技术中的第一终端设备和服务器之间如何进行认证。图12是现有技术中基于AKA的认证方法的示意性流程图。以UE、移动性管理实体(Mobility Management Entity，MME)和HSS为例进行说明，如图12所示，该方法包括：
201，UE向MME发送接入请求消息；
202，MME基于该接入请求消息，从HSS获取认证向量(或者说，认证数据)，认证向量包括随机数(Random Number，RAND)、预期响应(Expected Response，XRES)和认证令牌(Authentication Token，AUTN)，该认证向量也可以称为鉴权向量。
203，MME将上述认证向量中的RAND和AUTN发送给UE，将XRES保留下来，等待UE的响应(Response，RES)，当UE的发送来的RES与MME保留的XRES相同时，认为该UE认证成功；
204，UE基于接收到的RAND和AUTN，对网络进行认证。
具体地说，UE基于网络预发放的共享密钥K来校验AUTN，UE通过RAND和K计算出匿名密钥(Anonymity Key，AK)，然后使用AK来恢复序列号(Sequence，SQN)，验证该SQN是否合法。接着通过得到的合法SQN、RAND和ISIM中保存的认证管理域(Authentication Management Field，AMF)来计算期望的消息认证码(eXpected Message Authentication Code，XMAC)，若该XMAC与从AUTN中取得的由HSS计算的消息认证码MAC一致，则校验成功，认为认证数据是从归属网络中发过来的。
205，UE在对网络的认证成功后，通过RAND和Key0来计算响应(Response，RES)，并将RES发送给MME；
206，MME将接收到的RES和自身保存的预期响应(eXpected RES，XRES)作校验，若两个参数一致，则认为对终端的认证成功。
应理解，以上所列举的认证流程的具体流程仅为示例性说明，不应对本申请构成任何限定。后面描述的第一终端设备与服务器之间进行认证的过程，可以参考201至206，为了简洁不再赘述，仅对本申请实施例中第二终端设备获取信任状的过程进行相信描述。
还应理解，下面所列举的核心网设备，例如网络认证实体和服务器仅为示例性说明，不应对本申请构成任何限定。例如在4G网络中，该网络认证实体可以为移动性管理实体(Mobility Management Entity，MME)，该服务器可以为归属用户服务器(Home Subscriber Server，HSS)。这里所列举的MME和HSS仅为网络认证实体和服务器的一例，本申请不排除在未来5G中定义的其他具有相同或相似功能的核心网网元用于执行本申请实施例中的认证方法。
图13是本申请实施例的移动网络的认证方法的流程交互图。图13中示出了第一终端设备、第二终端设备、网络认证实体和服务器。以一个第二终端设备为例，如图13所示，该方法包括：
301，第二终端设备确定该第二终端设备的DH公钥。
其中，该第二终端设备为未持有共享密钥的设备。也就是说，该第二终端设备不具有运营商预先发放的信任状，无法实现于服务器之间的认证从而接入运营商网络。
具体地说，通过第一终端设备，第二终端设备与服务器之间可以采用迪菲赫尔曼密钥协商的方式获取共享密钥。即利用第一终端设备具有运营商的信任状的条件，根据DH密钥交换的方法，与服务器协商出用于网络认证的共享密钥。
举例来说，第二终端设备可以产生一个随机数例如RAND 1，第二终端设备根据该RAND 1来计算第二终端设备的DH公钥，这里记作A，其中A＝gRAND 1mod p。
302，第二终端设备向第一终端设备发送第二终端设备的DH公钥和第一ID。
例如第二终端设备向第一终端设备发送的该消息的格式可以为(Device ID，A)，其中Device ID为第二终端设备的第一ID，A为第二终端设备根据自己产生的随机数RAND 1进行DH计算得到的DH公钥，A＝gRAND 1mod p。
进一步地，第二终端设备可以与该第一终端设备建立安全通道，例如蓝牙配对技术，WiFi局域网的加密访问控制技术或有线等短距离通信方式建立安全通道，并在安全通道内将自己的第一ID和生成的公钥发送给第一终端设备。
303，第一终端设备接收第二终端设备发送的第二终端设备的DH公钥和第一ID。
第一终端设备接收第二终端设备发送的接收消息格式例如为(Device ID，A)。进一步地，第一终端设备可以在安全通道内接收第二终端设备发送的第二终端设备的DH公钥和第二终端设备的第一ID。
304，第一终端设备向网络认证实体发送附着请求消息，或称为认证请求消息。
其中，该附着请求消息(Attach Request)包括第一消息和第一终端设备的身份标识ID，该第一消息包括第二终端设备的DH公钥和第二终端设备的第一ID。
可选地，该第一消息中还包括指示信息，该指示信息用于指示该第一消息用于为第二终端设备请求第二终端设备的共享密钥和第二终端设备的第二ID。第一终端设备的身份标识ID为服务器为第一终端设备分配的用于标识签约用户的ID，例如可以为第一终端设备的IMSI号码。
具体地说，该指示信息用来表示该第一消息的用途是为了给第二终端设备设备请求用于第二终端设备与服务器之间的认证的信任状，例如该信任状可以包括第二终端设备与服务器之间的共享密钥，以及服务器为第二终端设备生成的用于标识签约用户的第二ID，该第二ID例如可以是IMSI。该指示信息例如可以为一个标志位，该标志位可以用不同值表示是为个一个第二终端设备请求运营商颁发的信任状，还是为多个第二终端设备请求运营商颁发的信任状。当第一终端设备接收到第二终端设备发送的第二终端设备的第一ID和第二终端设备的DH公钥时，第一终端设备可以在向网络认证实体发送的第一消息中添加该指示信息。
第一终端设备向网络认证实体例如MME发起认证请求的消息格式例如为(Ptype，IMSI，Device ID，A)，其中PType为一个标志位，这个标志位用来表示这个消息的用途是为了给IoT Device请求3GPP Credential。其中，PType可以用不同值表示是为个单个设备请求还是为个多个设备请求，比如这里用Ptype＝1表示是为个单个设备请求3GPP Credential，其中IMSI来自于第一终端设备的3GPP Credential。
305，网络认证实体接收第一终端设备发送的附着请求消息。
网络认证实体接收第一终端设备发送的附着请求消息格式例如为(Ptype，IMSI，Device ID，A)。
306，网络认证实体向服务器发送认证数据请求消息(Authentication Data Request)。
其中，该附着请求消息包括第一消息和第一终端设备的身份标识ID，该第一消息包括第二终端设备的DH公钥和第二终端设备的第一ID。
网络认证实体向服务器发送的认证数据请求消息的格式例如(Ptype，IMSI，SN ID， Network Type，Device ID，A)，其中SN ID为服务网络的ID，Network Type为网路类型。
307，服务器接收网络认证实体发送的认证数据请求消息。
服务器接收的网络认证实体发送的认证数据请求消息的格式例如为(Ptype，IMSI，SN ID，Network Type，Device ID，A)。
308，服务器根据第二随机数确定服务器的DH公钥，并为第二终端设备生成第二终端设备的第二ID，并且确定第一共享密钥。
具体地说，服务器可以生成第二随机数，并根据该第二随机数确定该服务器的DH公钥，从而可以根据该第二随机数和接收到的第二终端设备的DH公钥，生成用于与第二终端设备进行认证的第二终端设备的第一共享秘钥。并且，服务器可以将自已的公钥传递给第二终端设备，以使得第二终端设备可以根据服务器的DH公钥和第二终端设备的DH公钥，确定用于与服务器进行认证的相同的第一共享秘钥。
例如服务器可以生成一个随机数例如RAND 2，服务器根据RAND 2计算服务器的DH公钥，这里记作B，B＝gRAND 2mod p。并利用收到第二终端设备的DH公钥生成第一共享密钥KD＝ARAND 2mod p，同时为第二终端设备产生第二终端设备的第二ID(Access ID)。
309，服务器基于该认证数据请求消息，确定认证向量。
这时服务器可以产生另一个随机数例如RAND 3，同时确定认证向量(Auth.Vector)，该认证向量包括认证相关的认证数据。
310，服务器向该网络认证实体发送认证数据响应消息。
其中，该认证数据响应消息(Authentication Data Response)包括该第二消息和该认证向量，该第二消息包括服务器的DH公钥和服务器为第二终端设备生成的第二终端设备的第二ID。
服务器向该网络认证实体发送认证数据响应消息的格式例如为(EPS Auth.Vector，Access ID，B，A)。
311，网络认证实体接收服务器发送的该认证数据响应消息。
网络认证实体接收的服务器发送的认证数据响应消息的格式例如为(EPS Auth.Vector，Access ID，B，A)。
312，网络认证实体向第一终端设备发送用户认证请求消息。
其中，该用户认证请求消息(User Authentication Request)包括该第二消息和该认证向量中的认证数据。
网络认证实体向第一终端设备发送用户认证请求消息的格式例如(RAND 3，AUTNHSS，Access ID，B，A)，其中AUTNHSS为认证令牌(Authentication Token)。
313，第一终端设备接收该网络认证实体发送的用户认证请求消息。
第一终端设备接收网络认证实体发送的用户认证请求消息的格式例如为(RAND 3，AUTNHSS，Access ID，B，A)，第一终端设备接收到该用户认证请求消息后计算认证响应Auth.Res.，并比较AUTHUE＝AUTHHSS是否相同，如果相同，则第一终端设备新人认证数据是从归属网络中发过来的，执行314。
314，第一终端设备向第二终端设备发送第二终端设备的第二ID和服务器的DH公钥。
第一终端设备接收到网络认证实体发送的用户认证请求消息后，将用户认证请求消息中的第二消息中的第二终端设备的第二ID和服务器的DH公钥发送给第二终端设备该第二消息的格式例如为(Access ID，B)。
315，第二终端设备接收第一终端设备发送的第二终端设备的第二ID和服务器的DH公钥。
316，第二终端设备根据第二终端设备的第一随机数以及接收到服务器的DH公钥，确定第一共享密钥。
具体地说，第二终端设备接收第一终端设备发送的服务器的DH公钥和第二终端设备的第二ID后，可以根据该第一消息中的服务器的DH公钥，以及第二终端设备生成自已的DH公钥时使用的第一随机数，确定用于与该服务器进行认证的第二终端设备的第一共享秘钥。
例如，第二终端设备根据收到的服务器的DH公钥，即B＝gRAND 2mod p，以及用于生成第二终端设备的DH公钥即A＝gRAND 1mod p的第一随机数RAND1，确定用于与服务器之间进行认证的共享密钥，即KD＝BRAND 1mod p。
可以看出，服务器在309中确定共享秘钥即KD＝ARAND 2mod p，与315中第二终端设备确定的共享密钥KD＝BRAND 1mod p是相同的，即K＝Ab mod p＝(ga mod p)b mod p＝gab mod p＝(gb mod p)a＝Ba mod p。并且，该共享密钥仅该第二终端设备与服务器知道，因此，该第二终端设备后续可以使用该共享秘钥和该第二终端设备的第二ID，与服务器之间进行认证从而接入运营商网络。
应注意，第二终端设备获取共享密钥KD后，能够在第一终端设备与服务器认证成功的条件，使用该共享密钥KD与服务器进行认证，并且可以在网络认证实体对第一终端设备认证的过程中，对获取的第一共享秘钥进行验证。
可选地，如图14所示的本申请实施例的移动网络的认证方法的流程交互图，该方法还可以包括316至325。
316，第二终端设备为第二终端设备的第二ID生成的MAC。
在获取第二终端设备的第一共享秘钥后，第二终端设备可以发起对第一共享密钥的验证过程，以确保其确定的第一共享秘钥与服务器确定的共享密钥是一致的。这时第二终端设备可以使用第一共享密钥KD为第二ID产生消息验证码MAC。
317，第二终端设备向第一终端设备发送第二终端设备的第二ID和第二ID的MAC。
第二终端设备向第一终端设备发送的第二ID和第二ID的MAC的消息格式例如为(Access ID，MAC)。
318，第一终端设备接收第二终端设备发送的第二终端设备的第二ID和为该第二ID生成的MAC，并基于用户认证请求消息向网络认证实体发送用户认证响应消息(User Authentication Response)。
第一终端设备接收到第二终端设备发送的第二终端设备的第二ID和为该第二ID生成的MAC后，向网络认证实体发送用户认证响应消息，该用户认证响应消息的格式例如为(Access ID，MAC，RES.)。
319，网络认证实体接收第一终端设备发送的用户认证响应消息，并根据该认证响应消息确定认证是否成功。
网络认证实体接收第一终端设备发送的用户认证响应消息的格式例如为(Access ID， MAC，RES.)，之后网络认证实体比较RES与XRES是否相等。如果相等，网络认证实体完成对第一终端设备的认证，并生成认证成功消息(Auth.Success)，并执行320。
320，网络认证实体向服务器发送第二终端设备的第二ID和第二终端设备的第二ID的MAC。
网络认证实体认证完成后，将第二终端设备的第二ID和第二终端设备的第二ID的MAC发送给服务器，该消息格式例如为(Access ID，MAC)。
321，服务器根据第一共享密钥，对第二终端设备的第二ID的MAC进行验证。
服务器收到第二终端设备的第二ID和第二终端设备的第二ID的MAC后，可以根据第一共享秘钥对第二ID的MAC进行认证。服务器接收到的该消息的格式例如为(Access ID，MAC)，之后可以根据第一共享密钥KD验证MAC。如果服务器对第二终端设备的第二ID的MAC验证通过，执行320。
322，服务器向网络认证实体发送配置完成消息(Provision Complete)。
323，网络认证实体接收服务器发送的配置完成消息，并向第一终端设备发送配置完成消息和基于318的认证成功消息。
网络认证实体接收配置完成消息后，将该配置完成消息和318中生成的认证成功消息一起发送给第二终端设备，网络认证实体向第一终端设备发送的该消息的格式例如为(Provision Complete，Auth.Success)。
324，第一终端设备接收网络认证实体发送的配置完成消息和认证成功消息，并向第二终端设备发送配置完成消息。
第一终端设备接收配置完成消息和认证成功消息后，根据认证成功消息确定第一终端设备认证成功，并将配置完成消息发送给第二终端设备，第一终端设备从网络认证实体接收到的消息格式例如为(Provision Complete，Auth.Success)，向第二终端设备发送Provision Complete后整个过程结束。
325，第二终端设备根据第一共享秘钥和第二终端设备的第二ID，与运营商网络进行认证。
应理解，对于多个第二终端设备的情况下，这多个第二终端设备在第一终端设备与服务器进行认证的过程中，通过第一终端设备获取运营商的信任状的具体过程，可以参考上面对图13的描述以及图11的相关描述。其中，多个第二终端设备中的每个第二终端设备获取运营商的信任状的过程，都可以按照图13中描述的方法来执行，为了简洁，这里不再赘述。
因此，本申请实施例的移动网络的认证方法，未持有运营商与预发放的信任状的终端设备能够在第一终端设备与服务器认证的过程中，通过第一终端设备从服务器获取用于与服务器进行认证的信任状，从而即使在第一终端设备还没有与运营商网络认证的情况下，也可以获取运营商网络颁发的信任状。
应理解，以上各图所示的实施例中，各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
以上，结合图7至图14详细说明了根据本申请实施例的移动网络的认证方法。以下，结合图15至图26详细说明根据本申请实施例的终端设备、服务以及网络认证实体。应理解，本申请实施例的网络设备和终端设备可以执行前述本申请实施例的各种方法，即 以下各种设备的具体工作过程，可以参考前述方法实施例中的对应过程。
图15示出了本申请实施例的终端设备1500的示意性框图。如图15所示，该终端设备1500为上述图7至图11的方法实施例中的第一终端设备，所述第一终端设备为已持有共享密钥的设备，该第一终端设备1500包括接收模块1501和发送模块1502。
接收模块1501，用于接收至少一个第二终端设备发送的迪菲赫尔曼DH公钥和第一身份标识ID，所述至少一个第二终端设备为未持有共享密钥的设备；
发送模块1502，用于向服务器发送第一消息，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID；
所述接收模块1501还用于，接收所述服务器基于所述第一消息发送的第二消息，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
所述发送模块1502还用于，向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥，以使得所述每个第二终端设备根据所述每个第二终端设备的第二ID和所述服务器的DH公钥，确定用于与所述服务器进行认证的所述每个第二终端设备的第一共享密钥和所述每个第二终端设备的第二ID。
可选地，所述第一消息还包括指示信息，所述指示信息用于指示所述第一消息用于为所述每个第二终端设备请求所述每个第二终端设备的共享密钥和所述每个第二终端设备第二ID。
可选地，在所述第一终端设备向所述服务器发送第一消息之前，所述第一终端设备还包括：
生成模块，用于根据第二共享密钥，为所述第一消息生成所述第一消息的消息验证码MAC，所述第二共享密钥用于所述第一终端设备与所述服务器之间的认证；
其中，所述发送模块1502具体用于：向所述服务器发送所述第一消息和所述第一消息的MAC。
可选地，所述接收模块1501具体用于：接收所述服务器发送的所述第二消息，和所述服务器根据第二共享密钥为所述第二消息生成的所述第二消息的MAC；
其中，所述发送模块1502具体用于：所述第一终端设备根据第二共享密钥，对所述第二消息的MAC进行验证；如果所述第一终端设备对所述第二消息的MAC验证通过，所述第一终端设备向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥。
可选地，所述接收模块1501具体用于：接收所述服务器发送的所述第二消息、所述服务器对所述每个第二终端设备的第二ID和所述服务器的DH公钥进行签名后得到的所述每个第二终端设备的签名消息、以及与所述每个第二终端设备的签名消息对应的所述每个第二终端设备的验证信息；
其中，所述发送模块1502具体用于：向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥、所述每个第二终端设备的签名消息和所述每个第二终端设备的验证信息。
可选地，所述验证消息包括所述服务器的证书或者所述服务器的ID。
可选地，在所述发送模块1502向所述服务器发送第一消息之前，所述终端设备还包括：
加密模块，用于根据第二共享密钥，对所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID进行加密；
其中，所述发送模块1502向所述服务器发送的所述第一消息中的所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，是经过所述第一终端设备加密的。
可选地，所述接收模块1501从所述服务器接收的所述第二消息中的所述每个第二终端设备的第二ID和所述服务器的DH公钥，是经过所述服务器加密的；其中，在所述发送模块1502向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥之前，所述终端设备还包括：
解密模块，用于根据第二共享密钥，对加密后的所述每个第二终端设备的第二ID和所述服务器的DH公钥进行解密；
所述发送模块1502具体用于：向所述每个第二终端设备发送解密后的所述每个第二终端设备的第二ID和所述服务器的DH公钥。
可选地，所述服务器包括归属用户服务器HSS。
根据本申请实施例的终端设备1500可对应于根据图7至图11中的本申请实施例的认证方法中的第一终端设备，并且，该终端设备1500中的各模块和上述其他操作和/或功能分别为了实现图7至图11中各个方法的相应流程，为了简洁，在此不再赘述。
因此，本申请实施例的终端设备，基于自身已持有的运营商的信任状，能够对未持有运营商预发放的信任状的终端设备建立与服务器之间的密钥协商的通道，使不具有运营商预先发放的信任状的终端设备，也能够从服务器获取用于与运营商网络进行认证的共享密钥从而能够接入网络。
图16示出了本申请实施例的终端设备1600的示意性框图。如图16所示，该终端设备1600为上述图7至图11的方法实施例中的第二终端设备，所述第二终端设备为未持有共享密钥的设备，该第二终端设备1600包括确定模块1601、发送模块1602、接收模块1603和认证模块1604。
确定模块1601，用于根据第一随机数确定所述第二终端设备的迪菲赫尔曼DH公钥；
发送模块1602，用于发送第一消息至第一终端设备，其中，所述第一消息包括所述第二终端设备的DH公钥和所述第二终端设备的第一身份标识ID，所述第一终端设备为已持有共享密钥的设备；
接收模块1603，用于接收所述第一终端设备基于所述第一消息发送的第二消息，所述第二消息包括服务器的DH公钥，和所述服务器为所述第二终端设备生成的第二ID，所述第二ID用于标识签约用户；
所述确定模块1601还用于，根据所述第一随机数，和所述服务器的DH公钥，确定第一共享密钥；
认证模块1604，用于根据所述第一共享密钥和所述第二ID，与所述服务器进行相互认证。
可选地，所述接收模块1603具体用于：接收所述第一终端设备发送的所述第二消息、所述服务器对所述第二消息签名后得到的签名消息、和与所述签名消息对应的验证信息；
所述确定模块1601具体用于：根据所述第二消息、所述签名消息和所述验证信息，对所述第二消息进行验证；如果对所述第二消息验证通过，所述第二终端设备根据所述第一随机数和所述服务器的DH公钥，确定所述第一共享密钥。
可选地，所述验证消息包括所述服务器的证书或者所述服务器的ID。
可选地，所述终端设备还包括生成模块和验证模块，所述生成模块用于：根据所述第一共享密钥，为所述第二ID生成所述第二ID的消息验证码MAC；
所述发送模块1602还用于，向所述服务器发送所述第二ID和所述第二ID的MAC；
所述接收模块1603还用于，接收所述服务器基于所述第二ID和所述第二ID的MAC发送的配置完成消息，以及所述服务器为所述配置完成消息生成的所述配置完成消息的MAC；
所述验证模块，用于根据所述第一共享密钥，对所述配置完成消息的MAC进行验证；
其中，所述认证模块1604具体用于：如果所述验证模块对所述配置完成消息的MAC验证通过，所述第二终端设备根据所述第一共享密钥和所述第二ID，与所述服务器进行相互认证。
根据本申请实施例的终端设备1600可对应于根据图7至图11中的本申请实施例的认证方法中的第二终端设备，并且，该终端设备1600中的各模块和上述其他操作和/或功能分别为了实现图7至图11中各个方法的相应流程，为了简洁，在此不再赘述。
因此，本申请实施例中，不具有运营商预先发放的信任状的终端设备，可以通过其他已持有信任状的终端设备，基于DH密钥交换的方式从服务器获取用于与运营商网络进行认证的共享密钥从而能够接入网络。
图17示出了本申请实施例的服务器1700的示意性框图。服务器1700为上述图7至图11的方法实施例中的服务器。如图17所示，该服务器1700包括接收模块1701、确定模块1702和发送模块1703。
接收模块1701，用于接收所述第一终端设备发送的第一消息，其中，所述第一消息包括所述第一终端设备从至少一个第二终端设备中的每个第二终端设备接收的所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；
确定模块1702，用于根据第二随机数确定所述服务器的DH公钥，并为所述每个第二终端设备生成所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
所述确定模块1702还用于，根据所述每个第二终端设备的DH公钥和所述第二随机数，确定用于与所述每个第二终端设备进行认证的所述每个第二终端设备的第一共享密钥；
发送模块1703，用于向所述第一终端设备发送第二消息，所述第二消息包括所述服务器的DH公钥和所述每个第二终端设备的第二ID。
可选地，所述第一消息还包括指示信息，所述指示信息用于指示所述第一消息用于为所述每个第二终端设备请求所述第二终端设备的的共享密钥和所述第二终端设备的第二ID。
可选地，所述接收模块1701具体用于：接收所述第一终端设备发送的所述第一消息，和所述第一终端设备根据第二共享密钥为所述第一消息生成的所述第一消息的消息验证码MAC，所述第二共享密钥用于所述第一终端设备与所述服务器之间的认证；
其中，确定模块1702具体用于：根据第二共享密钥，对所述第一消息的MAC进行验证；如果对所述第一消息的MAC验证通过，根据所述第二随机数和所述服务器的DH 公钥，确定用于与所述每个第二终端设备进行认证的每个第二终端设备的第一共享密钥。
可选地，在所述发送模块1703向所述第一终端设备发送第二消息之前，所述服务器还包括：生成模块，用于根据第二共享密钥，为所述第二消息生成所述第二消息的MAC；
其中，所述发送模块1703具体用于：向所述第一终端设备发送所述第二消息和所述第二消息的MAC。
可选地，在所述发送模块1703向所述第一终端设备发送第二消息之前，所述服务器还包括：
签名模块，用于对所述每个第二终端设备的第二ID和所述服务器的DH公钥进行签名；
其中，所述发送模块1703具体用于：向所述第一终端设备发送所述第二消息、所述服务器对所述每个第二终端设备的第二ID和所述服务器的DH公钥进行签名后得到所述每个第二终端设备的签名消息、和与所述每个第二终端设备的签名消息对应的所述每个第二终端设备的验证消息。
可选地，所述验证消息包括所述服务器的证书或者所述服务器的ID。
可选地，所述接收模块1701从所述第一终端设备接收的所述第一消息中的所述每个第二终端设备的DH公钥，和所述每个第二终端设备的第一ID，是经过所述第一终端设备加密的；
其中，在所述确定模块1702根据所述每个第二终端设备的DH公钥，和所述第二随机数，确定用于与所述每个第二终端设备进行认证的每个第二终端设备的第一共享密钥之前，所述服务器还包括：解密模块，用于根据第二共享密钥，对加密后的所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID进行解密；
所述确定模块1702具体用于：根据解密后的所述每个第二终端设备的DH公钥，和所述第二随机数，确定用于与所述每个第二终端设备进行认证的所述每个第二终端设备的第一共享密钥。
可选地，在所述发送模块1703向所述第一终端设备发送第二消息之前，所述服务器还包括：加密模块，用于根据第二共享密钥，对所述服务器的DH公钥和所述每个第二终端设备的第二ID进行加密；
其中，所述发送模块1703向所述第一终端设备发送的所述第二消息中的所述服务器的DH公钥和所述每个第二终端设备的第二ID，是经过所述服务器加密的。
可选地，所述服务器还包括验证模块，其中，所述接收模块1701还用于：接收所述每个第二终端设备发送的所述每个第二终端设备的第二ID，和所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC；
所述验证模块，用于根据所述第一共享密钥，对所述每个第二终端设备的第二ID的MAC进行验证；
所述发送模块1703还用于，如果所述验证模块对所述每个第二终端设备的第二ID的MAC验证成功，向所述每个第二终端设备发送配置完成消息，以及所述服务器为所述配置完成消息生成的所述配置完成消息的MAC。
根据本申请实施例的服务器1700可对应于根据图7至图11中的本申请实施例的认证方法中的服务器，并且，该服务器1700中的各模块和上述其他操作和/或功能分别为了实现图7至图11中各个方法的相应流程，为了简洁，在此不再赘述。
因此，本申请实施例的服务器，能够通过已持有信任状的终端设备，基于DH密钥交换的方式，为不具有运营商预先发放的信任状的终端设备提供用于与运营商网络进行认证的共享密钥从而使其能够接入网络。
图18是根据本申请实施例的终端设备1800的另一示意性框图。该终端设备1800为上述方法实施例中的第一终端设备。如图18所示，该终端设备1800包括：接收器1810、发送器1820、处理器1830和存储器1840。接收器1810和发送器1820可以合称为收发信机。其中，接收器1810、发送器1820、处理器1830和存储器1840通过内部连接通路互相连接，该存储器1840用于存储指令，该处理器1830用于执行该存储器1840存储的指令，以控制接收器1810接收信号，并控制发送器1820发送信号。
其中，接收器1810用于接收至少一个第二终端设备发送的迪菲赫尔曼DH公钥和第一身份标识ID，所述至少一个第二终端设备为未持有共享密钥的设备；
发送器1820用于向服务器发送第一消息，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID；
接收器1810还用于，接收所述服务器基于所述第一消息发送的第二消息，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
发送器1820还用于，向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥，以使得所述每个第二终端设备根据所述每个第二终端设备的第二ID和所述服务器的DH公钥，确定用于与所述服务器进行认证的所述每个第二终端设备的第一共享密钥和所述每个第二终端设备的第二ID。
根据本申请实施例的终端设备1800可对应于根据图7至图11所示的本申请实施例的移动网络的认证方法中的第一终端设备，以及根据本申请实施例的终端设备1500，并且，该终端设备1800中的各模块和上述其他操作和/或功能为了实现图7至图11中各个方法的相应流程，为了简洁，在此不再赘述。
图19是根据本申请实施例的终端设备1900的另一示意性框图。该终端设备1900为上述方法实施例中的第二终端设备。如图19所示，该终端设备1900包括：接收器1910、发送器1920、处理器1930、和存储器1940。接收器1910和发送器1920可以合称为收发信机。其中，接收器1910、发送器1920、处理器1930和存储器1940通过内部连接通路互相连接，该存储器1940用于存储指令，该处理器1930用于执行该存储器1940存储的指令，以控制接收器1910接收信号，并控制发送器1920发送信号。
处理器1930，用于根据第一随机数确定所述第二终端设备的迪菲赫尔曼DH公钥；
发送器1920，用于发送第一消息至第一终端设备，其中，所述第一消息包括所述第二终端设备的DH公钥和所述第二终端设备的第一身份标识ID，所述第一终端设备为已持有共享密钥的设备；
接收器1910，用于接收所述第一终端设备基于所述第一消息发送的第二消息，所述第二消息包括服务器的DH公钥，和所述服务器为所述第二终端设备生成的第二ID，所述第二ID用于标识签约用户；
处理器1930还用于：根据所述第一随机数，和所述服务器的DH公钥，确定第一共享密钥；根据所述第一共享密钥和所述第二ID，与所述服务器进行相互认证。
根据本申请实施例的终端设备1900可对应于根据图7至图11所示的本申请实施例 的移动网络的认证方法中的第二终端设备，以及根据本申请实施例的终端设备1600，并且，该终端设备1900中的各模块和上述其他操作和/或功能为了实现图7至图11中各个方法的相应流程，为了简洁，在此不再赘述。
图20是根据本申请实施例的服务器2000的另一示意性框图。该服务器2000为上述方法实施例中的第二终端设备。如图20所示，该服务器2000包括：接收器2010、发送器2020、处理器2030和存储器2040。接收器2010和发送器2020可以合称为收发信机。其中，接收器2010、发送器2020、处理器2030和存储器2040通过内部连接通路互相连接，该存储器2040用于存储指令，该处理器2030用于执行该存储器2040存储的指令，以控制接收器2010接收信号，并控制发送器2020发送信号。
接收器2010，用于接收所述第一终端设备发送的第一消息，其中，所述第一消息包括所述第一终端设备从至少一个第二终端设备中的每个第二终端设备接收的所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；
处理器2030，用于根据第二随机数确定所述服务器的DH公钥，并为所述每个第二终端设备生成所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；根据所述每个第二终端设备的DH公钥和所述第二随机数，确定用于与所述每个第二终端设备进行认证的所述每个第二终端设备的第一共享密钥；
发送器2020，用于向所述第一终端设备发送第二消息，所述第二消息包括所述服务器的DH公钥和所述每个第二终端设备的第二ID。
根据本申请实施例的服务器2000可对应于根据图7至图11所示的本申请实施例的移动网络的认证方法中的服务器，以及根据本申请实施例的服务器1700，并且，该服务器2000中的各模块和上述其他操作和/或功能为了实现图7至图11中各个方法的相应流程，为了简洁，在此不再赘述。
图21示出了本申请另一实施例的终端设备2100的示意性框图。如图21所示，该终端设备2100为上述图13的方法实施例中的第一终端设备，所述第一终端设备为已持有共享密钥的设备，该第一终端设备2100包括接收模块2101和发送模块2102。
接收模块2101，用于接收至少一个第二终端设备发送的迪菲赫尔曼DH公钥和第一身份标识ID，所述至少一个第二终端设备为未持有共享密钥的设备；
发送模块2102，用于向网络认证实体发送附着请求消息，其中，所述附着请求消息包括第一消息和所述第一终端设备的身份标识ID，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID；
所述接收模块2101还用于，接收所述网络认证实体基于所述附着请求消息发送的用户认证请求消息，其中，所述用户认证请求消息包括第二消息和认证数据，所述第二消息包括服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
所述发送模块2102还用于，向所述每个第二终端设备发送所述服务器的DH公钥和所述每个第二终端设备的第二ID，以使得所述每个第二终端设备根据所述每个第二终端设备的第二ID和所述服务器的DH公钥，确定用于与所述服务器进行认证的所述每个第二终端设备的第一共享密钥和所述每个第二终端设备的第二ID。
因此，本申请实施例的终端设备，能够在根据自身已持有的信任状与运营商网络进 行认证的过程中，对未持有运营商预发放的信任状的终端设备建立与服务器之间的密钥协商的通道，使不具有运营商预先发放的信任状的终端设备，也能够从服务器获取用于与运营商网络进行认证的共享密钥从而能够接入网络。
可选地，所述接收模块2101还用于：接收所述每个第二终端设备发送的所述每个第二终端设备的第二ID，和所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC；
所述发送模块2102还用于，向所述网络认证实体发送所述每个第二终端设备的第二ID，和所述每个第二终端设备的第二ID的MAC；
所述接收模块2101还用于，接收所述网络认证实体基于所述每个第二终端设备的第二ID和所述每个第二终端设备的第二ID的MAC发送的配置完成消息；
所述发送模块2102还用于，向所述每个第二终端设备发送所述配置完成消息。
可选地，所述发送模块2102还用于：基于所述用户认证请求消息，向所述网络认证实体发送用户认证响应消息；
所述接收模块2101还用于，接收所述网络认证实体基于所述认证响应消息发送的认证成功消息。
可选地，其特征在于，所述服务器包括归属用户服务器HSS。
可选地，所述网络认证实体包括移动性管理实体MME。
根据本申请实施例的终端设备2100可对应于根据图13中的本申请实施例的认证方法中的第一终端设备，并且，该终端设备2100中的各模块和上述其他操作和/或功能分别为了实现图13中各个方法的相应流程，为了简洁，在此不再赘述。
图22示出了本申请另一实施例的网络认证实体2200的示意性框图。如图22所示，该网络认证实体2200为上述图13的方法实施例中的网络认证实体，该网络认证实体2200包括接收模块2201和发送模块2202。
接收模块2201，用于接收第一终端设备发送的附着请求消息，其中，所述附着请求消息包括第一消息和所述第一终端设备的身份标识ID，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；
发送模块2202，用于根据所述附着请求消息，向服务器发送认证数据请求消息；
所述接收模块2201还用于，接收所述服务器基于所述认证数据请求消息发送的认证数据响应消息，其中，所述认证数据响应消息包括第二消息和认证向量，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
所述发送模块2202还用于，向所述第一终端设备发送所述第二消息和所述认证向量中的认证数据，以使得所述第一终端设备向所述每个第二终端设备发送所述服务器的DH公钥和所述每个第二终端设备的第二ID。
因此，本申请实施例中，网络认证实体在对已持有信任状的终端设备进行认证的过程中，能够为未持有运营商预发放的信任状的终端设备提供与服务器之间的密钥协商的通道，以使不具有运营商预先发放的信任状的终端设备，也能够从服务器获取用于与运营商网络进行认证的共享密钥从而能够接入网络。
可选地，所述接收模块2201还用于：接收所述第一终端设备发送的所述每个第二终端设备的第二ID、所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC，以及所述第一终端设备基于所述用户认证请求消息发送的用户认证响应消息；
所述发送模块2202还用于，向所述服务器发送所述每个第二终端设备的第二ID和所述每个第二终端设备的第二ID的MAC；
所述接收模块2201还用于，接收所述服务器基于所述每个第二终端设备的第二ID和所述每个第二终端设备的第二ID的MAC发送的配置完成消息；
所述发送模块2202还用于，根据所述用户认证响应消息，向所述第一终端设备发送认证成功消息，并向所述第一终端设备发送所述配置完成消息，以使得所述第一终端设备向所述每个第二终端设备发送所述配置完成消息。
根据本申请实施例的网络认证实体2200可对应于根据图13中的本申请实施例的认证方法中的网络认证实体，并且，该网络认证实体2200中的各模块和上述其他操作和/或功能为了实现图13中各个方法的相应流程，为了简洁，在此不再赘述。
图23示出了本申请另一实施例的服务器2300的示意性框图。如图23所示，该服务器2300为上述图13的方法实施例中的服务器，该服务器2300包括接收模块2301、确定模块2302和发送模块2303。
接收模块2301，用于接收网络认证实体发送的认证数据请求消息，所述认证数据请求消息包括第一消息和第一终端设备的身份标识ID，所述第一消息包括至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述至少一个第二终端设备为未持有共享密钥的设备；
确定模块2302，用于确定所述服务器的DH公钥，并为所述每个第二终端设备，生成所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；基于所述认证数据请求消息，确定认证向量；
所述发送模块2303，用于向所述网络认证实体发送用户认证响应消息，所述用户认证响应消息包括所述第二消息和所述认证向量，所述第二消息包括所述服务器的DH公钥，以及所述每个第二终端设备的第二ID。
因此，本申请实施例的服务器，能够在与已持有信任状的终端设备进行认证的过程中，基于DH密钥交换的方式，为不具有运营商预先发放的信任状的终端设备提供用于与运营商网络进行认证的共享密钥从而使其能够接入网络。
可选地，所述服务器还包括验证模块，其中，所述接收模块2301用于：接收所述网络认证实体发送的所述每个第二终端设备的第二ID，和所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC；
所述验证模块，用于根据所述第一共享密钥，对所述每个第二终端设备的第二ID的MAC进行验证；
所述发送模块用于，如果所述验证模块对所述每个第二终端设备的第二ID的MAC验证通过，向所述网络认证实体发送配置完成消息。
根据本申请实施例的服务器2300可对应于根据图13中的本申请实施例的认证方法中的服务器，并且，该服务器2300中的各模块和上述其他操作和/或功能为了实现图13中各个方法的相应流程，为了简洁，在此不再赘述。
图24是根据本申请另一实施例的终端设备2400的另一示意性框图。该终端设备2400为上述图13的方法实施例中的第一终端设备。如图24所示，该终端设备2400包括：接收器2410、发送器2420、处理器2430和存储器2440。接收器1810和发送器1820可以合称为收发信机。其中，接收器2410、发送器2420、处理器2430和存储器2440通过内部连接通路互相连接，该存储器2440用于存储指令，该处理器2430用于执行该存储器2440存储的指令，以控制接收器2410接收信号，并控制发送器2420发送信号。
其中，接收器2410，用于接收至少一个第二终端设备发送的迪菲赫尔曼DH公钥和第一身份标识ID，所述至少一个第二终端设备为未持有共享密钥的设备；
发送器2420，用于向网络认证实体发送附着请求消息，其中，所述附着请求消息包括第一消息和所述第一终端设备的身份标识ID，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID；
所述接收器2410还用于，接收所述网络认证实体基于所述附着请求消息发送的用户认证请求消息，其中，所述用户认证请求消息包括第二消息和认证数据，所述第二消息包括服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
所述发送器2420还用于，向所述每个第二终端设备发送所述服务器的DH公钥和所述每个第二终端设备的第二ID，以使得所述每个第二终端设备根据所述每个第二终端设备的第二ID和所述服务器的DH公钥，确定用于与所述服务器进行认证的所述每个第二终端设备的第一共享密钥和所述每个第二终端设备的第二ID。
根据本申请实施例的终端设备2400可对应于根据图13所示的本申请实施例的移动网络的认证方法中的第一终端设备，以及根据本申请实施例的终端设备2100，并且，该终端设备2400中的各模块和上述其他操作和/或功能为了实现图13中各个方法的相应流程，为了简洁，在此不再赘述。
图25是根据本申请另一实施例的网络认证实体2500的另一示意性框图。该网络认证实体2500为上述图13的方法实施例中的网络认证实体。如图25所示，该网络认证实体2500包括：接收器2510、发送器2520、处理器2530和存储器2540。接收器2510和发送器2520可以合称为收发信机。其中，接收器2510、发送器2520、处理器2530和存储器2540通过内部连接通路互相连接，该存储器2540用于存储指令，该处理器2530用于执行该存储器2540存储的指令，以控制接收器2510接收信号，并控制发送器2520发送信号。
其中，接收器2510，用于接收第一终端设备发送的附着请求消息，其中，所述附着请求消息包括第一消息和所述第一终端设备的身份标识ID，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；
发送器2520，用于根据所述附着请求消息，向服务器发送认证数据请求消息；
所述接收器2510还用于，接收所述服务器基于所述认证数据请求消息发送的认证数据响应消息，其中，所述认证数据响应消息包括第二消息和认证向量，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
所述发送器2520还用于，向所述第一终端设备发送所述第二消息和所述认证向量中的认证数据，以使得所述第一终端设备向所述每个第二终端设备发送所述服务器的DH公钥和所述每个第二终端设备的第二ID。
根据本申请实施例的网络认证实体2500可对应于根据图13所示的本申请实施例的移动网络的认证方法中的第一终端设备，以及根据本申请实施例的网络认证实体2200，并且，该网络认证实体2500中的各模块和上述其他操作和/或功能为了实现图13中各个方法的相应流程，为了简洁，在此不再赘述。
图26是根据本申请另一实施例的服务器2600的另一示意性框图。该服务器2600为上述方法实施例中的服务器。如图26所示，该服务器2600包括：接收器2610、发送器2620、处理器2630和存储器2640。接收器2610和发送器2620可以合称为收发信机。其中，接收器2610、发送器2620、处理器2630和存储器2640通过内部连接通路互相连接，该存储器2640用于存储指令，该处理器2630用于执行该存储器2640存储的指令，以控制接收器2610接收信号，并控制发送器2620发送信号。
其中，接收器2610，用于接收网络认证实体发送的认证数据请求消息，所述认证数据请求消息包括第一消息和第一终端设备的身份标识ID，所述第一消息包括至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述至少一个第二终端设备为未持有共享密钥的设备；
处理器2630，用于确定所述服务器的DH公钥，并为所述每个第二终端设备，生成所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；基于所述认证数据请求消息，确定认证向量；
所述发送器2620，用于向所述网络认证实体发送用户认证响应消息，所述用户认证响应消息包括所述第二消息和所述认证向量，所述第二消息包括所述服务器的DH公钥，以及所述每个第二终端设备的第二ID。
根据本申请实施例的服务器2600可对应于根据图13所示的本申请实施例的移动网络的认证方法中的服务器，以及根据本申请实施例的服务器2300，并且，该服务器2600中的各模块和上述其他操作和/或功能为了实现图13中各个方法的相应流程，为了简洁，在此不再赘述。
可以理解，本申请实施例中的处理器可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
可以理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可 包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data Rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(Synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
另外，本文中术语“系统”和“网络”在本文中常被可互换使用。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
应理解，在本申请实施例中，“与A相应的B”表示B与A相关联，根据A可以确定B。但还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以 是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (62)

  1. 一种移动网络的认证方法，其特征在于，所述方法包括：
    第一终端设备接收至少一个第二终端设备发送的迪菲赫尔曼DH公钥和第一身份标识ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；
    所述第一终端设备向服务器发送第一消息，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID；
    所述第一终端设备接收所述服务器基于所述第一消息发送的第二消息，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
    所述第一终端设备向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥，以使得所述每个第二终端设备根据所述每个第二终端设备的第二ID和所述服务器的DH公钥，确定用于与所述服务器进行认证的所述每个第二终端设备的第一共享密钥和所述每个第二终端设备的第二ID。
  2. 根据权利要求1所述的方法，其特征在于，所述第一消息还包括指示信息，所述指示信息用于指示所述第一消息用于为所述每个第二终端设备请求所述每个第二终端设备的共享密钥和所述每个第二终端设备第二ID。
  3. 根据权利要求1或2所述的方法，其特征在于，在所述第一终端设备向所述服务器发送第一消息之前，所述方法还包括：
    所述第一终端设备根据第二共享密钥，为所述第一消息生成所述第一消息的消息验证码MAC，所述第二共享密钥用于所述第一终端设备与所述服务器之间的认证；
    其中，所述第一终端设备向所述服务器发送第一消息，包括：
    所述第一终端设备向所述服务器发送所述第一消息和所述第一消息的MAC。
  4. 根据权利要求1至3中任一项所述的方法，其特征在于，所述第一终端设备接收所述服务器基于所述第一消息发送的第二消息，包括：
    所述第一终端设备接收所述服务器发送的所述第二消息，和所述服务器根据第二共享密钥为所述第二消息生成的所述第二消息的MAC；
    其中，所述第一终端设备向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥，包括：
    所述第一终端设备根据第二共享密钥，对所述第二消息的MAC进行验证；
    如果所述第一终端设备对所述第二消息的MAC验证通过，所述第一终端设备向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥。
  5. 根据权利要求1至4中任一项所述的方法，其特征在于，所述第一终端设备接收所述服务器基于所述第一消息发送的第二消息，包括：
    所述第一终端设备接收所述服务器发送的所述第二消息、所述服务器对所述每个第二终端设备的第二ID和所述服务器的DH公钥进行签名后得到的所述每个第二终端设备的签名消息、以及与所述每个第二终端设备的签名消息对应的所述每个第二终端设备的验证信息；
    其中，所述第一终端设备向所述每个第二终端设备发送所述第二消息，包括：
    所述第一终端设备向所述每个第二终端设备发送所述每个第二终端设备的第二ID 和所述服务器的DH公钥、所述每个第二终端设备的签名消息和所述每个第二终端设备的验证信息。
  6. 根据权利要求5所述的方法，其特征在于，所述验证消息包括所述服务器的证书或者所述服务器的ID。
  7. 根据权利要求1至6中任一项所述的方法，其特征在于，在所述第一终端设备向所述服务器发送第一消息之前，所述方法还包括：
    所述第一终端设备根据第二共享密钥，对所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID进行加密；
    其中，所述第一终端设备向所述服务器发送的所述第一消息中的所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，是经过所述第一终端设备加密的。
  8. 根据权利要求1至7中任一项所述的方法，其特征在于，所述第一终端设备从所述服务器接收的所述第二消息中的所述每个第二终端设备的第二ID和所述服务器的DH公钥，是经过所述服务器加密的；
    其中，在所述第一终端设备向所述每个第二终端设备发送所述每个第二终端设备的第二ID，和所述服务器的DH公钥之前，所述方法还包括：
    所述第一终端设备根据第二共享密钥，对加密后的所述每个第二终端设备的第二ID和所述服务器的DH公钥进行解密；
    所述第一终端设备向所述每个第二终端设备发送所述每个第二终端设备的第二ID，和所述服务器的DH公钥，包括：
    所述第一终端设备向所述每个第二终端设备发送解密后的所述每个第二终端设备的第二ID和所述服务器的DH公钥。
  9. 根据权利要求1至8中任一项所述的方法，其特征在于，所述服务器包括归属用户服务器HSS。
  10. 一种移动网络的认证方法，其特征在于，所述方法包括：
    第二终端设备根据第一随机数确定所述第二终端设备的迪菲赫尔曼DH公钥，所述第二终端设备为未持有共享密钥的设备；
    所述第二终端设备发送第一消息至第一终端设备，其中，所述第一消息包括所述第二终端设备的DH公钥和所述第二终端设备的第一身份标识ID，所述第一终端设备为已持有共享密钥的设备；
    所述第二终端设备接收所述第一终端设备基于所述第一消息发送的第二消息，所述第二消息包括服务器的DH公钥，和所述服务器为所述第二终端设备生成的第二ID，所述第二ID用于标识签约用户；
    所述第二终端设备根据所述第一随机数，和所述服务器的DH公钥，确定第一共享密钥；
    所述第二终端设备根据所述第一共享密钥和所述第二ID，与所述服务器进行相互认证。
  11. 根据权利要求10所述的方法，其特征在于，所述第二终端设备接收所述第一终端设备发送的第二消息，包括：
    所述第二终端设备接收所述第一终端设备发送的所述第二消息、所述服务器对所述第二消息签名后得到的签名消息、和与所述签名消息对应的验证信息；
    所述第二终端设备根据所述第一随机数，和所述服务器的DH公钥，确定第一共享密钥，包括：
    所述第二终端设备根据所述第二消息、所述签名消息和所述验证信息，对所述第二消息进行验证；
    如果所述第二终端设备对所述第二消息验证通过，所述第二终端设备根据所述第一随机数和所述服务器的DH公钥，确定所述第一共享密钥。
  12. 根据权利要求11所述的方法，其特征在于，所述验证消息包括所述服务器的证书或者所述服务器的ID。
  13. 根据权利要求10至12中任一项所述的方法，其特征在于，所述方法还包括：
    所述第二终端设备根据所述第一共享密钥，为所述第二ID生成所述第二ID的消息验证码MAC；
    所述第二终端设备向所述服务器发送所述第二ID和所述第二ID的MAC；
    所述第二终端设备接收所述服务器基于所述第二ID和所述第二ID的MAC发送的配置完成消息，以及所述服务器为所述配置完成消息生成的所述配置完成消息的MAC；
    所述第二终端设备根据所述第一共享密钥，对所述配置完成消息的MAC进行验证；
    其中，所述第二终端设备根据所述第一共享密钥和所述第二ID，与所述服务器进行相互认证，包括：
    如果所述第二终端设备对所述配置完成消息的MAC验证通过，所述第二终端设备根据所述第一共享密钥和所述第二ID，与所述服务器进行相互认证。
  14. 一种移动网络的认证方法，其特征在于，所述方法包括：
    服务器接收所述第一终端设备发送的第一消息，其中，所述第一消息包括所述第一终端设备从至少一个第二终端设备中的每个第二终端设备接收的所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；
    所述服务器根据第二随机数确定所述服务器的DH公钥，并为所述每个第二终端设备生成所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
    所述服务器根据所述每个第二终端设备的DH公钥和所述第二随机数，确定用于与所述每个第二终端设备进行认证的所述每个第二终端设备的第一共享密钥；
    所述服务器向所述第一终端设备发送第二消息，所述第二消息包括所述服务器的DH公钥和所述每个第二终端设备的第二ID。
  15. 根据权利要求14所述的方法，其特征在于，所述第一消息还包括指示信息，所述指示信息用于指示所述第一消息用于为所述每个第二终端设备请求所述第二终端设备的的共享密钥和所述第二终端设备的第二ID。
  16. 根据权利要求14或15所述的方法，其特征在于，所述服务器接收所述第一终端设备发送的第一消息，包括：
    所述服务器接收所述第一终端设备发送的所述第一消息，和所述第一终端设备根据第二共享密钥为所述第一消息生成的所述第一消息的消息验证码MAC，所述第二共享密钥用于所述第一终端设备与所述服务器之间的认证；
    其中，所述服务器根据所述第二随机数，和所述服务器的DH公钥，确定用于与所述每个第二终端设备进行认证的每个第二终端设备的第一共享密钥，包括：
    所述服务器根据第二共享密钥，对所述第一消息的MAC进行验证；
    如果所述服务器对所述第一消息的MAC验证通过，所述服务器根据所述第二随机数，和所述服务器的DH公钥，确定用于与所述每个第二终端设备进行认证的每个第二终端设备的第一共享密钥。
  17. 根据权利要求14至16中任一项所述的方法，其特征在于，在所述服务器向所述第一终端设备发送第二消息之前，所述方法还包括：
    所述服务器根据第二共享密钥，为所述第二消息生成所述第二消息的MAC；
    其中，所述服务器向所述第一终端设备发送第二消息，包括：
    所述服务器向所述第一终端设备发送所述第二消息和所述第二消息的MAC。
  18. 根据权利要求14至17中任一项所述的方法，其特征在于，在所述服务器向所述第一终端设备发送第二消息之前，所述方法还包括：
    所述服务器对所述每个第二终端设备的第二ID和所述服务器的DH公钥进行签名；
    其中，所述服务器向所述第一终端设备发送第二消息，包括：
    所述服务器向所述第一终端设备发送所述第二消息、所述服务器对所述每个第二终端设备的第二ID和所述服务器的DH公钥进行签名后得到所述每个第二终端设备的签名消息、和与所述每个第二终端设备的签名消息对应的所述每个第二终端设备的验证消息。
  19. 根据权利要求18所述的方法，其特征在于，所述验证消息包括所述服务器的证书或者所述服务器的ID。
  20. 根据权利要求14至19中任一项所述的方法，其特征在于，所述服务器从所述第一终端设备接收的所述第一消息中的所述每个第二终端设备的DH公钥，和所述每个第二终端设备的第一ID，是经过所述第一终端设备加密的；
    其中，在所述服务器根据所述每个第二终端设备的DH公钥，和所述第二随机数，确定用于与所述每个第二终端设备进行认证的每个第二终端设备的第一共享密钥之前，所述方法还包括：
    所述服务器根据第二共享密钥，对加密后的所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID进行解密；
    所述服务器根据所述每个第二终端设备的DH公钥，和所述第二随机数，确定用于与所述每个第二终端设备进行认证的所述每个第二终端设备的第一共享密钥，包括：
    所述服务器根据解密后的所述每个第二终端设备的DH公钥，和所述第二随机数，确定用于与所述每个第二终端设备进行认证的所述每个第二终端设备的第一共享密钥。
  21. 根据权利要求14至20中任一项所述的方法，其特征在于，在所述服务器向所述第一终端设备发送第二消息之前，所述方法还包括：
    所述服务器根据第二共享密钥，对所述服务器的DH公钥和所述每个第二终端设备的第二ID进行加密；
    其中，所述服务器向所述第一终端设备发送的所述第二消息中的所述服务器的DH公钥和所述每个第二终端设备的第二ID，是经过所述服务器加密的。
  22. 根据权利要求14至21中任一项所述的方法，其特征在于，所述方法还包括：
    所述服务器接收所述每个第二终端设备发送的所述每个第二终端设备的第二ID，和所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC；
    所述服务器根据所述第一共享密钥，对所述每个第二终端设备的第二ID的MAC进 行验证；
    如果所述服务器对所述每个第二终端设备的第二ID的MAC验证成功，所述服务器向所述每个第二终端设备发送配置完成消息，以及所述服务器为所述配置完成消息生成的所述配置完成消息的MAC。
  23. 一种移动网络的认证方法，其特征在于，所述方法包括：
    第一终端设备接收至少一个第二终端设备发送的迪菲赫尔曼DH公钥和第一身份标识ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；
    所述第一终端设备向网络认证实体发送附着请求消息，其中，所述附着请求消息包括第一消息和所述第一终端设备的身份标识ID，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID；
    所述第一终端设备接收所述网络认证实体基于所述附着请求消息发送的用户认证请求消息，其中，所述用户认证请求消息包括第二消息和认证数据，所述第二消息包括服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
    所述第一终端设备向所述每个第二终端设备发送所述服务器的DH公钥和所述每个第二终端设备的第二ID，以使得所述每个第二终端设备根据所述每个第二终端设备的第二ID和所述服务器的DH公钥，确定用于与所述服务器进行认证的所述每个第二终端设备的第一共享密钥和所述每个第二终端设备的第二ID。
  24. 根据权利要求23所述的方法，其特征在于，所述方法还包括：
    所述第一终端设备接收所述每个第二终端设备发送的所述每个第二终端设备的第二ID，和所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC；
    所述第一终端设备向所述网络认证实体发送所述每个第二终端设备的第二ID，和所述每个第二终端设备的第二ID的MAC；
    所述第一终端设备接收所述网络认证实体基于所述每个第二终端设备的第二ID和所述每个第二终端设备的第二ID的MAC发送的配置完成消息；
    所述第一终端设备向所述每个第二终端设备发送所述配置完成消息。
  25. 根据权利要求23或24所述的方法，其特征在于，所述方法还包括：
    所述第一终端设备基于所述用户认证请求消息，向所述网络认证实体发送用户认证响应消息；
    所述第一终端设备接收所述网络认证实体基于所述认证响应消息发送的认证成功消息。
  26. 根据权利要求23至25中任一项所述的方法，其特征在于，所述服务器包括归属用户服务器HSS。
  27. 根据权利要求23至26中任一项所述的方法，其特征在于，所述网络认证实体包括移动性管理实体MME。
  28. 一种移动网络的认证方法，其特征在于，所述方法包括：
    网络认证实体接收第一终端设备发送的附着请求消息，其中，所述附着请求消息包括第一消息和所述第一终端设备的身份标识ID，所述第一消息包括所述至少一个第二终 端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；
    所述网络认证实体根据所述附着请求消息，向服务器发送认证数据请求消息；
    所述网络认证实体接收所述服务器基于所述认证数据请求消息发送的认证数据响应消息，其中，所述认证数据响应消息包括第二消息和认证向量，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
    所述网络认证实体向所述第一终端设备发送所述第二消息和所述认证向量中的认证数据，以使得所述第一终端设备向所述每个第二终端设备发送所述服务器的DH公钥和所述每个第二终端设备的第二ID。
  29. 根据权利要求28所述的方法，其特征在于，所述方法还包括：
    所述网络认证实体接收所述第一终端设备发送的所述每个第二终端设备的第二ID、所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC，以及所述第一终端设备基于所述用户认证请求消息发送的用户认证响应消息；
    所述网络认证实体向所述服务器发送所述每个第二终端设备的第二ID和所述每个第二终端设备的第二ID的MAC；
    所述网络认证实体接收所述服务器基于所述每个第二终端设备的第二ID和所述每个第二终端设备的第二ID的MAC发送的配置完成消息；
    所述网络认证实体根据所述用户认证响应消息，向所述第一终端设备发送认证成功消息，并向所述第一终端设备发送所述配置完成消息，以使得所述第一终端设备向所述每个第二终端设备发送所述配置完成消息。
  30. 一种移动网络的认证方法，其特征在于，所述方法包括：
    服务器接收网络认证实体发送的认证数据请求消息，所述认证数据请求消息包括第一消息和第一终端设备的身份标识ID，所述第一消息包括至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述至少一个第二终端设备为未持有共享密钥的设备；
    所述服务器确定所述服务器的DH公钥，并为所述每个第二终端设备，生成所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
    所述服务器基于所述认证数据请求消息，确定认证向量；
    所述服务器向所述网络认证实体发送用户认证响应消息，所述用户认证响应消息包括所述第二消息和所述认证向量，所述第二消息包括所述服务器的DH公钥，以及所述每个第二终端设备的第二ID。
  31. 根据权利要求30所述的方法，其特征在于，所述方法包括：
    所述服务器接收所述网络认证实体发送的所述每个第二终端设备的第二ID，和所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC；
    所述服务器根据所述第一共享密钥，对所述每个第二终端设备的第二ID的MAC进行验证；
    如果所述服务器对所述每个第二终端设备的第二ID的MAC验证通过，所述服务器向所述网络认证实体发送配置完成消息。
  32. 一种终端设备，其特征在于，所述终端设备为第一终端设备，所述第一终端设备为已持有共享密钥的设备，所述第一终端设备包括：
    接收模块，用于接收至少一个第二终端设备发送的迪菲赫尔曼DH公钥和第一身份标识ID，所述至少一个第二终端设备为未持有共享密钥的设备；
    发送模块，用于向服务器发送第一消息，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID；
    所述接收模块还用于，接收所述服务器基于所述第一消息发送的第二消息，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
    所述发送模块还用于，向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥，以使得所述每个第二终端设备根据所述每个第二终端设备的第二ID和所述服务器的DH公钥，确定用于与所述服务器进行认证的所述每个第二终端设备的第一共享密钥和所述每个第二终端设备的第二ID。
  33. 根据权利要求32所述的终端设备，其特征在于，所述第一消息还包括指示信息，所述指示信息用于指示所述第一消息用于为所述每个第二终端设备请求所述每个第二终端设备的共享密钥和所述每个第二终端设备第二ID。
  34. 根据权利要求32或33所述的终端设备，其特征在于，在所述第一终端设备向所述服务器发送第一消息之前，所述第一终端设备还包括：
    生成模块，用于根据第二共享密钥，为所述第一消息生成所述第一消息的消息验证码MAC，所述第二共享密钥用于所述第一终端设备与所述服务器之间的认证；
    其中，所述发送模块具体用于：
    向所述服务器发送所述第一消息和所述第一消息的MAC。
  35. 根据权利要求32至34中任一项所述的终端设备，其特征在于，所述接收模块具体用于：
    接收所述服务器发送的所述第二消息，和所述服务器根据第二共享密钥为所述第二消息生成的所述第二消息的MAC；
    其中，所述发送模块具体用于：
    所述第一终端设备根据第二共享密钥，对所述第二消息的MAC进行验证；
    如果所述第一终端设备对所述第二消息的MAC验证通过，所述第一终端设备向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥。
  36. 根据权利要求32至35中任一项所述的终端设备，其特征在于，所述接收模块具体用于：
    接收所述服务器发送的所述第二消息、所述服务器对所述每个第二终端设备的第二ID和所述服务器的DH公钥进行签名后得到的所述每个第二终端设备的签名消息、以及与所述每个第二终端设备的签名消息对应的所述每个第二终端设备的验证信息；
    其中，所述发送模块具体用于：
    向所述每个第二终端设备发送所述每个第二终端设备的第二ID和所述服务器的DH公钥、所述每个第二终端设备的签名消息和所述每个第二终端设备的验证信息。
  37. 根据权利要求36所述的终端设备，其特征在于，所述验证消息包括所述服务器的证书或者所述服务器的ID。
  38. 根据权利要求32至37中任一项所述的终端设备，其特征在于，在所述发送模块向所述服务器发送第一消息之前，所述终端设备还包括：
    加密模块，用于根据第二共享密钥，对所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID进行加密；
    其中，所述发送模块向所述服务器发送的所述第一消息中的所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，是经过所述第一终端设备加密的。
  39. 根据权利要求32至38中任一项所述的终端设备，其特征在于，所述接收模块从所述服务器接收的所述第二消息中的所述每个第二终端设备的第二ID和所述服务器的DH公钥，是经过所述服务器加密的；
    其中，在所述发送模块向所述每个第二终端设备发送所述每个第二终端设备的第二ID，和所述服务器的DH公钥之前，所述终端设备还包括：
    解密模块，用于根据第二共享密钥，对加密后的所述每个第二终端设备的第二ID和所述服务器的DH公钥进行解密；
    所述发送模块具体用于：
    向所述每个第二终端设备发送解密后的所述每个第二终端设备的第二ID和所述服务器的DH公钥。
  40. 根据权利要求32至39中任一项所述的终端设备，其特征在于，所述服务器包括归属用户服务器HSS。
  41. 一种终端设备，其特征在于，所述终端设备为第二终端设备，所述第二终端设备为未持有共享密钥的设备，所述第二终端设备包括：
    确定模块，用于根据第一随机数确定所述第二终端设备的迪菲赫尔曼DH公钥；
    发送模块，用于发送第一消息至第一终端设备，其中，所述第一消息包括所述第二终端设备的DH公钥和所述第二终端设备的第一身份标识ID，所述第一终端设备为已持有共享密钥的设备；
    接收模块，用于接收所述第一终端设备基于所述第一消息发送的第二消息，所述第二消息包括服务器的DH公钥，和所述服务器为所述第二终端设备生成的第二ID，所述第二ID用于标识签约用户；
    所述确定模块还用于，根据所述第一随机数，和所述服务器的DH公钥，确定第一共享密钥；
    认证模块，用于根据所述第一共享密钥和所述第二ID，与所述服务器进行相互认证。
  42. 根据权利要求41所述的终端设备，其特征在于，所述接收模块具体用于：
    接收所述第一终端设备发送的所述第二消息、所述服务器对所述第二消息签名后得到的签名消息、和与所述签名消息对应的验证信息；
    所述确定模块具体用于：
    根据所述第二消息、所述签名消息和所述验证信息，对所述第二消息进行验证；
    如果对所述第二消息验证通过，所述第二终端设备根据所述第一随机数和所述服务器的DH公钥，确定所述第一共享密钥。
  43. 根据权利要求42所述的终端设备，其特征在于，所述验证消息包括所述服务器的证书或者所述服务器的ID。
  44. 根据权利要求41至43中任一项所述的终端设备，其特征在于，所述终端设备 还包括生成模块和验证模块，所述生成模块用于：
    根据所述第一共享密钥，为所述第二ID生成所述第二ID的消息验证码MAC；
    所述发送模块还用于，向所述服务器发送所述第二ID和所述第二ID的MAC；
    所述接收模块还用于，接收所述服务器基于所述第二ID和所述第二ID的MAC发送的配置完成消息，以及所述服务器为所述配置完成消息生成的所述配置完成消息的MAC；
    所述验证模块，用于根据所述第一共享密钥，对所述配置完成消息的MAC进行验证；
    其中，所述认证模块具体用于：
    如果所述验证模块对所述配置完成消息的MAC验证通过，所述第二终端设备根据所述第一共享密钥和所述第二ID，与所述服务器进行相互认证。
  45. 一种服务器，其特征在于，所述服务器包括：
    接收模块，用于接收所述第一终端设备发送的第一消息，其中，所述第一消息包括所述第一终端设备从至少一个第二终端设备中的每个第二终端设备接收的所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；
    确定模块，用于根据第二随机数确定所述服务器的DH公钥，并为所述每个第二终端设备生成所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
    所述确定模块还用于，根据所述每个第二终端设备的DH公钥和所述第二随机数，确定用于与所述每个第二终端设备进行认证的所述每个第二终端设备的第一共享密钥；
    发送模块，用于向所述第一终端设备发送第二消息，所述第二消息包括所述服务器的DH公钥和所述每个第二终端设备的第二ID。
  46. 根据权利要求45所述的服务器，其特征在于，所述第一消息还包括指示信息，所述指示信息用于指示所述第一消息用于为所述每个第二终端设备请求所述第二终端设备的的共享密钥和所述第二终端设备的第二ID。
  47. 根据权利要求45或46所述的服务器，其特征在于，所述接收模块具体用于：
    接收所述第一终端设备发送的所述第一消息，和所述第一终端设备根据第二共享密钥为所述第一消息生成的所述第一消息的消息验证码MAC，所述第二共享密钥用于所述第一终端设备与所述服务器之间的认证；
    其中，确定模块具体用于：
    根据第二共享密钥，对所述第一消息的MAC进行验证；
    如果对所述第一消息的MAC验证通过，根据所述第二随机数和所述服务器的DH公钥，确定用于与所述每个第二终端设备进行认证的每个第二终端设备的第一共享密钥。
  48. 根据权利要求45至47中任一项所述的服务器，其特征在于，在所述发送模块向所述第一终端设备发送第二消息之前，所述服务器还包括：
    生成模块，用于根据第二共享密钥，为所述第二消息生成所述第二消息的MAC；
    其中，所述发送模块具体用于：
    向所述第一终端设备发送所述第二消息和所述第二消息的MAC。
  49. 根据权利要求45至48中任一项所述的服务器，其特征在于，在所述发送模块向所述第一终端设备发送第二消息之前，所述服务器还包括：
    签名模块，用于对所述每个第二终端设备的第二ID和所述服务器的DH公钥进行签名；
    其中，所述发送模块具体用于：
    向所述第一终端设备发送所述第二消息、所述服务器对所述每个第二终端设备的第二ID和所述服务器的DH公钥进行签名后得到所述每个第二终端设备的签名消息、和与所述每个第二终端设备的签名消息对应的所述每个第二终端设备的验证消息。
  50. 根据权利要求49所述的服务器，其特征在于，所述验证消息包括所述服务器的证书或者所述服务器的ID。
  51. 根据权利要求45至50中任一项所述的服务器，其特征在于，所述接收模块从所述第一终端设备接收的所述第一消息中的所述每个第二终端设备的DH公钥，和所述每个第二终端设备的第一ID，是经过所述第一终端设备加密的；
    其中，在所述确定模块根据所述每个第二终端设备的DH公钥，和所述第二随机数，确定用于与所述每个第二终端设备进行认证的每个第二终端设备的第一共享密钥之前，所述服务器还包括：
    解密模块，用于根据第二共享密钥，对加密后的所述每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID进行解密；
    所述确定模块具体用于：
    根据解密后的所述每个第二终端设备的DH公钥，和所述第二随机数，确定用于与所述每个第二终端设备进行认证的所述每个第二终端设备的第一共享密钥。
  52. 根据权利要求45至51中任一项所述的服务器，其特征在于，在所述发送模块向所述第一终端设备发送第二消息之前，所述服务器还包括：
    加密模块，用于根据第二共享密钥，对所述服务器的DH公钥和所述每个第二终端设备的第二ID进行加密；
    其中，所述发送模块向所述第一终端设备发送的所述第二消息中的所述服务器的DH公钥和所述每个第二终端设备的第二ID，是经过所述服务器加密的。
  53. 根据权利要求45至52中任一项所述的服务器，其特征在于，所述服务器还包括验证模块，其中，所述接收模块还用于：
    接收所述每个第二终端设备发送的所述每个第二终端设备的第二ID，和所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC；
    所述验证模块，用于根据所述第一共享密钥，对所述每个第二终端设备的第二ID的MAC进行验证；
    所述发送模块还用于，如果所述验证模块对所述每个第二终端设备的第二ID的MAC验证成功，向所述每个第二终端设备发送配置完成消息，以及所述服务器为所述配置完成消息生成的所述配置完成消息的MAC。
  54. 一种终端设备，其特征在于，所述终端设备为第一终端设备，所述第一终端设备为已持有共享密钥的设备，所述第一终端设备包括：
    接收模块，用于接收至少一个第二终端设备发送的迪菲赫尔曼DH公钥和第一身份标识ID，所述至少一个第二终端设备为未持有共享密钥的设备；
    发送模块，用于向网络认证实体发送附着请求消息，其中，所述附着请求消息包括第一消息和所述第一终端设备的身份标识ID，所述第一消息包括所述至少一个第二终端 设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID；
    所述接收模块还用于，接收所述网络认证实体基于所述附着请求消息发送的用户认证请求消息，其中，所述用户认证请求消息包括第二消息和认证数据，所述第二消息包括服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
    所述发送模块还用于，向所述每个第二终端设备发送所述服务器的DH公钥和所述每个第二终端设备的第二ID，以使得所述每个第二终端设备根据所述每个第二终端设备的第二ID和所述服务器的DH公钥，确定用于与所述服务器进行认证的所述每个第二终端设备的第一共享密钥和所述每个第二终端设备的第二ID。
  55. 根据权利要求54所述的终端设备，其特征在于，所述接收模块还用于：
    接收所述每个第二终端设备发送的所述每个第二终端设备的第二ID，和所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC；
    所述发送模块还用于，向所述网络认证实体发送所述每个第二终端设备的第二ID，和所述每个第二终端设备的第二ID的MAC；
    所述接收模块还用于，接收所述网络认证实体基于所述每个第二终端设备的第二ID和所述每个第二终端设备的第二ID的MAC发送的配置完成消息；
    所述发送模块还用于，向所述每个第二终端设备发送所述配置完成消息。
  56. 根据权利要求54或55所述的终端设备，其特征在于，所述发送模块还用于：
    基于所述用户认证请求消息，向所述网络认证实体发送用户认证响应消息；
    所述接收模块还用于，接收所述网络认证实体基于所述认证响应消息发送的认证成功消息。
  57. 根据权利要求54至56中任一项所述的终端设备，其特征在于，所述服务器包括归属用户服务器HSS。
  58. 根据权利要求54至57中任一项所述的终端设备，其特征在于，所述网络认证实体包括移动性管理实体MME。
  59. 一种网络认证实体，其特征在于，所述网络认证实体包括：
    接收模块，用于接收第一终端设备发送的附着请求消息，其中，所述附着请求消息包括第一消息和所述第一终端设备的身份标识ID，所述第一消息包括所述至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述第一终端设备为已持有共享密钥的设备，所述至少一个第二终端设备为未持有共享密钥的设备；
    发送模块，用于根据所述附着请求消息，向服务器发送认证数据请求消息；
    所述接收模块还用于，接收所述服务器基于所述认证数据请求消息发送的认证数据响应消息，其中，所述认证数据响应消息包括第二消息和认证向量，所述第二消息包括所述服务器的DH公钥，以及所述服务器为所述每个第二终端设备生成的所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
    所述发送模块还用于，向所述第一终端设备发送所述第二消息和所述认证向量中的认证数据，以使得所述第一终端设备向所述每个第二终端设备发送所述服务器的DH公钥和所述每个第二终端设备的第二ID。
  60. 根据权利要求59所述的网络认证实体，其特征在于，所述接收模块还用于：
    接收所述第一终端设备发送的所述每个第二终端设备的第二ID、所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC，以及所述第一终端设备基于所述用户认证请求消息发送的用户认证响应消息；
    所述发送模块还用于，向所述服务器发送所述每个第二终端设备的第二ID和所述每个第二终端设备的第二ID的MAC；
    所述接收模块还用于，接收所述服务器基于所述每个第二终端设备的第二ID和所述每个第二终端设备的第二ID的MAC发送的配置完成消息；
    所述发送模块还用于，根据所述用户认证响应消息，向所述第一终端设备发送认证成功消息，并向所述第一终端设备发送所述配置完成消息，以使得所述第一终端设备向所述每个第二终端设备发送所述配置完成消息。
  61. 一种服务器，其特征在于，所述服务器包括：
    接收模块，用于接收网络认证实体发送的认证数据请求消息，所述认证数据请求消息包括第一消息和第一终端设备的身份标识ID，所述第一消息包括至少一个第二终端设备中的每个第二终端设备的DH公钥和所述每个第二终端设备的第一ID，所述至少一个第二终端设备为未持有共享密钥的设备；
    确定模块，用于确定所述服务器的DH公钥，并为所述每个第二终端设备，生成所述每个第二终端设备的第二ID，所述第二ID用于标识签约用户；
    所述确定模块还用于，基于所述认证数据请求消息，确定认证向量；
    所述发送模块，用于向所述网络认证实体发送用户认证响应消息，所述用户认证响应消息包括所述第二消息和所述认证向量，所述第二消息包括所述服务器的DH公钥，以及所述每个第二终端设备的第二ID。
  62. 根据权利要求61所述的服务器，其特征在于，所述服务器还包括验证模块，其中，所述接收模块用于：
    接收所述网络认证实体发送的所述每个第二终端设备的第二ID，和所述每个第二终端设备为所述每个第二终端设备的第二ID生成的消息验证码MAC；
    所述验证模块，用于根据所述第一共享密钥，对所述每个第二终端设备的第二ID的MAC进行验证；
    所述发送模块用于，如果所述验证模块对所述每个第二终端设备的第二ID的MAC验证通过，向所述网络认证实体发送配置完成消息。
PCT/CN2017/092429 2016-09-09 2017-07-11 移动网络的认证方法、终端设备、服务器和网络认证实体 WO2018045817A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP17847990.3A EP3493502B1 (en) 2016-09-09 2017-07-11 Supplying an iot-device with an authentication key
US16/297,231 US11026084B2 (en) 2016-09-09 2019-03-08 Mobile network authentication method, terminal device, server, and network authentication entity

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610814492.7 2016-09-09
CN201610814492.7A CN107809411B (zh) 2016-09-09 2016-09-09 移动网络的认证方法、终端设备、服务器和网络认证实体

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/297,231 Continuation US11026084B2 (en) 2016-09-09 2019-03-08 Mobile network authentication method, terminal device, server, and network authentication entity

Publications (1)

Publication Number Publication Date
WO2018045817A1 true WO2018045817A1 (zh) 2018-03-15

Family

ID=61562682

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/092429 WO2018045817A1 (zh) 2016-09-09 2017-07-11 移动网络的认证方法、终端设备、服务器和网络认证实体

Country Status (4)

Country Link
US (1) US11026084B2 (zh)
EP (1) EP3493502B1 (zh)
CN (1) CN107809411B (zh)
WO (1) WO2018045817A1 (zh)

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10700856B2 (en) * 2013-11-19 2020-06-30 Network-1 Technologies, Inc. Key derivation for a module using an embedded universal integrated circuit card
CN110383755B (zh) * 2017-01-05 2022-04-19 皇家飞利浦有限公司 网络设备和可信第三方设备
CN110621019A (zh) * 2018-06-20 2019-12-27 华为技术有限公司 一种防止流量欺诈的方法及装置
JP7185978B2 (ja) * 2018-07-03 2022-12-08 株式会社ソラコム 認証情報の設定を仲介するための装置及び方法
US10757572B2 (en) * 2018-11-01 2020-08-25 Qualcomm Incorporated Identity based signature in system information protection
CN113228721B (zh) 2018-12-29 2022-08-26 华为技术有限公司 通信方法和相关产品
DE102019204951A1 (de) * 2019-04-08 2020-10-08 Osram Gmbh Verfahren zum sicheren austauschen von nachrichten zwischen endgeräten in einem netzwerk
CN111835508B (zh) * 2019-04-23 2023-02-28 深圳市汇顶科技股份有限公司 一种密钥分配部署方法和系统
CN110176994A (zh) * 2019-05-30 2019-08-27 全链通有限公司 基于联盟区块链的会话密钥分发方法、设备及存储介质
CN110138558B (zh) * 2019-05-30 2021-09-10 全链通有限公司 会话密钥的传输方法、设备及计算机可读存储介质
CN110048842B (zh) * 2019-05-30 2021-09-10 全链通有限公司 会话密钥处理方法、设备及计算机可读存储介质
CN110176993A (zh) * 2019-05-30 2019-08-27 全链通有限公司 基于联盟区块链的会话密钥分发方法、设备及存储介质
CN110225011B (zh) * 2019-05-30 2021-07-13 全链通有限公司 用户节点的认证方法、设备及计算机可读存储介质
CN110048843B (zh) * 2019-05-30 2021-09-10 全链通有限公司 会话密钥传输方法、设备及计算机可读存储介质
EP3745640A1 (en) * 2019-05-31 2020-12-02 Siemens Aktiengesellschaft Establishing secure communication without local time information
CN110299994B (zh) * 2019-06-28 2022-03-22 苏州浪潮智能科技有限公司 一种数据处理方法、系统、设备及计算机可读存储介质
CN110337101B (zh) * 2019-07-16 2022-02-08 恒宝股份有限公司 一种号码资源的远程配置方法
CN111314274B (zh) * 2019-07-30 2023-02-10 厦门雅迅网络股份有限公司 一种车载终端与中心平台双向认证方法及系统
CN110505619B (zh) * 2019-09-12 2022-04-01 恒宝股份有限公司 一种eSIM远程配置中的数据传输方法
US10764746B1 (en) * 2019-10-28 2020-09-01 Sprint Communications Company L.P. Electronic subscriber identity module (eSIM) transfer from inactive device
US11146948B1 (en) 2019-11-05 2021-10-12 Sprint Communications Company L.P. Electronic subscriber identity module (eSIM) transfer via activation code
US11265301B1 (en) * 2019-12-09 2022-03-01 Amazon Technologies, Inc. Distribution of security keys
CN111083131B (zh) * 2019-12-10 2022-02-15 南瑞集团有限公司 一种用于电力物联网感知终端轻量级身份认证的方法
US11599671B1 (en) 2019-12-13 2023-03-07 TripleBlind, Inc. Systems and methods for finding a value in a combined list of private values
US11431688B2 (en) 2019-12-13 2022-08-30 TripleBlind, Inc. Systems and methods for providing a modified loss function in federated-split learning
US11146944B1 (en) 2020-02-20 2021-10-12 Sprint Communications Company L.P. Mobile phone peer-to-peer electronic subscriber identity module (eSIM) transfer
CN111726782B (zh) * 2020-05-22 2023-12-29 浙江吉利汽车研究院有限公司 一种安全认证方法及系统
CN114521260A (zh) * 2020-08-27 2022-05-20 华为技术有限公司 在不可信存储系统中进行数据去重和压缩的方法和系统
GB2600500B (en) * 2020-10-22 2023-01-11 Kigen Uk Ltd An apparatus and method for managing the provisioning of security modules
EP4241415A1 (en) * 2020-11-05 2023-09-13 Signify Holding B.V. A method of, a provisioner and a system for provisioning a plurality of operatively interconnected node devices in a network
CN112491549A (zh) * 2020-12-08 2021-03-12 平安国际智慧城市科技股份有限公司 数据信息加密校验方法、系统及计算机可读存储介质
CN114760028A (zh) * 2020-12-26 2022-07-15 西安西电捷通无线网络通信股份有限公司 一种身份鉴别方法和装置
WO2023009588A1 (en) 2021-07-27 2023-02-02 TripleBlind, Inc. Systems and methods for providing a multi-party computation system for neural networks
WO2024086997A1 (en) * 2022-10-24 2024-05-02 Nokia Shanghai Bell Co., Ltd. Method and apparatus for device validation in wireless local area network
CN115442807B (zh) * 2022-11-10 2023-02-07 之江实验室 一种用于5g系统的用户安全性提升方法及装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101052033A (zh) * 2006-04-05 2007-10-10 华为技术有限公司 基于ttp的认证与密钥协商方法及其装置

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001060013A1 (en) * 2000-02-08 2001-08-16 Swisscom Mobile Ag Single sign-on process
US7783041B2 (en) * 2005-10-03 2010-08-24 Nokia Corporation System, method and computer program product for authenticating a data agreement between network entities
US7861078B2 (en) * 2005-10-14 2010-12-28 Juniper Networks, Inc. Password-authenticated asymmetric key exchange
CN102638794B (zh) * 2007-03-22 2016-03-30 华为技术有限公司 鉴权和密钥协商方法、认证方法、系统及设备
CN101656956B (zh) * 2008-08-22 2012-05-23 华为技术有限公司 一种接入3gpp网络的方法、系统和网关
CN102158860B (zh) * 2010-02-12 2014-05-21 华为技术有限公司 无线节点入网方法、系统及中继节点
US9037112B2 (en) 2010-03-15 2015-05-19 Samsung Electronics Co., Ltd. Method and system for secured remote provisioning of a universal integrated circuit card of a user equipment
US8627422B2 (en) * 2010-11-06 2014-01-07 Qualcomm Incorporated Authentication in secure user plane location (SUPL) systems
EP2712222B1 (en) 2012-09-25 2020-04-01 Alcatel Lucent Confidential provisioning of secret keys over the air
US9350550B2 (en) 2013-09-10 2016-05-24 M2M And Iot Technologies, Llc Power management and security for wireless modules in “machine-to-machine” communications
JP6254675B2 (ja) * 2014-02-18 2017-12-27 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 認証方法及び認証システム
US9628273B2 (en) * 2014-04-30 2017-04-18 Thamir Alshammari Cryptographic method and system for secure authentication and key exchange
US10326590B2 (en) * 2014-11-11 2019-06-18 Intel Corporation Technologies for trusted device on-boarding
EP3038393A1 (en) 2014-12-23 2016-06-29 Gemalto M2M GmbH Method for connecting to a visited cellular network based on a second subscriber identity and mobile station for executing said method

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101052033A (zh) * 2006-04-05 2007-10-10 华为技术有限公司 基于ttp的认证与密钥协商方法及其装置

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
HUAWEI ET AL.: "Group Provisioning for IoT Devices via a Companion UE", 3GPP TSG SA WG3 (SECURITY) MEETING #85 S3-161785, 11 November 2016 (2016-11-11), XP051170636 *
HUAWEI ET AL.: "Remote Provisioning for IoT Devices through a Companion UE", 3GPP TSG SA WG3 (SECURITY) MEETING #84 S3-161004, 29 July 2016 (2016-07-29), XP051122021 *
HUAWEI ET AL.: "Remote Provisioning for IoT Devices without Initial Credentials", 3GPP TSG SAWG3 (SECURITY) MEETING #85 S3-161726, 11 November 2016 (2016-11-11), XP051185806 *
HUAWEI ET AL.: "Secure Mechanism to Achieve Remote Credential Provisioning for IoT devices", 3GPP TSG SA WG3 (SECURITY) MEETING #84 S3-161000, 29 July 2016 (2016-07-29), XP051122017 *
See also references of EP3493502A4 *

Also Published As

Publication number Publication date
EP3493502B1 (en) 2021-06-09
CN107809411A (zh) 2018-03-16
CN107809411B (zh) 2021-12-03
US20190208417A1 (en) 2019-07-04
EP3493502A1 (en) 2019-06-05
US11026084B2 (en) 2021-06-01
EP3493502A4 (en) 2019-06-26

Similar Documents

Publication Publication Date Title
US11026084B2 (en) Mobile network authentication method, terminal device, server, and network authentication entity
US10601594B2 (en) End-to-end service layer authentication
US9565172B2 (en) Method for enabling a secure provisioning of a credential, and related wireless devices and servers
KR102116399B1 (ko) 서비스 레이어에서의 콘텐츠 보안
KR102134302B1 (ko) 무선 네트워크 접속 방법 및 장치, 및 저장 매체
JP5432156B2 (ja) Ｕｉｃｃと端末との間のセキュア通信方法
WO2017185999A1 (zh) 密钥分发、认证方法，装置及系统
US11044084B2 (en) Method for unified network and service authentication based on ID-based cryptography
US20150244685A1 (en) Generalized cryptographic framework
CN111865603A (zh) 认证方法、认证装置和认证系统
US20230014894A1 (en) Quantum resistant secure key distribution in various protocols and technologies
WO2019034014A1 (zh) 接入认证的方法和装置
Xu et al. BE-RAN: Blockchain-enabled open RAN with decentralized identity management and privacy-preserving communication
CN109076058B (zh) 一种移动网络的认证方法和装置
BR112021003448A2 (pt) dispositivo sem identidade de assinante, dispositivo de identidade do assinante, método para uso em um dispositivo sem identidade de assinante, método para uso em um dispositivo com identidade de assinante e produto de programa de computador transferível por download
CN104243452A (zh) 一种云计算访问控制方法及系统
US20200403780A1 (en) Secure Communications Using Network Access Identity
Ouaissa et al. A Secure Model for Machine to Machine Device Domain Based Group in a Smart City Architecture.
Singh et al. Elliptic curve cryptography based mechanism for secure Wi-Fi connectivity
KR20080056055A (ko) 통신 사업자간 로밍 인증방법 및 키 설정 방법과 그 방법을포함하는 프로그램이 저장된 기록매체
KR102345093B1 (ko) 무선 인터넷의 보안 세션 제어 시스템 및 보안 세션 제어 방법
JP6609212B2 (ja) 暗号化通信チャネル確立システム、方法、プログラム及びコンピュータ読取り可能なプログラム記録媒体
CN116321158A (zh) 基于证书的本地ue认证
Suman A novel authentication algorithm for vertical handoff in heterogeneous wireless networks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17847990

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017847990

Country of ref document: EP

Effective date: 20190301