Friday, December 27, 2019

Introduction to 5G Authentication Security

Introduction
Upon switching on mobile phone, it will start to search for available cellular networks nearby, and register itself into the subscribed network using some secrets in USIM card. In this chapter, we will discuss how 5G-AKA has improved the security of this process. However, in order to understand it better, we need to go through some history from 2G (GSM), 3G (UMTS) and 4G (LTE) first. It would help us understand why 5G-AKA is designed in this way.

What is AKA
Authentication and Key Agreement (AKA) is a set of rules (i.e. a protocol) to allow mobile phone and core network to exchange their identity and secret keys for communication. Authentication is a way to make sure both two parties are trustworthy: let say if you want to go to the university library, you will check the address of the library to make sure the library is not a fake one. At the same time, the library staff will also ask you to show your student ID card to make sure that you are the eligible users (e.g. student) of this library. Key agreement is a way of negotiating one common secret key without revealing the key to any third parties. Diffie-Hellman key exchange or computed keys based on common secret are some commonly used methods.

AKA in GSM:
Here is the simplified flow of GSM attach authentication process (EAP-SIM, RFC 4186).
MSC = Mobile Switching Center (the main switch of voice calls)
VLR = Visitor Location Register (a database storing connected devices)
HLR = Home Location Register (the central database of all mobile subscribers details)
AUC = Authentication Center (the functional entity which only focus on running authentication)

In the picture it shows that, when the mobile device is switched on, it will immediately send a request access message which contains the IMSI of the USIM to MSC. Then, VLR will only send a RAND signal to UE to ask for its reply. Also, the final judge of authentication success is located in VLR. As a result, it will have (at least) these 3 main problems:
  • By listening to the IMSI in request access messages, eavesdroppers can track a specific device.
  • UEs have no way to make sure the cellular network is trustworthy (it just reply a RAND!).
  • Authentication decision is made in VLR instead of AUC, which is potentially dangerous.
Not to mention that the predictability of A3 and A8 algorithm could be higher than expected, it is easy to justify that GSM is insecure in many aspects.

---

AKA in 3G (UTRAN, UMTS):
UTRAN (UMTS Terrestrial Radio Access Network) had improved the authentication system slightly. The main focus of the improvements are generating more different keys for different controls. Although the term "temporary identity (pseudonym)" is appeared in EAP-AKA (RFC 4187), the actual implementation still largely follows the GSM way - IMSI is sent in clear text during registration.

---

AKA in 4G (E-UTRAN, LTE):
After some painful lessons from 2G and 3G, 4G LTE tried to tackle the problem of mutual authentication and user tracking. Here is the simplified flow of EPS-AKA:
GUTI = Globally Unique Temporary Identity
AUTN = Authentication Token

After the first registration which uses IMSI, the USIM will be assigned with a new temporary identity called GUTI. This GUTI will be used for next registration, and it will be updated periodically to prevent eavesdroppers to trace the device easily. Besides, since the cellular network will send an extra field (AUTN) to UE as a feedback, UE can use it to make sure the network is legitimate. Unfortunately, there are still some problems found:
  • EPS-AKA is still prone to man-in-the-middle (MITM) attack (check here). This is largely because by the time of releasing EPS-AKA, no formal verification was done, so nobody discovered it at the beginning.
  • GUTI are not changed as frequently as necessary, and it is easily predictable.
  • Authentication decision is still made on MME instead of HSS, which is still dangerous.
Some people asked why 4G LTE is still widely used with so many security issues.
However, think about that:
  • Expensive equipment - buying eNB from market is generally expensive for hackers.
  • Legislation - radio frequently usage is strictly monitored by government, and the location of fake stations can actually be traced quite easily.
  • Lack of alternatives - there is no other choice in the market until 5G launch.
---

AKA in 5G (5GC, NR):
Finally, we have come to 5G era. The new implementation looks like the following:

If you look close enough, you will find that the authentication process still looked very similar to EPS-AKA. However, there are some major improvements:
  • SUCI is an encrypted SUPI (IMSI in EPS core network), therefore, even in the first registration UE will not reveal its identity to eavesdropper.
  • New entities such as "SEAF", "AUSF", "UDM/ARPF" are created to split the tasks to many servers/entities.
  • Authentication decision cannot be solely done in SEAF (which is located in AMF). In fact, SEAF can reject the authentication at any time, but it can only approve authentication after receiving the authenticate response from AUSF.
In fact, there are some researchers doing formal verification of 5G-AKA, and they provided quite reasonable comments about it (check here).

By the way, since 5G supports Non-3GPP AN, 5GC will support various AKA protocols such as EAP-AKA' (improved EAP-AKA) and EAP-TLS. Also there will be a specific functional entity (N3IWF) to handle the signal transmission in Non-3GPP AN. Since this part is also quite complicated, so I will skip it until I need to write them.

---

Reference:

[1]: A Comparative Introduction to 4G and 5G Authentication - https://www.cablelabs.com/insights/a-comparative-introduction-to-4g-and-5g-authentication
[2]: Authentication In GSM - https://www.youtube.com/watch?v=82NYPC3zwiA
[3]: GSM Authentication Procedure - https://diameter-protocol.blogspot.com/2013/06/gsm-2g-authentication-procedure.html
[4]: UTRAN Authentication Procedure - https://diameter-protocol.blogspot.com/2013/06/umts-3g-utran-authentication-procedure.html
[5] - 3GPP 33.501 V15.2 - https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3169

No comments:

Post a Comment