Authentication between a communication device and a mobile network

Abstract

There is provided techniques for authentication between a communication device and a mobile network. A method is performed by the communication device. The method comprises generating a SUCI. The method comprises deriving a key, Kmacme_CD, from a shared secret established as part of generating the SUCI. The shared secret is established by a key agreement protocol. The method comprises sending a registration request message comprises the SUCI to the mobile network. The method comprises receiving an authentication request message from a management device in the mobile network. The authentication request comprises authentication protocol data provided by a server device. The authentication protocol data is based on a key, Kmacme_UDM, of the server device. The method comprises performing an authentication procedure in conjunction with verifying the authentication protocol data using the key Kmacme_CD.

Description

[0001] AUTHENTICATION BETWEEN

[0002] A COMMUNICATION DEVICE AND A MOBILE NETWORK

[0003] TECHNICAL FIELD

[0004] Embodiments presented herein relate to methods, a communication device, a unified data management device, a server device, computer programs, and a computer program product for authentication between the communication device and a mobile network.

[0005] BACKGROUND

[0006] In some mobile networks, the permanent unique identifier of each subscriber International Mobile Subscriber Identity (IMSI) is sent in clear text to the network when a user equipment (UE) registers to the network. So-called IMSI catchers are then able to listen in on the traffic and record the IMSI. By scanning for IMSIs at a later time, and possibly in a different location, tracking of UEs is possible. In this respect, there are different types of attacks for tracking subscribers based on knowledge of subscription information, such as IMSI and Mobile Station International Subscriber Directory Number (MSISDN). This is commonly referred to as IMSI probing attacks. One example of an IMSI probing attack when the MSISDN is known is to send many text messages, such as short messaging service (SMS) messages, towards the UE with the known MSISDN and then detect if there is a lot of corresponding signaling to a given UE to thereby identify to which UE the MSISDN belongs.

[0007] Another type of attack for tracking subscribers is the so-called AKA probing attack described below, where AKA is short for Authentication and Key Agreement, as in the AKA protocol used for subscriber authentication in mobile networks. In the AKA probing attack (also known as a linkability attack), an attacker has observed, or recorded, a pair of a random value (RAND) and an Authentication Token (AUTN) sent in an authentication request to a particular UE at a given time and location. Using a false base station, the attacker can lure a UE to connect to it and, in the subscriber authentication that follows from a registration request from the UE towards a mobile network, act as a man-in-the-middle and exchange the (RAND, AUTN)-pair sent in an authentication request from the network to the UE with the previously recorded (RAND, AUTN)-pair. If the UE responds with an authentication response indicating a synchronization error, the attacker knows it is the same UE as previously observed.

[0008] Even with the use of Subscription Concealed Identifiers (SUCIs), where the Subscription Permanent Identifier (SUPI) is not sent in clear text, attacks are still possible. SUPI probing attacks refers to attacks where an attacker already knows the SUPI, e.g., the IMSI, and wants to find out whether the subscriber with this identifier is present in a given area. In one variant the attacker knows the SUPI and the home network public key and can then generate a SUCI for that SUPI. Using a false base station, the attacker can lure a UE to connect to it and in the registration request towards a mobile network act as a man-in-the-middle and exchange the SUCI received from the UE with the generated SUCI. If the UE in the subscriber authentication that follows, using the fifth generation (5G) variants of the AKA protocol (i.e., 5G AKA or EAP-AKA’, where EAP-AKA’ is short for Extensible Authentication Protocol Authentication and Key Agreement prime), indicates success or error (in the authentication response), the attacker knows whether or not the UE is the one with the IMSI. In another variant the attacker does not even know the SUPI in clear text but knows a SUCI generated from a SUPI belonging to some subscriber as recorded, or observed, at a given time and location. The attacker can perform the same attack as above and replace the SUCI from the UE by the recorded SUCI. If in the subscriber authentication that follows the UE indicates an error (in the authentication response), the attacker knows that the UE connected to the false base station is the one from which the SUCI was previously obtained.

[0009] SUPI probing attacks also include attacks where the attacker’s goal is to enumerate valid SUPIs of a given network. These SUPIs can then be used to find out whether a subscriber is present in a given area or not. In this variant the attacker uses a false base station that guesses a SUPI and generates a SUCI for the guessed SUPI. The attack then works the same as for the generated SUCI above. If the network responds with an authentication request message containing the RAND and AUTN, this means the guessed SUPI belongs to a valid subscriber. This process can thus be used to enumerate the space of active SUPIs. The attacker can then proceed with the attack as described above. If the guessed SUPI is not valid, the network responds with a registration reject message. Solution #2.12 in 3GPP TR 33.846 VI7.0.0, ’’Study on authentication enhancements in the 5G System”, is proposed to address the AKA probing and SUPI probing attacks described above. Accordingly, a random value, RAND_MS, generated by the UE is included in the registration request along with the SUCI to add randomness to the AKA protocol run not only from the network side but also from the UE side. The registration request also contains a Message Authentication Code (MAC), denoted MACo, calculated by the Universal Subscriber Identity Module (USIM) in the UE over the SUCI and RAND_MS using a shared secret key K. The UE stores RAND_MS for use in the AKA protocol. The network verifies and decrypts the SUCI to obtain the SUPI. Using the SUPI, the network can obtain the correct subscriber secret key K and it then verifies MAC0over the SUCI and RAND_MS received in the registration request. If the MAC0verification fails, the network sends a registration reject to the UE. Since MAC0depends on the key K, this prevents attacker-generated SUCIs. Upon successful verification the network generates an authentication vector comprising RAND, AUTN, XRES, and a key, KAUSF, where XRES is an expected result. The AKA authentication is modified such that AUTN now depends both on RAND_MS and RAND generated by the network. This allows the USIM to verify that an authentication request (RAND, AUTN) is linked with the latest generated SUCI and prevents SUCI replay.

[0010] However, the aforementioned solution #2.12 requires changes in both USIM, Mobile Equipment (ME), and in the Unified Data Management (UDM) entity. The solution does not specify if the USIM or the Mobile Equipment (ME) in the UE generates the RAND_MS and does not put limitations on which entity (USIM or ME) that generates SUCI. This means there is need for an updated USIM interface for the ME to retrieve RAND_MS, provide RAND_MS and / or SUCI to USIM, if generated by ME, for use when creating MAC0, and retrieve MAC0. Further, solution #2.12 does not describe how RAND_MS is generated and transferred in the case of AKA-based authentication where the 5G-GUTI is presented as subscriber identifier to the network (and no SUCI is available), where GUTI is short for Globally Unique Temporary Identity. Hence, solution #2.12 has a specific binding of the SUCI generation to the AKA protocol. In particular, MAC0is generated using the AKA protocol shared secret key K. Another issue when using the AKA shared secret key for the binding to the AKA protocol is that the ME-USIM interface becomes more complicated in order to be able to handle SUCI generation and RAND_MS generation by the ME. The SUCI and possibly ME generated RAND_MS must then be provided to the USIM for the computation of MAC0.

[0011] Hence, there is still a need for improved protection against the aforementioned probing attacks.

[0012] SUMMARY

[0013] An object of embodiments herein is to provide authentication between a communication device and a mobile network that protects against at least some of the aforementioned probing attacks.

[0014] In the aforementioned solution #2.12, the SUCI generation and binding between the SUCI and the executed authentication protocol is not generic and therefore not usable for authentication methods not involving the AKA protocol. As an example, it would therefore be desirable if the MAC0generation in solution #2.12 would leverage another key not linked to the AKA protocol. A particular object is therefore to make the SUCI generation and binding between the SUCI and the executed authentication protocol generic and usable for other authentication methods that do not involve the AKA protocol.

[0015] Further, since the AKA protocol is the base for several network generations and backward compatibility is desired, at the same time as the update of Subscriber Identity Module (SIM) cards (i.e., distribution of new SIM cards) is slow and costly, a particular object is therefore to provide a solution without changes to the USIM.

[0016] According to a first aspect there is presented a method for authentication between a communication device and a mobile network. The method is performed by the communication device. The method comprises generating a SUCI. The method comprises deriving a key, Kmacme_CD, from a shared secret established as part of generating the SUCI. The shared secret is established by a key agreement protocol. The method comprises sending a registration request message comprises the SUCI to the mobile network. The method comprises receiving an authentication request message from a management device in the mobile network. The authentication request comprises authentication protocol data provided by a server device. The authentication protocol data is based on a key, Kmacme_UDM, of the server device. The method comprises performing an authentication procedure in conjunction with verifying the authentication protocol data using the key Kmacme_CD.

[0017] According to a second aspect there is presented a communication device for authentication between the communication device and a mobile network. The communication device comprises processing circuitry. The processing circuitry is configured to cause the communication device to generate a SUCI. The processing circuitry is configured to cause the communication device to derive a key, Kmacme_CD, from a shared secret established as part of generating the SUCI. The shared secret is established by a key agreement protocol. The processing circuitry is configured to cause the communication device to send a registration request message comprises the SUCI to the mobile network. The processing circuitry is configured to cause the communication device to receive an authentication request message from a management device in the mobile network. The authentication request comprises authentication protocol data provided by a server device. The authentication protocol data is based on a key, Kmacme_UDM, of the server device. The processing circuitry is configured to cause the communication device to perform an authentication procedure in conjunction with verifying the authentication protocol data using the key Kmacme_CD.

[0018] According to a third aspect there is presented a computer program for authentication between a communication device and a mobile network, the computer program comprising computer program code which, when run on processing circuitry of the communication device, causes the communication device to perform actions. One action comprises the communication device to generate a SUCI. One action comprises the communication device to derive a key, Kmacme_CD, from a shared secret established as part of generating the SUCI. The shared secret is established by a key agreement protocol. One action comprises the communication device to send a registration request message comprises the SUCI to the mobile network. One action comprises the communication device to receive an authentication request message from a management device in the mobile network. The authentication request comprises authentication protocol data provided by a server device. The authentication protocol data is based on a key, Kmacme_UDM, of the server device. One action comprises the communication device to perform an authentication procedure in conjunction with verifying the authentication protocol data using the key Kmacme_CD.

[0019] According to a fourth aspect there is presented a method for authentication between a communication device and a mobile network. The method is performed by a UDM device. The method comprises receiving a SUCI of the communication device from a server device. The method comprises deriving a key, Kmacme_UDM, from a shared secret established based on the SUCI. The shared secret is established by a key agreement protocol. The method comprises sending the key Kmacme_UDM to the server device.

[0020] According to a fifth aspect there is presented a UDM device for authentication between a communication device and a mobile network. The UDM device comprises processing circuitry. The processing circuitry is configured to cause the UDM device to receive a SUCI of the communication device from a server device. The processing circuitry is configured to cause the UDM device to derive a key, Kmacme_UDM, from a shared secret established based on the SUCI. The shared secret is established by a key agreement protocol. The processing circuitry is configured to cause the UDM device to send the key Kmacme_UDM to the server device.

[0021] According to a sixth aspect there is presented a computer program for authentication between a communication device and a mobile network, the computer program comprising computer program code which, when run on processing circuitry of a UDM device, causes the UDM device to perform actions. One action comprises the UDM device to receive a SUCI of the communication device from a server device. One action comprises the UDM device to derive a key, Kmacme_UDM, from a shared secret established based on the SUCI. The shared secret is established by a key agreement protocol. One action comprises the UDM device to send the key Kmacme_UDM to the server device.

[0022] According to a seventh aspect there is presented a method for authentication between a communication device and a mobile network. The method is performed by a server device. The method comprises receiving an authentication request message for the communication device from a management device. The authentication request message comprises a SUCI of the communication device. The method comprises sending the SUCI to a UDM device. The method comprises receiving a key, Kmacme_UDM, from the UDM device. The method comprises sending an authentication response message to the management device. The authentication response comprises authentication protocol data based on the key Kmacme_UDM.

[0023] According to an eighth aspect there is presented a server device for authentication between a communication device and a mobile network. The server device comprises processing circuitry. The processing circuitry is configured to cause the server device to receive an authentication request message for the communication device from a management device. The authentication request message comprises a SUCI of the communication device. The processing circuitry is configured to cause the server device to send the SUCI to a UDM device. The processing circuitry is configured to cause the server device to receive a key, Kmacme_UDM, from the UDM device. The processing circuitry is configured to cause the server device to send an authentication response message to the management device. The authentication response comprises authentication protocol data based on the key Kmacme_UDM.

[0024] According to a ninth aspect there is presented a computer program for authentication between a communication device and a mobile network, the computer program comprising computer program code which, when run on processing circuitry of a server device, causes the server device to perform actions. One action comprises the server device to receive an authentication request message for the communication device from a management device. The authentication request message comprises a SUCI of the communication device. One action comprises the server device to send the SUCI to a UDM device. One action comprises the server device to receive a key, Kmacme_UDM, from the UDM device. One action comprises the server device to send an authentication response message to the management device. The authentication response comprises authentication protocol data based on the key Kmacme_UD M .

[0025] According to a tenth aspect there is presented a computer program product comprising a computer program according to at least one of the third aspect, the sixth aspect, and the ninth aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium can be a non- transitory computer readable storage medium. Advantageously, these aspects provide efficient protection against the aforementioned probing attacks.

[0026] Advantageously, these aspects protect against the aforementioned AKA-probing and SUPI-probing attacks where an old SUCI is either replayed or generated by the attacker from a known SUPI.

[0027] Advantageously, according to these aspects the mechanism for binding the SUCI to the authentication protocol is generic and can be used for other authentication mechanisms than the AKA protocol. There are also few changes required to the USIM and UDM.

[0028] Advantageously, these aspects can be combined with mitigation techniques to provide even further protection against the aforementioned probing attacks. For example, the network could always return the same response both when the SUPI is valid and invalid, where this response contains an authentication vector (or parts of it) as when the SUPI is valid. But, in case of an invalid SUPI, the authentication vector would contain random data. The attacker can therefore not learn anything from the returned authentication request from the network. Depending on how this mitigation is realized in the network, the combination of this mitigation and the herein disclosed embodiments may still only require changes to the UDM, and no changes to the USIM.

[0029] Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings.

[0030] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a / an / the element, apparatus, component, means, module, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, module, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The inventive concept is now described, by way of example, with reference to the accompanying drawings, in which:

[0032] Fig. 1 is a schematic diagram illustrating a communication system according to embodiments;

[0033] Figs. 2, 3, and 4 are flowcharts of methods according to embodiments;

[0034] Figs. 5, 6, and 7 are flowcharts of methods according to embodiments;

[0035] Fig. 8 is a schematic diagram showing functional units of a communication device according to an embodiment;

[0036] Fig. 9 is a schematic diagram showing functional modules of a communication device according to an embodiment;

[0037] Fig. 10 is a schematic diagram showing functional units of a UDM device according to an embodiment;

[0038] Fig. 11 is a schematic diagram showing functional modules of a UDM device according to an embodiment;

[0039] Fig. 12 is a schematic diagram showing functional units of a server device according to an embodiment;

[0040] Fig. 14 is a schematic diagram showing functional modules of a server device according to an embodiment; and

[0041] Fig. 15 shows one example of a computer program product comprising computer readable means according to an embodiment.

[0042] DETAILED DESCRIPTION

[0043] The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the inventive concept are shown. This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description. Any step or feature illustrated by dashed lines should be regarded as optional.

[0044] The EAP framework has been introduced 5G mobile networks to make it possible to use other authentication protocols than AKA-based authentication. However, for public 5G networks the only EAP method allowed is the EAP -AKA’ method. For nonpublic networks other methods such as EAP-TLS may be used, where TLS is short for Transport Layer Security. An AKA-based authentication method outside of the EAP framework is also specified called 5G AKA.

[0045] A communication system 10 based on the 5G architecture is illustrated in Fig. 1. The communication system 10 comprises a communication device 100 in the form of a UE. The communication device 100 is configured to be operatively connected to a mobile network, as represented by (radio) access networks ((R)ANs) 12a, 12b, where (R)AN 12a represents the home mobile network operator and (R)AN 12b represents the serving mobile network operator. Each of the (R)ANs 12a, 12b is in turn operatively connected to a respective core network (CN) 14a, 14b. Each CN 14a, 14b comprises a management device 16a, 16b in the form of an AMF, a server device 300 in the form of an AUSF, and a UDM device 200.

[0046] According to the 5G architecture the UDM device 200 of the home mobile network handles user data including data for subscriber authentication (comprising at least the authentication algorithm to be used but may also include data for the authentication). If an AKA based protocol, such as 5G AKA or EAP-AKA’ is used, the UDM device 200 handles the AKA shared secret key K and provides AKA authentication vectors to the server device 300. The server device 300 is responsible for the subscriber authentication. The server device 300 implements the EAP framework and network part of the subscriber authentication. The AUSF interacts with the management device 16a, 16b that handles registration and mobility management and that interacts with the communication device 100 via the (R)AN. In non-roaming case it is the management device 160a of the home mobile network that interacts with the communication device 100 via the (R)AN 12a of the home mobile network. In the roaming case the communication device 100 interacts with the management device 16b of the serving mobile network that in turn interacts with the AUSF 300 of the home mobile network via a roaming interface between the networks.

[0047] According to the 5G architecture, the unique SUPI, which can be in the form of an IMSI, can be encrypted and integrity protected (MACed). The encrypted and integrity protected SUPI is the SUCI and the generation of the SUCI is either done by the USIM application or by the ME in the communication device 100. The USIM / ME generates an ephemeral elliptic curve (EC) key pair and derives the encryption key and MAC key using an elliptic curve key agreement using Diffie-Hellman (DH) from the generated private key and the home operator public key stored on the SIM card as part of the USIM application. The SUPI consists of one part used for routing to the home network in the roaming cases and a part unique for each subscriber. Only the subscriber unique part is encrypted using the encryption key. The part used for routing is included in clear text. The SUCI also includes the generated ephemeral public key. The SUCI is integrity protected by computing a MAC over the SUCI data using the MAC key.

[0048] The SUCI is sent by the communication device 100 to the management device 16a, 16b in the network, e.g., in a registration request message or as a response to an identity request from the network. The management device 16a, 16b analyzes nonencrypted routing part of the SUCI to determine the home network. The SUCI is then forwarded to the UDM device 200 via the server device 300 where the UDM device 200 uses the (home) network private key and the received ephemeral public key contained in the SUCI to derive the encryption and MACs keys. The UDM device 200 then uses these keys to verify the integrity of the SUCI, by verifying the SUCI MAC, and decrypt the encrypted part of the SUCI to obtain the SUPI. Based on the SUPI the UDM device 200 can obtain subscriber information from the database, decide on authentication algorithm to be used and, depending on the authentication algorithm, derive authentication data such as an AKA authentication vector for use in the subscriber authentication. This information and the SUPI are returned to the server device 300 that starts the authentication protocol. Upon successful authentication the server device 300 delivers the SUPI to the management device 16a, 16b. Any entity with the knowledge of the SUPI and the home network public key can generate a valid SUCI that is accepted by the (home) network. A temporary identifier assigned by the management device 16a, 16b, called 5G-GUTI, is used as identifier of the communication device 100 in the communication between the communication device 100 and the (serving) mobile network instead of the SUPI to protect privacy. Improvements have been made in 5G mobile networks related to the how this parameter is refreshed.

[0049] However, as noted above, there is still a need for improved protection against the aforementioned probing attacks.

[0050] The embodiments disclosed herein thus relate to techniques for authentication between a communication device 100 and a mobile network 12. In order to obtain such techniques, there is provided a communication device 100, a method performed by the communication device 100, a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the communication device 100, causes the communication device 100 to perform the method. In order to obtain such techniques, there is further provided a UDM device 200, a method performed by the UDM device 200, and a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the UDM device 200, causes the UDM device 200 to perform the method. In order to obtain such techniques, there is further provided a server device 300, a method performed by the server device 300, and a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the server device 300, causes the server device 300 to perform the method.

[0051] Reference is now made to Fig. 2 illustrating a method for authentication between a communication device 100 and a mobile network 12 as performed by the communication device 100 according to an embodiment.

[0052] S102: The communication device 100 generates a SUCI. In some examples, the SUCI is associated with a subscriber of the communication device 100.

[0053] S104: The communication device 100 derives a key, Kmacme_CD, from a shared secret established as part of generating the SUCI. The shared secret is established by a key agreement protocol. Sio6: The communication device 100 sends a registration request message comprising the SUCI to the mobile network 12.

[0054] Sio8: The communication device 100 receives an authentication request message from a management device 16 in the mobile network 12. The authentication request comprises authentication protocol data provided by a server device 300. The authentication protocol data is based on a key, Kmacme_UDM, of the server device 300. As will be further disclosed below, the key Kmacme_UDM is derived by the UDM device 200 from the shared secret established based on the SUCI.

[0055] S110: The communication device 100 performs an authentication procedure in conjunction with verifying the authentication protocol data using the key Kmacme_CD. In other words, the authentication protocol data is only successfully verified in case the key Kmacme_UDM is identical to the key Kmacme_CD.

[0056] Embodiments relating to further details of authentication between a communication device 100 and a mobile network 12 as performed by the communication device 100 will now be disclosed with continued reference to Fig. 2.

[0057] There may be different types of authentication protocol data. In some embodiments, the authentication protocol data is a MAC having been computed using the key Kmacme_UDM. For example, in case of an AKA based authentication algorithm, the MAC might be computed based on a random value RAND and / or an authentication token AUTN. In other embodiments, the authentication protocol data is data encrypted using the key Kmacme_UDM. For example, in case of an AKA based authentication algorithm, the authentication protocol data is an encrypted random value RAND and / or an encrypted Authentication Token AUTN. The RAND and / or the AUTN have / has been encrypted using the key Kmacme_UDM, and verifying the authentication protocol data comprises using the key Kmacme_CD to decrypt the RAND and / or the AUTN.

[0058] There may be different orders in which the verification and the authentication is performed in step S110. When the authentication protocol data is an encrypted random value RAND and / or an encrypted Authentication Token AUTN, the decryption (as performed as part of verifying the authentication protocol data) to obtain RAND and / or AUTN needs to be performed before authentication can be performed. Further, when the authentication protocol data is a MAC, the authentication can be performed either before or after the MAC is verified (as performed as part of verifying of the authentication protocol data).

[0059] The communication device 100 could derive the Kmacme_CD in different ways. In some embodiments, the key Kmacme_CD is derived by the USIM of the communication device loo. In some embodiments, the key Kmacme_CD is derived by the ME module of the communication device 100. Further, in some embodiments, the authentication protocol data is by the ME module verified using the key Kmacme_CD.

[0060] As will be disclosed in further detail below with reference to Fig. 6, the communication device 100 might be triggered to perform a new authentication to refresh key material. In this case the network may trigger the UE to perform a new registration request. Therefore, in some embodiments, the communication device IOO is configured to perform (optional) step S112.

[0061] S112: The communication device 100 receives a trigger from the management device 16 for the communication device 100 to send a new registration request message that comprises a GUTI of the communication device 100.

[0062] As will be disclosed in further detail below with reference to Fig. 6, the communication device 100 might derive a new key, here referred to as Kmacme_CD_new, from a random value. Therefore, in some embodiments, the communication device 100 is configured to perform (optional) steps S114 and S116.

[0063] S114: The communication device 100 generates a random value, RAND_ME.

[0064] S116: The communication device 100 derives a new key, Kmacme_CD_new, from the random value RAND_ME and a key, K_AUSF, shared with the server device 300.

[0065] As will be disclosed in further detail below with reference to Fig. 6, the communication device 100 might then send a registration request message. Particularly, in some embodiments, the communication device 100 is configured to perform (optional) step S118. Sn8: The communication device 100 sends a new registration request message comprises the GUTI and the random value RAND_ME to the management device 16.

[0066] Reference is now made to Fig. 3 illustrating a method for authentication between a communication device 100 and a mobile network 12 as performed by the UDM device 200 according to an embodiment.

[0067] S202: The UDM device 200 receives a SUCI of the communication device 100 from a server device 300.

[0068] S206: The UDM device 200 derives a key, Kmacme_UDM, from a shared secret established based on the SUCI. The shared secret is established by a key agreement protocol.

[0069] S208: The UDM device 200 sends the key Kmacme_UDM to the server device 300.

[0070] Embodiments relating to further details of authentication between a communication device 100 and a mobile network 12 as performed by the UDM device 200 will now be disclosed with continued reference to Fig. 3.

[0071] In some aspects, the SUCI is decrypted and verified by the UDM device 200. Therefore, in some embodiments, the UDM device 200 is configured to perform (optional) step S204.

[0072] S204: The UDM device 200 decrypts and verifies the SUCI. Decrypting and verifying the SUCI comprises establishing the shared secret based on the SUCI.

[0073] The SUCI might be decrypted and verified either before or after the UDM device 200 derives the key Kmacme_UDM, but at least before the UDM device 200 sends the key Kmacme_UDM to the server device 300.

[0074] In some examples, the key Kmacme_UDM is sent in conjunction with sending an indication of a selected authentication protocol to the server device 300.

[0075] Reference is now made to Fig. 4 illustrating a method for authentication between a communication device 100 and a mobile network 12 as performed by the server device 300 according to an embodiment. S302: The server device 300 receives an authentication request message for the communication device 100 from a management device 16. The authentication request message comprises a SUCI of the communication device 100.

[0076] S304: The server device 300 sends the SUCI to a UDM device 200.

[0077] S306: The server device 300 receives a key, Kmacme_UDM, from the UDM device 200.

[0078] S308: The server device 300 sends an authentication response message to the management device 16. The authentication response comprises authentication protocol data based on the key Kmacme_UDM.

[0079] Embodiments relating to further details of authentication between a communication device 100 and a mobile network 12 as performed by the server device 300 will now be disclosed with continued reference to Fig. 4.

[0080] In some embodiments, the server device 300 receives the key Kmacme_UDM from the UDM device 200 in conjunction with receiving an indication of a selected authentication protocol from the UDM device 200.

[0081] As disclosed above, there maybe different types of authentication protocol data. In some embodiments, the authentication protocol data is a MAC computed by the server device 300 using the key Kmacme_UDM. For example, in case of an AKA based authentication algorithm, the MAC can be computed based on a random value, RAND, and / or an AUTN. In other embodiments, the authentication protocol data is data encrypted by the server device 300 using Kmacme_UDM. For example, in case of an AKA based authentication algorithm, the authentication protocol data is an encrypted random value, RAND, and / or an encrypted AUTN. The RAND and / or AUTN have / has been encrypted by the server device 300 using the key Kmacme_UD M .

[0082] As will be disclosed in further detail below with reference to Fig. 6, the communication device 100 might be triggered to perform a new authentication to refresh key material. In this case the management device 16 might send a random value RAND_ME, possibly together with other data, to the server device 300. Therefore, in some embodiments, the server device 300 is configured to perform (optional) step S310.

[0083] S310: The server device 300 receives a random value, RAND_ME, associated with the communication device 100 from the management device 16.

[0084] As will be disclosed in further detail below with reference to Fig. 6, the server device 300 derives a new key, Kmacme_AUSF_new. In particular, in some embodiments, the server device 300 is configured to perform (optional) step S312.

[0085] S312: The server device 300 derives a new key, Kmacme_AUSF_new, from the random value RAND_ME and a key, K_AUSF, shared with the server device 300.

[0086] Further aspects of authentication between a communication device 100 and a mobile network 12 as applicable to any of the above disclosed embodiments will be disclosed next.

[0087] For illustrative purposes, the communication device 100 will be represented by a UE, the server device 300 will be represented by an AUSF, and the management device 16 will be represented by an AMF. Further, the keys Kmacme_CD and Kmacme_UDM will both be referred to as Kmacme.

[0088] In general terms, according to the herein disclosed embodiments, the SUCI is bound to the authentication protocol (e.g., the 5G AKA protocol or the EAP-AKA’ protocol).

[0089] In a first example, a key, Kmacme, is derived by the UE and the UDM from the SUCI ECDH shared secret and made available to the ME and AUSF. The binding of the SUCI to the 5G AKA or EAP-AKA’ protocol is achieved by the AUSF computing a MAC on at least one of the AKA protocol data RAND and AUTN. The MAC is computed using Kmacme and the SUCI is bound to the 5G AKA or EAP-AKA’ protocol data through Kmacme (that is derived from the SUCI ECDH shared secret). The MAC is sent in addition to the RAND and AUTN in the authentication request message to the UE. In addition to the existing AKA-based authentication performed by the USIM and parts of 5G AKA or EAP-AKA’ handled by the ME, the ME also verifies the received MAC leveraging Kmacme and the received RAND and AUTN. In addition to any errors in the AKA-based authentication, if the MAC verification fails a MAC error is returned to the network. For authentication procedures where no identity request is sent, e.g., when a temporary identifier such as GUTI is used to identify the ME, a random value can be sent from the UE to the AMF and used as input to the MAC computation. When the authentication is a re-authentication, and where the authentication signaling is already integrity and replay protected, e.g., by the NAS protocol, no additional MAC is required to protect against the aforementioned probing attacks.

[0090] In a second example, no additional MAC is computed and sent in the authentication request message, but instead the AUTN and / or RAND is encrypted using Kmacme. This avoids adding an extra MAC in the exchange between the AUSF and the ME.

[0091] The derivation of Kmacme is generic and may be leveraged in other authentication protocols such as EAP-TLS, etc.

[0092] In some aspects, the authentication between the communication device 100 and the mobile network 12 is separated into an initiating phase and an authentication phase. The initiation phase establishes a key Kmacme, which is used in the authentication phase to detect invalid (RAND, AUTN)-pairs. There are two variants of the authentication phase described when using 5G AKA and EAP-AKA’ procedures, see Figs. 7 and 8. Both of these variants includes a step where the ME verifies a MAC computed using the Kmacme in order to detect an invalid (RAND, AUTN)-pair. The authentication can be triggered in different ways. For example, the ME starts up and performs a registration request to a mobile network (as in Fig. 5). Alternatively, the network requests and triggers a new authentication (as in Fig. 6).

[0093] Further aspects of the initiation phase will be disclosed next with reference to the signaling diagram of Fig. 5.

[0094] S402: The UE generates the SUCI following standard procedures and in addition to the SUCI encryption key and MAC key the UE also derives the key Kmacme from the SUCI ECDH shared secret. The SUCI is either generated by the USIM (steps 8402a - 8402c) or the ME (steps S402d - 8402c):

[0095] 8402a: The ME calls the USIM-Getldentity command.

[0096] 8402b: The USIM application generates the SUCI and derives Kmacme. S402C: The SUCI and Kmacme are provided to the ME.

[0097] S402C: The ME reads USIM application elementary files to obtain SUCI calculation information (e.g.m home MNO public key), SUPI, etc.

[0098] S402d: The request information is returned to the ME.

[0099] S402e: The ME generates the SUCI and derives Kmacme.

[0100] S403: The ME sends a registration request containing the SUCI to the mobile network. The registration request is routed to the AMF.

[0101] S404: The AMF determines from the non-encrypted part of the SUCI the home network of the UE. In case of non-roaming AMF sends an authentication request to the AUSF in its own network. Otherwise, an authentication request is sent to the home network which is routed to the AUSF of that network. The authentication request contains the SUCI and the serving network name (SN-name).

[0102] S405: The AUSF forwards the SUCI and SN-name to the UDM.

[0103] S406: The UDM performs the following:

[0104] 8406a: The UDM verifies and decrypts the SUCI using the home private key available to the UDM to obtain the SUPI. Using the SUPI the UDM checks the corresponding subscription information in its database and selects authentication protocol to be used and optionally prepares authentication data. Examples of such data is an authentication vector for 5G AKA or EAP-AKA’.

[0105] 8406b: The UDM derives the key Kmacme from the SUCI ECDH shared secret derived in step 8406a as part of verifying and decrypting the SUCI.

[0106] S407: The UDM returns (to the AUSF) the selected authentication protocol possibly including authentication data, SUPI, and Kmacme.

[0107] The AUSF is now ready to start the authentication protocol with the UE. The UE and AUSF shares Kmacme that can be used in the authentication protocol.

[0108] The mobile network might periodically perform a new authentication to refresh key material. In this case the network may trigger the UE to perform a new registration request. Since the UE is already registered, such request and the corresponding authentication exchange are encrypted and integrity protected using the established NAS channel between the UE and the AMF. With such a NAS protection the AKA- probing and SUPI-probing attacks are not possible. However, it may still be desirable to establish a fresh shared key Kmacme between the UE and the AUSF for use in the authentication protocol, such that the authentication protocol is the same in all scenarios. One possible procedure for how to derive a fresh shared Kmacme will be disclosed next with reference to the signaling diagram of Fig. 6.

[0109] S501: The AMF triggers the UE to send a new registration request using 5G-GUTI.

[0110] S502: The ME generates a random value RAND_ME (e.g., 128 bits) and derives Kmacme from RAND_ME and KAUSF. For example, the derivation may be performed in a similar way as how KSEAF is derived from KAUSF and SN-name (based on the same KDF with RAND_ME replacing (or in addition to) the SN-name).

[0111] S503: The ME sends a registration request containing 5G-GUTI and RAND_ME to the AMF.

[0112] S504: The AMF sends the RAND_ME and the SUPI corresponding to the 5G-GUTI to the AUSF.

[0113] S505: The AUSF sends the SUPI to the UDM.

[0114] S506: The following is performed:

[0115] 8506a: Using the SUPI the UDM checks the corresponding subscription information in its database and selects authentication protocol to be used and optionally prepares authentication data. Examples of such data is an authentication vector for 5G AKA or EAP-AKA’.

[0116] 8506b: The AUSF derives Kmacme from RAND_ME and KAUSF. This step can be performed by the AUSF before calling UDM in step S506 or after receiving the response from the UDM in step S508.

[0117] S507: The UDM returns (to the AUSF) the selected authentication protocol possibly including authentication data. The NAS counter for replay protection (e.g. NAS COUNT for uplink protecting the registration request) may be used instead of RAND_ME. This avoids changes to the protocol between UE and AMF.

[0118] A first variant of the authentication phase will be disclosed next with reference to the signaling diagram of Fig. 7. In this variant the authentication phase is using the 5G AKA protocol.

[0119] It is assumed that the key Kmacme is known to the ME and may already be known to the AUSF or is obtained in step S607.

[0120] S607: This is the same as above step S407 and step S507 to illustrate that the UDM has selected the 5G AKA authentication protocol and provided the home environment authentication vector 5G HE AV. The SUPI and Kmacme may be returned from the UDM depending on if the initiation of the authentication is according to Fig. 5 or Fig. 6.

[0121] S608: The AUSF performs standard 5G AKA processing to store RES* and compute HXRES* and form the serving environment authentication vector 5G SE AV.

[0122] S609: The AUSF computes MACme using Kmacme on RAND and / or AUTN where e.g. HMAC-SHA-256-128 maybe used as MAC function.

[0123] S610: The AUSF sends an authentication response to AMF containing 5G SE AV and MACme.

[0124] S611: The AMF sends an authentication request to the ME containing MACme and the RAND and AUTN from the 5G SE AV.

[0125] S612: The ME verifies MACme using Kmacme. If the verification fails, the ME responds with a MAC error (same error as if AUTN verification fails) to the AMF.

[0126] S613: Upon successful verification, the ME calls the USIM Authenticate command for the USIM application to perform the authentication using a standard AKA procedure.

[0127] 8613a: The ME provides the RAND and AUTN in the Authenticate command. S6i3b: The USIM verifies AUTN and computes the authentication response RES, Ciphering Key (CK), and Integrity Key (IK).

[0128] 8613c: The RES, CK, and IK are returned to the ME.

[0129] S614: The ME derives KAUSF from CK and IK and SN-name and RES* from RES, CK, IK, and SN-name. The ME sends RES* to the AMF.

[0130] S615: The AMF calculates HRES* from RES* and compare to HXRES* obtained from the 5G SE AV.

[0131] S616: If success, the AMF sends RES* to AUSF.

[0132] S617: The AUSF verifies RES* against the stored XRES*.

[0133] S618: If success, the AUSF returns the result of the authentication and KSEAF to the AMF. If the authentication was initiated by sending a SUCI, the AUSF also returns the SUPI to the AMF.

[0134] S619: The AMF responds with Registration accept to the ME.

[0135] The procedure in Fig. 7 assumes there is always a Kmacme available to the ME and the AUSF in step S608. As explained above, the AKA-probing and SUCI-probing attacks are not possible when a full NAS secure channel is established. Instead of sending a RAND_ME from the ME to the AUSF (via AMF) as in Fig. 5 for Kmacme derivation, it is possible to skip this part and only limit the use Kmacme and MACme to when a SUCI is available.

[0136] In one example of the first variant of the authentication phase, the shared key Kmacme is instead used for encryption and decryption. For example, the RAND and / or the AUTN of the 5G SE AV may be encrypted by the AUSF in step S609. For example, AES-128-CBC maybe used for the encryption. The encrypted RAND and / or AUTN replaces the unencrypted RAND and / or AUTN in 5G SE AV and are sent to the AMF in step S610 and further to the ME in step S611. MACme is not computed and is not sent. In step S612, the ME decrypts the RAND and / or AUTN using Kmacme. The use of encrypted values means there is no need to send MACme in addition to standard 5G AKA data and message formats can be kept. The person skilled in the art understands that besides inputting the SUCI to the MACme, it is possible to include additional context information to the authentication protocol. Such context information is known to the ME and the AMF, and additional context information can be provided by the AMF to the AUSF in the Nausf_UEAuthentication_Authenticate Request message along with the SUCI. The additional context information may be provided as input when the AUSF computes the MACme in step S609. The ME can then include its view of the additional context information when verifying MACme in step S612.

[0137] The second variant of the authentication phase will be disclosed next with reference to the signaling diagram of Fig. 8.

[0138] It is assumed that the key Kmacme is known to the ME and may already be known to the AUSF or is obtained in step S707.

[0139] S707: This is the same as above step S407 and step S507 to illustrate that the UDM has selected the FAP -AKA’ authentication protocol and provided an authentication vector for use with FAP -AKA’. The SUPI and Kmacme may be returned from the UDM depending on if the initiation of the authentication is according to Fig. 5 or Fig. 6.

[0140] S708: The AUSF prepares an EAP-Request / AKA’-Challenge message with data from the FAP -AKA’ AV and with the AT_MAC value set to all-zero.

[0141] S709: The AUSF computes the AT_MAC value following the EAP-AKA’ protocol but with Kauth = Kmacme. For example, the HMAC-SHA-256-128 algorithm can be used. The MAC value is inserted into the prepared EAP-Request / AKA’-Challenge message.

[0142] S710: The AUSF sends an authentication response to the AMF containing the EAP- Request / AKA’-Challenge.

[0143] S711: The AMF sends an authentication request to the ME containing the EAP- Request / AKA’-Challenge.

[0144] S712: The ME verifies the AT_MAC using Kmacme. If the verification fails, the ME responds with a MAC error to the AMF. S713:Upon successful verification, the ME calls the USIM Authenticate command for the USIM application to perform the authentication using a standard AKA procedure.

[0145] 8713a: The ME provides the RAND and AUTN in the Authenticate command.

[0146] 8713b: The USIM verifies the AUTN and computes the authentication response RES, CK, and IK.

[0147] 8713c: The RES, CK, and IK are returned to the ME.

[0148] S714: The ME derives KAUSF from CK and IK and SN-name and prepares an EAP- Response / AKA’-Challenge. The ME sends the EAP-Response / AKA’-Challenge to the AMF.

[0149] S715: The AMF forwards the EAP-Response / AKA’-Challenge to the AUSF.

[0150] S716: The AUSF verifies the EAP-Response / AKA’-Challenge.

[0151] S717: If success, additional messages are optionally exchanged between the ME and the AUSF in further FAP -AKA’ rounds.

[0152] S718: The AUSF sends an EAP-Success message concatenated with KSEAF to the AMF that sends RES* to the AUSF. If the authentication was initiated by sending a SUCI, the AUSF also returns the SUPI to the AMF.

[0153] S719: The AMF responds with Registration accept to the ME containing the EAP- Success message.

[0154] In one example of the second variant of the authentication phase, the shared key Kmacme is instead used for encryption and decryption. For example, the RAND and / or the AUTN of the FAP -AKA’ AV may be encrypted by the AUSF in step S708. For example, AES-128-CBC maybe used for the encryption. The encrypted RAND and / or AUTN are used instead of unencrypted RAND and / or AUTN when preparing the EAP-Request / AKA’-Challenge and the AT_MAC is computed according to the standard FAP -AKA’ protocol (i.e., step S709 is skipped). In step S712, the ME decrypts the encrypted RAND and / or AUTN from the received EAP-Request / AKA’- Challenge using Kmacme. Inputting additional context information in the MACme computations when using the EAP-AKA’ protocol is possible in a similar manner as described for 5G AKA. The additional context information may for example be included as message specific data in the AT_MAC computation and verification.

[0155] Fig. 8 schematically illustrates, in terms of a number of functional units, the components of a communication device 100 according to an embodiment. Processing circuitry no is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1510a (as in Fig. 15), e.g. in the form of a storage medium 130. The processing circuitry no may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

[0156] Particularly, the processing circuitry 110 is configured to cause the communication device 100 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 130 may store the set of operations, and the processing circuitry no maybe configured to retrieve the set of operations from the storage medium 130 to cause the communication device 100 to perform the set of operations. The set of operations maybe provided as a set of executable instructions. Thus the processing circuitry 110 is thereby arranged to execute methods as herein disclosed.

[0157] The storage medium 130 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

[0158] The communication device 100 may further comprise a communications (comm.) interface 120 for communications with other entities, functions, nodes, and devices, as in Fig. 1, in order for the communication device 100 to implement the embodiments as disclosed herein. As such the communications interface 120 may comprise one or more transmitters and receivers, comprising analogue and digital components.

[0159] The processing circuitry no controls the general operation of the communication device 100 e.g. by sending data and control signals to the communications interface 120 and the storage medium 130, by receiving data and reports from the communications interface 120, and by retrieving data and instructions from the storage medium 130. Other components, as well as the related functionality, of the communication device 100 are omitted in order not to obscure the concepts presented herein.

[0160] Fig. 9 schematically illustrates, in terms of a number of functional modules, the components of a communication device 100 according to an embodiment. The communication device 100 of Fig. 9 comprises a number of functional modules; a generate module 110a configured to perform step S102, a derive module nob configured to perform step S104, a send module 110c configured to perform step S106, a receive module nod configured to perform step S108, and an authenticate (Auth.) module noe configured to perform step S110. The communication device 100 of Fig. 9 may further comprise a number of optional functional modules, such as any of a receive module nof configured to perform step S112, a generate module nog configured to perform step S114, a derive module noh configured to perform step S116, and a send module noi configured to perform step S118.

[0161] In general terms, each functional module 110a: noi maybe implemented in hardware or in software. Preferably, one or more or all functional modules 110a: noi maybe implemented by the processing circuitry 110, possibly in cooperation with the communications interface 120 and the storage medium 130. The processing circuitry no may thus be arranged to from the storage medium 130 fetch instructions as provided by a functional module 110a: noi and to execute these instructions, thereby performing any steps of the communication device 100 as disclosed herein.

[0162] Fig. 10 schematically illustrates, in terms of a number of functional units, the components of a UDM device 200 according to an embodiment. Processing circuitry 210 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1510b (as in Fig. 15), e.g. in the form of a storage medium 230. The processing circuitry 210 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

[0163] Particularly, the processing circuitry 210 is configured to cause the UDM device 200 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 230 may store the set of operations, and the processing circuitry 210 maybe configured to retrieve the set of operations from the storage medium 230 to cause the UDM device 200 to perform the set of operations. The set of operations maybe provided as a set of executable instructions. Thus the processing circuitry 210 is thereby arranged to execute methods as herein disclosed.

[0164] The storage medium 230 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

[0165] The UDM device 200 may further comprise a communications interface 220 for communications with other entities, functions, nodes, and devices, as in Fig. 1, in order for the UDM device 200 to implement the embodiments as disclosed herein. As such the communications interface 220 may comprise one or more transmitters and receivers, comprising analogue and digital components.

[0166] The processing circuitry 210 controls the general operation of the UDM device 200 e.g. by sending data and control signals to the communications interface 220 and the storage medium 230, by receiving data and reports from the communications interface 220, and by retrieving data and instructions from the storage medium 230. Other components, as well as the related functionality, of the UDM device 200 are omitted in order not to obscure the concepts presented herein.

[0167] Fig. 11 schematically illustrates, in terms of a number of functional modules, the components of a UDM device 200 according to an embodiment. The UDM device 200 of Fig. 11 comprises a number of functional modules; a receive module 210a configured to perform step S202, a derive module 210c configured to perform step S206, and a send module 2iod configured to perform step S208. The communication device 100 of Fig. 9 may further comprise a number of optional functional modules, such as a decrypt module 210b configured to perform step S204.

[0168] In general terms, each functional module 2ioa:2iod maybe implemented in hardware or in software. Preferably, one or more or all functional modules 210a: 2iod maybe implemented by the processing circuitry 210, possibly in cooperation with the communications interface 220 and the storage medium 230. The processing circuitry 210 may thus be arranged to from the storage medium 230 fetch instructions as provided by a functional module 2ioa:2iod and to execute these instructions, thereby performing any steps of the UDM device 200 as disclosed herein.

[0169] Fig. 12 schematically illustrates, in terms of a number of functional units, the components of a server device 300 according to an embodiment. Processing circuitry 310 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1510c (as in Fig. 15), e.g. in the form of a storage medium 330. The processing circuitry 310 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

[0170] Particularly, the processing circuitry 310 is configured to cause the server device 300 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 330 may store the set of operations, and the processing circuitry 310 maybe configured to retrieve the set of operations from the storage medium 330 to cause the server device 300 to perform the set of operations. The set of operations maybe provided as a set of executable instructions. Thus the processing circuitry 310 is thereby arranged to execute methods as herein disclosed.

[0171] The storage medium 330 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

[0172] The server device 300 may further comprise a communications interface 320 for communications with other entities, functions, nodes, and devices, as in Fig. 1, in order for the server device 300 to implement the embodiments as disclosed herein. As such the communications interface 320 may comprise one or more transmitters and receivers, comprising analogue and digital components.

[0173] The processing circuitry 310 controls the general operation of the server device 300 e.g. by sending data and control signals to the communications interface 320 and the storage medium 330, by receiving data and reports from the communications interface 320, and by retrieving data and instructions from the storage medium 330. Other components, as well as the related functionality, of the server device 300 are omitted in order not to obscure the concepts presented herein. Fig. 14 schematically illustrates, in terms of a number of functional modules, the components of a server device 300 according to an embodiment. The server device 300 of Fig. 14 comprises a number of functional modules; a receive module 310a configured to perform step S302, a send module 310b configured to perform step S304, a receive module 310c configured to perform step S306, and a send module 3iod configured to perform step S308. The communication device 100 of Fig. 9 may further comprise a number of optional functional modules, such as a receive module 3ioe configured to perform step S310, a derive module 3iof configured to perform step S312.

[0174] In general terms, each functional module 3ioa:3iof maybe implemented in hardware or in software. Preferably, one or more or all functional modules 3ioa:3iof may be implemented by the processing circuitry 310, possibly in cooperation with the communications interface 320 and the storage medium 330. The processing circuitry 310 may thus be arranged to from the storage medium 330 fetch instructions as provided by a functional module 3ioa:3iof and to execute these instructions, thereby performing any steps of the server device 300 as disclosed herein.

[0175] The UDM device 200 and / or server device 300 maybe provided as a standalone device or as a part of at least one further device. For example, the UDM device 200 and / or server device 300 maybe provided in a node of the core network 14a, 14b. Alternatively, functionality of the communication device 100 maybe distributed between at least two devices, or nodes. Thus, a first portion of the instructions performed by the UDM device 200 and / or server device 300 may be executed in a first device, and a second portion of the of the instructions performed by the UDM device 200 and / or server device 300 maybe executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the UDM device 200 and / or server device 300 maybe executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by a UDM device 200 and / or server device 300 residing in a cloud computational environment. Therefore, although a single processing circuitry 210, 310 is illustrated in Figs. 11 and 13 the processing circuitry 210, 310 maybe distributed among a plurality of devices, or nodes. The same applies to the functional modules 2ioa:2iod, 3ioa:3iof of Figs. 12 and 14 and the computer programs 1520b, 1520c of Fig. 15. Fig. 15 shows one example of a computer program product 1510a, 1510b, 1510c comprising computer readable means 1530. On this computer readable means 1530, a computer program 1520a can be stored, which computer program 1520a can cause the processing circuitry no and thereto operatively coupled entities and devices, such as the communications interface 120 and the storage medium 130, to execute methods according to embodiments described herein. The computer program 1520a and / or computer program product 1510a may thus provide means for performing any steps of the communication device 100 as herein disclosed. On this computer readable means 1530, a computer program 1520b can be stored, which computer program 1520b can cause the processing circuitry 210 and thereto operatively coupled entities and devices, such as the communications interface 220 and the storage medium 230, to execute methods according to embodiments described herein. The computer program 1520b and / or computer program product 1510b may thus provide means for performing any steps of the UDM device 200 as herein disclosed. On this computer readable means 1530, a computer program 1520c can be stored, which computer program 1520c can cause the processing circuitry 310 and thereto operatively coupled entities and devices, such as the communications interface 320 and the storage medium 330, to execute methods according to embodiments described herein. The computer program 1520c and / or computer program product 1510c may thus provide means for performing any steps of the server device 300 as herein disclosed.

[0176] In the example of Fig. 15, the computer program product 1510a, 1510b, 1510c is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product 1510a, 1510b, 1510c could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory or a Flash memory, such as a compact Flash memory. Thus, while the computer program 1520a, 1520b, 1520c is here schematically shown as a track on the depicted optical disk, the computer program 1520a, 1520b, 1520c can be stored in any way which is suitable for the computer program product 1510a, 1510b, 1510c. The inventive concept has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the inventive concept, as defined by the appended patent claims.

Claims

CLAIMS1. A method for authentication between a communication device (100) and a mobile network (12), wherein the method is performed by the communication device (100), and wherein the method comprises: generating (S102) a Subscription Concealed Identifier, SUCI; deriving (S104) a key, Kmacme_CD, from a shared secret established as part of generating the SUCI, the shared secret being established by a key agreement protocol; sending (S106) a registration request message comprising the SUCI to the mobile network (12); receiving (S108) an authentication request message from a management device (16) in the mobile network (12), wherein the authentication request comprises authentication protocol data provided by a server device (300), the authentication protocol data being based on a key, Kmacme_UDM, of the server device (300); and performing (S110) an authentication procedure in conjunction with verifying the authentication protocol data using the key Kmacme_CD.

2. The method according to claim 1, wherein the authentication protocol data is a Message Authentication Code, MAC, having been computed using the key Kmacme_UDM.

3. The method according to claim 2, wherein the MAC is computed based on a random value, RAND, and / or an Authentication Token, AUTN.

4. The method according to claim 1, wherein the authentication protocol data is an encrypted random value, RAND, and / or an encrypted Authentication Token, AUTN, the RAND and / or AUTN having been encrypted using the key Kmacme_UDM, and wherein verifying the authentication protocol data comprises using the key Kmacme_CD to decrypt the RAND and / or AUTN.

5. The method according to claim 1, wherein the communication device (ioo) comprises a Universal Subscriber Identity Module, USIM, and wherein the key Kmacme_CD is derived by the USIM.

6. The method according to claim 1, wherein the communication device (ioo) comprises a Mobile Equipment, ME, module, and wherein the key Kmacme_CD is derived by the ME module.

7. The method according to claim 1, wherein the communication device (100) comprises a Mobile Equipment, ME, module, and wherein the authentication protocol data is verified using the key Kmacme_CD by the ME module.

8. The method according to claim 1, wherein the method further comprises: receiving (S112) a trigger from the management device (16) for the communication device (100) to send a new registration request message comprising a Globally Unique Temporary Identifier, GUTI, of the communication device (100).

9. The method according to claim 8, wherein the method further comprises: generating (S114) a random value, RAND_ME; and deriving (S116) a new key, Kmacme_CD_new, from the random value RAND_ME and a key, K_AUSF, shared with the server device (300).

10. The method according to claim 9, wherein the method further comprises: sending (S118) a new registration request message comprising the GUTI and the random value RAND_ME to the management device (16).

11. A method for authentication between a communication device (100) and a mobile network (12), wherein the method is performed by a Unified Data Management, UDM, device (200), and wherein the method comprises: receiving (S202) a Subscription Concealed Identifier, SUCI, of the communication device (100) from a server device (300); deriving (S206) a key, Kmacme_UDM, from a shared secret established based on the SUCI, the shared secret being established by a key agreement protocol; andsending (S208) the key Kmacme_UDM to the server device (300).

12. The method according to claim 11, wherein the method further comprises: decrypting and verifying (S204) the SUCI, wherein the decrypting and verifying the SUCI comprises establishing the shared secret based on the SUCI.

13. The method according to claim 11, wherein the key Kmacme_UDM is sent in conjunction with sending an indication of a selected authentication protocol to the server device (300).

14. A method for authentication between a communication device (100) and a mobile network (12), wherein the method is performed by a server device (300), and wherein the method comprises: receiving (S302) an authentication request message for the communication device (100) from a management device (16), the authentication request message comprising a Subscription Concealed Identifier, SUCI, of the communication device (100); sending (S304) the SUCI to a Unified Data Management, UDM, device (200); receiving (S306) a key, Kmacme_UDM, from the UDM device (200); and sending (S308) an authentication response message to the management device (16), the authentication response comprising authentication protocol data based on the key Kmacme_UDM.

15. The method according to claim 14, wherein the key Kmacme_UDM is received from the UDM device (200) in conjunction with the server device (300) receiving an indication of a selected authentication protocol from the UDM device (200).

16. The method according to claim 14, wherein the authentication protocol data is a Message Authentication Code, MAC, computed by the server device (300) using the key Kmacme_UDM.

17. The method according to claim 16, wherein the MAC is computed based on a random value, RAND, and / or an Authentication Token, AUTN.

18. The method according to claim 14, wherein the authentication protocol data is an encrypted random value, RAND, and / or an encrypted Authentication Token, AUTN, the RAND and / or AUTN having been encrypted by the server device (300) using the key Kmacme_UDM.

19. The method according to claim 14, wherein the method further comprises: receiving (S310) a random value, RAND_ME, associated with the communication device (100) from the management device (16).

20. The method according to claim 19, wherein the method further comprises: deriving (S312) a new key, Kmacme_AUSF_new, from the random value RAND_ME and a key, K_AUSF, shared with the server device (300).

21. A communication device (100) for authentication between the communication device (100) and a mobile network (12), the communication device (100) comprising processing circuitry (no), the processing circuitry being configured to cause the communication device (100) to: generate a Subscription Concealed Identifier, SUCI; derive a key, Kmacme_CD, from a shared secret established as part of generating the SUCI, the shared secret being established by a key agreement protocol; send a registration request message comprising the SUCI to the mobile network (12); receive an authentication request message from a management device (16) in the mobile network (12), wherein the authentication request comprises authentication protocol data provided by a server device (300), the authentication protocol data being based on a key, Kmacme_UDM, of the server device (300); and perform an authentication procedure in conjunction with verifying the authentication protocol data using the key Kmacme_CD.

22. A Unified Data Management, UDM, device (200) for authentication between a communication device (100) and a mobile network (12), the UDM device (300) comprising processing circuitry (210), the processing circuitry being configured to cause the UDM device (300) to: receive a Subscription Concealed Identifier, SUCI, of the communication device (100) from a server device (300); derive a key, Kmacme_UDM, from a shared secret established based on the SUCI, the shared secret being established by a key agreement protocol; and send the key Kmacme_UDM to the server device (300).

23. A server device (300) for authentication between a communication device (100) and a mobile network (12), the server device (300) comprising processing circuitry (310), the processing circuitry being configured to cause the server device (300) to: receive an authentication request message for the communication device (100) from a management device (16), the authentication request message comprising a Subscription Concealed Identifier, SUCI, of the communication device (100); send the SUCI to a Unified Data Management, UDM, device (200); receive a key, Kmacme_UDM, from the UDM device (200); and send an authentication response message to the management device (16), the authentication response comprising authentication protocol data based on the key Kmacme_UD M .

24. A computer program (1520a) for authentication between a communication device (100) and a mobile network (12), the computer program comprising computer code which, when run on processing circuitry (no) of the communication device (100), causes the communication device (100) to: generate (S102) a Subscription Concealed Identifier, SUCI;derive (S104) a key, Kmacme_CD, from a shared secret established as part of generating the SUCI, the shared secret being established by a key agreement protocol; send (S106) a registration request message comprising the SUCI to the mobile network (12); receive (S108) an authentication request message from a management device (16) in the mobile network (12), wherein the authentication request comprises authentication protocol data provided by a server device (300), the authentication protocol data being based on a key, Kmacme_UDM, of the server device (300); and perform (S110) an authentication procedure in conjunction with verifying the authentication protocol data using the key Kmacme_CD.

25. A computer program (1520b) for authentication between a communication device (100) and a mobile network (12), the computer program comprising computer code which, when run on processing circuitry (210) of a Unified Data Management, UDM, device (200), causes the UDM device (300) to: receive (S202) a Subscription Concealed Identifier, SUCI, of the communication device (100) from a server device (300); derive (S206) a key, Kmacme_UDM, from a shared secret established based on the SUCI, the shared secret being established by a key agreement protocol; and send (S208) the key Kmacme_UDM to the server device (300).

26. A computer program (1520c) for authentication between a communication device (100) and a mobile network (12), the computer program comprising computer code which, when run on processing circuitry (310) of a server device (300), causes the server device (300) to: receive (S302) an authentication request message for the communication device (100) from a management device (16), the authentication request message comprising a Subscription Concealed Identifier, SUCI, of the communication device (100);send (S304) the SUCI to a Unified Data Management, UDM, device (200); receive (S306) a key, Kmacme_UDM, from the UDM device (200); and send (S308) an authentication response message to the management device (16), the authentication response comprising authentication protocol data based on the key Kmacme_UDM.

27. A computer program product (1510a, 1510b, 1510c) comprising a computer program (1520a, 1520b, 1520c) according to at least one of claims 24, 25 and 26, and a computer readable storage medium (1530) on which the computer program is stored.

Images