You appear to be neglecting the need for symmetric stream ciphers to achieve realtime communications (needed for performance reasons). No matter what you do, you are going to have a symmetric key in there somewhere for adversaries to extract. Once the adversary owns the telco, it is over (i.e., calls can be decrypted), no matter how strong the cryptography is. Your strongest cryptography cannot withstand a key leak.
Do you know how TLS works? The asymmetric keys are used to negotiate temporary symmetric keys, which are used for the actual data. That's exactly what the mentioned Diffie-Hellman algorithm does. Also check out "perfect forward secrecy".
Of course I know how TLS works, as well as PFS. I recommend Kaufman on the subject. The general scheme you refer to is known as hybrid cryptography, and the key material that is derived is used to generate symmetric keys for the TLS session (several keys, in fact, separately for confidentiality and integrity, and for duplex communications). You missed my point completely, though. Unlike TLS sessions, which rely on packets, calls are multiplexed with TDMA or CDMA, for example. Unlike TCP, these channels have realtime requirements that necessitate stream ciphers be employed. I could ask you if you know how telecom works, but that would be childish and demeaning. As ephemeral as you wish to make it, the telco must know the secret key, for imagine if the call is being relayed to Timbuktu and must be passed in plaintext.
> these channels have realtime requirements that necessitate stream ciphers be employed
Even if that were relevant (you can easily convert a block cipher to a stream cipher): It's absolutely possible to do key derivation for a symmetric stream cipher asymmetrically.
> the telco must know the secret key
No, the telco must not know the secret key if they're serious about confidentiality.
The telco must know the secret key at time of use (because telephone networks are non-e2e nowadays and any new design must be interoperable), it's how the key is derived that is at issue here.
If it's derived from symmetric key material, you need to hack the manufacturer, card or telco once, and then it's over. As long as you can observe the over-the-air procedure where the session keys are derived based on the static keys, you can listen in on the entire session.
If it's derived from symmetric keys (both static and ephemeral), then if you are ever discovered and lose access to the operator's network, you can't decrypt any further communications.
Isn't every new mobile standard effectively a complete redesign of the core network anyway?
Sure, it'll take decades to be fully rolled out, but that's true for every large-scale change. The real problem is that it's not in the interest of stakeholders to have end-to-end security.
Judging by this and your other comment, you seem to have made up your mind that the powers that be are not interested in end to end security. You seem to be ignoring (or disregarding without explanation) similar engineering feedback independently provided to you by different people. Good luck to you, sir!
Confidentiality in networking is entirely possible and rolling out such a system would make carriers instantly liable for every phone and internet connection they fail to wiretap.
5G has redesigned several core identifiers to make it harder for middleboxes to MitM/intercept traffic for a specific target. This has led to slowdowns in 5G rollout all over the world, as carriers needed their suppliers to figure out how to wire tap their customers now that they couldn't uniquely identify a customer by a static identifier anymore.
Carriers may have the best intentions for the security and reliability of their customers, but they're legally obligated to deliver plaintext dumps of phone calls on their network somehow. Same goes for other unencrypted side channels such as SMS.
If 6G redesigns the entire network to be fully E2EE, it's essentially illegal to roll out as a carrier. This isn't an engineering problem as much as it is a legal problem.
There are also financial challenges in a secure system. You need to know who to bill for long international three-way calls. That sounds easy, but because of backwards compatibility and many different ways to do roaming, doing billing for mobile phones is an entire industry in itself.
By stakeholders I don't mean the telecom industry, but the governments regulating it. Lawful interception is non-negotiable, and (working) end-to-end encryption would break that, so I predict that we'll never see it on the POTS, VoIP or circuit switched. (And even OTT VoIP is under constant political attack.)
> You seem to be ignoring (or disregarding without explanation) similar engineering feedback
You mean the other "Bellhead" comments explaining why it's technically impossible to do something on the POTS that's been solved in OTT VoIP for years, like real-time end-to-end encryption using block ciphers etc.?
Yeah, I do discount confident statements declaring something technically impossible when I've been happily using such a system for the better part of a decade.
You can "easily" convert a block cipher to a stream cipher on paper (e.g., using OFB or output feedback mode), but you will not get the performance. You clearly have no working knowledge here.
I don't doubt that it's hard in existing systems, which might not have AES hardware instructions, spare processing power available etc., but my point is more that, if it were made a design goal, it would be absolutely feasible.
If we can encrypt basically every HTTP request on the Internet, surely we can encrypt a few phone calls too?
But the main problem is not technical, but that stakeholders don't want to anyway (lawful interception etc.), so presumably nothing will change.
> If we can encrypt basically every HTTP request on the Internet, surely we can encrypt a few phone calls too?
Again, you seem to not understand the performance requirements of real-time audio. The amount of data is tinry, but the latency (and particularly jitter) requirements are on a completelt different level than HTTP.
Given that Signal and WhatsApp manage it just fine even on the slowest Android smartphones made in the past decade (without hardware AES acceleration), I’d say you are vastly overestimating the computational load of symmetric encryption.
The added latency is probably undetectable, and unless the CPU is at capacity, there’s no extra jitter either.
Conversely, you might be vastly overestimating channel capacity. If ALL subscriber calls were on WhatsApp or Signal, the network would grind to a halt.
Besides making no sense (modern networks are already largely VoIP based, so what’s the difference from a capacity point of view): What does that have to do with anything discussed in this thread, i.e. the feasibility of encrypting VoIP calls?
I'm really starting to wonder: Did I unintentionally send some kind of bat signal through time, channeling Bellhead objections to the feasibility of VoIP that have been thoroughly and empirically disproven years ago when the POTS largely switched to NGN and IETF standards, and people around the world have moved on entirely to Internet-based OTT VoIP services?
I was not commenting on VoIP, it works nicely and has for a long time, in the network core too. Mobile carriers do not use VoIP with the MS, to my knowledge. There's "Wi-Fi Calling", but that is the closest you're gonna get to packetized data streams reaching your phone (it sees traction where other reception is bad and the carrier has to rely on the Internet). Your use of "Bellhead" as a derogatory term is noted, and is more reflective on you than anything else. Feel free to have the last word, though.
No, they do, exclusively. LTE and beyond don’t even support circuit switched calls anymore.
Bellhead wasn’t intended in a derogatory way, just as a reference to the “Netheads vs. Bellheads” schools of thinking about networks.
I do have great respect for historical phone systems and the clever engineers making them work. In terms of absolute reliability, I think VoIP was indeed a step back (although I think that’s mainly due to modern engineering and QA practices than inherent limitations).
Exclusively? You make it sound like VoLTE is mandatory. That is not the case, to my knowledge. On a 4G network, for example, one does not always have VoLTE available, and yet one is always able to place voice calls. Since your conviction is palpable, if you could please provide a reference then that would help further the discussion. If not, then no worries, will find the information on my own.
> 4G and Evolved Packet Core (EPC) architectures do not include support for circuit-switched voice and video calls. Two tracks are available that provide interoperable voice services on 4G smartphones: Circuit-Switched Fallback (CSFB) and VoLTE.
Circuit switched fallback means falling back to 3G or 2G (or maybe CDMA) for voice calls; if such networks are no longer available in a given area, VoLTE is indeed mandatory if voice calls are to be supported. (Which is often mandated by regulations, so networks sometimes even block non-VoLTE UEs from attaching.)
Not without redesign. I am telling you that whatever key exchange you run, it will result in key material that is accessible by the telco and therefore by your adversary (e.g., PRC). This is true even if you deployed authenticated Diffie-Hellman between endpoints. You might be able to do secure VoIP on top of that, but you cannot use existing telco infrastructure for your calls without expecting the tower to be able to decrypt the call. The ability of the telco to decrypt the call is the very basis of CALEA and LI, or lawful interception modules, and the reason why Salt Typhoon works.
The point is to limit the damage of a key leak, not eliminate it. Limiting the scope of a compromise to a single connection rather than all communications for the past and future is an improvement.
And yeah, of course we're talking about a redesign. If we were content with the status quo why would we be here?
Sorry about that. Assumed you were trying to piggyback on the existing, to come up with a practical fix. Never entered into my mind that you were suggesting to overhaul the infrastructure. Yes, if you redesigned everything from scratch everything is possible. I will say, however, that getting rid of legacy is often harder than people think.
Yes, but that "somewhere" could very well be only the two phones involved in a call, with key establishment happening via Diffie-Hellman. Doesn't protect against an active attack, but there's no key to leak inside the network.
After seeing STIR/SHAKEN's implementation details (hey what if we used JWT, and then maximized the metadata leakage of who you're calling), I really do not want to trust telecoms to roll their own crypto.
