WO2020029735A1 - 扩展的通用引导架构认证方法、装置及存储介质 - Google Patents

扩展的通用引导架构认证方法、装置及存储介质 Download PDF

Info

Publication number
WO2020029735A1
WO2020029735A1 PCT/CN2019/095193 CN2019095193W WO2020029735A1 WO 2020029735 A1 WO2020029735 A1 WO 2020029735A1 CN 2019095193 W CN2019095193 W CN 2019095193W WO 2020029735 A1 WO2020029735 A1 WO 2020029735A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
network element
terminal
eap
tid
Prior art date
Application number
PCT/CN2019/095193
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 EP19848561.7A priority Critical patent/EP3817271A4/en
Publication of WO2020029735A1 publication Critical patent/WO2020029735A1/zh
Priority to US17/169,737 priority patent/US20210165885A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • 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/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device 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/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0863—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving passwords or one-time passwords
    • 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/321—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 a third party or a trusted authority
    • H04L9/3213—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 a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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/3226—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 using a predetermined code, e.g. password, passphrase or PIN
    • 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/3236—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 using cryptographic hash functions
    • H04L9/3242—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 using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • 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/3271—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 using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]

Definitions

  • the present application relates to the field of communication technologies, and in particular, to an extended universal boot architecture authentication method, device, and storage medium.
  • GBA generalized bootstrapping architecture
  • UE User Equipment
  • NAF Network Application Server
  • GBA technology includes GBA authentication and key agreement (AKA) authentication.
  • 3GPP TS33.220 has given specific definitions of GBA and AKA certification.
  • GBA AKA certification the UE and the Bootstrapping Server Function (BSF) complete the GBA AKA certification based on the HyperText Transfer Protocol (HTTP).
  • HTTP HyperText Transfer Protocol
  • This application provides an extended universal boot architecture authentication method, device, and storage medium to enable the UE and BSF to complete GBA and AKA authentication based on EAP.
  • the present application provides an extended universal boot architecture authentication method, including: a first network element obtaining a B-TID and a key lifetime; the first network element sending the B-TID and a key lifetime to the terminal so that the terminal can -TID and Key lifetime, perform EAP-based GBA and AKA authentication with the first network element.
  • the beneficial effects of this application include: Since the extended universal boot architecture authentication method provided in this application is based on EAP, the UE and the BSF can complete GBA and AKA authentication based on EAP.
  • the obtaining of the B-TID by the first network element may include: the first network element generates a B-TID according to the RAND and the BSF server name; or the first network element generates an identifier and uses the identifier as the B-TID.
  • the first network element sending the B-TID and the key lifetime to the terminal includes: the first network element sends an EAP request AKA challenge message to the terminal, where the EAP request AKA challenge message carries the B-TID and key lifetime. That is, the B-TID and Key lifetime are transmitted through the AKA challenge message requested by the EAP.
  • the method provided in this application may further include: the first network element receives the RES and MAC sent by the terminal, and performs verification of the RES and MAC; On success, the first network element generates a key and sends an EAP-success message to the terminal to complete the EAP-based GBA and AKA authentication.
  • the method further includes: the first network element receives the identifier of the terminal sent by the terminal.
  • the method further includes that the first network element obtains the RAND, AUTN, and MAC in any of the following ways:
  • Method 1 The first network element executes the AKA algorithm to generate RAND, AUTN, and MAC;
  • Manner 2 The first network element receives RAND, AUTN, and MAC.
  • the first network element receiving the identity of the terminal sent by the terminal may include: the first network element receives the identity of the terminal sent by the second network element, and the identity of the terminal is sent by the terminal after receiving the second network element After the EAP request message is sent to the second network element.
  • the EAP request message is used to request the identity of the terminal.
  • the present application provides an extended universal boot architecture authentication method, including: a terminal receiving a B-TID and a Keylifetime sent by a first network element; the terminal performing a GBA and AKA certification for EAP.
  • the beneficial effects of this application include: Since the extended universal boot architecture authentication method provided in this application is based on EAP, the UE and the BSF can complete GBA and AKA authentication based on EAP.
  • the terminal receiving the B-TID and Key lifetime sent by the first network element may include: the terminal receiving the AKA challenge message of the EAP request sent by the first network element, and the AKA challenge message of the EAP request carries the B-TID and Key lifetime.
  • the terminal performs EAP-based GBA authentication with the first network element according to the B-TID and Key lifetime, including: the terminal acquires RAND, AUTN, and MAC; the terminal executes the AKA algorithm to verify AUTN and MAC; the terminal generates RES and secret The terminal sends the RES and MAC to the first network element, so that the first network element performs the RES and MAC verification. If the verification is successful, the first network element generates a key and sends an EAP-success message to the terminal. Receive an EAP-success message.
  • the method further includes: the terminal sends the terminal identifier to the first network element.
  • the terminal sending the identity of the terminal to the first network element includes: the terminal sending the identity of the terminal to the second network element, so that the second network element sends the identity of the terminal to the first network element.
  • the method further includes: the terminal receives an EAP request message sent by the second network element, where the EAP request message is used to request the identity of the terminal.
  • the B-TID can also be used to determine the BSF address and / or key.
  • the B-TID and Key lifetime are protected by the MAC.
  • the terminal and the first network element send and receive information through the second network element, and the information here includes, but is not limited to, the B-TID and Key Lifetime described above.
  • the identity of the terminal may be a permanent identity or a temporary identity, including any one of the following: SUPI, SUCI, IMSI, IMPI, TMPI, GUTI, TMSI, IMPU, App ID, network identity, service identity, and NAI.
  • the present application provides a key generation method, including: obtaining a key parameter, the key parameter including: at least one of CK and IK, EMSK, MSK; and generating a key according to the key parameter.
  • generating the key according to the key parameter includes any of the following implementation manners:
  • Ks represents the generated key.
  • generating the key according to the key parameter includes generating a key based on a basic key generated in the authentication process, where the basic key includes at least one of CK
  • generating the key based on the basic key generated in the authentication process may include: generating the key Ks in the following manner, and the specific derivation formula is as follows:
  • Ks KDF (base key), where KDF represents a key derivation function
  • Ks KDF (base key, BSF ID);
  • Ks KDF (base key, SN ID), where SN ID represents the service network ID;
  • Ks KDF (base key, SN ID, BSF ID).
  • any of the above derivation formulas may further include: an indication indicating a protocol type, and the protocol type includes at least one of the following: EAP, EAP, AKA, EAP, AKA ', 5G, 5G, AKA, GBA, 5G, and GBA.
  • any of the above derivation formulas further includes at least one of the following parameters: UE ID, session ID, EAP server ID, Authenticator ID, uplink or downlink counter, sequence number, and nonce.
  • the present application provides an extended universal boot architecture authentication device, including: the device has a function of realizing the behavior of the first network element in the first aspect or the optional method of the first aspect in practice.
  • the functions may be implemented by hardware, and may also be implemented by hardware executing corresponding software.
  • the hardware or software includes one or more modules corresponding to the functions described above.
  • the present application provides an extended universal boot architecture authentication device, including: the device has a function of implementing the behavior of the terminal in the second aspect or the optional method of the second aspect in practice.
  • the functions may be implemented by hardware, and may also be implemented by hardware executing corresponding software.
  • the hardware or software includes one or more modules corresponding to the functions described above.
  • the present application provides a key generation device, including: the device has a function of implementing the key generation behavior in the third aspect or the optional method of the third aspect in practice.
  • the functions may be implemented by hardware, and may also be implemented by hardware executing corresponding software.
  • the hardware or software includes one or more modules corresponding to the functions described above.
  • the present application provides an extended universal boot architecture authentication device.
  • the structure of the device includes a processor and a transceiver.
  • the processor is configured to support the device to execute the first aspect or the first aspect.
  • the transceiver is configured to support communication between the device and the terminal, and transmit and receive information or instructions involved in the foregoing method.
  • the device may further include a memory for coupling with the processor, which stores program instructions and data necessary for the device.
  • the present application provides an extended universal boot architecture authentication device.
  • the structure of the device includes a processor and a transceiver.
  • the processor is configured to support the device to execute the second aspect or the second aspect.
  • the transceiver is configured to support communication between the device and the first network element, and transmit and receive information or instructions involved in the foregoing method.
  • the device may further include a memory for coupling with the processor, which stores program instructions and data necessary for the device.
  • the present application provides a key generation device.
  • a structure of the device includes a processor and a memory.
  • the processor is configured to support the device to execute the third aspect or the optional method of the third aspect.
  • the memory is used for coupling with a processor, and it stores program instructions and data necessary for the device.
  • the present application provides a computing storage medium including program instructions, and the program instructions are used to implement the universal boot architecture authentication method of the first aspect or an optional extension of the first aspect.
  • the present application provides a computing storage medium including program instructions, and the program instructions are used to implement an extended universal boot architecture authentication method such as the second aspect or the second aspect.
  • the present application provides a computing storage medium including program instructions, and the program instructions are used to implement the key generation method in the third aspect or an optional manner of the third aspect.
  • the present application provides a computer program product including program instructions, and the program instructions are used to implement the universal boot architecture authentication method of the first aspect or an optional extension of the first aspect.
  • the present application provides a computer program product including program instructions.
  • the program instructions are used to implement an extended universal boot architecture authentication method as in the second aspect or an optional manner of the second aspect.
  • the present application provides a computer program product including program instructions, the program instructions being used to implement the key generation method in the third aspect or an optional manner of the third aspect.
  • the present application provides an extended universal boot architecture authentication method, device, and storage medium.
  • the extended universal boot architecture authentication method provided in this application is based on EAP
  • the UE and BSF can be made to complete GBA and AKA authentication based on EAP.
  • the present application also provides a key generation method, which expands a key generation method.
  • FIG. 1 is a schematic diagram of an existing GBA architecture
  • FIG. 2 shows a possible protocol stack format between the UE and the BSF
  • FIG. 3 shows another possible protocol stack format between the UE and the BSF
  • FIG. 5A illustrates a message format
  • 5B is a message format provided by an embodiment of the present application.
  • FIG. 6A is a message format including a B-TID according to an embodiment of the present application.
  • 6B is another message format including a B-TID according to an embodiment of the present application.
  • FIG. 7A is a message format including a Key Lifetime according to an embodiment of the present application.
  • FIG. 7B is another message format including a Key lifetime provided by an embodiment of the present application.
  • FIG. 8 is a flowchart of an extended universal boot architecture authentication method according to another embodiment of the present application.
  • FIG. 9 shows a message format of an existing EAP success message
  • FIG. 10 is a flowchart of an extended universal boot architecture authentication method according to another embodiment of the present application.
  • FIG. 11 is a flowchart of an extended universal boot architecture authentication method according to another embodiment of the present application.
  • FIG. 13 is a flowchart of an extended universal boot architecture authentication method according to another embodiment of the present application.
  • FIG. 14 is a schematic block diagram of an extended universal boot architecture authentication device according to an embodiment of the present application.
  • 15 is a schematic block diagram of an extended universal boot architecture authentication device according to another embodiment of the present application.
  • 16 is a schematic block diagram of an extended universal boot architecture authentication device according to another embodiment of the present application.
  • FIG. 17 is a schematic block diagram of an extended universal boot architecture authentication device according to another embodiment of the present application.
  • FIG. 1 is a schematic diagram of the existing GBA architecture.
  • the GBA architecture includes: BSF, UE, NAF, and Subscriber Locator Function (SLF).
  • BSF as an intermediate hub, interacts with the UE through the Ub interface to perform authentication between the UE and the BSF;
  • the ZS interface can obtain UE authentication-related parameters from the HSS, and the HSS stores UE-related authentication parameters; NAF interaction; interaction with the SLF through the Dz interface.
  • the BSF can obtain the HSS name corresponding to the UE from the SLF.
  • the UE interacts with NAF through the Ua interface. Since each application corresponds to a NAF, the BSF and the UE may interact with multiple NAFs.
  • the participants include UE, BSF, and HSS.
  • the key negotiation of Ks between UE and BSF is implemented. Bootstrapping), a shared key is established between the BSF and the UE.
  • the UE and BSF complete the GBA and AKA authentication based on HTTP.
  • IK BSF sends B-TID and Key lifetime to UE, where BSF generates B-TID based on RAND and BSF server name, ie base64encode (RAND) @BSF_servers_domain_name, base64encode (RAND) represents Base64 encoding conversion for RAND; UE calculates Ks CK
  • FIG. 2 shows a possible protocol stack format between the UE and the BSF. From this protocol stack, it can also be seen that the existing GBA and AKA authentication is based on HTTP.
  • the existing EAP AKA authentication process can refer to RFC4187, which mainly includes three entities:
  • the authenticatee the entity participating in the authentication, which can be a terminal device such as UE or Internet of Things (IoT);
  • UE User Equipment
  • IoT Internet of Things
  • Authenticator An authenticator who participates in EAP AKA authentication and can perform preliminary authentication for entities such as access points. In this process, the authenticator mainly performs tasks such as data forwarding;
  • EAP server Authentication server that performs authentication for Peer.
  • the EAP AKA authentication process is described as follows:
  • the Authenticator sends an EAP request message to the Peer, which is used to request the identity of the Peer;
  • Peer sends a UE ID (for example, a Network Access Identifier (NAI)) to the Authenticator;
  • UE ID for example, a Network Access Identifier (NAI)
  • the Authenticator sends the UE ID to the EAP server.
  • the EAP server executes the AKA algorithm to generate the RAND, AUTN, and Message Authentication Code (MAC), and sends the RAND, AUTN, and MAC to the Authenticator;
  • MAC Message Authentication Code
  • Authenticator sends RAND, AUTN and MAC to Peer;
  • Peer executes the AKA algorithm to verify AUTN and MAC; and generates RES and session key (session key);
  • Peer sends RES and MAC to Authenticator
  • Authenticator sends RES and MAC to EAP server; EAP server performs RES and MAC authentication. If the authentication is successful, send an EAP-success message to the Authenticator;
  • the Authenticator sends an EAP-success message to Peer.
  • the MAC sent by Authenticator to Peer is different from the MAC sent by Peer to Authenticator.
  • FIG. 3 shows another possible protocol stack format between the UE and the BSF. But the authentication process only includes the transfer of RAND, AUTN and MAC. Because EAP is a very widely used protocol, and it also includes EAP extension protocol (RFC5448), such as EAP, AKA, or other EAP authentications such as EAP-SIM, this application does not limit this; and EAP extension will also be applied in the future 5G Therefore, if the EAP is extended to support GBA and AKA authentication, it is necessary to add B-TID and Keylifetime sending methods to the existing EAP and AKA authentication process. In addition, in order to support other authentication methods, such as 5G AKA, etc., this application will also improve the existing GBA authentication protocol.
  • EAP extension protocol RCC5448
  • this application provides an extended GBA authentication method, device, and storage medium, including an EAP-based GBA AKA authentication scheme, and a new key derivation method.
  • the EAP-based GBA AKA authentication scheme is to add the transfer of B-TID and Key lifetime to the above EAP AKA or EAP AKA authentication, so that the UE and BSF complete the GBA AKA authentication based on the EAP.
  • there are multiple authentication methods that support EAP such as EAP, AKA or EAP, AKA's evolution protocol, EAP-TLS, or EAP, PSK, EAP, IKEv2, etc.
  • the lifetime process implements the GBA authentication function.
  • the key shared by the two parties can be used as Ks after the negotiation of the above authentication method, or Ks can be further derived.
  • the following only uses the EAP AKA process as an example.
  • B-TID and Key lifetime are two parameters
  • this application supports three processing and distribution methods for B-TID, or Key lifetime, or B-TID and Key lifetime. The following will describe the process of B-TID and Key lifetime together.
  • the other processes for processing and distributing B-TIDs are to remove the parts involved in the key lifetime in the following processes, which will not be described here.
  • the other processes for processing and distributing the Keylifetime are to remove the parts involved in the B-TID in the following process, which will not be described here.
  • the EAP-based GBA AKA authentication scheme provided in this application still mainly includes three entities: Peer, Authenticator, and EAP server.
  • FIG. 4 is a flowchart of an extended universal boot architecture authentication method according to an embodiment of the present application. As shown in Figure 4, the method includes the following steps:
  • the Authenticator sends an EAP request message to Peer.
  • the EAP request message is used to request the identity of the Peer.
  • Peer receives the EAP request message and responds to it, and executes S402.
  • S401 is an optional step. In the following embodiments, this step can be omitted, that is, the entire GBA authentication process can start from S402.
  • Peer sends a UE ID to the Authenticator.
  • the UE ID may be a permanent ID or a temporary ID, including but not limited to any of the following: a user permanent identifier (Subscription, permanent identifier, SUPI), a user sealed identifier (Subscription, Concealed identifier, SUCI), and an international mobile user identifier (International Mobile Subscriber Identity, IMSI), IP Multimedia Private Identity (IMPI), Temporary IP Multimedia Private ID (Temporary IP Multimedia Private Identity, TMPI), Globally Unique Temporary Identity (Globally Unique Temporary Identifier, GUTI), Temporary Mobile Station Identity (TMSI), IP Multimedia Public Identity (IMPU), Application Identity (App ID), Network Identity (Network ID), Service Identity (service ID), NAI, etc.
  • IMSI International Mobile Subscriber Identity
  • IMPI IP Multimedia Private Identity
  • TMPI Temporary IP Multimedia Private ID
  • TMPI Temporary IP Multimedia Private ID
  • GUTI Globally Unique Temporary Identity
  • TMSI Temporary Mobile Station Identity
  • the UEID may be a server ID; if the UE ID is an encrypted identifier, such as SUCI, the subsequent EAP server may decrypt the UE ID by itself to obtain the identifier before the UE is encrypted, such as SUPI; or send UE ID to other network elements, and obtain the identity before UE encryption, such as SUPI, from other network elements.
  • the Authenticator receives the UE ID and executes S403.
  • the Authenticator sends a UE ID to the EAP server.
  • the EAP server receives the UE ID and executes S404.
  • the EAP server executes the AKA algorithm to generate RAND, AUTN, and MAC; and generates B-TID and Key lifetime.
  • B-TID is Bootstrapping Transaction Identifier, which is the leading transaction ID.
  • the B-TID may be referred to as a transaction ID, an identification ID, a first ID, a GBA session ID, and other names.
  • the EAP server executes the AKA algorithm, and the method of obtaining RAND, AUTN, and MAC is not limited.
  • the EAP server can obtain related authentication vectors from other network elements, including RAND, AUTN, and MAC; or the EAP server itself executes the AKA algorithm to generate RAND, AUTN, and MAC.
  • the B-TID function is capable of determining a BSF address and / or a key Ks according to the B-TID.
  • the content of MAC integrity protection includes B-TID and Key lifetime.
  • the EAP server sends RAND, AUTN, MAC, B-TID and Key lifetime to the Authenticator.
  • the EAP server carries the RAND, AUTN, MAC, B-TID, and Keylifetime in messages such as the AKA Challenge (AKA-Challenge) message sent by the EAP, and the application does not limit the carrying of RAND, AUTN, MAC, B- The specific name of the TID and Keylifetime message.
  • AKA Challenge AKA-Challenge
  • the Authenticator receives RAND, AUTN, MAC, B-TID and Key lifetime, and executes S406.
  • the Authenticator sends RAND, AUTN, MAC, B-TID and Key lifetime to Peer.
  • Peer receives RAND, AUTN, MAC, B-TID and Key lifetime, and executes S407.
  • Peer executes the AKA algorithm, verifies AUTN and MAC, and generates RES and key.
  • Peer sends RES and MAC to the Authenticator.
  • Peer sends the RES and MAC to the Authenticator in messages such as the AKA-Challenge message of the EAP-response, and this application does not limit the specific name of the message carrying the RES and MAC.
  • the Authenticator receives the RES and the MAC, and executes S409.
  • the Authenticator sends the RES and MAC to the EAP server.
  • the EAP server receives the RES and MAC, and executes S410.
  • the EAP server performs verification of the RES and MAC; if the authentication is successful, the EAP server generates a key.
  • the EAP server sends an EAP-success message to the Authenticator.
  • the Authenticator receives the EAP-success message and executes S412.
  • the Authenticator sends an EAP-success message to Peer.
  • Peer receives the EAP-success message and completes GBA and AKA authentication.
  • MAC-related operations in the processes of all embodiments of this application are optional.
  • the MAC may also not be calculated, transmitted, and verified.
  • the Authenticator network element may not be deployed.
  • an EAP server generates a key in this application.
  • the EAP server can generate a key in the following manner, and the specific derivation formula is as follows:
  • the key Ks is generated based on the key generated during the authentication process, for example, at least one of CK
  • Ks KDF (base key), where KDF stands for Key Derivation Function
  • Ks KDF (base key, BSF ID);
  • Ks KDF (basic key, SN ID), where SN ID represents a serving network (Serving network) ID;
  • Ks KDF (base key, SN ID, BSF ID);
  • the above-mentioned basic key is a key obtained by the EAP server during the authentication process, for example, at least one of CK
  • the above derivation formula may further include an indication indicating a protocol type, for example, indicating at least one of the following protocol indications, such as EAP, EAP, AKA, EAP, AKA ', 5G, 5G, AKA, GBA, 5G, and GBA.
  • protocol indications such as EAP, EAP, AKA, EAP, AKA ', 5G, 5G, AKA, GBA, 5G, and GBA.
  • the above derivation formula may also include at least one of the following parameters, such as UE ID, session ID, EAP server ID, Authenticator ID, uplink or downlink counter, sequence number, nonce, etc. If some of the above parameters are only parameters owned by the EAP server, they need to be sent to Peer, such as session ID, EAP server ID, Authenticator ID, uplink or downlink counter, sequence number or nonce.
  • IK represents the cascade of CK and IK.
  • the BSF ID can be generated for the EAP server itself, or the BSF ID can be received from Peer.
  • Peer may generate the key in the following manner, and the specific derivation formula is as follows:
  • Ks is the key generated by Peer during the authentication process, for example: CK
  • the key Ks is generated based on the key generated during the authentication process, for example, at least one of CK
  • Ks KDF (base key
  • Ks KDF (base key, BSF ID);
  • Ks KDF (base key, SN ID);
  • Ks KDF (base key, SN ID, BSF ID);
  • the above-mentioned basic key is a key obtained by Peer during the authentication process, for example, at least one of CK
  • the above derivation formula may further include an indication indicating a protocol type, for example, indicating at least one of the following protocol indications, such as EAP, EAP, AKA, EAP, AKA ', 5G, 5G, AKA, GBA, 5G, GBA, etc.
  • the above derivation formula may also include at least one of the following parameters, such as UE ID, session ID, EAP server ID, Authenticator ID, uplink or downlink counter, sequence number, and nonce, etc. If the above parameters are only parameters owned by Peer, then Need to send to EAP server, such as session ID, EAP server ID, Authenticator ID, upstream or downstream counter, serial number or nonce.
  • IK represents the cascade of CK and IK.
  • the BSF ID can be generated by Peer itself, or the BSF ID can be received from BSF.
  • the Authenticator generates a key in this application.
  • the EAP server does not generate a Ks key, and the Authenticator generates a Ks key in the following manner.
  • the specific derivation formula is as follows:
  • the Authenticator generates the key Ks based on the key received from the EAP server, for example, at least one of CK
  • the key received from the EAP server for example, at least one of CK
  • Ks KDF (base key
  • Ks KDF (base key).
  • Ks KDF (base key).
  • Ks KDF (base key, SN ID, BSF ID);
  • the above-mentioned basic key is a key obtained by the Authenticator during the authentication process, for example, at least one of CK
  • the above derivation formula may further include an indication indicating a protocol type, for example, indicating at least one of the following protocol indications, such as EAP, EAP, AKA, EAP, AKA ', 5G, GBA, 5G, and GBA.
  • protocol indications such as EAP, EAP, AKA, EAP, AKA ', 5G, GBA, 5G, and GBA.
  • the above derivation formula may further include at least one of the following parameters, such as UE ID, session ID, uplink or downlink counter, sequence number, nonce, etc. If nonce is the parameter selected by Authenticator, it needs to be sent to Peer.
  • the above derivation formula may also include at least one of the following parameters, such as UE ID, session ID, EAP server ID, Authenticator ID, uplink or downlink counter, sequence number, and nonce, etc. If the above parameters are only parameters of the Authenticator, then Need to send to peer, such as session ID, EAP server ID, Authenticator ID, upstream or downstream counter, serial number or nonce.
  • IK represents the cascade of CK and IK.
  • the BSF ID can be generated for the BSF itself, or the BSF ID can be received from Peer.
  • Peer's position for deriving Ks can be any step after receiving the Authenticator message.
  • the position of EAP derived server Ks can be any step after receiving the Authenticator message.
  • the position of Authenticator to derive Ks can be any step after receiving the EAP server message. Therefore, the specific position of the key derivation is not limited.
  • the generation of a B-TID by an EAP server may include: The EAP server generates a B-TID based on the RAND and the BSF server name.
  • RAND stands for Base64 encoding conversion for RAND.
  • the EAP server generating the B-TID may include: the EAP server generating an identifier as the B-TID.
  • this application is not limited, and may include, but is not limited to, random selection.
  • the message (EAP-Request / AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC)) shown in FIG. 5A is used as an example to explain:
  • Code indicates whether it is an EAP-request message, or an EAP-reponse, or an EAP success, or an EAP failure message, specifically:
  • Code is 1, which means EAP-request, and so on.
  • Identifier indicates the association for request and response messages.
  • Length indicates the length of the packet.
  • Type indicates the protocol type, such as EAP AKA authentication.
  • Subtype indicates a subtype, such as the AKA-challenge message type.
  • the attribute information include: AT_RAND, AT_AUTN, AT_MAC.
  • Attribute type is an attribute type, for example, indicates an AT_RAND parameter type.
  • Length is the attribute length, including attribute type, length, and value.
  • Value is the attribute value, that is, the specific parameter.
  • AT_RAND it refers to the specific RAND parameter value.
  • the B-TID message format can be expressed as the following format:
  • length represents the length of the entire message, including (AT_B-TID, length, B-TID length, B-TID), and B-TID length is the length of the B-TID content.
  • the message format of Key lifetime can be expressed as:
  • length represents the length of the entire message, including (AT_Keylifetime, length, Keylifetime, Keylifetime), and Keylifetime is the length of Keylifetime content.
  • FIG. 8 is a flowchart of an extended universal boot architecture authentication method according to another embodiment of the present application. As shown in FIG. 8, the method includes the following steps:
  • the Authenticator sends an EAP request message to Peer.
  • Peer sends the UE ID to the Authenticator.
  • the Authenticator sends a UE ID to the EAP server.
  • S801 to S803 are similar to S401 to S403, respectively, and are not repeated here.
  • the EAP server executes the AKA algorithm to generate RAND, AUTN, and MAC.
  • the EAP server sends RAND, AUTN, and MAC to the Authenticator.
  • the EAP server carries the RAND, AUTN, and MAC in a message such as the AKA challenge message sent by the EAP request, and this application does not limit the specific name of the message carrying the RAND, AUTN, and MAC.
  • the Authenticator receives RAND, AUTN, and MAC, and executes S806.
  • the Authenticator sends RAND, AUTN, and MAC to Peer.
  • Peer receives RAND, AUTN, and MAC, and executes S807.
  • Peer executes the AKA algorithm, verifies AUTN and MAC, and generates RES and key.
  • Peer sends RES and MAC to the Authenticator.
  • Peer sends the RES and MAC to the Authenticator in messages such as the AKA-Challenge message of the EAP-response, and this application does not limit the specific name of the message carrying the RES and MAC.
  • the Authenticator receives the RES and the MAC, and executes S809.
  • the Authenticator sends the RES and MAC to the EAP server.
  • the EAP server receives the RES and MAC, and executes S810.
  • the EAP server performs verification of RES and MAC; if the authentication is successful, the EAP server generates a key, a B-TID, and a Keylifetime.
  • the EAP server sends an EAP-success message to the Authenticator.
  • the EAP-success message carries a B-TID and a key lifetime.
  • the Authenticator receives the EAP-success message and executes S812.
  • the Authenticator sends an EAP-success message to Peer.
  • Peer receives the EAP-success message and completes GBA and AKA authentication.
  • the difference between the process shown in FIG. 8 and the process shown in FIG. 4 is that in the process shown in FIG. 4, the AKA challenge message requested by the EAP carries the B-TID and Key lifetime; the process shown in FIG. 8 In the EAP-success message, the B-TID and Key lifetime are carried.
  • this embodiment expands the content of an existing EAP-success message, and adds fields of B-TID and Key lifetime.
  • the format of the EAP success message field is shown in FIG. 9.
  • the existing EAP success message does not support the transmission of other fields or messages.
  • the embodiment of the present application modifies an existing EAP success message, for example, a newly added field is used to transmit B-TID and Key lifetime. The added content is shown in FIG. 6A, FIG. 6B, 6A, and FIG. 6B.
  • length represents the length of the entire message, including (AT_B-TID, length, B-TID length, B-TID), and B-TID length is the length of the B-TID content.
  • the field format used to pass Key lifetime can be expressed as:
  • length represents the length of the entire message, including (AT_Keylifetime, length, Keylifetime, Keylifetime), and Keylifetime is the length of Keylifetime content.
  • FIG. 10 is a flowchart of an extended universal boot architecture authentication method according to another embodiment of the present application. As shown in FIG. 10, the method includes the following steps:
  • the Authenticator sends an EAP request message to Peer.
  • Peer sends the UE ID to the Authenticator.
  • the Authenticator sends a UE ID to the EAP server.
  • S101 to S103 are similar to S401 to S403, respectively, and are not repeated here.
  • the EAP server executes the AKA algorithm to generate RAND, AUTN, and MAC.
  • the EAP server sends RAND, AUTN, and MAC to the Authenticator.
  • the EAP server carries the RAND, AUTN, and MAC in a message such as the AKA challenge message sent by the EAP request, and this application does not limit the specific name of the message carrying the RAND, AUTN, and MAC.
  • the Authenticator receives RAND, AUTN, and MAC, and executes S106.
  • the Authenticator sends RAND, AUTN, and MAC to Peer.
  • Peer receives RAND, AUTN, and MAC, and executes S107.
  • Peer executes the AKA algorithm to verify AUTN and MAC; and generates RES and key.
  • Peer sends RES and MAC to the Authenticator.
  • Peer sends the RES and MAC to the Authenticator in messages such as the AKA-Challenge message of the EAP-response, and this application does not limit the specific name of the message carrying the RES and MAC.
  • the Authenticator receives the RES and the MAC, and executes S109.
  • the Authenticator sends the RES and MAC to the EAP server.
  • the EAP server receives the RES and MAC, and executes S110.
  • the EAP server performs verification of RES and MAC; if the authentication is successful, the EAP server generates a key, a B-TID, and a Keylifetime.
  • the EAP server sends a first message to the Authenticator.
  • the first message carries a B-TID and a key lifetime.
  • the first message may be specifically an AKA-Notification message of the EAP-Request, and the application does not limit the specific name of the first message.
  • the Authenticator receives the first message and executes S112.
  • the Authenticator sends a first message to Peer.
  • Peer receives the first message and executes S113.
  • Peer sends a second message to the Authenticator.
  • the second message may be empty, that is, it does not carry any information.
  • the second message may be specifically an AKA-Notification message of the EAP-Response, etc.
  • the present application does not limit the specific name of the second message.
  • the Authenticator receives the second message and executes S114.
  • the Authenticator sends a second message to the EAP server.
  • the EAP server receives the second message and executes S115.
  • the EAP server sends an EAP-success message to the Authenticator.
  • the Authenticator receives the EAP-success message and executes S116.
  • the Authenticator sends an EAP-success message to Peer.
  • Peer receives the EAP-success message and completes GBA and AKA authentication.
  • the difference between the process shown in FIG. 10 and the process shown in FIG. 4 is that in the process shown in FIG. 4, the AKA challenge message requested by the EAP carries the B-TID and the key lifetime; the process shown in FIG. 10 In the first message, the B-TID and the key lifetime are carried in the first message.
  • this embodiment expands the content of an existing EAP-Response message or AKA-Notification message, and adds fields of B-TID and Key lifetime.
  • This embodiment of the present application modifies an existing EAP-Response message or AKA-Notification message, for example, a newly added field is used to transmit B-TID and Key lifetime.
  • FIG. 6B for specific explanation, reference may be made to the foregoing embodiment, and details are not described herein again.
  • a new EAP message may also be defined to pass the B-TID and Key lifetime.
  • the new EAP message may be a GBA-AKA notification message of the EAP-Request.
  • the B-TID and Key lifetime are generated by the EAP server.
  • the B-TID and Key lifetime can also be generated by Peer. The specific implementation manner is explained by the following embodiments.
  • FIG. 11 is a flowchart of an extended universal boot architecture authentication method according to another embodiment of the present application. As shown in FIG. 11, the method includes the following steps:
  • the Authenticator sends an EAP request message to Peer.
  • S1102. Peer sends a UE ID to the Authenticator.
  • S1103 The Authenticator sends a UE ID to the EAP server.
  • S1101 to S1103 are similar to S401 to S403, respectively, and are not repeated here.
  • the EAP server executes the AKA algorithm to generate RAND, AUTN, and MAC.
  • the EAP server sends RAND, AUTN, and MAC to the Authenticator.
  • the EAP server carries the RAND, AUTN, and MAC in a message such as the AKA challenge message sent by the EAP request, and this application does not limit the specific name of the message carrying the RAND, AUTN, and MAC.
  • the Authenticator receives RAND, AUTN, and MAC, and executes S1106.
  • the Authenticator sends RAND, AUTN, and MAC to Peer.
  • Peer receives RAND, AUTN, and MAC, and executes S1107.
  • Peer executes the AKA algorithm to verify AUTN and MAC; and generates RES, key, B-TID and Key lifetime.
  • Peer sends RES and MAC to the Authenticator.
  • Peer sends the RES and MAC to the Authenticator in messages such as the AKA-Challenge message of the EAP-response, and this application does not limit the specific name of the message carrying the RES and MAC.
  • the Authenticator receives the RES and the MAC, and executes S1109.
  • the Authenticator sends the RES and MAC to the EAP server.
  • the EAP server receives the RES and MAC, and executes S1110.
  • the EAP server performs the RES and MAC authentication. If the authentication is successful, the EAP server generates the key, B-TID, and Keylifetime.
  • the EAP server sends an EAP-success message to the Authenticator.
  • the Authenticator receives the EAP-success message and executes S1112.
  • the Authenticator sends an EAP-success message to Peer.
  • Peer receives the EAP-success message and completes GBA and AKA authentication.
  • S1101 to S1112 are used to obtain the B-TID and Key lifetime in the GBA and AKA authentication process, thereby achieving the parameters required for GBA and AKA authentication in EAP AKA, and achieving EAP-based GBA authentication; meanwhile, Peer Share the key with the EAP server.
  • Peer generating B-TID may include: generating B-TID according to RAND and BSF server name. Specifically, through S1106, Peer receives RAND, that is, for RAND, Peer obtains RAND in authentication; for BSF server name, there are the following possibilities:
  • the EAP server or Authenticator sends the BSF server name to Peer.
  • the BSF server name is carried in the EAP-request / identity message, or the EAP request / AKA-challenge message is sent to the Peer by the EAP server or Authenticator.
  • Peer receives the BSF server name sent by the EAP server or Authenticator.
  • the BSF server ID may also be sent here. Through the BSF server ID, Peer can obtain the BSF server name.
  • Peer can obtain the BSF server name by using certain rules through operator identification.
  • operator can be an operator identity.
  • Peer generates BSF server name based on Peer's identity in different scenarios. For example, Peer generates the BSF server name based on the IMSI in the Universal Subscriber Identity Module (USIM) scenario; or, Peer generates the IMPI in the IP Multimedia Service Identity Module (ISIM) scenario based on the IM Multimedia Service Module (ISIM) scenario BSF server name.
  • USIM Universal Subscriber Identity Module
  • ISIM IP Multimedia Service Identity Module
  • ISIM IP Multimedia Service Identity Module
  • Peer generates Key lifetime with the following possibilities:
  • Possibility 1 During the authentication process, the EAP server or Authenticator sends the key lifetime to Peer. For example, the Key lifetime is carried in the EAP-requrest / identity message, or the EAP request / AKA-challenge message is sent to the Peer by the EAP server or Authenticator.
  • Peer receives the Key lifetime from the EAP server or Authenticator.
  • Peer generates B-TID based on RAND and BSF server name.
  • the positions of any one or more of the three items of B-TID, Key lifetime, and key Ks are specifically generated, and this application is not limited.
  • the B-TID can be generated by the EAP server, and the Key lifetime can be generated by Peer. Accordingly, only the B-TID is transmitted in the subsequent steps.
  • the Key Lifetime can be generated by the EAP server, and the B-TID can be generated by the Peer. Accordingly, only the key lifetime is transmitted in the subsequent steps.
  • the B-TID and Key lifetime can be generated by Peer, and the B-TID and Key lifetime are sent by Peer to the EAP server.
  • Peer If Peer does not require the success notification message to be protected, it directly sends a success indication to Peer using the EAP success message; or, if peer needs to be successful notification message to be protected, the BSF sends an AKA-Notification message to send a success indication to Peer.
  • the BSF can send the B-TID and Key lifetime through the EAP-success message; or if Peer needs the success notification message to be protected, the BSF can send the B-TID and Key through the first message lifetime.
  • BSF can be EAP server or Authenticator.
  • the B-TID is generated based on the RAND and the BSF server name.
  • the first half of B-TID is an identifier randomly selected by BSF, and BSF sends B-TID and Key lifetime to Peer.
  • B-TID includes two parts: one is the RAND random number, and the other is the BSF server domain name, that is, B-TID: base64encode (RAND) @BSF_servers_domain_name. Therefore, random selection here means that instead of using the RAND parameter in the authentication process, the BSF randomly selects a random number as the first half of the B-TID.
  • Subsequent Peer may send B-TID to NAF to request to perform authentication between Peer and NAF.
  • the BSF determines the corresponding key based on the saved B-TID, and executes the subsequent NAF key generation and other processes.
  • GBA technology also includes key negotiation of K_NAF between UE and NAF. Participants include UE, NAF and BSF.
  • K_NAF key negotiation between UE and NAF is as follows:
  • the UE stores B-TID and key Ks.
  • the UE first generates Ks_NAF; after that, it initiates an application request to NAF, where the application request carries a B-TID and other msg messages;
  • NAF sends B-TID and NAF-ID to BSF
  • the BSF determines the key Ks according to the B-TID and generates Ks_NAF; sends Ks_NAF, Key lifetime, etc. to the NAF;
  • NAF sends an application response to the UE.
  • the above mainly completes how the UE obtains the B-TID after using the above authentication, and completes the key sharing with the NAF. Subsequent UEs and NAFs may use TLS and other security methods to establish a secure channel.
  • an embodiment of the present application provides an EAP-based authentication method between the UE and the NAF.
  • B-TID is the user name
  • Ks_ANF is the password; in this way, authentication methods such as EAP-POTP, EAP-PSK, and EAP-PWD are supported.
  • the following uses the EAP-PSK process as an example for illustration.
  • the specific implementation mode is that the UE performs an EAP-PSK process:
  • the UE replaces the user name in the authentication message with B-TID, replaces the password in it with Ks_NAF, and sends the modified authentication message to NAF.
  • the NAF After receiving the authentication message sent by the UE, the NAF checks whether the user name and password stored in the NAF are consistent with the user name and password sent by the UE. If they match, the verification succeeds, otherwise the verification fails.
  • the current 5G architecture includes the following security network elements: Authentication Server Function (AUSF), Authentication Trust Storage and Processing Function (ARPF), and Security Anchor Function (SEAF).
  • AUSF Authentication Server Function
  • ARPF Authentication Trust Storage and Processing Function
  • SEAF Security Anchor Function
  • the above network element can also be used to play the role of BSF, or generate Ks and send it to BSF.
  • the difference between this embodiment and the foregoing embodiment is mainly that the specific implementation manners of generating a key are different.
  • the generation of specific B-TID and Key lifetime is not limited here.
  • the method in which the BSF generates the B-TID and the key lifetime and distributes it to the UE and the manner in which the UE generates the B-TID and the key lifetime.
  • ARPF generates Ks based on EMSK, MSK, or CK
  • Ks Ks based on EMSK, MSK, or CK
  • Specific UE operations include generating Ks based on the key during the authentication process.
  • FIG. 12 is a flowchart of an extended universal boot architecture authentication method according to another embodiment of the present application. As shown in FIG. 12, the method may include the following steps:
  • the UE sends a first request to the BSF.
  • the first request includes a UE ID.
  • the BSF receives the first request, and adds a BSF ID to the first request to form a second request, that is, the second request includes a UE ID and a BSF ID, and executes S1202.
  • the BSF sends a second request to the ARPF.
  • the ARPF receives the second request and executes S1203.
  • ARPF calculates an authentication vector.
  • the authentication vector includes Ks, XRES, RAND, and AUTN.
  • the ARPF sends an authentication vector to the BSF.
  • the BSF receives the authentication vector and executes S1205.
  • the BSF sends the RAND and AUTN in the authentication vector to the UE.
  • the UE receives RAND and AUTN, and executes S1206.
  • the UE successfully verifies the AUTN, and generates Ks and RES.
  • S1207 The UE sends a RES to the BSF.
  • the BSF receives the RES and executes S1208.
  • the BSF does not need to send the BSF ID to the ARPF, that is, the BSF can forward the first request to the ARPF; or, if the ARPF can obtain the BSF ID by other means, Similarly, the BSF does not need to send the BSF ID to the ARPF, and only forwards the first request to the ARPF.
  • the way in which the ARPF obtains the BSF ID can be implemented in any of the following ways:
  • Implementation method 2 Determine the BSF ID according to the source of the message.
  • Implementation method three ARPF requests a BSF ID from a BSF or other network element and obtains a response, and the response includes the BSF ID.
  • the BSF ID can be replaced with BSF server name.
  • the ARPF sends a first key to the BSF, so that the BSF derives Ks according to the first key.
  • the first key may be EMSK, MSK, or CK
  • specific formulas and parameters for deriving the first key refer to the method for generating Ks in the embodiment corresponding to FIG. 4.
  • Ks KDF (first key
  • Ks KDF (first key, BSF ID);
  • Ks KDF (first key, SN ID);
  • Ks KDF (first key, SN ID, BSF ID);
  • the above-mentioned derivation formula may further include an indication indicating a protocol type, for example, indicating at least one of the following protocol indications: EAP, EAP, AKA, EAP, AKA ', 5G, GBA, 5G, and GBA.
  • the above derivation formula may further include at least one of the following parameters: UE ID, session ID, uplink or downlink counter, sequence number, nonce, and so on. If nonce is a parameter selected by the Authenticator, the Authenticator needs to send a nonce to the UE.
  • the above derivation formula may further include at least one of the following parameters: such as UE ID, session ID, EAP server ID, Authenticator ID, uplink or downlink counter, sequence number, nonce, and so on. If the above parameters are only parameters owned by ARPF, ARPF needs to send the parameters to the UE, such as session ID, EAP server ID, Authenticator ID, uplink or downlink counter, sequence number or nonce.
  • the operation of the specific UE includes: generating a first key according to the key during the authentication process, and then generating Ks according to the first key.
  • FIG. 13 is a flowchart of an extended universal boot architecture authentication method according to another embodiment of the present application. As shown in FIG. 13, the method may include the following steps:
  • the UE sends a first request to the BSF.
  • the first request includes a UE ID.
  • the BSF receives the first request, and adds a BSF ID to the first request to form a second request, that is, the second request includes a UE ID and a BSF ID, and executes S1302.
  • the BSF sends a second request to AUSF.
  • the AUSF receives the second request and executes S1303.
  • the AUSF sends a second request to the ARPF.
  • the ARPF receives the second request and executes S1304.
  • ARPF calculates an authentication vector.
  • the authentication vectors include XRES, RAND, AUTN, and Kausf.
  • Kasuf represents the key sent by ARPF to AUSF. It is also possible that the authentication vectors are XRES, RAND, AUTN, (at least one of EMSK, MSK, and CK
  • the ARPF sends an authentication vector to the AUSF.
  • AUSF receives the authentication vector and executes S1306.
  • the AUSF generates Ks based on the authentication vector.
  • AUSF generating Ks based on the authentication vector may include: AUSF generating Ks based on CK
  • AUSF sends XRES, RAND, AUTN, and Ks to BSF.
  • the BSF receives XRES, RAND, AUTN, and Ks, and executes S1308.
  • the BSF sends RAND and AUTN to the UE.
  • the UE receives RAND and AUTN, and executes S1309.
  • the UE verifies that the AUTN is successful, and generates Ks and RES.
  • the UE sends a RES to the BSF.
  • the BSF receives the RES and executes S1311.
  • This embodiment is different from the previous embodiment in that the BSF and the AUSF have an interface, and through this interface, the AUSF receives CK, IK, EMSK, MSK, or Kausf from the ARPF.
  • AUSF derives Ks according to the above key.
  • Ks please refer to the method for generating Ks in the embodiment corresponding to FIG. 4. The difference is that in addition to CK
  • BSF does not need to send BSF ID to AUSF, that is, BSF can forward the first request to AUSF; or, if AUSF can obtain BSF ID by other means, then Similarly, the BSF does not need to send the BSF ID to the AUSF, and only forwards the first request to the AUSF.
  • the application does not limit the method of obtaining the BSF ID by AUSF.
  • the way in which AUSF obtains the BSF ID can be implemented in any of the following ways:
  • Implementation method 2 Determine the BSF ID according to the source of the message.
  • Implementation method three AUSF requests a BSF ID from the BSF or other network elements and obtains a response.
  • the response includes the BSF ID.
  • the BSF ID can be replaced with BSF server name.
  • the AUSF sends a second key to the BSF, so that the BSF derives Ks according to the second key.
  • the second key may be EMSK, MSK, Kausf, or CK
  • Ks KDF (second key).
  • Ks KDF (second key, BSF ID);
  • Ks KDF (second key, SN ID);
  • Ks KDF (second key, SN ID, BSF ID);
  • the above-mentioned derivation formula may further include an indication indicating a protocol type, for example, indicating at least one of the following protocol indications: EAP, EAP, AKA, EAP, AKA ', 5G, GBA, 5G, and GBA.
  • the above-mentioned derivation formula may further include at least one of the following parameters, such as a UE ID, a session ID, an uplink or downlink counter, a sequence number, and a nonce. If nonce is a parameter selected by the Authenticator, the Authenticator needs to send a nonce to the UE.
  • the above derivation formula may further include at least one of the following parameters: UE ID, session ID, EAP server ID, Authenticator ID, uplink or downlink counter, sequence number, nonce, etc. If the above parameters are only parameters owned by AUSF, the AUSF needs to send parameters to the UE, such as session ID, EAP server ID, Authenticator ID, uplink or downlink counter, sequence number or nonce.
  • the operation of the specific UE includes: generating a second key according to the key during the authentication process, and then generating Ks according to the second key.
  • the above BSF ID can be replaced with BSF server name.
  • BSF has an interface with SEAF.
  • SEAF generates Ks, or SEAF generates a third key, and sends the third key to BSF, so that BSF generates Ks according to the third key.
  • the KSF generated by the SEAF does not require the BSF ID, the BSF does not need to send the BSF ID to the SEAF; or, if the SEAF can obtain the BSF ID by other means, the same BSF does not need to send the BSF ID to the SEAF.
  • the method by which the SEAF obtains the BSF ID can be preset, or the BSF ID can be determined according to the source of the message, or the SEAF requests the BSF or other network elements to obtain the BSF ID, and obtains a response.
  • the response includes the BSF ID, etc. There are no restrictions here.
  • the key generation method is a third key generated based on EMSK, MSK, Kseaf, or CK
  • Possibility 1 (applicable to all embodiments): The B-TID and Key lifetime are generated and sent by the Authenticator to Peer.
  • Peer generation Ks can be any step after receiving the EAP-response / AKA-request message sent by the Authenticator, which is not limited in this application. For example, after receiving the EAP-success message, Peer generates Ks.
  • the EAP server generates any step after Ks can receive the message sent by the Authenticator, which is not limited in this application. For example, after receiving the EAP-response / AKA-challenge message, the EAP server generates Ks.
  • Possibility 4 (applicable to all embodiments): For a specific manner of generating Ks by Peer and EAP server, refer to the description of the embodiment shown in FIG. 4.
  • Possibility 5 (applicable to all embodiments):
  • the Ks is generated by the Authenticator, and the specific generation method can refer to the description of the embodiment shown in FIG. 4.
  • Possibility 6 (applicable to all embodiments): for the correspondence between the network element in the EAP and the GBA network element. There are the following possibilities:
  • Peer performs actions corresponding to UE, and EAP server performs actions corresponding to BSF.
  • the actions include, for example: authentication, and generating Ks, generating B-TID and key lifetime, at least one of the three actions;
  • Peer performs an action corresponding to the UE
  • Authenticator performs an action corresponding to the BSF.
  • the actions here include, for example, authentication, generating Ks, generating B-TID and key lifetime, at least one of three actions.
  • BSF is deployed independently and has an interface with Authenticator or EAP server. If the BSF is deployed independently, the UE will first access the BSF, then the BSF will access the authenticator, and the authenticator will then access the EAP server. It is also possible that the UE first accesses the authenticator, the authenticator then the BSF, and the BSF then the EAP server.
  • Possibility 7 (applicable to all embodiments):
  • the above-mentioned CK and IK are represented as encryption keys and integrity protection keys, and the symbols are not restricted, but can also be CK 'and IK', etc., and are not restricted here .
  • Possibility 8 (applicable to all embodiments): for the correspondence between ARPF, AUSF and SEAF network elements and GBA network elements. There are the following possibilities:
  • ARPF performs actions corresponding to BSF.
  • the actions here include, for example: authentication, and generating Ks, generating B-TID and key lifetime, at least one of the three actions;
  • the AUSF performs an action corresponding to the BSF.
  • the actions here include, for example: authentication, and generating Ks, generating B-TID and key lifetime, at least one of the three actions;
  • the SEAF performs an action corresponding to the BSF.
  • the actions here include, for example: authentication, and generating Ks, generating B-TID and key lifetime, at least one of the three actions.
  • Possibility 9 (applicable to all embodiments): The UE or Peer generates Ks, which is any step after receiving the message sent by BSF / ARPF / AUSF / SEAF, which is not limited in this application.
  • BSF / ARPF / AUSF / SEAF generating Ks can be any step after receiving the relevant message sent by the UE or Peer, which is not limited in this application.
  • Possibility 11 (applicable to all embodiments): for the correspondence between ARPF / AUSF / SEAF networks and GBA network elements. There are the following possibilities:
  • BSF is deployed independently and has an interface with ARPF / AUSF / SEAF. If the BSF is deployed independently, the UE will first access the BSF, and then the BSF will access ARPF / AUSF / SEAF. It is also possible that the UE accesses the SEAF first, the SEAF then the BSF, and the BSF then the AUSF. It is also possible that the UE accesses the SEAF first, the SEAF then the AUSF, the AUSF then the BSF, and the BSF and the ARPF. The above combination is not limited.
  • the first network element involved in this application may be EAP server or AUSF
  • the terminal may be Peer or UE
  • the second network element may be Authenticator, etc.
  • This application does not limit this.
  • the application does not limit the execution entity that generates the key, and may be EAP server, Peer, UE, AUSF, Authenticator, or ARPF.
  • the embodiment of the present application describes the schematic structure of the extended universal boot architecture authentication device in detail.
  • FIG. 14 is a schematic block diagram of an extended universal boot architecture authentication device according to an embodiment of the present application.
  • the extended universal boot architecture authentication device 1400 in the embodiment of the present application may be the first network element in the foregoing method embodiment, or may be one or more chips in the first network element.
  • the extended universal boot architecture authentication device 1400 may be configured to perform some or all functions of the first network element in the foregoing method embodiment.
  • the extended universal boot architecture authentication device 1400 may include a processing module 1410 and a transceiver module 1420.
  • the extended universal boot architecture authentication device 1400 may further include a storage module 1430.
  • the processing module 1410 may be configured to execute the steps of generating a B-TID and a key lifetime in the foregoing method embodiment.
  • the transceiver module 1420 may be configured to perform the steps of sending the B-TID and the key lifetime in the foregoing method embodiment.
  • the extended universal boot architecture authentication device 1400 may also be configured as a universal processing system, such as a chip, and the processing module 1410 may include: one or more processors providing processing functions; the transceiver module 1420 may, for example, It is an input / output interface, a pin or a circuit, etc.
  • the input / output interface can be used for the information interaction between this chip system and the outside world. For example, this input / output interface can output the B-TID and key lifetime generated by the processing module 1410 Other modules outside this chip are processed.
  • the processing module 1410 can execute computer execution instructions stored in the storage module 1430 to implement the functions of the first network element in the foregoing method embodiment.
  • the optional storage module 1430 included in the extended universal boot architecture authentication device 1400 may be a storage unit in a chip, such as a register, a cache, etc.
  • the storage module 1430 may also be the first network element.
  • the internal storage unit located outside the chip such as read-only memory (ROM) or other types of static storage devices that can store static information and instructions, random access memory (RAM), etc.
  • FIG. 15 is a schematic block diagram of an extended universal boot architecture authentication apparatus according to another embodiment of the present application.
  • the extended universal boot architecture authentication device 1500 in the embodiment of the present application may be the first network element in the foregoing method embodiment, and the extended universal boot architecture authentication device 1500 may be used to execute a part of the first network element in the foregoing method embodiment. Or all functions.
  • the extended universal boot architecture authentication device 1500 may include a processor 1510, a baseband circuit 1530, a radio frequency circuit 1540, and an antenna 1550.
  • the extended universal boot architecture authentication device 1500 may further include a memory 1520.
  • the components of the extended universal boot architecture authentication device 1500 are coupled together by a bus 1560.
  • the bus system 1560 includes a power bus, a control bus, and a status signal bus in addition to a data bus. However, for the sake of clarity, various buses are marked as the bus system 1560 in the figure.
  • the processor 1510 may be configured to implement control on the first network element, and is configured to execute the processing performed by the first network element in the foregoing embodiment.
  • the processor 1510 may execute the processing process involving the first network element in the foregoing method embodiment and / or Other processes of the technology described in this application can also run an operating system, be responsible for managing the bus, and can execute programs or instructions stored in memory.
  • the baseband circuit 1530, the radio frequency circuit 1540, and the antenna 1550 may be used to support the transmission and reception of information between the first network element and the terminal involved in the foregoing embodiment to support wireless communication between the first network element and the terminal.
  • the memory 1520 may be used to store program codes and data on the transmitting end, and the memory 1520 may be a storage module 1530 in FIG. 15. It can be understood that the baseband circuit 1530, the radio frequency circuit 1540, and the antenna 1550 can also be used to support the first network element to communicate with other network entities, for example, to support the first network element to communicate with other network elements.
  • the memory 1520 is shown as being separate from the processor 1510 in FIG. 15, however, it will be readily apparent to those skilled in the art that the memory 1520 or any portion thereof may be located outside the extended universal boot architecture authentication device 1500.
  • the memory 1520 may include transmission lines and / or computer products separated from the wireless nodes, and these media may be accessed by the processor 1510 through the bus interface 1560.
  • the memory 1520 or any part thereof may be integrated into the processor 1510, for example, it may be a cache and / or a general-purpose register.
  • FIG. 15 only shows a simplified design of the first network element.
  • the first network element may include any number of transmitters, receivers, processors, memories, etc., and all the first network elements that can implement this application are within the protection scope of this application.
  • the extended universal boot architecture authentication device on the first network element side can also be implemented using the following: one or more field-programmable gate array (FPGA), programmable Any combination of logic devices (programmable logic devices, PLDs), controllers, state machines, gate logic, discrete hardware components, any other suitable circuits, or circuits capable of performing the various functions described throughout this application.
  • FPGA field-programmable gate array
  • PLDs programmable Any combination of logic devices
  • controllers state machines
  • gate logic discrete hardware components
  • an embodiment of the present application further provides a computer storage medium.
  • the computer storage medium may store program instructions for instructing any one of the foregoing methods, so that the processor executes the program instructions to implement the foregoing method embodiments. Methods and functions related to the first network element.
  • FIG. 16 is a schematic block diagram of an extended universal boot architecture authentication apparatus according to another embodiment of the present application.
  • the extended universal boot architecture authentication device 1600 in the embodiment of the present application may be a terminal in the foregoing method embodiment, or may be one or more chips in the terminal.
  • the extended universal boot architecture authentication device 1600 may be used to perform some or all functions of the terminal in the foregoing method embodiments.
  • the extended universal boot architecture authentication device 1600 may include a processing module 1610 and a transceiver module 1620.
  • the extended universal boot architecture authentication device 1600 may further include a storage module 1630.
  • the transceiver module 1620 is configured to receive a B-TID and a key lifetime.
  • the extended universal boot architecture authentication device 1600 may also be configured as a general-purpose processing system, such as a chip, and the processing module 1610 may include: one or more processors that provide processing functions; the transceiver module 1620 may, for example, It is an input / output interface, a pin or a circuit, etc. The input / output interface can be used to be responsible for the information interaction between this chip system and the outside world.
  • the one or more processors may execute computer execution instructions stored in the storage module 1630 to implement the functions of the terminal in the foregoing method embodiments.
  • the optional storage module 1630 included in the extended universal boot architecture authentication device 1600 may be a storage unit in a chip, such as a register, a cache, etc.
  • the storage module 1630 may also be located in the terminal.
  • a storage unit external to the chip such as a ROM or other type of static storage device, RAM, etc. that can store static information and instructions.
  • FIG. 17 is a schematic block diagram of an extended universal boot architecture authentication device according to another embodiment of the present application.
  • the extended universal boot architecture authentication device 1700 in the embodiment of the present application may be a terminal in the foregoing method embodiment, and the extended universal boot architecture authentication device 1700 may be used to perform some or all functions of the terminal in the foregoing method embodiment.
  • the extended universal boot architecture authentication device 1700 may include a processor 1710, a baseband circuit 1730, a radio frequency circuit 1740, and an antenna 1750.
  • the extended universal boot architecture authentication device 1700 may further include a memory 1720.
  • the components of the extended universal boot architecture authentication device 1700 are coupled together through a bus 1760.
  • the bus system 1760 includes a power bus, a control bus, and a status signal bus in addition to a data bus. However, for the sake of clarity, various buses are marked as the bus system 1760 in the figure.
  • the processor 1710 may be used to implement control of the terminal, and is used to execute the processing performed by the terminal in the foregoing embodiments, and may execute the processing process involving the terminal in the foregoing method embodiments and / or other processes used in the technology described in this application. , Can also run the operating system, is responsible for managing the bus and can execute programs or instructions stored in memory.
  • the baseband circuit 1730, the radio frequency circuit 1740, and the antenna 1750 may be used to support the sending and receiving of information between the terminal and the first network element involved in the foregoing embodiment to support wireless communication between the first network element and the terminal.
  • a memory 1720 may be used to store program code and data on the transmitting end, and the memory 1720 may be a storage module 1730 in FIG. 17. It can be understood that the baseband circuit 1730, the radio frequency circuit 1740, and the antenna 1750 can also be used to support the terminal to communicate with other network entities.
  • FIG. 17 shows only a simplified design of the terminal.
  • the terminal may include any number of transmitters, receivers, processors, memories, and the like, and all terminals that can implement this application are within the protection scope of this application.
  • the extended universal boot architecture authentication device on the terminal side may also be implemented using the following: one or more field-programmable gate array (FPGA), programmable logic device (FPGA) programmable logic (device, PLD), controller, state machine, gate logic, discrete hardware components, any other suitable circuit, or any combination of circuits capable of performing the various functions described throughout this application.
  • FPGA field-programmable gate array
  • FPGA programmable logic device
  • PLD programmable logic
  • controller state machine
  • gate logic discrete hardware components
  • any other suitable circuit any combination of circuits capable of performing the various functions described throughout this application.
  • an embodiment of the present application further provides a computer storage medium.
  • the computer storage medium may store program instructions for instructing any one of the foregoing methods, so that the processor executes the program instructions to implement the foregoing method embodiments.
  • the methods and functions of the terminal are involved.
  • the processors involved in the extended universal boot architecture authentication device 1500 and the extended universal boot architecture authentication device 1700 may be general-purpose processors, such as a general-purpose central processing unit (CPU), a network processor (Network Processor) (NP), a microcomputer
  • the processor or the like may also be an application-specific integrated circuit (ASIC) or one or more integrated circuits for controlling the execution of the program of the solution of the present application. It can also be a Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components.
  • DSP Digital Signal Processor
  • FPGA Field-Programmable Gate Array
  • the controller / processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and so on.
  • a processor typically performs logic and arithmetic operations based on program instructions stored in memory.
  • the memory involved in the extended universal boot architecture authentication device 1500 and the extended universal boot architecture authentication device 1700 may further store an operating system and other application programs.
  • the program may include program code, and the program code includes a computer operation instruction.
  • the above memory may be a read-only memory (ROM), other types of static storage devices that can store static information and instructions, random access memory (RAM), and can store Other types of dynamic storage devices, disk storage, etc. for information and instructions.
  • the memory may be a combination of the above storage types.
  • the above computer-readable storage medium / memory may be in the processor, may also be external to the processor, or may be distributed on multiple entities including the processor or the processing circuit.
  • the computer-readable storage medium / memory described above may be embodied in a computer program product.
  • a computer program product may include a computer-readable medium in packaging materials.
  • the disclosed systems, devices, and methods may be implemented in other ways.
  • the device embodiments described above are only schematic.
  • the division of the unit is only a logical function division.
  • multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, which may be electrical, mechanical or other forms.
  • 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, may be located in one place, or may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objective of the solution of this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each of the units may exist separately physically, or two or more units may be integrated into one unit.
  • the above integrated unit may be implemented in the form of hardware or in the form of software functional unit.
  • An embodiment of the present application provides a computing storage medium including program instructions, where the program instructions are used to implement the method described in any one of the foregoing embodiments.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请提供一种扩展的通用引导架构认证方法、装置及存储介质，该方法包括：第一网元获取B-TID和Key lifetime；第一网元发送B-TID和Key lifetime至终端，以使终端根据B-TID和Key lifetime，与第一网元进行基于EAP的GBA AKA认证，从而实现终端与第一网元基于EAP完成GBA AKA认证。

Description

扩展的通用引导架构认证方法、装置及存储介质
本申请要求于2018年08月10日提交中国专利局、申请号为201810911034.4、申请名称为“扩展的通用引导架构认证方法、装置及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域，尤其涉及一种扩展的通用引导架构认证方法、装置及存储介质。
背景技术
作为移动通信的一种通用引导架构(Generic Bootstrapping Architecture,GBA)，GBA技术可被用来建立用户设备(User Equipment,UE)与网络应用服务器(Network Application Function,NAF)之间的安全隧道。其中，GBA技术包括GBA认证与密钥协商(Authentication and Key Agreement,AKA)认证。
在通用移动通信***(Universal Mobile Telecommunications System,UMTS)3G场景，3GPP TS33.220已经给出了具体的GBA AKA认证定义。该已定义的GBA AKA认证中，是由UE与引导服务器功能(Bootstrapping Server Function,BSF)基于超文本传输协议(HyperText Transfer Protocol,HTTP)完成GBA AKA认证。发明人考虑到可扩展的身份验证协议(Extensible Authentication Protocol,EAP)的发展趋势，以及未来其他应用的可能性，研究一种扩展的GBA认证方法。
发明内容
本申请提供一种扩展的通用引导架构认证方法、装置及存储介质，以使UE与BSF基于EAP完成GBA AKA认证。
第一方面，本申请提供一种扩展的通用引导架构认证方法，包括：第一网元获取B-TID和Key lifetime；第一网元发送B-TID和Key lifetime至终端，以使终端根据B-TID和Key lifetime，与第一网元进行基于EAP的GBA AKA认证。
本申请的有益效果包括：由于本申请提供的扩展的通用引导架构认证方法基于EAP，因此，可以使UE与BSF基于EAP完成GBA AKA认证。
可选地，第一网元获取B-TID，可以包括：第一网元根据RAND和BSFserver name生成B-TID；或者，第一网元生成一标识，将该标识作为B-TID。
可选地，第一网元发送B-TID和Key lifetime至终端，包括：第一网元发送EAP请求的AKA挑战消息给终端，该EAP请求的AKA挑战消息携带B-TID和Key lifetime。即通过EAP请求的AKA挑战消息传输B-TID和Key lifetime。
可选地，第一网元发送B-TID和Key lifetime至终端之后，本申请提供的方法还 可以包括：第一网元接收终端发送的RES和MAC，并执行RES和MAC的验证；若验证成功，第一网元生成密钥，并发送EAP-success消息至终端，完成基于EAP的GBA AKA认证。
可选地，第一网元获取B-TID和Key lifetime之前，还包括：第一网元接收终端发送的终端的标识。
可选地，第一网元接收终端发送的终端的标识之后，还包括：第一网元通过以下任一方式获取RAND、AUTN和MAC：
方式一、第一网元执行AKA算法，生成RAND、AUTN和MAC；
方式二、第一网元接收RAND、AUTN和MAC。
可选地，第一网元接收终端发送的终端的标识，可以包括：第一网元接收第二网元发送的终端的标识，该终端的标识是由终端在接收到第二网元发送的EAP请求消息之后，发送给第二网元的。其中，EAP请求消息用于请求终端的标识。
第二方面，本申请提供一种扩展的通用引导架构认证方法，包括：终端接收第一网元发送的B-TID和Key lifetime；终端根据B-TID和Key lifetime，与第一网元进行基于EAP的GBA AKA认证。
本申请的有益效果包括：由于本申请提供的扩展的通用引导架构认证方法基于EAP，因此，可以使UE与BSF基于EAP完成GBA AKA认证。
可选地，终端接收第一网元发送的B-TID和Key lifetime，可以包括：终端接收第一网元发送的EAP请求的AKA挑战消息，该EAP请求的AKA挑战消息携带B-TID和Key lifetime。
可选地，终端根据B-TID和Key lifetime，与第一网元进行基于EAP的GBA认证，包括：终端获取RAND、AUTN和MAC；终端执行AKA算法，验证AUTN和MAC；终端生成RES和密钥；终端发送RES和MAC给所述第一网元，以使第一网元执行RES和MAC的验证，若验证成功，第一网元生成密钥，并发送EAP-success消息至终端；终端接收EAP-success消息。
可选地，终端接收第一网元发送的B-TID和Key lifetime之前，还包括：终端发送终端的标识给第一网元。
可选地，终端发送终端的标识给第一网元，包括：终端发送终端的标识给第二网元，以使第二网元发送终端的标识给第一网元。
可选地，终端发送终端的标识给第一网元之前，还包括：终端接收第二网元发送的EAP请求消息，该EAP请求消息用于请求终端的标识。
在上述基础上，还存在以下可能的实施方式：
可选地，B-TID还可以用于确定BSF地址和/或密钥。
可选地，B-TID和Key lifetime受MAC保护。
可选地，终端和第一网元之间通过第二网元收发信息，这里的信息包括但不限于上述B-TID和Key lifetime。
可选地，终端的标识可以为永久标识或者临时标识，包括以下任意一项：SUPI，SUCI，IMSI，IMPI，TMPI，GUTI，TMSI，IMPU，App ID，网络标识，服务标识和NAI。
第三方面，本申请提供一种密钥生成方法，包括：获取密钥参数，该密钥参数包括；CK和IK、EMSK、MSK中的至少一项；根据密钥参数生成密钥。
可选地，根据密钥参数生成密钥，包括以下实现方式的任一种：
实现方式一、密钥参数包括；CK和IK，计算推衍公式一：Ks＝CK||IK，CK||IK代表CK和IK的级联；
实现方式二、密钥参数包括；EMSK，计算推衍公式二：Ks＝EMSK；
实现方式三、密钥参数包括；MSK，计算推衍公式三：Ks＝MSK；
上述公式中，Ks表示生成的密钥。
可选地，根据密钥参数生成密钥，包括：基于认证过程中生成的基础密钥生成密钥，其中，该基础密钥包括CK||IK、EMSK和MSK中的至少一项。
可选地，基于认证过程中生成的基础密钥生成密钥，可以包括：通过以下方式生成密钥Ks，具体的推衍公式如下：
公式四、Ks＝KDF(基础密钥)，其中，KDF表示密钥推衍函数；
公式五、Ks＝KDF(基础密钥,BSF ID)；
公式六、Ks＝KDF(基础密钥,SN ID)，SN ID表示服务网络ID；
公式七、Ks＝KDF(基础密钥,SN ID,BSF ID)。
可选地，上述任一推衍公式还可以包括：指示协议类型的指示，该协议类型包括以下至少一项：EAP，EAP AKA，EAP AKA’，5G，5G AKA，GBA和5G GBA等。
可选地，上述任一推衍公式还包括以下参数的至少一项：UE ID，session ID，EAP server ID，Authenticator ID，上行或下行计数器，序列号和nonce。
第四方面，本申请提供一种扩展的通用引导架构认证装置，包括：该装置具有实现上述第一方面或第一方面的可选方法实际中第一网元行为的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。
第五方面，本申请提供一种扩展的通用引导架构认证装置，包括：该装置具有实现上述第二方面或第二方面的可选方法实际中终端行为的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。
第六方面，本申请提供一种密钥生成装置，包括：该装置具有实现上述第三方面或第三方面的可选方法实际中密钥生成行为的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。
第七方面，本申请提供一种扩展的通用引导架构认证装置，该装置的结构中包括处理器和收发器，所述处理器被配置为支持所述装置执行上述第一方面或第一方面的可选方法中相应的功能。所述收发器用于支持所述装置与终端之间的通信，收发上述方法中所涉及的信息或者指令。所述装置还可以包括存储器，所述存储器用于与处理器耦合，其保存所述装置必要的程序指令和数据。
第八方面，本申请提供一种扩展的通用引导架构认证装置，该装置的结构中包括处理器和收发器，所述处理器被配置为支持所述装置执行上述第二方面或第二方面的 可选方法中相应的功能。所述收发器用于支持所述装置与第一网元之间的通信，收发上述方法中所涉及的信息或者指令。所述装置还可以包括存储器，所述存储器用于与处理器耦合，其保存所述装置必要的程序指令和数据。
第九方面，本申请提供一种密钥生成装置，该装置的结构中包括处理器和存储器，所述处理器被配置为支持所述装置执行上述第三面或第三方面的可选方法中相应的功能。所述存储器用于与处理器耦合，其保存所述装置必要的程序指令和数据。
第十方面，本申请提供一种计算存储介质，包括程序指令，程序指令用于实现如第一方面或第一方面的可选方式的扩展的通用引导架构认证方法。
第十一方面，本申请提供一种计算存储介质，包括程序指令，程序指令用于实现如第二方面或第二方面的可选方式的扩展的通用引导架构认证方法。
第十二方面，本申请提供一种计算存储介质，包括程序指令，程序指令用于实现如第三方面或第三方面的可选方式的密钥生成方法。
第十三方面，本申请提供一种计算机程序产品，包括程序指令，程序指令用于实现如第一方面或第一方面的可选方式的扩展的通用引导架构认证方法。
第十四方面，本申请提供一种计算机程序产品，包括程序指令，程序指令用于实现如第二方面或第二方面的可选方式的扩展的通用引导架构认证方法。
第十五方面，本申请提供一种计算机程序产品，包括程序指令，程序指令用于实现如第三方面或第三方面的可选方式的密钥生成方法。
本申请提供一种扩展的通用引导架构认证方法、装置及存储介质。首先，由于本申请提供的扩展的通用引导架构认证方法基于EAP，因此，可以使UE与BSF基于EAP完成GBA AKA认证。另外，本申请还提供一种密钥生成方法，扩展密钥的生成方式。
附图说明
图1为现有GBA架构示意图；
图2示出UE与BSF之间一种可能的协议栈格式；
图3示出UE与BSF之间另一种可能的协议栈格式；
图4为本申请一实施例提供的扩展的通用引导架构认证方法的流程图；
图5A示出一种消息格式；
图5B为本申请一实施例提供的消息格式；
图6A为本申请实施例提供的包含B-TID的一消息格式；
图6B为本申请实施例提供的包含B-TID的另一消息格式；
图7A为本申请实施例提供的包含Key lifetime的一消息格式；
图7B为本申请实施例提供的包含Key lifetime的另一消息格式；
图8为本申请另一实施例提供的扩展的通用引导架构认证方法的流程图；
图9示出现有的EAP success消息的消息格式；
图10为本申请又一实施例提供的扩展的通用引导架构认证方法的流程图；
图11为本申请又一实施例提供的扩展的通用引导架构认证方法的流程图；
图12为本申请又一实施例提供的扩展的通用引导架构认证方法的流程图；
图13为本申请又一实施例提供的扩展的通用引导架构认证方法的流程图；
图14为本申请一实施例提供的扩展的通用引导架构认证装置的示意性框图；
图15为本申请另一实施例提供的扩展的通用引导架构认证装置的示意性框图；
图16为本申请又一实施例提供的扩展的通用引导架构认证装置的示意性框图；
图17为本申请又一实施例提供的扩展的通用引导架构认证装置的示意性框图。
具体实施方式
图1为现有GBA架构示意图。如图1所示，该GBA架构包括：BSF、UE、NAF和签约位置功能(Subscriber Locator Function，SLF)。其中，BSF作为中间枢纽，通过Ub接口与UE交互，执行UE与BSF之间的认证；通过Zh接口可以从HSS获得UE认证相关的参数，HSS存储有UE与认证相关的参数；通过Zn接口与NAF交互；通过Dz接口与SLF交互，在多个HSS场景下，BSF可从SLF处得到UE对应的HSS名称。另外，UE通过Ua接口与NAF交互。由于每个应用都对应有一个NAF，因此，BSF和UE可能与多个NAF进行交互。
如上所述，已定义的GBA AKA认证标准中，参与方包括UE、BSF和HSS，基于UE与HSS之间共享的根密钥，实现UE与BSF之间Ks的密钥协商；通过执行引导(Bootstrapping)过程，在BSF与UE之间建立一个共享的密钥。具体地，UE与BSF是基于HTTP完成GBA AKA认证的，其具体步骤如下：UE发送UE ID至BSF；BSF发送UE ID至归属用户服务器(Home Subscriber Server,HSS)；HSS根据UE ID，确定UE ID对应根密钥，并且计算得到认证向量(authentication vector,AV)，AV＝(RAND，AUTN，CK，IK，XRES)，并发送AV至BSF，其中，RAND为随机数，AUTN为认证令牌(Authentication token)，CK为加密密钥(Cipher Key)，IK为完整性保护密钥(Integrity key)，XRES为期望的用户响应(Expected user Response)；BSF发送AV中RAND和AUTN至UE；UE验证AUTN，并计算得到CK、IK和RES，RES为用户响应(user Response)；UE发送RES至BSF；BSF对比XRES和RES，验证RES是否正确；若验证成功，BSF计算Ks＝CK||IK；BSF发送B-TID和Key lifetime至UE，其中，BSF基于RAND和BSF server name生成B-TID，即base64encode(RAND)@BSF_servers_domain_name，base64encode(RAND)代表对RAND进行Base64编码转换；UE计算得到Ks＝CK||IK。另外，图2示出UE与BSF之间一种可能的协议栈格式，从该协议栈也可看出现有的GBA AKA认证是基于HTTP的。
而现有的EAP AKA认证流程可参考RFC4187，主要包含三个实体：
Peer：被认证者，参与认证的实体，可以为UE或物联网(Internet of things,IoT)等终端设备；
Authenticator：认证者，参与EAP AKA认证，可以为接入点等实体，执行初步的认证等。在本流程中，认证者主要执行数据的转发等工作；
EAP server：认证服务器，执行对于Peer的认证。
其中，EAP AKA认证流程描述如下：
1、Authenticator向Peer发送EAP请求消息，该EAP请求消息用于请求Peer的标识；
2、Peer发送UE ID(例如，网络接入标识(Network Access Identifier,NAI))至 Authenticator；
3、Authenticator向EAP server发送UE ID，这里，EAP server执行AKA算法，生成RAND、AUTN和消息验证码(Message Authentication Code，MAC)，并发送RAND、AUTN和MAC至Authenticator；
4、Authenticator发送RAND、AUTN和MAC至Peer；
5、Peer执行AKA算法，验证AUTN和MAC；并生成RES和会话密钥(session key)；
6、Peer发送RES和MAC至Authenticator；
7、Authenticator发送RES和MAC至EAP server；EAP server执行RES和MAC的验证。若验证成功，发送EAP-success消息至Authenticator；
8、Authenticator发送EAP-success消息至Peer。
注意：Authenticator发送给Peer的MAC和Peer发送给Authenticator的MAC不同。
根据上述描述及图3可以发现，EAP AKA认证虽然是基于EAP的，其中，图3示出UE与BSF之间另一种可能的协议栈格式。但认证过程仅包含RAND、AUTN和MAC的传递。由于EAP是应用非常广的协议，同时包括EAP扩展协议(RFC5448)，例如，EAP AKA’或者EAP-SIM等其他EAP认证，本申请对此不做限制；并且在未来的5G也会应用EAP扩展协议，因此，如果将EAP扩展为支持GBA AKA认证，需要在现有EAP AKA认证流程中，新增B-TID和Key lifetime的发送方法。另外，考虑为了支持其他认证方法，例如5G AKA等，本申请也会对现有GBA认证协议做改进。
基于上述，本申请提供一种扩展的GBA认证方法、装置及存储介质，包括基于EAP的GBA AKA认证方案，以及新的密钥推衍方法。其中，基于EAP的GBA AKA认证方案是在上述EAP AKA或者EAP AKA’认证中增加B-TID和Key lifetime的传递，以使UE与BSF基于EAP完成GBA AKA认证。另外支持EAP的认证方法包含多种，例如EAP AKA或者EAP AKA’的演进协议，EAP-TLS，或者EAP PSK，EAP IKEv2等，针对上述认证方法或者流程，都可以通过新增B-TID和Key lifetime的流程实现GBA的认证功能。另外也可以通过上述认证方法协商后双方共享的密钥作为Ks，或者做进一步推衍得到Ks。针对EAP的GBA扩展，以下仅以EAP AKA流程为例进行阐述。
另外，由于B-TID和Key lifetime为两个参数，因此本申请支持针对B-TID，或者Key lifetime，或者B-TID和Key lifetime的三种处理和分发方式。以下将以B-TID和Key lifetime一起的流程进行描述。其他处理和分发B-TID的流程，就是将以下流程中Key lifetime涉及的部分去除即可，在此不作额外描述。其他处理和分发Key lifetime的流程，就是将以下流程中B-TID涉及的部分去除即可，在此不作额外描述。
与现有的EAP AKA认证流程兼容，本申请提供的基于EAP的GBA AKA认证方案中，仍主要包含三个实体：Peer、Authenticator和EAP server。
图4为本申请一实施例提供的扩展的通用引导架构认证方法的流程图。如图4所示，该方法包括如下步骤：
S401、Authenticator向Peer发送EAP请求消息。
其中，该EAP请求消息用于请求Peer的标识。
对应地，Peer接收EAP请求消息，并对其进行响应，执行S402。
需说明的是，S401为可选步骤。在以下实施例中，该步骤可省略，即整个GBA认证流程可以从S402开始。
S402、Peer发送UE ID至Authenticator。
可选地，UE ID可以为永久ID或者临时ID，包括但不限于以下任意一项：用户永久标识(Subscription Permanent Identifier,SUPI)，用户密封标识(Subscription Concealed Identifier,SUCI)，国际移动用户识别码(International Mobile Subscriber Identity,IMSI)，IP多媒体私有标识(IP Multimedia Private Identity,IMPI)，临时IP多媒体私有ID(Temporary IP Multimedia Private Identity,TMPI)，全球唯一临时标识(Globally Unique Temporary Identifier,GUTI)，临时移动台标识符(Temporary Mobile Station Identity,TMSI)，IP多媒体公共标识(IP Multimedia Public Identity,IMPU)，应用标识(App ID)，网络标识(网络ID)，服务标识(service ID)，NAI等可以唯一标识UE的身份标识。示例地，若UE为server网元，则此UEID可以为server ID；若UE ID为加密后的标识，如SUCI，后续EAP server可以自己解密UE ID得到UE加密前的标识，例如SUPI；或者发送UE ID至其他网元，从其他网元处获得UE加密前的标识，例如SUPI。
对应地，Authenticator接收UE ID，并执行S403。
S403、Authenticator向EAP server发送UE ID。
对应地，EAP server接收UE ID，并执行S404。
S404、EAP server执行AKA算法，生成RAND、AUTN和MAC；生成B-TID和Key lifetime。
其中，Key lifetime代表后续生成的密钥Ks的生命周期。B-TID为Bootstrapping Transaction Identifier，即引导交易ID。可选地，B-TID又可以称为交易ID、识别ID、第一ID、GBA会话ID等其他命名。
可选的，EAP server执行AKA的算法，获得RAND、AUTN和MAC的方式不做限制。例如，EAP server可以从其他网元那里获得相关认证向量，其中包含RAND，AUTN和MAC；或者EAP server自己执行AKA算法，生成RAND，AUTN和MAC。
可选的，B-TID功能为，根据B-TID能够确定BSF地址和/或密钥Ks。
可选地，MAC完整性保护的内容包括B-TID和Key lifetime。
S405、EAP server发送RAND、AUTN、MAC、B-TID和Key lifetime至Authenticator。
可选地，EAP server将RAND、AUTN、MAC、B-TID和Key lifetime携带在EAP请求的AKA挑战(AKA-Challenge)消息等消息中发送，本申请不限制携带RAND、AUTN、MAC、B-TID和Key lifetime的消息的具体名称。
对应地，Authenticator接收RAND、AUTN、MAC、B-TID和Key lifetime，并执行S406。
S406、Authenticator发送RAND、AUTN、MAC、B-TID和Key lifetime至Peer。
对应地，Peer接收RAND、AUTN、MAC、B-TID和Key lifetime，并执行S407。
S407、Peer执行AKA算法，验证AUTN和MAC；并生成RES和密钥。
S408、Peer发送RES和MAC至Authenticator。
可选地，Peer将RES和MAC携带在EAP-response的AKA-Challenge消息等消息中发送至Authenticator，本申请不限制携带RES和MAC的消息的具体名称。
对应地，Authenticator接收RES和MAC，并执行S409。
S409、Authenticator发送RES和MAC至EAP server。
对应地，EAP server接收RES和MAC，并执行S410。
S410、EAP server执行RES和MAC的验证；若验证成功，EAP server生成密钥。
S411、EAP server发送EAP-success消息至Authenticator。
对应地，Authenticator接收EAP-success消息，并执行S412。
S412、Authenticator发送EAP-success消息至Peer。
对应地，Peer接收EAP-success消息，完成GBA AKA认证。
该实施例，通过S401至S412，实现了GBA AKA认证过程中B-TID和Key lifetime的分发，从而实现了EAP AKA中GBA AKA认证需要的参数传递，实现基于EAP的GBA认证；同时，Peer与EAP server共享密钥。
可选的，针对本申请所有实施例流程中MAC相关的操作为可选。在一些实施方式中，也可以不计算、发送和验证MAC。
可选的，针对本申请所有实施例流程中，若Authenticator仅接收消息和发送消息。因此，在一些实施方式中，可以不部署Authenticator网元。
可选地，适用于本申请任一由EAP server生成密钥的实施例，EAP server可以通过以下方式生成密钥，具体的推衍公式如下：
Ks为认证过程中，EAP server生成的密钥，例如：Ks＝CK||IK；或者，Ks＝EMSK，EMSK即扩展的主会话密钥(Extended Master SessionKey)；或者，Ks＝MSK，MSK即主会话密钥(Master SessionKey)。
或者，基于认证过程中生成的密钥，例如：CK||IK、EMSK和MSK中的至少一项，生成密钥Ks。例如：
Ks＝KDF(基础密钥)，其中，KDF表示密钥推衍函数(Key derivation function)；
或者，Ks＝KDF(基础密钥,BSF ID)；
或者，Ks＝KDF(基础密钥,SN ID)，SN ID表示服务网络(Serving network)ID；
或者，Ks＝KDF(基础密钥,SN ID,BSF ID)；
等等。
上述基础密钥为认证过程中EAP server获得的密钥，例如：CK||IK、EMSK和MSK中的至少一项。
上述推衍公式还可以包括指示协议类型的指示，例如指示以下协议指示的至少一项，如EAP，EAP AKA，EAP AKA’，5G，5G AKA，GBA和5G GBA等。
上述推衍公式还可以包括以下参数的至少一项，如UE ID，session ID，EAP server ID，Authenticator ID，上行或下行计数器(counter)，序列号和nonce等。若上述部分参数仅为EAP server拥有的参数，则需发送给Peer，例如session ID，EAP server ID，Authenticator ID，上行或下行counter，序列号或nonce。
上述推衍公式中，CK||IK代表CK和IK的级联。其中BSF ID，可以为EAP server 自己生成，或者从Peer接收到BSF ID。
可选地，适用于本申请任一由Peer生成密钥的实施例，Peer可以通过以下方式生成密钥，具体的推衍公式如下：
Ks为认证过程中，Peer生成的密钥，例如：CK||IK；或者，Ks＝EMSK；或者，Ks＝MSK。
或者，基于认证过程中生成的密钥，例如：CK||IK、EMSK和MSK中的至少一项，生成密钥Ks。例如：
Ks＝KDF(基础密钥)；
或者，Ks＝KDF(基础密钥,BSF ID)；
或者，Ks＝KDF(基础密钥,SN ID)；
或者，Ks＝KDF(基础密钥,SN ID,BSF ID)；
等等。
上述基础密钥为认证过程中Peer获得的密钥，例如：CK||IK、EMSK和MSK中的至少一项。
上述推衍公式还可以包括指示协议类型的指示，例如指示以下协议指示的至少一项，如EAP，EAP AKA，EAP AKA’，5G，5G AKA，GBA和5G GBA等；
上述推衍公式还可以包括以下参数的至少一项，如UE ID，session ID，EAP server ID，Authenticator ID，上行或下行counter，序列号和nonce等；若上述参数为Peer仅拥有的参数，则需发送给EAP server，例如session ID，EAP server ID，Authenticator ID，上行或下行counter，序列号或nonce。
上述推衍公式中，CK||IK代表CK和IK的级联。其中BSF ID，可以为Peer自己生成，或者从BSF接收到BSF ID。
可选地，适用于本申请任一由Authenticator生成密钥的实施例，EAP server不生成Ks密钥，而Authenticator通过以下方式生成Ks密钥，具体的推衍公式如下：
Ks为认证过程中，EAP server生成的密钥并发送至Authenticator，例如：Ks＝CK||IK；或者，Ks＝EMSK；或者，Ks＝MSK。
或者，Authenticator基于从EAP server接收的密钥，例如：CK||IK、EMSK和MSK中的至少一项，生成密钥Ks。例如：
Ks＝KDF(基础密钥)；
或者，Ks＝KDF(基础密钥)；
或者，Ks＝KDF(基础密钥)；
或者，Ks＝KDF(基础密钥,SN ID,BSF ID)；
等等。
上述基础密钥为认证过程中Authenticator获得的密钥，例如：CK||IK、EMSK和MSK中的至少一项。
上述推衍公式还可以包括指示协议类型的指示，例如指示以下协议指示的至少一项，如EAP，EAP AKA，EAP AKA’，5G，GBA和5G GBA等。
上述推衍公式还可以包括以下参数的至少一项，如UE ID，session ID，上行或下行counter，序列号和nonce等。若nonce为Authenticator选择的参数，需发送给Peer。
上述推衍公式还可以包括以下参数的至少一项，如UE ID，session ID，EAP server ID，Authenticator ID，上行或下行counter，序列号和nonce等；若上述参数为Authenticator仅拥有的参数，则需发送给peer，例如session ID，EAP server ID，Authenticator ID，上行或下行counter，序列号或nonce。
上述推衍公式中，CK||IK代表CK和IK的级联。其中BSF ID，可以为BSF自己生成，或者从Peer接收到BSF ID。
可选的，针对本申请的所有实施例，Peer推衍Ks的位置可以为接收到Authenticator消息后任何一步。EAP server推衍Ks的位置可以为接收到Authenticator消息后任何一步。Authenticator推衍Ks的位置可以为接收到EAP server消息后任何一步。因此密钥推衍的具***置，不做限制。
适用于本申请任一由EAP server生成B-TID的实施例，EAP server生成B-TID可以包括：EAP server根据RAND和BSF server name生成B-TID，即base64encode(RAND)@BSF_servers_domain_name，其中base64encode(RAND)代表对RAND进行Base64编码转换。
或者，EAP server生成B-TID可以包括：EAP server生成一标识，作为B-TID。对于该标识的具体生成方式，本申请不予限制，可以包括但不限于随机选择。
由于在上述实施例中增加了B-TID和Key lifetime的传递，因此对EAP已有消息的格式进行修改。以下简要介绍EAP的已有消息格式。
以图5A所示消息(EAP-Request/AKA-Challenge(AT_RAND,AT_AUTN,AT_MAC))为例进行解释：
其中，Code指示是EAP-request消息，还是EAP-reponse，或者EAP succes，或者EAP failure消息，具体地：
Code＝1(Request)，Code＝2(Response)，Code＝3(Success)，Code＝4(Failure)。
此示例中，Code为1，代表EAP-request，以此类推。
Identifier指示用于request和response消息的关联性。
Length指示packet的长度。
Type指示协议类型，例如EAP AKA认证。
Subtype指示子类型，例如AKA-challenge消息类型。
另外，还包括消息的属性信息，此例子中，属性值包括：AT_RAND,AT_AUTN,AT_MAC。
属性信息的格式如图5B所示：
其中，Attribute type为属性类型，例如指示AT_RAND参数类型。
Length为属性长度，包括attribute type，length，和value。
Value为属性值，即具体参数。对于AT_RAND，指具体RAND参数值。
基于上述，B-TID的消息格式可以表示为以下格式：
如图6A所示的格式一；
或者，如图6B所示的格式二。
其中，length代表整个消息的长度，包括(AT_B-TID，length，B-TID length，B-TID)，B-TID length为B-TID内容的长度。
与B-TID的消息格式类似，Key lifetime的消息格式可以表示为：
如图7A所示的格式一；
或者，如图7B所示的格式二。
其中，length代表整个消息的长度，包括(AT_Key lifetime，length，Key lifetime length，Key lifetime)，Key lifetime length为Key lifetime内容的长度。
图8为本申请另一实施例提供的扩展的通用引导架构认证方法的流程图。如图8所示，该方法包括如下步骤：
S801、Authenticator向Peer发送EAP请求消息。
S802、Peer发送UE ID至Authenticator。
S803、Authenticator向EAP server发送UE ID。
其中，S801至S803分别与S401至S403类似，此处不再赘述。
S804、EAP server执行AKA算法，生成RAND、AUTN和MAC。
S805、EAP server发送RAND、AUTN和MAC至Authenticator。
可选地，EAP server将RAND、AUTN和MAC携带在EAP请求的AKA挑战消息等消息中发送，本申请不限制携带RAND、AUTN和MAC的消息的具体名称。
对应地，Authenticator接收RAND、AUTN和MAC，并执行S806。
S806、Authenticator发送RAND、AUTN和MAC至Peer。
对应地，Peer接收RAND、AUTN和MAC，并执行S807。
S807、Peer执行AKA算法，验证AUTN和MAC；并生成RES和密钥。
S808、Peer发送RES和MAC至Authenticator。
可选地，Peer将RES和MAC携带在EAP-response的AKA-Challenge消息等消息中发送至Authenticator，本申请不限制携带RES和MAC的消息的具体名称。
对应地，Authenticator接收RES和MAC，并执行S809。
S809、Authenticator发送RES和MAC至EAP server。
对应地，EAP server接收RES和MAC，并执行S810。
S810、EAP server执行RES和MAC的验证；若验证成功，EAP server生成密钥、B-TID和Key lifetime。
其中，Key lifetime和B-TID的描述可参考图4对应实施例。
S811、EAP server发送EAP-success消息至Authenticator。
其中，该EAP-success消息携带B-TID和Key lifetime。
对应地，Authenticator接收EAP-success消息，并执行S812。
S812、Authenticator发送EAP-success消息至Peer。
对应地，Peer接收EAP-success消息，完成GBA AKA认证。
图8所示所示流程与图4所示流程的区别在于：在图4所示所示流程中，通过EAP 请求的AKA挑战消息携带B-TID和Key lifetime；在图8所示所示流程中，通过EAP-success消息携带B-TID和Key lifetime。
该实施例，通过S801至S812，实现了GBA AKA认证过程中B-TID和Key lifetime的分发，从而实现了EAP AKA中GBA AKA认证需要的参数传递，实现基于EAP的GBA认证；同时，Peer与EAP server共享密钥。
可选地，与上述实施例类似，该实施例对已有的EAP-success消息进行内容的扩展，新增B-TID和Key lifetime的字段。
已有技术中，EAP success消息字段格式如图9所示。参考图9，现有的EAP success消息包括三个字段，分别为：Code、Identifier和Length。其中，Code指示是否成功，具体地：Code＝3(Success)，Code＝4(Failure)。该现有的EAP success消息不支持其他字段或者消息的传递。本申请实施例对现有的EAP success消息进行修改，例如在其后续新增字段用来传递B-TID和Key lifetime，新增的内容如图6A、图6B、6A和图6B所示。
用来传递B-TID的字段格式可以表示为以下格式：
如图7A所示的格式一；
或者，如图7B所示的格式二。
其中，length代表整个消息的长度，包括(AT_B-TID，length，B-TID length，B-TID)，B-TID length为B-TID内容的长度。
与用来传递B-TID的字段格式类似，用来传递Key lifetime的字段格式的可以表示为：
如图7A所示的格式一；
或者，如图7B所示的格式二。
其中，length代表整个消息的长度，包括(AT_Key lifetime，length，Key lifetime length，Key lifetime)，Key lifetime length为Key lifetime内容的长度。
图10为本申请又一实施例提供的扩展的通用引导架构认证方法的流程图。如图10所示，该方法包括如下步骤：
S101、Authenticator向Peer发送EAP请求消息。
S102、Peer发送UE ID至Authenticator。
S103、Authenticator向EAP server发送UE ID。
其中，S101至S103分别与S401至S403类似，此处不再赘述。
S104、EAP server执行AKA算法，生成RAND、AUTN和MAC。
S105、EAP server发送RAND、AUTN和MAC至Authenticator。
可选地，EAP server将RAND、AUTN和MAC携带在EAP请求的AKA挑战消息等消息中发送，本申请不限制携带RAND、AUTN和MAC的消息的具体名称。
对应地，Authenticator接收RAND、AUTN和MAC，并执行S106。
S106、Authenticator发送RAND、AUTN和MAC至Peer。
对应地，Peer接收RAND、AUTN和MAC，并执行S107。
S107、Peer执行AKA算法，验证AUTN和MAC；并生成RES和密钥。
S108、Peer发送RES和MAC至Authenticator。
可选地，Peer将RES和MAC携带在EAP-response的AKA-Challenge消息等消息中发送至Authenticator，本申请不限制携带RES和MAC的消息的具体名称。
对应地，Authenticator接收RES和MAC，并执行S109。
S109、Authenticator发送RES和MAC至EAP server。
对应地，EAP server接收RES和MAC，并执行S110。
S110、EAP server执行RES和MAC的验证；若验证成功，EAP server生成密钥、B-TID和Key lifetime。
其中，Key lifetime和B-TID的描述可参考图4对应实施例。
S111、EAP server发送第一消息至Authenticator。
其中，该第一消息携带B-TID和Key lifetime。可选地，该第一消息可以具体为EAP-Request的AKA-Notification消息等，本申请不限制第一消息的具体名称。
对应地，Authenticator接收第一消息，并执行S112。
S112、Authenticator发送第一消息至Peer。
对应地，Peer接收第一消息，并执行S113。
S113、Peer发送第二消息至Authenticator。
其中，第二消息可以为空，即不携带任何信息。可选地，第二消息可以具体为EAP-Response的AKA-Notification消息等，本申请不限制第二消息的具体名称。
对应地，Authenticator接收第二消息，并执行S114。
S114、Authenticator发送第二消息至EAP server。
对应地，EAP server接收第二消息，并执行S115。
S115、EAP server发送EAP-success消息至Authenticator。
对应地，Authenticator接收EAP-success消息，并执行S116。
S116、Authenticator发送EAP-success消息至Peer。
对应地，Peer接收EAP-success消息，完成GBA AKA认证。
图10所示所示流程与图4所示流程的区别在于：在图4所示所示流程中，通过EAP请求的AKA挑战消息携带B-TID和Key lifetime；在图10所示所示流程中，通过第一消息携带B-TID和Key lifetime。
该实施例，通过S101至S116，实现了GBA AKA认证过程中B-TID和Key lifetime的分发，从而实现了EAP AKA中GBA AKA认证需要的参数传递，实现基于EAP的GBA认证；同时，Peer与EAP server共享密钥。
可选地，与上述实施例类似，该实施例对已有的EAP-Response消息或AKA-Notification消息进行内容的扩展，新增B-TID和Key lifetime的字段。本申请实施例对现有的EAP-Response消息或AKA-Notification消息进行修改，例如在其后续新增字段用来传递B-TID和Key lifetime，新增的内容如图6A、图6B、6A和图6B所示，具体解释可参考上述实施例，此处不再赘述。
在一些实施例中，还可以定义新的EAP消息用来传递B-TID和Key lifetime。该 新的EAP消息可以为EAP-Request的GBA-AKA notification消息等。
综上，上述实施例均是由EAP server生成B-TID和Key lifetime。作为可选方案，B-TID和Key lifetime还可以由Peer生成，具体实现方式通过以下实施例进行解释说明。
图11为本申请又一实施例提供的扩展的通用引导架构认证方法的流程图。如图11所示，该方法包括如下步骤：
S1101、Authenticator向Peer发送EAP请求消息。
S1102、Peer发送UE ID至Authenticator。
S1103、Authenticator向EAP server发送UE ID。
其中，S1101至S1103分别与S401至S403类似，此处不再赘述。
S1104、EAP server执行AKA算法，生成RAND、AUTN和MAC。
S1105、EAP server发送RAND、AUTN和MAC至Authenticator。
可选地，EAP server将RAND、AUTN和MAC携带在EAP请求的AKA挑战消息等消息中发送，本申请不限制携带RAND、AUTN和MAC的消息的具体名称。
对应地，Authenticator接收RAND、AUTN和MAC，并执行S1106。
S1106、Authenticator发送RAND、AUTN和MAC至Peer。
对应地，Peer接收RAND、AUTN和MAC，并执行S1107。
S1107、Peer执行AKA算法，验证AUTN和MAC；并生成RES、密钥、B-TID和Key lifetime。
其中，Key lifetime和B-TID的描述可参考图4对应实施例。
S1108、Peer发送RES和MAC至Authenticator。
可选地，Peer将RES和MAC携带在EAP-response的AKA-Challenge消息等消息中发送至Authenticator，本申请不限制携带RES和MAC的消息的具体名称。
对应地，Authenticator接收RES和MAC，并执行S1109。
S1109、Authenticator发送RES和MAC至EAP server。
对应地，EAP server接收RES和MAC，并执行S1110。
S1110、EAP server执行RES和MAC的验证；若验证成功，EAP server生成密钥，B-TID和Key lifetime。
S1111、EAP server发送EAP-success消息至Authenticator。
对应地，Authenticator接收EAP-success消息，并执行S1112。
S1112、Authenticator发送EAP-success消息至Peer。
对应地，Peer接收EAP-success消息，完成GBA AKA认证。
图11所示所示流程与图4所示流程的区别在于：在图4所示所示流程中，B-TID和Key lifetime由EAP server生成并发送给UE的；在图11所示所示流程中，B-TID和Key lifetime由Peer和EAP server分别生成的。
可选的，针对本申请所有实施例流程中，EAP server生成B-TID和Key lifetime的位置不做限制。Peer生成B-TID和Key lifetime的位置不做限制。
该实施例，通过S1101至S1112，实现了GBA AKA认证过程中B-TID和Key  lifetime的获取，从而实现了EAP AKA中GBA AKA认证需要的参数的获取，实现基于EAP的GBA认证；同时，Peer与EAP server共享密钥。
一些实施例中，Peer生成B-TID，可以包括：根据RAND和BSF server name生成B-TID。具体地，通过S1106，Peer接收RAND，即针对RAND，Peer在认证中得到RAND；针对BSF server name，有以下可能性：
可能性1：认证过程中，EAP server或者Authenticator发送BSF server name至Peer。例如，将BSF server name携带在EAP-request/identity消息，或者，EAP request/AKA-challenge消息中，由EAP server或者Authenticator发送至Peer。
相应地，Peer接收到EAP server或者Authenticator发送的BSF server name。
可选地，这里也可能发送的是BSF server ID。通过BSF server ID，Peer可以获得BSF server name。
可能性2：通过运营商标识，Peer采用一些确定的规则可以得到BSF server name。例如BSF.operator.com，或者BSF server.operater.com。这里operator可以为运营商标识。
可能性3：Peer根据不同场景下Peer的标识，生成BSF server name。例如，Peer根据全球用户识别卡(Universal Subscriber Identity Module,USIM)场景下的IMSI，生成BSF server name；或者，Peer根据IP多媒体服务身份模块(IP Multimedia Service Identity Module,ISIM)场景下的IMPI，生成BSF server name。
一些实施例中，Peer生成Key lifetime，有以下可能性：
可能性1：认证过程中，EAP server或者Authenticator发送Key lifetime至Peer。例如，将Key lifetime携带在EAP-requrest/identity消息，或者，EAP request/AKA-challenge消息中，由EAP server或者Authenticator发送至Peer。
相应地，Peer接收到EAP server或者Authenticator发送的Key lifetime。
可能性2：Peer已预置Key lifetime，或者，在认证之前，Peer已经获得Key lifetime。
Peer根据RAND和BSF server name生成B-TID。可选地，在上述实施例的基础上，具体生成B-TID、Key lifetime和密钥Ks三项中任一项或多项的位置，本申请不做限制。
另需说明的是，由于B-TID和Key lifetime既可以由Peer生成，也可以由EAP server生成，因此：
作为一种可能的实现方式，可以由EAP server生成B-TID，并由Peer生成Key lifetime。相应地，在后续步骤中仅传输B-TID。
作为另一种可能的实现方式，可以由EAP server生成Key lifetime，并由Peer生成B-TID。相应地，在后续步骤中仅传输Key lifetime。
作为一种可能的实现方式，可以由Peer生成B-TID和Key lifetime，并由Peer发送B-TID和Key lifetime至EAP server。
补充说明的是，考虑到已有EAP AKA认证包括：
若Peer不需要success通知消息被保护，则直接采用EAP success消息发送成功指示给Peer；或者，若peer需要success通知消息被保护，则BSF采用AKA-Notification消息发送成功指示给Peer。
因此，对应本申请中B-TID和Key lifetime的分发方法：
若Peer不需要success通知消息被保护，则BSF可以通过EAP-success消息发送B-TID和Key lifetime；或者，若Peer需要success通知消息被保护，则BSF可以通过第一消息发送B-TID和Key lifetime。其中，这里BSF可以为EAP server或者Authenticator。
在上述实施例中，B-TID是根据RAND和BSF server name生成的。对于B-TID的生成，还包括另外一种可能性，即B-TID中前半部分是BSF随机选择的标识，BSF发送B-TID和Key lifetime至Peer。具体的分发B-TID和Key lifetime的方式可以参考前述实施例。其中，B-TID包括两部分内容：一部分为RAND随机数，一部分为BSF server domain name，即B-TID:base64encode(RAND)@BSF_servers_domain_name。因此，这里随机选择是指，不采用认证过程中的RAND参数，而是由BSF随机选择一个随机数，作为B-TID的前半部分。
后续Peer可以发送B-TID至NAF请求执行Peer与NAF之间的认证。NAF发送B-TID至BSF后，BSF根据保存的B-TID确定相应的密钥，并执行之后的NAF key生成等流程。
现有技术中，GBA技术还包括UE与NAF之间K_NAF的密钥协商，参与方包括UE，NAF和BSF。UE与NAF之间K_NAF的密钥协商的基本流程如下：
1、UE保存有B-TID和密钥Ks。UE首先生成Ks_NAF；之后，发起应用请求至NAF，其中，该应用请求携带B-TID，以及其他msg消息；
2、NAF发送B-TID和NAF-ID至BSF；
3、BSF根据B-TID确定密钥Ks，并生成Ks_NAF；发送Ks_NAF，Key lifetime等至NAF；
4、NAF发送应用响应至UE。
上述主要完成了UE如何使用上述认证后得到B-TID，完成与NAF之间的密钥共享。后续UE与NAF之间可以采用TLS等安全方法建立安全通道。
参考上述现有技术，本申请实施例给出了UE与NAF之间基于EAP的认证方式。例如可以假定B-TID为用户名，Ks_ANF为密码(password)；这样就支持EAP-POTP,EAP-PSK,EAP-PWD等认证方法。
下面以EAP-PSK流程为例进行阐述。具体实施方式为，UE执行EAP-PSK流程：
1、UE将认证消息中用户名替换为B-TID，将其中的密码替换为Ks_NAF，并发送修改后的认证消息至NAF。
2、NAF在接收到UE发送的认证消息后，校验其内存储的用户名和密码是否与UE发送的用户名和密码一致。若一致则校验成功，否则校验失败。
现在5G架构包括以下安全网元：认证服务器功能(Authentication Server Function,AUSF)，认证信任状存储和处理功能(Authentication credential Repository and Processing Function,ARPF)，安全锚定功能(SEcurity Anchor Function,SEAF)。上述网元也可用来作为扮演BSF的角色，或者生成Ks发送给BSF。该实施例与上述实施例的区别主要在于：生成密钥的具体实现方式不同。具体B-TID和Key lifetime的生成此处不做限制。可以兼容上述实施例中，BSF生成B-TID和Key lifetime并分发给UE的方法，以及UE生成B-TID和Key lifetime等方式。
一种实现方式中，ARPF基于EMSK，MSK或者CK||IK生成Ks，并发送至BSF。具体推衍公式可以参考图4对应实施例中Ks的生成方法。具体UE的操作包括根据认证过程中密钥生成Ks。
图12为本申请又一实施例提供的扩展的通用引导架构认证方法的流程图。如图12所示，该方法可以包括如下步骤：
S1201、UE发送第一请求至BSF。
其中，该第一请求包含UE ID。
对应地，BSF接收该第一请求，在该第一请求中增加BSF ID形成第二请求，即第二请求包括UE ID和BSF ID，并执行S1202。
S1202、BSF发送第二请求至ARPF。
对应地，ARPF接收该第二请求，并执行S1203。
S1203、ARPF计算认证向量。
其中，认证向量包括Ks，XRES、RAND和AUTN。
S1204、ARPF发送认证向量至BSF。
对应地，BSF接收认证向量，并执行S1205。
S1205、BSF发送认证向量中RAND和AUTN至UE。
对应地，UE接收RAND和AUTN，并执行S1206。
S1206、UE验证AUTN成功，并生成Ks和RES。
S1207、UE发送RES至BSF。
对应地，BSF接收RES，并执行S1208。
S1208、BSF验证XRES与RES是否相同。
若相同，则代表验证UE成功；若不相同，则代表验证UE不成功。
可选地，如果ARPF在生成Ks时不需要BSF ID，则BSF不需要将BSF ID发送给ARPF，即BSF转发第一请求给ARPF即可；或者，如果ARPF可以通过其他方式获得BSF ID，则同样的，BSF不需要将BSF ID发送给ARPF，仅转发第一请求至ARPF。
对于ARPF获得BSF ID方式，本申请不做限制。示例性地，ARPF获得BSF ID方式，可以通过以下任一方式实现：
实现方式一、预置。
实现方式二、根据消息的来源来确定BSF ID。
实现方式三、ARPF向BSF或者其他网元请求获得BSF ID，并得到响应，该响应中包含BSF ID。
上述实现方式中，BSF ID可以替换为BSF server name。
另一种实现方式中，ARPF发送第一密钥至BSF，以使BSF根据第一密钥推衍出Ks。这里第一密钥可以为EMSK，MSK，或者CK||IK；或者，基于EMSK，MSK或者CK||IK生成的第一密钥。具体推衍第一密钥的公式和参数可以参考图4对应实施例中Ks的生成方法。
示例性地，BSF根据第一密钥推衍Ks的公式可能性如下：
Ks＝KDF(第一密钥)；
或者，Ks＝KDF(第一密钥,BSF ID)；
或者，Ks＝KDF(第一密钥,SN ID)；
或者，Ks＝KDF(第一密钥,SN ID,BSF ID)；
等等。
一些实施例中，上述推衍公式还可以包括指示协议类型的指示，例如指示以下协议指示的至少一项：EAP，EAP AKA，EAP AKA’，5G，GBA和5G GBA等。
一些实施例中，上述推衍公式还可以包括以下参数的至少一项：UE ID，session ID，上行或下行counter，序列号和nonce等。若nonce为Authenticator选择的参数，需Authenticator发送nonce给UE。
一些实施例中，上述推衍公式还可以包括以下参数的至少一项：如UE ID，session ID，EAP server ID，Authenticator ID，上行或下行counter，序列号和nonce等。若上述参数为ARPF仅拥有的参数，则需ARPF将参数发送给UE，例如session ID，EAP server ID，Authenticator ID，上行或下行counter，序列号或nonce。
具体UE的操作包括：根据认证过程中密钥生成第一密钥，之后根据第一密钥生成Ks。
图13为本申请又一实施例提供的扩展的通用引导架构认证方法的流程图。如图13所示，该方法可以包括如下步骤：
S1301、UE发送第一请求至BSF。
其中，该第一请求包含UE ID。
对应地，BSF接收该第一请求，在该第一请求中增加BSF ID形成第二请求，即第二请求包括UE ID和BSF ID，并执行S1302。
S1302、BSF发送第二请求至AUSF。
对应地，AUSF接收该第二请求，并执行S1303。
S1303、AUSF发送第二请求给ARPF。
对应地，ARPF接收该第二请求，并执行S1304。
S1304、ARPF计算认证向量。
其中，认证向量包括XRES、RAND、AUTN、Kausf。这里Kasuf代表ARPF发送给AUSF的密钥。也可能认证向量为XRES、RAND、AUTN、(EMSK，MSK和CK||IK的至少一项)。
S1305、ARPF发送认证向量至AUSF。
对应地，AUSF接收认证向量，并执行S1306。
S1306、AUSF基于认证向量生成Ks。
可选地，AUSF基于认证向量生成Ks可包括：AUSF基于CK||IK生成Ks；或者，AUSF基于EMSK或者MSK生成Ks；AUSF基于Kausf生成Ks，等等。
S1307、AUSF发送XRES、RAND、AUTN和Ks给BSF。
对应地，BSF接收XRES、RAND、AUTN和Ks，并执行S1308。
S1308、BSF发送RAND和AUTN至UE。
对应地，UE接收RAND和AUTN，并执行S1309。
S1309、UE验证AUTN成功，并生成Ks和RES。
S1310、UE发送RES至BSF。
对应地，BSF接收RES，并执行S1311。
S1311、BSF验证XRES与RES是否相同。
若相同，则代表验证UE成功；若不相同，则代表验证UE不成功。
本实施例与上个实施例的不同点在于：BSF与AUSF有接口，通过该接口，AUSF从ARPF接收到CK，IK，EMSK，MSK或者Kausf。AUSF根据上述密钥推衍Ks，具体推衍Ks的公式和参数可以参考图4对应实施例中Ks的生成方法。不同点在于除了CK||IK，MSK，EMSK，还有加上Kausf生成的可能性。
可选地，如果AUSF在生成Ks时不需要BSF ID，则BSF不需要将BSF ID发送给AUSF，即BSF转发第一请求给AUSF即可；或者，如果AUSF可以通过其他方式获得BSF ID，则同样的，BSF不需要将BSF ID发送给AUSF，仅转发第一请求至AUSF即可。这里，对于AUSF获得BSF ID方式，本申请不做限制。示例性地，AUSF获得BSF ID方式，可以通过以下任一方式实现：
实现方式一、预置。
实现方式二、根据消息的来源来确定BSF ID。
实现方式三、AUSF向BSF或者其他网元请求获得BSF ID，并得到响应，该响应中包含BSF ID。
上述实现方式中，BSF ID可以替换为BSF server name。
又一种实现方式中，AUSF发送第二密钥至BSF，以使BSF根据第二密钥推衍出Ks。这里第二密钥可以为EMSK，MSK，Kausf，或者CK||IK；或者，基于EMSK，MSK，Kausf，或者CK||IK生成的第二密钥。具体推衍第二密钥的公式和参数可以参考图4对应实施例中Ks的生成方法。
示例性地，BSF根据第二密钥推衍Ks的公式可能性如下：
Ks＝KDF(第二密钥)；
或者，Ks＝KDF(第二密钥,BSF ID)；
或者，Ks＝KDF(第二密钥,SN ID)；
或者，Ks＝KDF(第二密钥,SN ID,BSF ID)；
等等。
一些实施例中，上述推衍公式还可以包括指示协议类型的指示，例如指示以下协议指示的至少一项：EAP，EAP AKA，EAP AKA’，5G，GBA和5G GBA等。
一些实施例中，上述推衍公式还可以包括以下参数的至少一项，如UE ID，session ID，上行或下行counter，序列号和nonce等。若nonce为Authenticator选择的参数，需Authenticator发送nonce给UE。
一些实施例中，上述推衍公式还可以包括以下参数的至少一项：UE ID，session ID，EAP server ID，Authenticator ID，上行或下行counter，序列号和nonce等。若上述参数为AUSF仅拥有的参数，则需AUSF发送参数给UE，例如session ID，EAP server ID，Authenticator ID，上行或下行counter，序列号或nonce。
具体UE的操作包括：根据认证过程中密钥生成第二密钥，之后根据第二密钥生成Ks。
上述BSF ID可以替换为BSF server name。
另外，还有一种可能性：BSF与SEAF有接口。SEAF生成Ks，或者SEAF生成第三密钥，并发送第三密钥至BSF，以使BSF根据第三密钥生成Ks。另外，如果SEAF生成Ks不需要BSF ID，则BSF不需要将BSF ID发送给SEAF；或者，如果SEAF可以通过其他方式获得BSF ID，则同样的BSF不需要将BSF ID发送给SEAF。这里，SEAF获得BSF ID方式，可以为预置，或者根据消息的来源来确定BSF ID，或者SEAF向BSF或者其他网元请求获得BSF ID，并得到响应，该响应中包含BSF ID，等等，这里不做限制。
该可能性实施例与上述实施例还一个不同点为：密钥生成方法中为基于EMSK，MSK，Kseaf，或者CK||IK生成的第三密钥。
针对上述实施例，还存在以下可能性：
可能性1(适用所有实施例)：由Authenticator生成并发送B-TID和Key lifetime至Peer。
可能性2(适用所有实施例)：Peer生成Ks可以为接收到Authenticator发送的EAP-response/AKA-request消息后的任一步骤，对此本申请不做限定。例如，在接收到EAP-success消息之后，Peer生成Ks。
可能性3(适用所有实施例)：EAP server生成Ks可以为接收到Authenticator发送的消息后的任一步骤，对此本申请也不做限定。例如，在接收到EAP-response/AKA-challenge消息之后，EAP server生成Ks。
可能性4(适用所有实施例)：具体Peer和EAP server生成Ks的方式，可以参考如图4所示的实施例的描述。
可能性5(适用所有实施例)：由Authenticator生成Ks，具体生成方式可以参考如图4所示的实施例的描述。
可能性6(适用所有实施例)：针对EAP中网元与GBA网元的对应。有以下可能性：
Peer执行对应UE的动作，EAP server执行对应BSF的动作。这里的动作例如包括：认证，以及生成Ks，生成B-TID和key lifetime，三个动作的至少一项；
或者，Peer执行对应UE的动作，Authenticator执行对应BSF的动作。这里的动 作例如包括：认证，以及生成Ks，生成B-TID和key lifetime，三个动作的至少一项。
或者BSF独立部署，与Authenticator或者EAP server有接口。若BSF独立部署，则UE会先接入BSF，BSF再接入authenticator，authenticator再接入EAP server的方式。也可能UE会先接入authenticator，authenticator再接入BSF，BSF再接入EAP server的方式。
可能性7(适用所有实施例)：上述提到的CK和IK，表示为加密密钥和完整性保护密钥，表示符号不做限制，也可以为CK’和IK‘等，这里不做限制。
可能性8(适用所有实施例)：针对ARPF,AUSF和SEAF网元与GBA网元的对应。有以下可能性：
ARPF执行对应BSF的动作。这里的动作例如包括：认证，以及生成Ks，生成B-TID和key lifetime，三个动作的至少一项；
或者，AUSF执行对应BSF的动作。这里的动作例如包括：认证，以及生成Ks，生成B-TID和key lifetime，三个动作的至少一项；
或者，SEAF执行对应BSF的动作。这里的动作例如包括：认证，以及生成Ks，生成B-TID和key lifetime，三个动作的至少一项。
可能性9(适用所有实施例)：UE或Peer生成Ks可以为接收到BSF/ARPF/AUSF/SEAF发送的消息后的任一步骤，对此本申请不做限定。
可能性10(适用所有实施例)：BSF/ARPF/AUSF/SEAF生成Ks可以为接收到UE或Peer发送的相关消息后的任一步骤，对此本申请也不做限定。
可能性11(适用所有实施例)：针对ARPF/AUSF/SEAF网络与GBA网元的对应。有以下可能性：
BSF独立部署，与ARPF/AUSF/SEAF有接口。若BSF独立部署，则UE会先接入BSF，BSF再接入ARPF/AUSF/SEAF。也可能UE会先接入SEAF，SEAF再接入BSF，BSF再接入AUSF的方式。也可能UE会先接入SEAF，SEAF再接入AUSF，AUSF再接入BSF，BSF再接入ARPF的方式。上述组合方式不做限制。
综上，本申请涉及到的第一网元可以是EAP server或AUSF等，终端可以是Peer或UE，第二网元可以是Authenticator等，本申请对此不做限制，具体示例可参考后续实施例。且，对于生成密钥的执行主体，本申请也不对此做限制，可以是EAP server、Peer、UE、AUSF、Authenticator或ARPF等。
上文中详细描述了根据本申请实施例的扩展的通用引导架构认证方法，下面将描述本申请实施例的扩展的通用引导架构认证装置。
本申请实施例详细描述了扩展的通用引导架构认证装置的示意性结构。
在一个示例中，图14为本申请一实施例提供的扩展的通用引导架构认证装置的示意性框图。本申请实施例的扩展的通用引导架构认证装置1400可以是上述方法实施例中的第一网元，也可以是第一网元内的一个或多个芯片。扩展的通用引导架构认证装置1400可以用于执行上述方法实施例中的第一网元的部分或全部功能。该扩展的通用引导架构认证装置1400可以包括处理模块1410和收发模块1420，可选的，该扩展的通用引导架构认证装置1400还可以包括存储模块1430。
例如，该处理模块1410，可以用于执行前述方法实施例中生成B-TID和key lifetime的步骤。
该收发模块1420，可以用于执行前述方法实施例中的发送B-TID和key lifetime的步骤。
可以替换的，扩展的通用引导架构认证装置1400也可配置成通用处理***，例如通称为芯片，该处理模块1410可以包括：提供处理功能的一个或多个处理器；所述收发模块1420例如可以是输入/输出接口、管脚或电路等，输入/输出接口可用于负责此芯片***与外界的信息交互，例如，此输入/输出接口可将处理模块1410生成的B-TID和key lifetime输出给此芯片外的其他模块进行处理。该处理模块1410可执行存储模块1430中存储的计算机执行指令以实现上述方法实施例中第一网元的功能。在一个示例中，扩展的通用引导架构认证装置1400中可选的包括的存储模块1430可以为芯片内的存储单元，如寄存器、缓存等，所述存储模块1430还可以是所述第一网元内的位于芯片外部的存储单元，如只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)等。
在另一个示例中，图15为本申请另一实施例提供的扩展的通用引导架构认证装置的示意性框图。本申请实施例的扩展的通用引导架构认证装置1500可以是上述方法实施例中的第一网元，扩展的通用引导架构认证装置1500可以用于执行上述方法实施例中的第一网元的部分或全部功能。该扩展的通用引导架构认证装置1500可以包括：处理器1510，基带电路1530，射频电路1540以及天线1550，可选的，该扩展的通用引导架构认证装置1500还可以包括存储器1520。扩展的通用引导架构认证装置1500的各个组件通过总线1560耦合在一起，其中总线***1560除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图中将各种总线都标为总线***1560。
处理器1510可用于实现对第一网元的控制，用于执行上述实施例中由第一网元进行的处理，可以执行上述方法实施例中涉及第一网元的处理过程和/或用于本申请所描述的技术的其他过程，还可以运行操作***，负责管理总线以及可以执行存储在存储器中的程序或指令。
基带电路1530、射频电路1540以及天线1550可以用于支持第一网元和上述实施例中涉及的终端之间收发信息，以支持第一网元与终端之间进行无线通信。
存储器1520可以用于存储发送端的程序代码和数据，存储器1520可以是图15中的存储模块1530。可以理解的，基带电路1530、射频电路1540以及天线1550还可以用于支持第一网元与其他网络实体进行通信，例如，用于支持第一网元与其他网元进行通信。图15中存储器1520被示为与处理器1510分离，然而，本领域技术人员很容易明白，存储器1520或其任意部分可位于扩展的通用引导架构认证装置1500之外。举例来说，存储器1520可以包括传输线、和/或与无线节点分离开的计算机制品，这些介质均可以由处理器1510通过总线接口1560来访问。可替换地，存储器1520或其任意部分可以集成到处理器1510中，例如，可以是高速缓存和/或通用寄存器。
可以理解的是，图15仅仅示出了第一网元的简化设计。例如，在实际应用中，第 一网元可以包含任意数量的发射器，接收器，处理器，存储器等，而所有可以实现本申请的第一网元都在本申请的保护范围之内。
一种可能的实现方式中，第一网元侧的扩展的通用引导架构认证装置也可以使用下述来实现：一个或多个现场可编程门阵列(field-programmable gate array，FPGA)、可编程逻辑器件(programmable logic device，PLD)、控制器、状态机、门逻辑、分立硬件部件、任何其它适合的电路、或者能够执行本申请通篇所描述的各种功能的电路的任意组合。在又一个示例中，本申请实施例还提供一种计算机存储介质，该计算机存储介质可以存储用于指示上述任一种方法的程序指令，以使得处理器执行此程序指令实现上述方法实施例中涉及第一网元的方法和功能。
本申请实施例详细描述扩展的通用引导架构认证装置的示意性结构。在一个示例中，图16为本申请又一实施例提供的扩展的通用引导架构认证装置的示意性框图。本申请实施例的扩展的通用引导架构认证装置1600可以是上述方法实施例中的终端，也可以是终端内的一个或多个芯片。扩展的通用引导架构认证装置1600可以用于执行上述方法实施例中的终端的部分或全部功能。该扩展的通用引导架构认证装置1600可以包括处理模块1610和收发模块1620，可选的，该扩展的通用引导架构认证装置1600还可以包括存储模块1630。该收发模块1620，用于接收B-TID和key lifetime。
可以替换的，扩展的通用引导架构认证装置1600也可配置成通用处理***，例如通称为芯片，该处理模块1610可以包括：提供处理功能的一个或多个处理器；所述收发模块1620例如可以是输入/输出接口、管脚或电路等，输入/输出接口可用于负责此芯片***与外界的信息交互。该一个或多个处理器可执行存储模块1630中存储的计算机执行指令以实现上述方法实施例中终端的功能。在一个示例中，扩展的通用引导架构认证装置1600中可选的包括的存储模块1630可以为芯片内的存储单元，如寄存器、缓存等，所述存储模块1630还可以是所述终端内的位于芯片外部的存储单元，如ROM或可存储静态信息和指令的其他类型的静态存储设备，RAM等。
在另一个示例中，图17为本申请又一实施例提供的扩展的通用引导架构认证装置的示意性框图。本申请实施例的扩展的通用引导架构认证装置1700可以是上述方法实施例中的终端，扩展的通用引导架构认证装置1700可以用于执行上述方法实施例中的终端的部分或全部功能。该扩展的通用引导架构认证装置1700可以包括：处理器1710，基带电路1730，射频电路1740以及天线1750，可选的，该扩展的通用引导架构认证装置1700还可以包括存储器1720。扩展的通用引导架构认证装置1700的各个组件通过总线1760耦合在一起，其中总线***1760除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图中将各种总线都标为总线***1760。
处理器1710可用于实现对终端的控制，用于执行上述实施例中由终端进行的处理，可以执行上述方法实施例中涉及终端的处理过程和/或用于本申请所描述的技术的其他过程，还可以运行操作***，负责管理总线以及可以执行存储在存储器中的程序或指令。
基带电路1730，射频电路1740以及天线1750可以用于支持终端和上述实施例中涉及的第一网元之间收发信息，以支持第一网元与终端之间进行无线通信。一个存储 器1720可以用于存储发送端的程序代码和数据，存储器1720可以是图17中的存储模块1730。可以理解的，基带电路1730，射频电路1740以及天线1750还可以用于支持终端与其他网络实体进行通信。
可以理解的是，图17仅仅示出了终端的简化设计。例如，在实际应用中，终端可以包含任意数量的发射器，接收器，处理器，存储器等，而所有可以实现本申请的终端都在本申请的保护范围之内。
一种可能的实现方式中，终端侧的扩展的通用引导架构认证装置也可以使用下述来实现：一个或多个现场可编程门阵列(field-programmable gate array，FPGA)、可编程逻辑器件(programmable logic device，PLD)、控制器、状态机、门逻辑、分立硬件部件、任何其它适合的电路、或者能够执行本申请通篇所描述的各种功能的电路的任意组合。
在又一个示例中，本申请实施例还提供一种计算机存储介质，该计算机存储介质可以存储用于指示上述任一种方法的程序指令，以使得处理器执所述程序指令实现上述方法实施例中涉及终端的方法和功能。
上述扩展的通用引导架构认证装置1500和扩展的通用引导架构认证装置1700中涉及的处理器可以是通用处理器，例如通用中央处理器(CPU)、网络处理器(Network Processor，简称NP)、微处理器等，也可以是特定应用集成电路(application-specific integrated circBIt，简称ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。还可以是数字信号处理器(Digital Signal Processor，简称DSP)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。控制器/处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。处理器通常是基于存储器内存储的程序指令来执行逻辑和算术运算。
上述扩展的通用引导架构认证装置1500和扩展的通用引导架构认证装置1700中涉及的存储器还可以保存有操作***和其他应用程序。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。更具体的，上述存储器可以是只读存储器(read-only memory，简称ROM)、可存储静态信息和指令的其他类型的静态存储设备、随机存取存储器(random access memory，简称RAM)、可存储信息和指令的其他类型的动态存储设备、磁盘存储器等等。存储器可以是上述存储类型的组合。并且上述计算机可读存储介质/存储器可以在处理器中，还可以在处理器的外部，或在包括处理器或处理电路的多个实体上分布。上述计算机可读存储介质/存储器可以具体体现在计算机程序产品中。举例而言，计算机程序产品可以包括封装材料中的计算机可读介质。
在本申请所提供的几个实施例中，应该理解到，所揭露的***，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显 示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
本申请一实施例提供一种计算存储介质，包括程序指令，所述程序指令用于实现上述任一实施例所述的方法。

Claims (31)

  1. 一种扩展的通用引导架构认证方法，其特征在于，包括：
    第一网元获取引导交易标识B-TID和密钥的生命周期Key lifetime；
    第一网元发送所述B-TID和所述Key lifetime至终端，以使所述终端根据所述B-TID和所述Key lifetime，与所述第一网元进行基于可扩展的身份验证协议EAP的通用引导架构GBA认证与密钥协商AKA认证。
  2. 根据权利要求1所述的方法，其特征在于，所述第一网元获取B-TID，包括：
    所述第一网元根据随机数RAND和引导服务器功能BSF服务器名称生成B-TID；
    或者，所述第一网元生成一标识，作为所述B-TID。
  3. 根据权利要求1所述的方法，其特征在于，所述第一网元发送所述B-TID和所述Key lifetime至终端，包括：
    所述第一网元发送EAP请求的AKA挑战消息给所述终端，所述EAP请求的AKA挑战消息携带所述B-TID和所述Key lifetime。
  4. 根据权利要求1所述的方法，其特征在于，所述第一网元发送所述B-TID和所述Key lifetime至终端之后，还包括：
    所述第一网元接收所述终端发送的RES和消息验证码MAC；
    所述第一网元执行所述RES和所述MAC的验证；
    若验证成功，所述第一网元生成密钥，并发送EAP-success消息至所述终端。
  5. 根据权利要求1至4任一项所述的方法，其特征在于，所述终端和所述第一网元之间通过第二网元收发信息，所述信息包括所述B-TID和所述Key lifetime。
  6. 根据权利要求5所述的方法，其特征在于，所述第一网元获取B-TID和Key lifetime之前，还包括：
    所述第一网元接收所述终端发送的所述终端的标识。
  7. 根据权利要求6所述的方法，其特征在于，所述第一网元接收所述终端发送的所述终端的标识之后，还包括：
    所述第一网元通过以下任一方式获取随机数RAND、认证令牌AUTN和消息验证码MAC：
    方式一、所述第一网元执行AKA算法，生成所述RAND、所述AUTN和所述MAC；
    方式二、所述第一网元接收所述RAND、所述AUTN和所述MAC。
  8. 根据权利要求6所述的方法，其特征在于，所述第一网元接收所述终端发送的所述终端的标识，包括：
    所述第一网元接收所述第二网元发送的所述终端的标识，所述终端的标识是由所述终端在接收到所述第二网元发送的EAP请求消息之后，发送给所述第二网元的，所述EAP请求消息用于请求所述终端的标识。
  9. 一种扩展的通用引导架构认证方法，其特征在于，包括：
    终端接收第一网元发送的引导交易标识B-TID和密钥的生命周期Key lifetime；
    所述终端根据所述B-TID和所述Key lifetime，与所述第一网元进行基于可扩展的身份验证协议EAP的通用引导架构GBA认证与密钥协商AKA认证。
  10. 根据权利要求9所述的方法，其特征在于，所述终端接收第一网元发送的B-TID和Key lifetime，包括：
    所述终端接收所述第一网元发送的EAP请求的AKA挑战消息，所述EAP请求的AKA挑战消息携带所述B-TID和所述Key lifetime。
  11. 根据权利要求9所述的方法，其特征在于，所述终端根据所述B-TID和所述Key lifetime，与所述第一网元进行基于EAP的GBA认证，包括：
    所述终端获取随机数RAND、认证令牌AUTN和消息验证码MAC；
    所述终端执行AKA算法，验证所述AUTN和所述MAC；
    所述终端生成RES和密钥；
    所述终端发送所述RES和所述MAC给所述第一网元，以使所述第一网元执行所述RES和所述MAC的验证，若验证成功，所述第一网元生成密钥，并发送EAP-success消息至所述终端；
    所述终端接收所述EAP-success消息。
  12. 根据权利要求9至11任一项所述的方法，其特征在于，所述终端和所述第一网元之间通过第二网元收发信息，所述信息包括所述B-TID和所述Key lifetime。
  13. 根据权利要求12所述的方法，其特征在于，所述终端接收第一网元发送的B-TID和Key lifetime之前，还包括：
    所述终端发送所述终端的标识给所述第一网元。
  14. 根据权利要求13所述的方法，其特征在于，所述终端发送所述终端的标识给所述第一网元，包括：
    所述终端发送所述终端的标识给所述第二网元，以使所述第二网元发送所述终端的标识给所述第一网元。
  15. 根据权利要求13或14所述的方法，其特征在于，所述终端发送所述终端的标识给所述第一网元之前，还包括：
    所述终端接收所述第二网元发送的EAP请求消息，所述EAP请求消息用于请求所述终端的标识。
  16. 一种密钥生成方法，其特征在于，包括：
    获取密钥参数，所述密钥参数包括；加密密钥CK和完整性保护密钥IK、扩展的主会话密钥EMSK、主会话密钥MSK中的至少一项；
    根据所述密钥参数生成密钥。
  17. 根据权利要求16所述的方法，其特征在于，所述根据所述密钥参数生成密钥，包括以下实现方式的任一种：
    实现方式一、所述密钥参数包括；CK和IK，计算推衍公式一：Ks＝CK||IK，CK||IK代表CK和IK的级联；
    实现方式二、所述密钥参数包括；EMSK，计算推衍公式二：Ks＝EMSK；
    实现方式三、所述密钥参数包括；MSK，计算推衍公式三：Ks＝MSK；
    上述公式中，Ks表示生成的所述密钥。
  18. 根据权利要求16所述的方法，其特征在于，所述根据所述密钥参数生成密钥，包括：
    基于认证过程中生成的基础密钥生成密钥，其中，所述基础密钥包括CK||IK、扩展的主会话密钥EMSK和主会话密钥MSK中的至少一项。
  19. 根据权利要求18所述的方法，其特征在于，所述基于认证过程中生成的基础密钥生成密钥，包括：
    通过以下方式生成密钥Ks，具体的推衍公式如下：
    公式四、Ks＝KDF(基础密钥)，其中，KDF表示密钥推衍函数；
    公式五、Ks＝KDF(基础密钥,BSF ID)；
    公式六、Ks＝KDF(基础密钥,SN ID)，SN ID表示服务网络ID；
    公式七、Ks＝KDF(基础密钥,SN ID,BSF ID)。
  20. 根据权利要求17或19所述的方法，其特征在于，所述推衍公式还包括：
    指示协议类型的指示，所述协议类型包括以下至少一项：EAP，EAP AKA，EAP AKA’，5G，5G AKA，GBA和5G GBA等。
  21. 根据权利要求17或19或20所述的方法，其特征在于，所述推衍公式还包括以下参数的至少一项：
    UE ID，session ID，EAP server ID，Authenticator ID，上行或下行计数器，序列号和nonce等。
  22. 一种扩展的通用引导架构认证装置，其特征在于，包括：
    处理模块，用于获取引导交易标识B-TID和密钥的生命周期Key lifetime；
    收发模块，用于发送所述B-TID和所述Key lifetime至终端，以使所述终端根据所述B-TID和所述Key lifetime，与第一网元进行基于可扩展的身份验证协议EAP的通用引导架构GBA认证与密钥协商AKA认证。
  23. 一种扩展的通用引导架构认证装置，其特征在于，包括：
    收发模块，用于接收第一网元发送的引导交易标识B-TID和密钥的生命周期Key lifetime；
    处理模块，用于根据所述B-TID和所述Key lifetime，与所述第一网元进行基于可扩展的身份验证协议EAP的通用引导架构GBA认证与密钥协商AKA认证。
  24. 一种密钥生成装置，其特征在于，包括：
    处理模块，用于获取密钥参数，所述密钥参数包括；加密密钥CK和完整性保护密钥IK、扩展的主会话密钥EMSK、主会话密钥MSK中的至少一项；并，根据所述密钥参数生成密钥。
  25. 一种扩展的通用引导架构认证装置，其特征在于，包括：
    处理器，用于获取引导交易标识B-TID和密钥的生命周期Key lifetime；
    收发器，用于发送所述B-TID和所述Key lifetime至终端，以使所述终端根据所述B-TID和所述Key lifetime，与第一网元进行基于可扩展的身份验证协议EAP的通用引导架构GBA认证与密钥协商AKA认证。
  26. 一种扩展的通用引导架构认证装置，其特征在于，包括：
    收发器，用于接收第一网元发送的引导交易标识B-TID和密钥的生命周期Key lifetime；
    处理器，用于根据所述B-TID和所述Key lifetime，与所述第一网元进行基于可扩 展的身份验证协议EAP的通用引导架构GBA认证与密钥协商AKA认证。
  27. 一种密钥生成装置，其特征在于，包括：
    处理器，用于获取密钥参数，所述密钥参数包括；加密密钥CK和完整性保护密钥IK、扩展的主会话密钥EMSK、主会话密钥MSK中的至少一项；并，根据所述密钥参数生成密钥。
  28. 一种计算存储介质，其特征在于，包括程序指令，所述程序指令用于实现如权利要求1至21任一项所述的方法。
  29. 一种扩展的通用引导架构认证装置，其特征在于，包括：存储器和处理器；
    所述存储器，用于存储程序代码；
    所述处理器，调用所述程序代码，当程序代码被执行时，用于执行如权利要求1-8任一项或者9-15任一项所述的方法。
  30. 一种密钥生成装置，其特征在于，包括：
    存储器和处理器；
    所述存储器，用于存储程序代码；
    所述处理器，调用所述程序代码，当程序代码被执行时，用于执行如权利要求16-21任一项所述的方法。
  31. 一种程序产品，其特征在于，所述程序产品包括计算机程序，所述计算机程序存储在可读存储介质中；
    扩展的通用引导架构认证装置的至少一个处理器可以从所述可读存储介质读取所述计算机程序，所述至少一个处理器执行所述计算机程序使得所述扩展的通用引导架构认证装置实施如权利要求1-8任一项或者9-15任一项所述的方法；或者，
    密钥生成装置的至少一个处理器可以从所述可读存储介质读取所述计算机程序，所述至少一个处理器执行所述计算机程序使得所述密钥生成装置实施如权利要求16-21任一项所述的方法。
PCT/CN2019/095193 2018-08-10 2019-07-09 扩展的通用引导架构认证方法、装置及存储介质 WO2020029735A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP19848561.7A EP3817271A4 (en) 2018-08-10 2019-07-09 METHOD AND DEVICE FOR EXPANDABLE AUTHENTICATION BASED ON GENERIC BOOTSTRAP ARCHITECTURE AND STORAGE MEDIUM
US17/169,737 US20210165885A1 (en) 2018-08-10 2021-02-08 Extended Authentication Method And Apparatus For Generic Bootstrapping Architecture, And Storage Medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810911034.4A CN110831002B (zh) 2018-08-10 2018-08-10 一种密钥推演的方法、装置及计算存储介质
CN201810911034.4 2018-08-10

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/169,737 Continuation US20210165885A1 (en) 2018-08-10 2021-02-08 Extended Authentication Method And Apparatus For Generic Bootstrapping Architecture, And Storage Medium

Publications (1)

Publication Number Publication Date
WO2020029735A1 true WO2020029735A1 (zh) 2020-02-13

Family

ID=69414489

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/095193 WO2020029735A1 (zh) 2018-08-10 2019-07-09 扩展的通用引导架构认证方法、装置及存储介质

Country Status (4)

Country Link
US (1) US20210165885A1 (zh)
EP (1) EP3817271A4 (zh)
CN (2) CN110831002B (zh)
WO (1) WO2020029735A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111147421B (zh) * 2018-11-02 2023-06-16 中兴通讯股份有限公司 一种基于通用引导架构gba的认证方法及相关设备
WO2022027674A1 (zh) * 2020-08-07 2022-02-10 华为技术有限公司 一种通用引导架构中的方法及相关装置
CN114449515A (zh) * 2020-10-20 2022-05-06 中国电信股份有限公司 验证方法、***和应用平台、终端

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101156486A (zh) * 2005-02-14 2008-04-02 诺基亚公司 无线通信***中数据优化传输的方法和装置
US20110255692A1 (en) * 2010-04-14 2011-10-20 Qualcomm Incorporated Power savings through cooperative operation of multiradio devices

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI20041447A0 (fi) * 2004-11-09 2004-11-09 Nokia Corp Avainderivointitoiminnon määrittäminen
WO2007063420A2 (en) * 2005-12-01 2007-06-07 Nokia Corporation Authentication in communications networks
CN101087261B (zh) * 2006-06-05 2012-05-23 华为技术有限公司 基于通用引导构架实现推送功能的方法、设备和***
WO2009106091A1 (en) * 2008-02-25 2009-09-03 Nokia Siemens Networks Oy Secure bootstrapping architecture method based on password-based digest authentication
CN101888626B (zh) * 2009-05-15 2013-09-04 ***通信集团公司 一种实现gba密钥的方法及其终端设备
CN102238540A (zh) * 2010-04-27 2011-11-09 ***通信集团公司 通用引导架构密钥更新的方法、装置与***
AU2011380272A1 (en) * 2011-10-31 2014-05-22 Nokia Technologies Oy Security mechanism for external code
WO2013159818A1 (en) * 2012-04-26 2013-10-31 Telefonaktiebolaget L M Ericsson (Publ) Network application function authorisation in a generic bootstrapping architecture
FR2992811A1 (fr) * 2012-07-02 2014-01-03 France Telecom Mise en place d'une association de securite lors de l'attachement d'un terminal a un reseau d'acces
KR20180086286A (ko) * 2013-05-22 2018-07-30 콘비다 와이어리스, 엘엘씨 액세스 네트워크 지원형 부트스트랩핑
GB2586549B (en) * 2013-09-13 2021-05-26 Vodafone Ip Licensing Ltd Communicating with a machine to machine device
US10142769B2 (en) * 2015-01-14 2018-11-27 Samsung Electronics Co., Ltd. Method and system for establishing a secure communication between remote UE and relay UE in a device to device communication network
WO2017153858A1 (en) * 2016-03-09 2017-09-14 Telefonaktiebolaget Lm Ericsson (Publ) Systems and methods for using gba for services used by multiple functions on the same device
JP6725764B2 (ja) * 2017-01-30 2020-07-22 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 無線リソース制御接続の再確立
WO2019108100A1 (en) * 2017-11-29 2019-06-06 Telefonaktiebolaget Lm Ericsson (Publ) Session key establishment
US10880291B2 (en) * 2018-02-09 2020-12-29 Cisco Technology, Inc. Mobile identity for single sign-on (SSO) in enterprise networks

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101156486A (zh) * 2005-02-14 2008-04-02 诺基亚公司 无线通信***中数据优化传输的方法和装置
US20110255692A1 (en) * 2010-04-14 2011-10-20 Qualcomm Incorporated Power savings through cooperative operation of multiradio devices

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
3GPP TS33.220

Also Published As

Publication number Publication date
CN114363890A (zh) 2022-04-15
CN110831002B (zh) 2021-12-03
US20210165885A1 (en) 2021-06-03
EP3817271A1 (en) 2021-05-05
CN110831002A (zh) 2020-02-21
EP3817271A4 (en) 2021-09-08

Similar Documents

Publication Publication Date Title
US11405780B2 (en) Method for performing verification by using shared key, method for performing verification by using public key and private key, and apparatus
US11825303B2 (en) Method for performing verification by using shared key, method for performing verification by using public key and private key, and apparatus
US11496320B2 (en) Registration method and apparatus based on service-based architecture
US11178584B2 (en) Access method, device and system for user equipment (UE)
US10129031B2 (en) End-to-end service layer authentication
CN106922216B (zh) 用于无线通信的装置、方法和存储介质
JP6732095B2 (ja) 異種ネットワークのための統一認証
JP5579872B2 (ja) 安全な複数ｕｉｍ認証および鍵交換
CN111147231B (zh) 一种密钥协商的方法、相关装置及***
JP2016096557A (ja) 暗号鍵の生成
EP2957114B1 (en) Method and network node for obtaining a permanent identity of an authenticating wireless device
US20210165885A1 (en) Extended Authentication Method And Apparatus For Generic Bootstrapping Architecture, And Storage Medium
WO2018076740A1 (zh) 数据传输方法及相关设备
JP7237200B2 (ja) パラメータ送信方法及び装置
CN115104332A (zh) 重新认证密钥生成
US20220329582A1 (en) Communication method and related product
US20190149326A1 (en) Key obtaining method and apparatus
CN111836260A (zh) 一种认证信息处理方法、终端和网络设备
WO2021236078A1 (en) Simplified method for onboarding and authentication of identities for network access
US20230308874A1 (en) Security authentication method and apparatus applied to wi-fi
US20230300615A1 (en) Security authentication method and apparatus applied to wi-fi
US20230108626A1 (en) Ue challenge to a network before authentication procedure
Londe et al. A new lightweight eap-pk authentication method for ieee 802. 11 standard wireless network
WO2019001509A1 (zh) 一种网络鉴权方法及***

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: 19848561

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019848561

Country of ref document: EP

Effective date: 20210127

NENP Non-entry into the national phase

Ref country code: DE