The different reactions of different phones to IMSI catchers (update)

Over the weekend I stumbled upon this paper: The diverse and variegated reactions of different cellular devices to IMSI catching attacks.

I have no idea how this paper fell under my radar, but I already tweaked a bit my alerts from Google Scholar and ResearchGate so, hopefully, I don’t miss such a paper again.

This paper presents a very (very!) interesting study of how different mobile handsets behave in the presence of an IMSI catcher, with or without the presence of an extra jammer. Really great paper by Ivan Palama and team at the University of Rome Tor Vergata.

The authors implement an LTE IMSI catcher with srsLTE and with Open Air Interface. My very first LTE IMSI catcher ever was written using openLTE, but ever since 2015 I have done all my work using srsLTE. I never did any work with Open Air Interface, but I would assume that turning it into an IMSI catcher should be as simple as with srsLTE. The IMSI catcher is implements a couple of the standard techniques to force an LTE handset to disclose its IMSI in the clear, namely:

• Service Reject message, with EMM cause code 0b00001001 (“UE identity cannot be derived by the network”)
• Tracking Area Update Reject, with EMM cause code 0b00001001 (“UE identity cannot be derived by the network”)

In parallel, they implement a derivation of what I used to refer to as “smart jamming” in LTE back in 2014. Interestingly, they have open-sourced their jammer.

The results of the paper can be summarized in Table I:

Fascinating at the very least. As I was expecting when I started reading the paper, the behavior when facing an IMSI catcher is independent of the mobile operator. However, the results show some quite distinct behavior in Android devices when compared to iOS. For iPhone 8s and beyond, the device is not fooled by the IMSI catcher unless the jammer is applied. And, even with the jammer, the authors observed the devices often downgrading to 3G or GSM instead of disclosing their IMSI (“If we run LTE jammers over non-priority frequencies, often when we start the malicious eNodeB the iPhone automatically downgrades to 3G or even GPRS without providing IMSI to our IMSI Catcher“).

These results are very interesting. Most of the behavior when facing an IMSI catcher would be driven by the cellular modem’s, and these interesting “resiliency” to IMSI catchers seems to start appearing when Apple started using Intel cellular modems.

The modem used by the iPhone XS (Intel XMM 7560) is also used in the HP Spectre Folio laptops. I would run the same experiments with one of these HP laptops and see what happens. If the behavior is different when compared to the iPhone XS, this could indicate that this is partially (or mostly) related to the OS, with iOS exhibiting some interesting partial resiliency to IMSI catchers. There’s some things that could potentially be done from the OS, despite the response to an IMSI catcher happening mostly on the modem. However, it could also be a custom configuration or tweak of the modem’s FW for the Apple phones too.

Although some interesting technique to flag eNodeBs that appear to be suspicious (similar to what SnoopStitch or Crocodile Hunter do, with both approaches being very different, though), simply refusing the disclose the IMSI would be a simple viable approach as well. The likelihood to see an EMM cause code 0b00001001 ((“UE identity cannot be derived by the network”) in the wild for a legitimate reason is very low. Just refusing the disclose the IMSI and downgrading to 3G instead is a valid approach against a not-too-sophisticated attacker. Arguably, with a few laptops and a few SDRs one can set up a rogue LTE eNodeB, jam LTE, jam 3G, jam GSM and set up a rogue GSM BS. But this is not the standard setup an adversary would have. I am unfamiliar whether an actual commercial IMSI catcher used by, for example, law enforcement, can account for devices refusing to disclose their IMSI on LTE and downgrading to 3G or GSM.

Regardless, having the OS and/or the modem and/or both refuse to disclose its IMSI and, instead, downgrade, substantially raises the security bar against many IMSI catchers.

Really interesting paper indeed!!!

Ps. I need a new template/style for my blog so I can show figures larger. Any suggestions?

 

Update (05/04/2021):

A few weeks later, the same authors have published a follow up to their paper with more results. Most interestingly, they have added to the analysis experiments with the latest iPhone (12), which was not part of their experiment corpus when they first published the paper.

With the previous result there seemed to be some correlation between many iPhones and a certain degree of resilience against IMSI catchers. Adding the result from experimenting with the latest iPhone, the authors indicate that the resilience to IMSI catchers might actually be correlated to the Intel modem used on many iPhones (Intel XMM 7xxx family).

Very interesting!

Leveraging digital certificates to protect commercial 5G mobile networks

(Cross-post from LinkedIn: https://www.linkedin.com/pulse/leveraging-digital-certificates-protect-commercial-5g-piqueras-jover)

1. Introduction

For years, a number of academic teams (TU Berlin, Ruhr Universität Bochum, KAIST, Purdue University, etc.) and infosec researchers, including myself, have been demonstrating ways in which GSM and LTE pre-authentication messages can be abused for fun and profit.

For example, the actual reason why IMSI catching is possible in LTE is the fact that the downlink message “Hey, I am your operator and I forgot your TMSI. Please send me your IMSI” has no protection of any sorts, including integrity protection or authentication. As a result, anyone with a native Linux laptop and about $1,000 worth of radios can intercept IMSIs from any commercial smartphone or mobile endpoint. One can also use the exact same system set-up to run Crocodile Hunter and collect data that can aide in detecting potential IMSI catchers.

However, IMSI catching, which receives the vast majority of the media’s attention, is just the tip of the iceberg. By abusing pre-authentication messages at the data link layer (aka layer 2), one can trivially downgrade the connection to GSM, and then proceed to fully Man-in-the-Middle the communications link. Other possible exploits include denying the connection to mobile devices, tracking the location of devices, hijacking DNS traffic, fingerprinting traffic, and many more. Moreover, all of these exploits have one commonality: they are triggered by spoofing a critical message at layer 2 that lacks authentication and integrity protection.

Unlike most other communications networks, mobile systems provide no method to verify cryptographically the identity of the other end in the communication. As a result, every single consumer electronic device with a cellular modem communicates with any base station that advertises broadcast messages claiming to be a valid operator, regardless of whether that is true or not. To put this into perspective, cellular networks at layer 2 behave as if your laptop’s browser always accepted self-signed certificates by default, without prompting the user for input on whether to do so in the first place.

This security challenge is inherent to mobile communications networks and impacts all wireless protocols and generations of cellular networks. Even newer 5G networks fail to prevent mobile devices from inadvertently camping on a malicious base station. This latest protocol provides no means to verify cryptographically the identity of base stations and networks to which a mobile device connects.

This implies that IMSI catching is still possible in 5G, and indeed, it is. The message “Hey, I am your operator and I forgot your TMSI. Please send me your IMSI” still lacks authentication and integrity protection in 5G. The only difference from LTE is that the concept of IMSI is replaced by the SUPI in 5G, and in place of TMSI, one would be referring to the GUTI.

However, 5G introduces a method whereby the SUPI is encrypted when being transmitted in a way such that only the legitimate home operator can decrypt it, thus effectively preventing IMSI catching in 5G. However, this method was recently proven easy to break.

For years, I have been advocating for the use of digital certificates and PKI-based systems in mobile communications systems. By the time I was starting to lose faith, one of the most renowned academic teams in the field of cellular security published a PoC demonstrating how to embed X.509 certificates within the SIB messages that are broadcast by LTE base stations.

This article presents some high-level details and discussion on a hypothetical private PKI implementation to tackle pre-authentication messages in 5G cellular networks. In order to introduce the subject and present an example that is familiar to technologists in general, the implementation of PKI in cellular mobile networks is described as an analogy to WebPKI.

2. Digital certificates and PKI

The main goal of using PKI and digital certificates in 5G is the same as applying this technology anywhere else: securely distribute public keys in order to verify the authenticity and integrity of messages transmitted over a communications channel.

Whenever a browser lands on, say, www.amazon.com, it is presented a digital certificate. At the time of writing, the certificate my browser was presented was issued by DigiCert.

This certificate, which was issued just a few weeks before I wrote this article, provides the browser with the necessary information to validate the origin and integrity of the contents of a given website.

In the case of an X.509 certificate, such as the one above, the main information provided is:

• Who issued the certificate (DigiCert in the example above)
• When the certificate was issued (11/5/2020)
• When it expires (10/31/2021)
• What domains this certificate is for (www.amazon.com, plus all the other hostnames listed in the Subject Alternate Name field)
• The public key (a 2048-bit RSA key, in this example, for www.amazon.com)
• The signature (DigiCert’s signature attesting that this is indeed Amazon’s public key)

The author strongly recommends reading this detailed analysis of all the fields found in an X.509 certificate encoded as an ASN.1 (Abstract Syntax Notation One) DER (Distinguished Encoding Rules) object.

By means of this certificate, the browser validates that this is the public key for www.amazon.com, and that it should be used to verify the authenticity and integrity of “messages” received from Amazon. In the case of browsing the web, that includes the contents of Amazon’s main website home page.

Although the certificate chain for the certificate in the example above is rather short, it is not commonly the trust anchor or main Certificate Authority (CA) signing public keys for everyone. There are intermediate CAs that sign certificates for others, with the root CA signing a certificate for the intermediate CA. As a result, digital certificates often act as a chain of trust. For example, the certificate chain of trust for www.wikipedia.com leverages the Internet Security Research Group’s Let’s Encrypt as its intermediate CA.

Briefly, Public Key Infrastructure (PKI) is the overall architecture, system, software, hardware and policy that is used to create, manage, distribute, revoke and use public keys in the form of digital certificates. PKI systems can be architected in a number of ways, with the following being the most common ones:

• Monopoly: Everyone selects a single entity to be the Certificate Authority to sign certificates for everyone else. Everyone trusts this single entity.
• Anarchy: No one trusts anyone and everyone trusts everyone else, all at the same time. In this model, each user is responsible for configuring trust anchors for individuals they know or they have met, and from whom they have securely received a public key. Did you ever see a public key on a QR code on someone’s business card? This is also the model used by PGP.
• Oligarchy: The model commonly used in browsers. Products come preconfigured with a number of trust anchors or certificate authorities, though this can be changed at any time. Any certificate signed by any of this pre-configured trust anchors is considered valid and, therefore, any valid certificate chain of trust that is seeded at one of these pre-configured trust anchors is accepted.

3. Leveraging digital certificates in 5G

As discussed above, cellular networks provide no means to verify the authenticity or integrity of messages at layer 2. To be more precise, the authenticity and integrity of layer 2 messages cannot be validated prior to the cryptographic handshake that occurs during the 5G-AKA (Authentication and Key Agreement) process.

For example, a mobile device decodes a SIB1 broadcast message indicating that this is a given operator’s legitimate base station. Despite the fact that there is no cryptographic verification and such a message could have been transmitted with a laptop and a $1,000 radio, the mobile device implicitly trusts the message.

Let’s use this example of a real 5G Release 15 SIB1 broadcast message captured from a real 5G base station in a lab setting:

The Mobile Country Code (MCC) and Mobile Network Code (MNC) in the SIB1 message indicates to the mobile device the alleged identity of the provider that owns and operates that base station. However, impersonating any provider on LTE, for example, is as simple as configuring srsLTE with the operator’s Mobile Country Code and Mobile Network Code (MCC-MNC).

A recent paper by an academic team at Purdue University presented an early-stage prototype that embedded stripped X.509 certificates in the payload of SIB1 and SIB2 messages. By means of embedding digital certificates in the 5G broadcast messages, a legitimate cellular operator could present a public key, which mobile devices would trust, that would be used to validate the authenticity and integrity of all layer 2 messages prior to the 5G-AKA handshake. In short, a certificate would be presented within the broadcast messages and the public key contained within it would be used to validate all subsequent messages that would be correspondingly cryptographically signed.

Such a system would prevent mobile devices from camping on a rogue base station, thus invalidating most protocol exploits identified over the last few years, including IMSI catching.

The 5G protocol introduces an optional feature to seed a public key of the home operator in the USIM (Universal Subscriber Identity Module). In a single-operator model, this could be leveraged to implement the aforementioned digital certificate system. This public key for the home operator would be the preconfigured root trust anchor used to validate certificates.

Unfortunately, this does not work in a practical scenario, which has a multitude of global operators, roaming agreements, and complex interconnected cellular systems. In many scenarios, layer 2 messages are crafted and transmitted by infrastructure that is not owned by the home operator. Therefore, these messages cannot possibly be signed with the home operator’s private key.

Then, how could a PKI system for 5G mobile systems be architected?

4. A PKI system for commercial 5G networks

The advantage of leveraging digital certificates in 5G and cellular systems in general is clear. This would mitigate and, arguably, fully remediate the threat of rogue base stations exploiting pre-authentication messages. By way of embedding a digital certificate in the SIB broadcast messages, each base station could securely provide all user equipment (UE) with that base station’s public key. With that key, all UEs could validate the integrity and authenticity of subsequent critical pre-authentication messages. More importantly, any mobile device could validate the legitimacy of a base station without needing to exchange any messages with that base station.

It is important to acknowledge here that this would only prevent UEs from camping out on a malicious base station. The challenge of UL protocol fuzzing remains. An adversary with a laptop running srsUE and an off-the-shelf software radio could still inject arbitrary messages into the network. In order to prevent this, mobile devices could be pre-seeded with a certificate signed by their operator. However, securely rotating keys and renewing a certificate in a phone would be very complex and is outside the scope of this article.

For a UE to validate the base station’s public key in the certificate, it would ultimately have to be signed by one of the root CAs that the UE trusts. For example, each UE or USIM could be pre-seeded at manufacturing with its own operator’s root CA.

In the event that UE roams abroad, the chain of trust then could look like this:

Once it has been established that all base stations would broadcast their X.509 certificate on the SIB messages, there are a number of design elements left in deploying and operating a global PKI system for 5G layer 2. Given the particularities and specific challenges faced in the context of a mobile system, these will be discussed in detail below:

• Pre-seeding of root CAs in UEs and/or USIMs
  • Where are root CAs stored?
  • How to update the list of root CAs?
• Who signs the certificate for each base station?
• Who signs certificates for operators or other intermediate CAs?
• How to revoke certificates?
• How to revoke trust on a root CA loaded in a UE/USIM?

Although a PKI system entails a number of other systems and functionalities, such as renewal of certificates, these present no added complexity in the context of mobile networks.

5. Loading and storing root CAs on a UE

Where to store the list of accepted root CAs in a smartphone is not a simple decision. Assuming the list of root CAs is stored in a file, there is a number of requirements and conditions to be considered:

• The file must be both accessible and readable by the cellular modem.
• There must be a way to update the file securely.
  • To update the file, there must be write access to the file from either/both userland and the cellular modem.
• Providing read-access to the file from userland to the root user, at least, would create a simple way to implement a periodic sanity check (periodic process that hashes the file and securely uploads it to the operator to verify it is the expected file).

Implementing a root CA update process from the cellular modem would be very complex, but it would allow blocking write access to the file from userland. This way the threat of mobile malware or social engineering is mostly tackled. Allowing the list of root CAs to be updated from userland would make it much easier to implement a secure method to do so. However, this would widen the attack surface on this file.

Such a system to allow for root CA updates should be designed very carefully, including the possibility of protecting the file behind an interrupt-driven proxied access method. Otherwise, having a file on disk or memory that can be accessed from both userland and the cellular modem could potentially widen the attack surface for, for example, zero-click exploits in the baseband aiming to move laterally into userland and then escalating privileges.

A compromise on the list of root CAs (or trusting a self-signed certificate) on a personal computer or a browser could lead to credential theft, financial loss, etc. However, in general, any non-administrator user in, for example, a Windows machine can easily update the list of trusted root CAs with just a few clicks.

The outcome of a compromise at 5G layer 2 on a smartphone would be much less devastating. Therefore, one could apply a similar threat model to the PKI system for 5G without making a compromise on security. Given the abundance and commonality of malware on mobile devices, though, it would be perhaps better to limit modification of the list of root CAs (e.g., write access to the file) exclusively to the root user. However, a compromised, jailbroken, or rooted device could result in malicious tampering of the file anyways.

In general, there is clearly no ideal location to store the list of root CAs, as storing it in either the SIM card or in a restricted location in userland had advantages and disadvantages.

6. Chain of trust in 5G mobile systems

As discussed above, each 5G base station should generate a key pair with both a public and secret key, and have an intermediate CA sign their public key within an X.509 certificate.

As the first intermediate CA, the obvious choice would be to have the operator sign the certificates for each of their base stations. This could be done in a centralized way or, more efficiently, in a distributed manner, with each network operating a number of intermediate CAs in different locations to distribute load and to provide, among others, DR compliance.

Setting up, maintaining, and running a PKI infrastructure is not simple. Therefore, certain operators, such as MVNOs (Mobile Virtual Network Operator), would likely have to rely on the infrastructure of their “parent” operator or on trusted third-parties to act as the intermediate CA. This would create a brand-new market for existing or new companies to offer PKIaaS-type of services. It is to be expected that such new companies would be subject to very strict regulations and oversight given their critical foothold at securing commercial mobile communications systems.

Assuming operators alone acted as the intermediate CA, a full oligarchy-based scheme could be implemented whereby roaming agreements would imply and derive into mutual trust between operators. For example, if Movistar in Spain had a roaming agreement with Verizon in the U.S., Movistar could sign a certificate with the public key of Verizon’s CA. However, this would require all operators to sign certificates for each other. Plus, base stations would have to broadcast multiple certificates, thereby greatly complicating the architecture of the system and its chain of trust.

A consensus should be reached by all telcos globally in order to define how to architect the rest of the chain of trust. Note, each country or region would have to settle for the same strategy, likely resulting in a heterogeneous chain of trust architecture globally.

In general, operators would likely delegate the CA role to either a public or a private entity:

• Public entity: The public institution or government agency with oversight of telecommunications policy and regulation could be tasked with owning and running or partnering with a CA. In the case of Europe, this role could potentially fall under the umbrella of the European Commission.
• Private entity: Much like the way x.509 certificates are issued on the Internet for applications running at layer 7, one could delegate the global or regional role of CA to a private institution. Even in the case of a public entity managing the CA, the infrastructure and systems of a private institution could perhaps be used.

Regardless of approach, the key operational challenge would be that all these entities running national and/or regional CAs would need to cooperate to enable each other’s chains of trust. Certain groups of nations, should as the European Union, could potentially leverage one single CA or easily organize each national CA under an EU one.

For example, following the example above, in order to have a European smartphone capable of roaming in the U.S., the European CA would have to sign a certificate for the central U.S. CA, though this would require the need to use a different chain of certificates for roaming devices as compared to American mobile devices. Alternatively, based on the policies and regulations in place, European-based operators could seed a root certificate for the American CA in mobile devices, thus allowing them to roam freely over each geographic region of the U.S. The decision on whether to add or remove a foreign root CA in mobile devices could be driven by the same entity that establishes the policies and regulations for telecommunications systems in each country or region.

7. Certificate revocation

One of the main challenges in leveraging certificates in cellular networks is, as I discussed during my ShmooCon talk, certificate revocation. If there has been an update in the certificate revocation list, a UE is unable to get that update until it has successfully connected to the network. In order to connect to the network, the UE must potentially trust a network and corresponding certificate that is perhaps in the last certificate revocation list update, which the UE has not seen yet.

As a result, there is a small risk even when leveraging digital certificates. For example, let us assume that there was a massive conflict escalating between the Spain and Eve-land while Alice was on a long-haul flight, during which her phone was turned off. Because Alice works for the TIA (Técnicos de Investigación Aeroterráquea, the mightiest secret intelligence agency in Spain), a government agency, it is critical to update the root of trust in such a way that Alice’s smartphone will not trust certificates signed by the subCA of Eve-land or any of the operators in that country. Otherwise, it would be a security risk and Alice’s phone could be the target of a malicious base station after she lands.

However, once Alice’s phone has been turned on again, it has no means of downloading a certificate revocation list before connecting to the network without first trusting an “old” certificate that is valid under the previous chain of trust. As a result, the phone will still trust any base stations of any operator in Eve-land.

This is a very hard problem to solve in a purely cellular communications context. How does one check a certificate revocation list if, in order to do so, one must first connect to a base station that could be using a revoked certificate? Could OCSP stapling be the solution?

Cellular-only access scenario:

One potential solution would be to identify high-risk scenarios and allow the device to initially connect in a low-exposure mode, retrieve the certificate revocation list, verify it, and then proceed.

If a UE has been off, offline, or in airplane mode for more than a certain time threshold T and, upon reconnection, it sees an MCC-MNC combination for, for example, another country, the UE would enter a low-exposure mode. Low-exposure would also be triggered if the UE noticed a substantial difference between its current location and its last known location before going offline. This would prevent rogue base stations from Eve-land attempting to impersonate Alice’s home operator from Spain.

In low-exposure mode, the phone should refuse connections and downgrades to any legacy protocol, particularly GSM. The phone would also ignore, and then disconnect, any messages with security implications, such as a request to disclose its IMSI/SUPI, regardless of the EMM cause code (3GPP TS 24.301, page 244).

Once in the low-exposure mode, the UE would connect to the network normally and attempt to establish a secure channel (mutually authenticated and encrypted) with the home operator. The UE would check whether there are any updates to the certificate revocation list, and download any update. It would then disconnect from the tower/network and start over in “normal” mode with an updated certificate list. Even if connected to a rogue base station, the certificate revocation list could not be tampered with without alerting the UE, which would disconnect immediately.

Given the sensitivity of Alice’s work for TIA, her phone could also be configured to stay entirely radio-silent if any of the aforementioned events that would trigger low-exposure mode occurred. This would mitigate other potential threats at layer 2, such as device and/or traffic fingerprinting and RNTI-based tracking.

This method does not work if the compromised certificate is from the UE’s home operator or if, after a certain time offline, the UE connects to a rogue base station that advertises itself as the home operator. Therefore, as a fail-safe mechanism, all UEs should periodically establish a mutually authenticated secure channel with their home operator to download any updates to the certificate revocation list. This way, devices would only be vulnerable during limited time windows.

In such a cellular-only scenario, an alternative for certificate revocation would be implementing OCSP stapling as described below.

Heterogeneous access scenario:

In the context of commercial networks and off-the-shelf smartphones, this problem could be solved by obtaining the latest certificate revocation list “out of band.” For example, if low-exposure mode were triggered, the device would have to connect to the network via 802.11 to download the latest revocation list prior to fully enabling its cellular radio.

There are multiple methods to establish a secure end-to-end connection with a remote server over an insecure network, be it an airport or hotel’s public WiFi network. Moreover, leveraging any of these non-cellular access networks does not carry the same security baggage as cellular. There are no pre-authentication messages in the TLS handshake that successfully instructs an endpoint to turn off its radio, downgrade to an insecure connection, or disclose a secret identifier.

OCSP and OCSP stapling:

Online Certificate Status Protocol (OCSP) is a common alternative method to check the validity of a certificate. By means of an authenticated and secured query to the issuing CA’s revocation server, a client can check the validity of a given certificate. The author recommends this article to learn more about OCSP.

This method, although common, would still not work for 5G certificates embedded in SIB broadcast messages as the UE is required to be online in order to query the certificate’s serial number against the OCSP responder. However, OCSP stapling is a possible solution to the challenge of revoking certificates in 5G. In the case of OCSP, the “network” would query the OCSP responder itself and staple such response from the issuing CA, which the UE can validate using the CAs root certificate loaded in the UE, onto the same broadcast message. This is a very attractive solution to this challenge, though it requires further bytes to be added to the SIB broadcast messages. Although this would not be possible today (the authors of this paper already had trouble to embed a trimmed down version of X.509 certificates within a SIB message) it is a viable solution should the requirements and schema of broadcast messages change in upcoming standard releases. However, this would obviously break backwards compatibility.

8. Concluding remarks

Cellular networks have been one of the main drivers of the technology revolution of the last 20 years, which has given birth to a myriad of ubiquitous and ultra-popular services, such as Uber, Google Maps, and such. However, the security for these radio access networks at layer 1 and, mostly, layer 2 has not kept up with the pace of other access networks.

With all security protections and precautions enabled, browsing the Internet over WiFi does not pose any substantial risk to an endpoint, at least in terms of protocol security. Implementation of the protocol at the baseband and exploiting baseband bugs for fun and profit is a completely different story.

Still, a number of pre-authentication messages in the 5G protocol cannot be cryptographically verified today. As a result, connecting a mobile device to a 5G network is, in essence, no different from trusting a self-signed certificate when browsing the Internet.

For years, a number of researchers, including myself, have advocated for the use of PKI to enhance greatly the security of 5G networks at layer 2. Despite its security benefits, this massive endeavor would take years and require global collaboration among operators and industry, in addition to sign-off from the standardization bodies. Unfortunately, it is 2021, we are at Release 15 of the 3GPP standards, and we are just now starting to see small signs that PKI might have just gotten its foot into 5G’s door. This is going to be a long journey.

It is unlikely that a full-fledged 5G PKI architecture will be deployed within the next few years. I personally find it interesting that some organizations are already discussing “6G”, whatever that is. Yet, cellular systems still carry baggage that was packed in the early ‘90s.

It is also important to acknowledge that, in terms of a threat model, the lack of integrity protection and authentication in certain 5G messages has a small impact when compared to the impact of accepting a self-signed certificate when browsing the Internet. In general, there is a higher risk and exposure when accepting a self-signed certificate on a browser (or having a malicious root CA loaded onto the browser) compared to when your smartphone discloses its IMSI as a response to a message without integrity protection and authentication (“I could be anyone, but trust me, I am you operator. Would you please send out your IMSI in the clear?”).

Update, and contribution, to to leveraging Digital Certificates to enhance 5G security

A few weeks ago I wrote a blog post about a 3GPP SA3 proposal to leverage Digital Certificates in cellular networks. Despite some aspects in the proposal being far from ideal (as I discussed in the blog post), that proposal was and is very good news. It is the first time I have seen an actual proposal to leverage PKI to address inherent security issues in cellular networks on both LTE and 5G.

Today, a new revision of that proposal has been published, and I am now one of the co-authors (under my Softhandover affiliation). The new revision of 3GPP SA3 S3-202630 can be found here.

This is a proposal for Non-Public Networks (NPN), which are essentially “private” 5G deployments commonly used for critical applications such as first responders, tactical networks, utilities and industrial plants, etc. As such, this proposal is not aimed at commercial 5G deployments. However, the technology proposed could fairly easily be applied to commercial 5G networks by expanding the Certificate Authority network. For example, a TelCo operator could sign certificates for foreign operators with which it has trusted roaming agreements, such that devices roaming could verify the certificate chain that a roaming base station presents to the UE.

One of my main concerns with the previous revision was that it proposed to encrypt broadcast messages as opposed to sign them.

The newest revision proposes to actually sign broadcast messages along with a digest that includes a time stamp and, potentially, some form of geo-location in order to prevent for those messages to be replayed. Along with the message, each base station passes to the UE a certificate signed by the core network which attests the base station’s public key.

By leveraging digital certificates and a root of trust pre-loaded on the UEs (in the case of private 5G networks, the core network as Certificate Authority) both broadcast messages (SIBx) and signaling messages (RRC, NAS, etc) can present a certificate to the UE. Then, the UE can cryptographically verify that they originated at a real and trusted base station.

I am not too familiar yet on how 3GPP procedures work when it comes to such proposals, so I am not sure why the introduction of the document still alludes to encrypting broadcast messages, tough. But the body of the proposal is updated with the aforementioned improvements.

I have been advocating for years for leveraging PKI-like technology in cellular as a solution to the many vulnerabilities that leverage pre-authentication messages. Back in February, during my talk at ShmooCon, I made the case once more. I am glad to see that things are finally starting to move in that direction. And I am a coauthor!

If this proposal is approved, it will be part of the actual 5G standard. Exciting to know that I might be able to contribute to the global standard for cellular communications to improve its security. Hopefully we can bring such a proposal to commercial 5G deployments as well.

Security analysis of 5G traffic

A few months ago, before the world as we knew it changed entirely into this “new normal” we live in, I rode the Acela to DC for a couple of days to give a talk in 5G security at SchmooCon. During the talk, given the obvious time limitations, I was not able to go in depth in the security analysis of 5G traffic.

I am done reading a book I was reading and I am out of things I want to watch on Netflix, so on nights I do not run or exercise, I started doing a bit of writing as part of my (pandemic+fatherhood)-induced Revenge Bedtime Procrastination. My plan is to eventually publish a paper with the full security analysis of 5G traffic but, meanwhile, I thought I would post some further analysis and ramblings here. Also, I was able to get some new traffic captures to analyze.

All captures analyzed here are from actual 5G devices (Release 15 compliant) communicating over 5G standalone mode (5G-SA). The traffic was captured with the Sanjole Wavejudge tool. The analysis has been done with the Sanjole Wavejudge v5.3.1 software analyzer. In the figure above we can see this particular capture is for a Release 15.4.0-compliant device.

This is a pretty good capture that contains the expected broadcast messages (MIB and SIB1) plus the attach handshake for a given UE. If we filter out everything and focus strictly on the messages between the UE and the gNodeB, we have the following:

This particular capture contains the PRACH handshake (without contention resolution) and the RRC handshake. However, we can notice that the DL MAC-RAR message is missing as well as the UL RRCSetupRequest. And the information transfer messages appear to have been retransmitted a few times, indicating perhaps issues at decoding those messages at the UE or the gNodeB. In a follow up post I will analyze another interesting capture of a UE initially connected to LTE that transitions to 5G via an RCCConnectionReconfiguration message sent by the NodeB. That capture is much cleaner and with all messages.

Note that 5G captures are massive and, unlike LTE captures that can be dumped in real time onto a pcap file, very short in duration. This particular capture is just 1.6 seconds long. This is why there is so few user messages in it.

One of the main things I argued in LTE and, as I discussed during my talk, is still an issue in 5G, is the potential for user tracking leveraging the RNTI. The T-RNTI derived during the RACH handshake, which is eventually upgraded to CRNTI, stays constant for long duration of times and allows to tell apart traffic between multiple users regardless of encryption. It is not that interesting in this capture as there is only one UE communicating. Plus in this capture there is no MAC-RAR message, which is the packet that allows to map an RNTI to a target user by triggering the target’s device to connect to the network at a known time. This can be achieved in many ways and the only requirement is to trigger a paging message for the target.

In the capture I analyzed for my ShmooCon talk, however, I was capable of dissecting the DL MAC-RAR message. As shown on the figure above, the T-CRNTI field in this message indicates the id to “track” to be able to tell apart traffic from a given target from the traffic of all other users. This is, for example, one of the setup steps of the aLTEr attack in order to identify DNS requests for a given UE. As I always highlight, this trick has been one of the stepping stones for a number of exploits demonstrated by academic teams over the last 3 years, however it was initially deemed not a security risk by 3GPP a few years ago after I introduced this issue.

Similarly to LTE, the 5G SIB1 broadcast message, shown directly above, discloses certain information, such as the identity of the operator of the tower. This has been identified as a potential issue in tactical or ad-hoc cellular deployments for critical applications, such as first responders. However, it is not really doable or feasible to encrypt this information in the broadcast messages, so this should be part of the overall threat model and attack surface evaluation of the 5G protocol. These messages should be signed using a digital certificate, though, as I argued in my ShmooCon talk.

Something interesting in cellular protocols is the amount of padding bits left in most messages in order to make room for potential new additions to the protocol. The SIB1 message, for example, has 13 bytes of padding always set to 0x00. When running fuzzing tests, I always like to add garbage in there to see how the cellular modem treats that. In some private deployments, it is not rare to see opportunistic usage of padding bytes for certain applications and, if the custom firmware does not properly treat those extra bytes, things get interesting.

These extra bytes have also been used recently to demonstrate the implementation of X.509 digital certificates in cellular in what was, in my humble opinion, the greatest and most promising paper in cellular security of the last few years.

Although the software does not allow me to decode some of the payloads embedded in certain RRC packets in this capture because the MAC layer appears to have been in developer mode in the UE+gNodeB, there is many things we can analyze. The raw bytes of the NAS payload can easily be decoded manually, though. I will work on that when I have some time.

Among the many pre-authentication messages that are exchanged in the 5G attach process, the devices exchange their capabilities reports in the clear (which this talk from BlackHat 2019 leverages to fingerprint devices). The message below, obfuscated, lists the capabilities of the UE in the ue-CapabilityRAT-Container payload.

Then the devices finally settle the cipher and integrity protection algorithms to be used in the SecurityModeCommand message.

In the context of LTE, in the event that UE is connecting for the first time, or in any event in which the serving network does not have the TMSI/GUTI of the UE, this one will transmit its IMSI in the clear. In the case of 5G, when the optional feature of protecting the SUPI is enabled (which I suspect will rarely be the case), the UE will disclose its SUCI (encrypted version of the SUPI). The capture above of an RRCSetupComplete message indeed contains a SUCI (obfuscated), indicating that this feature is enabled in this test network.

The SUPI encryption process, which is an optional feature, is well designed and does prevent identity tracking of devices, with a different SUCI being generated each time the SUPI is encrypted. Therefore, being able to capture SUCIs should not lead to fingerprinting a given user or device.

As I discussed during my talk, despite interesting new security features such as SUPI encryption, 5G protocols still leverage a number of handshakes that are not encrypted, not authenticated and not integrity protected. And, by means of abusing these messages, an attacker could launch similar attacks to the ones I started implementing 10 years ago, with a small subset of them being what I was able to demonstrate during my 2015 ShmooCon talk.

If you are interested in this type of security research, feel free to reach out. I know a few of groups in academia (UC Irvine, VATech, Mississippi State University, etc) that are looking for students to work in 5G protocol security. Also, the folks at the CCI 5G Security Initiative are also actively searching for security researchers (PhD grads and postdocs) and engineers to work in running and leveraging their security research 5G testbed.

When I have time I will post a follow up to this with an analysis of a capture of a UE initially camped in an LTE cell moving into a 5G cell. As part of this analysis, I will revisit a number of security issues that are present in LTE protocols.

Time to go to bed now. I’ll schedule this to publish tomorrow around lunch time so bon appetit!

 

Comments on 3GPP TSG-SA3 proposal S3-202161 – Leveraging digital certificates in cellular communications

I finally had some time, once I finished reading Do What You Want (highly recommended! Especially if you are a fan of the band like myself), to write a few notes on the first proposal I have ever seen in 3GPP to leverage digital certificates in cellular communications.

S3-202161 was among the many proposals discussed during the August 2020 meeting of 3GPP SA3. As I mentioned a few days ago, this proposal is beyond great news as it is the first proposal to leverage digital certificates in cellular that I have ever seen.

It is important to note that this proposal is strictly aimed at private 5G deployments, which has very different implications than commercial networks. The threat model is similar, though the solution can be slightly simple as there is no need for a full-fledged PKI infrastructure with CAs and sub-CAs and the need to validate certificate chains. As I mention below, if this proposal was for commercial 5G networks, it would be very incomplete and far from optimal or secure.

In general, anything that leverages digital certificates in 5G is a good idea compared to the current security specifications, period. However, there was a few items I wanted to discuss about this proposal that I summarize in this post.

• Encryption: This proposal appears to be hyper-focused in leveraging PKI to encrypt (as opposed to sign) pre-authentication messages. This is interesting. In general, assuming that the feature to encrypt the SUPI is always enabled (wishful thinking, I know…), encrypting pre-authentication messages does not address much of the threat model in cellular networks. After all, there is not much that an attacker can do by eavesdropping signaling messages as long as they cannot be spoofed or modified. Things like the RNTI are in the header of the outermost packet/payload, so that would likely never be encrypted. Otherwise each UE would have to (attempt to) decrypt every single packet it receives in the DL and run crypto on it. This way the radio would never be able to shut down to save battery. In general, aiming to encrypt the pre-authentication messages sounds like a sub-optimal strategy.
• Encryption with asymmetric keys???: It is interesting that the proposal aims at encrypting pre-authentication messages (referred to as unicast messages throughout the document) using asymmetric keys. Given the compute power of a smartphone and current basebands, this might be ok. But, in general, encryption/decryption using secret/public asymmetric keys is not a good idea. Keys are very large (current standards dictate 1024bits if not 2048bits) and encryption is computationally expensive and slow. Asymmetric keys are normally leveraged to secure an initial handshake to establish a secure channel and derive a session symmetric key, using thereafter AES or a similar symmetric cipher to encrypt traffic.
• Why not signing pre-authentication messages?: The majority of vulnerabilities identified in the LTE protocol over the last 4 years leverage spoofing pre-authentication messages. Although encrypting these messages is, perhaps, achieving a similar outcome to just signing them, it is surprising that the proposal does not aim at signing the messages. Ideally, those messages would be signed – but not necessarily encrypted – using an HMAC (if the UE and gNodeB have derived a symmetric “session” key already) or a digital signature that factors in a hash. The hash component is critical to prevent, among other threats, replay attacks. Note that just signing, for example, SIB1 messages and many RRC messages would not prevent replaying those messages later. In general, one should hash a timestamp and other metrics such that a message cannot be replayed or reused. Many years ago I worked on a project that PoCed something similar to this to protect SIBx messages. Some other items we proposed to hash were a fingerprint of the physical location of the tower and a timestamp.
• Threats that are not mitigated by this proposal?: Possibly the most interesting aspect of this proposal is section “6.2X.3.3 – Threats that are not mitigated by encrypting unicast signaling messages“, which explicitly mentions preventing UEs from camping on false base stations. I think that this should be the main goal of such a proposal. Even if encrypting signaling messages instead of signing them, I believe this proposal does prevent UEs from camping on malicious base stations, which would not be able to produce signaling messages that the UE can cryptographically verify as legitimate.

Regardless of the above, it is very good news that digital certificates are finally being considered for cellular communication systems as a way to prevent attacks that abuse unprotected pre-authentication messages.

However, such a solution would not suffice for 5G commercial deployments. In such a scenario, in order to support many of today’s use cases, such as roaming, a full-fledged PKI system would be necessary, with multiple CAs and each operator/country deciding what CAs to trust and which ones not to trust. Moreover, logistics such as certificate rotation and, especially, revocation would be very complex. I shared some thoughts on that in a previous blog post.

Done for tonight. Now I need to find myself another book to read. If only all my favorite bands wrote a book about their history… Again, I highly recommend Do What You Want.

 

Leveraging Digital Certificates to secure cellular communication networks

For over 10 years I have been identifying and testing a number of exploits in cellular protocols that leverage what I refer to as “pre-authentication message”. In parallel, I have been witnessing the rise of a number of excellent academic teams doing outstanding research in this area and identifying further security issues in cellular protocols, mst of which are root-caused by pre-authentication messages.

This never-ending challenge spawns from the fact that (as I highlighted back in January 2016 during my ShmooCon talk) any mobile device will exchange a number of messages in both directions with any base station, malicious or not, that advertises itself with the right broadcast information. A mobile device has no means to verify cryptographically the legitimacy of a base station until it has gone through a number of insecure (in plain text, no integrity protection, no authentication) message handshakes that occur prior to the establishment of an authenticated and secured connection.

For years I have advocated for the use of a PKI-like system in cellular, leveraging digital certificates to substantially raise the security bar against the threat of rogue base stations in both LTE and 5G.

After all, when I browse Gmail and I am asked to type in my credentials, my browser and, by extension myself, knows that it is indeed “Gmail” who it is speaking with before sending any “messages” to it. This is technology that has been deployed and matured for over 15 years and have made possible things such as eCommerce. However, when my smartphone sees a base station it has no way of verifying its legitimacy prior to exchanging a number of messages that have been proven to be exploitable for Denial of Service, silent downgrade to GSM, IMSI catching, etc.

A couple of years ago, the best thing in years in cellular security research happened. Syed Rafiul and his team at Purdue University published a paper detailing neat and really promising results of their application of digital certificates to LTE. In a nutshell, they did a PoC embedding X.509 certificates in the broadcast LTE messages, using srsLTE for it.

From that moment I have been waiting for the day someone would propose using digital certificates in cellular. And it seems that day has finally come. In this month’s 3GPP SA3 meeting, a number of proposals were presented. Among them, two that discuss leveraging Digital Certificates to substantially raise the bar against rogue base station attacks. This is a goal clearly stated from the get-go, with one of the documents entitled “Study on 5G security enhancement against false base stations“. These documents can be found in this link, by searching (ctrl+f) for “Mitre”.

• Study on 5G security enhancement against false base stations:

Interestingly, this first proposal discusses encrypting messages, not signing them, which is not exactly what I was expecting. Nevertheless, this proposal is mainly geared towards Non-Public Networks, eg. private cellular deployments, so that might be why its a proposal slightly different than what I have been advocating and recommending for years. The proposal goes on stating that X.509 certificates will be pre-loaded for the gNBs a given UE is allowed to connect, which would obviously never scale in a commercial network.

• Study on authentication enhancements in 5GS:

This second proposal is very similar to the previous one, both in its scope and in that it seems to place most highlight in encryption as opposed to authentication. Interestingly, this proposal covers certificates in both directions, in the sense that both the network (gNBs) and the UEs provide certificates to distribute their public keys.

 

In general, this is very good news as it is the very first time such a proposal ends up in the standards. These two documents are mostly geared for non-public cellular networks and do not scale too well over commercial deployments, but it is a great step in the right direction.

As I discussed in my ShmooCon talk in February, pre-authentication messages still exist in 5G and they can be exploited in similar ways as in LTE to launch DoS attacks, silently downgrade the connection to legacy protocols, etc.

In deploying digital certificates in cellular, one could leverage the existing trust relationships between global operators (eg. roaming agreements) to build and architect the certificate chain and corresponding roots of trust each operator chooses to pre-load on their devices or USIM cards. For example (in very high-level detail):

• Each mobile operator is a sub-CA and trusts/signs certificates for their own base stations.
• Each mobile operator has a list of trusted partners/peers (eg. via roaming agreements) and, as such, it signs and certifies the certificates for each of those operators, which can then act as a further sub-CA.
  • Alternatively, the mobile devices of USIM cards could come pre-loaded with the certificates for the national operators a given operator “trusts”.
  • However, it is always best to trust no-one but your own operator and let the chain of certificates, which can be adjusted any time, do the rest.
• Each country could have a trusted 3rd party be the national trusted CA, which could in turn decide what other countries to “trust” and, thus, sign the certificates for the national CA of these countries.

Looking forward to seeing where do these two new proposals end up.

Edit (08/25/2020):

One of the main challenges in leveraging Digital Certificates in cellular is, as I discussed as well during my ShmooCon talk, certificate revocation. If there has been an update in the certificate revocation list, a UE is not able to get that update until it has successfully connected to the network by, potentially, trusting a network and corresponding certificate that is perhaps in the last certificate revocation list update.

As a result of this, there is a small risk even if leveraging digital certificates. For example, let’s say that while you were on a long-haul flight with your phone off, there was a massive conflict escalating between the US and country X. Because you work in, for example, XYZ government agency, the certificate chain is updated in a way that your phone will not trust anymore certificates signed by the subCA of, for example, country X or any of the operators in that country. Otherwise, it would be a security risk and you could be the target of a malicious gNB at the arrival airport.

At that point, your phone has no means of downloading a certificate revocation list because, by definition, it has not connected to the Internet yet. And, as a result, your phone, upon landing, will still trust the “old” certificate chain and the base stations of any operator in country X.

One potential solution to this would be the following:

• If your phone has been “off” for a few hours and sees an MCC-MNC combination for, for example, another country the phone enters a “let’s be careful mode” (limited security exposure to a potential rogue base station).
• Connect to the network normally and attempt to establish a secure channel (mutually authenticated and encrypted) with your home operator.
• Check whether there is any updates in the certificate revocation list, download any update.
• Disconnect from the tower/network and start over in “normal” mode with an updated certificate list.

In the event that, upon landing at the airport in country X, my phone connects to a rogue base station, this will be within this “minimal security exposure mode”. In that case, establishing the secure channel with the home operator will fail. Only if the base station I am connecting to is legitimate and operating normally, the UE will be able to download the updated certificate revocation list.

Testing Sniffle, a new sniffing tool for Bluetooth 5 and 4.X LE

A few days ago I read about NCC Group’s Sniffle tool, a BLE sniffer for Bluetooth 4.X and 5. Given my interest and previous track record at looking into the security of BLE devices, I could not stop myself from testing it.

The tool is available on NCC Group’s Github, along with quite good documentation. It was not hard to install all the prerequisites and set up everything following their documentation. My environment is pretty well set up for this type of experimentation and devices, so from Python to PySerial, I did not have to do much. All the TI-specific tools should be installed in their default folders suggested upon install (when running the .run files) and one will not have any major issues.

So far, I have been able to run the sniffer on the TI CC26x2R Launchpad Board. The firmware loads without issue and the board is ready to use. Note that, as I will describe below, I have been having a bit of stability/buggyness issues with the sniffer. Whenever something acts up a bit, the best thing to do is to reload the firmware. That seems to get things fixed for me most of the times.

Once the firmware is loaded, it is easy to start running captures. Given the simplicity of the radio it’s running on, the sniffer can only scan one channel at a time, so you are either scanning ADV channels (37, 38 and 39) or following a connection. Therefore, unless you happen to catch an actual connection establishment, you should expect to only see ADV-related messages on your first captures.

Once you are all set up, it is highly recommended to dump the traffic being captured to a pcap file using sniffle’s -o option. Looking at one of the captures I took, I see the expected advertising traffic. A whole bunch of Apple devices (in my experience, always very “loud” at sending ADV-related traffic) from my neighbors, some smart TVs (including mine; it’s been the subject of my research before and I know like the back of my hand the characteristics of its ADV packets) and some interesting devices that I will explore when I have more time.

Now that I am all set up, I will start taking actual captures of devices connecting and will test how reliable Sniffle’s ability to follow connections is. By the way, once you capture a full initial pairing and connection establishment, you should be able to process the pcap with Crackle to bruteforce the LTK session key and decrypt traffic. This is possible unless the pairing is being done with the Out of Band method. In my experience, the only device that I have observed in the wild using OOB pairing is the Apple Watch, though.

While using Sniffle I have noticed some instability. Every now and then I get weird errors raised by sniffle when having trouble parsing certain packets. See example above for a crash when it parses a packet that, allegedly, has an incorrect length field. I have observed similar parsing errors happening from time to time. When this happens, sniffle seems to get stuck when you try running it again. The quickest fix is to reload the firmware.

Once I have some time I will continue playing with sniffle. With two kids now, time is a very scarce resource! 🙂

EDIT (10/04/2019): Correction to myself. Bluetooth 5 *should* be using Diffie-Hellman for the handshake to derive STK which encrypts the handshake to exchange LTK. If that is the case, even when sniffing a full initial pairing+connection, one could not be able to brute force anything. I have to find myself a Bluetooth 5 device and capture that traffic. I’ll update when I have some time.

A reflection on the history of cellular security research and the security outlook of 5G

(Originally published as a LinkedIn article – Reposted on this blog)

About 10 years ago, I started working on mobile and cellular security research. While most of my work in the early days leveraged costly network testing equipment and a neat lab set-up, I also experimented with a number of open-source implementations of the LTE (Long Term Evolution) PHY layer, which were critical for the work on protocol-aware jamming back in 2011. Everything changed in 2012, though. On December 31st 2011 the first commit for openLTE had been uploaded and for the very first time, there was an open-source implementation of the LTE stack aiming to go beyond the PHY layer. Just a couple of years later, by 2013/2014, after outstanding progress in the development of openLTE, I was in the lab able to test LTE IMSI-catching, taking advantage of unprotected AttachReject messages and tracking devices via mapping MSISDN (i.e. phone numbers) to TMSI to C-RNTI.

During those years, other implementations of the LTE stack became available, though I stuck with openLTE until srsLTE reached a significant level of maturity. Currently srsLTE is by far the best and most widely used – both in academia and industry – tool for LTE security research. srsLTE has been my tool of choice since my career change in Fall 2015, after which I used it to rewrite my IMSI catchers, protocol exploits, and RNTI-based techniques for my January 2016 ShmooCon talk.

Around that time, I wrote an article predicting that the combination of a) low-cost software-radios, b) mature and very stable open-source implementations of the LTE protocol stack, and c) an army of bright, smart and talented grad students, could only have one possible outcome. I predicted – not taking much credit for that prediction, as it was quite clear that it would happen anyways – that within the following few years there would be a number of new academic research labs working in cellular network security projects, and a large number of new exploits identified in cellular networks released in papers at top security conferences.

It has been 3 years since I published that article and, indeed, researchers have found numerous flaws in the LTE protocol by applying formal verification techniques to the LTE standards, hijacked DNS requests and responses at LTE’s layer 2, exploited flaws in the Self Organizing Network protocols of LTE, and tracked devices via their GUTI, to name just a few.

Most of the vulnerabilities identified by researchers so far primarily affect subscribers and mobile devices. However, the latest addition to the srsLTE toolset, srsUE, is already changing the cellular security research landscape. srsUE is an open-source implementation of the UE (User Equipment) LTE stack. As such, it facilitates the same type of security research against the network infrastructure, as opposed to just mobile devices. In other words, it is now possible to fuzz cellular protocols in the uplink against the network infrastructure and, for example, send arbitrary messages to an MME (Mobility Management Entity, one of the core parts of an LTE network).

It is worth noting that some teams in academia have already started experimenting with uplink LTE protocol fuzzing. Recent results indicate the feasibility of crashing network equipment. In addition, an academic research team published an excellent paper identifying a number of previously unknown protocol exploits in LTE that are being assigned CVEs and addressed by the OEMs and operators.

In parallel, the industry is in the midst of the 5G marketing frenzy. 5G is introduced as a panacea to everything that needed to be addressed in previous mobile generations: a revolutionary technology that will empower exciting new applications such as smart vehicles, critical control of remote devices, virtual reality, etc. In that context, the industry has been raving about the security of 5G and its resilience to cyber-attacks. However, a number of recent studies and publications indicate that the marketing statements about 5G security are actually inaccurate and things are not much different than in LTE.

The security research landscape has changed drastically when it comes to cellular network security. The GSM (Global Standard for Mobile communications) standards were drafted in the late 80s and no major vulnerabilities were publicly released until the Barkan attacks against A5/1 and Karsten Nohl’s presentation at the Chaos Communication Congress in 2010. It took over 10 years from GSM to be standardized and deployed to the first security issues being identified. Similarly, the LTE standards were finalized sometime between 2007 and 2008, and operators started deploying LTE networks sometime around 2011. It only took a few years, though, for security researchers to identify and release exploits in late 2015, including the excellent work from an academic team in TU Berlin and the results I myself released at ShmooCon.

This trend of identifying protocol vulnerabilities sooner and sooner after the inception of a new mobile generation also applies for 5G. The first release of the 5G specifications was published in March 2018. Just a bit over a year later, the research community has identified protocol vulnerabilities in the 5G-AKA (Authentication and Key Agreement) and privacy breaches in 5G. It is worth highlighting here that 5G mobile networks are not even deployed commercially yet, though over the last year there has been half a dozen papers published highlighting critical vulnerabilities in the technology that is supposed to drive mobile systems and innovation for the next 10 years. More importantly, a recent study highlights the fact that 5G protocols are still vulnerable to the great majority of exploits existing in LTE as they carry over the main root cause of threats against LTE.

The greatest common divisor of most vulnerabilities identified in LTE over the last 5 years is what the research world refers to as pre-authentication messages. Unlike other layer 2 protocols, cellular networks rely on an implicit reciprocal trust between Alice and Bob prior to executing the authentication cryptographic handshake. In other words, a UE blindly trusts any base station that appears to be legitimate and the base station blindly trusts anything that looks like a commercial UE even before they have mutually authenticated. Needless to say, it is trivial to configure a rogue base station or rogue UE to look like a real one.

Security threats spawn from the fact that, by spoofing or intercepting such pre-authentication messages, an adversary can turn a smartphone or mobile IoT device into a connectionless brick or silently downgrade any UE to an insecure connection over GSM. IMSI catchers, commonly referred to as Stingrays or cell site simulators, are actually possible in LTE because of the exact same reason. The message that instructs a UE to disclose its IMSI in the clear is a pre-authentication message that can be trivially spoofed and directed to all UEs in a geographical region. Note that this is possible by literally just adding a couple extra lines of code to srsLTE. Spoofing presidential emergency alert messages is also possible because many messages in LTE cannot be properly identified and attributed.

Stingrays have been for years the security threat in cellular networks that attracts the most attention from the media, especially since the discovery last year of evidence of numerous Stingrays in the Washington DC area. This might be the motivation behind the proposal in 5G for a solution to prevent IMSI catchers. This specific solution, if implemented, would indeed prevent certain IMSI catcher style attacks in 5G. As such, it has been the cornerstone of the industry’s elevator pitch praising 5G security. Unfortunately, this security feature in 5G appears to be defined, as many others, as optional, leaving it up to the operator whether to implement it or not. The history of previous generations indicates that optional features rarely get fully implemented. This is one of the reasons why the implementations of the same cellular protocols end up being dramatically different from operator to operator.

After years of cellular security research, many scientific publications at top security conferences, and numerous exploits and vulnerabilities, all with one single clear root cause, it is interesting that the industry and standardization bodies have not yet tackled the pre-authentication message challenge. After all, there are mature and widely deployed technologies in the Internet that allow endpoints to validate the identity of a server before needing to perform a cryptographic handshake. TLS (Transport Layer Security) and its deprecated predecessor, SSL (Secure Sockets Layer), are perhaps the best-known examples. These technologies have made possible the rise of eCommerce and other modern applications, providing the necessary tools to authenticate communication endpoints prior to any handshake by means of digital certificates.

A number of security researchers, myself included, have been advocating for the application of digital certificates or related technologies to cellular networks for years. An excellent recent paper implements a proof of concept of the application of X.509 certificates in cellular networks, presenting very promising results. This is the first time, to the best of my knowledge, that such a study is published.

Leveraging digital certificates in cellular networks would require architectural changes from the ground up at a very large scale and, unfortunately, this is unlikely to occur. There is little incentive in the industry to make large changes to a security architecture that has remained rather unchanged for many years.

The cellular industry and the technology behind it are tightly driven and regulated by the 3GPP (3rd Generation Partnership Project) standards, which could and should be the driving force behind such a paradigm change in how security and trust are established in cellular networks. However, the strongest forces sitting around the table at standardization meetings are the cellular industry itself, both telcos and OEMs, which seems like a clear conflict of interest. As a result, the outlook of the state of affairs in mobile network security is not likely to change in the short term.

It took over 10 years for researchers to find security flaws in the GSM protocol, just a few years for the first protocol exploits to be identified in LTE and, in the case of 5G, researchers are already highlighting vulnerabilities before the technology is deployed and available for consumers. Despite the challenges and lack of incentives for the industry, this might finally be the time to start addressing security weaknesses inherent to cellular protocols since their very inception. Until that happens, though, I look forward to excellent cellular security research from bright grad students and hackers alike, and to reading future papers they publish.

The current state of affairs in 5G security

The first version of the LTE specifications (3GPP Release 8) was published in 2007. For obvious reasons, I am unaware of the state of R&D in LTE security in 3-letter agencies. In the research community, though, the first public disclosure of protocol exploits against LTE did not occur until early 2016 with the work of the team of Prof. Jean-Pierre Seifert at TU Berlin [1] and myself [2].

Back in May of that same year I wrote an article discussing the main reasons why it took 9 years for us security researchers to start finding vulnerabilities in LTE protocols and testing them. The lack of maturity of software-defined radio hardware and, mostly, the lack of open-source low-cost software implementations of the LTE protocol stack. However, as I stated in that article, when the first commit of openLTE was pushed in 2012 things started to change. And then, a couple of years later, srsLTE was available as well. Back in 2016 I anticipated to see a wave of excellent security research in LTE, which would uncover all sorts of vulnerabilities.

As I expected, over the last 3 years, some academic research teams have crafted excellent research and published groundbreaking papers disclosing new vulnerabilities of the LTE protocols (e.g. [3,4,5]). And now, with the availability of srsUE, the possibilities are endless in terms of exploring the security of LTE against the operator’s infrastructure. I am myself collaborating with two teams in academia in what I call LTE protocol fuzzing using srsUE, and there has been already some very interesting findings of potential exploits in the uplink [6].

How do things look like in 5G? Quite different, actually. The first release of the 5G specifications (3GPP Release 15) was published in December 2017, and the first security specifications document was published in March 2018 [7]. However, this time the research community is not waiting to start working and identifying potential protocol vulnerabilities. Despite the lack of open-source implementations of the 5G protocols and tools to facilitate this work, security researchers are not giving any headstart to 3GPP this time. In fact, ever since the publication of the 5G security specifications, these very interesting papers have been published:

• Martin Dehnel-Wild and Cas Cremers: Authentication vulnerability in the most recent 5G AKA draft. [February 2018]
• Roger Piqueras Jover, Vuk Marojevic: Security and Protocol Exploit Analysis of the 5G Specifications. [September 2018]
• Basin, David and Dreier, Jannik and Hirschi, Lucca and Radomirovic, Sa\v{s}a and Sasse, Ralf and Stettler, Vincent: A Formal Analysis of 5G Authentication. [October 2018]
• Adrien Koutsos: The 5G-AKA Authentication Protocol Privacy. [November 2018]
• Mohsin Khan, Philip Ginzboorg, Kimmo Järvinen, Valtteri Niemi: Defeating the Downgrade Attack on Identity Privacy in 5G. [November 2018]
• Ravishankar Borgaonkar, Lucca Hirschi, Shinjo Park, and Altaf Shaik: New Privacy Threat on 3G, 4G, and Upcoming 5G AKA Protocols. [December 2018]
• Cas Cremers, Martin Dehnel-Wild: Component-Based Formal Analysis of 5G-AKA:
  Channel Assumptions and Session Confusion. Network and Distributed Systems Security (NDSS) Symposium 2019. [December 2018]

It is interesting to note that the first paper above was released in February 2018, before the actual 5G security specifications. Those researchers did their work with the drafts that 3GPP often releases before an official specification release is closed. It is pretty clear that this time the research community is ready and prepared to analyze the proposed security specifications of 5G and an insecure protocol will not slip again and end up being deployed in the field (hopefully). Note that, by the time [1] and [2] identified the first known protocol exploits on LTE, LTE networks were widely deployed already and being used by hundreds of millions of people all over the world.

The current 5G specifications are not optimal yet. Despite a technique to tackle IMSI catchers, it is yet to be seen if a rogue base station of malicious application could easily trigger a mobile device to perform one of the few things that would result in a device disclosing its IMSI in the clear (transmit its SUPI not concealed, using 5G jargon). Also, there is yet no clear way in 5G to tackle the challenge of pre-authentication messages, which are the root cause of most protocol exploits in LTE. Moreover, some of the aforementioned papers and research reports have identified potential vulnerabilities in the Authentication and Key Agreement protocol in 5G. And the media is already picking up on these papers and making noise about them.

There is still work to be done and things to polish in 5G security, but this time it will not take years to identify security problems and start fixing them. The research community, academia, industry and standardization bodies will hopefully start working together with the goal of designing a 5G security architecture that will substantially raise the bar with respect to previous generations.

By the way, I recently found out of an actual software implementation of the 5G core based on 3GPP Release 15. This s great news and will fuel so much more research in this field. The two university teams I collaborate with and myself will start using this tool for our research. Looking forward to it.

Ps. By the way, students with a strong background in math, signal processing, communication systems, Python and C++, both academic groups are looking for PhD students and postdocs. Ping me if you are interested!

[1] A. Shaik, R. Borgaonkar, N. Asokan, V. Niemi, and J.-P. Seifert, “Practical attacks against privacy and availability in 4G/LTE mobile communication systems,” in Proceedings of the 23rd Annual Network and Distributed System Security Symposium (NDSS 2016), 2016.

[2] Jover, R.P., 2016. LTE security and protocol exploits. Shmoocon 2016.

[3] Hussain, S.R., Chowdhury, O., Mehnaz, S. and Bertino, E., 2018, February. LTEInspector: A Systematic Approach for Adversarial Testing of 4G LTE. In Symposium on Network and Distributed Systems Security (NDSS) (pp. 18-21).

[4] Shaik, A., Borgaonkar, R., Park, S. and Seifert, J.P., 2018, June. On the Impact of Rogue Base Stations in 4G/LTE Self Organizing Networks. In Proceedings of the 11th ACM Conference on Security & Privacy in Wireless and Mobile Networks (pp. 75-86). ACM.

[5] Rupprecht, D., Kohls, K., Holz, T. and Pöpper, C., Breaking LTE on Layer Two. In Breaking LTE on Layer Two (p. 0). IEEE.

[6] Raza, Muhammad Taqi, Fatima Muhammad Anwar, and Songwu Lu. “Exposing LTE Security Weaknesses at Protocol Inter-Layer, and Inter-Radio Interactions.” In International Conference on Security and Privacy in Communication Systems, pp. 312-338. Springer, Cham, 2017.

[7] 3GPP TS 33.501 V15.0.0 (2018-03).

 

Edited on 12/26/2018: Adding yet more papers and studies finding issues in the 5G security specifications.

Updates on “Security and Protocol Exploit Analysis of the 5G Specifications”

We recently released a pre-print of our paper analyzing the 5G security specifications. The idea of releasing the pre-print while the paper is under submission was to get it out there soon and start collecting feedback in parallel to the actual review. There are a couple of things we want to clarify in the published version. The editorial process for this paper is taking longer than anticipated, so I thought I could make a quick update as sneak peak.

A few folks have pinged us with some questions and really good constructive feedback about the paper. Some questions were related to the main two concepts we will be clarifying in the final version.

1.  The IMSI (SUPI in the context of 5G – I have been working in LTE security for many years and I am too used to saying IMSI, so I might wrongly refer to the IMSI here when I mean SUPI…) will be concealed using the public key of the home network, which does indeed imply that a SIM card only requires to have one single public key stored in order to conceal the SUPI into the SUCI.The SUPI will still be transmitted in the clear if there is no public key for the home network provisioned or in the case of an unauthenticated emergency call. It is not clear yet whether a rogue 5G base station could trick a device to issue such an unauthenticated call. Also, similarly to a recovery from a network outage in LTE, 5G might (should?) support a similar procedure for 5G. It is not clear yet either how the operator will indicate a UE/USIM that it needs to rotate the secret key (maybe it has been compromised, maybe it is time to rotate it… because they plan to rotate them, right???). In that scenario, implicitly, the operator will need to require the UE to authenticate in a manner that will not allow the SUPI to be concealed. To make things more complex, key management and rotation and what to do in these cases is left outside of the specifications.
2. The 5G security specifications never explicitly state that a USIM will require to have a public key for every operator from every country. That is, however, an implicit requirement for the secure implementation of the protocol and to tackle the known LTE exploits (e.g. Attach Reject to DoS the device or downgrade it to GSM). Most of the protocol exploits discovered in LTE exploit one or multiple pre-authentication PHY, RRC or NAS messages before the handshake. An IMSI catcher returns an Attach Reject “I don’t know your TMSI/GUTI, send me your IMSI” message, a DoS-device replies with an AttachReject EMM Cause Code (for example) 0x03 Illegal UE and the device stops trying to connect until the timer T3245 expires (24h to 48h). A sophisticated Stingray replies with AttachReject EMM Cause Code 0x07 EPS Services Not Allowed and downgrades the UE to GSM to Man in the Middle the connection.Note that, in the case of IMSI/SUPI catching, 5G is *not* preventing the pre-authentication message to be exploited. In 5G, when an adversary sends an AttachReject “I don’t know your TMSI/GUTI send me your SUPI”, the UE replies with the SUPI, but this identifier is concealed. So the adversary catches the identifier, tough she/he cannot decrypt it. All the other exploits that leverage pre-authentication messages, and any other one that has not been identified yet, could still potentially be possible in 5G unless pre-authentication messages can be cryptographically authenticated by the UE. If mobile users never roamed to other networks or countries, having the public key of the home network would suffice. But, factoring roaming into the equation, the only way a UE could possibly cryptographically authenticate PHY, RRC and NAS pre-authentication messages is if the UE had a public key for every single operator from every single country. Otherwise, if I am missing a public key from an operator from say, Spain, I just need to set up my rogue 5G base station to broadcast, for example, MCC=214 MNC=07 (for Movistar) and the UE will implicitly trust every single PHY, RRC and NAS message that comes before the NAS authentication process.

   An alternative could be to have NAS messages from roaming UEs always routed back to/from the home operator in the home country. This would likely be an overload nightmare for Diameter networks and the mobile core networks. And, actually, probably this is something that could be exploited as a DDoS attack against mobile operators by having an army of fake software-radio based UEs initiating connections from different locations claiming to be USIM’s from all over the world. There might be other potential solutions to this problem, and I know of a couple research groups in academia doing excellent work to tackle this challenge.

Long story short, IMSI catching trickier in 5G but still not clear if fully prevented, and the requirement for a public key from all operators and countries is not an explicit requirement in the specifications but an implicit requirement if 5G is to tackle protocol exploits leveraging pre-authentication messages.

We will update the document on arXiv soon with these clarifications. Thank you very much again to everyone who has sent us feedback on the paper. We really appreciate it!

Ps. Good game by Barcelona last night despite having Messi out! 😀

EDIT: Just to clarify further. The public key of the home network at the USIM is intended only to conceal the SUPI. We are not trying to imply that this key is intended to apply to pre-authentication PHY/RRC/NAS messages. If this public/private key scheme was to be used to protect pre-authentication messages, though, then there would be an implicit requirement of having public keys for all operators.