Schneier on Security

Litron • August 22, 2015 10:36 AM

@Nick P:

I’m EXTREMELY suspicious about this thing, and I’m afraid that your donation has gone down the drain. I’m also quite puzzled how Bruce Schneier could appear to endorse this thing. Is he privy to more information than a mortal like could find?

A device inserted in the audio connector would essentially have to transform a speech-like signal into another speech-like signal, which would preserve the information content once it went through an unspecified codec operating at an unknown compression ratio.

These strip away as much as possible any redundancy in the signal, and the parts which the human ear wouldn’t be able to perceive anyway, and then proceed to code them with as few bits they can get away with. A transformed audio signal may not play well with all that processing.

That’s a very tall order for me.

Furthermore, many mobile phones systems work on the premise that speech communication is half duplex to make a better use of the spectrum.

Does this device also output a signal when the audio input is idle? This would especially create problems when calling a 2-wire landline from a mobile phone, especially on long-distance calls.

Speech scramblers have been around since the 1920s, but it was quickly realized that the transposition and/or permutations and/or inversion of a signal in the time and/or frequency domain did not result in secure communication. Only a handful of combinations wouldn’t permit comprehension by a trained listener.

Germans listened in on scrambled transatlantic phone channels, on both shortwave and the one-of-a-kind 60kHz long-wave system at the outset of the WW2 hostilities, and filled reams of transcripts.

This all stopped when SIGSALY was introduced: the output of a vocoder-based digital speech encoder was encrypted using a one-time key recorded on two special phonograph records played synchronously at both ends. The terminals were literally only a couple of pounds less heavy than a sawmill, but that was what was needed to keep Churchill and Roosevelt chatting in confidence.

GSM provided at the outset special modes allowing the transparent transmission of FAX and data modem signals, but these would be more adapted to the needs of the 1980s than those of 2015, and I doubt that these are supported by a lot of models.

Merely sending a Modem carrier over a microphone is very unlikely to provide good results.

Litron • August 22, 2015 2:14 PM

@Nick P:

I glanced at the page. It tells you what they claim it ISN’T, but doesn’t tell you what it IS.

The crypto mumbo-jumbo doesn’t tell me anything about how the signal, ciphered or not, is transmitted from one black box to the other one.

Again:

The issue isn’t the crypto, but with basic signal processing and transmission.

If it isn’t a mere speech scrambler, then what is it?

Could it be: A speech coder, followed by a crypto, followed by a modulator?

At the receiving end, the operations would have to be performed in reverse.

Might work on an 2-wire landline. There were 56kb/s modem standards which approached the theoretical limit of the channel when it was connected to a digital exchange. The absolute limit imposed by the ADC was 64kb/s, but certain forms of trunks signaling robbed a bit now and then, and there was also spectral constraints on the line. The rate was achieved by a carefully designed equalizer.

This little feat could be achieved as PCM was extremely simple in comparison with the codecs used in mobile phones, and you only had few variations to take care of.

But is that feasible on a mobile phone, or Skype?

A mobile phone codec transforms speech into a bit-stream with a rate between something like 2 to 13kb/s, depending on the standard and other parameters. The channels they provide are not at all transparent.

The encoder in your little black box would have to put out a comparable bit rate to achieve the same quality. It can only be lower than the the phone’s own throughput, never higher.

A robust way must be found to map this signal onto something the phone coder’s will accept, without as little penalty as possible, and including all the necessary handshakes, and impervious to transcoding, dropouts, and other problems. The box would have to figure by itself what bit rate is achievable on the channel, how the phone compresses the signal, what signal levels should be used, and that without any cooperation from the phone.

That’s a tough requirement, to say the least.

In the present case, I really believe that we have a choice candidate for the previous post’s Snake Oil Cryptography Competition.

I checked patents, there’s nothing in the firm or inventor’s name, except US2013080639A1, which is about software engineering and not crypto or modem design per se.

Executing the crypto outside the communication device isn’t a bad idea per se. I could imagine a bluetooth headset providing this function, with the smartphone being used only for data transmission.

But not over the audio lines.

While I’m mentioning patents: there are a few SS7 firewalls out there, and the security issue was already known in the 1990s. Why aren’t these widely used? If the CO equipment is crap, a competent telco operator could still secure its domain by filtering and logging all unusual traffic at its network boundaries.