(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?”).