|
1.INTRODUCTION5G communication will efficiently enable new secure, dependable, ultrareliable, and low latency services to everyone and everything1-3. Unlike traditional human-to-human communications, 5G extends to highly converged communications among people, things and networks. A large number of user equipment (UE) will be connected to the network, thus more security issues are faced in more complex scenarios. To ensure data security in 5G, it is necessary to use authentication and data encryption for UE access4. In 5G communication, authentication and encryption are carried out sequentially. 5G system supports the use of 5G Authentication and Key Agreement (AKA) for mutual authentication between the UE and the network, which greatly enhances security5. However, the AKA protocol has flaws at the beginning of its design6-8, and the 5G AKA protocol also inherits this. These flaws lead to the threat of linkability attacks over the air interface. This threat refers to a plaintext message with authentication failure reason will leak UE information, which gives the malicious attacker the possibility of illegally tracking users. Many efforts have been made to patch the flaws mentioned above. For the protection of failure messages, Arapinis et al.9 suggest using HN’s public key to encrypt different message types of subscribers’ responses to the service network (SN), which can confuse the attacker’s judgment. But there is no available global PKI in MNO, so the deployment of this method is difficult. Fuwen Liu et al.10 apply Diffie Hellman (DH) key exchange with a digital signature to 5G attachment process. The encryption key Ke and integrity key Km are used to protect the authentication response message that sends from UE to the service network. Xinxin Hu et al.11 puts forward a countermeasure of using the existing 5G network PKI mechanism without adding a key, and the security, communication, computing and storage overhead of the method are discussed. Although the existing methods can make the content of the failure message unidentifiable through encryption or concealment, the attacker can distinguish the failure types by the length of different failure messages, so as to achieve a purpose of linkability attack. The length of the different messages can be obtained from the known failure messages. In light of this, two methods are proposed to solve the above problems. The two methods use adopt encryption and non-encryption, respectively. 2.5G AKA PROTOCOL AND LINKABILITY ATTACKAKA protocol is used to realize mutual authentication between UE and the network, but it has known flaws in the authentication process12, and it will be subject to linkability attacks based on failure messages. When UE fails to authenticate the network, the specific reasons for the authentication failure will generate13. The failures are divided into MAC_ FAIL and synchronization failure SYNC_ FAIL. MAC_ FAIL means that the MAC in the authentication message from the network is unmatched and the SYNC_ FAIL means the MAC in the authentication message from the network is matched but SQN is incorrect. As a result, the attacker can judge whether the target UE is in the network or not by the type of the response message. The attacker replays the authentication request received by the target UE and observes the received reply. If the reply is MAC_FAIL, it is not the target UE; If the reply is SYNC_FAIL, it is the target UE, thus exposing the user’s location privacy information. Figure 1 shows the attack model in the authentication process of 5G AKA. As shown in Figure 1, during the 5G AKA authentication process, the network sends an authentication request to the UE. The authentication request includes the authentication vector calculated by the home network. The home network sends the 5G SE AV to the serving network, including RAND, AUTN and HXRES* and the serving network forwards the authentication request to the UE, including RAND and AUTN. To carry out the attack, the attacker builds a malicious base station and eavesdrops on the authentication request message at the air interface, which contains two key information, RAND and AUTN. Attackers use previously intercepted RAND and AUTN forged authentication request messages to broadcast wherever the target UE may appear. After the UE receives the authentication request message, it will authenticate the AUTN in the message, including MAC and SQNHN. If the MAC verification fails, it will reply to the failure reason as “MAC_FAIL” in the failure response message, indicating that the UE has failed to authenticate the network. If the verification is passed but the SQNHN is not in the correct range, the failure reason is “SYNC_FAIL”. UE will also calculate the feedback parameter AUTS (Authentication Token for Synchronisation), which carries the terminal serial number SQNMS. After receiving the failure response message, the network side will reset the network serial number according to SQNMS to generate a new authentication vector. Under this certification process, the MAC_ FAIL and SYNC_ FAIL not only have different content, but also different message lengths. Thus the attacker can make the following judgments—if there is a synchronization failure message, the target UE belongs to this network; if all received messages are MAC failures, the target UE is not in this network. 3.OUR METHODSIn order to protect the location privacy information of users, this paper proposes two methods to solve the problems. Both of these methods are designed to hide the message so that the attacker cannot distinguish the failure type by the message content or the message length. 3.1Method IThe main idea of this method is to hide the content of the message through encryption, and at the same time to ensure the consistent length of the MAC_ FAIL and SYNC_ FAIL message through message reconstruction. The reconstruction method is shown in Figure 2. The fields in green represent newly added sections in Figure 2. If the authentication failure is MAC_FAIL, the INFO and RAND fields are added. Both parts are composed of changed random numbers, and the length of the INFO field is the same as that of AUTS. If the authentication failure is SYNC_ FAIL, the RAND field consisting of changed random numbers is added. Failure type and AUTS are the same as before. The length of RAND filed in the MAC_FAIL is the same as that in the SYNC_ FAIL. The length of the RAND field can be customized in the implementation. A longer length helps the same type of message change more, but it also increases the computational burden, which needs to be balanced in practical use. The INFO fields in the two failure messages ensure the length of the authentication response message is consistent. The RAND fields make each failure message different and it can prevent attackers from observing the message obtained by multiple replays. After the message reconstruction is complete, the message is encrypted using the key produced during the authentication process. The implementation of this method in AKA is shown in Figure 3. The sections marked with a lock are the message reconstruction part in Method I. The UE uses the shared key generated in the primary authentication phases. The encryption key KENC is used to encrypt the authentication response message to generate ciphertext (Failure type, INFO, Rand) KENC, and the integrity key KMAC is used to protect the integrity of the ciphertext and generate the ciphertext digest tag. Finally, the content of the Authentication Response message becomes (CAUSE, RAND, SUPI, INFO) KENC || Tag. Step 8 is the decryption and parsing operations that HN needs to obtain the real cause of failure. 3.2Method IIMethod I hides the response message through random number padding and data encryption. However, the message need encrypted after reconstruction, the data decryption also needs to be added in the AKA, as Step 8 in Figure 3, which makes the authentication process complicated. Method II proposes a message hiding method that only needs to reconstruct the failure message without encryption. The core of this method is to construct a unified authentication response message using pseudo parameters. The reconstruction of the response message is displayed in Figure 4. In this method, not only the failure message but also the success message is reconstructed. A new unified authentication message body is constructed, which consists of three fields [RES*][CAUSE][AUTS]. The generation configuration of the three fields needs to be set collaboratively according to specific scenarios. A new unified authentication message body is constructed, which consists of three fields [RES*][CAUSE][AUTS]. The generation of the three fields needs to be set collaboratively according to specific scenarios, and the following rules are shown in Table 1. Table 1.Parameter configuration in Method II.
The implementation of this method in AKA is shown in Figure 5. The UE returns a unified authentication response message to the network after completing the authentication. The SEAF in SN and the UDM in HN are responsible for verifying the fields of the response message. The verification methods are as follows: • SEAF verifies RES* field by comparing HRES* with HXRES*. If the verification is passed, it means that the real authentication result is “successful”; otherwise, it means “failed”, and the AUTS field needs to be further verified; • UDM verifies the AUTS field by using f1* algorithm to calculate MAC-S and using key AK to check SQNMS according to TS 33.102. If the verification passes, it means that the real failure reason is “synchronization failure”, otherwise it means “MAC failure”. This solution does not need to send the real failure type. The parameters RES* and AUTS can be verified by relevant calculations on the relevant network elements. For the attacker, what is received is only a unified authentication response message, so the attacker cannot verify the parameter value in the message field, and thus cannot know the real content of the authentication. 4.THE COMPARISON OF THE TWO METHODSMethod I needs reconstruction and encryption in the message construction phase, while Method II only needs to construct the message which is simpler for the UE. However, Method I does not affect the SE, and the implementation impacts the UE and the HE. Method II does not require an additional key to encrypt the response message, but the UE, SE and HE require adaptive changes. To sum up, in terms of implementation, method II is simpler than method I, but involves a wider range of aspects. In practical use, it should be comprehensively considered according to the hardware capabilities of the UE and the scope of the changes. 5.CONCLUSIONThe linkability attack in 5G AKA is analyzed in this paper. Based on the analysis of attack methods, two methods are proposed to overcome the attack problem. Encryption and random number padding for reconstruction are used in Method I, so that not only the content of the response message is hidden, but the length of the message is also the same and cannot be distinguished by the attacker. Method II only needs reconstruction through the coordinated configuration of specific fields. The authentication information is contained in RES* and AUTS. This method does not require the participation of keys, but more roles are involved to make changes. The message construction methods of the two methods and the implementation steps in AKA are also presented in the paper. REFERENCESSoldani, D. and Manzalini, A.,
“Horizon 2020 and beyond: On the 5G operating system for a true digital society,”
IEEE Vehicular Technology Magazine, 10
(1), 32
–42
(2015). https://doi.org/10.1109/MVT.2014.2380581 Google Scholar
Alnoman, A. and Anpalagan, A.,
“Towards the fulfillment of 5G network requirements: technologies and challenges,”
Telecommunication Systems, 65
(1), 101
–116
(2017). https://doi.org/10.1007/s11235-016-0216-9 Google Scholar
Gavrilovska, L., Rakovic, V. and Atanasovski, V.,
“Visions towards 5G: Technical requirements and potential enablers,”
Wireless Personal Communications, 87
(3), 731
–757
(2016). https://doi.org/10.1007/s11277-015-2632-7 Google Scholar
Jover, R. P. and Marojevic, V.,
“Security and protocol exploit analysis of the 5G specifications,”
IEEE Access, 7 24956
–24963
(2019). https://doi.org/10.1109/Access.6287639 Google Scholar
3GPP TS33.501,
“Security architecture and procedures for 5G system,”
(2019). Google Scholar
Koutsos, A.,
“The 5G-AKA authentication protocol privacy,”
in 2019 IEEE European Symposium on Security and Privacy (EuroS&P),
464
–479
(2019). Google Scholar
Liu, T., Wu, F., Li, X., et al,
“A new authentication and key agreement protocol for 5G wireless networks,”
Telecommunication Systems, 78
(3), 317
–329
(2021). https://doi.org/10.1007/s11235-021-00815-9 Google Scholar
Edris, E. K. K., Aiash, M. and Loo, J. K. K.,
“Formal verification and analysis of primary authentication based on 5G-AKA protocol,”
in 2020 Seventh International Conference on Software Defined Systems (SDS),
256
–261
(2020). Google Scholar
Arapinis, M., Mancini, L., Ritter, E., et al,
“New privacy issues in mobile telephony: Fix and verification,”
in Proceedings of the 2012 ACM conference on Computer and Communications Security,
205
–216
(2012). Google Scholar
Liu, F., Peng, J. and Zuo, M.,
“Toward a secure access to 5G network,”
in 2018 17th IEEE international Conference on Trust, Security and Privacy in Computing and Communications/12th IEEE International Conference on Big Data Science and Engineering (TrustCom/BigDataSE),
1121
–1128
(2018). Google Scholar
Hu, X., Liu, C., Liu, S., et al,
“A vulnerability in 5G authentication protocols and its countermeasure,”
IEICE Transactions on Information and Systems, 103
(8), 1806
–1809
(2020). https://doi.org/10.1587/transinf.2019FOL0001 Google Scholar
Braeken, A., Liyanage, M., Kumar, P., et al,
“Novel 5G authentication protocol to improve the resistance against active attacks and malicious serving networks,”
IEEE Access, 7 64040
–64052
(2019). https://doi.org/10.1109/Access.6287639 Google Scholar
Wang, Y., Zhang, Z., Xie, Y.,
“Privacy-preserving and standard-compatible AKA protocol for 5G,”
in 30th USENIX Security Symposium (USENIX Security 21),
3595
–3612
(2021). Google Scholar
3GPP TS33.102,
“3G Security; Security architecture,”
(2018). Google Scholar
|