AU2024259751B1 - Attack resistant authentication - Google Patents
Attack resistant authenticationInfo
- Publication number
- AU2024259751B1 AU2024259751B1 AU2024259751A AU2024259751A AU2024259751B1 AU 2024259751 B1 AU2024259751 B1 AU 2024259751B1 AU 2024259751 A AU2024259751 A AU 2024259751A AU 2024259751 A AU2024259751 A AU 2024259751A AU 2024259751 B1 AU2024259751 B1 AU 2024259751B1
- Authority
- AU
- Australia
- Prior art keywords
- subscriber
- challenge
- network
- tag
- key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
- H04W12/69—Identity-dependent
- H04W12/72—Subscriber identity
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
#$%^&*AU2024259751B120250814.pdf#####
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.
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.
20
24
25
97
51
06
N
ov
2
02
4
A
B
S
T
R
A
C
T
2
0
2
4
2
5
9
7
5
1
0
6
N
o
v
2
0
2
4
T
h
i
s
d
i
s
c
l
o
s
u
r
e
r
e
l
a
t
e
s
t
o
a
u
t
h
e
n
t
i
c
a
t
i
n
g
a
s
u
b
s
c
r
i
b
e
r
d
e
v
i
c
e
w
i
t
h
a
n
e
t
w
o
r
k
d
e
v
i
c
e
o
f
a
c
o
m
m
u
n
i
c
a
t
i
o
n
n
e
t
w
o
r
k
.
T
h
e
s
u
b
s
c
r
i
b
e
r
d
e
v
i
c
e
c
a
l
c
u
l
a
t
e
s
a
s
e
c
r
e
t
k
e
y
b
y
e
n
c
r
y
p
t
i
n
g
a
s
u
b
s
c
r
i
b
e
r
c
h
a
l
l
e
n
g
e
w
i
t
h
a
p
u
b
l
i
c
k
e
y
o
f
t
h
e
n
e
t
w
o
r
k
d
e
v
i
c
e
;
c
a
l
c
u
l
a
t
e
s
a
s
u
b
s
c
r
i
b
e
r
c
h
a
l
l
e
n
g
e
t
a
g
;
a
n
d
s
e
n
d
s
a
r
e
q
u
e
s
t
f
o
r
a
u
t
h
e
n
t
i
c
a
t
i
o
n
t
o
t
h
e
n
e
t
w
o
r
k
d
e
v
i
c
e
.
T
h
e
n
e
t
w
o
r
k
d
e
v
i
c
e
d
e
c
r
y
p
t
s
t
h
e
o
n
e
o
r
m
o
r
e
c
i
p
h
e
r
s
f
r
o
m
t
h
e
r
e
q
u
e
s
t
t
o
d
e
t
e
r
m
i
n
e
t
h
e
s
e
c
r
e
t
k
e
y
a
n
d
t
h
e
s
u
b
s
c
r
i
b
e
r
c
h
a
l
l
e
n
g
e
;
v
e
r
i
f
i
e
s
t
h
e
s
u
b
s
c
r
i
b
e
r
c
h
a
l
l
e
n
g
e
u
s
i
n
g
t
h
e
s
u
b
s
c
r
i
b
e
r
c
h
a
l
l
e
n
g
e
t
a
g
;
u
p
o
n
v
e
r
i
f
i
c
a
t
i
o
n
,
c
a
l
c
u
l
a
t
e
s
a
s
e
s
s
i
o
n
k
e
y
b
a
s
e
d
o
n
a
n
e
t
w
o
r
k
c
h
a
l
l
e
n
g
e
a
n
d
t
h
e
s
u
b
s
c
r
i
b
e
r
c
h
a
l
l
e
n
g
e
;
c
a
l
c
u
l
a
t
e
s
a
n
e
t
w
o
r
k
c
h
a
l
l
e
n
g
e
t
a
g
;
a
n
d
s
e
n
d
s
a
r
e
s
p
o
n
s
e
t
o
t
h
e
r
e
q
u
e
s
t
.
T
h
e
s
u
b
s
c
r
i
b
e
r
d
e
v
i
c
e
t
h
e
n
c
a
l
c
u
l
a
t
e
s
t
h
e
s
e
s
s
i
o
n
k
e
y
f
r
o
m
t
h
e
r
e
s
p
o
n
s
e
;
v
e
r
i
f
i
e
s
t
h
a
t
t
h
e
r
e
s
p
o
n
s
e
d
a
t
a
c
o
r
r
e
s
p
o
n
d
s
t
o
t
h
e
r
e
q
u
e
s
t
f
o
r
a
u
t
h
e
n
t
i
c
a
t
i
o
n
s
e
n
t
t
o
t
h
e
n
e
t
w
o
r
k
d
e
v
i
c
e
;
a
n
d
u
p
o
n
v
e
r
i
f
i
c
a
t
i
o
n
,
t
r
a
n
s
m
i
t
s
a
n
o
t
i
f
i
c
a
t
i
o
n
t
o
a
u
t
h
e
n
t
i
c
a
t
e
t
h
e
s
u
b
s
c
r
i
b
e
r
d
e
v
i
c
e
w
i
t
h
t
h
e
n
e
t
w
o
r
k
d
e
v
i
c
e
.
Description
MARKED-UP COPY 1
"Attack resistant authentication" 07 Jul 2025
Cross-Reference to Related Applications
[0001] The present application claims priority from Australian Provisional Patent Application No 2024902698 filed on 29 August 2024, the contents of which are incorporated herein by reference in their entirety. 2024259751
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 field relevant to the present disclosure as it existed before the priority date of each of the appended claims.
MARKED-UP COPY 2
[0006] Throughout this specification the word “comprise”, or variations such as “comprises” or 07 Jul 2025
“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 2024259751
[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 equipped with a universal subscriber identity module (USIM): calculating a secret key by encrypting a subscriber challenge with a public key of the network device; calculating a subscriber challenge tag by encrypting the subscriber challenge with the secret key and a subscriber secret key obtained from the USIM, the subscriber secret key being indicative of a subscription to services provided by the network device; 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; 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
MARKED-UP COPY 3
by the subscriber device: 07 Jul 2025
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. 2024259751
[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
MARKED-UP COPY 4
calculating the network challenge tag by the network device comprises applying a cryptographic 07 Jul 2025
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. 2024259751
[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.
MARKED-UP COPY 5
[0020] In some embodiments, communication between the subscriber device and the network 07 Jul 2025
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; 2024259751
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 equipped with a universal subscriber identity module (USIM), 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 by encrypting the subscriber challenge with the secret key and a subscriber secret key obtained from the USIM, the subscriber secret key being indicative of a subscription to services provided by the network device; 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
MARKED-UP COPY 6
upon verification, transmitting a notification to the network device to authenticate the 07 Jul 2025
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 equipped with a 2024259751
universal subscriber identity module (USIM), the request comprising a subscriber challenge tag and one or more ciphers determined from a subscriber challenge, the subscriber challenge tag being based on encrypting the subscriber challenge with a secret key and a subscriber secret key obtained from the USIM, the subscriber secret key being indicative of a subscription to services provided 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; 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.
MARKED-UP COPY 7
Brief Description of Drawings 07 Jul 2025
[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. 2024259751
[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 between the 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, (e.g., the Fifth-Generation (5G) mobile network technology), Wi-Fi, WiMax, and satellite networks. However, the system and methods
MARKED-UP COPY 8
disclosed herein are especially applicable to mobile network communication. In particular, the 07 Jul 2025
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 standards related to 5G. One such standard is the 5G-AKA (5G-Authentication and Key Agreement), 2024259751
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.
MARKED-UP COPY 9
[0042] Two primary reasons in the 5G-AKA protocol may be the cause of its lack of resistance 07 Jul 2025
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 sequence number-based replay attack prevention mechanism. However, the freshness check relies on a 2024259751
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).
MARKED-UP COPY 10
[0046] Some embodiments of the methods described herein can also be extended to support 07 Jul 2025
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 may be efficiently introduced along with the modified challenge-response process. This extension supports all the security aspects, including resistance to both passive and active attacks. 2024259751
[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
MARKED-UP COPY 11
communicate with memory 113 by communicating with non-volatile memory 114 and/or volatile 07 Jul 2025
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 2024259751
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. 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. 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.
MARKED-UP COPY 12
[0053] Once executed, software may cause processor 112 to calculate a secret key, calculate a 07 Jul 2025
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 subscriber challenge, calculate a session key, send a response to the request and authenticate subscriber device 110 with network device 120. 2024259751
[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
MARKED-UP COPY 13
[0056] Fig. 2 illustrates an example embodiment of a method for authenticating subscriber 07 Jul 2025
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 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 114, which causes processor 112 (or multiple processors or a distributed computing 2024259751
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 firstly calculates 201 a secret key ( kUE ) by encrypting a subscriber
challenge ( R ) with a public key of the network device ( PK HN ). The subscriber challenge ( R )
may be a numerical value such as a large integer, a hexadecimal value or the like, which processor 112 may generate randomly or otherwise. The subscriber challenge ( R ) may also be a hash value, for example. 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 key of the network device 120 may be based on symmetric-key encryption. Encrypting the subscriber challenge ( R ) with the public key of the network device ( PK HN ) ensures that only
the network device 120 can determine the subscriber challenge ( R ), as only network device 120 contains the private key.
[0059] Processor 112 may encrypt the subscriber challenge ( R ) with the public key of the network device ( PK HN ) by applying an algorithm or mathematical operation to the subscriber
challenge ( R ) with the public key of the network device ( PK HN ). For example, processor 112
may encrypt the subscriber challenge ( R ) by multiplying the subscriber challenge ( R ) with the public key of the network device ( PK HN ). As such, the secret key ( kUE ) may be based on a
product of the subscriber challenge ( R ) with the public key of the network device ( PK HN ). In
some examples, processor 112 may encrypt the subscriber challenge ( R ) using a sum of the
MARKED-UP COPY 14
subscriber challenge ( R ) and the public key of the network device ( PK HN ). Processor 112 may 07 Jul 2025
also calculate 201 the secret key ( kUE ) by applying a mathematical function to a product or sum
of 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. 2024259751
[0060] Processor 112 then calculates 202 a subscriber challenge tag ( MAC ) based on the subscriber challenge ( R ) and the secret key ( kUE ). Subscriber challenge tag ( MAC ) may also be
referred to an authentication tag, which may be used to verify the subscriber challenge ( R ). The refence 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 this disclosure, may be a message authentication code, for example. However, it is noted that the tags disclosed 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 an algorithm or mathematical operation to the subscriber challenge ( R ) and the secret key ( kUE ).
For example, applying a mathematical function (such as a cryptographical function or a hash function) to a tuple of the subscriber challenge ( R ) and the secret key ( kUE ). Processor 112 may
also calculate 202 the subscriber challenge tag ( MAC ) using a product or sum of the subscriber challenge ( R ) and the secret key ( kUE ). Processor 112 may also calculate 202 the subscriber
challenge tag ( MAC ) using other quantities, such as, an identifier of service network 130 (in embodiments 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 then sends 203 a request for authentication to network device 120. The request comprises the subscriber challenge tag ( MAC ) and one or more ciphers ( C0 , C1 )
determined from the subscriber challenge ( R ). The request may also comprise further tags (such as authentication tags) for verifying the one or more ciphers ( C0 , C1 ), for example. Any of the
MARKED-UP COPY 15
one or more ciphers ( C0 , C1 ) may be referred to as an ephemeral public-key component, 07 Jul 2025
ciphertext component, or an encrypted component. In some examples, processor 112 may determine the one or more ciphers ( C0 , C1 ) by encrypting the subscriber challenge ( R ). In some
examples, processor 112 may determine the one or more ciphers ( C0 , C1 ) from the secret key (
kUE ) which is calculated from the subscriber challenge ( R ). In some examples, the one or more
ciphers ( C0 , C1 ) may be part or a component of the secret key ( kUE ), such as the first or last 8 2024259751
bits of the secret key ( kUE ). The one or more ciphers ( C0 , C1 ) may also be determined using a
user identifier ( SUPI ) of user 111.
[0063] The user identifier ( SUPI ) is a unique identifier used in wireless communication networks, 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. The request for authentication may also comprise an encrypted user identifier ( SUCI ), which is an encrypted (or concealed) version of the SUPI . The encrypted user identifier ( SUCI ) may be referred to as a Subscription Concealed Identifier. The SUCI may be used by network device 120 to help identify user 111. Processor 112 may calculate the encrypted user identifier ( SUCI ) using the one or more ciphers ( C0 , C1 ), particularly if the one or more ciphers ( C0 , C1 ) are
determined using the user identifier ( SUPI ).
[0064] Processor 112 then receives 204 a response to the request from the network device 120. The response comprises a network challenge tag ( MAC * ) and response data ( RHN or dhHN ) that
is based on a network challenge ( RHN ). For example, the response data may be the network
challenge ( RHN ), which may be generated by network device 120, or other data indicative of the
network challenge ( RHN ), such as an encrypted version of the network challenge ( RHN ). The
network challenge ( RHN ) may be a numerical value such as a large integer, a hexadecimal value
or the like, which processor 122 may generate randomly or otherwise. The network challenge ( RHN ) 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 ( RHN ) based on the request for
MARKED-UP COPY 16
authentication, which is based on the subscriber challenge ( R ). The response may comprise 07 Jul 2025
other quantities, such as, an identifier of service network 130 (in embodiments where system 100 comprises service network 130).
[0066] Processor 112 then calculates 205 a session key ( K SEAF ) based on the response data (
RHN or dhHN ) and the subscriber challenge ( R ). The session key ( K SEAF ) may be used to encrypt 2024259751
all 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 device
110 and network device 120). The session key ( K SEAF ) may be referred to as an anchor key
and/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 ( RHN or dhHN )
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 hash
function) to a tuple of the response data ( RHN or dhHN ) and the subscriber challenge ( R ).
Processor 112 may also calculate 205 the session key ( K SEAF ) using other quantities, such as the
secret key ( kUE ) and an identifier of service network 130 (in embodiments where system 100
comprises service network 130).
[0068] Processor 112 then verifies 206 that the response data ( RHN or dhHN ) corresponds to the
request for authentication sent to network device 120. Processor 112 verifies 206 the response data ( RHN or dhHN ) using the network challenge tag ( MAC * ) with the session key ( K SEAF ). For
example, processor 112 may calculate a network challenge tag using the response data ( RHN or dhHN ) and the session key ( K SEAF ), and compare the calculated network challenge tag to
the network challenge tag ( MAC * ) received from network device 120. The network challenge tag 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 network challenge tag calculated by processor 112 matches network challenge tag ( MAC * ) received from network device 120, then processor 112 then verifies 206 that the response data ( RHN or dhHN ) indeed corresponds to the request for authentication sent to network device 120.
Otherwise, the verification may fail, and the session may be aborted.
MARKED-UP COPY 17
[0069] Finally, upon verification, processor 112 transmits 207 a notification to network device 07 Jul 2025
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 enable subscriber 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 2024259751
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 quantities received 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 device 110. The request comprises a subscriber challenge tag ( MAC ) and one or more ciphers (
MARKED-UP COPY 18
xC0 , xC1 ) determined from a subscriber challenge ( R ). The request may also comprise other 07 Jul 2025
quantities, such as further tags (e.g., authentication tags) for verify the one or more ciphers ( xC0 , xC1 ). The request for authentication may comprise the encrypted user identifier ( SUCI ).
[0074] Processor 122 then decrypts 302 the one or more ciphers ( xC0 , xC1 ) using a private key
of the network device ( sk HN ) to determine a secret key ( xkUE ) and the subscriber challenge ( xR 2024259751
). By decrypting 302 the one or more ciphers ( xC0 , xC1 ), processor 122 may calculate the secret
key ( xkUE ) and/or the subscriber challenge ( xR ). It is noted that the private key of the network
device ( sk HN ) may be cryptographically linked (or coupled) to the public key of the network
device ( PK HN ) described earlier in relation to method 200. Hence, ideally, only network device
120 can decrypt the one or more ciphers ( xC0 , xC1 ) as only network device 120 should comprise
the private key of the network device ( sk HN ) .
[0075] Processor 122 may decrypt 302 the one or more ciphers ( xC0 , xC1 ) by applying an
algorithm or a mathematical operation to the one or more ciphers ( xC0 , xC1 ) and the private key
of the network device ( sk HN ). For example, processor 122 may calculate a product or sum of one
of the one or more ciphers ( xC0 , xC1 ) and the private key of the network device ( sk HN ) to
determine the secret key ( xkUE ), thereby decrypting 302 the one or more ciphers ( xC0 , xC1 ).
Processor 122 may decrypt 302 the one or more ciphers ( xC0 , xC1 )) using the secret key ( xkUE ).
For example, processor 122 may decrypt 302 one cipher ( xC0 ) to determine the secret key ( xkUE
) and use the secret key ( xkUE ) or apart thereof to decrypt 302 the other cipher ( xC1 ). The one or
more ciphers ( xC0 , xC1 ) may be determined from the user identifier ( SUPI ) of user 111. Hence,
by decrypting 302 the one or more ciphers ( xC0 , xC1 ), processor 122 may also determine the
user identifier ( SUPI ). Processor 122 may use the user identifier ( SUPI ) to identify user 111 and determine whether user 111 is a subscriber of the communication network.
[0076] Processor 122 then verifies 303 the subscriber challenge ( xR ) using the subscriber challenge tag ( MAC ) with the secret key ( xkUE ). “Verify” in this context may refer to verifying
that the subscriber challenge ( xR ) calculated by network device 120 is equivalent to the subscriber challenge ( R ) generated by subscriber device 110. In other words, processor 122 then
MARKED-UP COPY 19
verifies 303 the subscriber challenge ( xR ) originates from subscriber device 110. In some 07 Jul 2025
examples, processor 122 may calculate its own subscriber challenge tag using the subscriber challenge ( xR ) and the secret key ( xkUE ) that it has determined. Processor 122 may then
compare its own subscriber challenge tag to the subscriber challenge tag ( MAC ) received from subscriber device 110. If processor 122 determines that its own subscriber challenge tag and the subscriber challenge tag ( MAC ) received from subscriber device 110 are a match, then 2024259751
processor 122 may verify the subscriber challenge ( xR ). Otherwise, the verification may fail, and the session may be aborted.
[0077] Upon verification, processor 122 calculates 304 a session key ( K SEAF ) based on a
network challenge ( RHN ) and the subscriber challenge ( xR ). Similar to method 200, calculating
304 a session key ( K SEAF ) based on a network challenge ( RHN ) and the subscriber challenge ( xR
) mutually binds the network challenge ( RHN ) and the subscriber challenge ( xR ), which
enhances 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 ( RHN ) and
the subscriber challenge ( xR ). Processor 122 may calculate 304 a session key ( K SEAF ) using
other 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 the network challenge ( RHN ) and the session key ( K SEAF ), upon verification. The network challenge
tag ( MAC * ) may be used by subscriber device 110 to verify the network challenge ( RHN )
received from network device 120. Subscriber device 110 may also use the network challenge tag ( MAC * ) to verify that the received network challenge ( RHN ) is based on its own generated
subscriber challenge ( R ). In other words, subscriber device 110 may use the network challenge tag ( MAC * ) to verify that the received network challenge ( RHN ) is based on the initial request
for authentication.
[0079] Processor 122 then sends 306 a response to the request (for authentication) to subscriber device 110. The response comprises the network challenge tag ( MAC * ) and response data ( RHN or dhHN ) that is based on the network challenge ( RHN ). For example, the response data (
RHN or dhHN ) may be the network challenge ( RHN ). However, as will be later discussed, in some
MARKED-UP COPY 20
embodiments, the response data ( RHN or dhHN ) is an encrypted version of the network challenge 07 Jul 2025
[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 2024259751
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 device 110. In some examples, processor 122 may send the user identifier ( SUPI ) and/or the encrypted user identifier ( SUPI ) to service network 130 to authenticate subscriber device 110. (in embodiments where system 100 comprises service network 130).
Explicit key confirmation
[0081] In some embodiments, upon verifying the response data ( RHN or dhHN ), processor 112
of subscriber device 110 calculates a key confirmation tag ( kcMac ) by hashing the response data ( RHN or dhHN ) with the session key ( K SEAF ) calculated by the subscriber device. Processor 112
may hash the response data ( RHN or dhHN ) with the session key ( K SEAF ) by applying a hash
function (such as SHA256 or an equivalent hash function) to the response data ( RHN or dhHN )
with the session key ( K SEAF ). As such, the key confirmation tag ( kcMac ) may be considered to
be a hash or hash value. Further, the notification transmitted 207 by processor 112 may comprise the key confirmation tag ( kcMac ). The key confirmation tag ( kcMac ) may be used to verify that both 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 easier implemented in the disclosed methods as the additional challenge provided by subscriber device 110 (i.e., the subscriber challenge ( R )) may provide this additional 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).
MARKED-UP COPY 21
[0083] In some embodiments, processor 122 of network device 120 may receive the key 07 Jul 2025
confirmation tag ( kcMac ) with the notification received from subscriber device 110. Processor 122 may then verifies the session key ( K SEAF ) of subscriber device 110 using the ( kcMac ) with
the session key ( K SEAF ) of network device 120 and the response data ( RHN or dhHN ). Processor
122 may verify the session key ( K SEAF ) of subscriber device 110 by calculating its own key
confirmation tag using its own session key ( K SEAF ) and the response data ( RHN or dhHN ) that 2024259751
itself 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 ( RHN or dhHN ) with the session key ( K SEAF ). Upon verification, processor 122 then authenticates
307 subscriber 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 first embodiment, the response data ( RHN or dhHN ) comprises the network challenge ( RHN ). As such,
at 204 of method, subscriber device 110 (more specifically, processor 112) receives the network challenge ( RHN ), rather than an encrypted version of the network challenge ( RHN ), 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 ( RHN ) and
the subscriber challenge ( R ). For example, the respective processors 112, 122 of subscriber device 110 and network device 120 may calculate the session key ( K SEAF ) by applying a
cryptographic function to a tuple of the network challenge ( RHN ) and the subscriber challenge (
[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 may calculate 202 the subscriber challenge tag ( MAC ) by applying a cryptographic function to the
MARKED-UP COPY 22
subscriber challenge ( R ) and the secret key ( kUE ). Further, processor 122 of network device 120 07 Jul 2025
may calculate 305 the network challenge tag ( MAC * ) by applying a cryptographic function to the network challenge ( RHN ) and the session key ( K SEAF ). In these examples, the cryptographic
functions using by processor 112 and processor 122 may be the same or different cryptographical functions. 2024259751
[0087] In some examples of the first embodiment, processor 112 of subscriber device 110 may calculate one or more keys ( CK , IK ) by encrypting the subscriber challenge ( R ) using a different 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 encrypting
the subscriber challenge ( R ) and the secret key ( kUE ). Similarly, processor 122 of network
device 120 may calculate one or more keys ( CK , IK ) by encrypting the subscriber challenge (
xR ), determined by decrypting 302 the one or more ciphers ( xC0 , xC1 ), using a different
cryptographic function for each of the one or more keys ( CK , IK ). It is noted that the different cryptographic functions may be a similar, yet different, function. For example, the cryptographic function used to calculate one of the one or more keys ( CK ) may be Keccak-256 and the cryptographic function used to calculate another one of the one or more keys ( IK ) may be SHA256. However, in some examples, processor 112 of subscriber device 110 may calculate one or more keys ( CK , IK ) by encrypting the subscriber challenge ( R ) using the same cryptographic function for each of the one or more keys ( CK , IK ) and a different input. For example, an input to calculate one key ( CK ) may be a bit (0 or 1), while an input to calculate the 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 may
calculate 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 one or 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 of other authentication protocols, such as the 5G-AKA protocol.
MARKED-UP COPY 23
[0089] In some examples of the first embodiment, processor 112 of subscriber device 110 may 07 Jul 2025
generate a network challenge response tag ( RES * ). Similarly, processor 122 of network device 120 may generate an expected network challenge response tag ( xRES * ). The network challenge response tag ( RES * ) and the expected network challenge response tag ( xRES * ) may be used to verify 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 expected 2024259751
network challenge response tag ( xRES * ). Further, upon verification, processor 112, 122 may providing 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 network challenge response hash ( HxRES * ) by applying a hash function to the expected network challenge response tag ( xRES * ). In these examples, the expected network challenge response hash ( HxRES * ) may be used to verify the network challenge determined by subscriber device 110. Hashing the expected network challenge response tag ( xRES * ) may provide further security.
[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 receive network challenge response tag ( RES * ) and the expected network challenge response tag ( xRES * ) and verify the network challenge response tag ( RES * ) using the expected network challenge response tag ( xRES * ). Then, upon verification, service network 130 may providing network device 120 with access to the notification from subscriber device 110. In some examples, service network 130 may receive network challenge response tag ( RES * ) and an expected network challenge response hash ( HxRES * ) and verify the network challenge response tag ( RES * ) using the expected network challenge response hash ( HxRES * ).
[0091] In some examples of the first embodiment, processor 122 of network device 120 may generate a subscriber challenge response tag ( xRES ). Moreover, processor 122 may generate the expected network challenge response tag ( xRES * ) from the subscriber challenge response tag ( xRES ). Similarly, processor 112 of subscriber device 110 may generate an expected subscriber challenge response tag ( RES ). Moreover, processor 112 may generate the network challenge response tag ( RES * ) from the expected subscriber challenge response tag ( RES ). In these examples, processor 112, 122 or service network 130 may verify subscriber challenge response tag ( xRES ) using the expected subscriber challenge response tag ( RES ).
MARKED-UP COPY 24
Second embodiment of the methods 07 Jul 2025
[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 ( dhHN ) by encrypting the network challenge ( RHN ). Processor 122 also calculates calculating a
network challenge key ( dhkey ) by encrypting the network challenge ( RHN ) with one of the one or 2024259751
more ciphers ( xC0 ). As such, in the second embodiment, the response data ( RHN or dhHN )
comprises the encrypted network challenge ( dhHN ). By encrypting the network challenge ( RHN )
before sending the network challenge ( RHN ) to the subscriber device 110, this enhances the
security of the disclosed methods 200, 300. More particularly, encrypting the network challenge ( RHN ) provides perfect forward secrecy, as will be discussed later in the disclosure. It is noted
that 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 a
cryptographic function to the network challenge key ( dhkey ) and the secret key ( kUE ).
[0094] In some examples of the second embodiment, processor 112 of subscriber device 110 calculates 202 a subscriber challenge tag ( MAC ) by applying a cryptographic function to one of the one or more ciphers ( C0 ) and the secret key ( kUE ). Moreover, in some examples of the
second embodiment, processor 122 of network device 120 calculates 305 the network challenge tag ( MAC * ) by applying a cryptographic function to the network challenge key ( dhkey ) and the
session key ( K SEAF ).
[0095] In some examples of the second embodiment, processor 112, 122 may calculate one or more keys ( CK , IK ) by encrypting one of the one or more ciphers ( C0 or xC0 ) using a different
cryptographic function for each of the one or more keys ( CK , IK ). Moreover, in some examples
of the second embodiment, processor 112, 122 may calculate the session key ( K SEAF ) using the
one or more keys ( CK , IK ).
MARKED-UP COPY 25
[0096] In some examples of the second embodiment, processor 112 of subscriber device 110 07 Jul 2025
may generate a network challenge response tag ( RES * ) using the network challenge key ( dhkey ).
Similarly, in some examples of the second embodiment, processor 122 of network device 120 may generate an expected network challenge response tag ( xRES * ) using the network challenge key ( dhkey ). Similar to examples of the first embodiment, the expected network challenge
response tag ( xRES * ) may be used to verify the network challenge ( RHN ) received by 2024259751
subscriber device 110. Similar to examples of the first embodiment, processor 122 of network device 120 may generate an expected network challenge response hash ( HxRES * ) by applying a hash function to the expected network challenge response tag ( xRES * ), and the expected network challenge response tag ( xRES * ) may be used to verify the network challenge ( RHN )
received by subscriber device 110.
[0097] As such, in some examples of the second embodiment, processor 112, 122 may verify the network challenge response tag ( RES * ) using the expected network challenge response tag ( xRES * ). Then upon verification, processor 112, 122 may provide network device 120 with access to the notification from subscriber device 110. In these examples, service network 130 may verify the network challenge response tag ( RES * ) using the expected network challenge response tag ( xRES * ). Then upon verification, service network 130 may provide network device 120 with access to the notification from subscriber device 110. Similar to examples of the first embodiment, service network 130 may receive network challenge response tag ( RES * ) and an expected network challenge response hash ( HxRES * ) and verify the network challenge response tag ( RES * ) using the expected network challenge response hash ( HxRES * ).
[0098] In some examples of the second embodiment, processor 122 of network device 120 may generate 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 of the second embodiment, processor 112 of subscriber device 110 may generate an expected subscriber challenge response tag ( RES ) using one of the one or more ciphers ( C0 ). Similar, in
further examples, processor 112 may generate the network challenge response tag ( RES * ) from the expected subscriber challenge response tag ( RES ).
MARKED-UP COPY 26
[0099] In some examples of the second embodiment, processor 122 of network device 120 may 07 Jul 2025
calculate the encrypted network challenge ( dhHN ) and calculating a network challenge key ( dhkey
) 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 subsequent communications using a symmetric-key cipher. In other examples of the second embodiment, 2024259751
processor 122 of network device 120 may calculate the encrypted network challenge ( dhHN ) and
calculating a network challenge key ( dhkey ) based on other cryptographic protocols, such as, but
not 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 may receive the response data ( RHN or dhHN ) and the session key ( K SEAF ) from network device.
Service network 130 may also receive a key confirmation tag ( kcMac ) from subscriber device 110. Based on this, service network 130 may verify the session key ( K SEAF ) of subscriber device
MARKED-UP COPY 27
110 using the key confirmation tag ( kcMac ) with the session key ( K SEAF ) of network device 120 07 Jul 2025
and the response data ( RHN or dhHN ). Then upon verification, service network 130 may provide
network device 120 with access to the notification from subscriber device 110.
Elliptical curve cryptography 2024259751
[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 ( C0 ) by
encrypting the subscriber challenge ( R ). Encrypting the subscriber challenge ( R ) may be based on elliptic-curve cryptography, where one of the one or more ciphers ( C0 ) by a product of the
subscriber challenge ( R ) and a generator ( G ) of the elliptic curve. Symmetric keys may also be based on elliptic-curve cryptography, such as the public key of the network device ( PK HN )and
the private key of the network device ( sk HN ). Processor 112 may calculate another one of the one
or more ciphers ( C1 ) using encryption based on elliptic-curve cryptography. Similarly, processor
122 may decrypt 302 the one or more ciphers ( C0 , C1 ) based 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 the subscriber challenge tag ( MAC ) by encrypting the subscriber challenge ( R ) with the secret key ( kUE ) and a subscriber secret key ( k ). The subscriber secret key ( k ) may be indicative of a
subscription to services provided by network device 120. The subscriber secret key ( k ) may be referred to as a long-term secret key. As such, once network device 120 identifies subscriber device 110, processor 122 of network device 120 may determine the subscriber secret key ( k ) by retrieving the subscriber secret key ( k ) from a database based on an identifier of subscriber
MARKED-UP COPY 28
device 110, for example. Other quantities may be calculated using the subscriber secret key ( k ). 07 Jul 2025
For example, processor 112, 122 may calculate the one or more keys ( CK , IK ) using the subscriber secret key ( k ) as well as the other factors, such as the subscriber challenge ( R or xR ) and the secret key ( kUE or xkUE ).
5G-AKA Protocol 2024259751
[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 several cryptographic primitives such as hash functions f1, f2 , f3 , f4 , f5 , f1* , f5* , the Secure Hash
Algorithm-256 ( SHA256 ), the elliptic curve integrated encryption (ECIES) key encapsulation mechanism (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. 1. Initiation: In the Initiation phase, subscriber device 110 sends the encrypted SUPI using ECIES, which is represented as SUCI , to network device 120 via the radio channel through service network 130. 2. Challenge-Response: In the Challenge-Response phase, network device 120 chooses a random value R . It computes AUTN , which consists of the MAC for the R and the XOR ( ) of the sequence number SQN HN for privacy. Subscriber device 110 performs
two tasks upon receiving the challenge message from network device 120. First, it checks
MARKED-UP COPY 29
the MAC to authenticate and verify the integrity of the challenge R . Second, the SQN HN 07 Jul 2025
is used to check the freshness of the challenge R from network device 120 to prevent replay attacks. Subscriber device 110 checks the freshness of the challenge message by comparing the received SQN HN with its own sequence number SQNUE . It is noted that,
as per the 3GPP TS 33.50, SQN HN and SQNUE should remain synchronized at all times.
3. Sequence Number Re-synchronization: If this comparison of the sequence numbers fails, 2024259751
i.e., if SQN HN and SQNUE are unsynchronized, subscriber device 110 sends a Sync _ Failure message, along with AUTN , to network device 120 for re-
synchronization of its sequence number SQNUE 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 _ Failure message and returns to the Initiation phase to restart the process.
[0109] If both the MAC and SQN HN checks are successfully completed, subscriber device
110 generates a response message RES for the challenge R , computes the key material to generate the session keys (i.e., K SEAF ), and sends RES to network device 120. As mentioned
earlier, 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 that stores subscriber-related information, such as the subscriber secret key ( k ) and the unique identity of the subscriber (e.g., user 111 of system 100), which may be referred to as the
MARKED-UP COPY 30
Subscription Permanent Identifier ( SUPI ). Each subscriber may be registered with network 07 Jul 2025
device 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 authenticates subscribers, and UDM (Unified Data Management), which computes keying material and 2024259751
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 of network device 120, which recovers the plaintext SUPI of subscribers from its encrypted version SUCI . For simplicity and without compromising overall security, AUSF and UDM may be 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.
MARKED-UP COPY 31
[0114] Assumption on Cryptographic Functions: The disclosed methods may not require all 07 Jul 2025
the cryptographic primitives outlined in 3GPP TS 33.501. Instead, the disclosed methods may utilize a part of the cryptographic functions such as SHA256 , f1 , f 2 , f 3 , f 4 These cryptographic
functions are publicly available and provide confidentiality and integrity of their inputs. However, the disclosed method may not utilise the cryptographic functions f5 , f1* , f5* from the
5G-AKA protocol. Additionally, the Elliptic Curve Integrated Encryption method may be 2024259751
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 the honest subscribers are capable of protecting their session keys ( K SEAF ). However, in proving the
perfect forward secrecy property, a scenario is considered where the attacker has access to both the subscriber secret key ( k ) of the subscribers and the private key ( sk HN ) of network device
120.
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 methods may 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.
MARKED-UP COPY 32
• Secrecy: In the 3GPP TS 33.501, in addition to the secrecy of the SUPI and subscriber 07 Jul 2025
secret key ( k ), another security aspects is the secrecy of the session keys ( K SEAF ). The
5G-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. 2024259751
o Perfect Forward Secrecy (PFS): If the subscriber secret key ( k ) and the private key ( sk HN ) of network device 120 are compromised, the attacker must not be able
to compute any previously generated session keys ( K SEAF ).
• 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 on K SEAF and weak
agreement with each other. • Agreement between the subscriber device and the network device: Subscriber device 110 and network device 120 must achieve injective agreement regarding K SEAF and establish
a weak agreement with each other. Additionally, both the subscriber and network device 120 must achieve a non-injective agreement regarding IDSN with each other.
• Agreement between the service network and network device: Service network 130 and network device 120 must both achieve injective agreement on K SEAF and weak
agreement with each other. Service network 130 must also achieve a non-injective agreement on SUPI with network device 120.
MARKED-UP COPY 33
Preferred embodiments 07 Jul 2025
[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, all communication 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 2024259751
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 random challenge of network device 120 by checking the MAC . Subsequently, subscriber device 110 assesses the freshness of the challenge of network device 120 by comparing the sequence number SQNUE of subscriber device 110 with the sequence number SQN HN of network device
120. For instance, in the Encrypted SUPI Replay Attack, the attacker captures the SUCI of the targeted subscriber and replays it later. Consequently, the targeted subscriber responds to the challenge 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 by network device 120 to the targeted subscriber and replays them later. As a result, the targeted subscriber successfully verifies the MAC but fails to confirm freshness, responding with a Sync _ Failure message. Conversely, all other subscribers fail the MAC verification and respond
MARKED-UP COPY 34
with MAC _ Failure messages. Additionally, another type of privacy-related attack called the 07 Jul 2025
Sequence Number Inference Attack may occur in the 5G-AKA protocol by capturing R and AUTN and replaying them later.
Preferred first embodiment
[0122] Fig. 5 provides a high-level overview of the preferred first embodiment, where dotted 2024259751
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, f1 , f 2 , f 3 , f 4 , KDF and SHA256 , as
documented 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 to network 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 and generates a randomized encrypted SUPI for privacy protection using elliptic curve integrated encryption (ECIES), as outlined in Appendix A. The ECIES key encapsulation mechanism Encap ECIES generates a shared secret key kUE and one of the one or more ciphers C0 , which may
be referred to as an ephemeral public-key component. Concurrently, the data encryption mechanism of ECIES produces another one of the one or more ciphers C1 , which may be
referred to as an encrypted component, for the SUPI and the subscriber challenge R using symmetric key encryption. The s1 portion of the shared secret key kUE is used as the encryption
key, while the remaining s 2 portion creates a tag (i.e., message authentication code) MAC ECIES
for authenticity and integrity verification of C1 .
[0126] Secondly, a message authentication code MAC is computed for the subscriber challenge R . This may verify the authenticity and integrity of the subscriber challenge R .
MARKED-UP COPY 35
[0127] Finally, subscriber device 110 sends the tuple SUCI = C0 , C1 , MACECIES , MAC , IDHN 07 Jul 2025
to service network 130. Subsequently, service network 130 forwards the tuple SUCI , MAC, IDHN , IDSN to network device 120.
[0128] (2) Network challenge and response: 2024259751
[0129] In this phase, network device 120 performs broadly two tasks once network device 120 receives the tuple SUCI , MAC, IDHN , IDSN from subscriber device 110.
[0130] Firstly, network device 120 recovers the plaintext SUPI using its private key sk HN
from SUCI to retrieve the subscriber secret key k associated with subscriber device 110 from its database. Following the decapsulation operation of ECIES using its private key sk HN and the
one of the one or more ciphers C0 (i.e., the ephemeral public-key component) of SUCI , network
device 120 acquires the shared secret key xkUE . Subsequently, it decrypts C1 using xs1 (a
component of the shared secret xkUE ) after successfully verifying the tag (i.e., MAC ECIES ) using
xs2 (the second component of the shared secret xkUE ) and C1 , thus obtaining the plaintext SUPI
and the subscriber challenge xR .
[0131] Secondly, network device 120 verifies the authenticity and integrity of the subscriber challenge xR by checking the MAC . An unsuccessful verification results in a MAC _ Failure .
Once the verification is successful, network device 120 chooses a network challenge RHN for
subscriber device 110 and computes xRES , cipher key CK , and integrity key IK using the subscriber secret key k of subscriber device 110 and the subscriber challenge xR . It then generates the expected response from subscriber device 110 xRES * , and the session keys K SEAF .
Next, network device 120 computes the hashed response HxRES * , which includes the expected response xRES * , the subscriber challenge xR , and its challenge for subscriber device 110 RHN .
Additionally, network device 120 generates a message authentication code MAC* . Network device 120 sends the tuple HxRES * , MAC * , xR, RHN , K SEAF to service network 130. Note that
MAC* serves three functions: it acts as the response from network device 120 to the subscriber challenge, it provides authenticity and integrity verification for network device 120’s challenge RHN , and it offers key confirmation for the session key K SEAF to subscriber device 110.
MARKED-UP COPY 36
[0132] Upon receiving the tuple HxRES * , MAC * , xR, RHN , K SEAF , service network 130 retains 07 Jul 2025
HxRES * , xR, RHN , K SEAF and forwards the tuple MAC * , RHN , IDSN to subscriber device 110.
[0133] (3) Subscriber device response and key confirmation:
[0134] Upon receiving the tuple MAC * , RHN , IDSN , subscriber device 110 computes the 2024259751
response RES , cipher key CK , and integrity key IK using f 2 , f 3 , and f 4 respectively, along
with the subscriber secret key k , shared secret key kUE , and the random challenge R as inputs.
Subscriber device 110 then computes the session keys K SEAF and verifies the MAC* using K SEAF
, HN’s challenge RHN , and IDSN .
[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 challenge RHN ,
confirmation of the session key K SEAF , and verification of network device 120’s response to its
challenge R . Afterward, subscriber device 110 generates its response RES * and a message authentication code kcMAC using SHA256 , and sends the tuple kcMAC , RES * , IDSN to
service network 130. Note that kcMAC serves two purposes: verifying the response of subscriber device 110 to network device 120’s challenge RHN and confirming the session keys
K SEAF to network device 120.
[0136] Upon receiving the response from subscriber device 110, service network 130 first verifies HxRES with RES * , xR and RHN . It also verifies kcMAC with the session keys K SEAF
and RHN . A successful verification indicates authentication of subscriber device 110 at service
network 130 and session key K SEAF confirmation. Next, service network 130 forwards the tuple
kcMAC, RES * , RHN to network device 120, where RHN is sent for the binding purposes.
[0137] Upon receiving the tuple kcMAC, RES * , RHN , network device 120 verifies RES * with
xRES * and also kcMAC using K SEAF and RHN . A successful verification indicates mutual
authentication between subscriber device 110 and network device 120 and confirms the session keys K SEAF . Network device 120 then sends the tuple SUPI , SUCI to service network 130,
MARKED-UP COPY 37
where SUCI is used for binding purposes. Once service network 130 receives SUPI , the 07 Jul 2025
authentication process is concluded, and subscriber device 110 can use the session key K SEAF to
access network services.
Preferred second embodiment (Extension for Perfect Forward Secrecy)
[0138] Fig. 6 provides a high-level overview of the preferred second embodiment, where 2024259751
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 ciphers C0 (i.e., the ECIES ephemeral public
key) 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 ciphers xC0 (i.e., C0 ) to calculate a DH key dhkey , using its random challenge RHN as the secret
key. Furthermore, network device 120 computes the DH key material dhHN for subscriber device
110 using RHN , enabling subscriber device 110 to compute the same DH key dhkey on its end.
Subsequently, both subscriber device 110 and network device 120 derive the session keys (i.e., K SEAF ) using the dhkey , kUE , and IDSN .
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
MARKED-UP COPY 38
replay attack prevention mechanism, which makes it unsuitable for modelling using ProVerif. 07 Jul 2025
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. It operates 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 2024259751
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 decryption operations are modelled using the constructor senc for encryption and the destructor sdec for decryption. The senc constructor takes two arguments: a message m of type bitstring and a key n of type bitstring, and returns the encrypted message. The sdec destructor takes an encrypted message produced by senc and the corresponding key n , and returns the original message m . Additionally, cryptographic hash functions such as f1 , f 2 , f 3 , f 4 , KDF , and SHA256 are also
modelled as constructors. Each hash function takes a single input argument of type bitstring and returns a bitstring as output.
MARKED-UP COPY 39
The modular exponentiation operation (i.e., g x ) is modelled using the constructor exp . 07 Jul 2025
[0145] 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: 2024259751
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 type
argument 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 construct Choice M, M' is utilised, which provides a single biprocess encoding both processes. The
Choice M, M' encapsulates the terms that differ between the two processes: one process uses
the first component, M , while the other process uses the second one, M' . For example, if two processes contain terms out ( usch,a ) and out ( usch, b ) , and it is aimed to verify their
equivalence, 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.
MARKED-UP COPY 40
Point of View UE SN HN 07 Jul 2025
Partner SN HN UE HN UE SN Weak agreement x x x x x x Agreement on K SEAF I I I I I I Agreement on IDSN NI NI NI NI NI NI Agreement on SUPI NI NI NI NI NI NI Secrecy on K SEAF x x x PFS x 2024259751
Indistinguishability x 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 a1 : t1 , ( , an : tn ; event e ( X 1 , ) , X j ) == event ( e ' (Y1 , , Yk ) ) .
where e, e ' are events, X 1 , , X n , Y1 , , Yk are the terms, a1 , , an are variables of types t1 , , tn
. The above query is satisfied if, for each occurrence of the event e ( X1 , , X n ) , there is a
previous execution of e ' (Y1 , , Yk ) .
[0151] On the other hand, the injective correspondence assertion appears as follows:
query a1 : t1 , , an : tn ;
inj − event (e ( X , 1 ) , X j ) == inj − event ( e ' (Y , 1 , Yk ) )
[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 each occurrence of event e ( X1 , , X n ) , there is a distinct earlier occurrence of event e ' (Y1 , , Yk ) .
MARKED-UP COPY 41
[0153] From Table 1, it is evident that the disclosed methods align with the security aspect 07 Jul 2025
goals discussed earlier in the disclosure. Specifically, the disclosed methods achieve injective agreements on K SEAF for each pair of parties. Moreover, the disclosed methods obtain non-
injective agreements on IDSN between subscriber device 110 and network device 120, and
service network 130 achieves non-injective agreement on SUPI with network device 120. 2024259751
[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 automatically search for any terms accessible to an attacker. Therefore, if a term, e.g., X , is accessible to an attacker, ProVerif can help identify the attack vector. To prove the secrecy of K SEAF , SUPI , and
k , the following queries are employed:
query attacker ( KSEAF ) . query attacker ( SUPI ) . query attacker ( k ).
[0155] Perfect Forward Secrecy (PFS): ProVerif’s modelling features referred to as Phases is utilised. 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 exposes the subscriber secret key k , SUPI of subscriber device 110 and the private key sk HN of network
device 120 to the attacker. The formal security analysis demonstrates that despite the attacker gaining access to k , SUPI , and network device 120’s private key sk HN in Phase 1, the
confidentiality of the session keys, K SEAF , remains preserved. This demonstrates that the
disclosed 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 processes involving 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
MARKED-UP COPY 42
suggests that an active attacker cannot distinguish between these distinct processes during 07 Jul 2025
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 as 2024259751
5G-AKA ' ) is presented.
Theoretical Comparison
[0158] In this section, a theoretical comparison between the disclosed methods with the 3GPP standardized 5G-AKA and 5G-AKA ' is presented.
[0159] Table 2 shows a comparison between thedisclosed 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 and 5G-AKA ' require 13 and 9 messages, respectively, when sequence number synchronization is necessary 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 disclosed methods send additional parameters compared to 5G-AKA and 5G-AKA ' . Specifically, MAC is sent from subscriber device 110 to service network 130, and then from service network 130 to network device 120; MAC* and kcMAC are sent from service network 130 to subscriber device 110; and finally, dhHN is sent from service network 130 to network device 120. The sizes of
MAC , MAC* , kcMAC , and dhHN are 32,32,32, and 64 bytes, respectively.
5G-AKA 5G-AKA ' Method I Method II Resynchronization Yes Yes No No Messages Resync 13 13 NA NA No Resync 9* 9* 7 7 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 between
MARKED-UP COPY 43
the parties for mutual authentication and an additional 2 messages for the anchor key K SEAF 07 Jul 2025
confirmation 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 between the disclosed methods and 5G-AKA and 5G-AKA ' . Method 1 being the first preferred embodiment, and Method II being the second preferred embodiment. The computation costs 2024259751
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). The computation costs involved in completing the authentication process following these failure cases in 5G-AKA and 5G-AKA ' are also accounted. Since the disclosed methods do not utilise sequence numbers to prevent replay attacks, unlike 5G-AKA and 5G-AKA ' , they do not require handling these latter two cases. Th , Tm , Tenc , Txor , Tadd , Tprf , and Tdec are represented as the time
required 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 lower computation costs in Cases 2 and 3 compared to both 5G-AKA and 5G-AKA ' . Additionally, the disclosed methods have minimal or comparable computation costs in Case 1 when compared with 5G-AKA and 5G-AKA ' .
Experimental Results
[0161] The disclosed methods as well as 5G-AKA and 5G-AKA ' were implemented to compare 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 f 1, f 2, f 3, f 4, f 5, f 1* , f 5* . For key derivation and message authentication, Password-Based Key Derivation Function 2
MARKED-UP COPY 44
(PBKDF2) and Hash-based Message Authentication Code (HMAC) were used for KDF and 07 Jul 2025
HMAC , respectively.
[0163] Table 4 presents the actual computation times for to complete their respective operations. The results are averaged over 1000 trials and are reported in microseconds. From the table, it is observed that in case 1, the disclosed methods incur comparable computation times by subscriber device 110. 5G-AKA and 5G-AKA ' impose significantly higher computation costs 2024259751
by subscriber device 110 and network device 120 in case 2 and case 3, in comparison to case 1.
Case 1 Case 2 Case 3 UE SN HN UE SN HN UE SN HN 5G-AKA 30384.35 10.9 38472.40 42592.65 10.9 91003.46 40075.80 10.9 76144.90 5G-AKA 30884.20 11.01 38972.40 43092.36 11.01 92903.46 42975.27 11.01 78144.34 ' Method I 30591.10 20.68 45731.20 NA NA Method 30791.83 20.68 45811.45 NA NA II 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 and 5G-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 input
and outputs a private key sk and a public key pk , where sk * q (a multiplicative group of
integer modulo q ), pk = sk g , and g is a generator of the chosen elliptic curve. 3GPP recommends two elliptic curves Curve25519 and secp256r1. However, any elliptic curves may be used in the disclosed methods.
MARKED-UP COPY 45
[0166] Encap ( ( C0 , k s ) pk ) : It takes the public key pk as input to generate an ephemeral 07 Jul 2025
private-public key pair ( r, R ) , where r Z*q and R = r g . It sets C0 = R and computes a shared
secret key k s , where ks = KDF ( r pk ) .
[0167] Decap ( k s ( C0 , sk ) ) : It takes C0 and the private key sk as input and outputs the
shared secret key k s as follows ks = KDF ( sk C0 ) . 2024259751
[0168] SEnc ((C , C ) (k , M )) : 1 2 s It takes the shared secret key k s and a message M as
input. It outputs two ciphertext components ( C1 , C2 ) , where C1 = Enc ( s1 , M ) is the encrypted
component of the message M using a symmetric key encryption algorithm, and C2 = MAC ( s2 , C1 ) is a message authentication code to check the integrity and authenticity of C1 .
Here, ( s1 , s2 ) are the leftmost and rightmost octets of the shared secret key k s .
[0169] SDec ( M ( k s , C1 , C2 ) ) : It takes the shared secret key k s , C1 , and C 2 as input. It
outputs the actual message M as follows: It extracts ( s1 ,s2 ) from k s , verifies if
C2 = MAC ( s2 , C1 ) , and if the verification is successful, decrypts C1 to obtain M using
Dec ( s1 , C1 ) .
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 network 130 is initialized. Subscriber device 110 encrypts its unique identity SUPI with the public key PK HN of network device 120 using ECIES and produces a ciphertext SUCI . Subscriber device
110 then sends SUCI and the identity of network device 120, IDHN to service network 130.
Afterward, service network 130 forwards the received SUCI to network device 120, adding its
MARKED-UP COPY 46
own identity IDSN . Upon receiving SUCI , network device 120 decrypts it using its own private 07 Jul 2025
key sk HN and retrieves SUPI , which helps network device 120 obtain the subscriber secret key
k and sequence number SQN HN associated with subscriber device 110’s SUPI from its
database.
[0173] (2) Challenge-Response: 2024259751
[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 tuple R, AUTN = CONC, MAC , HxRES , K SEAF , which is then sent to subscriber device 110. In
CONC , network device 120 conceals the sequence number associated with subscriber device 110 SQN HN using the anonymous key AK derived from R and k . The MAC is computed for
the 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 from subscriber device 110, which is computed using R and k . Finally, the session keys K SEAF are
computed using k , R , IDSN , and SQN HN . Network device 120 also increments the sequence
number SQN HN by 1 at the end.
[0176] After receiving the tuple R, AUTN , HxRES , KSEAF , service network 130 stores a copy
of R, HxRES , KSEAF and forwards the tuple R, AUTN to subscriber device 110.
[0177] Upon receiving the tuple R, AUTN , subscriber device 110 computes an anonymous
key AK inside the USIM card using k and R , and uncovers the sequence number SQN HN from
the CONC part of AUTN . Next, it checks MAC using R and SQN HN inside the USIM card. If
this check fails, it returns a MAC_Failure message, which is sent to service network 130 and goes to the MAC Failure phase. If the check is successful, subscriber device 110 verifies the freshness of SQN HN . If this verification fails, the USIM card returns AUTN = CONC , MAC * ,
where CONC conceals the sequence number SQNUE , and sends the tuple
MARKED-UP COPY 47 07 Jul 2025
Sync _ 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 sets SQNUE to SQN HN , computes the session keys K SEAF using k , R , IDSN , and
SQN HN , and finally returns the tuple KSEAF , RES . Subscriber device 110 keeps K SEAF and
sends RES to service network 130. 2024259751
[0178] After receiving RES , service network 130 compares the hash of RES and R with HxRES . If successful, service network 130 forwards RES to network device 120, which then compares RES with its stored xRES . If this comparison is successful and subscriber device 110 is authenticated, network device 120 sends the SUPI associated with subscriber device 110 to service 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 using K 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’s SQN UE and
network device 120’s SQN HN .
[0182] When the freshness check fails, as previously mentioned, the USIM card returns AUTN = CONC , MAC * , with CONC concealing the sequence number SQNUE . It then sends
the tuple Sync _ Failure, AUTN to network device 120 to synchronize the sequence number.
Upon receiving the Sync _ Failure message, service network 130 forwards the tuple
Sync _ Failure, AUTN , R, SUCI to network device 120. Subsequently, network device 120 de-
conceals the SQNUE after verifying the message authentication code MAC* . If the verification is
successful, network device 120 sets its sequence number SQN HN to SQNUE + 1 .
MARKED-UP COPY 48
[0183] (4) MAC Failure: 07 Jul 2025
[0184] This phase is initiated as a result of the MAC check fails in the Challenge-Response phase. In this phase, subscriber device 110 simply returns a MAC - Failure message and goes to the Initiation phase to restart the AKA protocol in a new session.
Appendix C: Privacy Issues with 5G-AKA Protocol 2024259751
[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 a
Sync _ Failure message because the replayed message passes the initial MAC verification with
the correct subscriber secret key k but fails the freshness check SQN HN . In contrast, other
subscribers respond with a MAC _ Failure message, as the replayed message fails the MAC verification 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 number SQNUE . The attacker replays previously
captured tuples R, AUTN multiple times and captures the returned CONC in the i +1 i Sync _ Failure messages. The attacker attempts to learn SQNUE SQNUE by performing an
Exclusive-OR operation between CONC i and CONC i +1 , as both CONC i and CONC i +1 have concealed their sequence numbers using the same anonymous key AK .
[0188] Encrypted SUPI Replay Attack: The goal of this attack is to distinguish the targeted subscriber from others. In this attack, the attacker replays the captured SUCI during the Initiation 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 targeted subscriber responds successfully, while the other subscribers reply with MAC - Failure
MARKED-UP COPY 49
messages because the subscriber secret key k used to generate the MAC matches only for the 07 Jul 2025
targeted 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 (22)
1. A method for authenticating a subscriber device with a network device of a communication network, the method comprising: by the subscriber device equipped with a universal subscriber identity module (USIM): calculating a secret key by encrypting a subscriber challenge with a public key of the network device; 2024259751
calculating a subscriber challenge tag by encrypting the subscriber challenge with the secret key and a subscriber secret key obtained from the USIM, the subscriber secret key being indicative of a subscription to services provided by the network device; 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; 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 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.
MARKED-UP COPY 51
3. The method of claim 2, wherein the method further comprises: 07 Jul 2025
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 2024259751
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.
MARKED-UP COPY 52
9. The method of claim 1, wherein the method further comprises, by the network device, 07 Jul 2025
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 2024259751
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; and
MARKED-UP COPY 53
by the subscriber device, generating an expected subscriber challenge response tag 07 Jul 2025
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. 2024259751
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 encrypting is based on elliptic- curve cryptography.
19. A method for authenticating a subscriber device with a network device of a communication network, as performed by the subscriber device equipped with a universal subscriber identity module (USIM), 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 by encrypting the subscriber challenge with the secret key and a subscriber secret key obtained from the USIM, the subscriber secret key being indicative of a subscription to services provided by the network device; 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;
MARKED-UP COPY 54
calculating a session key based on the response data and the subscriber challenge; 07 Jul 2025
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.
20. A method for authenticating a subscriber device with a network device of a 2024259751
communication network, as performed by the network device, the method comprising: receiving a request for authentication from the subscriber device equipped with a universal subscriber identity module (USIM), the request comprising a subscriber challenge tag and one or more ciphers determined from a subscriber challenge, the subscriber challenge tag being based on encrypting the subscriber challenge with a secret key and a subscriber secret key obtained from the USIM, the subscriber secret key being indicative of a subscription to services provided 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; 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.
21. Software that, when executed by a computer, causes the computer to perform the method of any one of the preceding claims.
22. 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 20.
123 124 125 100 116
memory
non- vol vol 126
memory 123 113 memory non- 126 122 124 non- 122 vol 114 112 vol 120 vol 125 Fig. 1 115 vol 1/6
130 110
112
111
memory non- 130 vol vol 116
110 120
113 114 115
Fig. 1 111
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| AU2024902698A AU2024902698A0 (en) | 2024-08-29 | Attack resistant authentication | |
| AU2024902698 | 2024-08-29 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| AU2024259751B1 true AU2024259751B1 (en) | 2025-08-14 |
Family
ID=96659874
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| AU2024259751A Active AU2024259751B1 (en) | 2024-08-29 | 2024-11-06 | Attack resistant authentication |
Country Status (1)
| Country | Link |
|---|---|
| AU (1) | AU2024259751B1 (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10826712B2 (en) * | 2015-06-30 | 2020-11-03 | Visa International Service Association | Confidential authentication and provisioning |
| WO2023134844A1 (en) * | 2022-01-12 | 2023-07-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Establishment of network connection for a communication device |
-
2024
- 2024-11-06 AU AU2024259751A patent/AU2024259751B1/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10826712B2 (en) * | 2015-06-30 | 2020-11-03 | Visa International Service Association | Confidential authentication and provisioning |
| WO2023134844A1 (en) * | 2022-01-12 | 2023-07-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Establishment of network connection for a communication device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Cremers et al. | Component-based formal analysis of 5G-AKA: Channel assumptions and session confusion | |
| Vanhoef et al. | Key reinstallation attacks: Forcing nonce reuse in WPA2 | |
| Mitchell | The impact of quantum computing on real-world security: A 5G case study | |
| Alezabi et al. | An efficient authentication and key agreement protocol for 4G (LTE) networks | |
| EP2522100B1 (en) | Secure multi-uim authentication and key exchange | |
| US8340288B2 (en) | Cryptographic key generation | |
| US8467532B2 (en) | System and method for secure transaction of data between a wireless communication device and a server | |
| Liu et al. | Toward a secure access to 5G network | |
| CN103560879B (en) | A kind of light-weight authentication and the implementation method of key agreement | |
| Edris et al. | Formal verification and analysis of primary authentication based on 5G-AKA protocol | |
| CN101116284B (en) | Anti-cloning mutual authentication method, identity module, server and system in radio communication network | |
| Abdrabou et al. | LTE authentication protocol (EPS-AKA) weaknesses solution | |
| CN108880813A (en) | A kind of implementation method and device of attachment flow | |
| Parne et al. | PPSE: Privacy preservation and security efficient AKA protocol for 5G communication networks | |
| Cao et al. | LPPA: Lightweight privacy‐preservation access authentication scheme for massive devices in fifth Generation (5G) cellular networks | |
| Palit et al. | Performance analysis of 5GMAKA: lightweight mutual authentication and key agreement scheme for 5G network | |
| Leu et al. | Improving security level of LTE authentication and key agreement procedure | |
| Zhang et al. | PUF-Based Lightweight Group Authentication for Massive IoT Access With Insecure Channel | |
| Zhou et al. | A hybrid authentication protocol for LTE/LTE-A network | |
| Abdo et al. | EC-AKA2 a revolutionary AKA protocol | |
| CN106209384B (en) | Use the client terminal of security mechanism and the communication authentication method of charging unit | |
| Sultan et al. | Active attack resilience in 5g: A new take on authentication and key agreement | |
| AU2024259751B1 (en) | Attack resistant authentication | |
| Bala et al. | Separate session key generation approach for network and application flows in LoRaWAN | |
| Lauser et al. | Data Distribution and Redistribution-A formal and practical Analysis of the DDS Security Standard |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FGA | Letters patent sealed or granted (standard patent) | ||
| DA3 | Amendments made section 104 |
Free format text: THE NATURE OF THE AMENDMENT IS: AMEND THE NAME OF THE INVENTOR TO READ SULTAN, NAZATUL; SUZUKI, HAJIME; PIEPRZYK, JOSEF; ABUADBBA, SHARIF AND NI, WEI |