WO2019010701A1

WO2019010701A1 - Methods and computing device for transmitting encoded information during authentication

Info

Publication number: WO2019010701A1
Application number: PCT/CN2017/093001
Authority: WO
Inventors: Zhenhua Xie
Original assignee: Zte Corporation
Priority date: 2017-07-14
Filing date: 2017-07-14
Publication date: 2019-01-17

Abstract

A first network device verifies a user equipment's access to a network by : receiving a random string, authentication token, a verification code, and an encoded information element (e.g., an encoded anchor key, permanent identifier of a subscriber associated with the user equipment, or user equipment identification) from a second network device; transmitting the random string to the user equipment; receiving, from the user equipment, a response string that is based on the random string; determining a decoded information element based on the encoded information element and a key; determining an expected verification code based on the decoded information element and one or more of the random string, the authentication token, and the response string; comparing the expected verification code with the verification code; and accepting or rejecting a registration of the user equipment based on the comparison.

Description

METHODS AND COMPUTING DEVICE FOR TRANSMITTING ENCODED INFORMATION DURING AUTHENTICATION

TECHNICAL FIELD

The present disclosure is related generally to wireless communication and, more particularly, to a method for transmitting encoded information during authentication.

BACKGROUND

In currently-proposed implementations of new radio ( “NR” ) networks, the key required for authenticating a user equipment when it moves from its home network to a visited network is transmitted between the two networks in plain text. This poses a security risk

DRAWINGS

While the appended claims set forth the features of the present techniques with particularity, these techniques, together with their objects and advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which:

FIG. 1 is a diagram of a system in which various embodiments of the disclosure are implemented.

FIG. 2 shows an example hardware architecture, according to an embodiment.

FIGS. 3 through 6 are message flow diagrams illustrating various embodiments.

DESCRIPTION

The disclosure is generally directed to methods and a computing device for verifying a user equipment’s access to a network. According to an embodiment, a first network device, verifies a user equipment’s access to a network by: receiving a random string, an authentication token, a verification code, and an encoded information element (e.g., an encoded anchor key, permanent identifier of a subscriber associated with the user equipment, or user equipment identification) from a second network device； transmitting the random string to the user equipment； receiving, from the user equipment, a response string that is based on the random string； determining a decoded information element based on the encoded information element and a key (e.g., using the key to decode the encoded information element) ； determining an expected verification code based on the decoded information element and one or more of the random string, the authentication token, and the response string (e.g., calculating or computing the expected verification code using the decoded information element and one or more of the random string, the authentication token, and the response string) ； comparing the expected verification code with the verification code； and accepting or rejecting a registration of the user equipment based on the comparison.

In an embodiment, the verification code and the encoded information element are received in separate messages. In another embodiment, they are received in the same message (e.g., an authentication request) .

In various embodiments, the expected verification code is determined additionally based on the key itself, a value used to generate the key, or a value that is generated from the key.

According to an embodiment, a first network device verifies a user equipment’s access to a network by: determining an expected response string based on a random string (e.g., calculating or computing the expected response string using the random string) ； determining an encoded information element based on an information element and a key (e.g., encoding an information element using the key) ； determining (e.g., calculating or computing) a verification code based on the expected response string and the information element； and transmitting the random string, the verification code, and the encoded information element to a second network device.

Table 1 lists various abbreviations used in the present disclosure, along with their expanded forms.

Abbreviation	Expansion
AES	Advanced Encryption Standard
AIR	Authentication Information Request
AKA	Authentication and Key Agreement
AUSF	Authentication Server Function


DH	Diffie-Hellman
EPS	Evolved Packet System
HMAC	keyed-hash message authentication code
HPLMN	Home Public Land Mobile Network
K	Key
Kng	Anchor Key
NG	Next Generation
PLMN	Public Land Mobile Network
RAND	Random string
SHA	Secure Hash Algorithm
SUPI	Subscriber Permanent Identifier
UEID	User Equipment Identification
VC	Verification Code
VPLMN	Visited Public Land Mobile Network
XVC	Expected Verification Code
XRES	Expected Response

Table 1

FIG. 1 depicts a wireless communication system 100, which includes a wireless base station 102 and a UE 104. In an embodiment, the wireless communication system 100 has many components that are not depicted in FIG. 1, including other base stations, other UEs, wireless infrastructure, wired infrastructure, and other devices commonly found in wireless networks. Example implementations of the UE include any device capable of wireless communication, such as a smartphone, tablet, laptop computer, and non-traditional devices (e.g., household appliances or other parts of the “Internet of Things” ) . The base station 102 and UE 104 may sometimes be referred to herein as “communication nodes. ” Thus, “communication node” encompasses both types of devices.

The system 100 also includes a support network 106 (e.g., a core network) , which may be physically part of a PLMN or may be cloud-based. The support network 106 includes many computing devices, but shown in FIG. 1 are an SEAF 108, an AUSF 110, and an ARPF 112. The AUSF 110 and ARPF 112 may be co-located and may even execute as separate processes on the same computing device. The SEAF 108 provides a security anchor function. The AUSF 110 terminates requests from the SEAF 108. The ARPF 112 stores the long-term security credentials used in authentication and executes cryptographic algorithms that use the long-term security credentials as input. It also stores the security-related information of the subscriber’s profile. The ARPF 112 and AUSF 110 may be located in a secure environment on the home network of the UE 104.

FIG. 2 illustrates a basic (computing device) hardware architecture found in the base station 102, UE 104, and the computing devices of the support network 104, according to an embodiment. They may have other components as well, some of which are common to all of the devices of FIG. 1 and others that are not. The hardware architecture depicted in FIG. 2 includes logic circuitry 202, memory 204, transceiver 206, and one more antennas represented by antenna 208. Each of these elements is communicatively linked to one another via one or more data pathways 210. Examples of data pathways include wires, conductive pathways on a microchip, and wireless connections.

The term “logic circuitry” as used herein means a circuit (atype of electronic hardware) designed to perform complex functions defined in terms of mathematical logic. Examples of logic circuitry include a microprocessor, a controller, or an application-specific integrated circuit. When the present disclosure refers to a device carrying out an action, it is to be understood that this can also mean that logic circuitry integrated with the device is, in fact, carrying out the action.

Possible implementations of the memory 204 include: volatile data storage； nonvolatile data storage； electrical memory； magnetic memory； optical memory； random access memory ( “RAM” ) ； cache memory； and hard drives.

In order to help illustrate the various embodiments of the disclosure, a general description of schemes used for authenticating a user equipment in an implementation of the system 100 will now be described. Other implementations are possible, however.

Turning to FIG. 3, the UE 104, SEAF 108, and the AUSF and/or ARPF 112 are depicted as engaging in communication with one another. In this example, the AUSF 110 and the ARPF 112 (if present) are assumed to be located in the home network (e.g., PLMN2) of the UE 104. According to an embodiment, prior to the operations shown in FIG. 3, the SEAF 108 and the AUSF 110 or ARPF 112 have established a shared key K. Possible ways in which this may have occurred include K being pre-configured or the devices using the DH protocol to establish K, e.g., the SEAF 108 sends a DH public key to the AUSF 110 or ARPF 112, the AUSF 110 or ARPF 112 sends another DH public key to the SEAF 108, and the SEAF 108 and the AUSF 110 or ARPF 112 uses the received DH public key to generate the shared key K.

Continuing with FIG. 3, a procedure carried out according to an embodiment will now be described. At operation 301, the UE 104 sends a registration request, e.g., an Attach Request, to the SEAF 108 which, in this example, is located in a visited network (e.g., PLMN1) . At operation 302, the SEAF 108 forwards the registration request to the AUSF 110 which, in this example, is located in the home network of the UE 104 (e.g., PLMN2) of the UE 104. The SEAF 108 may send a DH public key (or an RSA public key that it computed from a private key) along with the registration request. The AUSF 110 may further forward the registration request to an ARPF 112, also located in the home network.

Next at operation 303, the AUSF 110 or ARPF 112 may generate a DH public key for establishing the shared key K, and generates a random string RAND and anauthentication token AUTN and computes an expected response XRES based on RAND, e.g., using a hash function, such as HMAC, with a shared key (i.e., shared with the UE 104, which is not to be confused with the shared key K； the shared key K is shared between the SEAF 108 and the AUSF 110) and the RAND as input parameters. In an embodiment, AUTN ＝ SQN *AK || AMF || MAC, where SQN is a sequence number, AK is an anonymity key, AMF is an authentication management field, and MAC is a message authentication code.

The AUSF 110 or ARPF 112 also encodes one or more information elements. The information elements that will be encoded may include one or more of the following: an anchor key Kng, a SUPI, a UEID, and other information that the visited network (e.g., PLMN1) should know. Possible methods used by the AUSF 110 or ARPF 112 to encode the one or more information elements include encoding functions such as AES, with the shared key K or a key generated from the shared key as the key or (if RSA is used) with the RSA public key as the key.

The AUSF 110 or ARPF 112 also generates a VC. The method that the AUSF 110 or ARPF 112 uses for generating VC can be, for example, a hash function, such as SHA-256, with a parameter that is generated based one or more of XRES, RAND, and AUTN as well as the one or more information elements, e.g., any combination of XRES, RAND, and AUTN concatenated with the information elements. Other parameters that the AUSF 110 or ARPF 112 may use as inputs into a hash function when generating VC include the shared key K or the RSA public key or a value that was generated from the shared key K. The AUSF 110 or ARPF 112 includes RAND, the encoded information elements (K and Kng in the example of FIG 3) and VC in an EAP-AUTH request and sends the EAP-AUTH request to the SEAF 108.

At operation 304, the SEAF 108 forwards the EAP-AUTH request without the encoded information and the VC to the UE 104.

At operation 305, the UE 104 computes RES based on the RAND in the same way that the AUSF 110 or ARPF 112 computed XRES and sends an EAP-AUTH response that includes RES to the SEAF 108.

At operation 306, the SEAF 108 carries out one or more of the following: decoding the encoded information using the shared key K, a key generated from the shared key K and, if RSA was used, decoding the information using the private key that the SEAF 108 used to compute the RSA public key, computing an expected verification code XVC based on the information in the same way that AUSF 110 or ARPF 112 computed VC (e.g., if XRES is one of the inputs into the generation of VC, then RES is one of the inputs into the generation of XVC) , and comparing the XVC with the VC to determine whether they are equal. If XVC and VC are determined not to be equal, then the process ends. If they are determined to be equal, then the SEAF 108 forwards the EAP-AUTH response with the RES to the AUSF 110. The AUSF 110 may further forward the registration request to the ARPF 112.

Next, at operation 307, the AUSF 110 or ARPF 112 compares the XRES with the RES and, if they are equal, then the AUSF 110 or ARPF 112 sends a registration response, e.g., EAP-SUCCESS, to the SEAF 108. If they are not equal, then the AUSF 110 or ARPF 112 sends a registration reject, e.g., EAP-FAILURE, to the SEAF 108.

Next, at operation 308, the SEAF 108 sends a registration response, e.g., EAP-SUCCESS, to the UE 104.

Turning to FIG. 4, a procedure carried out according to an embodiment will now be described. In this example, the AUSF 110 and the ARPF 112 (if present) are assumed to be located in the home network (e.g., PLMN2) of the UE 104.

Operations

401, 402, and 403 are identical to

operations

301, 302, and 303 described above in conjunction with FIG. 3 with the exception that the AUSF 110 or ARPF 112 does not send encoded information to the SEAF 108. At operation 404, the SEAF 108 forwards the EAP-AUTH without the VC to the UE 104.

Next, at operation 405, the UE 104 computes RES based on RAND in the same way that the AUSF 110 or ARPF 112 computed XRES. The UE sends an EAP-AUTH response to the SEAF 108, which includes the RES. At operation 406, the SEAF 108 forwards the EAP-AUTH response with the RES to the AUSF 110. The AUSF 110 may further forward the registration request to the ARPF 112.

Next, at operation 407, the AUSF 110 or ARPF 112 compares the XRES with the RES and, if they are equal, then the AUSF 110 or ARPF 112 sends a registration response, e.g., EAP-SUCCESS, to the SEAF 108. The EAP-SUCCESS includes the encoded information. If they are not equal, then the AUSF 110 or ARPF 112 sends a registration reject, e.g., EAP-FAILURE, to the SEAF 108. The AUSF 110 or ARPF 112 may perform the computation of the encoded information described at operation 403 here.

Next, at operation 408, the SEAF 108 carries out one or more of the following: decoding the encoded information using the shared key K or a key generated from the shared key K (or, if RSA was used, decoding the encoded information using the private key that the SEAF 108 used to compute the RSA public key) , computing an expected verification code XVC based on the information in the same way that AUSF 110 or ARPF 112 computes VC (e.g., if XRES is one of the inputs into the generation of VC, then RES is one of the inputs into the generation of XVC) , and comparing the XVC with the VC to determine whether they are equal. If XVC and VC are determined not to be equal, then the process ends. If they are determined to be equal, then the SEAF 108 forwards the EAP-SUCCESS to the UE 104.

Specific example implementations of the above-described techniques will now be described with reference to FIGS. 5 and 6.

Proposed implementations of EPS AKA*have the following issue. If authentication confirmation is not needed by the HPLMN and a hacker is able to intercept and tamper the information sent from the AUSF to the SEAF, then he can preset RES*and K_ASME*into a illegal UE and change the K_ASME*and HXRES*in the AV*. Accordingly, when the illegal UE performs an authentication procedure in the name of a genuine user, he can grant any illegal UE the ability to use the services of the VPLMN in the name of some genuine user.

A lightweight secure method is preferred to protect the anchor key in the AV*from being intercepted and tampered, and protect the HXRES*from being tampered. FIG. 5 illustrates such a method according to an embodiment, where:

HXRES ＝ SHA-256 (XRES || RAND || OPIK || KASME*) , and OPCK ||OPIK is the 256-bit shared key

According to an embodiment, the following modifications to existing methods are made:

(1) The public key of HPLMN is in a roaming agreement. Prior to all authentication procedure, the SEAF uses the agreed public key of HPLMN to negotiate a shared key. The SEAF and AUSF, based on local policy, may update the shared key after an authentication procedure. The shared key is split to OPCK and OPIK for encoding and verifying the K_ASME*.

(2) K_ASME*is replaced in the AV*with an encoded K_ASME*, named EK_ASME*. The mask for encoding is per anchor key and will not be repeated.

(3) Change HXRES*to HXRES, which is used for verifying K_ASME*, as well as the DH shared key and also used for authenticating the UE by VPLMN. As a new parameter (K_ASME* and DH shared key) is included for computing HXRES, XRES does not need to be changed to XRES*, which is consistent with EAP-AKA’ .

(4) An encryption method for encoding the K_ASME*with the OPCK as the key is another option for securing the transmitting of the K_ASME*. This option still needs the HXRES computed as above to prevent K_ASME*from tampering and needs a negotiation mechanism for the encryption algorithm.

In an embodiment, prior to all authentication procedures, the SEAF and the AUSF negotiate a 256-bit shared key. After an authentication procedure, the AUSF and the SEAF, based on local policy, may update the shared key. The AUSF and the SEAF use the high 128 bits of the shared key as OPCK and the low 128 bits of the shared key as OPIK.

According to an embodiment, the SEAF initiates an authentication with the UE at any time, according to the SEAF's policy.

In an embodiment, the SEAF sends an Authentication Initiation Request (AIR) to the AUSF whenever the SEAF wishes to initiate an authentication with the UE with the following exception: The SEAF does not need to send an air if it has an authentication vector for EPS AKA*available and wishes to initiate an authentication with the UE over 3GPP access.

According to an embodiment, the AIR contains a subscriber identifier, from which the AUSF can derive the UE's subscriber permanent identifier (SUPI) . The subscriber identifier contained in the AIR may be a concealed SUPI, e.g., in the form of a pseudonym or a public-key encrypted SUPI. Furthermore, the subscriber identifier may be in the form of a NAI, depending on the decisions in SA2, CT1, and CT4.

In an embodiment, upon receiving the AIR, the AUSF determines the SUPI from the subscriber identifier in the air and selects the authentication method based on local policy. The local policy for the selection of the authentication method does not need to be on a per-UE basis, but can be the same for all UEs. After selecting the authentication method, the AUSF starts the authentication procedure for the selected method.

According to an embodiment, the EPS AKA*enhances the currently-existing EPS AKA by providing an Authentication Confirmation message from the visited network to the home network that confirms successful authentication of the UE such that the message cannot be spoofed by the visited network with a reasonable probability. The solution leaves the authentication exchange between the UE and the visited network unchanged, compared to using EPS AKA (except for the means to transport authentication messages over N1 and a modified authentication response) .

In an embodiment, the EPS AKA*is applied within the authentication framework as follows (and as shown in FIG. 6) :

When the AUSF has received an AIR from the SEAF and has selected EPS AKA*as the authentication method, the AUSF checks that the requesting SEAF in the serving network is entitled to use the serving network name received in the AIR.

The AUSF requests one or more authentication vectors (AVs) from the ARPF in an AV-Req including the serving network name and an indication that the authentication vector is for EPS AKA*. The ARPF generates an authentication vector with AMF separation bit ＝ 1, where AMF ＝ Authentication Management Field. The ARPF then transforms the authentication vector into a new authentication vector by replacing K_ASME with K_ASME*.

The KASME*is computed with CK, IK,

and the value of <serving network name> being the input parameters. The ARPF then returns the requested number of transformed AVs to the AUSF in an AV-Resp.

The AUSF stores XRES temporarily until a protocol timer expires. The AUSF generates encoded K_ASME*, named as EK_ASME*by computing:

The AUSF then generates HXRES from XRES and K_ASME*by computing HXRES ＝ SHA-256 (XRES || RAND || OPIK || K_ASME*) , truncated to 128 bits.

The AUSF then returns one or more authentication vectors AV*to the SEAF in a Authentication Initiation Answer (AIA) . The only difference between AV*and the transformed AV received from the ARPF is that AV*contains HXRES and EK_ASME*while the transformed AV contains XRES and K_ASME*.

The SEAF understands from the AIA that the authentication method used is EPS AKA*and that the included authentication vector is of type AV*, not AV. Furthermore, the AUSF tells the SEAF whether a confirmation message is required. Note that the AUSF may have a policy to always require a confirmation message, or adopt a more fine-grained policy depending on the trust in the roaming partner. The AUSF may learn from a database of roaming partners whether a confirmation message is required.

In an embodiment, if the AUSF requests a confirmation message from the SEAF then the AUSF sends only one authentication vector AV*to the SEAF at a time.

The SEAF sends RAND, AUTN to the UE in a NAS message Auth-Req. The UE returns RES to the SEAF in a NAS message Auth-Resp. The SEAF then gets expected K_ASME*, name as XK_ASME*, by computing

The SEAF then computes HRES from RES and XK_ASME*in the same way as the AUSF computed HXRES from XRES and K_ASME*, and then compares HRES and HXRES. If they coincide the SEAF considers the authentication successful and XK_ASME*is K_ASME*. If not the SEAF rejects the authentication.

If the authentication was successful, the key KASME*encoded in AV*becomes the anchor key. If the authentication was successful, and if a confirmation message is required, the SEAF sends RES, as received from the UE, in a newly defined Authentication Confirmation (AC) message (containing the subscriber identifier and the serving network name) to the AUSF.

When the AC message was received in response to an AIA and was received before the protocol timer above has expired the AUSF compares the received RES with the stored XRES. If they coincide the AUSF considers the confirmation message as successfully verified. If the confirmation message is not successfully verified the AUSF acts according to the home network's policy.

Possible ways for negotiating a shared key between the SEAF and the AUSF include the following. Prior to all authentication procedure, the SEAF generates a private key, computes it public key, generates a random number and use SHA-256 (random) as the shared key, and encrypts the shared key and the public key using the public key of the HPLMN that agreed between the HPLMN and the VPLMN, and then sends the encrypted keys to the AUSF. After receiving the encrypted keys, the AUSF decrypts them using private key.

After an authentication procedure, the SEAF/AUSF, based on local policy, may decide to update the shared key. The SEAF/AUSF generates a 256bits shared key as described above, and may generate a private key and compute its public key. The SEAF/AUSF encrypts the shared key and the public key if it is computed using the public key of the AUSF/SEAF, then sends the encrypted key (s) to the AUSF/SEAF.

Possible ways for using Diffie-Hellman include the following. Prior to all authentication procedure, the SEAF generates a 256bits private key, computes its DH public key, derives a shared key from the private key and the DH public key of the HPLMN that agreed between the HPLMN and the VPLMN, and then sends the computed DH public key to the AUSF.

After receiving a DH public key from the SEAF, the AUSF derives the shared key from the received DH public key and the private key for computing the DH public key that agreed between the HPLMN and the VPLMN, and generate a SKVC by computing SKVC ＝ SHA-256 (shared key) .

The AUSF then sends the SKVC to the SEAF. After receiving the SKVC, the SEAF checks the SKVC, if failure, the SEAF shall not perform any authentication procedure.

After an authentication procedure, the SEAF/AUSF, based on local policy, may decide to update the shared key. The SEAF/AUSF generates a PKVC by computing PKVC ＝ HMAC-SHA-256 (old shared key, new DH public key) . The SEAF/AUSF sends the new DH public key and the PKVC to the AUSF/SEAF, the AUSF/SEAF generates an indication corresponding to the result of the check, and generates a INVC by computing INVC ＝ HMAC-SHA-256 (old shared key, indication) . The AUSF/SEAF sends response to the SEAF/AUSF with the indication and the INVC.

It should be understood that the embodiments described herein should be considered in a descriptive sense only and not for purposes of limitation. Descriptions of features or aspects within each embodiment should typically be considered as available for other similar features or aspects in other embodiments. It will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from their spirit and scope. For example, the steps of the methods described herein could be reordered in ways that will be apparent to those of skill in the art.

Claims

A method, carried out by a first network device, for verifying a user equipment’s access to a network, the method comprising:

receiving a random string, an authentication token, a verification code, and an encoded information element from a second network device；

transmitting the random string and the authentication token to the user equipment；

receiving, from the user equipment, a response string that is based on the random string；

determining a decoded information element based on the encoded information element and a key；

determining an expected verification code based on the decoded information element and one or more of the random string, the authentication token, and the response string；

comparing the expected verification code with the verification code； and

accepting or rejecting a registration of the user equipment based on the comparison.
The method of claim 1, wherein the verification code and the encoded information element are received in separate messages.
The method of claim 1, wherein the verification code and the encoded information element are received in a single message.
The method of claim 3, wherein the single message is an authentication request.
The method of claim 1, wherein the expected verification code is determined additionally based on the key.
The method of claim 1, wherein the expected verification code is determined additionally based on a value used to generate the key.
The method of claim 1, wherein the expected verification code is determined additionally based on a value that is generated from the key.
The method of claim 1, wherein the key is a shared key, the method further comprising establishing the shared key with the second network device.
The method of claim 1 further comprising receiving a registration request from the user equipment.
The method of claim 1, wherein the encoded information element is an encoded anchor key, permanent identifier of a subscriber associated with the user equipment, or user equipment identification.
The method of claim 1 further comprising:

transmitting a message indicating success or failure to the second network device based on the comparison.
The method of claim 1, further comprising:

receiving one or more additional encoded information elements；

determining one or more additional decoded information elements based on the encoded information element and the key,

wherein the expected verification code is determined additionally based on the one or more additional information elements.
A method, carried out by a first network device, for verifying a user equipment’s access to a network, the method comprising:

determining an expected response string based on a random string；

determining an encoded information element based on an information element and a key；

determining a verification code based on the expected response string and the information element； and

transmitting the random string, the verification code, and the encoded information element to a second network device.
The method of claim 13, wherein the verification code is determined additionally based on the key.
The method of claim 13, wherein the verification code is determined additionally based on a value that is used to generate the key.
The method of claim 13, wherein the verification code is determined additionally based on a value generated from the key.
The method of claim 13, wherein the encoded information element is an encoded anchor key, permanent identifier of a subscriber associated with the user equipment, or user equipment identification.
The method of claim 13, further comprising:

determining one or more additional enccoded information elements based on one or more addtional information elements and the key,

determining a verification code based additionally on the one or more additional information elements； and

transmitting the one or more additional information elements to a second network device.
A computing device that carries out the method of any one of claims 1 through 18.
A non-transitory computing readable medium having stored thereon computer executable instructions for carrying out a method of any one of claims 1 through 18.