What your vendor says about PQC tells you if they are ready

In this interview with Help Net Security, Dr. Yaakov Stein, VP CTO of Allot, discusses what post-quantum readiness looks like inside a mobile network. The discussion covers which operator traffic stays sensitive for years, including subscriber identity mappings, billing records and call metadata, and which becomes worthless within hours.

It walks through the order of work, starting with a crypto inventory and hybrid key exchange on TLS interfaces, then IPsec links. It also names the vendor answers that should raise suspicion and explains why a missed interface is the likely point of failure.

When you sit with a carrier’s security team, how do you help them sort traffic that has a long confidentiality shelf life from traffic that does not? What ends up in the long-life bucket that surprises them?

Traffic shelf-life is one of the terms in Mosca’s equation for PQC readiness urgency, and is thus important to estimate. While most operator control traffic becomes stale very quickly, there are several types of signaled operator metadata that can remain sensitive for years, such as subscriber identity mappings, billing records, and call metadata. Of course, any traffic that may reveal personal or system passwords is high on the list.

Some types of core traffic may reveal internal topology information to potential attackers and exposing some interfaces may impact long-term relationships between operators. Subscriber voice calls, web browsing and streaming are worthless within hours. Subscriber financial transactions such as credit card information remain sensitive for at least several years, their protection is best handled by the subscriber’s browser or app.

A tier-two mobile operator with no post-quantum program calls you on a Monday. Walk me through weeks one through twelve. Just as useful: what do you tell them to deliberately not do yet?

I’m not sure that each task can be confined to single weeks, so I will itemize tasks. The first task is creating a comprehensive inventory of all public-key crypto usage. This includes identifying 5G SBA interfaces, IKE for IPsec-protected links, DNSsec, encrypted APIs, etc.; compiling a comprehensive list will save time and effort later. The 2nd step is migrating everything using TLS (including SBA interfaces, SEPP, web portals and OSS/BSS APIs) to hybrid key exchange; this is the most readily available technology.

This should be followed by similarly migrating IPsec links, including backhaul, inter-DC and LTE roaming interfaces. Next (4th week), all other protocols relying on public keys, including proprietary ones. After all key exchanges are covered, one can start considering authentication of long-lived connections. These can tolerate the overhead of the huge public keys of currently standardized PQC digital signatures. For now, software authentication of short-lived connections can wait. Hardware authentication and attestation mechanisms need to hang on vendors being ready. And operators need not worry about ordinary subscribers, although enterprise and governmental customers may have special needs.

5G subscriber authentication rests largely on symmetric keys, but the PKI around it does not. If an operator can only do one PQC deployment this year, where in the core should it go, and why there?

As I already mentioned, the low-hanging fruit is TLS key exchange. Deploying hybrid ML-KEM (X25519 ECC with ML-KEM, and if possible with crypto-agile backup to HQC) on all TLS-protected SBA and management-plane interfaces is the single easiest and most impactful PQC measure for any operator.

What vendor answer to a PQC question should be treated as a warning sign? I would like the exact sentences that make you suspicious.

Other than “we don’t yet support PQC”, the worst response a vendor can give is “we are waiting for the standards to stabilize”. While it is true that the RFCs are not all yet finalized, PQC is being standardized faster than any major innovation in telecom history. And there crypto-agility is the key to future-proofing, not delaying. The next worse responses are “but cryptographically relevant quantum computers are still not here”, and “our encryption is based on symmetric encryption and so quantum safe”, both of which indicate either lack of understanding or purposeful deception.

What is the most likely way an operator’s migration goes wrong? Not the cryptographic break, the boring operational failure.

This harks back to an issue we emphasized in a previous answer – the preparation of a comprehensive crypto inventory. An operator can upgrade most of its security mechanisms but miss an interface, such as an SSH accessible machine, an old RADIUS interface, a load balancer or NAT, some orchestration tool no-one has touched in years, etc. The operator then gains a false sense of PQC security, but of course PQC readiness is only as safe as the weakest link.

But there is another issue as well. Some of the newer mechanisms can break assumptions of legacy equipment. This is what happened when Kyber was first introduced – its multi-packet TLS client hello broke assumptions of various middleboxes, and it had to be rolled back.

Download: The ultimate guide to network operations management