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.
Dunno if that is still the case though. However, cell phones as secure communication did not use to be the case.
You would probably want to communicate with encrypted data traffic device to device.