WO2021258922A1 - 引导认证方法、系统、电子设备和可读存储介质 - Google Patents

引导认证方法、系统、电子设备和可读存储介质 Download PDF

Info

Publication number
WO2021258922A1
WO2021258922A1 PCT/CN2021/094396 CN2021094396W WO2021258922A1 WO 2021258922 A1 WO2021258922 A1 WO 2021258922A1 CN 2021094396 W CN2021094396 W CN 2021094396W WO 2021258922 A1 WO2021258922 A1 WO 2021258922A1
Authority
WO
WIPO (PCT)
Prior art keywords
network element
naf
identifier
authentication
tid
Prior art date
Application number
PCT/CN2021/094396
Other languages
English (en)
French (fr)
Inventor
刘小军
刘建华
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2021258922A1 publication Critical patent/WO2021258922A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • This application relates to the field of communication technology, and in particular to a boot authentication method, system, electronic device, and readable storage medium.
  • GBA Generic Bootstrapping Architecture
  • 3GPP Third Generation Partnership Project
  • UE User Equipment
  • AS Application Server
  • two-way authentication is required between the UE and the AS. If the UE and the AS interact directly, there are two serious problems: independent authentication between the UE and each AS, including the negotiation of the authentication mechanism, and key management; each time the UE logs in to a different AS, it needs to enter the password.
  • GBA is a universal authentication architecture based on a shared key.
  • GBA uses the Authentication and Key Agreement (AKA) of the third-generation mobile communication network to provide a mechanism for key sharing, mutual authentication and service protection between the UE and the network. Security and versatility.
  • AKA Authentication and Key Agreement
  • the main purpose of the embodiments of this application is to propose a boot authentication method, system, electronic device, and readable storage medium, which can effectively reduce the signaling interaction between the UE and the BSF network element, reduce the risk of network storms, and improve GBA The reliability of the network.
  • the embodiment of the application provides a boot authentication method, applied to user equipment UE, including: receiving response information sent by a network application function/authentication agent NAF/AP network element; if a preset first is identified from the response information An identifier, and it is determined that the UE locally stores the B-TID of the guided transaction identifier, and performs two-way authentication with the NAF/AP network element according to the B-TID; wherein the first identifier is determined by the NAF/AP network element When a business challenge is to be executed, the identifier carried in the response information.
  • the embodiment of the application provides a boot authentication method, which is applied to the network application function/authentication agent NAF/AP network element, including: if it is determined to perform a service challenge, sending a response message carrying a preset first identifier to the user equipment UE , For the UE to perform mutual authentication with the NAF/AP network element according to the B-TID when the UE recognizes the first identifier and determines that the UE locally stores the B-TID of the guided transaction identifier.
  • the embodiment of the application provides a boot authentication system, including: network application function/authentication agent NAF/AP network element and user equipment UE;
  • the UE sends response information carrying the preset first identifier; the UE is used to receive the response information sent by the NAF/AP network element, if the first identifier is identified from the response information, and the UE is determined
  • a boot transaction identifier B-TID is stored locally, and mutual authentication is performed with the NAF/AP network element according to the B-TID.
  • An embodiment of the present application provides an electronic device, including: at least one processor; and, a memory communicatively connected with the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor The instruction is executed by the at least one processor, and when the electronic device is a network application function/authentication agent network element, the at least one processor can execute the boot authentication method applied to the NAF/AP network element as described above ; When the electronic device is a user equipment, the at least one processor can execute the aforementioned boot authentication method applied to the UE.
  • the embodiment of the present application provides a computer-readable storage medium that stores a computer program that, when executed by a processor, implements the aforementioned boot authentication method applied to NAF/AP network elements, or implements the aforementioned application to UE The boot authentication method.
  • FIG. 1 is a schematic diagram of the GBA architecture mentioned in the first embodiment of the present application.
  • Figure 2 is a typical GBA service flow chart in some situations mentioned in the first embodiment of this application;
  • Fig. 3 is the GBA redirecting business process in some situations mentioned in the first embodiment of this application;
  • FIG. 4 is a service flow chart of the first embodiment of the application mentioned in the application scenario of multiple NAF/AP network elements in some situations where frequent reboots may occur, causing a network storm;
  • FIG. 5 is a flowchart of the boot authentication method mentioned in the first embodiment of the present application.
  • FIG. 6 is a service flow chart of the UE receiving response information carrying the first identifier mentioned in the first embodiment of the present application;
  • FIG. 7 is a service flow chart of the UE receiving response information carrying the second identifier mentioned in the first embodiment of the present application;
  • FIG. 8 is a schematic diagram of a process in which a UE performs mutual authentication based on B-TID and NAF/AP network elements according to the second embodiment of the present application;
  • FIG. 9 is a flowchart of the UE accessing multiple NAF/AP network elements mentioned in the second embodiment of this application.
  • FIG. 10 is a flowchart of the boot authentication method mentioned in the third embodiment of the present application.
  • FIG. 11 is a schematic diagram of a GBA network designed for disaster tolerance scenarios in some situations mentioned in the fourth embodiment of the present application.
  • FIG. 12 is a flow chart of disaster tolerance in some situations mentioned in the fourth embodiment of the present application.
  • FIG. 13 is a flowchart of backing up disaster recovery data mentioned in the fourth embodiment of the present application.
  • FIG. 14 is a flowchart of refreshing boot authentication mentioned in the fourth embodiment of the present application.
  • FIG. 15 is a business flowchart from detecting a BSF network element failure to downloading disaster tolerance data through a takeover BSF network element mentioned in the fourth embodiment of the present application;
  • 16 is a schematic diagram of the boot authentication system mentioned in the fifth embodiment of the present application.
  • FIG. 17 is a schematic diagram of the structure of the electronic device mentioned in the sixth embodiment of the present application.
  • the first embodiment of the present application relates to a boot authentication method, which is applied to user equipment UE, and the UE is distributed in a GBA architecture.
  • the GBA architecture To facilitate understanding, the following first briefly describes the GBA architecture:
  • the schematic diagram of the GBA architecture can refer to Figure 1.
  • the logical entities in the GBA architecture can include: Bootstrapping Server Function (BSF) network elements, Network Application Function (Network Application Function, NAF) /Authentication Proxy (Authentication Proxy, referred to as AP) network element (ie NAF/AP network element), user home network server (Home Subscribe Server, referred to as HSS), user equipment (User Equipment, referred to as UE), etc.
  • BSF Bootstrapping Server Function
  • NAF Network Application Function
  • AP Authentication Proxy
  • HSS Home Subscribe Server
  • UE User Equipment
  • the BSF network element is in the user's home network.
  • the BSF network element obtains the user security settings of the GBA and the AKA authentication vector from the HSS through the Zh interface, completes the authentication of the UE, and establishes the shared key Ks.
  • the NAF network element is equivalent to the application server AS. After the NAF network element receives the service request from the UE, it can obtain the key information negotiated during the boot authentication process of the UE and the BSF network element from the BSF network element through the Zn interface, and complete the UE Certification.
  • AP network elements are generally deployed between the UE and the AS.
  • the AP network element can complete the authentication of the UE on behalf of the AS, and then the AP network element can forward the service request of the UE to the AS, and the AS processes the service request.
  • HSS user security settings, private user IDs, and authentication vectors are all stored in HSS.
  • HSS supports returning authentication vectors to BSF network elements through the Zh interface.
  • UE supports AKA protocol/Hyper Text Transfer Protocol (Hyper Text Transfer Protocol, HTTP for short) Digest protocol, and can generate Ks through mutual authentication with BSF network elements, and then generate a derived key Ks_NAF based on Ks.
  • the key can be used for mutual authentication between UE and NAF/AP.
  • the network application function/authentication proxy Network Application Function/Authentication Proxy, referred to as NAF/AP
  • NAF/AP Network Application Function/Authentication Proxy
  • BSF Bootstrapping Server Function
  • Figure 2 shows a typical GBA business flow chart in some situations, including:
  • Steps 1-1 to 1-2 the UE sends an initial service request (HTTP GET, no B-TID) to the NAF/AP network element, and the NAF/AP network element initiates a service challenge to the UE.
  • HTTP GET HTTP GET, no B-TID
  • Steps 1-3 to 1-9 After receiving the service challenge initiated by the NAF/AP network element, the UE executes a four-step guidance process (ie, lead initiation, lead challenge, lead challenge response, lead success). Steps 1-3 to 1-9 are as follows:
  • Steps 1-3 the UE sends an HTTP request to the BSF network element to indicate the initiation of the guidance.
  • the HTTP request may carry the user's private user identification (IMPI).
  • Steps 1-4 the BSF network element sends a user authentication request (Multimedia Authentication Request, referred to as MAR) to the HSS, and the MAR can carry IMPI.
  • MAR Multimedia Authentication Request
  • Steps 1-5 the HSS sends a user authentication response (Multimedia Authentication Answer, MAA for short) to the BSF network element.
  • a user authentication response Multimedia Authentication Answer, MAA for short
  • the MAA carries the authentication vector, such as the five-tuple vector of AKA authentication: random number RAND, network authentication token AUTN, and expected authentication response XRES, confidentiality key CK, integrity key IK.
  • Steps 1-6 the BSF network element sends a guidance challenge to the UE.
  • the BSF network element can send it to the UE according to the authentication vector structure 401 Unauthorized carried in the MAA, which means that the BSF network element sends a guidance challenge to the UE.
  • 401 Unauthorized can include RAND and AUTN, but does not carry IK, CK, and XRES.
  • Steps 1-7 the UE replies to the BSF network element to guide the challenge response.
  • the UE authenticates the network by checking the AUTN, including checking whether it is out of order.
  • the UE sends an HTTP GET to the BSF, which contains the AKA response value (RES) calculated by the UE, that is, the UE replies with a guided challenge response (HTTP GET) to the BSF network element.
  • RES AKA response value
  • HTTP GET guided challenge response
  • Steps 1-8 the BSF network element authenticates the UE and generates a shared key Ks and B-TID.
  • the BSF can use its own key information to calculate the RES to complete the UE authentication.
  • Steps 1-9 The BSF network element sends a 200 OK message to the UE.
  • the BSF network element is generated after the UE is successfully authenticated, and the BSF network element sends a 200 OK message to the UE to notify the UE that the authentication is successful, and the message contains the B-TID.
  • the 200 OK message may also include the lifetime of the shared key Ks.
  • the above steps 1-3 to 1-9 implement the boot authentication between the BSF and the UE through the AKA protocol. After the authentication is successful, the UE and the BSF have the B-TID and Ks.
  • Steps 1-10 After the UE is successfully booted, it sends a service challenge response carrying the B-TID to the NAF/AP network element.
  • Step 1-11 the NAF/AP network element goes to the BSF network element to find user authentication data.
  • Steps 1-12 the BSF network element returns the user authentication data to the NAF/AP network element.
  • Steps 1-13 service authentication and storage (B-TID, Ks_NAF).
  • NAF/AP network element and UE complete mutual authentication through the derived key Ks_NAF derived from Ks.
  • Steps 1-14 to 1-16 the NAF/AP network element forwards the service request to the AS, receives the service response returned by the AS, and returns it to the UE.
  • Steps 1-17 to 1-19 the UE initiates a service request again, and the NAF/AP network element authenticates the UE based on the last saved B-TID and Ks_NAF, and then forwards the service request to the AS after the authentication is passed, so as to quickly complete the service access Process.
  • FIG. 3 shows that in some cases, GBA redirects the business process, including:
  • Steps 3-1 to 3-2 the UE sends an initial service request to the NAF/AP network element, and the NAF/AP network element initiates a service challenge to the UE.
  • Step 3-3 the UE executes a four-step guidance process after receiving the challenge.
  • the AKA protocol implements the boot authentication between the BSF and the UE.
  • the UE and the BSF have B-TID1, Ks, and IMPI. Refer to the related description of the four-step guidance process in Figure 2, which will not be repeated here.
  • Steps 3-4 to 3-7 After the UE is successfully guided, it sends a service challenge response carrying B-TID1.
  • the NAF/AP network element queries the user authentication data according to the B-TID1 in the challenge response to the BSF, but the BSF returns a failure response (abnormal scenarios such as BSF sending and restarting, and user subscription data is lost).
  • the NAF/AP network element query fails, and a 401 response is returned to the UE, instructing the UE to initiate a re-direction process.
  • Steps 3-8 the UE executes the four-step guidance process after receiving the redirection response.
  • the two-way authentication between the BSF and the UE is realized through the AKA protocol. After the authentication is successful, the UE and the BSF have B-TID2, Ks, and IMPI.
  • Steps 3-9 to 3-15 after the reboot is successful, the UE executes the service access process.
  • the two-way authentication is completed between UE and NAF/AP through Ks_NAF generated by Ks.
  • Figure 4 is a business flow chart of network storms that may occur frequently in the application scenario of multiple NAF/AP network elements in some situations, including:
  • the UE initiates a service request to the NAF1/AP1 network element, and the UE obtains B-TID1 and Ks with the BSF network element after four steps of guidance.
  • the NAF1/AP1 network element performs service authentication, the locally stored B-TID1 and Ks_NAF1 forward the service request to the AS.
  • the UE initiates a service request to the NAF2/AP2 network element, and the UE and the BSF network element obtain new B-TID2 and Ks after the four-step guidance again.
  • the NAF2/AP2 network element performs service authentication, the locally stored B-TID2 and Ks_NAF2 forward the service request to the AS.
  • Steps 4-14 to 4-16 when the UE accesses the NAF1/AP1 network element again, because the re-boot process is executed when accessing the NAF2/AP2 network element, the B-TID2 is carried, and the NAF1/AP1 network element checks that there is no B- locally. TID2, return 401 to instruct the UE to reboot.
  • Step 4-17 the UE again initiates a redirection to the BSF network element to generate B-TID3.
  • the NAF1/AP1 network element queries the B-TID3 and Ks_NAF from the BSF network element to authenticate the UE.
  • the NAF1/AP1 network element stores B-TID3 and Ks_NAF data locally.
  • NAF1/AP1 network elements still have unexpired B-TID1 and Ks_NAF garbage data locally.
  • the UE accesses the NAF2/AP2 network element again, it will initiate a four-step guidance process to generate B-TID4, and the originally stored B-TID1, B-TID2, and B-TID3 will all become garbage data.
  • This scenario will cause the NAF/AP network element to store a large amount of junk data, and the signalling to the NAF/AP network element and the BSF network element will increase sharply and may cause a network storm and reduce the reliability of the GBA network.
  • the boot authentication method proposed in the first embodiment of the present application can effectively reduce the signaling interaction between the UE and the BSF network element, reduce the risk of causing network storms, and improve the reliability of the GBA network.
  • the following describes the implementation details of the boot authentication method of this embodiment. The following content is provided only for ease of understanding and is not necessary for implementing this solution.
  • the flowchart of the boot authentication method in this embodiment can refer to FIG. 5, including:
  • Step 501 Receive response information sent by the network application function/authentication agent NAF/AP network element.
  • the UE may receive response information sent by the NAF/AP network element, and the response information may be a 401 response.
  • the NAF/AP network element determines to perform a service challenge, it can send response information carrying a preset first identifier to the UE, so that the UE can receive the response information carrying the first identifier.
  • the NAF/AP network element can determine the service challenge to be executed in the following situations: the NAF/AP network element receives the service request (HTTP GET) sent by the UE, and the service request does not carry the B-TID. At this time, the NAF/AP The network element can determine the business challenge to be executed.
  • the NAF/AP network element determines to perform the redirection, it can send response information carrying the preset second identifier to the UE, so that the UE can receive the response information carrying the second identifier.
  • the NAF/AP network element can determine to perform the redirection in the following situations: the NAF/AP network element receives a service request (HTTP GET) sent by the UE, and the service request carries the B-TID, but the NAF/AP network element It is detected that the B-TID is not stored locally and the B-TID is not found in the BSF network element, indicating that the B-TID carried in the service request received by the NAF/AP network element is out of date or illegal. At this time, NAF The /AP network element can determine to perform a reboot. Or, when the NAF/AP network element detects a failure of the BSF network element, it can be determined to perform a reboot.
  • the first identifier and the second identifier are different parameter values of the Reason-Phrase parameter.
  • the parameter value of the Reason-Phrase parameter can be customized.
  • the response information that carries the first identifier can be expressed as 401 unauthorized, that is, challenge response; those that carry the second identifier
  • the response information can be expressed as 401 renegotiation, which is a redirect response.
  • unauthorized and renegotiation can be understood as parameter values customized for Reason-Phrase parameters. It should be noted that in this embodiment, the above two custom parameter values are only used as examples, and the specific implementation is not limited to this.
  • Reason-Phrase parameters can customize the parameters of Reason-Phrase parameters according to actual needs. Value to distinguish the first identifier from the second identifier. By defining different parameter values for the Reason-Phrase parameter, it is convenient to distinguish the received response information as a service challenge response (the response information sent when the NAF/AP network element determines to execute a service challenge) or a redirect response (NAF/AP) The network element determines to perform the reboot and sends a response message).
  • service challenge response the response information sent when the NAF/AP network element determines to execute a service challenge
  • NAF/AP redirect response
  • the first identifier and the second identifier may be numbers, letters, symbols, etc. that are different from each other.
  • this embodiment does not specifically limit the specific manifestations of the first identifier and the second identifier.
  • the first identifier and the second identifier are located at the head of the response message. Located at the head of the response information, it is convenient for the UE to quickly identify which identifier the response information carries after receiving the response information.
  • the NAF/AP network element may send response information carrying a preset first identifier to the UE. If the NAF/AP network element determines to perform a re-direction, it can send response information without adding an identifier to the UE. With this setting, after the UE receives the response information, if it recognizes the first identifier from the response information, it can be determined that the received response information is actually a service challenge response, and if no preset identifier is identified from the response information, it can be determined The received response information is actually a re-direction response, that is, the UE can also distinguish service challenge response and re-direction response. The purpose of this embodiment is to enable the UE to distinguish the service challenge response and the redirection response, and the method of distinguishing is not specifically limited.
  • Step 502 Determine whether the first identifier is recognized from the response information; if yes, go to step 503, otherwise go to step 504.
  • the UE can determine whether the first identifier is recognized from the response information, if the first identifier is recognized, step 503 can be performed, and if the first identifier is not recognized, step 504 can be performed.
  • Step 503 If it is determined that the UE locally stores the guided transaction identifier B-TID, perform mutual authentication with the NAF/AP network element according to the B-TID.
  • the UE can be determined that the response information sent by the NAF/AP network element is actually a service challenge response. At this point, the UE can determine whether the B-TID is stored locally. If the UE determines that the B-TID is stored locally, it means that the locally stored B-TID is valid. Then the UE can compare the B-TID with the NAF/AP network element Perform mutual authentication.
  • the process of performing mutual authentication between the UE and the NAF/AP network element according to the B-TID may be as follows:
  • the UE sends a service challenge response carrying the B-TID to the NAF/AP network element.
  • the NAF/AP network element queries the BSF network element for the authentication data of the UE, and the NAF/AP locally saves the B-TID and For data such as the derived key Ks_NAF, NAF/AP and the UE are mutually authenticated through the derived key.
  • the service request is forwarded to the AS, and the AS processes the service request. Since how to perform mutual authentication between the NAF/AP and the UE through the derived key is a well-known category, this embodiment will not further describe how to implement the two-way authentication through the derived key.
  • the UE may initiate a guided authentication process with the BSF network element.
  • the process of the UE initiating the boot authentication process with the BSF network element can refer to the four-step boot process shown in FIG. 2, and it will not be repeated here to avoid repetition.
  • the first identifier is recognized, and it is determined that the B-TID is not stored locally in the UE, indicating that the UE and the BSF network element have not undergone boot authentication, or the B-TID obtained after the UE and the BSF network element have been booted and authenticated has expired, Initiating a boot authentication process with the BSF network element at this time helps to ensure that the authentication process is guided normally when necessary.
  • Step 504 Initiate a boot authentication process with a boot service function BSF network element.
  • the UE can directly initiate the boot authentication process with the BSF network element.
  • the implementation process of the UE initiates the boot authentication process with the BSF network element refer to the four-step boot process shown in Figure 2 to avoid Repeat it here without repeating it.
  • the UE can directly initiate and guide the service function BSF network after not recognizing the first identity.
  • Step 6-1 The UE initiates a four-step guided authentication process to the BSF network element, and obtains the B-TID and Ks from the BSF network element.
  • the specific implementation of the four-step guided authentication process can refer to Figure 2, which will not be repeated here.
  • Step 6-2 the UE initiates a service request (HTTP GET) to the NAF/AP network element.
  • HTTP GET a service request
  • Step 6-3 the NAF/AP network element determines that it has received the initial service request and executes the service challenge.
  • Step 6-4 The NAF/AP network element sends response information carrying the first identifier to the UE.
  • Step 6-5 the UE recognizes the first identifier, and the B-TID already exists locally, and does not initiate a re-direction process. Wherein, when the UE recognizes the first identifier, it can determine that the received response information is a service challenge response.
  • Step 6-6 The UE sends a service challenge response to the NAF/AP network element.
  • the UE derives the derived secret key according to the last guided B-TID and Ks, and calculates the response value response according to the derived secret key.
  • the UE carries the response value response in the service challenge response to the NAF/AP network element.
  • NAF/AP network element inquires UE authentication data (user authentication data) to BSF network element, saves B-TID and Ks_NAF data locally, authenticates the UE, and forwards the service request after the authentication is passed To AS (not shown in Figure 6).
  • step 7-1 the UE initiates a four-step guided authentication process to obtain the B-TID and Ks from the BSF network element.
  • the specific implementation of the four-step guided authentication process can refer to Figure 2, which will not be repeated here.
  • Step 7-2 The UE initiates an initial service request to the NAF/AP network element; among them, the B-TID may not be carried in the initial service request.
  • Step 7-3 The NAF/AP network element determines that it has received the initial service request and executes the service challenge.
  • Step 7-4 The NAF/AP network element sends response information carrying the first identifier, such as a service challenge (401unauthorized), to the UE.
  • the first identifier such as a service challenge (401unauthorized)
  • Step 7-5 the UE derives the derived secret key according to the B-TID1 and Ks, calculates the response value, and returns a challenge response to the NAF/AP network element.
  • the challenge response carries B-TID1 and response.
  • Step 7-6 the NAF/AP network element fails to obtain B-TID1 or detects BSF disaster tolerance, and determines to perform a reboot.
  • the NAF/AP network element fails to obtain the B-TID1.
  • Step 7-7 The NAF/AP network element sends response information carrying the second identifier, such as 401 renegotiation, to the UE.
  • the second identifier such as 401 renegotiation
  • Steps 7-8 the UE receives the re-direction response and re-initiates the four-step guidance process to the BSF network element to obtain the new Ks and B-TID2.
  • Steps 7-9 the UE returns a service challenge response to the NAF/AP network element.
  • the UE derives the derived secret key according to B-TID2 and Ks, calculates the response value response, and returns a service challenge response carrying the response value response to the NAF/AP network element, and the service challenge response also carries B-TID2.
  • NAF/AP network element inquires UE authentication data (user authentication data) to BSF network element, saves B-TID2 and Ks_NAF and other data locally, and authenticates the UE, and the authentication passes the service request to AS (not shown in Figure 7).
  • UE authentication data user authentication data
  • BSF network element saves B-TID2 and Ks_NAF and other data locally
  • AS not shown in Figure 7
  • the UE can easily recognize that the response information is the response information sent by the NAF/AP network element when it determines to execute the service challenge. If the UE recognizes the first identifier from the response information, the UE can determine that the received response information is a service challenge response. If it is determined that the B-TID has been stored locally at this time, the UE can directly use the B-TID to conduct two-way communication with NAF/AP Authentication without the need to perform the guided authentication process between the UE and the BSF network element, which helps reduce the number of times the UE initiates the guided authentication process with the BSF network element, thereby effectively reducing the trust between the UE and the BSF network element.
  • the UE can easily recognize that the response information is the NAF/AP network element and then determine the response information sent when the reboot is to be performed. If the UE recognizes the second identifier from the response information, the UE can determine that the received response information is a redirection response, and the UE can initiate a guided authentication process with the BSF network element. Moreover, because the NAF/AP network element in the typical GBA business process has a low probability of initiating the redirection information, the UE has a low probability of initiating the boot authentication process with the BSF network element because it receives the redirection response. .
  • the UE can clearly distinguish whether the received response information is a service challenge response or a redirect response through the first identifier and the second identifier, which is beneficial to reduce the number of times the UE initiates the boot authentication process with the BSF network element, thereby effectively reducing
  • the signaling interaction between the UE and the BSF network element reduces the risk of causing network storms and improves the reliability of the GBA network.
  • the second embodiment of the present application relates to a boot authentication method.
  • the UE executes the boot process with the BSF network element, it can use the B-TID and shared key obtained after a successful authentication to simultaneously access multiple NAF/ AP helps to reduce the number of times that the UE initiates the boot authentication process with the BSF network element, which can effectively reduce the signaling interaction between the UE and the BSF network element, reduce the risk of network storms, and improve the reliability of the GBA network .
  • the following describes the implementation details of the boot authentication method of this embodiment. The following content is provided only for ease of understanding and is not necessary for implementing this solution.
  • the UE before receiving the response information sent by the NAF/AP network element, it also includes: the UE initiates a boot authentication process with the BSF network element, and obtains the B-TID and the B-TID corresponding to the B-TID after successful boot authentication. Shared key.
  • Fig. 8 the process of the UE performing mutual authentication with the NAF/AP network element according to the B-TID can refer to Fig. 8, which includes:
  • Step 801 Determine the encrypted information corresponding to the NAF/AP network element that sends the response information.
  • the encryption information may include: random numbers RAND, NAF_Id, etc., and NAF_Id may consist of the host name of the AS and the security identifier Ua.
  • Step 802 Generate a derived key according to the shared key corresponding to the B-TID and the encryption information corresponding to the NAF/AP network element.
  • the authentication function between the UE and NAF/AP is integrated in the mobile phone
  • the derived key can be expressed as Ks_NAF
  • Ks_int_NAF KDF(Ks, gba-u, RAND, IMPI ,NAF_Id), where u in gba-u refers to Universal Integrated Circuit Card, uicc for short, corresponds to a mobile phone card, gba-u can be understood as the identification information of the mobile phone card.
  • Step 803 Perform mutual authentication with the NAF/AP network element according to the derived key.
  • Step 9-1 The UE initiates a four-step guided authentication process to obtain the B-TID and Ks from the BSF network element.
  • Step 9-2 The UE initiates a service request to the NAF1/AP1 network element.
  • Step 9-3 The NAF1/AP1 network element sends response information carrying the first identifier, such as a service challenge (401unauthorized), to the UE.
  • the first identifier such as a service challenge (401unauthorized)
  • Step 9-4 the UE returns a service challenge response to the NAF1/AP1 network element.
  • the UE recognizes the first identifier and confirms that there is a B-TID locally, and does not initiate a re-direction process.
  • the UE generates the derived secret key Ks_int_NAF1 according to the B-TID and Ks booted last time and the encryption information corresponding to the NAF1/AP1 network element.
  • the UE uses the derived key Ks_int_NAF1 to calculate the response value response, and returns a service challenge response to NAF1/AP1.
  • NAF1/AP1 inquires the UE authentication data from the BSF, that is, after the user authentication data, locally saves B-TID and Ks_NAF1 and other data, authenticates the UE, and forwards the service request to the AS ( Not shown in Figure 9).
  • Steps 9-8 the UE initiates a service request to the NAF2/AP2 network element.
  • Steps 9-9 the NAF2/AP2 network element sends response information carrying the first identifier, such as a service challenge (401unauthorized), to the UE.
  • the first identifier such as a service challenge (401unauthorized)
  • Steps 9-10 the UE returns a service challenge response to the NAF2/AP2 network element.
  • the UE recognizes the first identifier and confirms that there is a B-TID locally, and does not initiate a re-direction process.
  • the UE generates the derived secret key Ks_int_NAF2 according to the B-TID and Ks that was booted last time and the encryption information corresponding to the NAF2/AP2 network element.
  • the UE uses the derived secret key Ks_int_NAF2, calculates the response value response, and returns a service challenge response to NAF2/AP2.
  • NAF2/AP2 network element inquires UE authentication data from BSF network element, that is, after user authentication data, it saves B-TID and Ks_NAF2 data locally, authenticates the UE, and the authentication passes the forwarding service Request to AS.
  • Steps 9-14 to 9-16 the UE initiates a service request to the NAF1/AP1 network element.
  • the NAF1/AP1 network element performs a service challenge and sends a service challenge (401 unauthorized) to the UE.
  • the UE and the NAF1/AP1 network element still perform mutual authentication based on the last derived key Ks_NAF.
  • the UE accesses multiple NAF/AP network elements at the same time, such as the aforementioned NAF1/AP1 network elements and NAF2/AP2 network elements.
  • a service challenge response for example, 401 unauthorized
  • the UE can check whether the locally stored B-TID is valid (not timed out). If the locally stored B-TID is valid, the UE can generate a derived secret key based on the guided B-TID and Ks, and use its authentication directly without re-authentication. Guide, so as to achieve a B-TID access to multiple AS at the same time.
  • the UE can check whether the locally stored B-TID is valid, which can be understood as: the UE checks whether the B-TID is stored locally, and if the B-TID is invalid, the UE check will delete the B-TID and will not save it.
  • the derived key can be generated according to the B-TID, the shared key and the encryption information corresponding to the NAF/AP network element after successful boot authentication, so that the NAF/AP network element can
  • the two-way authentication is completed with the UE based on the derived key. That is, after the UE executes the boot process with the BSF network element, it can use the B-TID and shared key obtained after a successful authentication to access multiple NAF/APs at the same time, which is beneficial to reduce the UE initiates the boot authentication with the BSF network element
  • the number of procedures can effectively reduce the signaling interaction between the UE and the BSF network element, reduce the risk of causing network storms, and improve the reliability of the GBA network.
  • the third embodiment of the present application relates to a guided authentication method, which is applied to NAF/AP network elements.
  • the following describes the implementation details of the guided authentication method of this embodiment. The following content is provided only for ease of understanding and is not an implementation. A must for this program.
  • Step 1001 Determine whether to perform a business challenge; if yes, perform step 1002, otherwise, perform step 1003.
  • the NAF/AP network element can determine whether to perform business challenges.
  • the NAF/AP network element can determine the service challenge to be executed under the following circumstances: the NAF/AP network element receives a service request (HTTP GET) sent by the UE, and the service request does not carry the B-TID.
  • the NAF/AP network element can determine the business challenge to be executed.
  • Step 1002 Send response information carrying the preset first identifier to the UE, so that when the UE recognizes the first identifier and determines that the B-TID is stored locally in the UE, it performs mutual authentication with the NAF/AP network element based on the B-TID .
  • Step 1003 If it is determined to perform re-direction, send response information carrying a preset second identifier to the UE, so that the UE can initiate a boot authentication process with the BSF network element when the second identifier is recognized.
  • this embodiment corresponds to the first and second embodiments, so this embodiment can be compatible with The first and second embodiments are implemented in cooperation with each other.
  • the related technical details mentioned in the first and second embodiments are still valid in this embodiment, and the technical effects that can be achieved in the first and second embodiments can also be achieved in this embodiment. In order to reduce repetition, here No longer. Correspondingly, the related technical details mentioned in this embodiment can also be applied to the first and second embodiments.
  • the fourth embodiment of the present application relates to a guided authentication method.
  • the following describes the implementation details of the guided authentication method of this embodiment.
  • the following content is provided for ease of understanding and is not necessary for implementing this solution.
  • the boot authentication in the disaster tolerance scenario is mainly considered, and the disaster tolerance scenario may also cause a sudden increase in signaling and reduce the network reliability of the GBA.
  • Disaster tolerance is also called remote disaster tolerance or geographic disaster tolerance. It refers to two sites located in different geographical locations. When one site cannot provide services due to uncontrollable factors such as natural disasters, wars, and power failures, the other site can take over. business.
  • the designed GBA network is shown in Figure 11, and the load sharing disaster recovery network is adopted. Multiple BSF network elements perform business sharing, but do not share disaster tolerance data or synchronize disaster tolerance data. When one device fails, the remaining BSF devices can quickly take over. However, for a certain user, after the BSF device fails, it is necessary to re-execute the boot authentication process to restore the business.
  • the disaster recovery process in some situations can be as shown in Figure 12, including:
  • the UE initiates a service request to the NAF/AP network element, and the UE obtains B-TID1 and Ks with the BSF1 network element after four-step guidance.
  • the UE sends a service challenge response according to B-TID1.
  • Steps 12-5 to 12-7 the NAF/AP network element detects the BSF1 failure and executes the disaster recovery process.
  • the NAF/AP network element returns 401 Unauthorized to instruct the UE to reboot.
  • the UE performs a four-step redirection process again, and obtains B-TID2 and Ks from the BSF2 network element.
  • Steps 12-8 to 12-12 the UE responds to the challenge according to the B-TID2, the NAF/AP network element queries the user authentication data to the BSF2 network element, authenticates the UE, and saves B-TID2 and Ks_NAF locally, and the authentication is passed Forward the service request to the AS.
  • the above-mentioned disaster recovery process will, to a certain extent, increase the boot process of BSF2 and may cause network storms, reducing the network reliability of GBA.
  • This embodiment proposes the following solution for the situation where the disaster tolerance process has the risk of causing a network storm: when the UE and the BSF network element are successfully booted and authenticated, the BSF network element backs up the disaster recovery data to the preset backup network element, and passes Backup network elements backup and share disaster recovery data. When a BSF network element fails, the remaining BSF network elements can quickly take over and download disaster recovery data from the backup network element. Services can be processed without rebooting, that is, there is no need to perform the UE and BSF network element again. Guided certification process.
  • the backup network element can be set as an HSS or a newly deployed central data node CDB according to actual needs, which is not specifically limited in this embodiment.
  • the disaster tolerance data may be data backed up by the BSF network element and the UE after successful boot authentication.
  • the BSF network element uploads the disaster tolerance data to the backup network element.
  • the BSF network element can back up the disaster tolerance data to the backup network element.
  • the BSF network element refreshes the disaster recovery data backed up to the backup network element.
  • the BSF network element deletes the disaster tolerance data backed up on the backup network element.
  • the disaster tolerance data may include: B-TID and a shared key corresponding to the B-TID.
  • the B-TID is generated after the initial boot authentication between the BSF network element and the UE is successful, and is updated when the boot authentication is refreshed.
  • the shared key is a key negotiated between the BSF network element and the UE during the boot authentication process, which is valid during its life cycle and is updated when the boot authentication is refreshed.
  • the disaster tolerance data may also include information such as the temporary user identification TMPI, the BSF network element name, and the security settings of the user's contract.
  • FIG. 13 To further facilitate the understanding of this embodiment, the following briefly describes the process of backing up disaster recovery data, which may refer to FIG. 13, including:
  • Step 13-1 The UE initiates the initial boot authentication process and sends an initial boot request to the BSF network element.
  • the initial boot request indicates that the UE is not currently authenticated on the GBA network, and the initial boot authentication process needs to be performed before initiating the service.
  • Step 13-2 The BSF network element sends a user authentication request to the HSS.
  • the BSF network element sends a user authentication request to the HSS, that is, the BSF network element goes to the HSS to query user authentication data.
  • Step 13-3 The HSS returns a user authentication response, carrying the authentication vector.
  • the authentication response can be understood as the user authentication data returned by the HSS.
  • step 13-4 the BSF network element constructs a challenge request 401 Unauthorized according to the authentication vector, and sends it to the UE.
  • step 13-5 the UE replies to the BSF network element with a guided challenge response.
  • Step 13-6 The BSF network element sends an initial guidance success response (200 OK) to the UE.
  • the BSF network element receives the challenge response sent by the UE, it authenticates the UE through the authentication vector stored locally. After the authentication is passed, the user guide authentication identifier B-TID is generated, and the life cycle of the shared key Ks is calculated.
  • the BSF network element carries the life cycle of the B-TID and Ks in the 200 OK and returns it to the UE.
  • Step 13-7 the BSF network element backs up the disaster recovery data to the backup network element.
  • the disaster tolerance data includes information such as the temporary user identification TMPI, the user guide authentication identification B-TID, the shared key Ks, the life cycle of the Ks, and the name of the BSF network element.
  • Step 13-8 the backup network element returns a backup response. Among them, after the backup network element stores the disaster tolerance data, it can return a backup response to the BSF network element.
  • Step 14-1 The UE initiates a refresh boot authentication process, and sends a refresh boot request to the BSF network element. For example, the UE has been successfully authenticated on the GBA network before, and initiates the refresh boot authentication process before the life cycle is overdue.
  • Step 14-2 The BSF network element sends a user authentication request to the HSS.
  • Step 14-3 The HSS returns a user authentication response, carrying the authentication vector.
  • Step 14-4 The BSF network element constructs a challenge request 401 Unauthorized according to the authentication vector, and sends it to the UE.
  • step 14-5 the UE replies to the BSF network element with a guided challenge response.
  • Step 14-6 the BSF network element sends a refresh guidance success response (200 OK) to the UE.
  • the BSF network element receives the challenge response sent by the UE, it authenticates the UE through the authentication vector stored locally. After the authentication is passed, a new B-TID is generated and the life cycle of the new shared key Ks is calculated. The BSF network element carries the new B-TID and the life cycle of the new Ks in the 200 OK and returns it to the UE.
  • Step 14-7 the BSF network element refreshes the backup disaster tolerance data.
  • Step 14-8 the backup network element returns a refresh response.
  • the backup network element may return a refresh response to the BSF network element.
  • the UE does not initiate a refresh boot authentication process before the shared key Ks life cycle expires, and the BSF network element deletes the UE-related data stored locally.
  • the BSF network element deletes the relevant data of the local UE, it notifies the backup network element to delete the disaster tolerance data corresponding to the UE.
  • the NAF/AP network element when the NAF/AP network element is in the process of mutual authentication with the UE, when the NAF/AP network element determines that it needs to obtain the derived key from the BSF network element and detects that the BSF network element is faulty, the NAF/AP network element The network element obtains the derived key generated based on the backup disaster tolerance data from the preset takeover BSF network element; the NAF/AP network element performs mutual authentication with the UE based on the derived key obtained from the takeover BSF network element.
  • a takeover BSF network element can download disaster tolerance data from a backup network element, and generate a derived key based on the downloaded disaster tolerance data.
  • the business flow chart from detecting the failure of the BSF network element to downloading the disaster recovery data through the takeover BSF network element can refer to Figure 15, including:
  • step 15-1 the UE initiates a four-step guided authentication process to obtain the B-TID and Ks from the BSF1 network element.
  • Step 15-2 the BSF1 network element backs up the disaster tolerance data (B-TID, Ks) to the backup network element.
  • B-TID, Ks disaster tolerance data
  • Step 15-3 the UE initiates a service request to the NAF/AP network element.
  • Step 15-4 the NAF/AP network element returns a service challenge to the UE (401 unauthorized).
  • step 15-5 the UE returns a service challenge response to the NAF1/AP network element, and the service challenge response carries the B-TID.
  • Step 15-6 The NAF/AP network element determines the failure of the BSF1 network element that guides the UE according to the B-TID, and the disaster recovery to other takeover network elements, such as the BSF2 network element.
  • the NAF/AP network element can derive the BSF network element host name from the service challenge response sent by the UE, and then determine whether the BSF network element corresponding to the BSF network element host name is faulty.
  • Step 15-7 The NAF/AP network element sends a user authentication request to the BSF2 network element, and the authentication request carries the B-TID.
  • step 15-8 the BSF2 network element sends a disaster tolerance data query request to the backup network element, and the disaster tolerance data query request carries the B-TID.
  • Steps 15-9 the backup network element returns the disaster recovery data.
  • the backup network element queries the disaster tolerance data corresponding to the B-TID according to the B-TID carried by the backup network element, such as a shared key. It can be understood that the BSF2 network element downloads the disaster tolerance data from the backup network element.
  • Step 15-10 The BSF2 network element returns an authentication response to the NAF/AP network element.
  • the BSF2 network element can generate a derived key based on the disaster tolerance data, and carry the derived key in the authentication response and return it to the NAF/AP.
  • the NAF/AP network element authenticates the UE according to the derived key, and the authentication forwards the service request to the AS.
  • the remaining BSF network elements can be quickly taken over, and the NAF/AP network element can obtain the derived key generated based on the backup disaster recovery data from the preset takeover BSF network element , There is no need to take over the re-boot authentication between the BSF network element and the UE, which is beneficial to reduce the number of reboots, reduce signaling interaction, reduce the risk of network storms, and improve the reliability of the GBA network.
  • this embodiment corresponds to the first and second embodiments, so this embodiment can be compatible with The first and second embodiments are implemented in cooperation with each other.
  • the related technical details mentioned in the first and second embodiments are still valid in this embodiment, and in order to reduce repetition, they will not be repeated here.
  • the related technical details mentioned in this embodiment can also be applied to the first and second embodiments.
  • the fifth embodiment of the present application relates to a boot authentication system, as shown in FIG. 16, including: network application function/authentication agent NAF/AP network element 1601 and user equipment UE1602; NAF/AP network element 1601, used to determine whether to Perform a service challenge and send response information carrying a preset first identifier to UE1602; UE1602 is used to receive response information sent by NAF/AP network element 1601, if the first identifier is identified from the response information, and the UE is determined to store it locally There is a guided transaction identifier B-TID, and two-way authentication is performed with the NAF/AP network element 1601 according to the B-TID.
  • NAF/AP network element 1601 and user equipment UE1602
  • NAF/AP network element 1601 used to determine whether to Perform a service challenge and send response information carrying a preset first identifier to UE1602
  • UE1602 is used to receive response information sent by NAF/AP network element 1601, if the first identifier is identified from
  • this embodiment does not introduce network elements that are not closely related to solving the technical problems raised by this application, but this does not mean that there are no other network elements in this embodiment.
  • Network element
  • this embodiment is a system example corresponding to the first to fourth embodiments, and this embodiment can be implemented in cooperation with the first to fourth embodiments.
  • the related technical details and technical effects mentioned in the first to fourth embodiments are still valid in this embodiment, and in order to reduce repetition, they will not be repeated here.
  • the related technical details mentioned in this embodiment can also be applied to the first to fourth embodiments.
  • the functional modules/units in all or some of the above devices include a non-transitory machine-readable storage medium that stores logic that can be used to perform at least a part of the following functions, for example: a storage module, an acquisition module, a trigger module, and Delete modules, etc.
  • Logic may include instructions, data, and/or codes. If these instructions, data, and/or codes are executed by a machine, the machine can perform the methods, processes, and/or operations described herein.
  • the machine can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and can be implemented using any appropriate combination of hardware, software, firmware, etc. .
  • Logic may include or may be implemented as: software, software modules, applications, programs, subroutines, instructions, instruction sets, calculation codes, words, values, symbols, etc.
  • These instructions may include any suitable type of code, for example, source code, compiled code, interpreted code, executable code, static code, dynamic code, and so on.
  • These instructions can be implemented according to a predetermined computer language, manner, or grammar to instruct the processor to perform a certain function.
  • These instructions can be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language, for example, C, C++, Java, BASIC, Matlab, Pascal, Visual BASIC, assembly Language, machine code, etc.
  • the sixth embodiment of the present application relates to an electronic device. As shown in FIG. 17, it includes: at least one processor 1701; and a memory 1702 communicatively connected with at least one processor 1701; The instructions executed by the processor 1701 are executed by at least one processor 1701,
  • the at least one processor can execute the boot authentication method in the first or second embodiment
  • the at least one processor can execute the boot authentication method in the third or fourth embodiment.
  • the memory 1702 and the processor 1701 are connected in a bus manner.
  • the bus may include any number of interconnected buses and bridges.
  • the bus connects one or more various circuits of the processor 1701 and the memory 1702 together.
  • the bus can also connect various other circuits such as peripheral devices, voltage regulators, power management circuits, etc., which are all known in the art, and therefore, will not be further described herein.
  • the bus interface provides an interface between the bus and the transceiver.
  • the transceiver may be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on the transmission medium.
  • the data processed by the processor 1701 is transmitted on the wireless medium through the antenna. Further, the antenna also receives the data and transmits the data to the processor 1701.
  • the processor 1701 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions.
  • the memory 1702 may be used to store data used by the processor 1701 when performing operations.
  • the seventh embodiment of the present application relates to a computer-readable storage medium, which stores a computer program.
  • the computer-readable storage medium includes transient or non-transitory, removable or Non-removable media.
  • the program is stored in a storage medium and includes several instructions to enable a device ( It may be a single-chip microcomputer, a chip, etc.) or a processor (processor) that executes all or part of the steps of the methods described in the embodiments of the present application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disks or optical disks and other media that can store program codes. .

Landscapes

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

Abstract

本申请实施例涉及通讯技术领域，公开了一种引导认证方法、系统、电子设备和可读存储介质。本申请中，上述引导认证方法包括：接收网络应用功能/认证代理NAF/AP网元发送的响应信息；若从所述响应信息中识别出预设的第一标识，且确定UE本地存储有引导事务标识B-TID，根据所述B-TID与所述NAF/AP网元进行双向认证；其中；所述第一标识为所述NAF/AP网元确定要执行业务挑战时，在所述响应信息中携带的标识。

Description

引导认证方法、系统、电子设备和可读存储介质
相关申请的交叉引用
本申请基于申请号为202010580221.6、申请日为2020年6月23日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此以引入方式并入本申请。
技术领域
本申请涉及通讯技术领域，特别涉及一种引导认证方法、系统、电子设备和可读存储介质。
背景技术
通用引导架构(Generic Bootstrapping Architecture，简称：GBA)是第三代合作伙伴计划(The Third Generation Partnership Project，简称：3GPP)定义的一种通用引导架构。随着众多通信业务的开展，运营商和用户都需要可靠的认证机制来保证业务的合法使用。尤其是在3G/4G业务中，很多应用都需要用户设备(User Equipment，简称：UE)和应用服务器(Application Server，简称：AS)之间进行交互，如业务激活、业务设置、业务访问等。为了保证业务应用的安全性，就要求在UE和AS之间进行双向认证。如果UE和AS直接交互，存在两个严重问题：UE和每个AS之间都要进行独立的认证，包括认证机制的协商、密钥的管理；UE每次登陆不同的AS，都需要输入密钥，用户体验差。因此3GPP标准组织提出了通用认证架构的概念，其中GBA就是一种基于共享密钥的通用认证架构。GBA使用第三代移动通讯网络的认证与密钥协商协议(Authentication and Key Agreement,简称：AKA)为UE和网络之间提供一种密钥共享、相互认证和业务保护的机制，具有较高的安全性和通用性。
发明内容
本申请实施例的主要目的在于提出一种引导认证方法、系统、电子设备和可读存储介质，可以有效的减少UE与BSF网元之间的信令交互，降低引起网络风暴的风险，提高GBA网络的可靠性。
本申请实施例提供了一种引导认证方法，应用于用户设备UE，包括：接收网络应用功能/认证代理NAF/AP网元发送的响应信息；若从所述响应信息中识别出预设的第一标识，且确定UE本地存储有引导事务标识B-TID，根据所述B-TID与所述NAF/AP网元进行双向认证；其中，所述第一标识为所述NAF/AP网元确定要执行业务挑战时，在所述响应信息中携带的标识。
本申请实施例提供了一种引导认证方法，应用于网络应用功能/认证代理NAF/AP网元，包括：若确定要执行业务挑战，向用户设备UE发送携带预设的第一标识的响应信息，以供所述UE在识别出所述第一标识且确定所述UE本地存储有引导事务标识B-TID时，根据所 述B-TID与所述NAF/AP网元进行双向认证。
本申请实施例提供了一种引导认证系统，包括：网络应用功能/认证代理NAF/AP网元和用户设备UE；所述NAF/AP网元，用于若确定要执行业务挑战，向用户设备UE发送携带预设的第一标识的响应信息；所述UE，用于接收所述NAF/AP网元发送的响应信息，若从所述响应信息中识别出所述第一标识，且确定UE本地存储有引导事务标识B-TID，根据所述B-TID与所述NAF/AP网元进行双向认证。
本申请实施例提供了一种电子设备，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，当所述电子设备为网络应用功能/认证代理网元，所述至少一个处理器能够执行如上述的应用于NAF/AP网元的引导认证方法；当所述电子设备为用户设备，所述至少一个处理器能够执行如上述的应用于UE的引导认证方法。
本申请实施例提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现上述的应用于NAF/AP网元的引导认证方法，或者实现上述的应用于UE的引导认证方法。
附图说明
图1是本申请第一实施例提到的GBA架构的示意图；
图2是本申请第一实施例提到的在一些情形中，GBA典型业务流程图；
图3是本申请第一实施例提到的在一些情形中，GBA重引导业务流程；
图4是本申请第一实施例提到的在一些情形中，多NAF/AP网元的应用场景下可能发生频繁重引导，引起网络风暴的业务流程图；
图5是本申请第一实施例提到的引导认证方法的流程图；
图6是本申请第一实施例提到的UE收到携带第一标识的响应信息的业务流程图；
图7是本申请第一实施例提到的UE收到携带第二标识的响应信息的业务流程图；
图8是本申请第二实施例提到的UE根据B-TID与NAF/AP网元进行双向认证的过程的示意图；
图9是本申请第二实施例提到的UE访问多个NAF/AP网元的流程图；
图10是本申请第三实施例提到的引导认证方法的流程图；
图11是本申请第四实施例提到的在一些情形中针对容灾场景，设计的GBA组网示意图；
图12是本申请第四实施例提到的在一些情形中的容灾流程图；
图13是本申请第四实施例提到的备份容灾数据的流程图；
图14是本申请第四实施例提到的刷新引导认证的流程图；
图15是本申请第四实施例提到的从检测到BSF网元故障到通过可接管BSF网元下载容灾数据的业务流程图；
图16是本申请第五实施例提到的引导认证系统的示意图；
图17是本申请第六实施例提到的电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本申请各实施方式中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本申请的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。
本申请的第一实施例涉及一种引导认证方法，应用于用户设备UE，UE分布在GBA架构中。为便于理解，下面首先对GBA架构进行简单说明：
在一个例子中，GBA架构的示意图可以参考图1，GBA架构中的逻辑实体可以包括：引导服务功能(Bootstrapping Server Function，简称：BSF)网元、网络应用功能(Network Application Function，简称：NAF)/认证代理(Authentication Proxy，简称：AP)网元(即NAF/AP网元)、用户归属网络服务器(Home Subscribe Server，简称：HSS)、用户设备(User Equipment，简称：UE)等。各逻辑实体的功能可以如下：
BSF网元，处于用户的归属网络，BSF网元通过Zh接口从HSS获得GBA的用户安全设置和AKA认证向量，并完成对UE的认证，建立共享密钥Ks。
NAF网元，相当于应用服务器AS，NAF网元收到UE的业务请求后，可以通过Zn接口从BSF网元获取UE和BSF网元引导认证过程中协商的密钥信息，并完成对UE的认证。
AP网元，一般部署在UE和AS之间。AP网元可以代理AS完成对UE的认证，然后AP网元可以将UE的业务请求转发至AS，由AS处理业务请求。
HSS，用户安全设置、私有用户标识、认证向量都存储在HSS中，HSS支持通过Zh接口，给BSF网元返回认证向量。
UE，UE支持AKA协议/超文本传输摘要式协议(Hyper Text Transfer Protocol,简称：HTTP)Digest协议，并且能够与BSF网元双向认证产生Ks，进而根据Ks，产生衍生密钥Ks_NAF，该衍生密钥可以用于UE和NAF/AP之间所进行的双向认证。
发明人发现：目前，GBA典型业务流程中，网络应用功能/认证代理(Network Application Function/Authentication Proxy，简称：NAF/AP)网元发起挑战响应和发起重引导响应,在协议中是同一个响应消息(401响应)，因此UE只要收到401响应，都会立即发起四步引导流程，即引导服务功能(Bootstrapping Server Function，简称：BSF)与UE之间的引导认证流程。在多NAF/AP应用场景下可能发生频繁重引导，导致信令骤增，容易引起网络风暴，GBA网络的可靠性较低。
本申请申请人通过对一些情形中GBA典型业务流程进行分析，发现GBA典型业务流程中NAF/AP发起业务挑战(图2的步骤1-2)和NAF/AP发起重引导(图3的步骤3-4)在协议中是同一个响应消息(401 Unauthorized，未经授权)，信令一模一样，无法进行区分。因此UE只要收到401响应，无法区分是挑战还是重引导，都需要立即发起四步引导流程。在多NAF/AP应用场景下(图4)可能发生频繁重引导，引起网络风暴。下面对本段所提到的图2、图3、图4进行简单说明：
图2为在一些情形中，GBA典型业务流程图，包括：
步骤1-1～1-2，UE发送初次业务请求(HTTP GET,无B-TID)到NAF/AP网元，NAF/AP 网元向UE发起业务挑战。
步骤1-3～1-9，UE收到NAF/AP网元发起的业务挑战后执行四步引导流程(即引导发起、引导挑战、引导挑战响应、引导成功)。步骤1-3～1-9具体如下：
步骤1-3，UE向BSF网元发送HTTP请求，表示引导发起。该HTTP请求中可以携带用户的私有用户标识(IMPI)。
步骤1-4，BSF网元向HSS发送用户鉴权请求(Multimedia Authentication Request,简称：MAR)，MAR中可以携带IMPI。
步骤1-5，HSS发送用户鉴权响应(Multimedia Authentication Answer，简称：MAA)给BSF网元。
其中，HSS收到MAR消息之后，运行AKA算法，为该用户计算认证向量，MAA中携带认证向量，如AKA鉴权的五元组向量：随机数RAND、网络认证令牌AUTN、期望的认证应答XRES、保密性密钥CK、完整性密钥IK。
步骤1-6，BSF网元向UE发送引导挑战。
其中，BSF网元可以根据MAA中携带认证向量构造401 Unauthorized发送给UE，即表示BSF网元向UE发送引导挑战。401 Unauthorized中可以包含RAND和AUTN，不携带IK、CK、XRES。
步骤1-7，UE向BSF网元回复引导挑战响应。
其中，UE通过检查AUTN来认证网络，包括检查是否失序，UE根据自身密钥信息计算出CK、IK和RES，从而BSF和UE各自拥有共享密钥Ks＝CK||IK。UE发送HTTP GET到BSF，其中包含着UE计算的AKA响应值(RES)即UE向BSF网元回复引导挑战响应(HTTP GET)。
步骤1-8，BSF网元认证UE，并生成共享密钥Ks和B-TID。
其中，BSF可以通过自身密钥信息，计算RES完成对UE的认证。
步骤1-9，BSF网元向UE发送引导成功(200OK)消息。
其中，BSF网元对UE认证成功后生成，BSF网元发送200OK消息到UE通知认证成功，该消息中包含B-TID。在具体实现中，200OK消息中还可以包含共享密钥Ks的生存期。
至此，上述步骤1-3～1-9通过AKA协议实现BSF与UE之间进行的引导认证，当认证成功后，UE和BSF拥有B-TID和Ks。
步骤1-10，UE引导成功之后，发送携带B-TID的业务挑战响应至NAF/AP网元。
步骤1-11，NAF/AP网元去BSF网元查找用户鉴权数据。
步骤1-12，BSF网元返回用户鉴权数据至NAF/AP网元。
步骤1-13，业务鉴权并保存(B-TID，Ks_NAF)。
其中，NAF/AP网元与UE之间通过Ks衍生的衍生密钥Ks_NAF来完成双向认证。
步骤1-14～1-16，NAF/AP网元转发业务请求至AS，接收AS回复的业务响应，并返回至UE。
步骤1-17～1-19，UE再次发起业务请求，NAF/AP网元基于上次保存的B-TID和Ks_NAF对UE进行认证，鉴权通过后转发业务请求至AS，从而快速完成业务访问流程。
图3为在一些情形中，GBA重引导业务流程，包括：
步骤3-1～3-2，UE发送初次业务请求到NAF/AP网元，NAF/AP网元向UE发起业务挑战。
步骤3-3，UE收到挑战后执行四步引导流程。通过AKA协议实现BSF与UE之间进行的引导认证，当认证成功后，UE和BSF拥有B-TID1、Ks以及IMPI。可参考对图2中四步引导流程的相关描述，这里不再赘述。
步骤3-4～3-7，UE引导成功之后，发送携带B-TID1业务挑战响应。NAF/AP网元根据挑战响应中的B-TID1到BSF查询用户鉴权数据，但BSF返回失败响应(BSF发送重启等异常场景，用户签约数据丢失)。NAF/AP网元查询失败，向UE回复401响应，指示UE发起重引导流程。
步骤3-8，UE收到重引导响应后执行四步引导流程。通过AKA协议实现BSF与UE之间进行的双向认证，当认证成功后，UE和BSF拥有B-TID2、Ks以及IMPI。
步骤3-9～3-15，重引导成功之后，UE执行业务访问流程。UE与NAF/AP之间通过Ks所产生的Ks_NAF来完成双向认证。
图4为在一些情形中，多NAF/AP网元的应用场景下可能发生频繁重引导，引起网络风暴的业务流程图，包括：
步骤4-1～4-6，UE发起到NAF1/AP1网元的业务请求，UE经过四步引导后和BSF网元得到B-TID1、Ks。NAF1/AP1网元执行业务鉴权后，本地存储的B-TID1和Ks_NAF1，转发业务请求至AS。
步骤4-7～4-13，UE发起到NAF2/AP2网元的业务请求，UE再次四步引导后和BSF网元得到新的B-TID2、Ks。NAF2/AP2网元执行业务鉴权后，本地存储的B-TID2和Ks_NAF2，转发业务请求至AS。
步骤4-14～4-16，UE再访问NAF1/AP1网元时，因为访问NAF2/AP2网元时执行了重引导流程，携带的是B-TID2，NAF1/AP1网元检查本地没有B-TID2，回401指示UE重引导。
步骤4-17，UE再次发起到BSF网元的重引导，生成B-TID3。
接下来，NAF1/AP1网元从BSF网元查询B-TID3和Ks_NAF对UE进行认证。NAF1/AP1网元本地保存B-TID3和Ks_NAF数据。同时NAF1/AP1网元本地还有未超期的B-TID1和Ks_NAF垃圾数据。
以此类推，UE再访问NAF2/AP2网元，又会发起四步引导流程，生成B-TID4，则原来存储的B-TID1、B-TID2、B-TID3都变为垃圾数据。
这种场景会导致NAF/AP网元存储大量垃圾数据，到NAF/AP网元、BSF网元的信令骤增并可能引起网络风暴，降低GBA的网络可靠性。
本申请第一实施例中提出的引导认证方法，可以有效的减少UE与BSF网元之间的信令交互，降低引起网络风暴的风险，提高GBA网络的可靠性。下面对本实施例的引导认证方法的实现细节进行说明，以下内容仅为方便理解而提供的实现细节，并非实施本方案的必须。
本实施例中的引导认证方法的流程图可以参考图5，包括：
步骤501：接收网络应用功能/认证代理NAF/AP网元发送的响应信息。
具体的说，UE可以接收NAF/AP网元发送的响应信息，该响应信息可以为401响应。
在一个例子中，如果NAF/AP网元确定要执行业务挑战，可以向UE发送携带预设的第 一标识的响应信息，从而UE可以接收到该携带有第一标识的响应信息。其中，NAF/AP网元在以下情况下可以确定要执行业务挑战：NAF/AP网元接收到UE发送的业务请求(HTTP GET)，该业务请求中未携带B-TID，此时NAF/AP网元可以确定要执行业务挑战。
在另一个例子中，如果NAF/AP网元确定要执行重引导，可以向UE发送携带预设的第二标识的响应信息，从而UE可以接收到该携带有第二标识的响应信息。其中，NAF/AP网元在以下情况下可以确定要执行重引导：NAF/AP网元接收到UE发送的业务请求(HTTP GET)，该业务请求中携带B-TID，但NAF/AP网元检测到本地并未存储该B-TID，且在BSF网元中也未查找到该B-TID，说明NAF/AP网元接收到的业务请求中携带的B-TID过期或非法，此时NAF/AP网元可以确定要执行重引导。或者，NAF/AP网元检测到BSF网元故障时，可以确定要执行重引导。
在一个例子中，第一标识和第二标识为Reason-Phrase参数的不同参数值。其中，Reason-Phrase参数的参数值可以自定义，比如，第一标识为unauthorized，第二标识为renegotiation，则携带第一标识的响应信息可以表示为401 unauthorized，即挑战响应；携带第二标识的响应信息可以表示为401renegotiation，即重引导响应。其中，unauthorized和renegotiation均可以理解为对Reason-Phrase参数自定义的参数值。需要说明的是，本实施方式中，只是以上述两种自定义的参数值为例，在具体实现中并不以此为限，本领域技术人员可以根据实际需要自定义Reason-Phrase参数的参数值以区分第一标识和第二标识。通过对Reason-Phrase参数定义不同的参数值，方便了区分接收到的响应信息为业务挑战响应(NAF/AP网元确定要执行业务挑战时，发出的响应信息)还是重引导响应(NAF/AP网元确定要执行重引导，发出的响应信息)。
在具体实现中，第一标识和第二标识可以为互不相同的数字、字母、符号等，然而，本实施方式对第一标识和第二标识的具体表现形式不做具体限定。
在一个例子中，第一标识和第二标识位于响应信息的头部。位于响应信息的头部，方便UE在接收到响应信息后可以快速识别出该响应信息携带的是哪个标识。
在一个例子中，如果NAF/AP网元确定要执行业务挑战，可以向UE发送携带预设的第一标识的响应信息。如果NAF/AP网元确定要执行重引导，可以向UE发送不增加标识的响应信息。如此设置，UE在接收到响应信息后，如果从响应信息中识别出第一标识，则可以确定接收的响应信息实际为业务挑战响应，如果从响应信息中没有识别任何预设标识，则可以确定接收的响应信息实际为重引导响应，即UE也可以区分出业务挑战响应和重引导响应。本实施方式中旨在使得UE可以区分出业务挑战响应和重引导响应，对区分的方式不做具体限定。
步骤502：确定是否从响应信息中识别出第一标识；如果是，则执行步骤503，否则执行步骤504。
也就是说，UE可以判断是否从响应信息中识别出第一标识，如果识别出第一标识可以执行步骤503，如果未识别出第一标识，可以执行步骤504。
步骤503：若确定UE本地存储有引导事务标识B-TID，根据B-TID与NAF/AP网元进行双向认证。
具体的说，如果UE从响应信息中识别出预设的第一标识，可以确定NAF/AP网元发送的响应信息实际为业务挑战响应。此时，UE可以判断本地是否存储有引导事务标识B-TID， 如果UE确定本地存储有B-TID，即表明本地存储的B-TID有效，则UE可以根据B-TID与NAF/AP网元进行双向认证。
在一个例子中，UE根据B-TID与NAF/AP网元进行双向认证的过程可以如下：
UE向NAF/AP网元发送携带B-TID的业务挑战响应，NAF/AP网元在接收到业务挑战响应后，到BSF网元查询UE的鉴权数据，NAF/AP本地保存B-TID和衍生密钥Ks_NAF等数据，NAF/AP与UE之间通过衍生密钥进行双向认证，认证通过后转发业务请求到AS，由AS处理业务请求。由于，NAF/AP与UE之间如何通过衍生密钥进行双向认证属于公知范畴，本实施例对如何通过衍生密钥进行双向认证的实现方式不再展开描述。
在一个例子中，如果UE从响应信息中识别出预设的第一标识，但确定本地未存储有B-TID，则UE可以发起与BSF网元之间的引导认证流程。其中，UE发起与BSF网元之间的引导认证流程的过程可以参考图2中所示的四步引导流程，为避免重复在此不再赘述。识别出第一标识，且确定UE本地未存储有B-TID，说明UE与BSF网元之间还未进行过引导认证，或者UE与BSF网元进行引导认证后得到的B-TID已经失效，此时再发起与BSF网元之间的引导认证流程，有利于确保在必要时引导认证流程的正常进行。
步骤504：发起与引导服务功能BSF网元之间的引导认证流程。
在一个例子中，若UE从响应信息中未识别出第一标识，但识别出预设的第二标识，可以确定NAF/AP网元发送的响应信息实际为重引导响应。此时，UE可以直接发起与BSF网元之间的引导认证流程，其中，UE发起与BSF网元之间的引导认证流程的实现过程可以参考图2中所示的四步引导流程，为避免重复在此不再赘述。
在另一个例子中，若NAF/AP网元在确定要执行重引导，向UE发送了不增加标识的响应信息，则UE在未识别出第一标识后，可以直接发起与引导服务功能BSF网元之间的引导认证流程。
为便于对本实施方式的理解，下面对UE收到携带第一标识的响应信息的业务流程进行简单说明，可以参考图6，包括：
步骤6-1，UE发起到BSF网元的四步引导认证流程，从BSF网元获取B-TID和Ks。其中，四步引导认证流程的具体实现方式可以参考图2，在此不再赘述。
步骤6-2，UE发起业务请求(HTTP GET)给NAF/AP网元。
步骤6-3，NAF/AP网元确定接收的是初次业务请求，执行业务挑战。
步骤6-4，NAF/AP网元向UE发送携带第一标识的响应信息。
步骤6-5，UE识别出第一标识，且本地已有B-TID，不发起重引导流程。其中，UE识别出第一标识时可以确定接收到的响应信息为业务挑战响应。
步骤6-6，UE向NAF/AP网元发送业务挑战响应。其中，UE根据上次引导的B-TID和Ks导出衍生秘钥，根据衍生秘钥计算响应值response，UE将该响应值response携带在给NAF/AP网元回复的业务挑战响应中。
步骤6-7～6-10，NAF/AP网元到BSF网元查询UE鉴权数据即用户鉴权数据，本地保存B-TID和Ks_NAF等数据，并对UE认证，认证通过后转发业务请求到AS(图6中未示出)。
为便于对本实施方式的理解，下面对UE收到携带第二标识的响应信息的业务流程进行简单说明，可以参考图7，包括：
步骤7-1，UE发起四步引导认证流程，从BSF网元获取B-TID和Ks。其中，四步引导 认证流程的具体实现方式可以参考图2，在此不再赘述。
步骤7-2，UE发起初次业务请求给NAF/AP网元；其中，初次业务请求中可以不携带B-TID。
步骤7-3，NAF/AP网元确定接收的是初次业务请求，执行业务挑战。
步骤7-4，NAF/AP网元向UE发送携带第一标识的响应信息，如业务挑战(401unauthorized)。
步骤7-5，UE根据B-TID1和Ks导出衍生秘钥，计算响应值response，给NAF/AP网元回挑战响应，挑战响应中携带B-TID1和response等。
步骤7-6，NAF/AP网元获取B-TID1失败或者检测到BSF容灾，确定执行重引导。其中，在NAF/AP网元未在本地或者BSF网元检测到B-TID1的情况下，可以认为NAF/AP网元获取B-TID1失败。
步骤7-7，NAF/AP网元向UE发送携带第二标识的响应信息，如401renegotiation。
步骤7-8，UE收到重引导响应，重新发起到BSF网元的四步引导流程，获取新的Ks和B-TID2。
步骤7-9，UE向NAF/AP网元回业务挑战响应。其中，UE根据B-TID2和Ks导出衍生秘钥，计算响应值response，给NAF/AP网元回携带响应值response的业务挑战响应，业务挑战响应中还携带有B-TID2。
步骤7-10～7-13，NAF/AP网元到BSF网元查询UE鉴权数据即用户鉴权数据，本地保存B-TID2和Ks_NAF等数据，并对UE认证，认证通过转发业务请求到AS(图7中未示出)。
需要说明的是，本实施方式中的上述各示例均为为方便理解进行的举例说明，并不对本申请的技术方案构成限定。
在本实施例中，UE根据第一标识，可以方便的识别出响应信息为NAF/AP网元在确定要执行业务挑战时发出的响应信息。如果UE从响应信息中识别出第一标识，UE可以确定接收到的响应信息为业务挑战响应，如果此时确定本地已存储B-TID，UE可以直接利用该B-TID与NAF/AP进行双向认证，而无需再执行UE与BSF网元之间的引导认证流程，有利于减少UE发起与BSF网元之间的引导认证流程的次数，从而可以有效的减少UE与BSF网元之间的信令交互，降低引起网络风暴的风险，提高GBA网络的可靠性。另外，UE根据第二标识，可以方便的识别出响应信息为NAF/AP网元再确定要执行重引导时发出的响应信息。如果UE从响应信息中识别出第二标识，UE可以确定接收到的响应信息为重引导响应，则UE可以发起与BSF网元之间的引导认证流程。而且，由于GBA典型业务流程中NAF/AP网元发起重引导信息的概率较小，因此，UE因为接收到重引导响应，而发起与BSF网元之间的引导认证流程的概率也就较小。UE通过第一标识和第二标识可以明显的区分接收到的响应信息是业务挑战响应还是重引导响应，有利于减少UE发起与BSF网元之间的引导认证流程的次数，从而可以有效的减少UE与BSF网元之间的信令交互，降低引起网络风暴的风险，提高GBA网络的可靠性。
本申请第二实施例涉及一种引导认证方法，本实施方式中UE执行与BSF网元的引导流程之后，可以利用一次认证成功后得到的B-TID和共享密钥，同时访问多个NAF/AP，有利于减少UE发起与BSF网元之间的引导认证流程的次数，从而可以有效的减少UE与BSF网 元之间的信令交互，降低引起网络风暴的风险，提高GBA网络的可靠性。下面对本实施例的引导认证方法的实现细节进行说明，以下内容仅为方便理解而提供的实现细节，并非实施本方案的必须。
本实施例中在接收NAF/AP网元发送的响应信息之前，还包括：UE发起与BSF网元之间的引导认证流程，并在引导认证成功后获取B-TID和与B-TID对应的共享密钥。
在一个例子中，UE根据B-TID与NAF/AP网元进行双向认证的过程可以参考图8，包括：
步骤801：确定发送响应信息的NAF/AP网元对应的加密信息。
其中，不同的NAF/AP网元对应不同的加密信息。加密信息可以包括：随机数RAND、NAF_Id等，NAF_Id可以由AS的主机名和安全标识Ua组成。
步骤802：根据与B-TID对应的共享密钥以及NAF/AP网元对应的加密信息，生成衍生密钥。
在一个例子中，UE与NAF/AP之间的认证功能集成在手机中，衍生密钥可以表示为Ks_NAF，Ks_NAF的获取方式可以为：Ks_NAF＝KDF(Ks,gba-me,RAND,IMPI,NAF_Id)，其中，gba-me中me指mobile equipment，对应手机，gba-me可以理解为手机的标识信息。
在另一个例子中，UE与NAF/AP之间的认证功能集成在手机卡中，衍生密钥可以表示为Ks_int_NAF，Ks_int_NAF的获取方式可以为：Ks_int_NAF＝KDF(Ks,gba-u,RAND,IMPI,NAF_Id)，其中，gba-u中的u指Universal Integrated Circuit Card，简称uicc，对应手机卡，gba-u可以理解为手机卡的标识信息。
可以理解的是，对不不同的NAF/AP网元，由于加密信息不同，最终生成的衍生密钥也不相同。
步骤803：根据衍生密钥与NAF/AP网元进行双向认证。
为便于对本实施方式的理解，下面对UE访问多个NAF/AP网元的流程进行简单说明，可以参考图9，包括：
步骤9-1，UE发起四步引导认证流程，从BSF网元获取B-TID和Ks。
步骤9-2，UE发起业务请求给NAF1/AP1网元。
步骤9-3，NAF1/AP1网元向UE发送携带第一标识的响应信息，如业务挑战(401unauthorized)。
步骤9-4，UE向NAF1/AP1网元回业务挑战响应。其中，UE识别出第一标识，且确认本地已有B-TID，则不发起重引导流程。UE根据上次引导的B-TID和Ks以及NAF1/AP1网元对应的加密信息，生成衍生秘钥Ks_int_NAF1。UE使用衍生秘钥Ks_int_NAF1，计算响应值response，给NAF1/AP1回业务挑战响应。
步骤9-5～9-7，NAF1/AP1到BSF查询UE鉴权数据，即用户鉴权数据后，本地保存B-TID和Ks_NAF1等数据，并对UE认证，认证通过转发业务请求到AS(图9中未示出)。
步骤9-8，UE发起业务请求给NAF2/AP2网元。
步骤9-9，NAF2/AP2网元向UE发送携带第一标识的响应信息，如业务挑战(401unauthorized)。
步骤9-10，UE向NAF2/AP2网元回业务挑战响应。其中，UE识别出第一标识，且确认本地已有B-TID，则不发起重引导流程。UE根据上次引导的B-TID和Ks以及NAF2/AP2网 元对应的加密信息，生成衍生秘钥Ks_int_NAF2。UE使用衍生秘钥Ks_int_NAF2，计算响应值response，给NAF2/AP2回业务挑战响应。
步骤9-11～9-13，NAF2/AP2网元到BSF网元查询UE鉴权数据，即用户鉴权数据后，本地保存B-TID和Ks_NAF2等数据，并对UE认证，认证通过转发业务请求到AS。
步骤9-14～9-16，UE发起业务请求给NAF1/AP1网元。NAF1/AP1网元执行业务挑战向UE发送业务挑战(401 unauthorized)。UE和NAF1/AP1网元仍然基于上次的衍生秘钥Ks_NAF进行双向认证。
通过图9可以看出，UE同时访问多个NAF/AP网元，比如上述的NAF1/AP1网元、NAF2/AP2网元，当UE收到的是业务挑战响应(比如，401 unauthorized)时，UE可以检查本地存储的B-TID是否有效(未超时)，如果本地存储的B-TID有效，则UE可以根据已经引导的B-TID、Ks生成衍生秘钥，直接使用其认证，不再重引导，从而实现一个B-TID同时访问多个AS。其中，UE可以检查本地存储的B-TID是否有效，可以理解为：UE检查本地是否存储有B-TID，如果B-TID失效UE检查将删除该B-TID，不会保存。
需要说明的是，本实施方式中的上述各示例均为为方便理解进行的举例说明，并不对本申请的技术方案构成限定。
本实施例中，对于不同的NAF/AP均可以根据已引导认证成功后的B-TID、共享密钥以及NAF/AP网元对应的加密信息生成衍生密钥，从而使得NAF/AP网元可以与UE基于该衍生密钥完成双向认证。即UE执行与BSF网元的引导流程之后，可以利用一次认证成功后得到的B-TID和共享密钥，同时访问多个NAF/AP，有利于减少UE发起与BSF网元之间的引导认证流程的次数，从而可以有效的减少UE与BSF网元之间的信令交互，降低引起网络风暴的风险，提高GBA网络的可靠性。
本申请的第三实施例涉及一种引导认证方法，应用于NAF/AP网元，下面对本实施例的引导认证方法的实现细节进行说明，以下内容仅为方便理解而提供的实现细节，并非实施本方案的必须。
本实施例中引导认证方法的流程图可以参考图10，包括：
步骤1001：确定是否要执行业务挑战；如果是，则执行步骤1002，否则执行步骤1003。
也就是说，NAF/AP网元可以确定是否要执行业务挑战。在一个例子中，NAF/AP网元在以下情况下可以确定要执行业务挑战：NAF/AP网元接收到UE发送的业务请求(HTTP GET)，该业务请求中未携带B-TID，此时NAF/AP网元可以确定要执行业务挑战。
步骤1002：向UE发送携带预设的第一标识的响应信息，以供UE在识别出第一标识且确定UE本地存储有B-TID时，根据B-TID与NAF/AP网元进行双向认证。
步骤1003：若确定要执行重引导，向UE发送携带预设的第二标识的响应信息，以供UE在识别出第二标识时，发起与BSF网元之间的引导认证流程。
由于本实施方式的引导认证方法应用于NAF/AP网元，第一、二实施方式中的引导认证方法应用于UE，本实施方式与第一、二实施方式相互对应，因此本实施方式可与第一、第二实施方式互相配合实施。第一、二实施方式中提到的相关技术细节在本实施方式中依然有效，在第一、二实施方式中所能达到的技术效果在本实施方式中也同样可以实现，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第一、二实施方式中。
本申请的第四实施例涉及一种引导认证方法，下面对本实施例的引导认证方法的实现细节进行说明，以下内容仅为方便理解而提供的实现细节，并非实施本方案的必须。
本实施例中主要考虑到容灾场景下的引导认证，容灾场景也可能导致信令骤增，降低GBA的网络可靠性。容灾也称为异地容灾或地理容灾，指位于不同地理位置的2个站点，当其中一个站点因自然灾害、战争、电力故障等不可控因素无法提供服务时，另一个站点可以接管其业务。在一些情形中，针对容灾场景，设计的GBA组网如图11所示，采用的是负荷分担容灾组网。多个BSF网元进行业务的分担，但不共享容灾数据，也不进行容灾数据同步，当一个设备故障失效时，剩余的BSF设备可以快速接管。但对于某个用户来说，BSF设备故障后，需要重新执行引导认证流程才能恢复业务。一些情形中的容灾流程可以如图12所示，包括：
步骤12-1～12-4，UE发起到NAF/AP网元的业务请求，UE经过四步引导后和BSF1网元得到B-TID1和Ks。UE根据B-TID1发送业务挑战响应。
步骤12-5～12-7，NAF/AP网元检测到BSF1故障，执行容灾流程。NAF/AP网元回401Unauthorized指示UE重引导。UE再执行四步重引导流程，从BSF2网元得到B-TID2和Ks。
步骤12-8～12-12，UE根据B-TID2回挑战响应，NAF/AP网元到BSF2网元查询用户鉴权数据，对UE进行认证，并再本地保存B-TID2和Ks_NAF，认证通过转发业务请求到AS。
上述容灾流程，在一定程度上会导致增加BSF2的引导流程并可能引起网络风暴，降低GBA的网络可靠性。
本实施例对于容灾流程存在能引起网络风暴的风险的情形，提出如下解决方案：当UE与BSF网元引导认证成功后，BSF网元将容灾数据备份到预设的备份网元，通过备份网元备份和共享容灾数据。使得当一个BSF网元故障失效时，剩余的BSF网元可以快速接管，并从备份网元下载容灾数据，不需要重引导就可以处理业务，即不需要再次执行UE与BSF网元之间的引导认证流程。其中，备份网元可以根据实际需要设置为HSS或是新部署的中央数据节点CDB，本实施方式对此不做具体限定。
其中，容灾数据可以为BSF网元与UE在引导认证成功后备份的数据，比如BSF网元将容灾数据上传至备份网元。
在一个例子中，UE与BSF网元完成初始引导认证后，BSF网元可以将容灾数据备份至备份网元。当UE与BSF网元之间刷新引导认证后，BSF网元刷新备份至备份网元上的容灾数据。当容灾数据的存续时长超过其预设的生命周期后，BSF网元删除在备份网元上备份的容灾数据。
在一个例子中，容灾数据可以包括：B-TID和与B-TID对应的共享密钥。B-TID在BSF网元与UE初始引导认证成功后生成，刷新引导认证时更新。共享密钥为BSF网元与UE在引导认证过程中协商的密钥，在其生命周期内有效，刷新引导认证时更新。在具体实现中，容灾数据还可以包括：临时用户标识TMPI、BSF网元名、用户签约的安全设置等信息。
为进一步便于对本实施例的理解，下面对备份容灾数据的流程进行简单说明，可以参考图13，包括：
步骤13-1，UE发起初始引导认证流程，发送初始引导请求给BSF网元。
其中，初始引导请求表明UE当前未在GBA网络认证，发起业务前需要先执行初始引导 认证流程。
步骤13-2，BSF网元发送用户鉴权请求给HSS。其中，BSF网元发送用户鉴权请求给HSS，即BSF网元去HSS查询用户鉴权数据。
步骤13-3，HSS返回用户鉴权响应，携带认证向量。其中，鉴权响应可以理解为HSS返回的用户鉴权数据。
步骤13-4，BSF网元根据认证向量，构造挑战请求401 Unauthorized，发送给UE。
步骤13-5，UE向BSF网元回复引导挑战响应。
步骤13-6，BSF网元向UE发送初始引导成功响应(200OK)。其中，BSF网元收到UE发送的挑战响应后，通过本地保存的认证向量对UE进行认证。认证通过后生成用户引导认证标识B-TID、计算共享密钥Ks的生命周期，BSF网元将B-TID和Ks的生命周期携带在200OK中返回给UE。
步骤13-7，BSF网元备份容灾数据至备份网元。其中，容灾数据包括临时用户标识TMPI、用户引导认证标识B-TID、共享密钥Ks、Ks的生命周期、BSF网元名等信息。
步骤13-8，备份网元返回备份应答。其中，备份网元存储好容灾数据后，可以向BSF网元返回备份应答。
为进一步便于对本实施例的理解，下面对刷新引导认证的流程进行简单说明，可以参考图14，包括：
步骤14-1，UE发起刷新引导认证流程，发送刷新引导请求给BSF网元。比如，UE之前已经在GBA网络认证成功，在生命周期超期前发起刷新引导认证流程。
步骤14-2，BSF网元发送用户鉴权请求给HSS。
步骤14-3，HSS返回用户鉴权响应，携带认证向量。
步骤14-4，BSF网元根据认证向量，构造挑战请求401 Unauthorized，发送给UE。
步骤14-5，UE向BSF网元回复引导挑战响应。
步骤14-6，BSF网元向UE发送刷新引导成功响应(200OK)。其中，BSF网元收到UE发送的挑战响应后，通过本地保存的认证向量对UE进行认证。认证通过后生成新的B-TID、计算新的共享密钥Ks的生命周期，BSF网元将新的B-TID和新的Ks的生命周期携带在200OK中返回给UE。
步骤14-7，BSF网元刷新备份的容灾数据。
步骤14-8，备份网元返回刷新应答。其中，备份网元刷新完备份的容灾数据后，可以向BSF网元返回刷新应答。
在一个例子中，在共享密钥Ks生命周期超时前UE未发起刷新引导认证流程，BSF网元则删除本地保存的该UE相关数据。BSF网元删除本地UE相关数据时，通知备份网元删除该UE对应的容灾数据。
本实施例中，NAF/AP网元在与UE进行双向认证的过程中，当NAF/AP网元确定需从BSF网元获取衍生密钥，且检测到该BSF网元故障，则NAF/AP网元从预设的可接管BSF网元获取基于备份的容灾数据生成的衍生密钥；NAF/AP网元根据从可接管BSF网元获取的衍生密钥，与UE进行双向认证。比如，可接管BSF网元可以从备份网元上下载容灾数据，基于下载的容灾数据生成衍生密钥。比如，从检测到BSF网元故障到通过可接管BSF网元下载容灾数据的业务流程图可以参考图15，包括：
步骤15-1，UE发起四步引导认证流程，从BSF1网元获取B-TID和Ks。
步骤15-2，BSF1网元将容灾数据(B-TID，Ks)备份至备份网元。
步骤15-3，UE发起业务请求给NAF/AP网元。
步骤15-4，NAF/AP网元向UE回业务挑战(401 unauthorized)。
步骤15-5，UE向NAF1/AP网元回业务挑战响应，该业务挑战响应携带B-TID。
步骤15-6，NAF/AP网元根据B-TID确定引导UE的BSF1网元故障，容灾到其他可接管网元，比如BSF2网元。在具体实现中，NAF/AP网元可以从UE发的业务挑战响应中导出BSF网元主机名，再确定该BSF网元主机名对应的BSF网元是否故障。
步骤15-7，NAF/AP网元向BSF2网元发送用户鉴权请求，该鉴权请求携带B-TID。
步骤15-8，BSF2网元向备份网元发送查询容灾数据请求，该查询容灾数据请求携带B-TID。
步骤15-9，备份网元返回容灾数据。其中，备份网元接收到容灾数据请求后，根据其携带的B-TID查询与B-TID对应的容灾数据，比如共享密钥。即可以理解为，BSF2网元从备份网元下载得到容灾数据。
步骤15-10，BSF2网元返回鉴权响应至NAF/AP网元。其中，BSF2网元可以根据容灾数据，生成衍生密钥，将衍生密钥携带在鉴权响应中返回给NAF/AP。
步骤15-11～15-12，NAF/AP网元根据衍生密钥，对UE认证，认证通过转发业务请求到AS。
需要说明的是，本实施方式中的上述各示例均为为方便理解进行的举例说明，并不对本申请的技术方案构成限定。
本实施例中，当一个BSF网元故障失效时，剩余的BSF网元可以快速接管，NAF/AP网元可以从预设的可接管BSF网元获取基于备份的容灾数据生成的衍生密钥，不需要可接管BSF网元与UE之间重新进行引导认证，有利于减少重引导的次数，减少信令交互，降低出现网络风暴的风险，提高GBA网络的可靠性。
由于本实施方式的引导认证方法应用于NAF/AP网元，第一、二实施方式中的引导认证方法应用于UE，本实施方式与第一、二实施方式相互对应，因此本实施方式可与第一、第二实施方式互相配合实施。第一、二实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第一、二实施方式中。
此外，本领域技术人员可以理解，上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。
本申请第五实施例涉及一种引导认证系统，如图16所示，包括：网络应用功能/认证代理NAF/AP网元1601和用户设备UE1602；NAF/AP网元1601，用于若确定要执行业务挑战，向UE1602发送携带预设的第一标识的响应信息；UE1602，用于接收NAF/AP网元1601发送的响应信息，若从响应信息中识别出第一标识，且确定UE本地存储有引导事务标识B-TID，根据B-TID与NAF/AP网元1601进行双向认证。
需要说明的是，为了突出本申请的创新部分，本实施方式中并没有将与解决本申请所提出的技术问题关系不太密切的网元引入，但这并不表明本实施方式中不存在其它的网元。
不难发现，本实施方式为与第一至第四实施方式相对应的系统实施例，本实施方式可与第一至第四实施方式互相配合实施。第一至第四实施方式中提到的相关技术细节和技术效果在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第一至第四实施方式中。
本领域的技术人员应该明白，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件(可以用计算装置可执行的计算机程序代码来实现)、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。
上文中的全部或某些装置中的功能模块/单元包括储存逻辑非暂态机器可读存储介质，该逻辑可用于例如执行如下各项的功能的至少一部分：存储模块、获取模块、触发模块和删除模块等。逻辑可包括指令、数据和/或代码，如果这些指令、数据和/或代码被机器执行，则可以使得机器执行本文所述的方法、处理和/或操作。该机器可包括：例如，任意适当的处理平台、计算平台、计算装置、处理装置、计算系统、处理系统、计算机、处理器等，并且可使用硬件、软件、固件等的任意适当的组合来实施。逻辑可包括或可被实施为：软件、软件模块、应用、程序、子程序、指令、指令集、计算代码、词、值、符号等。这些指令可包括任意合适类型的代码，例如，源代码、编译代码、解译代码、可执行代码、静态代码、动态代码等。这些指令可根据预定的计算机语言、方式或语法来实现，以指导处理器执行某一功能。这些指令可使用任意合适的高级、低级、面向对象的、可视的、编译的和/或解译的编程语言来实现，例如，C、C++、Java、BASIC、Matlab、Pascal、Visual BASIC、汇编语言、机器代码等等。
本申请第六实施例涉及一种电子设备，如图17所示，包括：至少一个处理器1701；以及，与至少一个处理器1701通信连接的存储器1702；其中，存储器1702存储有可被至少一个处理器1701执行的指令，指令被至少一个处理器1701执行，
当电子设备为用户设备，所述至少一个处理器能够执行第一或第二实施方式中的引导认证方法；
当电子设备为网络应用功能/认证代理网元，所述至少一个处理器能够执行第三或第四实施方式中的引导认证方法。
其中，存储器1702和处理器1701采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器1701和存储器1702的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器1701处理的数据通过天线在无线介质上进行 传输，进一步，天线还接收数据并将数据传送给处理器1701。
处理器1701负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器1702可以被用于存储处理器1701在执行操作时所使用的数据。
本申请第七实施例涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。该计算机可读存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、计算机程序模块或其他数据)的任何方法或技术中实施的暂态性或非暂态性、可移除或不可移除的介质。
即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域的普通技术人员可以理解，上述各实施例是实现本申请的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本申请的精神和范围。

Claims (18)

  1. 一种引导认证方法，其中，应用于用户设备UE，包括：
    接收网络应用功能/认证代理NAF/AP网元发送的响应信息；
    若从所述响应信息中识别出预设的第一标识，且确定UE本地存储有引导事务标识B-TID，根据所述B-TID与所述NAF/AP网元进行双向认证；其中；所述第一标识为所述NAF/AP网元确定要执行业务挑战时，在所述响应信息中携带的标识。
  2. 根据权利要求1所述的引导认证方法，其中，在所述接收网络应用功能/认证代理NAF/AP网元发送的响应信息之后，还包括：
    若从所述响应信息中识别出预设的第二标识，发起与引导服务功能BSF网元之间的引导认证流程；其中，所述第二标识为所述NAF/AP网元确定要执行重引导时，在所述响应信息中携带的标识。
  3. 根据权利要求2所述的引导认证方法，其中，所述第一标识和所述第二标识为Reason-Phrase参数的不同参数值。
  4. 根据权利要求2所述的引导认证方法，其中，所述第一标识和所述第二标识位于所述响应信息的头部。
  5. 根据权利要求1所述的引导认证方法，其中，在所述接收网络应用功能/认证代理NAF/AP网元发送的响应信息之后，还包括：
    若从所述响应信息中识别出所述第一标识，且确定UE本地未存储有所述B-TID，发起与所述BSF网元之间的引导认证流程。
  6. 根据权利要求1所述的引导认证方法，其中，在所述接收网络应用功能/认证代理NAF/AP网元发送的响应信息之前，还包括：
    发起与所述BSF网元之间的引导认证流程，并在引导认证成功后获取所述B-TID和与所述B-TID对应的共享密钥；
    所述根据所述B-TID与所述NAF/AP网元进行双向认证，包括：
    确定发送所述响应信息的所述NAF/AP网元对应的加密信息；其中，不同的NAF/AP网元对应不同的加密信息；
    根据与所述B-TID对应的共享密钥以及所述NAF/AP网元对应的加密信息，生成衍生密钥；
    根据所述衍生密钥与所述NAF/AP网元进行双向认证。
  7. 一种引导认证方法，其中，应用于网络应用功能/认证代理NAF/AP网元，包括：
    若确定要执行业务挑战，向用户设备UE发送携带预设的第一标识的响应信息，以供所述UE在识别出所述第一标识且确定所述UE本地存储有引导事务标识B-TID时，根据所述B-TID与所述NAF/AP网元进行双向认证。
  8. 根据权利要求7所述的引导认证方法，其中，所述NAF/AP网元在以下情况下确定要执行业务挑战：所述NAF/AP网元接收到UE发送的业务请求，且所述业务请求中未携带 B-TID，则NAF/AP网元确定要执行业务挑战。
  9. 根据权利要求7所述的引导认证方法，其中，所述方法还包括：
    若确定要执行重引导，向所述UE发送携带预设的第二标识的响应信息，以供所述UE在识别出所述第二标识时，发起与引导服务功能BSF网元之间的引导认证流程。
  10. 根据权利要求9所述的引导认证方法，其中，所述NAF/AP网元在以下情况下确定要执行重引导：
    所述NAF/AP网元接收到所述UE发送的业务请求，所述业务请求中携带B-TID，但所述NAF/AP网元检测到本地并未存储所述B-TID，且在所述BSF网元中也未查找到所述B-TID，说明所述NAF/AP网元接收到的业务请求中携带的B-TID过期或非法，则所述NAF/AP网元确定要执行重引导。
  11. 根据权利要求9所述的引导认证方法，其中，所述NAF/AP网元在以下情况下确定要执行重引导：
    所述NAF/AP网元检测到BSF网元故障时，则所述NAF/AP网元确定要执行重引导。
  12. 根据权利要求9所述的引导认证方法，其中，所述方法还包括：
    若确定要执行重引导，向所述UE发送不增加标识的响应信息，使得UE在接收到响应信息后，如果从响应信息中没有识别任何预设标识，则确定接收的响应信息为重引导响应。
  13. 根据权利要求7所述的引导认证方法，其中，在所述进行双向认证的过程中，包括：
    当确定需从BSF网元获取衍生密钥，且检测到所述BSF网元故障，从预设的可接管BSF网元获取基于备份的容灾数据生成的所述衍生密钥；
    根据从所述可接管BSF网元获取的所述衍生密钥，与所述UE进行双向认证。
  14. 根据权利要求13所述的引导认证方法，其中，所述容灾数据为所述BSF网元与所述UE在引导认证成功后备份的数据。
  15. 根据权利要13或14所述的引导认证方法，其中，所述容灾数据至少包括：所述B-TID和与所述B-TID对应的共享密钥。
  16. 一种引导认证系统，其中，包括：网络应用功能/认证代理NAF/AP网元和用户设备UE；
    所述NAF/AP网元，用于若确定要执行业务挑战，向用户设备UE发送携带预设的第一标识的响应信息；
    所述UE，用于接收所述NAF/AP网元发送的响应信息，若从所述响应信息中识别出所述第一标识，且确定UE本地存储有引导事务标识B-TID，根据所述B-TID与所述NAF/AP网元进行双向认证。
  17. 一种电子设备，其中，包括：
    至少一个处理器；以及，
    与所述至少一个处理器通信连接的存储器；其中，
    所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，
    当所述电子设备为用户设备，所述至少一个处理器能够执行如权利要求1至6中任一所述的引导认证方法；
    当所述电子设备为网络应用功能/认证代理网元，所述至少一个处理器能够执行如权利要 求7至15所述的引导认证方法。
  18. 一种计算机可读存储介质，存储有计算机程序，其中，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的引导认证方法，或者实现权利要求7至15所述的引导认证方法。
PCT/CN2021/094396 2020-06-23 2021-05-18 引导认证方法、系统、电子设备和可读存储介质 WO2021258922A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010580221.6A CN113840283A (zh) 2020-06-23 2020-06-23 引导认证方法、系统、电子设备和可读存储介质
CN202010580221.6 2020-06-23

Publications (1)

Publication Number Publication Date
WO2021258922A1 true WO2021258922A1 (zh) 2021-12-30

Family

ID=78964071

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/094396 WO2021258922A1 (zh) 2020-06-23 2021-05-18 引导认证方法、系统、电子设备和可读存储介质

Country Status (2)

Country Link
CN (1) CN113840283A (zh)
WO (1) WO2021258922A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117597958A (zh) * 2022-06-17 2024-02-23 北京小米移动软件有限公司 认证与授权方法、装置、通信设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101022651A (zh) * 2006-02-13 2007-08-22 华为技术有限公司 一种组合鉴权架构及其实现方法
CN103067345A (zh) * 2011-10-24 2013-04-24 中兴通讯股份有限公司 一种变异gba的引导方法及系统
WO2020007461A1 (en) * 2018-07-04 2020-01-09 Telefonaktiebolaget Lm Ericsson (Publ) Authentication and key agreement between a network and a user equipment
CN111147421A (zh) * 2018-11-02 2020-05-12 中兴通讯股份有限公司 一种基于通用引导架构gba的认证方法及相关设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101022651A (zh) * 2006-02-13 2007-08-22 华为技术有限公司 一种组合鉴权架构及其实现方法
CN103067345A (zh) * 2011-10-24 2013-04-24 中兴通讯股份有限公司 一种变异gba的引导方法及系统
WO2020007461A1 (en) * 2018-07-04 2020-01-09 Telefonaktiebolaget Lm Ericsson (Publ) Authentication and key agreement between a network and a user equipment
CN111147421A (zh) * 2018-11-02 2020-05-12 中兴通讯股份有限公司 一种基于通用引导架构gba的认证方法及相关设备

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Sentinel Authentication Gateway Guide", METASWITCH, TAS-032-ISSUE 2.7.0-RELEASE 1, 1 April 2018 (2018-04-01), XP055882683, Retrieved from the Internet <URL:https://docs.rhino.metaswitch.com/ocdoc/books/sentinel-gaa/2.7.0/sentinel-agw-guide/sentinel-gaa-2.7.0-sentinel-agw-guide.pdf> *
NOKIA, SIEMENS: "Pseudo-CR to Liberty 3GPP Security Interworking TR", 3GPP DRAFT; S3-050399-TR-LAP-PSEUDO-CR-SUB, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG3, no. Montreal; 20050621, 21 June 2005 (2005-06-21), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP050277731 *

Also Published As

Publication number Publication date
CN113840283A (zh) 2021-12-24

Similar Documents

Publication Publication Date Title
US11496320B2 (en) Registration method and apparatus based on service-based architecture
WO2015029945A1 (ja) 加入者プロファイル転送方法、加入者プロファイル転送システム及びユーザ装置
US9015819B2 (en) Method and system for single sign-on
CN111630882B (zh) 用户设备、认证服务器、介质、及确定密钥的方法和系统
CN111147231B (zh) 一种密钥协商的方法、相关装置及系统
KR20190028824A (ko) 모바일 디바이스에서의 사용자 인증 및 인간 의도 검증을 위한 방법 및 장치
KR101743195B1 (ko) 정보 제공방법, 장치, 프로그램 및 기록매체
US20130263239A1 (en) Apparatus and method for performing user authentication by proxy in wireless communication system
US11711693B2 (en) Non-3GPP device access to core network
CN106559213B (zh) 设备管理方法、设备及系统
KR20150036371A (ko) 클라우드 서버를 위한 바우처 인가
WO2022170994A1 (zh) Pc5根密钥处理方法、装置、ausf及远程终端
US11917416B2 (en) Non-3GPP device access to core network
CA3137389A1 (en) Parameter sending method and apparatus
CN102970308A (zh) 一种用户认证方法及服务器
WO2021258922A1 (zh) 引导认证方法、系统、电子设备和可读存储介质
EP4175339A1 (en) 5g authentication method, 5g account opening method and system, and electronic device and computer-readable storage medium
US20200396088A1 (en) System and method for securely activating a mobile device storing an encryption key
CN108370369B (zh) 使用重定向促进客户端设备和应用服务器之间安全通信的网关、客户端设备和方法
WO2019141135A1 (zh) 支持无线网络切换的可信服务管理方法以及装置
WO2018032984A1 (zh) 一种接入认证方法、ue和接入设备
CN113949562B (zh) Portal认证方法、装置、系统、电子设备及存储介质
WO2018137239A1 (zh) 一种鉴权方法、鉴权服务器和核心网设备
US11750599B2 (en) Method and server for authentication using continuous real-time stream as an authentication factor
WO2017210977A1 (zh) 一种管理终端接入Wi-Fi的方法及装置

Legal Events

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

Ref document number: 21830055

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 10.02.2023)

122 Ep: pct application non-entry in european phase

Ref document number: 21830055

Country of ref document: EP

Kind code of ref document: A1