Eavesdropping on SMS Messages inside Telco Networks

Fireeye reports on a Chinese-sponsored espionage effort to eavesdrop on text messages:

FireEye Mandiant recently discovered a new malware family used by APT41 (a Chinese APT group) that is designed to monitor and save SMS traffic from specific phone numbers, IMSI numbers and keywords for subsequent theft. Named MESSAGETAP, the tool was deployed by APT41 in a telecommunications network provider in support of Chinese espionage efforts. APT41's operations have included state-sponsored cyber espionage missions as well as financially-motivated intrusions. These operations have spanned from as early as 2012 to the present day. For an overview of APT41, see our August 2019 blog post or our full published report.

Yet another example that demonstrates why end-to-end message encryption is so important.

Posted on November 7, 2019 at 6:05 AM • 47 Comments

Comments

meNovember 7, 2019 7:10 AM

i have created an iot device to remotely control my heating system and i have signed&encrypted my sms (using fernet).
i now see a strange behavior: there are ghost sms appearing.
the program is designed to check for new sms, decrypt, do something, save to disk and delete.
the problem is that sometimes it report "new" incoming sms that are in fact not new. luckily i designed my sistem to prevent replay attacks.
i just don't get if thes "ghost" sms are really sent from the mobile phone operator or it's a bug in the sim or 3g router.

has anyone ever experienced deleted sms reappearing?
if you try to read a deleted sms most of the time the modem (using at commands) returns "erorr" because there is no sms.
but sometimes it returns the deleted sms.

AlejandroNovember 7, 2019 7:33 AM

iPhones convert voice to text as a feature, although it does it quite badly, very often.

I always figured that was so various governments can collect our voicemails as text for future reference and analysis without having to go back and actually listen to the call (voice, too slow).

In other words, just because the PRC is doing something sketchy, don't assume others are not.

meNovember 7, 2019 7:39 AM

@Alejandro
> governments can collect our voice as text

maybe off topic but yes, i know a person who used sdr to record the teacher microphone and plugged the audio to google translator so there was realtime speech-to-text recorded and translated.
it was more like a joke "lazy way to take notes while at lesson" but it's definitely possible.
One general rule is: if it's technically possible, probably someone is doing it.

Jim Van ZandtNovember 7, 2019 7:40 AM

I have often received several copies of a text, spread over a minute or two. These are usually from a different sender (across the country). I figured there was a sketchy connection on one end of the other.

DavidNovember 7, 2019 7:51 AM

Western Governments have been doing speech to text on international calls for at least 35 years, so I presume that it has got universal these days.
Long term recording of all voice calls has become realistic in the last few years, even as speech

Clive RobinsonNovember 7, 2019 7:57 AM

@ me,

i just don't get if thes "ghost" sms are really sent from the mobile phone operator or

SMS /texts are a "secondary service" with know guarenty of delivery. The network makes "best effort" which means you don't get some and you do get others duplicated. They tend to "over send" as it causes least problems for Customer Services.

From Telco IndustryNovember 7, 2019 8:31 AM

Mr Schneier,

Yet another example that demonstrates why end-to-end message encryption is so important."

And how you suggest to do it so that even old "dumb" mobile
phones can do it? Clearly you can't use symmetric encryption, distributing keys is logistic nightmare. For asymmetric encryption you need the whole supporting infrastructure, not to mention that you can't add or change software to old "dumb" mobile phones.

Please instead of preaching what is important show _easy_ bulletproof solution and we all implement it.

Thank you.

meNovember 7, 2019 8:31 AM

@Clive Robinson, @Jim Van Zandt
happy to hear, makes sense also because the sim is in roaming also if everything is in the same country (low cost sim designed to be used in iot).
Initially i thought that i have "burned" the sim eeprom by doing too many reads (about 10000), as initially it operated in polling mode by querying for messages.
Although in my case there is a copy immediatly after send, one maybe after 3 minutes, another after half hour and they generally stop after two hours.

meNovember 7, 2019 8:34 AM

@From Telco Industry
to have widespread use it might be difficult, but if we consider that 90% of our communications is between few friends /family member that we know well symmectric encryption is not a bad idea.
Opportunistic encryption might be a good idea too.
whatsapp and signal both encrypt end to end, and optionally you can verify the fingerprint in person.

Clive RobinsonNovember 7, 2019 9:46 AM

@ Bruce, ALL,

Yet another example that demonstrates why end-to-end message encryption is so important.

Yes it is, one caveat though,

    Be sure your end points are secure

Otherwise it will be all for nothing, those desiring access to plaintext will simply move from being effectively hidden in the network to visable on the insecure end point devices.

We realy need secure endpoints --which we don't have-- befor we start to rely on end to end encryption.

Yeah I know I keep saying it, but it is very important, if we are not going to end up in an endless game of whack-a-Mole.

@ From Telco Industry,

Please instead of preaching what is important show _easy_ bulletproof solution and we all implement it.

There are currently no "bulletproof solutions" easy or otherwise.

And the fault for that is the "Telco Industry" not supplying secure base infrastructure or secure end point devices.

So if --as I have done-- you've worked in the industry for while at both the design and standards you might want to explain to every one here what the "Telco Industry" is going to do to supply the very badly needed secure base systems on which it would be possible to do your desired "_easy_ bulletproof solution". Because untill the Telco Industry pulls it's socks up you won't get what you want...

Which kind of puts you in the,

    Physician heal thy self

Position.

From Telco IndustryNovember 7, 2019 10:33 AM

Mr Clive Robinson

Don't blame Telco industry.
End users want smartphones where you can install new apps.
From the instance you can install new app to the phone it
becomes untrustable.

Govt wants lawful interception. You can't say no to govt.
So don't blame Telco industry. And we know all that end-to-end
encryption is hard, very hard to implement. Let's first Gurus
like Mr Schneider shows the way and then industry follows.

what aboutNovember 7, 2019 10:43 AM

What about a secure 3rd and 4th device? Does it make sense to use your mobile phone as a tether to another device? So let's say I have device A and B which are mobile phones and device C and D which are notebooks running OpenBSD.

My Friend {------------------} ME
C {--} B {---------------------} A {--} D


C and D are secure devices designed for encrypted End2End communication. The mobile phones just revert back to a carrier device.

Now the argument could be made that this is cumbersome and unwieldy, but security is never perfect and always imposes some inconvenience to be effective. With this known does it satisfy the starting point of a secure system?

Does it also have the side benefit of increasing the portability of the system to different carriers?

Does it duplicate or emulate existing known secure design instead of recreating the existing problem?

WaelNovember 7, 2019 11:35 AM

@what about,

Does it duplicate or emulate existing known secure design instead of recreating the existing problem?

I believe it does.

SpaceLifeFormNovember 7, 2019 2:02 PM

@what about

You are thinking along the right path.

But, you have not locked down devices C and D from potentionally leaking.

What if there are hidden radios in devices C and/or D?

You need to Faraday Cage them.

AndersNovember 7, 2019 2:22 PM

@what about

You can't have full control over the phones and phone
company infrastructure. They have remote access to your phones
and can install there anything they want over the air (OTA),
including MITM proxy.

SpaceLifeFormNovember 7, 2019 2:22 PM

@ From Telco Industry

When SS7 is secure, then come back and whine about the lack of solutions.

Hint: It will never be secure. BY DESIGN.

Of course, you know that.

From Telco IndustryNovember 7, 2019 2:29 PM

Mr SpaceLifeForm

You are barking under the wrong tree here.

First go and demand that government stops demanding
lawful interception interfaces.


Can you do that? Are you up to that?

FANovember 7, 2019 2:59 PM

@From Telco Industry

C.R. wrote

> There are currently no "bulletproof solutions" easy or otherwise.
> And the fault for that is the "Telco Industry" not supplying secure base
> infrastructure or secure end point devices.

Very true, but it's not only the 'telco industry' who is to blame. There are at
least three parties involved:

1. Regulatory bodies (i.e. governments),
2. The equipment providers (Google, Apple, smartphone and PC manufacturers),
3. The 'telco industry'.

None of these three want the general population to have secure, private communications, each of them for their own reasons. For 1. it's power and control, for 2. and 3. it's simply greed.

If all three of them would agree to allow secure and private communication,
then there could be the 'easy' and convenient solution that you are dreaming of.

As it is, whatever solution will not be 'easy' nor convenient.

Which doesn't mean there is no solution. There is, and it has been stated here many times: separate the security endpoint (i.e. the encryption) from the untrusted communication system. That is actually what 'professional' users of secure communication have been doing for as long as we have had electronic communication. It requires organisation and discipline. If that is asking too much, then just forget about it. That means it's not for everyone, but certainly not beyond the means of some 'bad guys'. Which in turn means that all the effort to control secure communication is probably sort of futile as it will only frustrate the amateurs.

Clive RobinsonNovember 7, 2019 3:20 PM

@ From Telco Industry,

Don't blame Telco industry.

Why not?

You by your handle claim to represent the Telco Industry.

And your first action is to blaim someone who whilst a public figure, who has effectivelly no control over the Telco Industry.

Thus you were pulling the old "externalise the problem" trick which Big Corp's do all the time, to avoid responsability...

So "over to you"...

From Telco IndustryNovember 7, 2019 3:53 PM

Mr FA

Why are you accusing telco industry against greed
and are equaling that lack of interests in security?

Believe me, we just want to sell the bandwidth and don't want to care what customers do there, what encryption they use or don't use. But we can't. There's kiddy porn, there's botnets, there copyrighted stuff, terrorists etc. At least so they tell us. Government makes the rules and we must obey. OBEY. Period.

While governments call the shots, you can't have end to end encryption.

From Telco IndustryNovember 7, 2019 4:01 PM

Mr Clive Robinson

Your public figure calls himself as a public-interest technologist.
End-to-end encryption is in public interest.
So let he first stops government regulations against telcos,
mandatory record collection, lawful interception etc and then we have all end-to-end encryption, for everyone.

But just a talk that end-to-end encryption is important...naah.

lurkerNovember 7, 2019 4:20 PM

Kudos for the sass of these guys, using the url of the SMS Standards document as the key for decoding their nastiness...

Sancho_PNovember 7, 2019 4:53 PM

@what about

”C and D are secure devices designed for encrypted End2End communication.”
(my emph).
This reads like a sound definition, but is a failure.
The mobile phones don’t “just revert back” (?) but also can infect C and D.

Is a laptop, regardless of the OS, known to be secure?
Is OpenBSD known to be secure?
Is a laptop, running OpenBSD, known to be secure?
Is the SW (all your SW) you’ll install on the laptop known to be secure?

And don’t forget:
https://cyber.bgu.ac.il/how-leak-sensitive-data-isolated-computer-air-gap-near-mobile-phone-airhopper/

Sancho_PNovember 7, 2019 5:00 PM

re “@Telco industry” [1]

I don’t think the telcos want us to be insecure / to have access to content.
They have the metadata, this is much more of value as the content.
Metadata is the truth, content is nada.

My “problem” is: Access to read content also means access to write content.
- My content!

[1]
To attack @Bruce likely isn’t fair, because he indeed openly rebuffs gov’s appetite, although I’m not sure about his point re lawful interception details.

SpaceLifeFormNovember 7, 2019 5:48 PM

@ From Telco Industry

Sincerely, I understand your predicament, but those of us outside Mainland China can not solve your Government problems.

Especially in Shenzhen.

The only solution possible would have to require that the Great Firewall would not block random ip addresses.

It then becomes whack-a-mole.

And, then, it could lead to complete balkanisation.

I do not believe that is what you want.


SpaceLifeFormNovember 7, 2019 6:30 PM

Happy Valentines Day SS7

https[:]//www.cnn.com/2019/11/07/tech/text-messages-delayed-valentines-day/index.html

"The text messages appear to have originally been sent on February 14, Valentine's Day, but were received more than eight months later with Wednesday's time stamp."

[timestamp being 2019-11-06, not 2019-02-14]

Me thinks, some MESSAGETAP cleanup in progress.

Expect more next few hours or days.

NotARCSFanNovember 7, 2019 6:34 PM

And let's not forget about the new SMS, called RCS, that it does not provide end-to-end message encryption. Google is pushing telcos to agreed on this. But they always dodge the question about end-to-end message encryption because otherwise, telcos will not adopt it.

Petre Peter November 7, 2019 6:52 PM

Yes to end-to-end encryption, no to giving police the equivalent of a house key copy.

Clive RobinsonNovember 7, 2019 8:31 PM

@ FA,

There are at least three parties involved:

Actually there is a fourth which is the NSA, but probably not in the way you might be tempted to think.

It's all to do with the basic algorithm used to digitize speach.

The NSA invented the Code Excited Linear Prediction (CELP) algorithm for speech coding, as a follow on from work that started in WWII. A modified form of CELP is the basis of most of the algorithm used in many digital cellular systems.

As algorithms go, CELP is fairly good at what it does, but it's important to remember that,

1, It's not "loss less".
2, It only works with "continuous" not discontinuous wave forms.

Both of which mean that it works very badly with audio that has been digitized, and then made,anything but continuous by the encryption process and turned back it into an audio waveform.

...

Clive RobinsonNovember 8, 2019 4:15 AM

@ What About,

You show two diagrams,

My Friend{--------------}ME

C{--}B{------------------}A{--}D

Have you thought about amalgamating them like so?

C{-}MF{-}B{---------}A{-}ME{-}D

A,B = Insecure mobile phones.
MF = First communicating party
ME = Second communicating party
C,D = Secure End points

That is you put you and your friend in the "communications path to act as "gap crossing" monitors?

I suggested this back last century when doing bank transaction authentication. Back then the banks only authenticated the communications chsnnel not the actuall transaction, which with the likes of what we now call MITM and Fallback attacks would put a third party into any actuall transactions. Further back in summer 2000 at a presentation I gave at Uppsala University I pointed out that "the human needed to be in the security chain" between the electronic communications end point (A/B) and the "tokens" (C/D) that authenticated the transactions. At the time when asked a question about securing things I remarked "The day Microsoft require a five pin DIN connector in my head, is the day I retire from society", which sadly more people remembered than the question that gave rise to it.

The question in essence was about the "reliability of humans" that is their ability to see a long string of hex or Base64 alpha charecters on a display and acurately type them in again on the keypad of either the communications end point (AB) or security end point "token" devices (CD) depending on which way traffic was going (MF-ME / ME-MF). But importantly the users tolerance to do so (ie the "How long befor they throw the token device through a window out of frustration?" test).

After a number of experiments I decided that the processing work load differential between humans and computers needed a little balancing to reduce the ability of malware in the comms point devices to break the authentication. So I looked around for something that was "easy for humans but hard for computers" and I suggested the use of captchas[1], but... did not know --much to my embarrassment-- that malware developers had solved the "captchers processing problem" by paying people in china a few cents per translation... So that idea blew up in my face, long before people have developed optical reader software capable of doing it as least as well as humans and better than many. It's why we now have the "nine photograph array" where you have to click on the images without cats/cars/etc. Something that was discussed on this blog by myself and others as a replacment for passwords. Though these days I ask myself just how long it will be before such systems will without doubt fall to an AI algorithm in the not to distant future...

Which is why if you are a regular blog reader you might have noticed that more recently I have abstracted the idea of the token devices C,D to something that has been well understood for a little over a century now. That is as a secure paper and pencil "hand cipher" such as a One Time Pad.

It works as an analog of token devices so that people can get their heads easily around the information based security issues.

Because it conveniently gets away from TEMPEST / EmSec issues, which can cause "conflation complexity" issues in peoples thinking.

However that said, with "Active EmSec" techniques writing with your hand has to be considered as nolonger secure, unless you sit inside the "RF Cage" with your OTP. That is "through the wall passive or active radar" techniques are evolving to the point where a computer can analyse the movment of hand and pencil sufficiently well to make out what you write in "block capitals" etc (which is what most people do when using codes/cipher pads).

The point is if you have become a "person of interest" such as a crime boss or drug cartel overlord, or just a whistleblower friendly journalist, then ensuring not just your message contents remain private, but also who you are communicating with likewise remains private is getting well-nigh impossible without the same level of protective features Diplomatic / Millitary ComCen's have which is dedicated "Crypto-Cells" actually within Sensitive Compartmentalised Information Fascilities (SCIFs)[2].

So whilst I can tell you how to make your message contents private, the real question becomes

    Is the average person going to do what is required?

To which I suspect most know the answer,

    Not untill after it is too late, due to "collect it all" already being in place.

Then of course there is the next issue of keeping who is talking to who private. This is sometimrs called "Anti-Traffic-Analysis". For years people have talked about using Tor. Well Tor has failings the biggest one being under the normal usage model neither party is actually in the Tor network. A partial solution to this is to run your own Tor node to another person also running a Tor node. The problem is that the nodes being on the Internet are vulnerable to being attacked by the usual array of vulnerabilities from old Zero-Days that have not been patched / fixed, through current Zero-Days and more topical faults in CPU's and other Hardware such ad Meltdown, RowHammer etc that the device manufacturers have decided not to fix. Then of course there are the so called "Ring -3" built in's like the Intel Managment Engine and hidden issues they might bring up such as being able to "disable the on chip RNG".

The recent embarrassment with the 0xffffff...ff generating RNG has been publically described as a failing in CPU "microcode" which in modern CPU chips can be "updated, over the wire".

It beggs the question of if it's actually revealed by accident a mechanism under the control of a Managment Engine to "down grade" an on chip RNG. Downgrading RNGs has certainly been a subject of interest to me since the 1980's when I first started designing RNGs, and why I've always recommended against using on chip RNGs especially as Intel insist on making them impossible to test by the user, by hiding them behind "magic pixie dust" hash and other crypto algorithms.

Getting and maintaining "privacy" on electronic communications is in effect impossible for the average user, because even if they are ultra carefull and follow OpSec procedures, fully, that does not say the second party they are communicating with is doing so.

Thus you have to realy consider not "privacy systems" but "debiability systems" that the plaintext withstands all scrutiny by a third party.

I've described such a system in outline in the past on this blog, but it still has the underlying issues of "KeyMat" that need to be sorted out before it's ready for "prime time" usage.

[1] https://en.wikipedia.org/wiki/CAPTCHA

[2] https://en.wikipedia.org/wiki/Sensitive_Compartmented_Information_Facility

Stefan ClaasNovember 8, 2019 6:54 AM

Actually, if you use secure old school methods like the Diana Cryptosystem (developed by the NSA for the Green Berets in Vietnam) and handle the pads properly, with people you know personally, you have a secure SMS solution, which works with old dump phones.

It remains to be seen however if people are willing to carry paper pads, a pencil and a notebook with them ...

FANovember 8, 2019 1:33 PM

@Clive Robinson

> It's all to do with the basic algorithm used to digitize speach.

* CELP is one of the many variations on Linear Predictive Coding (LPC). As far as I know the NSA was not involved in 'inventing' it.

* Anyway this is _source coding_ and its only purpose is to reduce the required bit rate. It has nothing at all to do with security. So how is this related to the matter discussed here ?

A Nonny BunnyNovember 8, 2019 3:01 PM

@Clive Robinson

Yes it is, one caveat though,
Be sure your end points are secure

Otherwise it will be all for nothing, those desiring access to plaintext will simply move from being effectively hidden in the network to visible on the insecure end point devices.
Aren't there more people on the network than on the endpoint, though? So isn't it an improvement?


e.g. I'm pretty sure using https makes banking over the internet safer than using http, even though either end point might be compromised. Because it's far easier to compromise the network.

Clive RobinsonNovember 8, 2019 6:09 PM

@ FA,

As far as I know the NSA was not involved in 'inventing' it.

https://www.nsa.gov/Portals/70/documents/news-features/declassified-documents/cryptologic-quarterly/history_of_secure_voice_coding.pdf


this is _source coding_ and its only purpose is to reduce the required bit rate. It has nothing at all to do with security.

It has a lot to do with security.

As I said above,

    Both of which mean that it works very badly with audio that has been digitized, and then made,anything but continuous by the encryption process and turned back it into an audio waveform.

The reason Linear Predictive Coding works is that the human voice contains not just a great deal of redundancy, it is also very very predictable as well.

If you encode the human voice with linear predictive coding you in effect extract the essence of the voice signal from the much larger redundancy. So the decoder can use successive values to rebuild the audio signal because of it's linearity and predictability.

The problem with encoding the human voice then encrypting the resulting digital signal is that what you send is by definition neither linear or predictable. Thus turning it back into an audio signal is somewhat fraught with difficulties (something JackPair found out the hard way).

If the channel you send the resulting audio --derived from the encrypted data-- down, is of the POTS simple audio bandwidth in the 300Hz to 3500Hz it will effectively get to the other end, where it can be digitized decrypted and turned back into understandable audio.

But if instead you try to send it through another linear predictive coder/decoder like the GSM or other celular network, as the encrypted signal is neither linear, nor predictable the resulting recovered digital data is unlikely to be the same thus decrypting it will not give back the original audio...

To get a secure voice encryption system to work across GSM etc you need to do things in a much different way. There are two basic options,

1, Use a lower bit rate and armour the resulting digital data so it appears to be more linear and predictable.

2, Use a very non standard encryption method that somehow retains linearity and predictability.

As far as I'm aware there is no encryption method in the public knowledge base that achieves the objectives of 2 above and also remains sufficiently secure. Which means you have to consider option 1 above as the solution.

Thus you have to trade bit rate for having a secure conversation.

There are other voice encoding systems that are less dependent on numerous samples being predictable and linear and these are easier to send encrypted voice traffic down.

Quite a few years ago I was involved with trying to develop a system to send ordinary modem signals across the old style analog celular systems. After extensive testing there were numerous issues that needed to be resolved not least of which were channel dropouts to allow inband signalling to be used. Whilst the drop outs were mostly imperceptible to humans they played havoc with the use of analog data signalling.

The result is that whilst you can send modem data across a GSM network, not doing so is easier to accomplish. That is use the data streams instead, but that means you can not use the ordinary POTS phones.

Thus the NSA by releasing CLEP on the world has made sending encrypted voice difficult to near inpossible for most people to design a universal voice encryption system. Which is very much in the SigInt agencies favour. Some would "high five" it or call it "nicely finessed"...:@

Clive RobinsonNovember 9, 2019 12:17 AM

@ A Nonny Bunny,

Aren't there more people on the network than on the endpoint, though? So isn't it an improvement?

That sort of depends on who is doing the attacking and why. Attackers on the network come in two basic flavours,

1, Targeted.
2, Opportunists.

If you are a "Person of Interest" like a journalist or suspected whistleblower, then you will be attacked irrespective of any other consideration currently. That is those doing the "Targeted attack" will keeping going at attacking your communications end point security with an entire panoply of attacks untill they succeed or their paymaster tells them to stop. Usually a stop order will be because others have found a different way in past the communications end point security via a variaty of "end run attacks" carried out via "black bag jobs" or the like. Where they get what used to be called "Front Panel Access" but these days gets called an "Evil Maid Attack". The obvious ones being the various "plug in attacks" via Apple's Firewire or the various USB port attacks.

So in the case of a targeted attack your communications end point device secutity, relative to the security of others on the network does not apply.

However with opportunistic attackers, your communications end point device security does matter to a certain extent. That is the principle of "Low hanging fruit" in a "target rich environment" kind of applies.

Opportunistic attackers are a little like those car thieves that walk down a road of parked cars after dark trying each car drivers door in turn, when they find an open door they get in and see if they can drive off or if there is anything to steal.

So if "your number comes up" and the opportunistic attacker "rattles your door", then if the security of your communications end point survives the attackers chosen "Door handle rattle test" the opportunistic attacker will move on to the next device in their number list.

So to recap,

1, If you are targeted a panoply of attacks will be used against you untill success is achieved.

2, If it's an opportunist attacker you will only be attacked on a probabilistic basis, and by a single attack type that you might or might not be vulnerable to thus the attacker will only succeed in proportion to the multiple of the two probabilities.

In the second case there is also a time component involved. That is with a new attack there is a probability that it will be detected and thus a clock starts on generating a patch and people installing the patch. If the attacker gets to you before you've patched you are owned, after that time you are not.

Thus the opportunistic attacker has two figure out where on the time line to place their attack between,

1, Beat the clock with fast and loud attacks.

2, Avoid triggering the clock with a slow and quiet attack.

If they have reason to believe the attack they are using is "known" then they will base the stratagy towards 1. Which is what we saw back in May 2017 with the WannaCry ransomware attack, that used the NSA "EternalBlue" attack that was aquired and published by an alleged group of crackers calling themselves "The Shadow Brokers" a few months prior to WannaCry hitting the network.

With regards,

Because it's far easier to compromise the network.

Whilst that might appear to be conceptually the case, the reality is different. Whilst the various national SigInt agencies may "grab data off the wire" from vampire taps, compromised routers, and via some MITM attacks, what is normally seen is cyber-criminals go for the communications end point devices not the network or it's nodes.

The exception to this is public WiFi at conventions, airports, hotels and very occasionaly coffee shops. The reason is the shear number of targets makes the effort worth it, and WiFi can be "passively attacked" so the risk of being detected is very low.

FANovember 9, 2019 4:52 AM

@Clive Robinson

> Both of which mean that it works very badly with audio that has been digitized, > and then made,anything but continuous by the encryption process and turned back > it into an audio waveform.

It took me some time to make sense of this, until it become clear that we are talking about different things.

The scheme I refer to is:

audio -> A/D -> CELP encoder -> encryption -> digital channel -> decryption -> CELP decoder -> D/A -> audio

which is how a secure voice system is build today given that we have digital networks. With this scheme, I fail to see in which way the CELP coding has anything to do with security.

In POTS times, the digital channel above would have been

modem -> telephone line -> modem

What you seem to refer to is using an analog channel that expects voice signals to transmit arbitrary data converted to a voice band signal. This isn't going to work well of course.

Now are you suggesting that today's voice communication systems are deliberately designed to make them near unusable for transmitting digital data ?

Is that is how you suspect the NSA is involved in resisting secure communication for the general population ? Is that what did you meant by

> Actually there is a fourth which is the NSA, but probably
> not in the way you might be tempted to think.

which started this discussion ?



Sancho_PNovember 9, 2019 9:41 AM

@FA

I think the real issue is the transmission.
In reality there is no digital in our environment, it’s all analog.

What you called “digital channel” in fact is analog, discriminated at the receiver to digital. The magic here is that regardless of the received error-prone “noise” the CELP decoder can form an analog signal that finally can be interpreted by our brain as to be sound / voice.
To encrypt / decrypt you’d need a nearly perfect transmission in between, which isn’t guaranteed here. Speed is the driver!

The channel is not designed as to be bad. Technology behind CELP is a requirement, not a burden.

FANovember 9, 2019 11:51 AM

@Sancho P

> What you called “digital channel” in fact is analog, discriminated at the receiver to digital.

Of course it is, but I don't see how that is relevant here.

> To encrypt / decrypt you’d need a nearly perfect transmission in between,

Or use some error detection/correction which in this case I consider to be part of the digital channel. Voice coders are usually capable of handling a missed packet every now and then. Most VOIP systems actually work on top of UDP, which can drop packets. Of course you can't use any crypto in a mode that would make a single error propagate forever. But that is true of most applications. There's nothing specific to CELP coding here.

What I _think_ Clive was referring to is that you can't just use a CELP encoded channel (encrypted or not) as a linear analog one with the same bandwidth, e.g. to transmit digital data using a standard modem.

Early digital secure phones worked by turning the encrypted data back into audio to be transmitted via a POTS line. This won't work if you replace the POTS line by e.g. the audio interfaces of e.g. a GSM phone.

But I don't think that this is part of any effort by the NSA to make secure communication for everybody impossible, which is what Clive seemed to say in his reply to my original message.

SpaceLifeFormNovember 9, 2019 2:17 PM

@FA @Clive

"Early digital secure phones worked by turning the encrypted data back into audio to be transmitted via a POTS line. This won't work if you replace the POTS line by e.g. the audio interfaces of e.g. a GSM phone."

I have to object, assumes facts not in evidence.

But, Metadata could defeat you anyway.

Think about who wants to intercept vs who is doing the comms. Big gubmint can just ignore *their* audio noise.

"But I don't think that this is part of any effort by the NSA to make secure communication for everybody impossible, which is what Clive seemed to say in his reply to my original message."

Agree.

Consider, in Siri voice:

One, Three, Five, Eight, Zero [etc, etc]

Numbers Stations.

It is the metadata. With radio, the end point recipient is hidden.

With non-radio (I.E., internet), you must be noise in a cloud of noise.

You can still do the voice encoding (in Siri), but it needs to get out without revealing the recipient.

The sender and receiver can not connect.

But, I believe it is possible that you can do numbers-stations over internet.

But, it requires more than a few servers.

It probably is already happening. Maybe via ad servers.

Clive RobinsonNovember 9, 2019 3:30 PM

@ FA,

What you seem to refer to is using an analog channel that expects voice signals to transmit arbitrary data converted to a voice band signal. This isn't going to work well of course.

Which is my point.

The problem with crypto-phones and similar is they are expected to work not just with "digital networks" but "analogue neteworks" including "radio networks" seamlessly.

In First world nations analogue networks still abound even though they are faked with the first mile to the CO being analogue BUT then converted to digital. This usualy involves a second CELP converter and it's here it often goes horribly wrong...

Hope that explains part of the problem.

But whilst CELP might have low latency and meets the bit rate requirments, there are better coders that work well not just with both analog and digital networks they also work well over HF radio links. Further the don't have anything like the problems you see with encrypted systems across analog and radio circuits.

Thus the question arises as to why a coder that is realy quite awful with encrypted traffic became the number one coder recomended by standards committees?... Especially when they were known to have Five-Eyes SigInt personnel on them. Hence the question over "Finessing".

FANovember 9, 2019 4:16 PM

@Clive Robinson

> In First world nations analogue networks still abound even though they are faked with the first mile to the CO being analogue BUT then converted to digital. This usualy involves a second CELP converter and it's here it often goes horribly wrong...

Agreed. But why is that a problem ? To have secure voice communication we don't need to pass via the telephone system, we have a digital infrastructure today -- it's called the internet :-)

So the fact that CELP voice channels can't be used for digital data doesn't in any way stop us from having a secure system. Which IMHO makes your 'CELP is one of the ways the NSA is resisting secure communication' assertion a bit tenuous.

On a related note: during one of my many recalls in the army (being in the officer reserves) we were introduced to RITA (1), the new tactical communication system that was being rolled out at the time (early 80'). It was quite advanced for its time: fully digital, encryption, frequency hopping, dynamic routing, etc. It could handle voice and teletype. But the voice channels *were* compatible with the standard modems of the time. From a military POV that made a lot of sense: you could just patch a RITA voice interface to a twisted pair as used for field telephones and have a modem at the other end. So you didn't need dedicated digital links all over your field HQ. Things have changed since then...

Ciao,

[1] Réseau Intégré de Transmissions Automatiques

Sancho_PNovember 9, 2019 6:42 PM

@FA

I was thinking of a mobile phone connection (Blackphone).
That amount of noise can’t be fully error corrected. What I called magic is the fact that most errors don’t reach our ear.
These phone standards are very old, the available HW was limited and had to be cheap (not military budget).

MarkHNovember 9, 2019 10:21 PM

I wish to offer up what I know about the modem question, having suffered for long years with problems related to modem communication. I'm no expert, and what I learned along the way might have been obsoleted by new developments, so I welcome any corrections.

Here in the U.S., the standard for wired telephone systems has for a long time been the Bell System "µ-law" non-linear digitization, with 8000 samples per second encoded in 8 bits. By the time modem makers started designing their exotic high-rate products, such digitization was standard, so all modems were designed to work compatibly with it.

I always assumed that a modem would be effectively killed by a mobile voice channel, and I'm impressed to learn of Clive's efforts to explore what could be done with it.

What happened where I live, and I guess is typical for many U.S. locations, is that for quite a few years we had no broadband available, being too far from the Central Office (CO) for aDSL to reach. When the operating company started offering aDSL, what they had done was to run a fiber-optic cable from the CO to a Controlled Environment Vault (CEV) they installed only a few hundred meters from my house. All of the neighborhood copper pairs were disconnected from the CO and routed to the CEV.

My mental image of the CEV, is that it contains a replication of what used to be at the CO: they probably use the exact same Subscriber Line Interface Circuit modules (SLICs) that the 5ESS uses at the CO. Of course, these are the aDSL-capable SLICs which long before provided DSL to those who lived close enough to the CO.

As far as any modem is concerned, my wired phone connection is the same µ-law voice channel as it always was. In theory, it ought to work even a little better, having a much shorter copper pair to traverse.

To my knowledge, CELP has no place in this system.
_________________________________________

However, things don't work this way everywhere; my neighborhood is served by what is probably one of the world's largest telephone operating companies.

A client of mine makes boxes which typically rely on modem communication, and a major customer has facilities in very remote rural regions, with vast stretches of little-populated land (think absence of paved roads).

At some of these locations in recent years, small "mom-and-pop" telephone operating companies have, as a money-saving measure, replaced customer copper connections with VoIP connections via some common data service. This isn't done at the customer site, but invisibly nearby (perhaps an equipment box mounted on a utility pole).

In fact, the customer was not aware of the change-over; they simply found that modem communication stopped working. Modem connections were not necessarily 100% broken, but far too unreliable to use. I assume this is due to aggressive compression in the VoIP system, whether CELP or some other compression.

In at least some cases, they were able to pressure the operating company to restore a few copper connections. It's possible that in other cases, VoIP has supplanted copper using non-compressing codecs with less impairment of modem communication. There are still some old-timers out there using FAX machines, whose modem protocols are closely related to those for data modems.

In the longer run, our customer plans to finally let go of modem communication (to our considerable relief) and put our systems onto an IP network.

However, that poses its own security problems ... snooping (or spoofing) modem traffic over conventional phone lines requires significant effort and risk to gain access, whereas the same malevolent interventions via data networks can be done easily and safely from the other side of the world. Whether they plan to rely solely on their own VPN, or intend other safeguards (such as dedicated data lines), I don't yet know.

SpaceLifeFormNovember 11, 2019 4:55 PM

@MarkH

s/CEV/VRAD/

Trust me, there is zero 5ESS tech outside CO.

5ESS tech is very, very old tech, held together with bailing wire and duct tape.

Seriously, the term 'Cluster F*ck' came about because on 5ESS switches, there was/is a software construct called a 'Cluster'.

The 'Cluster' was designed to conserve storage/ram on 5ESS switches.

It was created to save memory.

On 3B2 processors with very limited RAM.

Basically, a 5ESS switch is a bunch of 3B2 processors, held together with bailing wire and glue.

So. Most subscribers (aka, customers), that wanted certain features, such as CF (Call Forwarding), 3WC (Three Way Calling), CID (Caller ID), were given a Cluster, as opposed to giving each individual subscriber their own 'features'.

This saved RAM in the 3B2 processors.

But, when a tech screwed up, amd removed a festure from the software construct called a Cluster...


MarkHNovember 11, 2019 7:48 PM

@SpaceLifeForm:

To my knowledge, Video-Ready Access Devices don't exist in my region.

The copper pair to my house terminates in a Controlled Environment Vault: a service crew from my Operating Company pointed out its location when they had to spend some time inside to correct a ground fault.

I'm simply guessing that the SLICs there are the same as in the CO.

Clive RobinsonNovember 11, 2019 8:11 PM

@ MarkH,

Here in the U.S., the standard for wired telephone systems has for a long time been the Bell System "µ-law" non-linear digitization, with 8000 samples per second encoded in 8 bits

Actually both ITU G.711 u-law and A-law are used in the US. Because the rule is "When subscribers using u-law connect to subscribers using A-law, the connection will default to A-law".

Both u-law and A-law "compand only" that is they use an 8bit dynamic range, scaled to the mean audio level. Thus you get the ewuivalent of 14 or 16 bit levels given as 8bit levels and a scaling factor, which reduces the number of bits. Because the sampling rate remains constant and only companding is used the frequency, phase and any discontinuities get passed as though it is a true analogue channel. Thus encrypted data turned back into an audio signal will pass with little problems providing it's dynamic range is 42dB (volts) or less which most Phase and Amplitude modulated (QAM[1]) modem signals are (256QAM only uses a sixteen by sixteen constalation pattern which will work in a channel dynamic range of 30db).

But G.711 is not just "fixed sample rate" it is also realy quite inefficient have a look ay the ISDN bit and frame rates.

Various telco's wanted to increase "channel capacity" without "increasing bandwidth". So something had to give and it was the effective bit rate was to be dropped by a factor of eight or sixteen that the GSM radio interface had proved was more than possible. So in the 1990's various Telco's started to switch from "circuit switched networks" to "packet switched networks" such as the BT TCP/IP-2000 initiative. Companders were nolonger upto the job this CELP started to replace the G.711 companders.

Have a look at ITU-T G.728, G.729, and G.723.1 to see what is available. However you will find warnings such as,

    Dual-tone multi-frequency signaling (DTMF), fax transmissions, and high-quality audio cannot be transported reliably with this codec. DTMF requires the use of the named telephony events in the RTP payload for DTMF digits, telephony tones, and telephony signals as specified in RFC 4733

Which might answer a couple of your effective questions.

[1] Quadriture Amplitude Modulatrd QAM data keying uses the concept that an oscilator with two quadriture outputs one shifted by 90 degree with respect to the other, can be effectively combined to give multiple phase and amplitude "constelations". For QAM, each carrier is ASK/PSK modulated then put through a linear combiner to produce what is in effect a single frequency carrier with no actual carrier transmitted, thus all the transmitted signal power is in the data sidebands.

MarkHNovember 11, 2019 10:05 PM

@Clive:

I claim no visibility into the protocols major operating companies have adopted in managing their networks.

From experience, FAX and high- or medium-speed modems seemed to work in most U.S. locations for a long time, and as far as I'm aware still can.

In other words, however they manage the audio signal, it remains modem-compatible (in most of the country), at least up the 14.4k ITU V.17 protocol popular in FAX machines.

The little manufacturing company I consult for has many customers still using data modems, which gives us a sampling of the capacity of US landlines to support them. If modem-killing codecs become standard on US landlines, we'll probably notice.

All of our current customers are in North America, so we don't have a comparable picture of dial-up modem compatibility of landlines in other regions.

Of course, dial-up modems are a painfully old technology, and customers are gradually switching over to IP networks.

As I mentioned above, some American businesses still use FAX ... it's a lot more secure than emailing confidential documents. It's difficult to gauge, but there may be more than a million dial-up FAX machines still in use here, so operating companies using compression suitable only for voice will have to deal with a lot of customer complaints.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Sidebar photo of Bruce Schneier by Joe MacInnis.