Schneier on Security

Clive Robinson • November 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.

Clive Robinson • November 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.

Clive Robinson • November 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

Clive Robinson • November 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 Robinson • November 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”.

Clive Robinson • November 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.