Attack resistant authentication

Abstract

This disclosure relates to authenticating a subscriber device with a network device of a communication network. The subscriber device calculates a secret key by encrypting a subscriber challenge with a public key of the network device; calculates a subscriber challenge tag; and sends a request for authentication to the network device. The network device decrypts the one or more ciphers from the request to determine the secret key and the subscriber challenge; verifies the subscriber challenge using the subscriber challenge tag; upon verification, calculates a session key based on a network challenge and the subscriber challenge; calculates a network challenge tag; and sends a response to the request. The subscriber device then calculates the session key from the response; verifies that the response data corresponds to the request for authentication sent to the network device; and upon verification, transmits a notification to authenticate the subscriber device with the network device.

Description

"Attack resistant authentication" Cross-Reference to Related Applications

[0001] The present application claims priority from Australian Provisional Patent Application No 2024902698 filed on 29 August 2024 and Australian Patent Application No 2024259751 filed on 6 November 2024, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0002] This disclosure relates to authenticating a subscriber device with a network device of a communication network. Background

[0003] Communication system such as wireless communication systems (including the Fifth Generation (5G) mobile communication system) use authentication protocols to ensure the security of the network and the privacy of the user of the system. Some authentication protocols meet security aspects such as mutual authentication, user privacy, and key secrecy, which protects users from passive attackers. However, these authentication protocols have vulnerabilities related to subscriber privacy when facing active attackers. Further, these authentication methods suffer from other inefficiencies, such as the sequence number-based replay attack prevention method, which can be exploited by active attackers.

[0004] Some authentication protocols attempt to address these issues, but they fail to achieve all the security properties in a single protocol, including perfect forward secrecy (PFS), sequence number-less replay attack prevention mechanism, and active attack prevention. Moreover, these authentication protocols struggle with maintaining compatibility with the current technology and infrastructure, which limits the ability to implement these protocols.

[0005] Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the fieldrelevant to the present disclosure as it existed before the priority date of each of the appended claims.

[0006] Throughout this specification the word “comprise”, or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps. Summary

[0007] Disclosed herein are a system and methods for authenticating a subscriber device with a network device of a communication network. Embodiments of the system and methods may involve generating and transmitting challenges and responses between the subscriber device and the network device. Embodiments of the system and methods may further involve calculating a session key based on the challenges. Embodiments of the system and methods may further involve verifying tags to verifying the challenges and responses transmitted between the subscriber device and the network device.

[0008] According to the present disclosure, there is provided a method for authenticating a subscriber device with a network device of a communication network, the method comprising: by the subscriber device: calculating a secret key by encrypting a subscriber challenge with a public key of the network device; calculating a subscriber challenge tag based on the subscriber challenge and the secret key; and sending a request for authentication to the network device, the request comprising the subscriber challenge tag and one or more ciphers determined from the subscriber challenge; by the network device: decrypting the one or more ciphers using a private key of the network device to determine the secret key and the subscriber challenge; verifying the subscriber challenge using the subscriber challenge tag with the secret key; and upon verification, calculating a session key based on a network challenge and the subscriber challenge, and calculating a network challenge tag based on the network challenge and the session key;sending a response to the request comprising the network challenge tag and response data that is based on the network challenge; by the subscriber device: calculating the session key based on the response data and the subscriber challenge; verifying that the response data corresponds to the request for authentication sent to the network device, using the network challenge tag with the session key; and upon verification, transmitting a notification to the network device to authenticate the subscriber device with the network device.

[0009] It is an advantage to calculate the session key based on the network challenge and the subscriber challenge, as the session key used by the subscriber device and the network device are bound by the subscriber’s initial authentication request (i.e., the subscriber challenge), which enhances security. Further, it is an advantage to verify that the response data corresponds to the request for authentication sent to the network device as this verifies the authenticity and integrity of the response data, confirms the session key and tells the subscriber that the network challenge is based on the original authentication request. As such, this tells the subscriber device that the response from the network device is based on the current session and the verification can prevent active attackers.

[0010] In some embodiments, the method further comprises: by the subscriber device, upon verifying the response data, calculating a key confirmation tag by hashing the response data with the session key calculated by the subscriber device, wherein the notification comprises the key confirmation tag.

[0011] In some embodiments, the method further comprises: by the network device, verifying the session key of the subscriber device using the key confirmation tag with the session key of the network device and the response data; and upon verification, authenticating the subscriber device with the network device.

[0012] In some embodiments, response data comprises the network challenge, and the subscriber device and the network device calculate the session key by applying a cryptographic function to the network challenge and the subscriber challenge.

[0013] In some embodiments, calculating the subscriber challenge tag by the subscriber device comprises applying a cryptographic function to the subscriber challenge and the secret key; and calculating the network challenge tag by the network device comprises applying a cryptographic function to the network challenge and the session key.

[0014] In some embodiments, the method further comprises: calculating one or more keys by encrypting the subscriber challenge using a different cryptographic function for each of the one or more keys, wherein the session key is calculated using the one or more keys.

[0015] In some embodiments, the method further comprises: by the subscriber device, generating a network challenge response tag; by the network device, generating an expected network challenge response tag; verifying the network challenge response tag using the expected network challenge response tag; and upon verification, providing the network device with access to the notification from the subscriber device.

[0016] In some embodiments, the method further comprises by the network device, generating a subscriber challenge response tag, wherein the expected network challenge response tag is generated from the subscriber challenge response tag; and by the subscriber device, generating an expected subscriber challenge response tag, wherein the network challenge response tag is generated from the expected subscriber challenge response tag.

[0017] In some embodiments, the method further comprises, by the network device, calculating an encrypted network challenge by encrypting the network challenge and calculating a network challenge key by encrypting the network challenge with one of the one or more ciphers.

[0018] In some embodiments, the response data comprises the encrypted network challenge, and the subscriber device and the network device calculate the session key by applying a cryptographic function to the network challenge key and the secret key.

[0019] In some embodiments, calculating the encrypted network challenge and calculating a network challenge key is based on Diffie–Hellman (DH) key exchange protocol.

[0020] In some embodiments, communication between the subscriber device and the network device occurs via a service network.

[0021] In some embodiments, the method further comprises: by the service network: receiving the response data and the session key from the network device; receiving a key confirmation tag from the subscriber device; verifying the session key of the subscriber device using the key confirmation tag with the session key of the network device and the response data; and upon verification, providing the network device with access to the notification from the subscriber device.

[0022] In some embodiments, the subscriber challenge tag is based on encrypting the subscriber challenge with the secret key and a subscriber secret key, the subscriber secret key being indicative of a subscription to services provided by the network device.

[0023] In some embodiments, encrypting is based on elliptic-curve cryptography.

[0024] According to the present disclosure, there is provided a method for authenticating a subscriber device with a network device of a communication network, as performed by the subscriber device, the method comprising: calculating a secret key by encrypting a subscriber challenge with a public key of the network device; calculating a subscriber challenge tag based on the subscriber challenge and the secret key; sending a request for authentication to the network device, the request comprising the subscriber challenge tag and one or more ciphers determined from the subscriber challenge; receiving a response to the request from the network device, the response comprising a network challenge tag and response data that is based on a network challenge; calculating a session key based on the response data and the subscriber challenge; verifying that the response data corresponds to the request for authentication sent to the network device, using the network challenge tag with the session key; and upon verification, transmitting a notification to the network device to authenticate the subscriber device with the network device.

[0025] According to the present disclosure, there is provided a method for authenticating a subscriber device with a network device of a communication network, as performed by the network device, the method comprising: receiving a request for authentication from the subscriber device, the request comprising a subscriber challenge tag and one or more ciphers determined from a subscriber challenge; decrypting the one or more ciphers using a private key of the network device to determine a secret key and the subscriber challenge; verifying the subscriber challenge using the subscriber challenge tag with the secret key; upon verification, calculating a session key based on a network challenge and the subscriber challenge, and calculating a network challenge tag based on the network challenge and the session key; and sending a response to the request comprising the network challenge tag and response data that is based on the network challenge; and authenticating the subscriber device upon receiving a notification from the subscriber device based on the response.

[0026] According to the present disclosure, there is provided software that, when executed by a computer, causes the computer to perform any of the previously described methods.

[0027] According to the present disclosure, there is provided a system for authenticating a subscriber device with a network device of a communication network, the system comprising one or more processors configured to any of the previously described methods.

[0028] Optional features provided in relation to first method, equally apply as optional features to the other methods, software and the system. Brief Description of Drawings

[0029] An example will be described with reference to the following drawings:

[0030] Fig.1 illustrates an example embodiment of a system for authenticating a subscriber device with a network device of a communication network.

[0031] Fig.2 illustrates an example embodiment of a method for authenticating a subscriber device with a network device of a communication network, as performed by a subscriber device.

[0032] Fig.3 illustrates an example embodiment of a method for authenticating a subscriber device with a network device of a communication network, as performed by a network device.

[0033] Fig.4 illustrates a high-level overview of the 5G-AKA protocol.

[0034] Fig.5 provides a high-level overview of a preferred first embodiment of the disclosed methods.

[0035] Fig.6 provides a high-level overview of a preferred second embodiment of the disclosed methods.

[0036] Fig.7 presents Table 3, which presents a comparison of the computation costs betweenthe disclosed methods and 5G-AKA and 5G-AKA ' .Description of Embodiments

[0037] This disclosure provides a system and methods directed towards an authentication protocol that addresses issues with some authentication protocols while maintaining compatibility with technology and infrastructure (such as service networks and existing SIM cards, in the case of a mobile communication network). The methods described herein are secure against passive and active attackers, and support all security aspects specified in some standards for wireless communication, as well as the additional underspecified security aspects.

[0038] The system and methods disclosed herein are applicable for any wireless communication networks including, but not limited to, the 5G network (e.g., the Fifth- Generation (5G) mobile network technology), the 6G network (e.g., the Sixth-Generation (5G) mobile network technology), Wi-Fi, WiMax, and satellite networks. However, the system and methods disclosed herein are especially applicable to mobile network communication. In particular, the system and methods disclosed herein address limitations with authentication protocols in the 5G mobile network technology.

[0039] To maintain the security and privacy of 5G users, the Third Generation Partnership Project (3GPP) group (https: / / www.3gpp.org / ) has been proposing various security standardsrelated to 5G. One such standard is the 5G-AKA (5G-Authentication and Key Agreement), outlined in the 3GPP Technical Specification (TS) 33.501 (3GPP. Security Architecture and Procedures for 5G System TS33.501 v18.5.0. Technical Report, The 3rd Generation Partnership Project, 2024, https: / / portal.3gpp.org / desktopmodules / Specifications / SpecificationDetails.aspx?specificationId =3169).

[0040] 5G-AKA involves, at least, a subscriber device and the network device (e.g., home network), and the protocol is based on a challenge-response method where the network device sends a challenge to the subscriber device. The user of the subscriber device may be the mobile user connected to the 5G network via a Universal Integrated Circuit Card (UICC), as referred to as a SIM card, for example. The network device may represent the base station of a network carrier and the subscriber’s carrier, respectively. The 3GPP standardized 5G-AKA provides security guarantees to both subscribers (5G mobile users) and carriers, including mutual authentication and the establishment of a secure session key. These measures ensure secure data communication for subscribers.

[0041] Extensive security analysis demonstrate that 5G-AKA is designed to provide security against passive attackers. However, an active attacker can compromise subscriber privacy using different methods. Furthermore, there are underspecified security aspects and weaknesses inherited from its predecessor AKA protocols. These weaknesses include a lack of security against active attackers, the absence of key confirmation, and an inefficient sequence number- based replay attack prevention mechanism. As such, several attack scenarios aimed at compromising subscriber privacy are particularly concerning, especially those focusing on capturing and replaying messages from targeted subscribers. The idea used by the attacks is to distinguish the responses elicited from the targeted subscriber and other subscribers to the same replayed messages. This enables attackers to differentiate them, thus breaching the privacy of the targeted subscriber.

[0042] Two primary reasons in the 5G-AKA protocol may be the cause of its lack of resistance to active attackers. Firstly, there is a lack of binding between the subscriber’s initial authentication request (which may contain an encrypted user identifier) and the corresponding challenge of network device. As such, a subscriber device cannot ascertain whether the challenge of the network device is linked to its most recent authentication request. Secondly, the 5G-AKA relies on a freshness check to maintain the current session, which may be referred to as sequencenumber-based replay attack prevention mechanism. However, the freshness check relies on a sequence number maintained by both the subscriber device and the network device, which can be exploited by an active attacker.

[0043] The disclosed methods address the above-mentioned issues in the 5G-AKA protocol while ensuring that all security aspects previous discussed are met. Unlike the 5G-AKA protocol, which relies solely on a network device sending the challenge and the subscriber’s corresponding response, the disclosed methods incorporate an additional challenge message from the subscriber device to the network device during the initial authentication request. These challenge and response messages are mutually bound using random numbers, reducing the need for a sequence number-based replay attack prevention mechanism for freshness checking. This, in turn, also reduces the complexity of the disclosed methods compared to the 5G-AKA protocol.

[0044] The addition of the subscriber challenge provides a binding between the subscriber’s initial authentication request (which may contain an encrypted user identifier) and the corresponding challenge of network device. In this way, the subscriber device can also verify that the challenge received from the network device is based on its initial request for authentication to enhance the security of the connection between the subscriber device and the network device. More specifically, the session keys used by the subscriber device and the network device may be based on both the subscriber challenge and the network challenge, which further binds the subscriber challenge and network challenge and provides further security to the connection between the subscriber device and the network device.

[0045] The system and methods disclosed herein address the limitation of the 5G-AKA and may be considered to be a new AKA protocol based on the core concepts of the 5G-AKA protocol, addressing most existing issues while maintaining compatibility with existing SIM cards and service networks. Further, as the disclosed system and methods provide additional security aspects, the disclosed system and methods may be the foundation for future technology and infrastructure (such as the Sixth Generation (6G) mobile communication system).

[0046] Some embodiments of the methods described herein can also be extended to support perfect forward secrecy (PFS) with additional computationally lightweight cryptographic operations. PFS is a cryptographic feature that ensures the security of session keys even if the long-term secret key (i.e., a subscriber secret key and subscriber carrier’s private key) is compromised. In these embodiments, an ephemeral Diffie-Hellman key exchange method maybe efficiently introduced along with the modified challenge-response process. This extension supports all the security aspects, including resistance to both passive and active attacks.

[0047] As will be discussed, a thorough formal security analysis was conducted using an automated formal analysis tool. This formal analysis demonstrates that the disclosed system and methods (and embodiments thereof) support all the security aspects outlined in 3GPP TS 33.501, including mutual authentication, secrecy, and active attack resistance. Additionally, the disclosed system and methods were compared with existing authentication method in terms of computation and communication costs. System

[0048] Fig.1 illustrates an example embodiment of a system 100 for authenticating subscriber device 110 with network device 120 of a communication network. Fig.1 is one example of a configuration of system 100. However, system 100 is not strictly limited to this configuration and this may be one possible embodiment of system 100. It is noted that system 100 of Fig.1 is only meant to illustrate an example system which is capable of performing the disclosed methods. It is noted that system 100 is compatible of performing some authentication methods other than the disclosed methods, such as the 5G-AKA protocol.

[0049] System 100 comprises subscriber device 110, which performs the methods disclosed herein or part thereof. Subscriber device 110 is associated with user 111, whom may be a subscriber of the communication network. Subscriber device 110 may also be referred to as user equipment and hence, may be labelled using “UE” in this disclosure. Subscriber device 110 may be smartphone, computer, tablet, a server device, or any other similar device. Subscriber device 110 may also be a field-programmable gate array (FPGA), an application specific integrated circuits (ASIC), or one or more single board computers, such as a Raspberry Pi or an Arduino. Subscriber device 110 comprises processor 112, which may be configured to perform the methods described in this disclosure or part thereof. Subscriber device 110 comprises memory 113, which comprises non-volatile memory 114 and / or volatile memory 115. Processor 112 may communicate with memory 113 by communicating with non-volatile memory 114 and / or volatile memory 115. Non-volatile memory 114 is a non-transitory computer readable medium and may be an optical disk drive, hard disk drive, solid-state drive, flash memory, storage server, cloud storage or another equivalent type of memory. Volatile memory 115 may be cache, RAM, or another equivalent type of memory.

[0050] System 100 also comprises network device 120, which may be referred to as a home network and hence, may be labelled using “HN” in this disclosure. Network device 120 may be the base station of the carrier of user 111, for example. Network device 120 may be smartphone, computer, tablet, a server device, or any other similar device. Network device 120 may also be a field-programmable gate array (FPGA), an application specific integrated circuits (ASIC), or one or more single board computers, such as a Raspberry Pi or an Arduino. Similar to subscriber device 110, network device 120 comprises processor 122, which may be configured to perform the methods described in this disclosure or part thereof. Network device 120 comprises memory 123, which comprises non-volatile memory 124 and / or volatile memory 125. Subscriber device 110 and parts thereof may be similar or perform similar operations to network device 120 and parts thereof. For example, processor 112 and memory 113 may be similar or perform similar operations to processor 122 and memory 123.

[0051] Memory 113, 123 may store data to be retrieved for later use. For example, memory 113, 123 may store received messages, cryptographic keys including public, private, session and secret keys, tags including authentication tags, hashes, hash values or the like. In essence, memory 113, 123 may store any data used by processor 112, 122, respectively, when performing the methods described herein. The data thereof may be stored in memory 113 in the form of a JavaScript Object Notation (JSON) format file, Packet Capture (PCAP) file, XML format file or another equivalent data format file.

[0052] Software, that is, an executable program stored on non-volatile memory 114, 124 causes processor 112, 122, respectively to perform methods for authenticating subscriber device 110 with network device 120. While the singular of “processor” is used herein, it is meant to also encompass multiple processors that are individually or together configured (e.g., programmed) to perform the methods disclosed herein. As such, processor 112, 122 may refer to multiple central processing units (CPUs) and / or graphical processing units (GPUs) that are configured to collectively perform the methods disclosed herein.

[0053] Once executed, software may cause processor 112 to calculate a secret key, calculate a subscriber challenge tag, send a request for authentication, receive a response to the request, calculate a session key, verify response data and transmit a notification to authenticate subscriber device 110 with network device 120. Similarly, once executed, software may cause processor 122 to receive a request for authentication, decrypt one or more ciphers, verify the subscriberchallenge, calculate a session key, send a response to the request and authenticate subscriber device 110 with network device 120.

[0054] Subscriber device 110 (more specifically, processor 112) may communicate with network device 120 (more specifically, processor 122) via antennas 116, 126. Subscriber device 110 may communicate with network device 120 (via antennas 116, 126) through a wireless connection, such as by using a Wi-Fi network according to IEEE 802.11. In some examples, subscriber device 110 may communicate with network device 120 using a short-range wireless technology standard, such as Bluetooth. Subscriber device 110 may communicate with network device 120 may also communicate through any other wireless communication technology.

[0055] In some embodiments of system 100, system 100 comprises service network 130, as depicted in Fig.1. Service network 130 may be labelled using “SN” in this disclosure. Service network 130 may comprise physical components like servers, routers, and transmission media (e.g., fibre optics, satellites). As depicted in Fig.1, service network 130 comprise a communication tower. Service network 130 may represent the base station of a network carrier, for example. In such embodiments, communication between subscriber device 110 and network device 120 occurs via service network 130. As such, service network 130 may be used to extend the range between subscriber device 110 and network device 120. Similar to subscriber device 110 and network device 120, service network 130 may comprise a processor and a memory and hence, may be capable of performing processing tasks and store data. As will be discussed later in the disclosure, service network 130 may perform parts of the disclosed methods or parts of embodiments thereof. Although the example system depicted in Fig.1 comprises service network 130, it is noted that in other embodiments of system 100, subscriber device 110 may communicate directly with network device 120. Hence, in some embodiments, system 100 may not comprise service network 130. Methods Method as performed by the subscriber device

[0056] Fig.2 illustrates an example embodiment of a method for authenticating subscriber device 110 with network device 120 of a communication network, as performed by subscriber device 110, given as method 200. Fig.2 is to be understood as a blueprint for a software program and may be implemented step-by-step, such that each step in Fig.2 is represented by a functionin a programming language, such as, but not limited to, Python, C++, or Java. The resulting source code is then compiled and stored as computer-executable instructions on non-volatile memory 114, which causes processor 112 (or multiple processors or a distributed computing architecture) to perform method 200.

[0057] For explanatory purposes, the following method will be explained using reference labels, which are chosen based on consistency with various embodiments of method 200. However, the reference labels are use in a non-limiting manner to explain method 200 and should not be construed in a limiting manner.

[0058] Processor 112 calculates 201 a secret key (k UE ) by encrypting a subscriber challenge (R ) with a public key of the network device (PK HN ). The subscriber challenge ( R ) may be anumerical value such as a large integer, a hexadecimal value or the like, which processor 112may generate randomly or otherwise. The subscriber challenge ( R ) may also be a hash value, forexample. Similarly, the public key of the network device (PK HN ) may be a large integer,hexadecimal value, a hash value or the like, and may be cryptographically linked with a private key of the network device 120. The public key of the network device (PK HN ) and the private keyof the network device 120 may be based on symmetric-key encryption. Encrypting the subscriberchallenge ( R ) with the public key of the network device (PK HN ) may ensure that only thenetwork device 120 can determine the subscriber challenge ( R ), as only network device 120contains the private key.

[0059] Processor 112 may encrypt the subscriber challenge ( R ) with the public key of thenetwork device (PK HN ) by applying an algorithm or mathematical operation to the subscriberchallenge ( R ) with the public key of the network device (PK HN ). For example, processor 112may encrypt the subscriber challenge ( R ) by multiplying the subscriber challenge ( R ) with thepublic key of the network device (PK HN ). As such, the secret key (k UE ) may be based on aproduct of the subscriber challenge ( R ) with the public key of the network device (PK HN ). Insome examples, processor 112 may encrypt the subscriber challenge ( R ) using a sum of thesubscriber challenge ( R ) and the public key of the network device (PK HN ). Processor 112 mayalso calculate 201 the secret key (k UE ) by applying a mathematical function to a product or sumof the subscriber challenge ( R ) and the public key of the network device (PK HN ). For example,the mathematical function may be a cryptographic function, a hash function, a key derivation function or the like.

[0060] Processor 112 then calculates 202 a subscriber challenge tag ( MAC ) based on thesubscriber challenge ( R ) and the secret key (k UE ). Subscriber challenge tag ( MAC ) may also bereferred to an authentication tag, which may be used to verify the subscriber challenge ( R ). Therefence to “tag” is this disclosure may refer to a unique identifier assigned to a quantity, such as one of the challenges generated by subscriber device 110 or network device 120. More specification, “tag” may be a short piece of information used for authenticating and / or integrity-checking a message. The subscriber challenge tag ( MAC ), as well as other tags discussed in thisdisclosure, may be a message authentication code, for example. However, it is noted that the tagsdisclosed herein may be other types of tags. For example, the subscriber challenge tag ( MAC ),as well as other tags discussed in this disclosure, may be a hash.

[0061] Processor 112 may calculate 202 the subscriber challenge tag ( MAC ) by applying analgorithm or mathematical operation to the subscriber challenge ( R ) and the secret key (k UE ).For example, applying a mathematical function (such as a cryptographical function or a hashfunction) to a tuple of the subscriber challenge ( R ) and the secret key (k UE ). Processor 112 mayalso calculate 202 the subscriber challenge tag ( MAC ) using a product or sum of the subscriberchallenge ( R ) and the secret key (k UE ). Processor 112 may also calculate 202 the subscriberchallenge tag ( MAC ) using other quantities, such as, an identifier of service network 130 (inembodiments where system 100 comprises service network 130) and an identifier (or the like) of user 111. “Identifier” in this disclosure may have a similar meaning to “tag”, a short piece of information used to identify a quantity or entity.

[0062] Processor 112 sends 203 a request for authentication to network device 120. The requestcomprises the subscriber challenge tag ( MAC ) and one or more ciphers (C 0, C 1 ) determinedfrom the subscriber challenge ( R ). The request may also comprise further tags (such asauthentication tags) for verifying the one or more ciphers (C 0, C 1 ), for example. Any of the oneor more ciphers (C 0, C 1 ) may be referred to as an ephemeral public-key component, ciphertextcomponent, or an encrypted component. In some examples, processor 112 may determine the one or more ciphers (C 0, C 1 ) by encrypting the subscriber challenge ( R ). In some examples,processor 112 may determine the one or more ciphers (C 0, C 1 ) from the secret key (k UE ) whichis calculated from the subscriber challenge ( R ). In some examples, the one or more ciphers (C 0, C 1 ) may be part or a component of the secret key (k UE ), such as the first or last 8 bits of thesecret key (k UE ). The one or more ciphers ) may also be determined using a useridentifier ( SUPI ) of user 111.

[0063] The user identifier ( SUPI ) is a unique identifier used in wireless communicationnetworks, such as cellular networks, particularly in 5G, to identify subscribers and their devices.The user identifier ( SUPI ) may be referred to as a Subscription Permanent Identifier. Therequest for authentication may also comprise an encrypted user identifier ( SUCI ), which is anencrypted (or concealed) version of the SUPI . The encrypted user identifier ( SUCI ) may bereferred to as a Subscription Concealed Identifier. The SUCI may be used by network device120 to help identify user 111. Processor 112 may calculate the encrypted user identifier ( SUCI )using the one or more ciphers (C 0, C 1 ), particularly if the one or more ciphers (C 0, C 1 ) aredetermined using the user identifier ( SUPI ).

[0064] Processor 112 receives 204 a response to the request from the network device 120. Theresponse comprises a network challenge tag (MAC * ) and response data (R HN or dh HN ) that isbased on a network challenge (R HN ). For example, the response data may be the networkchallenge (R HN ), which may be generated by network device 120, or other data indicative of thenetwork challenge (R HN ), such as an encrypted version of the network challenge (R HN ). Thenetwork challenge (R HN ) may be a numerical value such as a large integer, a hexadecimal valueor the like, which processor 122 may generate randomly or otherwise. The network challenge (R HN ) may also be a hash value, for example.

[0065] The response may be based on a calculation performed by network device 120 according to the request for authentication sent 203 by subscriber device 110. In other words, network device 120 may generate the network challenge (R HN ) based on the request forauthentication, which is based on the subscriber challenge ( R ). The response may compriseother quantities, such as, an identifier of service network 130 (in embodiments where system 100 comprises service network 130).

[0066] Processor 112 calculates 205 a session key (K SEAF ) based on the response data (R HN or dh HN ) and the subscriber challenge ( R ). The session key (K SEAF ) may be used to encryptall further communication between subscriber device 110 and network device 120. The session key (K SEAF ) may be based on both challenges generated by both devices (i.e., subscriber device110 and network device 120). The session key (K SEAF ) may be referred to as an anchor keyand / or may be based on a security anchor function (SEAF).

[0067] Similar to other aspects of method 200, processor 112 may calculate 205 the session key (K SEAF ) by applying an algorithm or mathematical operation to the response data (R HN or dh HN )and the subscriber challenge ( R ). For example, processor 112 may calculate 205 the session key(K SEAF ) by applying a mathematical function (such as a cryptographical function or a hashfunction) to a tuple of the response data ( R HN or dh HN ) and the subscriber challenge ( R ).Processor 112 may also calculate 205 the session key (K SEAF ) using other quantities, such as thesecret key (k UE ) and an identifier of service network 130 (in embodiments where system 100comprises service network 130).

[0068] Processor 112 verifies 206 that the response data ( R HN or dh HN ) corresponds to therequest for authentication sent to network device 120. Processor 112 verifies 206 the responsedata (R HN or dh HN ) using the network challenge tag (MAC * ) with the session key (K SEAF ). Forexample, processor 112 may calculate a network challenge tag using the response data (R HN or dh HN ) and the session key ( K SEAF ), and compare the calculated network challenge tag tothe network challenge tag (MAC * ) received from network device 120. The network challengetag calculated by processor 112 may be calculated similarly to how the network challenge tag (MAC * ) is calculated by processor 122 of network device 120. In some examples, if the networkchallenge tag calculated by processor 112 matches network challenge tag (MAC * ) receivedfrom network device 120, then processor 112 then verifies 206 that the response data (R HN or dh HN ) indeed corresponds to the request for authentication sent to network device 120.Otherwise, the verification may fail, and the session may be aborted.

[0069] Finally, upon verification, processor 112 transmits 207 a notification to network device 120 to authenticate subscriber device 110 with network device 120. For example, upon receiving the notification, network device 120 may authenticate subscriber device 110 and enablesubscriber device 110 to access the communication network. In some examples, the notification may comprise further tags and further verification must be performed (by network device 120, for example) to authenticate subscriber device 110 with network device 120. The notification may comprise other quantities, such as further tags (e.g., authentication tags) and an identifier of network device 120. Method as performed by the network device

[0070] Fig.3 illustrates an example embodiment of a method for authenticating subscriber device 110 with network device 120 of a communication network, as performed by the network device, given as method 300. Fig.3 is to be understood as a blueprint for a software program and may be implemented step-by-step, such that each step in Fig.3 is represented by a function in a programming language, such as, but not limited to, Python, C++, or Java. The resulting source code is then compiled and stored as computer-executable instructions on non-volatile memory 124, which causes processor 122 (or multiple processors or a distributed computing architecture) to perform method 300.

[0071] Similar examples described in relation to method 200 are applicable to method 300. Various quantities described in relation to method 200 are similarly used in method 300. Again, for explanatory purposes, the following method will be explained using reference labels, which are chosen based on consistency with various embodiments of method 300. However, the reference labels are used in a non-limiting manner and should not be construed in a limiting manner.

[0072] It is noted that the use of “ x ” in the reference labels generally refers to quantitiesreceived by or calculated by processor 122 of network device 120. Ideally, if user 111 is indeed a subscriber of the communication network, each quantity determined independently by processor 122 should be equivalent to the corresponding quantity determined independently by processor 112 of subscriber device 110.

[0073] Firstly, processor 122 receives 301 a request for authentication from subscriber device110. The request comprises a subscriber challenge tag ( MAC ) and one or more ciphers (xC 0, xC 1 ) determined from a subscriber challenge ( R ). The request may also comprise otherquantities, such as further tags (e.g., authentication tags) for verify the one or more ciphers (xC 0, xC 1 ). The request for authentication may comprise the encrypted user identifier ( SUCI ).

[0074] Processor 122 decrypts 302 the one or more ciphers (xC 0, xC 1 ) using a private key ofthe network device (sk HN ) to determine a secret key ( xk UE ) and the subscriber challenge ( xR ).By decrypting 302 the one or more ciphers (xC 0, xC 1 ), processor 122 may calculate the secretkey (xk UE ) and / or the subscriber challenge ( xR ). It is noted that the private key of the networkdevice) may be cryptographically linked (or coupled) to the public key of the networkdevice (PK HN ) described earlier in relation to method 200. Hence, ideally, only network device120 can decrypt the one or more ciphers (xC 0, xC 1 ) as only network device 120 should comprisethe private key of the network device (sk HN ) .

[0075] Processor 122 may decrypt 302 the one or more ciphersxC 1 ) by applying analgorithm or a mathematical operation to the one or more ciphers (xC 0, xC 1 ) and the private keyof the network device (sk HN ). For example, processor 122 may calculate a product or sum of oneof the one or more ciphers (xC 0, xC 1 ) and the private key of the network device (sk HN ) todetermine the secret key (xk UE ), thereby decrypting 302 the one or more ciphers (xC 0, xC 1 ).Processor 122 may decrypt 302 the one or more ciphersusing the secret key ( xk UE ).For example, processor 122 may decrypt 302 one cipher (xC 0 ) to determine the secret key ( xk UE) and use the secret key (xk UE ) or apart thereof to decrypt 302 the other cipher. The one ormore ciphers (xC 0, xC 1 ) may be determined from the user identifier ( SUPI ) of user 111. Hence,by decrypting 302 the one or more ciphersprocessor 122 may also determine the useridentifier ( SUPI ). Processor 122 may use the user identifier ( SUPI ) to identify user 111 anddetermine whether user 111 is a subscriber of the communication network.

[0076] Processor 122 verifies 303 the subscriber challenge ( xR ) using the subscriber challengetag ( MAC ) with the secret key ( xk UE ). “Verify” in this context may refer to verifying that thesubscriber challenge ( xR ) calculated by network device 120 is equivalent to the subscriberchallenge ( R ) generated by subscriber device 110. In other words, processor 122 then verifies303 the subscriber challenge ( xR ) originates from subscriber device 110. In some examples,processor 122 may calculate its own subscriber challenge tag using the subscriber challenge ( xR) and the secret key (xk UE ) that it has determined. Processor 122 may then compare its ownsubscriber challenge tag to the subscriber challenge tag ( MAC ) received from subscriber device110. If processor 122 determines that its own subscriber challenge tag and the subscriberchallenge tag ( MAC ) received from subscriber device 110 are a match, then processor 122 mayverify the subscriber challenge ( xR ). Otherwise, the verification may fail, and the session maybe aborted.

[0077] Upon verification, processor 122 calculates 304 a session key (K SEAF ) based on anetwork challenge (R HN ) and the subscriber challenge ( xR ). Similar to method 200, calculating304 a session key (K SEAF ) based on a network challenge (R HN ) and the subscriber challenge ( xR) mutually binds the network challenge (R HN ) and the subscriber challenge ( xR ), whichenhances the security of the overall method. Processor 122 may calculate 304 a session key (K SEAF ) by applying an algorithm or mathematical operation to the network challenge ( R HN ) andthe subscriber challenge ( xR ). Processor 122 may calculate 304 a session key (K SEAF ) usingother quantities, such as, an identifier of service network 130 (in embodiments where system 100 comprises service network 130).

[0078] Processor 122 also calculates 305 a network challenge tag (MAC * ) based on thenetwork challenge (R HN ) and the session key (K SEAF ), upon verification. The network challengetag (MAC * ) may be used by subscriber device 110 to verify the network challenge (R HN )received from network device 120. Subscriber device 110 may also use the network challengetag (MAC * ) to verify that the received network challenge (R HN ) is based on its own generatedsubscriber challenge ( R ). In other words, subscriber device 110 may use the network challengetag (MAC * ) to verify that the received network challenge (R HN ) is based on the initial requestfor authentication.

[0079] Processor 122 sends 306 a response to the request (for authentication) to subscriberdevice 110. The response comprises the network challenge tag (MAC * ) and response data (R HN or dh HN ) that is based on the network challenge ( R HN ). For example, the response data (R HN or dh HN ) may be the network challenge (R HN ). However, as will be later discussed, in someembodiments, the response data (R HN or dh HN ) is an encrypted version of the network challenge(R HN ).

[0080] Finally, processor 122 authenticates 307 subscriber device 110 upon receiving a notification from subscriber device 110 based on the response. For example, subscriber device 110 may generate a further response based on the received response and network device 120 may receive the further response in the form of the notification. The notification may comprise further authentication tags, which processor 122 may verify before authenticating 307 subscriber device110. In some examples, processor 122 may send the user identifier ( SUPI ) and / or the encrypteduser identifier ( SUPI ) to service network 130 to authenticate subscriber device 110. (inembodiments where system 100 comprises service network 130). Explicit key confirmation

[0081] In some embodiments, upon verifying the response data (R HN or dh HN ), processor 112of subscriber device 110 calculates a key confirmation tag ( kcMac ) by hashing the response data(R HN or dh HN ) with the session key) calculated by the subscriber device. Processor 112may hash the response dataor dh HN ) with the session key (K SEAF ) by applying a hashfunction (such as SHA256 or an equivalent hash function) to the response data ( R HN or dh HN )with the session key (K SEAF ). As such, the key confirmation tag ( kcMac ) may be considered tobe a hash or hash value. Further, the notification transmitted 207 by processor 112 may comprisethe key confirmation tag ( kcMac ). The key confirmation tag ( kcMac ) may be used to verify thatboth subscriber device 110 and network device have calculated the same session key (K SEAF ),which may be referred to as explicit key confirmation.

[0082] It is noted that such explicit key confirmation is difficult to implement in some authentication methods, especially 5G-AKA, as these authentication methods may need modification to enable an additional round of key confirmation. However, explicit key confirmation can be easily implemented in the disclosed methods as the additional challengeprovided by subscriber device 110 (i.e., the subscriber challenge ( R )) may provide thisadditional round of key confirmation. In other words, the disclosed methods do not need significant modification to enable explicit key confirmation, as compared to other authentication methods (such as 5G-AKA).

[0083] In some embodiments, processor 122 of network device 120 may receive the keyconfirmation tag ( kcMac ) with the notification received from subscriber device 110. Processor122 may then verifies the session key (K SEAF ) of subscriber device 110 using the ( kcMac ) withthe session key (K SEAF ) of network device 120 and the response data ( R HN or dh HN ). Processor122 may verify the session key (K SEAF ) of subscriber device 110 by calculating its own keyconfirmation tag using its own session key (K SEAF ) and the response data (R HN or dh HN ) thatitself has generated. For example, processor 122 may calculate its own key confirmation tag by applying a hash function (such as SHA256 or an equivalent hash function) to the response data (R HN or dh HN ) with the session key (K SEAF ). Upon verification, processor 122 authenticates 307subscriber device 110 with network device 120. First embodiment of the methods

[0084] A first embodiment of methods 200, 300 will now be discussed. In the firstembodiment, the response dataor dh HN ) comprises the network challenge (R HN ). As such,at 204 of method, subscriber device 110 (more specifically, processor 112) receives the network challenge (R HN ), rather than an encrypted version of the network challenge (R HN ), for example.Further, in the first embodiment, subscriber device 110 and network device 120 calculate the session key (K SEAF ) by applying a cryptographic function to the network challenge ( R HN ) andthe subscriber challenge ( R ). For example, the respective processors 112, 122 of subscriberdevice 110 and network device 120 may calculate the session key (K SEAF ) by applying acryptographic function to a tuple of the network challenge (R HN ) and the subscriber challenge (R ).

[0085] Different embodiments of methods 200, 300 may use a cryptographic function. In any embodiment disclosed herein, the cryptographic function may be a key derivation function (KDF), such as, but not limited to, ANSI-X9.63-KDF with SHA-1. The cryptographic functions recited herein may be hash functions. The cryptographic functions recited herein may also be based on other authentication protocols. For example, the cryptographic functions recited herein may be based on the cryptographic functions used in the 5G-AKA protocol.

[0086] In some examples of the first embodiment, processor 112 of subscriber device 110 maycalculate 202 the subscriber challenge tag ( MAC ) by applying a cryptographic function to thesubscriber challenge ( R ) and the secret key (k UE ). Further, processor 122 of network device 120may calculate 305 the network challenge tag (MAC * ) by applying a cryptographic function tothe network challenge (R HN ) and the session key (K SEAF ). In these examples, the cryptographicfunctions using by processor 112 and processor 122 may be the same or different cryptographical functions.

[0087] In some examples of the first embodiment, processor 112 of subscriber device 110 maycalculate one or more keys (CK , IK ) by encrypting the subscriber challenge ( R ) using adifferent cryptographic function for each of the one or more keys (CK , IK ). In further examples,processor 112 of subscriber device 110 may calculate one or more keys (CK , IK ) by encryptingthe subscriber challenge ( R ) and the secret key (k UE ). Similarly, processor 122 of networkdevice 120 may calculate one or more keys (CK , IK ) by encrypting the subscriber challenge (xR ), determined by decrypting 302 the one or more ciphers ( xC 0, xC 1 ), using a differentcryptographic function for each of the one or more keys (CK , IK ). It is noted that the differentcryptographic functions may be a similar, yet different, function. For example, the cryptographicfunction used to calculate one of the one or more keys ( CK ) may be Keccak-256 and thecryptographic function used to calculate another one of the one or more keys ( IK ) may beSHA256. However, in some examples, processor 112 of subscriber device 110 may calculate oneor more keys (CK , IK ) by encrypting the subscriber challenge ( R ) using the samecryptographic function for each of the one or more keys (CK , IK ) and a different input. Forexample, an input to calculate one key ( CK ) may be a bit (0 or 1), while an input to calculatethe other key ( IK ) may be the flipped bit (1 or 0).

[0088] In this example, processors 112, 122 may calculate the respective session key (K SEAF )using the respective one or more keys (CK , IK ). For example, processors 112, 122 maycalculate the respective session key (K SEAF ) using a tuple of the respective one or more keys (CK , IK ). The one or more keys (CK , IK ) may be a cipher key and / or an integrity key. The oneor more keys (CK , IK ) may enhance the security and integrity of the disclosed methods 200,300. The one or more keys (CK , IK ) may be similar to the cipher key and / or the integrity key ofother authentication protocols, such as the 5G-AKA protocol.

[0089] In some examples of the first embodiment, processor 112 of subscriber device 110 maygenerate a network challenge response tag ( RES * ). Similarly, processor 122 of network device120 may generate an expected network challenge response tag ( xRES * ). The network challengeresponse tag ( RES * ) and the expected network challenge response tag ( xRES * ) may be used toverify the network challenge determined by subscriber device 110. As such, in these examples,processor 112, 122 may verify the network challenge response tag ( RES * ) and the expectednetwork challenge response tag ( xRES * ). Further, upon verification, processor 112, 122 mayproviding network device 120 with access to the notification from subscriber device 110. In some examples, processor 122 of network device 120 may generate an expected networkchallenge response hash (HxRES * ) by applying a hash function to the expected networkchallenge response tag ( xRES * ). In these examples, the expected network challenge responsehash (HxRES * ) may be used to verify the network challenge determined by subscriber device110. Hashing the expected network challenge response tag ( xRES * ) may provide furthersecurity.

[0090] In some examples, communication between subscriber device 110 and network device 120 may occur via service network 130. In these examples, service network 130 may receivenetwork challenge response tag ( RES * ) and the expected network challenge response tag (xRES * ) and verify the network challenge response tag ( RES * ) using the expected networkchallenge response tag ( xRES * ). Then, upon verification, service network 130 may providingnetwork device 120 with access to the notification from subscriber device 110. In someexamples, service network 130 may receive network challenge response tag ( RES * ) and anexpected network challenge response hash ( HxRES * ) and verify the network challenge responsetag (RES * ) using the expected network challenge response hash ( HxRES * ).

[0091] In some examples of the first embodiment, processor 122 of network device 120 maygenerate a subscriber challenge response tag ( xRES ). Moreover, processor 122 may generate theexpected network challenge response tag ( xRES * ) from the subscriber challenge response tag (xRES ). Similarly, processor 112 of subscriber device 110 may generate an expected subscriberchallenge response tag ( RES ). Moreover, processor 112 may generate the network challengeresponse tag ( RES * ) from the expected subscriber challenge response tag ( RES ). In theseexamples, processor 112, 122 or service network 130 may verify subscriber challenge responsetag ( xRES ) using the expected subscriber challenge response tag ( RES ).Second embodiment of the methods

[0092] A second embodiment of methods 200, 300 will now be discussed. In the second embodiment, processor 122 of network device 120 calculates an encrypted network challenge (dh HN ) by encrypting the network challenge ( R HN ). Processor 122 also calculates calculating anetwork challenge key (dh key ) by encrypting the network challenge (R HN ) with one of the one ormore ciphers (xC 0 ). As such, in the second embodiment, the response data (R HN or dh HN )comprises the encrypted network challenge (dh HN ). By encrypting the network challenge (R HN )before sending the network challenge (R HN ) to the subscriber device 110, this enhances thesecurity of the disclosed methods 200, 300. More particularly, encrypting the network challenge (R HN ) provides perfect forward secrecy, as will be discussed later in the disclosure. It is notedthat some examples or aspects thereof described in relation to the first embodiment may be applicable to the second embodiment.

[0093] In some examples of the second embodiment, processor 112, 122 of subscriber device 110 and network device 120, respectively, calculate the session key (K SEAF ) by applying acryptographic function to the network challenge key (dh key ) and the secret key).

[0094] In some examples of the second embodiment, processor 112 of subscriber device 110calculates 202 a subscriber challenge tag ( MAC ) by applying a cryptographic function to one ofthe one or more ciphers (C 0 ) and the secret key (k UE ). Moreover, in some examples of thesecond embodiment, processor 122 of network device 120 calculates 305 the network challengetag (MAC * ) by applying a cryptographic function to the network challenge key (dh key ) and thesession key (K SEAF ).

[0095] In some examples of the second embodiment, processor 112, 122 may calculate one ormore keys (CK , IK ) by encrypting one of the one or more ciphers (C 0 or xC 0 ) using a differentcryptographic function for each of the one or more keys (CK , IK ). Moreover, in some examplesof the second embodiment, processor 112, 122 may calculate the session key (K SEAF ) using theone or more keys (CK , IK ).

[0096] In some examples of the second embodiment, processor 112 of subscriber device 110may generate a network challenge response tag ( RES * ) using the network challenge key (dh key ).Similarly, in some examples of the second embodiment, processor 122 of network device 120may generate an expected network challenge response tag ( xRES * ) using the network challengekey (dh key ). Similar to examples of the first embodiment, the expected network challengeresponse tag ( xRES * ) may be used to verify the network challenge ( R HN ) received bysubscriber device 110. Similar to examples of the first embodiment, processor 122 of networkdevice 120 may generate an expected network challenge response hash (HxRES * ) by applying ahash function to the expected network challenge response tag ( xRES * ), and the expectednetwork challenge response tag ( xRES * ) may be used to verify the network challenge (R HN )received by subscriber device 110.

[0097] As such, in some examples of the second embodiment, processor 112, 122 may verifythe network challenge response tag ( RES * ) using the expected network challenge response tag (xRES * ). Then upon verification, processor 112, 122 may provide network device 120 withaccess to the notification from subscriber device 110. In these examples, service network 130may verify the network challenge response tag (RES * ) using the expected network challengeresponse tag ( xRES * ). Then upon verification, service network 130 may provide networkdevice 120 with access to the notification from subscriber device 110. Similar to examples of thefirst embodiment, service network 130 may receive network challenge response tag ( RES * ) andan expected network challenge response hash (HxRES * ) and verify the network challengeresponse tag ( RES * ) using the expected network challenge response hash ( HxRES * ).

[0098] In some examples of the second embodiment, processor 122 of network device 120 maygenerate a subscriber challenge response tag ( xRES ) using one of the one or more ciphers (xC0). In further examples, processor 122 may generated the expected network challenge response tag(xRES * ) from the subscriber challenge response tag ( xRES ). Similarly, in some examples ofthe second embodiment, processor 112 of subscriber device 110 may generate an expectedsubscriber challenge response tag ( RES ) using one of the one or more ciphers (C 0 ). Similar, infurther examples, processor 112 may generate the network challenge response tag ( RES * ) fromthe expected subscriber challenge response tag ( RES ).

[0099] In some examples of the second embodiment, processor 122 of network device 120 may calculate the encrypted network challenge (dh HN ) and calculating a network challenge key (dh key) based on Diffie–Hellman (DH) key exchange protocol. The Diffie–Hellman key exchange protocol enables two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel. This key can then be used to encrypt subsequentcommunications using a symmetric-key cipher. In other examples of the second embodiment, processor 122 of network device 120 may calculate the encrypted network challenge (dh HN ) andcalculating a network challenge key (dh key ) based on other cryptographic protocols, such as, butnot limited to, Elliptic Curve Diffie–Hellman (ECDH) protocol, RSA Key Exchange and the Internet Key Exchange (IKE). Service network

[0100] As previously discussed, in some embodiments, communication between subscriber device 110 and network device 120 occurs via service network 130. More specifically, processor 112 may send 203 the request for authentication, receive 204 the response to the request and transmit 207 the notification via service network 130. Similarly, processor 122 may receive 301 the request for authentication and send the response to the request via service network 130.

[0101] Communicating via service network 130 may present additional difficult, when compared to direct communication between subscriber device 110 and network device 120. For example, service network 130 may have limited processing capabilities as compared to between subscriber device 110 and network device 120. Despite this, it is noted that the disclosed methods may be integrated seamlessly in the presence of service network 130. This is because the disclosed methods were designed with consideration of a difficult communication network scenario i.e., the communication subscriber device 110 and network device 120 occurring via service network 130.

[0102] Service network 130 may store aspects of the communication between subscriber device 110 and network device 120. More specifically, in some embodiments, service network 130 mayreceive the response data (R HN or dh HN ) and the session key (K SEAF ) from network device.Service network 130 may also receive a key confirmation tag ( kcMac ) from subscriber device110. Based on this, service network 130 may verify the session key (K SEAF ) of subscriber device110 using the key confirmation tag ( kcMac ) with the session key (K SEAF ) of network device 120and the response data (R HN or dh HN ). Then upon verification, service network 130 may providenetwork device 120 with access to the notification from subscriber device 110. Elliptical curve cryptography

[0103] In some embodiments, processor 112, 122 may encrypt various quantities based on elliptic-curve cryptography. Elliptic-curve cryptography is an approach to public-key cryptography based on the algebraic structure of elliptic curves over finite fields. For example, processor 112 of subscriber device 110 may calculate one of the one or more ciphers (C 0 ) byencrypting the subscriber challenge ( R ). Encrypting the subscriber challenge ( R ) may be basedon elliptic-curve cryptography, where one of the one or more ciphers (C 0 ) by a product of thesubscriber challenge ( R ) and a generator ( G ) of the elliptic curve. Symmetric keys may also bebased on elliptic-curve cryptography, such as the public key of the network device)andthe private key of the network deviceProcessor 112 may calculate another one of the oneor more ciphers (C 1 ) using encryption based on elliptic-curve cryptography. Similarly, processor122 may decrypt 302 the one or more ciphersbased on elliptic-curve cryptography.

[0104] Encryption (and decryption) recited herein may also be based on specific elliptic-curve protocols, such as, but not limited to, Elliptic-curve Diffie–Hellman (ECDH) key agreement, Elliptic Curve Integrated Encryption method also referred to as Elliptic Curve Augmented Encryption method or simply the Elliptic Curve Encryption method and the Elliptic Curve Digital Signature Algorithm (ECDSA). Subscriber secret key

[0105] In some embodiments, processor 112 of subscriber device 110 calculates 202 thesubscriber challenge tag ( MAC ) by encrypting the subscriber challenge ( R ) with the secret key(k UE ) and a subscriber secret key ( k ). The subscriber secret key ( k ) may be indicative of asubscription to services provided by network device 120. The subscriber secret key ( k ) may bereferred to as a long-term secret key. As such, once network device 120 identifies subscriberdevice 110, processor 122 of network device 120 may determine the subscriber secret key ( k ) byretrieving the subscriber secret key ( k ) from a database based on an identifier of subscriberdevice 110, for example. Other quantities may be calculated using the subscriber secret key ( k ).For example, processor 112, 122 may calculate the one or more keys (CK , IK ) using thesubscriber secret key ( k ) as well as the other factors, such as the subscriber challenge ( R or xR )and the secret key (k UE or xk UE ).5G-AKA Protocol

[0106] In this section, an overview of the 5G-AKA protocol based on the 3GPP TS 33.501 standard is provided. The overview is provided for explanatory purposes to understand the differences between the disclosed methods and 5G-AKA. The 5G-AKA protocol uses severalcryptographic primitives such as hash functions f , f , f , f , f , f * , f *1 2 3 4 5 1 5 , the Secure HashAlgorithm-256 (SHA256 ), the elliptic curve integrated encryption (ECIES) key encapsulationmechanism (more details provided in Appendix A), and the Key Derivation Function ( KDF ).

[0107] The 5G-AKA protocol involves three primary entities: subscriber device 110, network device 120, and service network 130. However, it is noted that the 5G-AKA protocol may only involve subscriber device 110 and network device 120. Subscriber device 110 may represent the mobile device user with the USIM card and connects to the 5G network to access its services. Service network 130 may be the network carrier that subscriber device 110 connects to, while network device 120 may be the network carrier of subscriber device 110. The main functionality of the 5G-AKA protocol is to provide mutual authentication and establish a session key between the entities. A high-level overview of 5G-AKA protocol is shown in Fig.4, where dotted and solid arrows represent open channels and authenticated secure channels respectively.

[0108] A detailed overview of the 5G-AKA protocol is provided in Appendix B. However, the four phases of the 5G-AKA protocol are briefly presented here. These phases are: Initiation, Challenge-Response, Sequence Number Re-synchronization, and MAC Failure. SUPI 1. Initiation: In the Initiation phase, subscriber device 110 sends the encrypted usingSUCI ECIES, which is represented as , to network device 120 via the radio channelthrough service network 130. 2. Challenge-Response: In the Challenge-Response phase, network device 120 chooses a RAUTN MAC R random value . It computes , which consists of the for the and the^ XOR ( ) of the sequence number SQN for privacy. Subscriber device 110 performs HNtwo tasks upon receiving the challenge message from network device 120. First, it checks MAC R the to authenticate and verify the integrity of the challenge . Second, theSQN R is used to check the freshness of the challenge from network device 120 to HNprevent replay attacks. Subscriber device 110 checks the freshness of the challenge SQN SQN with its own sequence number . It ismessage by comparing the receivedHN UESQNSQN and should remain synchronized atnoted that, as per the 3GPP TS 33.50,HN UEall times.3. Sequence Number Re-synchronization: If this comparison of the sequence numbers fails, i.e., ifSQN HN and SQN UE are unsynchronized, subscriber device 110 sends aSync _ Failure message, along with AUTN , to network device 120 for re-synchronization of its sequence numberSQN UE with network device 120’s SQN HN .Afterward, subscriber device 110 returns to the Initiation phase to restart the process from the beginning. 4. MAC Failure: If the MAC check fails, subscriber device 110 outputs a MAC_ Failuremessage and returns to the Initiation phase to restart the process.

[0109] If both the MAC and SQN HN checks are successfully completed, subscriber device110 generates a response message RES for the challenge R , computes the key material togenerate the session keys (i.e.,K SEAF ), and sends RES to network device 120. As mentionedearlier, the 5G-AKA protocol has some subscriber privacy-related security issues. A few of the existing privacy-related issues with 5G-AKA are presented in Appendix C. System Model, Threat Model & Security Aspects

[0110] In this section, the system model, threat model, and security aspects for the disclosed methods are presented, which are primarily based on the 3GPP standards (3GPP TS 33.501). The following considers an embodiment of system 100 of Fig.1, which comprises service network 130, as depicted in Fig.1. System Model

[0111] Subscriber device 110 may represent smartphones or IoT devices equipped with Universal Subscriber Identity Modules (USIMs). The USIM may be a cryptographic chip thatstores subscriber-related information, such as the subscriber secret key ( k ) and the uniqueidentity of the subscriber (e.g., user 111 of system 100), which may be referred to as theSubscription Permanent Identifier ( SUPI ). Each subscriber may be registered with networkdevice 120. Network device 120 may be the network carrier of the subscriber, which maintains the database of the subscribers and also performs authentication before providing access to its services. Network device 120 may also store the same subscriber-related information as the USIM for each registered subscriber. In practice, network device 120 may consists of multiple sub-entities such as the AUSF (Authentication Server Function), which authenticatessubscribers, and UDM (Unified Data Management), which computes keying material and authentication-related data for the AUSF. The UDM may consist of ARPF and SIDF. The primary purpose of ARPF may be to store subscribers’ secret credentials and compute authentication-related cryptographic parameters. However, SIDF may contain the private key ofnetwork device 120, which recovers the plaintext SUPI of subscribers from its encryptedversion SUCI . For simplicity and without compromising overall security, AUSF and UDM maybe considered as a single entity i.e., network device 120. Service network 130 may be the actual network carrier to which subscribers connect and get access to the communication network. In scenarios where subscribers remain within the coverage areas of the network device 120, network device 120 may act as service network 130. In roaming scenarios, service network 130 may be maintained by a different network carrier. Threat Model & Security Assumptions

[0112] The presented threat model incorporates all the aspects outlined in the 3GPP standards. Additionally, the disclosed methods take into account additional security aspects, as will be discussed below.

[0113] Assumption on Channels: In accordance with 3GPP standards, the communication channel between service network 130 and network device 120 is considered authenticated and secure (i.e., a private channel). This ensures that any attempt by an attacker to eavesdrop, insert, or modify messages within the channel will be prevented and detected. However, the communication channel between subscriber device 110 and service network 130 is considered insecure or open, enabling passive attackers to eavesdrop and active attackers to manipulate, intercept, and inject messages. There may be a necessity for a binding channel between service network 130 and network device 120, where each message may be associated with a unique session ID to maintain security. The disclosed methods may operate under the assumption of such channel binding between service network 130 and network device 120.

[0114] Assumption on Cryptographic Functions: The disclosed methods may not require all the cryptographic primitives outlined in 3GPP TS 33.501. Instead, the disclosed methods mayutilize a part of the cryptographic functions such as SHA256 ,These cryptographicfunctions are publicly available and provide confidentiality and integrity of their inputs. However, the disclosed method may not utilise the cryptographic functionsf 5, f *1 , f *5 from the5G-AKA protocol. Additionally, the Elliptic Curve Integrated Encryption method may be employed as a secure public-key encryption. These assumptions regarding cryptographic functions may be aligned with the aspects outlined in the 3GPP standards.

[0115] Assumption on Components: Aligned with the 3GPP standards, the proposed threat model assumes that no attacker can compromise service network 130 and network device 120.Additionally, the subscriber secret key ( k ) of honest subscribers always remains secure, and thehonest subscribers are capable of protecting their session keys (K SEAF ). However, in proving theperfect forward secrecy property, a scenario is considered where the attacker has access to boththe subscriber secret key ( k ) of the subscribers and the private key (sk HN ) of network device120. Security Aspects:

[0116] The security aspects outlined in the 3GPP security specifications may be broadly categorized into three groups: privacy, secrecy, and authentication. All the security aspects specified in the 3GPP security specifications are presented below, along with additional security aspects, which are not fully specified by 3GPP. • Privacy: According to the 3GPP TS 33.501 standards, a subscriber’s privacy aspects can be classified into three types: user identity confidentiality, user location confidentiality, and user untraceability. These privacy aspects can be met by safeguarding the secrecy of the SUPI and ensuring subscriber device 110’s untraceability. The disclosed methodsmay support these privacy aspects in the presence of both passive and active attackers. Furthermore, all mentioned privacy aspects may be achieved if the disclosed methods support the indistinguishability property. This property asserts that no attacker can distinguish between two subscribers, which is summarised below: o Subscriber Indistinguishability: If there are two subscribers, denoted as UE1 and UE2, and an AKA session involves UE1 (or UE2), no active attacker can distinguish whether it is engaged with UE1 or UE2. •Secrecy: In the 3GPP TS 33.501, in addition to the secrecy of the SUPI and subscribersecret key ( k ), another security aspects is the secrecy of the session keys (K SEAF ). The5G-AKA protocol does not provide PFS. Therefore, the disclosed methods (particularly, the embodiments thereof) aims to support PFS as well. The two secrecy aspects are outlined below:o Key Secrecy: The session key (K SEAF ) must remain secret.o Perfect Forward Secrecy (PFS): If the subscriber secret key ( k ) and the privatekey (sk HN ) of network device 120 are compromised, the attacker must not be ableto compute any previously generated session keys).• Authentication: Some authentication properties considered in this proposed threat model are presented below: o Weak Agreement: This denotes that a participant has executed the protocol with its partner, but they may not be required to reach a consensus on any data transferred or secrets established during this session. o Non-Injective Agreement: This suggests that participants should reach an agreement on the data or secrets with their partners based on weak agreement. o Injective Agreement: This indicates that there is only one partner for the protocol execution who agrees on the data or secrets, building upon the foundation of non- injective agreement.

[0117] The required authentication properties of the disclosed methods are provided below: • Agreement between the subscriber device and the service network: Subscriber device 110 and service network 130 must both obtain injective agreement onK SEAF and weakagreement with each other. • Agreement between the subscriber device and the network device: Subscriber device 110 and network device 120 must achieve injective agreement regardingK SEAF and establisha weak agreement with each other. Additionally, both the subscriber and network device 120 must achieve a non-injective agreement regardingID SN with each other.• Agreement between the service network and network device: Service network 130 and network device 120 must both achieve injective agreement onK SEAF and weak agreementwith each other. Service network 130 must also achieve a non-injective agreement on SUPI with network device 120.Preferred embodiments

[0118] Preferred embodiments of methods 200, 300 (particularly, the preferred first embodiment and the preferred second embodiment) will now be presented. It is noted that in the preferred embodiments, system 100 comprises service network 130 and hence, allcommunication between subscriber device 110 and network device 120 occurs via service network 130. It is noted that aspects of the preferred embodiments may be equally applicable to other embodiments of the disclosed methods.

[0119] The preferred embodiments aim to streamline the AKA mechanism in 5G by addressing the limitations of the existing 5G-AKA protocol, such as enhancing subscriber privacy, ensuring perfect forward secrecy, and introducing an efficient replay attack prevention method. The objective is to meet all the security aspects outlined in the 3GPP standards and accommodate additional security needs that are not fully specified in the standards. Overview

[0120] While Appendix C presents a brief overview of the common types of privacy-related attacks in the 5G-AKA protocol and the methods used to carry out these attacks, the vulnerabilities of the 5G-AKA protocol are briefly discussed here. The primary vulnerability in 5G-AKA lies in conducting two security checks at the subscriber side for the challenge message of the network device.

[0121] Initially, a subscriber device 110 verifies the authenticity and integrity of the randomchallenge of network device 120 by checking the MAC . Subsequently, subscriber device 110assesses the freshness of the challenge of network device 120 by comparing the sequence numberSQN UE of subscriber device 110 with the sequence number SQN HN of network device120. For instance, in the Encrypted SUPI Replay Attack, the attacker captures the SUCI of thetargeted subscriber and replays it later. Consequently, the targeted subscriber responds to thechallenge of network device 120, whereas other subscribers return MAC_ Failure responses.Similarly, in the Failure Message Linkability Attack, the attacker captures R and AUTN sent bynetwork device 120 to the targeted subscriber and replays them later. As a result, the targetedsubscriber successfully verifies the MAC but fails to confirm freshness, responding with aSync_ Failure message. Conversely, all other subscribers fail the MAC verification and respondwith MAC_ Failure messages. Additionally, another type of privacy-related attack called theSequence Number Inference Attack may occur in the 5G-AKA protocol by capturing R andAUTN and replaying them later.Preferred first embodiment

[0122] Fig.5 provides a high-level overview of the preferred first embodiment, where dotted and solid arrows represent open channels and authenticated secure channels respectively. It is divided into three phases: Initiation and subscriber challenge, Network challenge and response and Subscriber device response and key confirmation, as will be described shortly. The preferred first embodiment uses the cryptographic functions such as,f 1, f 2 , f 3 , f 4 , KDF and SHA256 , asdocumented in 3GPP TS 33.501.

[0123] (1) Initiation and subscriber challenge:

[0124] Subscriber device 110 initiates this phase as a result of service network 130 triggering authentication. In this phase, subscriber device 110 primarily sends two useful messages tonetwork device 120: the encrypted SUPI , which is SUCI , and a subscriber challenge R .Subscriber device 110 mainly performs two tasks, as outlined below.

[0125] Firstly, subscriber device 110 chooses a subscriber challenge R at random andgenerates a randomized encrypted SUPI for privacy protection using elliptic curve integratedencryption (ECIES), as outlined in Appendix A. The ECIES key encapsulation mechanism generates a shared secret key k UE and one of the one or more ciphers C 0 , which maybe referred to as an ephemeral public-key component. Concurrently, the data encryption mechanism of ECIES produces another one of the one or more ciphersC 1 , which may bereferred to as an encrypted component, for the SUPI and the subscriber challenge R usingsymmetric key encryption. Thes 1 portion of the shared secret key k UE is used as the encryptionkey, while the remainings 2 portion creates a tag (i.e., message authentication code)for authenticity and integrity verification ofC 1.

[0126] Secondly, a message authentication code MAC is computed for the subscriberchallenge R . This may verify the authenticity and integrity of the subscriber challenge R .

[0127] Finally, subscriber device 110 sends the tuple SUCI = C 0, C 1 , MAC ECIES , MAC , ID HNto service network 130. Subsequently, service network 130 forwards the tuplenetwork device 120.

[0128] (2) Network challenge and response:

[0129] In this phase, network device 120 performs broadly two tasks once network device 120receives the tuple SUCI , MAC , IDHN , ID SN from subscriber device 110.

[0130] Firstly, network device 120 recovers the plaintext SUPI using its private key sk HNfrom SUCI to retrieve the subscriber secret key k associated with subscriber device 110 fromits database. Following the decapsulation operation of ECIES using its private keysk HN and theone of the one or more ciphersC 0 (i.e., the ephemeral public-key component) of SUCI , networkdevice 120 acquires the shared secret keyxk UE . Subsequently, it decrypts C 1 using(acomponent of the shared secretxk UE ) after successfully verifying the tag (i.e., MAC ECIES ) usingxs 2 (the second component of the shared secret xk UE ) and C 1 , thus obtaining the plaintext SUPIand the subscriber challenge xR .

[0131] Secondly, network device 120 verifies the authenticity and integrity of the subscriberchallenge xR by checking the MAC . An unsuccessful verification results in a MAC_ Failure .Once the verification is successful, network device 120 chooses a network challengeR HN forsubscriber device 110 and computes xRES , cipher key CK , and integrity key IK using thesubscriber secret key k of subscriber device 110 and the subscriber challenge xR . It thengenerates the expected response from subscriber device 110 xRES * , and the session keys K SEAF .Next, network device 120 computes the hashed response * , which includes the expectedHxRESresponse xRES * , the subscriber challenge xR , and its challenge for subscriber device 110 R HN .Additionally, network device 120 generates a message authentication code MAC * . Networkdevice 120 sends the tuple HxRES *, MAC * , xR , RHN , K SEAF to service network 130. Note thatMAC * serves three functions: it acts as the response from network device 120 to the subscriberchallenge, it provides authenticity and integrity verification for network device 120’s challengeR , and it offers key confirmation for the session key K to subscriber device 110. HN SEAF

[0132] Upon receiving the tupleservice network 130 retainsHxRES *, xR , R , K and forwards the tuple MAC *HN SEAF , RHN , ID SN to subscriber device 110.

[0133] (3) Subscriber device response and key confirmation:

[0134] Upon receiving the tuplesubscriber device 110 computes theresponse RES , cipher key CK , and integrity key IK using f 2 , f 3 , and f 4 respectively, alongwith the subscriber secret key k , shared secret key k UE , and the random challenge R as inputs.Subscriber device 110 then computes the session keysK SEAF and verifies the MAC * using K SEAF, HN’s challengeR HN , and ID SN .

[0135] If the verification fails, the connection may be aborted. If the verification is successful, it provides three functions: authenticity and integrity of network device 120’s challengeR HN ,confirmation of the session keyK SEAF , and verification of network device 120’s response to itschallenge R . Afterward, subscriber device 110 generates its response RES * and a messageauthentication code kcMAC using SHA256 , and sends the tuple kcMAC, RES * , ID SN toservice network 130. Note that kcMAC serves two purposes: verifying the response ofsubscriber device 110 to network device 120’s challengeR HN and confirming the session keysK SEAF to network device 120.

[0136] Upon receiving the response from subscriber device 110, service network 130 firstverifies HxRES with RES *, xR and R HN . It also verifies kcMAC with the session keys K SEAFandR HN . A successful verification indicates authentication of subscriber device 110 at servicenetwork 130 and session keyK SEAF confirmation. Next, service network 130 forwards the tuplekcMAC, RES * , R HN to network device 120, where R HN is sent for the binding purposes.

[0137] Upon receiving the tuple kcMAC, RES * , R , network device 120 verifies RES *HNwith xRES * and also kcMAC usingand R HN . A successful verification indicates mutualauthentication between subscriber device 110 and network device 120 and confirms the session keysK SEAF . Network device 120 then sends the tuple SUPI , SUCI to service network 130,where SUCI is used for binding purposes. Once service network 130 receives SUPI , theauthentication process is concluded, and subscriber device 110 can use the session keyK SEAF toaccess network services. Preferred second embodiment (Extension for Perfect Forward Secrecy)

[0138] Fig.6 provides a high-level overview of the preferred second embodiment, where dotted and solid arrows represent open channels and authenticated secure channels respectively. The preferred second embodiment may be considered to be an extension of the preferred first embodiment to further support PFS. The preferred second embodiment may provide PFS at the cost of minimal additional computational overhead. A notable difference in the preferred second embodiment is the introduction of an ephemeral Diffie-Hellman (DH) key exchange between subscriber device 110 and network device 120. The preferred second embodiment still supports all the security aspects of preferred first embodiment, which are confirmed by the formal analysis resented later in the disclosure.

[0139] The preferred second embodiment aims to maintain USIM compatibility without introducing new cryptographic operations. As such, the approach in the preferred second embodiment is to utilize the one of the one or more ciphersC 0 (i.e., the ECIES ephemeral publickey) as DH key material for computing a shared DH key between subscriber device 110 and network device 120. In Fig.6, it is shown that network device 120 employs the one or more ciphersxC 0 (i.e., C 0 ) to calculate a DH key dh key , using its random challenge R HN as the secretkey. Furthermore, network device 120 computes the DH key materialdh HN for subscriber device110 usingR HN , enabling subscriber device 110 to compute the same DH key dh key on its end.Subsequently, both subscriber device 110 and network device 120 derive the session keys (i.e.,K SEAF ) using the dh key , k UE , and ID SN .Formal Security Analysis

[0140] This section provides a detailed formal security analysis of the disclosed methods. A software tool for automated reasoning about the security properties of cryptographic protocols called ProVerif (https: / / bblanche.gitlabpages.inria.fr / proverif / ) was used to conduct the automated formal analysis, as it is easy to model a stateless protocol like the disclosed methods using ProVerif. It is noted that 5G-AKA is a stateful protocol due to its sequence number-based replay attack prevention mechanism, which makes it unsuitable for modelling using ProVerif. Consequently, most existing formal analyses of the 5G-AKA protocol are based on Tamarin (https: / / tamarin-prover.com / ), which supports stateful protocols.

[0141] ProVerif is a symbolic model-based tool that uses applied ^ -calculus syntax. Itoperates under the Dolev-Yao Attack Model, which grants the attacker the ability to read, modify,delete, and forge packets, as well as inject them into the public communication channel. ProVerif evaluates whether the designed protocol meets the defined security objectives within this attack model. When an attack is detected, ProVerif provides a comprehensive description of the steps involved in the attack. ProVerif is ideal for stateless protocols like the disclosed methods and for verifying a wide range of security properties under the Dolev-Yao model, including indistinguishability properties. Modelling Choices

[0142] In formal verification, modelling choices are useful in defining the behaviour, assumptions, and properties of the system to facilitate formal analysis. These choices abstractly represent the system or protocol under analysis. Before presenting the analysis, the modelling choices made for the disclosed methods will be briefly outlined to provide a better understanding of the modelled system.

[0143] Architecture: Three roles are considered: subscribers, service networks, and network devices. Each role can have an unbounded number of instances. The communication channels between subscriber device 110 and service network 130, and between service network 130 and network device 120, are considered open (or insecure) and authenticated private (or secure) channels, respectively.

[0144] Modelling Cryptographic Messages: Symmetric key-based encryption and decryptionoperations are modelled using the constructor senc for encryption and the destructor sdec fordecryption. The senc constructor takes two arguments: a message m of type bitstring and a keyn of type bitstring, and returns the encrypted message. The sdec destructor takes an encryptedmessage produced by senc and the corresponding key n , and returns the original message m .Additionally, cryptographic hash functions such as, and SHA256 are alsomodelled as constructors. Each hash function takes a single input argument of type bitstring and returns a bitstring as output.

[0145] The modular exponentiation operation (i.e., g x ) is modelled using the constructor exp .This constructor takes two arguments: g , a constant of type G (representing the generator of G), and x , an argument of type secKey . For modelling the Diffie-Hellman (DH) Key Exchange,the equation concept in ProVerif is utilised. The DH Key Exchange is represented by the equation: equation    ^x : secKey, y :secKey;exp( exp (g , x ) , y )= exp( exp ( g , y ) , x )

[0146] In addition, G _ to _ bitstring _ conversion ( G ) constructor is used to convert a G typeargument to bitstring.

[0147] Modeling of Active Attacker: In ProVerif, achieving the indistinguishability property entails ensuring that an active attacker cannot distinguish two different processes in the protocol execution. This is typically accomplished by designing the protocol in a manner that prevents any information leaked to the active attacker from providing an advantage in distinguishing between these processes. The concept of indistinguishability is represented using observational equivalence in ProVerif.

[0148] To model observational equivalence between two processes, the constructChoice ^ M,M' ^ is utilised, which provides a single biprocess encoding both processes. TheChoice ^ M,M' ^ encapsulates the terms that differ between the two processes: one process usesthe first component, M , while the other process uses the second one, M ' . For example, if twoprocesses contain terms out ( usch,a ) and out ( usch,b ) , and it is aimed to verify theirequivalence, the following biprocess can be employed in ProVerif: out( usch,choice ^ a,b ^ ) .Automated Verification Results

[0149] In this section, the formal analysis results are presented, which are based on the security aspects presented earlier in the disclosure. Table 1 displays the authentication, secrecy, and privacy goals presented earlier in the disclosure, all of which are supported by the disclosed methods.Table 1: Security Aspects Achieved by the disclosed methods. UE: Subscriber device 110; HN: Network device 120; SN: Service network 130; I: Injective agreement; wa: Weak agreement; NI: Non-injective agreement; x: Property supported; PFS: Perfect forward secrecy w.r.t subscriber secret key k .

[0150] Authentication: ProVerif provides correspondence assertions to capture the authentication or relationship between parties or events. Both basic and injective correspondence assertions are utilised to capture non-injective (which also covers weak agreement) and injective agreements between parties, respectively. A basic correspondence assertion appears as follows: query event (e ( X1, , X j ) ) ==^ eventwhere e , e ' are events, X 1, , Xn , Y 1 , , Y k are the terms, a 1, , a n are variables of types t 1, , t n .The above query is satisfied if, for each occurrence of the event e ( X1, , X n ) , there is aprevious execution of e' ( Y1 , , Y k ) .

[0151] On the other hand, the injective correspondence assertion appears as follows:inj− event    (e ( X1 , , X j ) ) ==^ inj − event    ( e ' ( Y 1 , , Y k ) )

[0152] This implies that there is a one-to-one relationship between the number of protocol runs performed by each participant. The injective correspondence assertion asserts that for eachoccurrence of event    e ( X1 , , X n ) , there is a distinct earlier occurrence of event    e '.

[0153] From Table 1, it is evident that the disclosed methods align with the security aspect goals discussed earlier in the disclosure. Specifically, the disclosed methods achieve injective agreements onK SEAF for each pair of parties. Moreover, the disclosed methods obtain non-injective agreements onID SN between subscriber device 110 and network device 120, andservice network 130 achieves non-injective agreement on SUPI with network device 120.

[0154] Secrecy: The reachability property of ProVerif is leveraged to demonstrate the secrecy of the disclosed methods. The reachability property enables the ProVerif tool to automaticallysearch for any terms accessible to an attacker. Therefore, if a term, e.g., X , is accessible to anattacker, ProVerif can help identify the attack vector. To prove the secrecy ofK SEAF , SUPI , andk , the following queries are employed:query    attacker     (SUPI ) .

[0155] Perfect Forward Secrecy (PFS): ProVerif’s modelling features referred to as Phases isutilised. The objective is to demonstrate that, even if a participant’s secret keys are compromised, the confidentiality of previously exchanged secrets remains intact. In ProVerif,corruption is illustrated by revealing the secret keys of corrupted participants during Phase1 ,while ensuring the confidentiality of Phase0 sessions. In the disclosed methods, Phase1 exposesthe subscriber secret key k , SUPI of subscriber device 110 and the private key sk HN of networkdevice 120 to the attacker. The formal security analysis demonstrates that despite the attackergaining access to k , SUPI , and network device 120’s private key sk HN in Phase 1, theconfidentiality of the session keys,K SEAF , remains preserved. This demonstrates that thedisclosed methods offer PFS.

[0156] Privacy: ProVerif utilizes the concept of observational equivalence to rigorously assess the indistinguishability property within the formal model of a protocol. As previously explained,the Choice construct is employed to establish observational equivalence between two processesinvolving the same subscriber. The analysis reveals that these two processes exhibit equivalence, implying they possess identical structures and differ only in the selection of terms. This finding suggests that an active attacker cannot distinguish between these distinct processes during protocol execution. Hence, the disclosed methods support protection against active attackers. Performance Analysis

[0157] In this section, a detailed comparison of the disclosed methods with the 3GPP standardized 5G-AKA protocol and an improved version of the 5G-AKA protocol (denoted as5G-AKA ' ) is presented.Theoretical Comparison

[0158] In this section, a theoretical comparison between the disclosed methods with the 3GPPstandardized 5G-AKA and 5G-AKA ' is presented.

[0159] Table 2 shows a comparison between the disclosed methods with others in terms of the number of messages exchanged between entities in each protocol. Since neither of disclosed methods uses sequence numbers, they do not utilise a sequence number resynchronization phase. As a result, the disclosed methods can be completed with only seven messages exchanged among subscriber device 110, network device 120 and service network 130. In contrast, 5G-AKA and5G-AKA ' require 13 and 9 messages, respectively, when sequence number synchronization isnecessary and when it is not. It is evident that disclosed methods use fewer message exchanges between entities, thereby reducing overall communication overhead. However, both of disclosedmethods send additional parameters compared to 5G-AKA and 5G-AKA ' . Specifically, MAC issent from subscriber device 110 to service network 130, and then from service network 130 tonetwork device 120; MAC * and kcMAC are sent from service network 130 to subscriber device110; and finally,dh HN is sent from service network 130 to network device 120. The sizes ofMAC , MAC * , kcMAC , and dh HN are 32,32,32, and 64 bytes, respectively.Table 2: A Communication Overhead Comparison between the disclosed methods (Method 1 being the first preferred embodiment, and Method II being the second preferred embodiment) and 5G-AKA and 5G-AKA ' . *5G-AKA and 5G-AKA ' require 7 message interactions betweenthe parties for mutual authentication and an additional 2 messages for the anchor keyK SEAFconfirmation between subscriber device 110 and service network 130; NA: Not Applicable.

[0160] Fig.7 presents Table 3, which presents a comparison of the computation costs betweenthe disclosed methods and 5G-AKA and 5G-AKA ' . Method 1 being the first preferredembodiment, and Method II being the second preferred embodiment. The computation costs incurred by subscriber device 110, service network 130, and network device 120 is assessed during the execution of each protocol. Three scenarios are considered for 5G-AKA and 5G-AKA' : successful authentication (Case 1), Sync_Failure (Case 2), and MAC_Failure (Case 3). Thecomputation costs involved in completing the authentication process following these failurecases in 5G-AKA and 5G-AKA ' are also accounted. Since the disclosed methods do not utilisesequence numbers to prevent replay attacks, unlike 5G-AKA and 5G-AKA ' , they do not requirehandling these latter two cases.T h , T m , T enc , T xor , T add , T prf , and T dec are represented as the timerequired to complete the computation of one hash / KDF / MAC, elliptic curve scalar multiplication, encryption, XOR, addition operation, random number generation, and decryption operations, respectively. As shown in Table 3, the disclosed methods incur substantially lowercomputation costs in Cases 2 and 3 compared to both 5G-AKA and 5G-AKA ' . Additionally, thedisclosed methods have minimal or comparable computation costs in Case 1 when comparedwith 5G-AKA and 5G-AKA ' .Experimental Results

[0161] The disclosed methods as well as 5G-AKA and 5G-AKA ' were implemented tocompare their computation times at the sides of subscriber device 110, service network 130, and network device 120. The simulations for service network 130 and network device 120 were conducted on a Windows Desktop machine with Windows 11 (64-bit), a 3.6 GHz Intel Core i7 processor, and 16 GB of memory. Subscriber device 110 was simulated using the iPhone 13 Simulator on a MacBook Pro running macOS Sonoma 14.6.1.

[0162] The Crypto++ cryptographic library (https: / / www.cryptopp.com / ) was used to implement ECIES with the secp256r1 curve. The Encryptor.Encrypt() and Decryptor.Decrypt() interfaces were modified to support the export and import of shared keys derived by ECIES.Additionally, SHA256 was employed with different prefixes as f1, f 2, f 3, f 4, f 5, f 1 * , f 5 * . Forkey derivation and message authentication, Password-Based Key Derivation Function 2(PBKDF2) and Hash-based Message Authentication Code (HMAC) were used for KDF andHMAC , respectively.

[0163] Table 4 presents the actual computation times for to complete their respectiveoperations. The results are averaged over 1000 trials and are reported in microseconds. From thetable, it is observed that in case 1, the disclosed methods incur comparable computation times bysubscriber device 110. 5G-AKA and 5G-AKA ' impose significantly higher computation costsby subscriber device 110 and network device 120 in case 2 and case 3, in comparison to case 1.Table 4: Computation Time (in microseconds) Comparison between (Method 1 being the first preferred embodiment, and Method II being the second preferred embodiment) and 5G-AKA and5G-AKA ' . UE: Subscriber device 110; HN: Network device 120; SN: Service network 130; NA:Not Applicable. Appendix A: Elliptic Curve Integrated Encryption (ECIES)

[0164] 5G uses ECIES cryptographic primitive to protect the unique identity of the subscribers. ECIES is a hybrid encryption method based on public key cryptography, comprising a Key Encapsulation Mechanism (KEM) and a Data Encapsulation Mechanism (DEM). In ECIES, the KEM is used to establish shared keys between the sender and recipient through public key cryptography. Subsequently, a DEM encrypts and decrypts the actual payload using symmetric cryptography with the shared key. The ECIES consists of the following algorithms.

[0165] KeyGen ( (sk, pk ) ^ pp ) : It takes an elliptic curve domain parameters pp as inputand outputs a private key sk and a public key pk , where sk^* q(a multiplicative group ofinteger modulo q ), pk = sk ^ g , and g is a generator of the chosen elliptic curve. 3GPPrecommends two elliptic curves Curve25519 and secp256r1. However, any elliptic curves may be used in the disclosed methods.

[0166] Encap( (C0 ,ks ) ^ pk ) : It takes the public key pk as input to generate an ephemeralprivate-public key pair (r, R ) , where r^Z *q and R= r ^ g . It sets C 0 = R and computes a sharedsecret keyk s , where ks = KDF ( r ^ pk ) .

[0167] Decap (ks ^ (C0 , sk ) ) : It takes C 0 and the private key sk as input and outputs theshared secret keyk s as follows ks = KDF C0 ) .

[0168] SEnc(k s , M ) ) : It takes the shared secret key k s and a message M asinput. It outputs two ciphertext components (C1, C 2 ) , where C1 = Enc (s 1 , M ) is the encryptedcomponent of the message M using a symmetric key encryption algorithm, andC2 = MAC is a message authentication code to check the integrity and authenticity of C 1.Here, are the leftmost and rightmost octets of the shared secret key k s .

[0169] SDec (M ^ (k s,It takes the shared secret key k s , C 1 , and C 2 as input. Itoutputs the actual message M as follows: It extracts (s1 ,s 2 ) from k s , verifies ifC2 = MAC (s 2 , C 1 ) , and if the verification is successful, decrypts C 1 to obtain M usingDec (s1 , C 1 ) .Appendix B: Detailed Description of 5G-AKA Protocol

[0170] A detailed description of the 5G-AKA protocol is now provided. The 5G-AKA protocol starts with the Initiation phase, followed by the Challenge-Response, Sequence Number Re-synchronization, and MAC Failure phases.

[0171] (1) Initiation:

[0172] This phase starts once the session between subscriber device 110 and service network130 is initialized. Subscriber device 110 encrypts its unique identity SUPI with the public keyPK HN of network device 120 using ECIES and produces a ciphertext SUCI . Subscriber device110 then sends SUCI and the identity of network device 120, ID HN to service network 130.Afterward, service network 130 forwards the received SUCI to network device 120, adding itsown identityID SN . Upon receiving SUCI , network device 120 decrypts it using its own privatekeysk HN and retrieves SUPI , which helps network device 120 obtain the subscriber secret keyk and sequence number SQN HN associated with subscriber device 110’s SUPI from itsdatabase.

[0173] (2) Challenge-Response:

[0174] In this phase, subscriber device 110 and network device 120 mutually authenticate each other using a challenge-response method. Additionally, subscriber device 110 and service network 130 establish the session keys,K SEAF , for any further secure communication.

[0175] Network device 120 chooses a random challenge R and generates a tupleR , AUTN = CONC , MAC , HxRES , K SEAF , which is then sent to subscriber device 110. InCONC , network device 120 conceals the sequence number associated with subscriber device110SQN HN using the anonymous key AK derived from R and k . The MAC is computed forthe authentication and integrity checking of the random challenge R , using R , k , and SQN HN .Additionally, HxRES is computed by hashing R with the expected response xRES fromsubscriber device 110, which is computed using R and k . Finally, the session keys K SEAF arecomputed using k , R , ID SN , and SQN HN . Network device 120 also increments the sequencenumberSQN HN by 1 at the end.

[0176] After receiving the tuple R , AUTN , HxRES , K SEAF , service network 130 stores a copyof R , HxRES , K SEAF and forwards the tuple R , AUTN to subscriber device 110.

[0177] Upon receiving the tuple R , AUTN , subscriber device 110 computes an anonymouskey AK inside the USIM card using k and R , and uncovers the sequence number SQN HN fromthe CONC part of AUTN . Next, it checks MAC using R and SQN HN inside the USIM card. Ifthis check fails, it returns a MAC_Failure message, which is sent to service network 130 andgoes to the MAC Failure phase. If the check is successful, subscriber device 110 verifies the freshness ofSQN HN . If this verification fails, the USIM card returns AUTN = CONC, MAC * ,where CONC conceals the sequence number SQN UE , and sends the tupleSync _ Failure , AUTN to network device 120 to synchronize the sequence number. The re-synchronization process later will be presented later. If the freshness check is successful, the USIM card setsSQN UE to SQN HN , computes the session keys K SEAF using k , R , ID SN , andSQN HN , and finally returns the tuple KSEAF , RES . Subscriber device 110 keeps K SEAF andsends RES to service network 130.

[0178] After receiving RES , service network 130 compares the hash of RES and R withHxRES . If successful, service network 130 forwards RES to network device 120, which thencompares RES with its stored xRES . If this comparison is successful and subscriber device 110is authenticated, network device 120 sends the SUPI associated with subscriber device 110 toservice network 130. This concludes the 5G-AKA protocol execution for the current session.

[0179] It is noted that 3GPP TS 33.501 also specifies that subscriber device 110 and service network 130 should implicitly confirm the agreed keys and each other’s identities through the successful use of keys in subsequent procedures. This can be achieved with an additional key- confirmation round trip usingK SEAF .

[0180] (3) Sequence Number Re-synchronization:

[0181] This phase is initiated as a result of subscriber device 110 needing to re-synchronize its sequence number with network device 120. The primary purpose of using a sequence number- based freshness check is to prevent replay attacks. However, factors such as message loss or system failure may lead to a desynchronization between subscriber device 110’sSQN UE andnetwork device 120’sSQN HN .

[0182] When the freshness check fails, as previously mentioned, the USIM card returnsAUTN = CONC, MAC * , with CONC concealing the sequence number SQN UE . It then sendsthe tuple Sync _ Failure , AUTN to network device 120 to synchronize the sequence number.Upon receiving the Sync_ Failure message, service network 130 forwards the tupleSync _ Failure , AUTN , R , SUCI to network device 120. Subsequently, network device 120 de-conceals theSQN UE after verifying the message authentication code MAC * . If the verification issuccessful, network device 120 sets its sequence numberSQN HN to SQNUE + 1.

[0183] (4) MAC Failure:

[0184] This phase is initiated as a result of the MAC check fails in the Challenge-Responsephase. In this phase, subscriber device 110 simply returns a MAC - Failure message and goes tothe Initiation phase to restart the AKA protocol in a new session. Appendix C: Privacy Issues with 5G-AKA Protocol

[0185] In this section, the three main types of privacy-related attacks that can take place in the 5G-AKA protocol are briefly discussed. The three types of privacy-related attacks the 5G-AKA protocol is vulnerable to are: Failure Message Linkability Attack, Sequence Number Inference Attack, and Encrypted SUPI Replay Attack.

[0186] Failure Message Linkability Attack: The goal of this attack is to distinguish a targeted subscriber from others by analyzing the responses received after replaying records of R, AUTN to all subscribers in the vicinity. The targeted subscriber responds with aSync_ Failure message because the replayed message passes the initial MAC verification withthe correct subscriber secret key k but fails the freshness check SQN HN . In contrast, othersubscribers respond with a MAC_ Failure message, as the replayed message fails the MACverification due to a mismatched subscriber secret key k .

[0187] Sequence Number Inference Attack: The objective of this attack is to learn information about the targeted subscriber’s sequence numberSQN UE . The attacker replays previouslycaptured tuples R , AUTN multiple times and captures the returned CONC in theSync_ Failure messages. The attacker attempts to learn SQNi ^ SQN i + 1UE UE by performing anExclusive-OR operation between CONC i and CONCi + 1 , as both CONC i and CONCi + 1 haveconcealed their sequence numbers using the same anonymous key AK .

[0188] Encrypted SUPI Replay Attack: The goal of this attack is to distinguish the targetedsubscriber from others. In this attack, the attacker replays the captured SUCI during theInitiation phase to network device 120 in all subscriber sessions and waits for subscriber device 110s’ responses to the corresponding challenge messages from network device 120. The targetedsubscriber responds successfully, while the other subscribers reply with MAC - Failuremessages because the subscriber secret key k used to generate the MAC matches only for thetargeted subscriber and not for the others.

[0189] It will be appreciated by persons skilled in the art that numerous variations and / or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

1. CLAIMS:

1. A method for authenticating a subscriber device with a network device of a communication network, the method comprising: by the subscriber device: calculating a secret key by encrypting a subscriber challenge with a public key of the network device; calculating a subscriber challenge tag based on the subscriber challenge and the secret key; and sending a request for authentication to the network device, the request comprising the subscriber challenge tag and one or more ciphers determined from the subscriber challenge; by the network device: decrypting the one or more ciphers using a private key of the network device to determine the secret key and the subscriber challenge; verifying the subscriber challenge using the subscriber challenge tag with the secret key; and upon verification, calculating a session key based on a network challenge and the subscriber challenge, and calculating a network challenge tag based on the network challenge and the session key; sending a response to the request comprising the network challenge tag and response data that is based on the network challenge; by the subscriber device: calculating the session key based on the response data and the subscriber challenge; verifying that the response data corresponds to the request for authentication sent to the network device, using the network challenge tag with the session key; and upon verification, transmitting a notification to the network device to authenticate the subscriber device with the network device.

2. The method of claim 1, wherein the method further comprises: by the subscriber device, upon verifying the response data, calculating a key confirmation tag by hashing the response data with the session key calculated by the subscriber device, wherein the notification comprises the key confirmation tag.

3. The method of claim 2, wherein the method further comprises:by the network device, verifying the session key of the subscriber device using the key confirmation tag with the session key of the network device and the response data; and upon verification, authenticating the subscriber device with the network device.

4. The method of any one of the preceding claims, wherein the response data comprises the network challenge, and the subscriber device and the network device calculate the session key by applying a cryptographic function to the network challenge and the subscriber challenge.

5. The method of any one of the preceding claims, wherein calculating the subscriber challenge tag by the subscriber device comprises applying a cryptographic function to the subscriber challenge and the secret key; and calculating the network challenge tag by the network device comprises applying a cryptographic function to the network challenge and the session key.

6. The method of any one of the preceding claims, wherein the method further comprises: calculating one or more keys by encrypting the subscriber challenge using a different cryptographic function for each of the one or more keys, wherein the session key is calculated using the one or more keys.

7. The method of any one of the preceding claims, wherein the method further comprises: by the subscriber device, generating a network challenge response tag; by the network device, generating an expected network challenge response tag; verifying the network challenge response tag using the expected network challenge response tag; and upon verification, providing the network device with access to the notification from the subscriber device.

8. The method of claim 7, wherein the method further comprises by the network device, generating a subscriber challenge response tag, wherein the expected network challenge response tag is generated from the subscriber challenge response tag; and by the subscriber device, generating an expected subscriber challenge response tag, wherein the network challenge response tag is generated from the expected subscriber challenge response tag.

9. The method of claim 1, wherein the method further comprises, by the network device, calculating an encrypted network challenge by encrypting the network challenge and calculating a network challenge key by encrypting the network challenge with one of the one or more ciphers.

10. The method of claim 9, wherein the response data comprises the encrypted network challenge, and the subscriber device and the network device calculate the session key by applying a cryptographic function to the network challenge key and the secret key.

11. The method of claim 9 or 10, wherein calculating the subscriber challenge tag by the subscriber device comprises applying a cryptographic function to one of the one or more ciphers and the secret key; and calculating the network challenge tag by the network device comprises applying a cryptographic function to the network challenge key and the session key.

12. The method of any one of claims 9 to 11, wherein the method further comprises: calculating one or more keys by encrypting one of the one or more ciphers using a different cryptographic function for each of the one or more keys, wherein the session key is calculated using the one or more keys.

13. The method of any one of claims 9 to 12, wherein the method further comprises: by the subscriber device, generating a network challenge response tag using the network challenge key; by the network device, generating an expected network challenge response tag using the network challenge key; verifying the network challenge response tag using the expected network challenge response tag; and upon verification, providing the network device with access to the notification from the subscriber device.

14. The method of claim 13, wherein the method further comprises by the network device, generating a subscriber challenge response tag using one of the one or more ciphers, wherein the expected network challenge response tag is generated from the subscriber challenge response tag; andby the subscriber device, generating an expected subscriber challenge response tag using one of the one or more ciphers, wherein the network challenge response tag is generated from the expected subscriber challenge response tag.

15. The method of any one of the preceding claims, wherein calculating the encrypted network challenge and calculating a network challenge key is based on Diffie–Hellman (DH) key exchange protocol.

16. The method of any one of the preceding claims, wherein communication between the subscriber device and the network device occurs via a service network.

17. The method of claim 16, wherein the method further comprises: by the service network: receiving the response data and the session key from the network device; receiving a key confirmation tag from the subscriber device; verifying the session key of the subscriber device using the key confirmation tag with the session key of the network device and the response data; and upon verification, providing the network device with access to the notification from the subscriber device.

18. The method of any one of the preceding claims, wherein the subscriber challenge tag is based on encrypting the subscriber challenge with the secret key and a subscriber secret key, the subscriber secret key being indicative of a subscription to services provided by the network device.

19. The method of any one of the preceding claims, wherein encrypting is based on elliptic- curve cryptography.

20. A method for authenticating a subscriber device with a network device of a communication network, as performed by the subscriber device, the method comprising: calculating a secret key by encrypting a subscriber challenge with a public key of the network device; calculating a subscriber challenge tag based on the subscriber challenge and the secret key;sending a request for authentication to the network device, the request comprising the subscriber challenge tag and one or more ciphers determined from the subscriber challenge; receiving a response to the request from the network device, the response comprising a network challenge tag and response data that is based on a network challenge; calculating a session key based on the response data and the subscriber challenge; verifying that the response data corresponds to the request for authentication sent to the network device, using the network challenge tag with the session key; and upon verification, transmitting a notification to the network device to authenticate the subscriber device with the network device.

21. A method for authenticating a subscriber device with a network device of a communication network, as performed by the network device, the method comprising: receiving a request for authentication from the subscriber device, the request comprising a subscriber challenge tag and one or more ciphers determined from a subscriber challenge; decrypting the one or more ciphers using a private key of the network device to determine a secret key and the subscriber challenge; verifying the subscriber challenge using the subscriber challenge tag with the secret key; upon verification, calculating a session key based on a network challenge and the subscriber challenge, and calculating a network challenge tag based on the network challenge and the session key; and sending a response to the request comprising the network challenge tag and response data that is based on the network challenge; and authenticating the subscriber device upon receiving a notification from the subscriber device based on the response.

22. Software that, when executed by a computer, causes the computer to perform the method of any one of the preceding claims.

23. A system for authenticating a subscriber device with a network device of a communication network, the system comprising one or more processors configured to perform the method of any one of claims 1 to 21.

Images