Extended universal boot architecture authentication method, device and storage medium

Abstract

The present application provides an extended universal bootstrap architecture authentication method, device and storage medium, the method comprising: a first network element obtains a B‑TID and a Key lifetime; the first network element sends the B‑TID and the Key lifetime to a terminal, so that the terminal performs an EAP-based GBA AKA authentication with the first network element according to the B‑TID and the Key lifetime, thereby enabling the terminal and the first network element to complete the GBA AKA authentication based on EAP.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to an extended universal boot architecture authentication method, device and storage medium. Background Art

[0002] As a Generic Bootstrapping Architecture (GBA) for mobile communications, GBA technology can be used to establish a secure tunnel between User Equipment (UE) and Network Application Function (NAF). GBA technology includes GBA Authentication and Key Agreement (AKA) authentication.

[0003] In the Universal Mobile Telecommunications System (UMTS) 3G scenario, 3GPP TS33.220 has given a specific definition of GBA AKA authentication. In the defined GBA AKA authentication, the UE and the Bootstrapping Server Function (BSF) complete the GBA AKA authentication based on the HyperText Transfer Protocol (HTTP). Considering the development trend of the Extensible Authentication Protocol (EAP) and the possibility of other applications in the future, the inventor studies an extended GBA authentication method. Summary of the invention

[0004] The present application provides an extended general bootstrapping architecture authentication method, device and storage medium, so that UE and BSF complete GBA AKA authentication based on EAP.

[0005] In a first aspect, the present application provides an extended general bootstrap architecture authentication method, including: a first network element obtains a B-TID and a Key lifetime; the first network element sends the B-TID and the Key lifetime to a terminal, so that the terminal performs an EAP-based GBA AKA authentication with the first network element according to the B-TID and the Key lifetime.

[0006] The beneficial effects of the present application include: since the extended general bootstrapping architecture authentication method provided by the present application is based on EAP, the UE and the BSF can complete the GBA AKA authentication based on EAP.

[0007] Optionally, the first network element acquires the B-TID, which may include: the first network element generates the 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.

[0008] Optionally, the first network element sends the B-TID and the Key lifetime to the terminal, including: the first network element sends an AKA challenge message of an EAP request to the terminal, and the AKA challenge message of the EAP request carries the B-TID and the Key lifetime. That is, the B-TID and the Key lifetime are transmitted through the AKA challenge message of the EAP request.

[0009] Optionally, after the first network element sends B-TID and Key lifetime to the terminal, the method provided in the present application may also include: the first network element receives RES and MAC sent by the terminal, and performs verification of RES and MAC; if the verification is successful, the first network element generates a key and sends an EAP-success message to the terminal to complete the EAP-based GBA AKA authentication.

[0010] Optionally, before the first network element acquires the B-TID and the Key lifetime, the process further includes: the first network element receiving an identifier of the terminal sent by the terminal.

[0011] Optionally, after the first network element receives the terminal identifier sent by the terminal, the method further includes: the first network element obtains RAND, AUTN, and MAC by any of the following methods:

[0012] Method 1: The first network element executes the AKA algorithm to generate RAND, AUTN and MAC;

[0013] Method 2: The first network element receives RAND, AUTN and MAC.

[0014] Optionally, the first network element receiving the terminal identifier sent by the terminal may include: the first network element receiving the terminal identifier sent by the second network element, the terminal identifier being sent by the terminal to the second network element after receiving an EAP request message sent by the second network element, wherein the EAP request message is used to request the terminal identifier.

[0015] In a second aspect, the present application provides an extended general bootstrapping architecture authentication method, including: a terminal receives a B-TID and a Key lifetime sent by a first network element; and the terminal performs an EAP-based GBA AKA authentication with the first network element according to the B-TID and the Key lifetime.

[0016] The beneficial effects of the present application include: since the extended general bootstrapping architecture authentication method provided by the present application is based on EAP, the UE and the BSF can complete the GBA AKA authentication based on EAP.

[0017] Optionally, the terminal receiving the B-TID and Key lifetime sent by the first network element may include: the terminal receiving an AKA challenge message of an EAP request sent by the first network element, where the AKA challenge message of the EAP request carries the B-TID and Key lifetime.

[0018] Optionally, the terminal performs EAP-based GBA authentication with the first network element according to B-TID and Key lifetime, including: the terminal obtains RAND, AUTN and MAC; the terminal executes the AKA algorithm to verify AUTN and MAC; the terminal generates RES and a key; the terminal sends RES and MAC to the first network element so that the first network element performs verification of RES and MAC. If the verification is successful, the first network element generates a key and sends an EAP-success message to the terminal; the terminal receives the EAP-success message.

[0019] Optionally, before the terminal receives the B-TID and Key lifetime sent by the first network element, the method further includes: the terminal sends an identifier of the terminal to the first network element.

[0020] Optionally, the terminal sending the terminal identifier to the first network element includes: the terminal sending the terminal identifier to the second network element, so that the second network element sends the terminal identifier to the first network element.

[0021] Optionally, before the terminal sends the terminal identifier 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 terminal identifier.

[0022] Based on the above, there are also the following possible implementations:

[0023] Optionally, the B-TID may also be used to determine the BSF address and / or key.

[0024] Optionally, B-TID and Key lifetime are protected by MAC.

[0025] Optionally, the terminal and the first network element send and receive information through the second network element, where the information includes but is not limited to the above-mentioned B-TID and Key lifetime.

[0026] Optionally, the terminal identifier may be a permanent identifier or a temporary identifier, including any one of the following: SUPI, SUCI, IMSI, IMPI, TMPI, GUTI, TMSI, IMPU, App ID, network identifier, service identifier and NAI.

[0027] In a third aspect, the present application provides a key generation method, comprising: obtaining key parameters, the key parameters comprising: CK and at least one of IK, EMSK, and MSK; generating a key according to the key parameters.

[0028] Optionally, the key is generated according to the key parameters, including any of the following implementations:

[0029] Implementation method 1, key parameters include: CK and IK, calculation derivation formula 1: Ks = CK||IK, CK||IK represents the cascade of CK and IK;

[0030] Implementation method 2, key parameters include: EMSK, calculation derivation formula 2: Ks = EMSK;

[0031] Implementation method three, key parameters include: MSK, calculation derivation formula three: Ks = MSK;

[0032] In the above formula, Ks represents the generated key.

[0033] Optionally, generating a key according to key parameters includes: generating a key based on a basic key generated in an authentication process, wherein the basic key includes at least one of CK||IK, EMSK and MSK.

[0034] Optionally, generating a key based on a basic key generated during the authentication process may include: generating a key Ks in the following manner, and a specific derivation formula is as follows:

[0035] Formula 4: Ks = KDF (basic key), where KDF represents a key derivation function;

[0036] Formula 5, Ks = KDF (basic key, BSF ID);

[0037] Formula 6: Ks = KDF (basic key, SN ID), where SN ID represents the service network ID;

[0038] Formula 7, Ks = KDF (basic key, SN ID, BSF ID).

[0039] Optionally, any of the above derivation formulas may further include: an indication of a protocol type, the protocol type including at least one of the following: EAP, EAP AKA, EAP AKA', 5G, 5G AKA, GBA and 5G GBA, etc.

[0040] Optionally, any of the above derivation formulas further includes at least one of the following parameters: UE ID, session ID, EAPserver ID, Authenticator ID, uplink or downlink counter, sequence number and nonce.

[0041] In a fourth aspect, the present application provides an extended universal boot architecture authentication device, including: the device has the function of implementing the first network element behavior in the above-mentioned first aspect or the optional method of the first aspect. The function can be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-mentioned functions.

[0042] In a fifth aspect, the present application provides an extended universal boot architecture authentication device, including: the device has the function of implementing the terminal behavior in the above second aspect or the optional method of the second aspect. The function can be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0043] In a sixth aspect, the present application provides a key generation device, including: the device has the function of implementing the key generation behavior in the third aspect or the optional method of the third aspect. The function can be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0044] In a seventh aspect, the present application provides an extended universal boot architecture authentication device, the structure of which includes a processor and a transceiver, and the processor is configured to support the device to perform the corresponding functions in the above-mentioned first aspect or the optional method of the first aspect. The transceiver is used to support communication between the device and the terminal, and to send and receive information or instructions involved in the above-mentioned method. The device may also include a memory, which is used to couple with the processor and store program instructions and data necessary for the device.

[0045] In an eighth aspect, the present application provides an extended universal bootstrap architecture authentication device, the structure of which includes a processor and a transceiver, the processor being configured to support the device to perform the corresponding functions in the second aspect or the optional method of the second aspect. The transceiver is used to support communication between the device and the first network element, and to send and receive information or instructions involved in the above method. The device may also include a memory, which is coupled to the processor and stores program instructions and data necessary for the device.

[0046] In a ninth aspect, the present application provides a key generation device, the structure of which includes a processor and a memory, wherein the processor is configured to support the device to perform the corresponding functions in the third aspect or the optional method of the third aspect. The memory is used to couple with the processor and store the necessary program instructions and data for the device.

[0047] In a tenth aspect, the present application provides a computing storage medium comprising program instructions, wherein the program instructions are used to implement an extended universal boot architecture authentication method as in the first aspect or in an optional manner of the first aspect.

[0048] In an eleventh aspect, the present application provides a computing storage medium comprising program instructions, wherein the program instructions are used to implement an extended universal boot architecture authentication method as in the second aspect or in an optional manner of the second aspect.

[0049] In a twelfth aspect, the present application provides a computing storage medium, including program instructions, and the program instructions are used to implement a key generation method such as the third aspect or an optional method of the third aspect.

[0050] In a thirteenth aspect, the present application provides a computer program product, comprising program instructions, wherein the program instructions are used to implement an extended universal boot architecture authentication method as in the first aspect or in an optional manner of the first aspect.

[0051] In a fourteenth aspect, the present application provides a computer program product, comprising program instructions, wherein the program instructions are used to implement an extended universal boot architecture authentication method such as the second aspect or an optional manner of the second aspect.

[0052] In a fifteenth aspect, the present application provides a computer program product, comprising program instructions, wherein the program instructions are used to implement a key generation method such as the third aspect or an optional manner of the third aspect.

[0053] The present application provides an extended universal bootstrap architecture authentication method, device and storage medium. First, since the extended universal bootstrap architecture authentication method provided by the present application is based on EAP, the UE and BSF can complete GBAAKA authentication based on EAP. In addition, the present application also provides a key generation method, an extended key generation method. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 It is a schematic diagram of the existing GBA architecture;

[0055] Figure 2 A possible protocol stack format between UE and BSF is shown;

[0056] Figure 3 Another possible protocol stack format between UE and BSF is shown;

[0057] Figure 4 A flowchart of an extended universal boot architecture authentication method provided in an embodiment of the present application;

[0058] Figure 5A A message format is shown;

[0059] Figure 5B A message format provided for an embodiment of the present application;

[0060] Fig. 6A A message format including B-TID provided in an embodiment of the present application;

[0061] Figure 6B Another message format including B-TID provided in an embodiment of the present application;

[0062] Fig. 7A A message format including Key lifetime provided in an embodiment of the present application;

[0063] Figure 7B Another message format including Key lifetime provided in an embodiment of the present application;

[0064] Figure 8 A flowchart of an extended universal boot architecture authentication method provided by another embodiment of the present application;

[0065] Fig. 9 The message format of the existing EAP success message is shown;

[0066] Fig.10 A flowchart of an extended universal boot architecture authentication method provided in yet another embodiment of the present application;

[0067] Fig.11 A flowchart of an extended universal boot architecture authentication method provided in yet another embodiment of the present application;

[0068] Fig.12 A flowchart of an extended universal boot architecture authentication method provided in yet another embodiment of the present application;

[0069] Fig.13 A flowchart of an extended universal boot architecture authentication method provided in yet another embodiment of the present application;

[0070] Fig.14 A schematic block diagram of an extended universal bootstrap architecture authentication device provided in an embodiment of the present application;

[0071] Fig.15 A schematic block diagram of an extended universal bootstrap architecture authentication device provided by another embodiment of the present application;

[0072] Fig.16A schematic block diagram of an extended universal bootstrap architecture authentication device provided in yet another embodiment of the present application;

[0073] Fig.17 A schematic block diagram of an extended universal bootstrapping architecture authentication device provided in yet another embodiment of the present application. DETAILED DESCRIPTION

[0074] Figure 1 Schematic diagram of the existing GBA architecture. Figure 1 As shown in the figure, the GBA architecture includes: BSF, UE, NAF and Subscriber Locator Function (SLF). Among them, BSF, as an intermediate hub, interacts with UE through the Ub interface to perform authentication between UE and BSF; obtains UE authentication-related parameters from HSS through the Zh interface, and HSS stores UE authentication-related parameters; interacts with NAF through the Zn interface; interacts with SLF through the Dz interface. In multiple HSS scenarios, BSF can obtain the HSS name corresponding to the UE from SLF. In addition, UE interacts with NAF through the Ua interface. Since each application corresponds to a NAF, BSF and UE may interact with multiple NAFs.

[0075] As mentioned above, in the defined GBAAKA authentication standard, the participants include UE, BSF and HSS. Based on the root key shared between UE and HSS, the key negotiation of Ks between UE and BSF is realized; by executing the bootstrapping process, a shared key is established between BSF and UE. Specifically, UE and BSF complete GBA AKA authentication based on HTTP, and the specific steps are as follows: UE sends UE ID to BSF; BSF sends UE ID to Home Subscriber Server (HSS); HSS determines the root key corresponding to UE ID based on UE ID, and calculates the authentication vector (AV), AV = (RAND, AUTN, CK, IK, XRES), and sends AV to BSF, where RAND is a random number, AUTN is an authentication token, CK is a cipher key, IK is an integrity protection key, and XRES is an expected user response; BSF sends RAND and AUTN in AV to UE; UE verifies AUTN, and calculates CK, IK and RES, RES is a user response; UE sends RES to BSF; BSF compares XRES and RES to verify whether RES is correct; if the verification is successful, BSF calculates Ks = CK||IK; BSF sends B-TID and Key lifetime to UE, where BSF generates B-TID based on RAND and BSF server name, i.e. base64encode(RAND)@BSF_servers_domain_name, where base64encode(RAND) represents Base64 encoding conversion of RAND; UE calculates Ks=CK||IK. In addition, Figure 2 A possible protocol stack format between UE and BSF is shown. It can also be seen from the protocol stack that the existing GBA AKA authentication is based on HTTP.

[0076] The existing EAP AKA authentication process can refer to RFC4187, which mainly includes three entities:

[0077] Peer: The entity participating in the authentication, which can be a terminal device such as UE or Internet of things (IoT);

[0078] Authenticator: Authenticator, 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;

[0079] EAP server: Authentication server, performs authentication for peers.

[0080] The EAP AKA authentication process is described as follows:

[0081] 1. Authenticator sends an EAP request message to Peer, which is used to request the Peer's identity;

[0082] 2. Peer sends UE ID (e.g., Network Access Identifier (NAI)) to Authenticator;

[0083] 3. The Authenticator sends the UE ID to the EAP server. Here, the EAP server executes the AKA algorithm, generates RAND, AUTN and a message authentication code (MAC), and sends the RAND, AUTN and MAC to the Authenticator.

[0084] 4. Authenticator sends RAND, AUTN and MAC to Peer;

[0085] 5. Peer executes the AKA algorithm to verify AUTN and MAC, and generates RES and session key;

[0086] 6. Peer sends RES and MAC to Authenticator;

[0087] 7. Authenticator sends RES and MAC to EAP server; EAP server performs verification of RES and MAC. If verification is successful, it sends an EAP-success message to Authenticator;

[0088] 8. Authenticator sends an EAP-success message to Peer.

[0089] Note: The MAC sent by the Authenticator to the Peer is different from the MAC sent by the Peer to the Authenticator.

[0090] According to the above description and Figure 3 It can be found that although EAP AKA authentication is based on EAP, Figure 3 Another possible protocol stack format between UE and BSF is shown. However, the authentication process only includes the transmission of RAND, AUTN and MAC. Since EAP is a widely used protocol, it also includes the EAP extension protocol (RFC5448), for example, EAP AKA' or other EAP authentications such as EAP-SIM, this application does not limit this; and the EAP extension protocol will also be applied in the future 5G. Therefore, if EAP is extended to support GBA AKA authentication, it is necessary to add a method for sending B-TID and Key lifetime in the existing EAP AKA authentication process. In addition, in order to support other authentication methods, such as 5G AKA, etc., the present invention will also improve the existing GBA authentication protocol.

[0091] Based on the above, the present 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. Among them, the EAP-based GBA AKA authentication scheme adds the transmission of B-TID and Key lifetime in the above-mentioned EAP AKA or EAP AKA' authentication, so that the UE and BSF complete the GBAAKA authentication based on EAP. In addition, the authentication methods supporting EAP include multiple ones, such as the evolution protocol of EAP AKA or EAP AKA', EAP-TLS, or EAP PSK, EAP IKEv2, etc. For the above-mentioned authentication methods or processes, the GBA authentication function can be realized by adding the process of B-TID and Keylifetime. In addition, the key shared by both parties after negotiation through the above-mentioned authentication method can be used as Ks, or Ks can be further derived. For the GBA extension of EAP, the following only takes the EAP AKA process as an example to explain.

[0092] In addition, since B-TID and Key lifetime are two parameters, the present invention supports three processing and distribution methods for B-TID, or Key lifetime, or B-TID and Key lifetime. The following will describe the process together with B-TID and Keylifetime. The process of other processing and distribution of B-TID is to remove the part involving Keylifetime in the following process, and no additional description is given here. The process of other processing and distribution of Key lifetime is to remove the part involving B-TID in the following process, and no additional description is given here.

[0093] Compatible with the existing EAP AKA authentication process, the EAP-based GBA AKA authentication solution provided by this application still mainly includes three entities: Peer, Authenticator and EAP server.

[0094] Figure 4 This is a flow chart of an extended universal boot architecture authentication method provided by an embodiment of the present application. Figure 4 As shown, the method comprises the following steps:

[0095] S401. Authenticator sends an EAP request message to Peer.

[0096] The EAP request message is used to request the identifier of the peer.

[0097] Correspondingly, the peer receives the EAP request message and responds thereto, and executes S402.

[0098] It should be noted that 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.

[0099] S402. Peer sends UE ID to Authenticator.

[0100] Optionally, the UE ID can be a permanent ID or a temporary ID, including but not limited to any of the following: Subscription Permanent Identifier (SUPI), Subscription Concealed Identifier (SUCI), International Mobile Subscriber Identity (IMSI), IP Multimedia Private Identity (IMPI), Temporary IP Multimedia Private Identity (TMPI), Globally Unique Temporary Identifier (GUTI), Temporary Mobile Station Identity (TMSI), IP Multimedia Public Identity (IMPU), Application ID (App ID), Network ID (Network ID), Service ID (service ID), NAI, etc., which can uniquely identify the UE's identity. For example, if the UE is a server network element, the UE ID may be a server ID; if the UE ID is an encrypted identifier, such as SUCI, the EAP server may subsequently decrypt the UE ID by itself to obtain the UE identifier before encryption, such as SUPI; or send the UE ID to other network elements and obtain the UE identifier before encryption, such as SUPI, from the other network elements.

[0101] Correspondingly, the Authenticator receives the UE ID and executes S403.

[0102] S403: Authenticator sends UE ID to EAP server.

[0103] Correspondingly, the EAP server receives the UE ID and executes S404.

[0104] S404. The EAP server executes the AKA algorithm to generate RAND, AUTN and MAC; and generates B-TID and Keylifetime.

[0105] Among them, Key lifetime represents the life cycle of the key Ks generated subsequently. B-TID is BootstrappingTransaction Identifier, i.e. boot transaction ID. Optionally, B-TID can also be called transaction ID, identification ID, first ID, GBA session ID and other names.

[0106] Optionally, the EAP server executes the AKA algorithm and obtains RAND, AUTN and MAC in any manner. For example, the EAP server can obtain relevant authentication vectors including RAND, AUTN and MAC from other network elements; or the EAP server can execute the AKA algorithm itself to generate RAND, AUTN and MAC.

[0107] Optionally, the function of the B-TID is to determine the BSF address and / or key Ks according to the B-TID.

[0108] Optionally, the content of MAC integrity protection includes B-TID and Key lifetime.

[0109] S405. The EAP server sends RAND, AUTN, MAC, B-TID and Key lifetime to the Authenticator.

[0110] Optionally, the EAP server carries RAND, AUTN, MAC, B-TID and Key lifetime in a message such as an AKA-Challenge message of the EAP request and sends it. This application does not limit the specific name of the message carrying RAND, AUTN, MAC, B-TID and Key lifetime.

[0111] Correspondingly, the Authenticator receives RAND, AUTN, MAC, B-TID and Key lifetime, and executes S406.

[0112] S406. Authenticator sends RAND, AUTN, MAC, B-TID and Key lifetime to Peer.

[0113] Correspondingly, the Peer receives RAND, AUTN, MAC, B-TID and Key lifetime, and executes S407.

[0114] S407. Peer executes the AKA algorithm to verify AUTN and MAC; and generates RES and key.

[0115] S408. Peer sends RES and MAC to Authenticator.

[0116] Optionally, the Peer carries RES and MAC in a message such as an AKA-Challenge message of an EAP-response and sends it to the Authenticator. This application does not limit the specific name of the message carrying RES and MAC.

[0117] Correspondingly, the Authenticator receives RES and MAC, and executes S409.

[0118] S409: Authenticator sends RES and MAC to EAP server.

[0119] Correspondingly, the EAP server receives RES and MAC, and executes S410.

[0120] S410. The EAP server performs verification of RES and MAC. If the verification is successful, the EAP server generates a key.

[0121] S411. The EAP server sends an EAP-success message to the Authenticator.

[0122] Correspondingly, the Authenticator receives the EAP-success message and executes S412.

[0123] S412: Authenticator sends an EAP-success message to Peer.

[0124] Correspondingly, the peer receives the EAP-success message and completes the GBA AKA authentication.

[0125] This embodiment, through S401 to S412, implements the distribution of B-TID and Key lifetime in the GBA AKA authentication process, thereby implementing the parameter transfer required for GBA AKA authentication in EAP AKA and implementing GBA authentication based on EAP; at the same time, the Peer shares a key with the EAP server.

[0126] Optionally, the MAC-related operations in the processes of all embodiments of the present invention are optional. In some implementations, the MAC may not be calculated, sent, or verified.

[0127] Optionally, in all the processes of the embodiments of the present invention, if the Authenticator only receives and sends messages, in some implementations, the Authenticator network element may not be deployed.

[0128] Optionally, applicable to any embodiment of the present application in which the EAP server generates a key, the EAP server may generate the key in the following manner, and the specific derivation formula is as follows:

[0129] Ks is the key generated by the EAP server during the authentication process, for example: Ks=CK||IK; or, Ks=EMSK, EMSK is the extended master session key (Extended Master Session Key); or, Ks=MSK, MSK is the master session key (Master Session Key).

[0130] Alternatively, the key Ks is generated based on the key generated during the authentication process, for example, at least one of CK||IK, EMSK and MSK. For example:

[0131] Ks = KDF (basic key), where KDF stands for key derivation function;

[0132] Or, Ks = KDF (base key, BSF ID);

[0133] Or, Ks=KDF (basic key, SN ID), SN ID represents the serving network ID;

[0134] Or, Ks = KDF (basic key, SN ID, BSF ID);

[0135] etc.

[0136] The basic key is a key obtained by the EAP server during the authentication process, for example, at least one of CK||IK, EMSK and MSK.

[0137] The above derivation formula may also include an indication of 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 and 5G GBA, etc.

[0138] 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 some of the above parameters are only parameters owned by the EAP server, they need to be sent to the Peer, such as session ID, EAP server ID, Authenticator ID, uplink or downlink counter, sequence number or nonce.

[0139] In the above derivation formula, CK||IK represents the cascade of CK and IK. The BSF ID can be generated by the EAP server itself or received from the peer.

[0140] Optionally, applicable to any embodiment of the present application in which a Peer generates a key, the Peer may generate a key in the following manner, and the specific derivation formula is as follows:

[0141] Ks is the key generated by the peer during the authentication process, for example: CK||IK; or, Ks=EMSK; or, Ks=MSK.

[0142] Alternatively, the key Ks is generated based on the key generated during the authentication process, for example, at least one of CK||IK, EMSK and MSK. For example:

[0143] Ks = KDF (base key);

[0144] Or, Ks = KDF (base key, BSF ID);

[0145] Or, Ks = KDF (base key, SN ID);

[0146] Or, Ks = KDF (basic key, SN ID, BSF ID);

[0147] etc.

[0148] The above basic key is a key obtained by the Peer during the authentication process, for example, at least one of CK||IK, EMSK and MSK.

[0149] The above derivation formula may further include an indication of 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 and 5G GBA, etc.;

[0150] The above derivation formula may also include at least one of the following parameters, such as UE ID, session ID, EAPserver ID, Authenticator ID, uplink or downlink counter, sequence number and nonce; if the above parameters are parameters only possessed by the Peer, they need to be sent to the EAP server, such as session ID, EAP server ID, AuthenticatorID, uplink or downlink counter, sequence number or nonce.

[0151] In the above derivation formula, CK||IK represents the concatenation of CK and IK. The BSF ID can be generated by the peer itself or received from the BSF.

[0152] Optionally, applicable to any embodiment of the present application in which the Authenticator generates a key, the EAP server does not generate a Ks key, and the Authenticator generates a Ks key in the following manner, and the specific derivation formula is as follows:

[0153] Ks is the key generated by the EAP server during the authentication process and sent to the Authenticator, for example: Ks=CK||IK; or, Ks=EMSK; or, Ks=MSK.

[0154] Alternatively, the Authenticator generates a key Ks based on a key received from the EAP server, such as at least one of CK||IK, EMSK, and MSK. For example:

[0155] Ks = KDF (base key);

[0156] Or, Ks = KDF (base key);

[0157] Or, Ks = KDF (base key);

[0158] Or, Ks = KDF (basic key, SN ID, BSF ID);

[0159] etc.

[0160] The above basic key is a key obtained by the Authenticator during the authentication process, for example, at least one of CK||IK, EMSK and MSK.

[0161] The above derivation formula may further include an indication of a protocol type, for example, indicating at least one of the following protocol indications, such as EAP, EAP AKA, EAP AKA', 5G, GBA and 5G GBA, etc.

[0162] The above derivation formula may also include at least one of the following parameters, such as UE ID, session ID, uplink or downlink counter, sequence number and nonce, etc. If nonce is a parameter selected by the Authenticator, it needs to be sent to the Peer.

[0163] 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 parameters only possessed by the Authenticator, they need to be sent to the peer, such as session ID, EAP server ID, Authenticator ID, uplink or downlink counter, sequence number or nonce.

[0164] In the above derivation formula, CK||IK represents the concatenation of CK and IK. The BSF ID can be generated by the BSF itself or received from the Peer.

[0165] Optionally, for all embodiments of the present invention, the location where the Peer derives Ks may be any step after receiving the Authenticator message. The location where the EAP server derives Ks may be any step after receiving the Authenticator message. The location where the Authenticator derives Ks may be any step after receiving the EAP server message. Therefore, the specific location of key derivation is not limited.

[0166] Applicable to any embodiment of the present application in which the EAP server generates the B-TID, the EAP server generating the B-TID may include: the EAP server generates the B-TID according to the RAND and the BSF server name, that is, base64encode(RAND)@BSF_servers_domain_name, wherein base64encode(RAND) represents Base64 encoding conversion of the RAND.

[0167] Alternatively, the EAP server generating the B-TID may include: the EAP server generates an identifier as the B-TID. The specific generation method of the identifier is not limited in this application, and may include but is not limited to random selection.

[0168] Since the transmission of B-TID and Key lifetime is added in the above embodiment, the format of the existing EAP message is modified. The following briefly introduces the existing EAP message format.

[0169] by Figure 5A Take the message (EAP-Request / AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC)) as an example for explanation:

[0170] The Code indicates whether it is an EAP-request message, an EAP-reponse message, an EAP success message, or an EAP failure message. Specifically:

[0171] Code=1(Request), Code=2(Response), Code=3(Success), Code=4(Failure).

[0172] In this example, Code is 1, which means EAP-request, and so on.

[0173] Identifier indicates the association between request and response messages.

[0174] Length indicates the length of the packet.

[0175] Type indicates the protocol type, such as EAP AKA authentication.

[0176] Subtype indicates the subtype, such as the AKA-challenge message type.

[0177] In addition, the attribute information of the message is also included. In this example, the attribute values ​​include: AT_RAND, AT_AUTN, AT_MAC.

[0178] The format of attribute information is as follows Figure 5B As shown:

[0179] Attribute type is the attribute type, for example, indicating the AT_RAND parameter type.

[0180] Length is the attribute length, including attribute type, length, and value.

[0181] Value is the attribute value, that is, the specific parameter. For AT_RAND, it refers to the specific RAND parameter value.

[0182] Based on the above, the message format of B-TID can be expressed as follows:

[0183] like Fig. 6A Format 1 shown;

[0184] Or, if Figure 6B Format two is shown.

[0185] Among them, 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.

[0186] Similar to the B-TID message format, the Key lifetime message format can be expressed as:

[0187] like Fig. 7A Format 1 shown;

[0188] Or, if Figure 7B Format two is shown.

[0189] Among them, length represents the length of the entire message, including (AT_Key lifetime, length, Keylifetime length, Key lifetime), and Key lifetime length is the length of the Key lifetime content.

[0190] Figure 8 This is a flow chart of an extended universal boot architecture authentication method provided by another embodiment of the present application. Figure 8 As shown, the method comprises the following steps:

[0191] S801. Authenticator sends an EAP request message to Peer.

[0192] S802. Peer sends UE ID to Authenticator.

[0193] S803: Authenticator sends UE ID to EAP server.

[0194] Among them, S801 to S803 are similar to S401 to S403 respectively, and will not be repeated here.

[0195] S804. The EAP server executes the AKA algorithm to generate RAND, AUTN and MAC.

[0196] S805. The EAP server sends RAND, AUTN and MAC to the Authenticator.

[0197] Optionally, the EAP server carries RAND, AUTN and MAC in a message such as an AKA challenge message of the EAP request and sends it. The present application does not limit the specific name of the message carrying RAND, AUTN and MAC.

[0198] Correspondingly, the Authenticator receives RAND, AUTN and MAC, and executes S806.

[0199] S806. Authenticator sends RAND, AUTN and MAC to Peer.

[0200] Correspondingly, the Peer receives RAND, AUTN and MAC, and executes S807.

[0201] S807. Peer executes the AKA algorithm to verify AUTN and MAC, and generates RES and key.

[0202] S808. Peer sends RES and MAC to Authenticator.

[0203] Optionally, the Peer carries RES and MAC in a message such as an AKA-Challenge message of an EAP-response and sends it to the Authenticator. This application does not limit the specific name of the message carrying RES and MAC.

[0204] Correspondingly, the Authenticator receives RES and MAC and executes S809.

[0205] S809: Authenticator sends RES and MAC to EAP server.

[0206] Correspondingly, the EAP server receives RES and MAC, and executes S810.

[0207] S810. The EAP server performs verification of RES and MAC. If the verification succeeds, the EAP server generates a key, B-TID, and Key lifetime.

[0208] For the description of Key lifetime and B-TID, please refer to Figure 4 Corresponding embodiment.

[0209] S811. The EAP server sends an EAP-success message to the Authenticator.

[0210] The EAP-success message carries the B-TID and Key lifetime.

[0211] Correspondingly, the Authenticator receives the EAP-success message and executes S812.

[0212] S812. Authenticator sends an EAP-success message to Peer.

[0213] Correspondingly, the peer receives the EAP-success message and completes the GBAAKA authentication.

[0214] Figure 8 The process shown is similar to Figure 4 The difference between the processes shown is that: Figure 4 In the process shown in the figure, the AKA challenge message requested by EAP carries B-TID and Key lifetime; Figure 8 In the process shown in the figure, the B-TID and Key lifetime are carried in the EAP-success message.

[0215] This embodiment, through S801 to S812, implements the distribution of B-TID and Key lifetime in the GBA AKA authentication process, thereby implementing the parameter transfer required for GBA AKA authentication in EAP AKA and implementing GBA authentication based on EAP; at the same time, the Peer shares a key with the EAP server.

[0216] Optionally, similar to the above embodiment, this embodiment extends the content of the existing EAP-success message and adds fields of B-TID and Key lifetime.

[0217] In the prior art, the EAP success message field format is as follows: Fig. 9 Reference Fig. 9The existing EAP success message includes three fields: Code, Identifier and Length. The Code indicates whether it is successful, specifically: Code = 3 (Success), Code = 4 (Failure). The existing EAP success message does not support the transmission of other fields or messages. The embodiment of the present application modifies the existing EAP success message, for example, a new field is added to transmit B-TID and Key lifetime, and the new content is as follows: Fig. 6A , Figure 6B , 6A and Figure 6B shown.

[0218] The field format used to convey the B-TID can be expressed as follows:

[0219] like Fig. 7A Format 1 shown;

[0220] Or, if Figure 7B Format two is shown.

[0221] Among them, 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.

[0222] Similar to the field format used to pass B-TID, the field format used to pass Key lifetime can be expressed as:

[0223] like Fig. 7A Format 1 shown;

[0224] Or, if Figure 7B Format two is shown.

[0225] Among them, length represents the length of the entire message, including (AT_Key lifetime, length, Keylifetime length, Key lifetime), and Key lifetime length is the length of the Key lifetime content.

[0226] Fig.10 The flowchart of the extended universal boot architecture authentication method provided by another embodiment of the present application is as follows. Fig.10 As shown, the method comprises the following steps:

[0227] S101. Authenticator sends an EAP request message to Peer.

[0228] S102. Peer sends UE ID to Authenticator.

[0229] S103. The Authenticator sends the UE ID to the EAP server.

[0230] Among them, S101 to S103 are similar to S401 to S403 respectively, and will not be repeated here.

[0231] S104. The EAP server executes the AKA algorithm to generate RAND, AUTN and MAC.

[0232] S105. The EAP server sends RAND, AUTN and MAC to the Authenticator.

[0233] Optionally, the EAP server carries RAND, AUTN and MAC in a message such as an AKA challenge message of the EAP request and sends it. The present application does not limit the specific name of the message carrying RAND, AUTN and MAC.

[0234] Correspondingly, the Authenticator receives RAND, AUTN, and MAC, and executes S106.

[0235] S106. Authenticator sends RAND, AUTN and MAC to Peer.

[0236] Correspondingly, the Peer receives RAND, AUTN and MAC, and executes S107.

[0237] S107. Peer executes the AKA algorithm to verify AUTN and MAC; and generates RES and key.

[0238] S108. Peer sends RES and MAC to Authenticator.

[0239] Optionally, the Peer carries RES and MAC in a message such as an AKA-Challenge message of an EAP-response and sends it to the Authenticator. This application does not limit the specific name of the message carrying RES and MAC.

[0240] Correspondingly, the Authenticator receives RES and MAC, and executes S109.

[0241] S109. Authenticator sends RES and MAC to EAP server.

[0242] Correspondingly, the EAP server receives RES and MAC, and executes S110.

[0243] S110. The EAP server performs verification of RES and MAC. If the verification is successful, the EAP server generates a key, B-TID, and Key lifetime.

[0244] For the description of Key lifetime and B-TID, please refer to Figure 4 Corresponding embodiment.

[0245] S111. The EAP server sends a first message to the Authenticator.

[0246] The first message carries the B-TID and the Key lifetime. Optionally, the first message may be specifically an AKA-Notification message of the EAP-Request, etc. The present application does not limit the specific name of the first message.

[0247] Correspondingly, the Authenticator receives the first message and executes S112.

[0248] S112. Authenticator sends a first message to Peer.

[0249] Correspondingly, the Peer receives the first message and executes S113.

[0250] S113. Peer sends a second message to Authenticator.

[0251] The second message may be empty, that is, it does not carry any information. Optionally, the second message may be specifically an AKA-Notification message of an EAP-Response, etc. The present application does not limit the specific name of the second message.

[0252] Correspondingly, the Authenticator receives the second message and executes S114.

[0253] S114. The Authenticator sends a second message to the EAP server.

[0254] Correspondingly, the EAP server receives the second message, and executes S115.

[0255] S115. The EAP server sends an EAP-success message to the Authenticator.

[0256] Correspondingly, the Authenticator receives the EAP-success message and executes S116.

[0257] S116. Authenticator sends an EAP-success message to Peer.

[0258] Correspondingly, the peer receives the EAP-success message and completes the GBA AKA authentication.

[0259] Fig.10 The process shown is similar to Figure 4 The difference between the processes shown is that: Figure 4 In the process shown in the figure, the AKA challenge message requested by EAP carries B-TID and Key lifetime; Fig.10 In the process shown, the B-TID and Key lifetime are carried by the first message.

[0260] This embodiment, through S101 to S116, implements the distribution of B-TID and Key lifetime in the GBAAKA authentication process, thereby implementing the parameter transmission required for GBAAKA authentication in EAP AKA and implementing EAP-based GBA authentication; at the same time, the Peer shares a key with the EAP server.

[0261] Optionally, similar to the above embodiment, this embodiment extends the content of the existing EAP-Response message or AKA-Notification message, and adds the fields of B-TID and Key lifetime. The embodiment of the present application modifies the existing EAP-Response message or AKA-Notification message, for example, by adding a new field to transmit B-TID and Key lifetime, and the newly added content is as follows: Fig. 6A , Figure 6B , 6A and Figure 6B As shown, the specific explanation can refer to the above embodiment, which will not be repeated here.

[0262] In some embodiments, a new EAP message may be defined to transfer B-TID and Key lifetime. The new EAP message may be a GBA-AKA notification message of an EAP-Request.

[0263] In summary, in the above embodiments, the B-TID and Key lifetime are generated by the EAP server. As an optional solution, the B-TID and Key lifetime can also be generated by the Peer, and the specific implementation method is explained through the following embodiments.

[0264] Fig.11 This is a flow chart of an extended universal boot architecture authentication method provided by another embodiment of the present application. Fig.11 As shown, the method comprises the following steps:

[0265] S1101. Authenticator sends an EAP request message to Peer.

[0266] S1102. Peer sends UE ID to Authenticator.

[0267] S1103. The Authenticator sends the UE ID to the EAP server.

[0268] Among them, S1101 to S1103 are similar to S401 to S403 respectively, and will not be repeated here.

[0269] S1104. The EAP server executes the AKA algorithm to generate RAND, AUTN and MAC.

[0270] S1105. The EAP server sends RAND, AUTN, and MAC to the Authenticator.

[0271] Optionally, the EAP server carries RAND, AUTN and MAC in a message such as an AKA challenge message of the EAP request and sends it. The present application does not limit the specific name of the message carrying RAND, AUTN and MAC.

[0272] Correspondingly, the Authenticator receives RAND, AUTN, and MAC, and executes S1106.

[0273] S1106. Authenticator sends RAND, AUTN and MAC to Peer.

[0274] Correspondingly, the Peer receives RAND, AUTN and MAC, and executes S1107.

[0275] S1107. Peer executes the AKA algorithm to verify AUTN and MAC; and generates RES, key, B-TID and Keylifetime.

[0276] For the description of Key lifetime and B-TID, please refer to Figure 4 Corresponding embodiment.

[0277] S1108. Peer sends RES and MAC to Authenticator.

[0278] Optionally, the Peer carries RES and MAC in a message such as an AKA-Challenge message of an EAP-response and sends it to the Authenticator. This application does not limit the specific name of the message carrying RES and MAC.

[0279] Correspondingly, the Authenticator receives RES and MAC, and executes S1109.

[0280] S1109. Authenticator sends RES and MAC to EAP server.

[0281] Correspondingly, the EAP server receives RES and MAC, and executes S1110.

[0282] S1110. The EAP server performs verification of RES and MAC. If the verification succeeds, the EAP server generates a key, B-TID, and Key lifetime.

[0283] S1111. The EAP server sends an EAP-success message to the Authenticator.

[0284] Correspondingly, the Authenticator receives the EAP-success message and executes S1112.

[0285] S1112. Authenticator sends an EAP-success message to Peer.

[0286] Correspondingly, the peer receives the EAP-success message and completes the GBA AKA authentication.

[0287] Fig.11 The process shown is similar to Figure 4 The difference between the processes shown is that: Figure 4 In the process shown, B-TID and Key lifetime are generated by the EAP server and sent to the UE; Fig.11 In the process shown in the figure, B-TID and Keylifetime are generated by Peer and EAP server respectively.

[0288] Optionally, in all the processes of the embodiments of the present invention, there is no restriction on the location where the EAP server generates the B-TID and Key lifetime, and there is no restriction on the location where the peer generates the B-TID and Key lifetime.

[0289] This embodiment, through S1101 to S1112, realizes the acquisition of B-TID and Key lifetime in the GBA AKA authentication process, thereby realizing the acquisition of parameters required for GBA AKA authentication in EAP AKA, and realizing GBA authentication based on EAP; at the same time, the Peer shares a key with the EAP server.

[0290] In some embodiments, the peer generates a B-TID, which may include: generating the B-TID according to the RAND and the BSF server name. Specifically, through S1106, the peer receives the RAND, that is, the peer obtains the RAND during authentication; for the BSF server name, there are the following possibilities:

[0291] Possibility 1: During the authentication process, the EAP server or Authenticator sends the BSF server name to the Peer. For example, the BSF server name is carried in the EAP-request / identity message, or the EAP request / AKA-challenge message, and is sent by the EAP server or Authenticator to the Peer.

[0292] Correspondingly, the Peer receives the BSF server name sent by the EAP server or Authenticator.

[0293] Optionally, the BSF server ID may also be sent here. Through the BSF server ID, the peer can obtain the BSF server name.

[0294] Possibility 2: Through the operator ID, the peer can obtain the BSF server name using certain rules, such as BSF.operator.com or BSF server.operater.com, where operator can be the operator ID.

[0295] Possibility 3: The peer generates the BSF server name based on the peer's identity in different scenarios. For example, the peer generates the BSF server name based on the IMSI in the Universal Subscriber Identity Module (USIM) scenario; or the peer generates the BSF server name based on the IMPI in the IP Multimedia Service Identity Module (ISIM) scenario.

[0296] In some embodiments, the peer generates a Key lifetime with the following possibilities:

[0297] Possibility 1: During the authentication process, the EAP server or Authenticator sends the Key lifetime to the Peer. For example, the Key lifetime is carried in the EAP-requrest / identity message, or the EAP request / AKA-challenge message, and is sent by the EAP server or Authenticator to the Peer.

[0298] Accordingly, the Peer receives the Key lifetime sent by the EAP server or Authenticator.

[0299] Possibility 2: The peer has preset the Key lifetime, or the peer has obtained the Key lifetime before authentication.

[0300] Peer generates B-TID according to RAND and BSF server name. Optionally, based on the above embodiment, the location of any one or more of the three items of B-TID, Key lifetime and key Ks is specifically generated, and this application does not limit it.

[0301] It should also be noted that since B-TID and Key lifetime can be generated by either the peer or the EAP server, therefore:

[0302] As a possible implementation, the EAP server may generate the B-TID, and the Peer may generate the Keylifetime. Accordingly, only the B-TID is transmitted in subsequent steps.

[0303] As another possible implementation, the EAP server may generate the Key lifetime, and the Peer may generate the B-TID. Accordingly, only the Key lifetime is transmitted in subsequent steps.

[0304] As a possible implementation method, the peer may generate a B-TID and a Key lifetime, and send the B-TID and the Key lifetime to the EAP server.

[0305] In addition, considering that the existing EAP AKA certifications include:

[0306] If the peer does not need the success notification message to be protected, the EAP success message is directly used to send a success indication to the peer; or, if the peer needs the success notification message to be protected, the BSF uses the AKA-Notification message to send a success indication to the peer.

[0307] Therefore, corresponding to the distribution method of B-TID and Key lifetime in this application:

[0308] If the peer does not need the success notification message to be protected, the BSF can send the B-TID and Key lifetime through the EAP-success message; or, if the peer needs the success notification message to be protected, the BSF can send the B-TID and Key lifetime through the first message. Here, the BSF can be an EAP server or an Authenticator.

[0309] In the above embodiment, B-TID is generated based on RAND and BSF server name. For the generation of B-TID, there is another possibility, that is, the first half of B-TID is an identifier randomly selected by BSF, and BSF sends B-TID and Key lifetime to Peer. The specific method of distributing B-TID and Key lifetime can refer to the above embodiment. Among them, B-TID includes two parts: one part is the RAND random number, and the other part is the BSF server domain name, that is, B-TID:base64encode(RAND)@BSF_servers_domain_name. Therefore, the random selection here means that the RAND parameter in the authentication process is not used, but a random number is randomly selected by BSF as the first half of B-TID.

[0310] Subsequently, the peer can send the B-TID to the NAF to request authentication between the peer and the NAF. After the NAF sends the B-TID to the BSF, the BSF determines the corresponding key based on the saved B-TID and executes the subsequent NAF key generation process.

[0311] In the prior art, the GBA technology also includes the key negotiation of K_NAF between the UE and the NAF, and the participants include the UE, the NAF and the BSF. The basic process of the key negotiation of K_NAF between the UE and the NAF is as follows:

[0312] 1. The UE stores the B-TID and the key Ks. The UE first generates Ks_NAF, then initiates an application request to NAF, where the application request carries the B-TID and other msg messages.

[0313] 2. NAF sends B-TID and NAF-ID to BSF;

[0314] 3. BSF determines the key Ks according to B-TID and generates Ks_NAF; sends Ks_NAF, Key lifetime, etc. to NAF;

[0315] 4. NAF sends the application response to the UE.

[0316] The above mainly completes how the UE uses the B-TID obtained after the above authentication to complete the key sharing between the UE and the NAF. Subsequently, a secure channel can be established between the UE and the NAF using a secure method such as TLS.

[0317] With reference to the above prior art, the embodiment of the present application provides an EAP-based authentication method between the UE and the NAF. For example, it can be assumed that B-TID is the user name and Ks_ANF is the password; thus, authentication methods such as EAP-POTP, EAP-PSK, and EAP-PWD are supported.

[0318] The following is an explanation using the EAP-PSK process as an example. The specific implementation method is that the UE executes the EAP-PSK process:

[0319] 1. The UE replaces the username in the authentication message with B-TID and the password with Ks_NAF, and sends the modified authentication message to NAF.

[0320] 2. After receiving the authentication message sent by the UE, the NAF verifies whether the username and password stored in it are consistent with the username and password sent by the UE. If they are consistent, the verification is successful, otherwise the verification fails.

[0321] The current 5G architecture includes the following security network elements: Authentication Server Function (AUSF), Authentication credential Repository and Processing Function (ARPF), Security Anchor Function (SEAF). The above network elements 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 above embodiment mainly lies in: the specific implementation method of generating keys is different. The generation of specific B-TID and Key lifetime is not limited here. It is compatible with the method in which BSF generates B-TID and Key lifetime and distributes them to UE in the above embodiment, as well as the method in which UE generates B-TID and Key lifetime.

[0322] In one implementation, ARPF generates Ks based on EMSK, MSK or CK||IK and sends it to BSF. The specific derivation formula can be found in Figure 4 The method for generating Ks in the corresponding embodiment. The specific operation of the UE includes generating Ks according to the key in the authentication process.

[0323] Fig.12 This is a flow chart of an extended universal boot architecture authentication method provided by another embodiment of the present application. Fig.12 As shown, the method may include the following steps:

[0324] S1201. UE sends a first request to BSF.

[0325] The first request includes a UE ID.

[0326] Correspondingly, the BSF receives the first request, adds the BSF ID to the first request to form a second request, that is, the second request includes the UE ID and the BSF ID, and executes S1202.

[0327] S1202. BSF sends a second request to ARPF.

[0328] Correspondingly, the ARPF receives the second request and executes S1203.

[0329] S1203. ARPF calculates an authentication vector.

[0330] Among them, the authentication vector includes Ks, XRES, RAND and AUTN.

[0331] S1204. ARPF sends the authentication vector to BSF.

[0332] Correspondingly, the BSF receives the authentication vector and executes S1205.

[0333] S1205. BSF sends RAND and AUTN in the authentication vector to UE.

[0334] Correspondingly, the UE receives RAND and AUTN, and executes S1206.

[0335] S1206. The UE verifies AUTN successfully and generates Ks and RES.

[0336] S1207. UE sends RES to BSF.

[0337] Correspondingly, the BSF receives RES and executes S1208.

[0338] S1208. BSF verifies whether XRES is the same as RES.

[0339] If they are the same, it means that the UE verification is successful; if they are different, it means that the UE verification is unsuccessful.

[0340] Optionally, if ARPF does not need the BSF ID when generating Ks, the BSF does not need to send the BSF ID to ARPF, that is, the BSF forwards the first request to ARPF; or, if ARPF can obtain the BSF ID through other means, then similarly, the BSF does not need to send the BSF ID to ARPF, and only forwards the first request to ARPF.

[0341] This application does not limit the method by which ARPF obtains the BSF ID. For example, the method by which ARPF obtains the BSF ID can be implemented in any of the following ways:

[0342] Implementation method 1: Preset.

[0343] Implementation method 2: Determine the BSF ID based on the source of the message.

[0344] Implementation method three: ARPF requests BSF or other network elements to obtain BSF ID and receives a response, which includes BSF ID.

[0345] In the above implementation, the BSF ID can be replaced by the BSF server name.

[0346] In another implementation, ARPF sends the first key to BSF, so that BSF derives Ks based on the first key. Here, the first key can be EMSK, MSK, or CK||IK; or, the first key generated based on EMSK, MSK or CK||IK. The specific formula and parameters for deriving the first key can be referred to Figure 4 The method for generating Ks in the corresponding embodiment.

[0347] Exemplarily, the formula for BSF to derive Ks from the first key may be as follows:

[0348] Ks = KDF (first key);

[0349] Or, Ks=KDF(first key, BSF ID);

[0350] Or, Ks=KDF(first key, SN ID);

[0351] Or, Ks=KDF(first key, SN ID, BSF ID);

[0352] etc.

[0353] In some embodiments, the above-mentioned derivation formula may further include an indication of a protocol type, such as indicating at least one of the following protocol indications: EAP, EAP AKA, EAP AKA', 5G, GBA and 5G GBA, etc.

[0354] In some embodiments, the above derivation formula may further include at least one of the following parameters: UE ID, session ID, uplink or downlink counter, sequence number and nonce, etc. If nonce is a parameter selected by the Authenticator, the Authenticator needs to send nonce to the UE.

[0355] In some embodiments, 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 and nonce, etc. If the above parameters are the only parameters owned by ARPF, ARPF needs to send the parameters to UE, such as session ID, EAP server ID, Authenticator ID, uplink or downlink counter, sequence number or nonce.

[0356] The specific operation of the UE includes: generating a first key according to the key in the authentication process, and then generating Ks according to the first key.

[0357] Fig.13 The flowchart of the extended universal boot architecture authentication method provided by another embodiment of the present application is as follows. Fig.13 As shown, the method may include the following steps:

[0358] S1301. UE sends a first request to BSF.

[0359] The first request includes a UE ID.

[0360] Correspondingly, the BSF receives the first request, adds the BSF ID to the first request to form a second request, that is, the second request includes the UE ID and the BSF ID, and executes S1302.

[0361] S1302. BSF sends a second request to AUSF.

[0362] Correspondingly, AUSF receives the second request and executes S1303.

[0363] S1303. AUSF sends a second request to ARPF.

[0364] Correspondingly, the ARPF receives the second request and executes S1304.

[0365] S1304. ARPF calculates an authentication vector.

[0366] The authentication vector includes XRES, RAND, AUTN, and Kausf. Here, Kasuf represents the key sent by ARPF to AUSF. It is also possible that the authentication vector is XRES, RAND, AUTN, (at least one of EMSK, MSK, and CK||IK).

[0367] S1305. ARPF sends the authentication vector to AUSF.

[0368] Correspondingly, the AUSF receives the authentication vector and executes S1306.

[0369] S1306. AUSF generates Ks based on the authentication vector.

[0370] Optionally, AUSF generating Ks based on the authentication vector may include: AUSF generating Ks based on CK||IK; or, AUSF generating Ks based on EMSK or MSK; AUSF generating Ks based on Kausf, and so on.

[0371] S1307. AUSF sends XRES, RAND, AUTN and Ks to BSF.

[0372] Correspondingly, BSF receives XRES, RAND, AUTN and Ks, and executes S1308.

[0373] S1308. BSF sends RAND and AUTN to UE.

[0374] Correspondingly, the UE receives RAND and AUTN, and executes S1309.

[0375] S1309. The UE verifies AUTN successfully and generates Ks and RES.

[0376] S1310. UE sends RES to BSF.

[0377] Correspondingly, BSF receives RES and executes S1311.

[0378] S1311. BSF verifies whether XRES is the same as RES.

[0379] If they are the same, it means that the UE verification is successful; if they are different, it means that the UE verification is unsuccessful.

[0380] The difference between this embodiment and the previous embodiment is that: BSF has an interface with AUSF, through which AUSF receives CK, IK, EMSK, MSK or Kausf from ARPF. AUSF derives Ks based on the above keys. The specific formula and parameters for deriving Ks can be found in Figure 4 The method for generating Ks in the corresponding embodiment is different in that in addition to CK||IK, MSK, EMSK, there is also the possibility of adding Kausf generation.

[0381] Optionally, if AUSF does not need BSF ID when generating Ks, BSF does not need to send BSF ID to AUSF, that is, BSF forwards the first request to AUSF; or, if AUSF can obtain BSF ID by other means, then similarly, BSF does not need to send BSF ID to AUSF, and only forwards the first request to AUSF. Here, this application does not limit the way AUSF obtains BSF ID. Exemplarily, the way AUSF obtains BSF ID can be implemented in any of the following ways:

[0382] Implementation method 1: Preset.

[0383] Implementation method 2: Determine the BSF ID based on the source of the message.

[0384] Implementation method three: AUSF requests BSF or other network elements to obtain BSF ID and receives a response, which includes BSF ID.

[0385] In the above implementation, the BSF ID can be replaced by the BSF server name.

[0386] In another implementation, AUSF sends the second key to BSF, so that BSF derives Ks based on the second key. Here, the second key can be EMSK, MSK, Kausf, or CK||IK; or, the second key generated based on EMSK, MSK, Kausf, or CK||IK. The specific formula and parameters for deriving the second key can be referred to Figure 4 The method for generating Ks in the corresponding embodiment.

[0387] Exemplarily, a possible formula for BSF to derive Ks from the second key is as follows:

[0388] Ks=KDF (second key);

[0389] Or, Ks=KDF(second key, BSF ID);

[0390] Or, Ks=KDF(second key, SN ID);

[0391] Or, Ks=KDF(second key, SN ID, BSF ID);

[0392] etc.

[0393] In some embodiments, the above-mentioned derivation formula may further include an indication of a protocol type, such as indicating at least one of the following protocol indications: EAP, EAP AKA, EAP AKA', 5G, GBA and 5G GBA, etc.

[0394] In some embodiments, 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 and nonce, etc. If nonce is a parameter selected by the Authenticator, the Authenticator needs to send nonce to the UE.

[0395] In some embodiments, 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 and nonce, etc. If the above parameters are the only parameters owned by AUSF, AUSF 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.

[0396] The specific operation of the UE includes: generating a second key according to the key in the authentication process, and then generating Ks according to the second key.

[0397] The above BSF ID can be replaced with BSF server name.

[0398] In addition, there is another possibility: 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 based on the third key. In addition, if SEAF does not need BSFID to generate Ks, then BSF does not need to send BSF ID to SEAF; or, if SEAF can obtain BSF ID through other means, then the same BSF does not need to send BSF ID to SEAF. Here, the way SEAF obtains BSF ID can be preset, or the BSF ID can be determined according to the source of the message, or SEAF requests BSF or other network elements to obtain BSF ID and obtains a response, which includes BSF ID, etc., and there is no restriction here.

[0399] This possible embodiment is different from the above embodiment in that the key generation method uses a third key generated based on EMSK, MSK, Kseaf, or CK||IK.

[0400] For the above embodiment, there are also the following possibilities:

[0401] Possibility 1 (applicable to all embodiments): The Authenticator generates and sends the B-TID and Key lifetime to the Peer.

[0402] Possibility 2 (applicable to all embodiments): Peer may generate Ks in any step after receiving the EAP-response / AKA-request message sent by Authenticator, which is not limited in this application. For example, after receiving the EAP-success message, Peer generates Ks.

[0403] Possibility 3 (applicable to all embodiments): The EAP server may generate Ks in any step after receiving a message sent by the Authenticator, and this application does not limit this. For example, after receiving an EAP-response / AKA-challenge message, the EAP server generates Ks.

[0404] Possibility 4 (applicable to all embodiments): The specific method for generating Ks by the peer and the EAP server can refer to the following: Figure 4 Description of the illustrated embodiment.

[0405] Possibility 5 (applicable to all embodiments): Authenticator generates Ks. The specific generation method can refer to Figure 4 Description of the illustrated embodiment.

[0406] Possibility 6 (applicable to all embodiments): For the correspondence between the network element in EAP and the network element in GBA, there are the following possibilities:

[0407] The peer executes the corresponding action of the UE, and the EAP server executes the corresponding action of the BSF. The actions here include, for example, authentication, and at least one of the three actions of generating Ks, generating B-TID and key lifetime;

[0408] Alternatively, the Peer performs actions corresponding to the UE, and the Authenticator performs actions corresponding to the BSF. The actions here include, for example, authentication, and at least one of the three actions of generating Ks, generating B-TID and key lifetime.

[0409] Or BSF is deployed independently and has an interface with Authenticator or EAP server. If BSF is deployed independently, UE will first access BSF, then BSF will access authenticator, and then authenticator will access EAP server. It is also possible that UE will first access authenticator, then authenticator will access BSF, and then BSF will access EAP server.

[0410] Possibility 7 (applicable to all embodiments): the CK and IK mentioned above represent the encryption key and the integrity protection key, and the symbols are not limited, and can also be CK' and IK', etc., which are not limited here.

[0411] 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:

[0412] ARPF executes the corresponding actions of BSF. The actions here include, for example, authentication, and at least one of the three actions of generating Ks, generating B-TID and key lifetime;

[0413] Alternatively, the AUSF executes the corresponding action of the BSF. The action here includes, for example, authentication, and at least one of the three actions of generating Ks, generating B-TID and key lifetime;

[0414] Alternatively, SEAF executes the corresponding action of BSF, which includes, for example, authentication, and at least one of the three actions of generating Ks, generating B-TID and key lifetime.

[0415] Possibility 9 (applicable to all embodiments): UE or Peer may generate Ks in any step after receiving a message sent by BSF / ARPF / AUSF / SEAF, which is not limited in this application.

[0416] Possibility 10 (applicable to all embodiments): BSF / ARPF / AUSF / SEAF may generate Ks in any step after receiving a related message sent by UE or Peer, and this application does not limit this.

[0417] Possibility 11 (applicable to all embodiments): For the correspondence between ARPF / AUSF / SEAF network and GBA network element, there are the following possibilities:

[0418] BSF is deployed independently and has an interface with ARPF / AUSF / SEAF. If BSF is deployed independently, the UE will first access BSF, and then BSF will access ARPF / AUSF / SEAF. It is also possible that the UE will first access SEAF, then SEAF will access BSF, and then BSF will access AUSF. It is also possible that the UE will first access SEAF, then SEAF will access AUSF, then AUSF will access BSF, and then BSF will access ARPF. There is no restriction on the above combinations.

[0419] In summary, the first network element involved in this application may be an EAP server or AUSF, etc., the terminal may be a Peer or UE, and the second network element may be an Authenticator, etc. This application does not limit this, and specific examples can refer to subsequent embodiments. Moreover, this application does not limit the execution subject of generating the key, which may be an EAP server, Peer, UE, AUSF, Authenticator or ARPF, etc.

[0420] The extended universal bootstrap architecture authentication method according to the embodiment of the present application is described in detail above. The extended universal bootstrap architecture authentication device according to the embodiment of the present application will be described below.

[0421] The embodiments of the present application describe in detail the schematic structure of an extended universal bootstrap architecture authentication device.

[0422] In one example, Fig.14A schematic block diagram of an extended universal boot architecture authentication device provided for an embodiment of the present application. The extended universal boot architecture authentication device 1400 of the embodiment of the present application may be the first network element in the above-mentioned method embodiment, or may be one or more chips within the first network element. The extended universal boot architecture authentication device 1400 may be used to perform part or all of the functions of the first network element in the above-mentioned method embodiment. The extended universal boot architecture authentication device 1400 may include a processing module 1410 and a transceiver module 1420. Optionally, the extended universal boot architecture authentication device 1400 may also include a storage module 1430.

[0423] For example, the processing module 1410 may be used to execute the steps of generating the B-TID and keylifetime in the aforementioned method embodiment.

[0424] The transceiver module 1420 may be used to execute the steps of sending the B-TID and key lifetime in the aforementioned method embodiment.

[0425] Alternatively, the extended universal boot architecture authentication device 1400 may also be configured as a general processing system, such as a chip, and the processing module 1410 may include: one or more processors that provide processing functions; the transceiver module 1420 may be, for example, an input / output interface, a pin or a circuit, etc. The input / output interface may be used to be responsible for the information interaction between the chip system and the outside world. For example, the input / output interface may output the B-TID and key lifetime generated by the processing module 1410 to other modules outside the chip for processing. The processing module 1410 may execute the computer-executable instructions stored in the storage module 1430 to implement the functions of the first network element in the above method embodiment. In an example, the storage module 1430 optionally included in the extended universal boot architecture authentication device 1400 may be a storage unit in the chip, such as a register, a cache, etc. The storage module 1430 may also be a storage unit located outside the chip in the first network element, such as a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM), etc.

[0426] In another example, Fig.15A schematic block diagram of an extended universal bootstrap architecture authentication device provided for another embodiment of the present application. The extended universal bootstrap architecture authentication device 1500 of the embodiment of the present application may be the first network element in the above method embodiment, and the extended universal bootstrap architecture authentication device 1500 may be used to perform part or all of the functions of the first network element in the above method embodiment. The extended universal bootstrap architecture authentication device 1500 may include: a processor 1510, a baseband circuit 1530, a radio frequency circuit 1540 and an antenna 1550. Optionally, the extended universal bootstrap architecture authentication device 1500 may also include a memory 1520. The various components of the extended universal bootstrap architecture authentication device 1500 are coupled together through a bus 1560, wherein 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 bus systems 1560 in the figure.

[0427] Processor 1510 can be used to implement control over the first network element, to execute the processing performed by the first network element in the above-mentioned embodiments, to execute the processing procedures involving the first network element in the above-mentioned method embodiments and / or other processes used for the technology described in this application, and to run an operating system, be responsible for managing the bus, and execute programs or instructions stored in the memory.

[0428] The baseband circuit 1530, the radio frequency circuit 1540 and the antenna 1550 may be used to support the sending and receiving of information between the first network element and the terminal involved in the above embodiments, so as to support wireless communication between the first network element and the terminal.

[0429] The memory 1520 can be used to store the program code and data of the sending end. The memory 1520 can be Fig.15 The storage module 1530 in the storage module 1530. 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. Fig.15 The memory 1520 is shown as being separated from the processor 1510, however, it is 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. For example, the memory 1520 may include a transmission line and / or a computer product separated from a wireless node, and these media may be accessed by the processor 1510 through the bus interface 1560. Alternatively, the memory 1520 or any portion thereof may be integrated into the processor 1510, for example, may be a cache and / or a general register.

[0430] Understandably, Fig.15Only a simplified design of the first network element is shown. For example, in practical applications, the first network element may include any number of transmitters, receivers, processors, memories, etc., and all first network elements that can implement the present invention are within the protection scope of the present invention.

[0431] In one possible implementation, 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 arrays (FPGA), programmable logic devices (PLD), controllers, state machines, gate logic, discrete hardware components, any other suitable circuits, or any combination of circuits capable of performing the various functions described throughout this application. In another example, an embodiment of the present application also provides a computer storage medium, which can store program instructions for indicating any of the above methods, so that the processor executes the program instructions to implement the methods and functions involving the first network element in the above method embodiments.

[0432] The present application embodiment describes in detail the schematic structure of the extended universal boot architecture authentication device. In one example, Fig.16 A schematic block diagram of an extended universal boot architecture authentication device provided for another embodiment of the present application. The extended universal boot architecture authentication device 1600 of the embodiment of the present application may be the terminal in the above 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 part or all of the functions of the terminal in the above method embodiment. The extended universal boot architecture authentication device 1600 may include a processing module 1610 and a transceiver module 1620. Optionally, the extended universal boot architecture authentication device 1600 may also include a storage module 1630. The transceiver module 1620 is used to receive a B-TID and a key lifetime.

[0433] Alternatively, the extended universal boot architecture authentication device 1600 may also be configured as a universal 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 be, for example, an input / output interface, a pin or a circuit, etc., and the input / output interface may be used to be responsible for the information interaction between this chip system and the outside world. The one or more processors may execute the computer-executable instructions stored in the storage module 1630 to implement the functions of the terminal in the above method embodiment. In an example, the storage module 1630 optionally included in the extended universal boot architecture authentication device 1600 may be a storage unit in the chip, such as a register, a cache, etc., and the storage module 1630 may also be a storage unit located outside the chip in the terminal, such as a ROM or other types of static storage devices that can store static information and instructions, RAM, etc.

[0434] In another example, Fig.17 A schematic block diagram of an extended universal bootstrap architecture authentication device provided for another embodiment of the present application. The extended universal bootstrap architecture authentication device 1700 of the embodiment of the present application may be a terminal in the above method embodiment, and the extended universal bootstrap architecture authentication device 1700 may be used to perform part or all of the functions of the terminal in the above method embodiment. The extended universal bootstrap architecture authentication device 1700 may include: a processor 1710, a baseband circuit 1730, a radio frequency circuit 1740 and an antenna 1750. Optionally, the extended universal bootstrap architecture authentication device 1700 may also include a memory 1720. The various components of the extended universal bootstrap architecture authentication device 1700 are coupled together through a bus 1760, wherein 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 bus systems 1760 in the figure.

[0435] Processor 1710 can be used to control the terminal, to execute the processing performed by the terminal in the above-mentioned embodiments, to execute the processing procedures involving the terminal in the above-mentioned method embodiments and / or other processes for the technology described in this application, and to run an operating system, be responsible for managing the bus, and execute programs or instructions stored in the memory.

[0436] The baseband circuit 1730, the radio frequency circuit 1740 and the antenna 1750 can be used to support the transmission and reception of information between the terminal and the first network element involved in the above embodiment, so as to support wireless communication between the first network element and the terminal. A memory 1720 can be used to store program codes and data of the transmitting end, and the memory 1720 can be Fig.17The storage module 1730 in the embodiment of the present invention. 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.

[0437] Understandably, Fig.17 Only a simplified design of the terminal is shown. For example, in practical applications, the terminal may include any number of transmitters, receivers, processors, memories, etc., and all terminals that can implement the present invention are within the protection scope of the present invention.

[0438] In one possible implementation, the extended universal boot architecture authentication device on the terminal side can also be implemented using the following: one or more field-programmable gate arrays (FPGA), programmable logic devices (PLD), controllers, state machines, gate logic, discrete hardware components, any other suitable circuits, or any combination of circuits capable of performing the various functions described throughout this application.

[0439] In another example, an embodiment of the present application further provides a computer storage medium, which can store program instructions for indicating any of the above methods, so that the processor executes the program instructions to implement the methods and functions involving the terminal in the above method embodiments.

[0440] The processor involved in the above-mentioned extended universal boot architecture authentication device 1500 and the extended universal boot architecture authentication device 1700 can be a general-purpose processor, such as a general-purpose central processing unit (CPU), a network processor (Network Processor, referred to as NP), a microprocessor, etc., or an application-specific integrated circuit (application-specific integrated circuit, referred to as ASIC), or one or more integrated circuits for controlling the execution of the program of the present application scheme. It can also be a digital signal processor (Digital Signal Processor, referred to as DSP), a field programmable gate array (Field-Programmable Gate Array, referred to as FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The controller / processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of DSP and microprocessors, and so on. The processor usually performs logical and arithmetic operations based on program instructions stored in the memory.

[0441] The memory involved in the above-mentioned extended universal boot architecture authentication device 1500 and the extended universal boot architecture authentication device 1700 may also store an operating system and other application programs. Specifically, the program may include a program code, and the program code includes computer operation instructions. More specifically, the above-mentioned memory may be a read-only memory (ROM), other types of static storage devices that can store static information and instructions, a random access memory (RAM), other types of dynamic storage devices that can store information and instructions, disk storage, etc. The memory may be a combination of the above-mentioned storage types. And the above-mentioned computer-readable storage medium / memory may be in the processor, or may be outside the processor, or distributed on multiple entities including a processor or a processing circuit. The above-mentioned computer-readable storage medium / memory may be specifically embodied in a computer program product. For example, a computer program product may include a computer-readable medium in a packaging material.

[0442] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0443] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0444] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0445] An embodiment of the present application provides a computing storage medium, including program instructions, wherein the program instructions are used to implement the method described in any of the above embodiments.

Claims

1. A method for key derivation, characterized in that: include: Get the key during the authentication process; A first key is generated according to an indication of a key and a protocol type in an authentication process, wherein the first key is used to generate a second key, wherein the second key is a shared key between a user device and an application server.

2. The method according to claim 1, characterized in that The method further comprises: A second key is generated according to the first key.

3. The method according to claim 1 or 2, characterized in that: Generating the first key according to the key and the indication of the protocol type in the authentication process includes: The first key is generated according to the key in the authentication process, the identifier of the user equipment and the indication of the protocol type.

4. The method according to claim 3, characterized in that The indication of the protocol type is at least one of extended authentication protocol EAP, EAP authentication and key agreement mechanism EAP AKA, enhanced EAP authentication and key agreement mechanism EAP AKA', 5G AKA, general bootstrapping architecture GBA and 5G GBA.

5. The method according to claim 3, characterized in that: The identifier of the user equipment is a user permanent identifier SUPI.

6. The method according to any one of claims 1 to 2, 4 to 5, characterized in that: The generating of the first key is also based on at least one of the following parameters: Session ID, authentication server ID, authenticator ID, uplink or downlink counter, sequence number, nonce, serving network ID, bootstrap server function ID.

7. The method according to claim 3, characterized in that The generating of the first key is also based on at least one of the following parameters: Session ID, authentication server ID, authenticator ID, uplink or downlink counter, sequence number, nonce, serving network ID, bootstrap server function ID.

8. The method according to any one of claims 1 to 2, 4 to 5, characterized in that: The method is executed by the user equipment.

9. The method according to claim 3, characterized in that: The method is performed by the user equipment.

10. The method according to claim 6, characterized in that The method is executed by the user equipment.

11. The method according to claim 7, characterized in that The method is performed by the user equipment.

12. The method according to any one of claims 1 to 2, 4 to 5, characterized in that: The method is executed by an authentication server.

13. The method according to any one of claim 3, characterized in that: The method is executed by an authentication server.

14. The method according to claim 6, characterized in that The method is executed by an authentication server.

15. The method according to claim 7, characterized in that The method is executed by an authentication server.

16. A key derivation device, characterized in that: include: One or more functional modules, configured to execute the method according to any one of claims 1 to 15.

17. A key derivation device, characterized in that: It comprises a processor and a memory; the memory is used to store computer-readable instructions, and the processor is used to execute the computer-readable instructions stored in the memory, so that the device executes the method described in any one of claims 1 to 15 above.

18. A computing storage medium, characterized in that: The method comprises program instructions, which are used to implement the method according to any one of claims 1 to 15 when the program instructions are executed by a processor.

19. A computer program product, characterized in that The method comprises program instructions, which are used to implement the method according to any one of claims 1 to 15 when the program instructions are executed by a processor.

20. A communication system, characterized in that: The method comprises a user device and an authentication server, wherein the user device is used to execute the method according to any one of claims 1 to 7, and the authentication server is used to execute the method according to any one of claims 1 to 7.

Images