Marin Ivezic
NIST published FIPS 203, FIPS 204 and FIPS 205 in August 2024. The replacement algorithms exist, they have names, and they have reference implementations. For a mobile operator, the hard part was never the algorithms; it was compiling the list.
Before anyone can plan a migration, someone has to answer a plain question: where is the cryptography? In a telecom network that question has an unpleasant property. The cryptography isn’t concentrated in a few obvious places. It’s distributed across silicon, radio protocols, IP transport, application-layer message formats, interconnect agreements with other companies, and physical cards in subscribers’ pockets.
So we’ll do the exercise the only way it works. Pick one ordinary event, follow it end to end, and write down every cryptographic mechanism it touches. The event: a subscriber roaming abroad places a voice call. Nothing exotic, nothing hardened, no special customer. This is the walkthrough we use with architects at the start of an inventory engagement, and it usually ends with a longer list than the team expected.
Tracing the call
Stage 1: Proving who the subscriber is
The call starts with an attach. The device has to prove its identity to a network that has never seen it before, on behalf of a home operator in another country.
Inside the SIM sits a long-term secret key, shared with exactly one other place in the world: the home operator’s subscriber database. Authentication runs on that shared secret through AKA, the Authentication and Key Agreement protocol. The network issues a random challenge, the SIM computes a response and a message authentication code, and the home network checks the response against the value it computed independently. Both sides prove possession of the key without transmitting it.
The algorithm set that turns the key and the challenge into a response is an operator choice. 3GPP specifies two example sets, MILENAGE and TUAK, and some operators run proprietary variants instead. That choice is the first inventory line item, and it’s one that scanning tools cannot see.
All of that is symmetric cryptography. The public-key work happens a moment earlier, and it’s easy to miss.
In 4G, a device sometimes had to send its permanent subscriber identity in the clear on first contact. 5G removes that. The permanent identifier, the SUPI, is never transmitted unprotected. Instead the SIM encrypts it into a SUCI, a concealed version, using a public key belonging to the home operator that was written onto the card at provisioning time.
The concealment scheme is ECIES, the Elliptic Curve Integrated Encryption Scheme. It works in three steps. The device generates a fresh elliptic-curve key pair, combines its private half with the home network’s public key to derive a shared secret, and then uses that secret to encrypt the identifier with AES-128 in counter mode and to compute an HMAC-SHA-256 tag over it. TS 33.501 defines two profiles for this, one built on Curve25519 and one on the NIST P-256 curve.
That single mechanism carries most of the migration difficulty in the whole call. The public key doesn’t live in a data center where an operations team can rotate it on a Tuesday. It lives on every SIM in the field. Replacing it means either a SIM refresh cycle or a remote provisioning campaign, and remote provisioning under the GSMA specifications is itself built on elliptic-curve certificates and key agreement. The lead time here is measured in years, and it starts with knowing which profile each card generation uses.
Once authentication succeeds, the shared secret feeds a hierarchy of derived keys, each scoped to one function: one for the core’s security anchor, one for the mobility function, one for the base station. The derivation runs through key derivation functions, which are one-way transformations built on HMAC with SHA-256, so a compromise at one level doesn’t hand an attacker the level above.
Into the inventory: the AKA algorithm set and its per-generation variants, the ECIES profile and curve on each SIM generation, the home network key pair and whatever holds it, the SIM personalization and eSIM provisioning platforms, the KDF chain, and the vendor contracts governing all of it.
Stage 2: The radio link
With keys in place, the device and the base station encrypt the air interface. 3GPP calls the confidentiality algorithms NEA and the integrity algorithms NIA. In practice you’ll find three of each in deployed equipment: one built on SNOW 3G, one on AES, and one on ZUC. The AES variants use counter mode for confidentiality and CMAC for integrity.
All symmetric, all keyed at 128 bits, all derived from the base station key established in Stage 1.
This stage is the calm part of the inventory. Quantum attacks on symmetric ciphers give a much weaker speedup than the attacks on public-key schemes, and 128-bit symmetric keys are not the urgent problem. ETSI SAGE and 3GPP SA3 have work under way on 256-bit air-interface algorithms for future releases, which is a planning input rather than a fire.
The reason to record this stage anyway is that an inventory has to be able to say not urgent, and here is why. A gap in the list reads identically to a risk.
Into the inventory: which NEA and NIA variants each RAN vendor supports, which are enabled in configuration, and whether any cell sites still permit the null algorithm.
Stage 3: Backhaul and the core
Traffic leaves the base station and travels to the core over links that frequently cross infrastructure the operator doesn’t own. Those links are usually protected with IPsec, and the IPsec tunnels are negotiated with IKEv2.
Now we’re back in public-key territory. IKEv2 authenticates the endpoints and performs an ephemeral Diffie-Hellman exchange, most often over elliptic curves. Endpoint authentication typically uses X.509 certificates issued from the operator’s own certificate authority hierarchy, profiled in TS 33.310. Each base station therefore holds a private key and a certificate, and somewhere there’s a CA, a hardware security module, an enrollment protocol and a renewal schedule.
Inside the core, the 5G Service-Based Architecture has network functions talk to each other over HTTP/2 APIs rather than dedicated point-to-point interfaces. Those interfaces are protected with TLS, usually mutually authenticated, so every network function is also a certificate holder. Authorization between functions commonly uses OAuth 2.0 access tokens, and those tokens are signed, which adds another signature verification path and another signing key.
Into the inventory: the CA hierarchy and every issuing CA under it, certificate counts by function and by vendor, key algorithms and sizes, validity periods, the HSMs holding CA keys, the enrollment and renewal automation, the IKEv2 and TLS cipher suite configuration on each element, and the token signing keys.
Certificate validity periods deserve a column of their own. Anything issued today with a multi-year lifetime will still be in service during the migration window, and the renewal schedule is what determines whether a certificate change is a routine operation or a project.
Stage 4: Crossing the operator border
The subscriber is roaming, so the visited network has to talk to the home network. In 5G that conversation goes through a Security Edge Protection Proxy, a SEPP, sitting at each operator’s edge.
Two SEPPs establish a mutually authenticated TLS session over the N32 interface. Where the two operators exchange traffic through an intermediary rather than directly, they can use PRINS, the protocol for N32 interconnect security, which applies protection at the message level rather than to the pipe. Sensitive fields inside each message get wrapped as JSON Web Encryption objects, so an intermediary can perform the routing and mediation it’s contracted to do without reading the authentication vectors passing through it.
This is where our roaming user’s SUCI travels. The visited network cannot decode it. It forwards the concealed identifier to the home network, the home network decrypts it with its private key, generates an authentication vector, and returns it under the protection just described. Only then can the visited network complete the AKA exchange with the device.
Stage 4 has a property none of the others share. You cannot change it alone. The cipher suites, the certificate trust, the PRINS policy and the field-level protection rules are all bilateral, negotiated with every roaming partner, and often mediated by an interconnect provider. Our experience is that this is the single most underestimated dependency in a telecom PQC plan. The technical work is modest and the coordination work is not.
Into the inventory: SEPP deployments and vendors, the roaming partner list, the certificate trust arrangements with each partner, PRINS policies, the interconnect providers in the path, and the contract clauses that govern algorithm changes.
Stage 5: IMS registration and call setup
Voice calls run over the IP Multimedia Subsystem. Before the call, the device registers with IMS, and that registration carries its own authentication exchange, specified in TS 33.203, reusing the SIM’s credentials through a challenge-response inside SIP signaling. Between the device and the P-CSCF, the proxy that fronts IMS for the subscriber, the signaling is typically protected by IPsec security associations negotiated during registration.
Then the SIP signaling itself moves through the network. Between IMS nodes, and especially across an interconnect to another operator’s session border controller, SIP runs over TLS with certificate-based mutual authentication. Each of those is another certificate, another trust store, another cipher suite configuration, and frequently another vendor.
Into the inventory: the IMS authentication scheme and its hash profile, the IPsec configuration between device and P-CSCF, SBC certificates and trust stores, and the SIP interconnect security terms with each peer.
Stage 6: The voice itself
The media stream is protected on the radio leg by Stage 2. Beyond the base station, protection depends on deployment choices.
Where media security is applied, it uses SRTP, the secure profile of the real-time transport protocol, typically with AES in counter mode authenticated by HMAC-SHA-1, the AES_CM_128_HMAC_SHA1 suite. AES-GCM is supported in newer profiles and appears in some deployments. The keys get established either through DTLS-SRTP, a datagram TLS handshake between the endpoints, or through SDES, which carries the keys inside the signaling messages. Those two options have very different inventory consequences. DTLS-SRTP introduces its own certificates and its own key exchange. SDES introduces none, and instead makes the confidentiality of the media entirely dependent on the TLS protecting the signaling path in Stage 5.
Into the inventory: whether media protection is enabled at all, on which segments, with which keying method, and what the media gateways support.
Stage 7: Everything holding it up
The call is now connected, and cryptography that never touched a voice packet has been working the whole time.
Charging records, the CDRs that turn the call into a line on a bill and into a settlement claim against the home operator, are transferred over TLS APIs or SFTP, and are sometimes signed so that a disputed record can be shown to be unaltered. Management access to network elements runs over SSH with its own key pairs. Firmware and software updates are accepted only if their digital signatures verify, which means every element trusts a vendor signing key that the operator does not control. Base stations and virtualized functions verify their own boot chain against a hardware root of trust. Container images in a cloud-native core are signed. Timing distribution to the RAN may be authenticated.
All of this protects the platform rather than the call itself. It decides whether the elements carrying the conversation are running the software their operator believes they are.
Into the inventory: CDR transport and signing, O&M access keys, vendor code-signing trust anchors, secure boot chains, image signing, and timing authentication.
Sorting the list
One call, seven stages, and the resulting list falls into three groups with very different urgency.
Symmetric and hash-based mechanisms. The air-interface ciphers, the AKA algorithm sets, the KDFs, the HMACs, the bulk encryption inside TLS and IPsec. Record them, note key sizes, track the 256-bit standardization work, and move on.
Public-key cryptography in live sessions. The IKEv2 and TLS key exchanges, and the certificates authenticating them. This is where hybrid key exchange goes first, combining a classical exchange with ML-KEM from FIPS 203, and where crypto-agility in the element configuration pays for itself. The blocker here is rarely the operator. It’s whether each vendor’s stack supports the new suites, which makes vendor roadmaps the binding constraint on schedule.
Public-key cryptography embedded in long-lived artifacts. The ECIES public key on every SIM, the code-signing trust anchors in deployed hardware, the certificates with multi-year validity, the roaming trust arrangements. These have lead times that no amount of engineering urgency compresses, and they’re the reason inventory cannot wait for a deployment plan.
One exposure spans two groups. Harvest-now-decrypt-later means traffic captured today is stored against a future capability to decrypt it, and it reaches any session whose keys were established through a classical public-key exchange: the IKEv2 and TLS handshakes in Stages 3 and 5, the DTLS-SRTP handshake wherever media keying uses it, the signaling that carries SDES keys, and the concealed subscriber identifiers from Stage 1. The air-interface ciphers are symmetric and are not subject to it. The SUCI case is the one with the longest lead time, because the recorded value is a permanent identity and the key protecting it sits on a card in a subscriber’s pocket.
What this does to your inventory method
Walk the seven stages back and ask which of them an automated discovery tool would have found.
Network scanning finds TLS endpoints and reports their cipher suites, which covers part of Stage 3 and part of Stage 5. Source code scanning finds cryptographic calls in software the operator wrote, which in most networks is a small fraction of the total. Neither one finds the ECIES profile burned into a SIM generation, the AKA variant a vendor implemented in 2016, the field-level protection policy in a roaming agreement, or the code-signing key a vendor holds in another jurisdiction.
So the inventory is three activities, not one. Automated discovery for what can be scanned. Configuration extraction from network elements for what’s set but not visible on the wire. And structured questioning of vendors, roaming partners and the SIM supply chain for everything else, with the answers written down against contract terms.
The output is a cryptographic bill of materials, a CBOM: a structured record of every cryptographic asset, its algorithm and parameters, the system that uses it, the party who controls it, and the lifecycle constraint on changing it. That last column is what turns a list into a plan. An ECIES key on a SIM and an ECDHE suite in a core network function are the same algorithm family and completely different projects.
Our observation from working through this exercise with operator teams: the walkthrough usually adds more line items than the discovery tooling did, and the additions cluster in Stages 1, 4 and 7. Identity, interconnect, and the platform underneath.
Where to take this next
If you’re scoping a post-quantum program for a mobile network, run this walkthrough against your own topology before you commit to a timeline. Substitute your generations of SIM, your RAN vendors, your core release and your roaming partner list. The stages don’t change. The line items do.
Quantum Academy’s telecom and migration-planning material takes this method further, from the walkthrough into a working CBOM and a sequenced migration plan, with exercises built on operator network topologies rather than generic enterprise IT. You can see the current programs and enroll at quantumacademy.com/.
For the migration methodology this sits inside, including inventory templates and phase structure, see pqcframework.org. For deeper technical background on the underlying cryptography and the quantum threat model, PostQuantum.com carries the long-form analysis.