One thing I absolutely don't understand about telecom security is how, in 2025, we're still using pre-shared keys in our mobile phone standards.
RSA and Diffie Hellman[1] have existed for decades, so have CA systems, yet SIM cards are still provisioned with a pre-shared key that only the card and the operator knows, and all further authentication and encryption is based on that key[2]. If the operator is ever hacked and the keys are stolen, there's nothing you can do.
To make things even worse, those keys have to be sent to the operator by the SIM card manufacturer (often a company based in a different country and hence subject to demands of foreign governments), so there are certainly opportunities to hack these companies and/or steal the keys in transit.
To me, this absolutely feels like a NOBUS vulnerability, if the SIM manufacturers and/or core network equipment vendors are in cahoots with the NSA and let the NSA take those keys, they can potentially listen in on all mobile phone traffic in the world.
[1] I'm aware that those algorithms are not considered best practices any more and that elliptic curves would be a better idea, but better RSA than what we have now.
> "AMERICAN AND BRITISH spies hacked into the internal computer network of the largest manufacturer of SIM cards in the world, stealing encryption keys used to protect the privacy of cellphone communications across the globe, according to top-secret documents provided to The Intercept by National Security Agency whistleblower Edward Snowden."
From what I remember from early 2000’s only the air interface was encrypted. Since anyway they have to provide lawful intercept capability there was not much benefit in providing end to end encryption. It’s not like it was a top of mind feature for consumers.
> BlackBerry got some market share for promoting their encryption.
Consumer-to-consumer BB messages were not E2E encrypted, but if you had a BES connected to your (on-prem?) Exchange server then everything with-in your company was wrapped in a key unique to your organization.
Further, I'm not sure if telcos could read the messages either: the bits were routed through RIM's central servers. For evidence of this, several countries made deals for access to the bit flow under threat of banning the service:
Blackberry's (probably) legally allowed to provide text message encryption, but telcos aren't. "Lawful intercept" (which should more accurately be called "gunpoint eavesdropping") is a legal requirement for all telcos, and the larger the telco, the more optimized and automated the process is required to be. They have to be able to read customer SMSes and tap phone calls. If the SMS happens to be gibberish, that's not their problem, but they can't make it gibberish.
In the late 90s/early 2000's, I would hear voice telephone conversations in central offices quite frequently. (Nobody was spying on purpose, or even paying much attention to what was being said. It was incidental to troubleshooting some problem report.)
This is still the case when troubleshooting POTS lines on analog PBX systems.
All you need is the probe side of a tone generator and you can listen to analog phone conversations in progress with no additional configuration or hardware.
That's done sometimes in central offices, although for analog lines a lineman's handset was the more common tool.
Digital test systems (I don't know what they use now; back then the venerable T-BERD 224 was the standard tool) can decode a single DS0 out of a larger multiplexed circuit and play the audio back and usually allow you to insert audio into a channel. That's normally what was being used to isolate a fault at one or more of the mux/demux/translation points.
Most of my telecom experiences were pretty boring. It largely consisted of handling digital circuits for modem banks, then later setting up a very small CLEC and building small PBX systems out of open source software in the early 2000s, which at the time worked about as well as you might imagine[0]. The outside plant people for the local ILEC had the best war stories:
* Someone tried to carjack a friend while he was suspended in the air in the bucket of a bucket truck, making a repair in a splice case[1].
* Another friend was making a repair in a bad part of town, and while doing some work in junction box (larger, ground-based version of a splice case,) a drug addict hobbled out of a nearby house and asked him if he was with the phone company. When he replied in the affirmative, the drug addict asked him to call 911 as one of his compatriots was ODing.
... etc...
I did get to help another service provider recover from a tornado by physically removing mud and debris from their equipment over the course of a few days and powering it back on. It almost all worked, with a few parts swapped out. I wrote about that one[2].
*Edit* I forgot I have one good CLEC war story. I wrote a test system that ended up calling 911 several times and playing a 1 kilohertz test tone at the 911 operator until they hung up. The test system was meant to troubleshoot an intermittent call quality issue that we were having difficult isolating. It consisted of a machine with a SIP trunk on one side and an analog telephone on the other. It would call itself repeatedly, play the 1k test tone to itself, and look for any audio disturbances, and record a lot of detail about which trunks were in use, etc., when that occurred. That all worked fine. The problem was the telephone number for the SIP trunk, which I remember to this day (20 years later) - 5911988. Every once and a while, when calling the SIP trunk from the analog line (this thing made thousands of calls,) the leading 5 wouldn’t get interpreted correctly, and the switch would just process the subsequent digits… 9, 1, 1 - as soon as that second one was processed, it sent the call to the local PSAP. After a few days a police officer showed up and asked us to please stop whatever it was we were doing.
0 - "not at all"
1 - in the US, anyway, these are the black cylindrical objects you see suspended from cables strung along utility poles
SMS is encrypted in transit between device and tower, but after that it's plaintext. Same with carrier-spec RCS over HTTP (although HTTPS is available, but then it's plain text at the carrier RCS server anyway).
Encryption between tower and device were particularly weak in 2G and 3G days, but since 4G things have been a lot better. 2G's continuing existence remains a security risk, which is why Google Pixels have a toggle to turn it off, and iOS disables it when you enable lockdown mode.
Do not use SMS or non-E2EE RCS for anything you wouldn't shout at a random telecom engineer or passing police officer.
Cell towers (BTSs and eNodeBs) do indeed have unencrypted access to the data passing through them. They're owned by the operator, this is fine.
An attack on SIM card keys would let anybody listen to traffic going over-the-air or impersonate a cell tower. All you need is the keys and some radio equipment to receive the traffic.
Some of these algorithms have to run on the SIM card, and smart cards (at least in the past) don't support RSA or (non-elliptic-curve) DH without a coprocessor that makes them more expensive.
Also, symmetric algorithms are quantum safe :)
But yes, I also wish that in 2025 we'd at least support ECC, which most smart cards should support natively at this point.
> To make things even worse, those keys have to be sent to the operator by the SIM card manufacturer (often a company based in a different country and hence subject to demands of foreign governments), so there are certainly opportunities to hack these companies and/or steal the keys in transit.
If you can't trust your SIM card vendor, you're pretty much out of luck. The attack vector for an asymmetric scheme would look a bit different, but if you can't trust the software running on them, how would you know if they were exfiltrating plaintexts through their choice of randomness for all nondeterministic algorithms?
There's a difference between asking / bribing / blackmailing / legally forcing the company to make a copy of some text files (or just figuring out a way to get those files yourself) versus forcing them to modify their software in deliberately insecure ways (which can also be discovered by others and used against you).
The former is a true NOBUS, the second one is not (though you're right that governments would probably treat this as one).
If you have the ability to distribute keys directly, asymmetric cryptography adds complexity without much payoff. Certainly the idea that introducing RSA to a symmetrical system makes it more sound isn't well supported; the opposite is true.
The "NOBUS vulnerability" thing is especially silly, since the root of trust of all these systems are telecom providers. You don't have to ask if your American telecom provider is "in cahoots" with the US intelligence community; they are.
Who said anything about American telecom providers specifically?
> If you have the ability to distribute keys directly, asymmetric cryptography adds complexity without much payoff.
It's hard for me to believe that a symmetric key, touched by at least three systems (SIM card, operator HSS, SIM manufacturer), the former two of which can't be completely airgapped for obvious reasons, with no ability to rekey, is more secure than a key that is physically unable to leave a single device.
With a TLS-like system, you'd have to somehow hack every single SIM card to get anywhere. Hacking the manufacturer wouldn't help unless you could make them flash custom software that would exfiltrate the keys, and the consequences of an operator hack could be contained by revoking an immediate certificate and generating a new one, presumably from the operator's root cert, sitting somewhere safe in a completely airgapped HSM.
I worked for a major telco in technical support/customer service.
I saw numerous security issues, and when I brought them up, with solutions to improve the service for customers, I was informed the the company would lose money.
Scammers are big customers for telcos, and when they get caught, and banned, they come back again and pay a new connection fee and start the cycle again. Scammers also enable feature upselling, another way to profit from not solving the problem.
Are you suggesting end-to-end encryption? Telecom providers have to implement "lawful intercept" interfaces to comply with the law in many jurisdictions.
I think they're just suggesting improvements on device-to-network encryption. Requiring the sim card secret to live on the sim card and the network means it needs to be transmitted from manufacturing to the network, which increases exposure.
If it were a public/private key pair, and you could generate it on the sim card during manufacturing, the private key would never need to be anywhere but the sim card. Maybe that's infeasible because of seeding, but even if the private key was generated on the manufacturing/programming equipment and stored on the sim card, it wouldn't need to be stored or transmitted and could only be intercepted while the equipment was actively compromised.
This really is the least concern in the entire mess that is phone network security. (Credit and debit card issuers have the same key distribution and derivation problem, but it's ~fine, and there are robust standard solutions, such as deriving per-card keys at the personalization site using tamper-proof HSMs.)
Even if SIM cards were to feature an asymmetric private key: What would you do with it? How would you look it up, and what would you use it for? There is simply no provision for end-to-end encryption in the phone network at the moment.
If there were, it would be a different story, of course, but I doubt that will ever happen.
As part of lawful intercept, they can't encrypt the traffic and then send the NSA the encrypted traffic. They have to send the unencrypted traffic. Or they go to jail.
you've missed the point. if it is e2ee, then there's nothing but noise going down that lawful intercept. the ISP upheld their obligation, yet nosy bitches get nothing.
okay. so let me break it down further. you and i exchange messages via e2ee app. i text you, the app encrypts it, then sends it down the wire. the TLA lawful intercepts that data, but it is just random noise because it is encrypted. your app finally receives the e2ee data, decrypts it, shows you the message.
the data in transit is encrypted beyond anything the ISP has control over, so if the ISP provides lawful intercept they have fulfilled their obligation to the TLA because they let them see the data. it's not the ISP's fault that you and I encrypted the data. this isn't TLS encryption.
if that's not clear enough, then someone else will have to step in as I have taken as far as I can
So let me break it down further. The ISP isn't allowed to sell E2EE apps because it would violate its lawful intercept requirement to not encrypt the data it gives to the government. Your E2EE apps have to come from a different company. That's why SMS isn't E2EE.
Are you seriously just trying to be this obtuse? WTF said anything about the ISP selling anything? You use Signal? You use PGP? Who uses anything from an ISP other than their bandwidth? I've never even heard of an ISP having an app let alone selling it that end users would use. Like it must be painful to think up nonsense like this. It'll be a lot less painful if you just think about it like a normal person using apps instead of whatever it is you have in your head. Damn near troll like
yeah? and? so? who does that? if you're concerned about being intercepted and are still using land lines, then you're really not concerned. we learned that in the 80s. if you're using SMS, you're also not really concerned. friends don't let friends use unencrypted.
I exclusively call landlines from my phone, at least using "actual" phone calls; businesses, to be precise.
For all person-to-person calls, my family and friends have long switched to FaceTime and WhatsApp, which are both encrypted. Why would I pay per minute for a less secure and lower fidelity (HD voice usually does not work internationally) channel?
That said, I really would prefer if the POTS were better secured, given that SSNs and payment card numbers are transmitted over it all the time.
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.
Nortel DMS100 switches are still running code written for Motorola 680x0 CPUs. There is not enough CPU power to validate an RSA key in a timely manner for any control message sent over a T1 or ISDN PRI.
> To me, this absolutely feels like a NOBUS vulnerability, if the SIM manufacturers and/or core network equipment vendors are in cahoots with the NSA and let the NSA take those keys, they can potentially listen in on all mobile phone traffic in the world.
This feels like the obligatory XKCD comic[1] when in reality there isn't any secretive key extraction or cracking...things are just sent unencrypted from deeper into the network to the three-letter-agencies. Telco's are well known to have interconnect rooms with agencies.
Not a requirement, but if for some reason you don't do the Right Thing that the NSA wants, oh dear your CEO goes to jail, he was a bad boy, look at all that insider trading. You'll do the Right Thing next time we ask, capiche?
There are also endless ramblings of some german blogger about how he has been sabotaged at the University of Karlsruhe, regarding very early development of encrypted digital telephony and data-transfer in the 80ies/90ies, by very incompetent and corrupted professors, connected to this.
RSA and Diffie Hellman[1] have existed for decades, so have CA systems, yet SIM cards are still provisioned with a pre-shared key that only the card and the operator knows, and all further authentication and encryption is based on that key[2]. If the operator is ever hacked and the keys are stolen, there's nothing you can do.
To make things even worse, those keys have to be sent to the operator by the SIM card manufacturer (often a company based in a different country and hence subject to demands of foreign governments), so there are certainly opportunities to hack these companies and/or steal the keys in transit.
To me, this absolutely feels like a NOBUS vulnerability, if the SIM manufacturers and/or core network equipment vendors are in cahoots with the NSA and let the NSA take those keys, they can potentially listen in on all mobile phone traffic in the world.
[1] I'm aware that those algorithms are not considered best practices any more and that elliptic curves would be a better idea, but better RSA than what we have now.
[2] https://nickvsnetworking.com/hss-usim-authentication-in-lte-...