Table of Contents
Introduction
Modern telecommunications networks rely on multiple layers of cryptography at every step of a call or data session. Understanding the complexity of the process and the amount of cryptography involved is critical for post-quantum migration planning – an initiative some of my advanced telecommunications clients are kicking off these days. Many are widely underestimating how much cryptography is used. From the moment a user’s device connects to the network, through call setup (or SMS delivery), across roaming interfaces, and into backend billing, dozens (hundreds?) of cryptographic mechanisms are at work.
To illustrate the complexity of preparing for post-quantum cryptography migration, I will try to briefly walk through key steps in a representative telecommunications use case – a 5G voice call with roaming – and identify every instance of cryptography involved. This step-by-step journey illustrates the complexity of securing telecom systems and why identifying quantum-vulnerable spots is such a challenge.
(For an introduction to the quantum threat to 5G see: “The Quantum Computing Threat.“)
1. Subscriber Identity and Authentication
SIM Secrets and AKA Protocol: It all starts with the SIM (or USIM) in your phone, which holds a long-term secret key shared only with your home network’s authentication server. When your phone connects (attaches) to the network, an Authentication and Key Agreement (AKA) handshake takes place. AKA is a cryptographic protocol between the User Equipment (UE) and network to mutually authenticate and derive encryption keys. It relies on the shared secret stored in the SIM and in the home subscriber database (HSS/UDM), making it a symmetric-key system. The network sends a random challenge, and the SIM runs algorithms (often the 3GPP-defined MILENAGE or newer TUAK set, but this is not standardized) to compute a response and a Message Authentication Code (MAC) using the secret key. The home network computes the expected response similarly. If the SIM’s response matches, the subscriber is authenticated. This process also yields initial cipher keys (CK) and integrity keys (IK) for communication (and potentially Anonymity Key (AK)). Importantly, 5G-AKA (and its variant EAP-AKA’) remain symmetric-key based protocols, in contrast to methods like EAP-TLS which use public-key cryptography.
IMSI Privacy – Asymmetric Encryption: One major improvement in 5G is how the subscriber’s permanent ID is handled. In 4G, the device might have to send its IMSI (International Mobile Subscriber Identity) in plaintext on first connect, which could be intercepted. 5G replaces the IMSI with a Subscription Permanent Identifier (SUPI), which the device encrypts into a Subscription Concealed Identifier (SUCI) before sending it over the air. This is done using the home network’s public key (provisioned in the SIM) and a scheme called Elliptic Curve Integrated Encryption Scheme (ECIES). Essentially, the phone generates an ephemeral elliptic-curve key pair and uses the home network’s public key to derive a shared secret (asymmetric key exchange). That secret is then used to encrypt the SUPI with a symmetric cipher (AES-128 in CTR mode) and to compute an HMAC-SHA256 integrity tag. The result is the SUCI, which only the home network (with the corresponding private key) can decrypt, thus concealing the IMSI from eavesdroppers. In our scenario, when the roaming user’s device sends its SUCI to the visited network, it cannot be decoded until it reaches the home operator’s servers. This public-key encryption of the IMSI is one instance of asymmetric cryptography in the attach procedure, and it mitigates IMSI-catcher attacks.
Key Generation and Derivation: Once the identity is confirmed and authentication succeeds, the protocol produces a master session key. From this, a hierarchy of keys is derived for different purposes (using cryptographic Key Derivation Functions that typically employ HMAC with SHA-256). For example, 5G derives keys like KAMF (for Access Management Function) and KgNB (for the gNodeB radio interface) to compartmentalize security. Each key in the chain is used only for a specific scope, which limits the impact of any single key compromise. The derivation uses hashing techniques (HMAC) – another cryptographic element – to ensure one-way isolation between keys. At this stage, we already have seen symmetric cryptography in AKA (shared secrets, MACs) and asymmetric cryptography for IMSI protection, plus cryptographic hashing in KDFs.
Keep in mind, though, that I am simplifying the process a lot. There are multiple interim steps and keys, multiple hand overs to different services, and multiple different implementations even in this first step of authentication.
2. Radio Access Network: Encryption and Integrity
Air Interface Encryption: With authentication complete and keys in place, the UE and the base station (gNodeB in 5G, eNodeB in 4G) set up encrypted communication over the radio link. The freshly derived KgNB (or in LTE, KeNB) is used to generate specific encryption and integrity keys for user-plane and signaling-plane traffic. 3GPP defines various algorithms for radio encryption, known as NEA algorithms in 5G (New Radio Encryption Algorithms, analogous to EEA in LTE). Common choices include 128-bit AES in CTR mode and stream ciphers like SNOW 3G or ZUC. For example, 128-NEA2 is essentially AES-128 in counter mode for confidentiality, and 128-NEA1 is based on SNOW 3G. Likewise, integrity protection uses NIA algorithms (e.g. 128-EIA2/128-NIA2 uses AES in CMAC mode for a message authentication code). These are symmetric-key algorithms – the same keys (derived from the master key) are used by both ends to encrypt and decrypt. At this stage, every voice packet or signaling message over the air is encrypted with a stream cipher and signed with a MAC, preventing eavesdropping or tampering over the radio interface.
It’s worth noting that the encryption and MAC algorithms used in 5G are carried over from the robust 4G designs. AES-CTR and AES-CMAC were introduced in LTE and remain primary options in 5G for their proven security and performance. These symmetric algorithms are considered secure against quantum attacks (apart from requiring longer keys in the distant future), unlike many asymmetric schemes. Nonetheless, they form another layer of cryptography in our call flow – ensuring confidentiality and integrity between the device and the base station.
Example: Suppose our user is now connected and initiates a call setup signaling message. That signaling (NAS message in 5G) is first integrity-protected by the UE computing a MAC with its NAS integrity key, and encrypted if confidentiality is enabled. The gNodeB (and AMF) validate the MAC and decrypt the message using the same shared keys. All of this happens almost instantaneously and invisibly to the user, leveraging symmetric cryptographic primitives.
3. Core Network Communication Security
Backhaul Link Protection: The base station then forwards the authenticated user’s traffic and signaling into the operator’s core network. These links (e.g. the fiber or microwave backhaul from a cell tower to the core) often traverse various networks and thus need protection against interception. IPsec tunnels are commonly used between gNodeBs and core network gateways (such as the 5G AMF or 4G MME). IPsec provides an encrypted tunnel (usually using AES or ChaCha20 for encryption) and integrity protection for all traffic passing through. Setting up an IPsec connection introduces asymmetric cryptography again: the IPsec handshake (IKEv2) typically uses a Diffie–Hellman key exchange or ECDH to establish shared keys, along with device authentication via either digital certificates or pre-shared keys. Many operators deploy X.509 certificates on base stations to authenticate them to the core – these certificates use RSA or ECC signatures and a PKI hierarchy (more asymmetric algorithms). The Diffie–Hellman exchange ensures Perfect Forward Secrecy (PFS), meaning even if someone recorded the encrypted traffic, they couldn’t decrypt it later without the ephemeral DH keys.
In practice, 3GPP has profiled strong security for these interfaces. For example, 5G standards mandate support for the latest TLS 1.3 and strong cipher suites for any TLS/IPsec use, forbidding older weak algorithms. Best practices include encrypting as much as possible and always doing key agreement with ephemeral Diffie–Hellman. So, as our call’s signaling travels from the gNodeB to the core network (AMF, SMF, etc.), it is likely encapsulated in an IPsec ESP tunnel using symmetric encryption (AES) for the actual data and asymmetric crypto (DH and certificates) for the key exchange and authentication of the tunnel endpoints. That’s yet another cryptographic layer in action.
Service-Based Architecture (SBA) Security: Inside the 5G core network, functions communicate with each other over IP networks. 5G’s Service-Based Architecture means that components like the AMF, UDM (subscriber database), SMF (session management), PCF (policy), etc., talk via RESTful APIs (HTTP/2 and JSON). (If you want to brush up on the 5G core service based architecture. I briefly explained it here: “Introduction to 5G Core Service-Based Architecture (SBA) Components.“) These SBI (Service-Based Interface) communications are typically protected by TLS even within the operator’s domain. Each network function may present a certificate (issued by an internal telco CA or other PKI) to authenticate itself, and messages are encrypted in transit. For instance, when the AMF in the visited network needs to query the subscriber’s profile or authenticate data from the home UDM, it will communicate over a secure TLS connection. This again utilizes asymmetric cryptography (TLS handshake with ECDHE key exchange and certificate-based auth) to set up a symmetric encryption channel (often using AES-GCM or ChaCha20 for the bulk encryption). The 5G specs explicitly encourage using standard IETF security protocols – TLS, DTLS, and IPsec – with state-of-the-art algorithms for these purposes.
Even within one operator’s network, one can count multiple cryptographic events here: certificate verification (asymmetric signature check), TLS handshake (asymmetric key exchange), and TLS record encryption (symmetric). The network nodes also rely on hashing – for example, to verify certificate signatures (using SHA-256/384) or to generate and validate OAuth2 tokens for API calls (which might be signed).
4. Roaming and Inter-Operator Security
Our use case involves a roaming scenario: the user is connected to a visited network, which must interface with the home network. Roaming historically was a weak point (in earlier generations, inter-operator links used minimal encryption or trusted private networks like the SS7/Diameter-based IPX). 5G improves this with the Security Edge Protection Proxy (SEPP) at each operator’s border. The visited SEPP and home SEPP set up a mutually authenticated TLS connection (N32 interface) for all control-plane messages. This ensures an eavesdropper on the internet or IPX can’t snoop or alter the Diameter/HTTP messages exchanged (like authentication vectors, policy data, etc.) The SEPPs also perform application-layer security: they can encrypt sensitive parts of messages end-to-end between operators using JSON Web Encryption (JWE) and sign them with JSON Web Signature (JWS). In other words, a piece of data (say, a subscriber’s permanent ID or key material) can be encapsulated in a JOSE object that only the home SEPP can decrypt, adding an extra asymmetric encryption layer on top of the TLS tunnel. The use of JOSE (JSON Object Signing and Encryption) in 5G roaming is explicitly recommended by 3GPP, bringing modern cryptographic frameworks into telecom. JWE typically uses a public-key encryption of a content encryption key and symmetric encryption (like AES) for the payload, so again both asymmetric and symmetric algorithms are employed.
Concretely, when our roaming user attached, the visited network’s SEPP forwarded the SUCI to the home SEPP over TLS. The home network decrypted the SUCI (using its private key as described earlier) and generated an authentication vector. That vector (containing fresh keys and an expected response) is sent back to the visited network – potentially encrypted at the application layer by the home SEPP so that intermediate transit providers can’t see or modify it. Upon receiving it, the visited network’s AMF can trust its integrity (checked via JWS signature) and proceed to complete the AKA with the device. Once the call is in progress, any policy or charging queries between operators (for example, to check subscriber entitlement or to report charging data) go through the SEPPs securely. This roaming exchange adds multiple cryptographic points: TLS (with its certs and ephemeral keys), and message-level encryption/signatures (with public-key cryptography under the hood).
(It’s worth noting that in older 4G roaming, Diameter messages were often sent over unencrypted links or at best IPsec tunnels between networks. This posed security risks. In 5G, the introduction of SEPP aims to make every inter-PLMN message encrypted and authenticated, dramatically increasing the cryptographic complexity but also security.)
5. IMS Signaling and Voice Call Setup
Once the network attachment is done, the user can initiate the voice call itself, which in 4G/5G is handled by the IP Multimedia Subsystem (IMS). The phone’s IMS client (using the ISIM application on the SIM) must register with the IMS network. This involves another challenge/response authentication – essentially an IMS AKA, which uses the same long-term SIM credentials but within a SIP Digest framework. The phone receives a SIP 401 Unauthorized with a challenge and computes a response using a hash (typically SHA-256) of certain strings plus a key derived from the SIM, proving its identity. This is a form of symmetric cryptography + hashing (no new asymmetric keys here, as it piggybacks off the SIM’s secret). If the user is roaming, the visited network’s IMS proxy (P-CSCF) will forward this to the home IMS (S-CSCF), which verifies the response by consulting the home subscriber server (HSS). That communication might occur over a secured Diameter or HTTPS interface – again employing TLS or IPsec between the visited and home IMS networks. So the IMS registration adds another instance of encryption in transit (SIP messages possibly over TLS within or between networks) and cryptographic authentication of the user via AKA.
SIP Signaling Security: Within the IMS core, signaling messages (SIP packets for call setup, ringing, etc.) often traverse internal networks and sometimes between operators for interconnect. These hops are frequently protected by TLS. For example, if a call goes from Operator A’s IMS to Operator B’s IMS (interconnect), they will typically use TLS with mutual authentication between their Session Border Controllers or gateways to secure the SIP signaling. This means exchanging certificates and doing an RSA/ECDSA-based handshake to set up encryption – yet another asymmetric crypto event. Even within one network, IMS nodes may use IPSec tunnels or TLS links to protect signaling, depending on the deployment. Thus, our call’s control plane (the SIP call setup messages) likely sees encryption and integrity via standard internet security protocols. In summary, the IMS layer introduces additional keys and certs: e.g., TLS protecting SIP, IPsec protecting signaling transport, and the use of secure hashes in SIP digest authentication.
Media Encryption (Voice Traffic): Finally, we consider the voice data (RTP) itself. By default, voice packets from the phone are already encrypted over the air (at the radio layer as described). However, once they reach the base station and then the IMS media gateways, standard RTP is often not encrypted within the operator’s controlled network. In some cases (and increasingly as security tightens), Secure RTP (SRTP) is used to encrypt voice packets end-to-end between the phone and the network’s media node (or even to the other party if both support it). SRTP can use protocols like DTLS-SRTP for key negotiation, where the endpoints perform a Datagram TLS handshake to agree on SRTP keys. This introduces, again, public-key cryptography (the DTLS handshake uses certificates or D-H key exchange to establish SRTP encryption keys). 3GPP has begun mandating support for SRTP with strong ciphers (AES-128 GCM) and requiring DTLS key exchange in newer releases. If our scenario assumes a fully secured media path, the phone and network perform a DTLS handshake (using, say, ECDHE for key exchange and an X.509 certificate to authenticate the network’s media gateway). The result is a set of SRTP keys that will encrypt the voice stream with AES-GCM. This is an optional layer (some operators forego SRTP for performance), but it’s increasingly relevant for comprehensive security. In any case, encryption of the voice packets is happening at least on the radio leg, and potentially on the end-to-end leg via SRTP – both using symmetric ciphers (with key exchanges that may use asymmetric cryptography).
6. Billing and Backend Systems
Even after the call itself is set up and secured, there are background systems employing cryptography. For instance, the network will generate Call Detail Records (CDRs) or charging data for the call. These records might be sent from the IMS core or from various network functions to a central billing system or even to the home operator (in a roaming scenario) for settlement. Such transfers often use secure file transfer or API calls. A common approach is to use HTTPS (TLS) for RESTful APIs or secure FTP/SFTP for file batches – both of which provide encryption and integrity (TLS again using asymmetric keys to set up, then symmetric encryption for the transfer). In our roaming call, the visited network could send an interim usage record to the home operator’s billing platform over a VPN or TLS-encrypted connection so that sensitive billing info isn’t exposed or altered in transit. Additionally, some operators digitally sign CDRs or use message authentication codes to ensure that records are tamper-evident and authentic (important for disputes and audits). If digital signatures are used, that’s yet another asymmetric crypto instance (e.g. the billing system may verify RSA signatures on records).
Furthermore, within the operator’s IT systems, database encryption and secure storage come into play. Subscriber data and keys in the HSS/UDM are stored encrypted or hashed where applicable. For example, although the long-term SIM keys must be stored in plaintext form for authentication, other user passwords or identifiers might be stored as cryptographic hashes. Operational interfaces – say, an engineer SSHing into a telecom server – rely on SSH (which uses asymmetric keys for handshaking) or O&M HTTPS links for management. Even time synchronization may use secure protocols (NTP with symmetric keys or certificates). All these are part of the broader telecom environment, though they may not be specific to a single call, they underscore how pervasive cryptography is in every system touching the call. In a single end-to-end use case, literally hundreds of cryptographic operations might be executed across dozens of systems to make the experience secure and seamless.
Additional Cryptographic Layers in 5G Devices and Services
Beyond the encryption directly securing calls, virtually every 5G component – from user devices to base stations and core network functions – relies on multiple layers of cryptography. These layers are built into hardware, firmware, operating systems, and network services to establish trust and security even before any call or data session begins. In other words, a 5G voice call’s security depends on a foundation of other cryptographic protections under the hood. Key additional cryptographic layers include:
- Hardware Secure Modules & Trusted Boot: Many 5G devices contain tamper-resistant hardware modules that store keys and perform cryptographic operations. For example, the SIM/UICC in a phone is a “tamper-proof secure element” that holds the subscriber’s secret keys and authenticates the device to the network. Likewise, network equipment often employs a hardware root of trust (like a TPM or secure enclave) to verify firmware integrity during boot-up. In a secure boot process, each stage of firmware is cryptographically measured and verified by the previous stage, ensuring that only trusted, untampered code is loaded. This hardware-backed chain of trust means that by the time the system is running, its core software (OS, firmware, etc.) has been vetted via digital signatures or hashes.
- OS-Level and Application Security: The operating systems in 5G infrastructure and devices add another layer of cryptography. OS kernels enforce code signing and may encrypt sensitive data at rest. Many 5G phones and network servers use a Trusted Execution Environment or secure element integrated with the OS – isolating cryptographic keys so that even if the main OS is compromised, critical keys remain safe. For instance, a hardened 5G smartphone will store encryption keys and authentication data in a dedicated secure chip, and the Android/Linux OS is modified to utilize this hardware security. Similarly, 5G network functions running in cloud containers use OS-level isolation and encryption (e.g. Linux Unified Key Setup for disk encryption) to protect software and data. In short, the platform software itself is protected by multiple cryptographic mechanisms (secure boot, code signing, encrypted storage, etc.), which aren’t part of a voice call’s encryption but are essential to keep the system trustworthy.
- Mutual Authentication & Secure Channels in the Network: Before any call can be set up, 5G components mutually authenticate each other using cryptography. A user’s device and the core network perform mutual authentication (e.g. the 5G AKA protocol) to verify each other’s identities, using the secret key in the SIM and the operator’s credentials. Similarly, a base station (gNodeB) must authenticate to the core network – often via certificates or pre-shared keys – to prove it’s a legitimate network element. All signaling messages between network elements get integrity protection to prevent tampering (in fact, 5G radio signaling requires integrity checks by design). Within the 5G core’s Service-Based Architecture (SBA), all the service-to-service API traffic is protected with modern cryptographic protocols. Network functions communicate over secure TLS channels with mutual authentication (TLS 1.2/1.3 with certificates). This means even when 5G core services talk to each other (for routing, subscriber data, etc.), those exchanges are encrypted and authenticated – an extra layer of security beneath the user’s call. (Earlier mobile generations often used IPsec tunnels in the backhaul for similar protection, and 5G still allows IPsec where needed.) Again, these mechanisms are not directly encrypting your voice, but a call cannot even be set up or routed securely without them.
- Integrity of Software and Updates: 5G systems also use cryptography to ensure the software running on each element remains legit over time. Software updates, patches, and configuration messages are typically signed with digital signatures, so devices and network nodes will reject any tampered or unauthorized code. For example, a 5G base station will only accept new firmware if it passes a signature check verifying its authenticity and integrity. This protects the network from malicious updates or configuration commands. Even routine management messages may be integrity-protected at the application layer or via the secure channels mentioned above. All of these protections ensure that each component in the call path is running trusted software and hasn’t been compromised.
Example – Layers of Crypto in a Single Device: To illustrate, consider a 5G smartphone (User Equipment). (1) It contains a secure SIM which holds the long-term key and runs authentication algorithms. (2) The phone’s bootloader and OS are validated via cryptographic signatures (secure boot), establishing that the device software is untampered from the hardware up. (3) The phone’s OS uses a hardware-backed keystore or secure enclave to store encryption keys and perform crypto tasks, isolating these from normal apps. (4) When the phone connects to the mobile network, it uses the SIM’s credentials to perform a cryptographic challenge-response with the core network (AKA), mutually authenticating and deriving session keys before any call or data is allowed. (5) The call’s voice/data encryption itself then uses those session keys, protecting the conversation over the air. (6) Meanwhile, if the phone receives an OS update or a carrier settings update, it uses the manufacturer’s public key to verify the update’s digital signature before installing – ensuring the device only runs trusted code. All these cryptographic layers work in concert: even though they aren’t all directly encrypting the voice call, a secure call depends on them. If any layer (say, the secure boot or the network authentication) fails, the call’s security could be undermined or the call might not even be allowed to proceed. Thus, each 5G device or service is bolstered by multiple overlapping crypto layers – a holistic security approach making the overall system far more resilient
Conclusion
As we’ve seen, a “simple” telecom use case like a voice call involves multiple layers of cryptography Just those directly involved in a call might include:
- Symmetric encryption on the radio link (AES or stream ciphers for confidentiality, and MACs for integrity).
- Symmetric cryptography in authentication (AKA algorithms like MILENAGE/TUAK and HMAC-based KDFs).
- Public-key (asymmetric) cryptography protecting subscriber identity (IMSI/SUPI via ECIES in 5G).
- Public-key cryptography establishing secure channels in the core and between operators (TLS/IPsec handshakes with Diffie–Hellman, certificates, RSA/ECC signatures).
- Hash functions and digital signatures ensuring data integrity (from HMACs on messages, to signed tokens or records).
- Optional end-to-end encryption for media and applications (DTLS-SRTP for voice, or the user using their own end-to-end encryption applications over the data connection, etc., which introduce their own cryptosystems like TLS for web, Signal protocol for messaging, and so on).
In total, our one call required the cooperation of numerous cryptographic keys and algorithms – a richness that highlights both security and complexity. For a telecom organization, identifying all these instances is non-trivial; each interface and system might use a different algorithm or standard, often configured at different times by different vendors.
Crucially, many of these cryptographic components rely on classical hardness assumptions that quantum computers could break. Specifically, the asymmetric algorithms are at risk: RSA, Diffie–Hellman, and elliptic-curve schemes (like the ECIES used for IMSI encryption, or ECDHE in TLS) would be easily defeated by a sufficiently powerful quantum computer. Mitigating quantum vulnerabilities means replacing or upgrading or encapsulating every instance of asymmetric cryptography we identified in this use case. That is a massive endeavor: every SIM/USIM would need to support new IMSI encryption methods; every network element’s TLS/IPsec stack must adopt post-quantum key exchange and certificates; inter-operator interfaces must agree on new encryption protocols; even application-layer encryption like SRTP or SSH needs an overhaul.
