Nobody Encrypts their Phone Calls

In an annual report published Friday by the U.S. judicial system on the number of wiretaps it granted over the past year …, the courts revealed that there were 2,376 wiretaps by law enforcement agencies in 2009, up 26% from 1,891 the year before, and up 76% from 1999. (Those numbers, it should be noted, don’t include international wiretaps or those aimed at intelligence purposes rather than law enforcement.)

But in the midst of that wiretapping bonanza, a more surprising figure is the number of cases in which law enforcement encountered encryption as a barrier: one.

According to the courts, only one wiretapping case in the entire country encountered encryption last year, and in that single case, whatever privacy tools were used don’t seemed to have posed much of a hurdle to eavesdroppers. “In 2009, encryption was encountered during one state wiretap, but did not prevent officials from obtaining the plain text of the communications,” reads the report.

Tags: courts, encryption, law enforcement, phones, privacy, surveillance

Posted on May 6, 2010 at 7:06 AM • 49 Comments

Comments

Mike B • May 6, 2010 7:27 AM

Well for POTS there just aren’t a lot of generally obtainable encryption tools. Furthermore key management is a bitch because its a bit hard to pre-share keys with all of your future criminal conspirators or set up some sort of underworld PKI.

larry seltzer • May 6, 2010 7:28 AM

I suppose the growth is telling, but the overall number of wiretaps is smaller than I expected. My sense of these things has probably been distorted by television.

bob • May 6, 2010 7:35 AM

@larry: These were legal wiretaps. Its the unlawful wiretaps that have had 50,000% annual growth since 9/11.

alreadyonthelist • May 6, 2010 7:48 AM

@bob you are right.

The manipulation of the taps is even more interesting. Raising background chatter and counting (for echelon’s dictionary function)instances of sounds such as “gee” taken out of the word geometry, keeps a lot of this garbage going. Its money for a corporation and local units of government. Patriot Act Abuse is very profitable, and the wiretaps are part of the piece.

Let’s say you are a local unit of gov/subcontractor watching some US citizen who is in a watch program for poilitics or an echelon phone blip. You are running out of time/money for the observation. You work for a company. This company wants to prolong the job. There’s no evidence of any illegal or dangerous activity. You can have an Arabic speaking person call the line when nobody is home and leave a message on the answering machine. Echelon grabs it, and bingo you’re authorized to watch for another year. It doesn’t matter that the people at the residence don’t speak the lingo. You are playing a game with a paying agency too far away to check. If your human intelligence gatherers are tied to paychecks, nobody is going to blow the whistle. The company sends the report to the paying agency.

Then, you need to prolong the job again. You elevate background noise on the tap and isolate key words taken out of context like the “gee” in geometry. All dictionary does on the phone tap is count instances, it does not put things in context.

Nobody investigates Patriot Act Abuses.
Phone/wiretaps are essential parts of keeping the abuse going.

D • May 6, 2010 7:48 AM

@Mike B:

“…all your future criminal conspirators…”

Or anyone else with whom you want to have a truly private conversation. I might actually like to have some racy conversations on the phone with my spouse if I knew it was encrypted.

AC2 • May 6, 2010 7:49 AM

What I really want to know about is Skype PC-PC wiretaps if any and what success they had with the encryption there….

@MikeB
+1 on that…

@bob, larry
I guess the “Those numbers, it should be noted, don’t include international wiretaps or those aimed at intelligence purposes rather than law enforcement.” covers what you’re referring to?

Brian • May 6, 2010 7:51 AM

@alreadyonthelist

I feel like movie plot threats to privacy are just as silly as movie plot threats to our safety.

Challenge • May 6, 2010 8:29 AM

@Brian

Agreed. The problem isn’t the technology they use to investigate citizens, violate privacy, or extend service contracts.

The overarching threat that enables all of this is pandering to people’s fears as a political tool. That’s exactly the tactic that such programs intend to combat!

arkanoid • May 6, 2010 8:30 AM

Have you guys noticed that law enforcement agencies’ whining about skype unwilling to cooperate and interfering with thier job suddenly stopped a year ago or so? Make your simple conclusion.

NobodySpecial • May 6, 2010 8:50 AM

But Skype calls wouldn’t be included in these figures – this is only telephone calls.

It’s typical government logic, skype calls are encrypted but if we define them not to be phone cals then there is no problem with encrypted phone calls.

Harry • May 6, 2010 8:51 AM

@AC2: What I really want to know about is Skype PC-PC wiretaps if any and what success they had with the encryption there…

Its possible to track the location of Skype conversations (ie, where the computers are) – Kobi Alexander was found in Sri Lanka by a private investigator in 2006 after his Skype call was placed. (http://www.engadget.com/2006/08/25/fugitives-skype-call-leads-to-his-arrest/) Bruce blogged about it on 26Aug06.

Call content, on the other hand, is encrypted. (Reference on ZDNet but that page isn’t loading for me today.)

zfone-fan • May 6, 2010 8:54 AM

Why hasn’t zfone been implemented into any commercial products? Is it too difficult and expensive to make the required changes to software?

GreenSquirrel • May 6, 2010 9:07 AM

So what options are there for private individuals who want to be able to encrypt their calls?

I suspect none to allow encrypted chat to general population. I cant think of any that I could (for example) give my wife to use so I can call her from a payphone and have an encrypted chat. (Not to mention the act of using payphones seems to have become a marker for “criminal activity”)

The reality is there is no realistic manner that an individual can set up their phone so their calls are encrypted. I am amazed they had one to work with.

Does the knock on effect of this mean we shouldnt assume our telephone calls carry a right to privacy? (Or does the point to point link count?)

chris • May 6, 2010 9:18 AM

@GreenSquirrel wrote:
I suspect none to allow encrypted chat to general population. I cant think of any that I could (for example) give my wife to use so I can call her from a payphone and have an encrypted chat. (Not to mention the act of using payphones seems to have become a marker for “criminal activity”)

what are payphones?

OTR_4_all • May 6, 2010 9:21 AM

I recently installed the newest version of the OS Ubuntu and I was surprised to see that it has encrypttion functions embedded within it. It therefore enables easy use of encrypted VOIP and the usual form of email/IM encryption.

Sooner or later a developer is going to create an phone encryption product for mobiles and landlines that is easy to use, but no doubt this will need a greater sense of distrust toward the state.

Just recently cellcrypt.com started to offer voice 3G and WiFi encryption products for smartphones, sooner or later this type of technology will be embedded in phones and could be enabled by the simple click of a button.

Just like Vanish, it would be good if such one-time irrecoverable data tech could be used for encrypted voice calls.

http://vanish.cs.washington.edu/

BF Skinner • May 6, 2010 9:24 AM

I remember reading somewhere that if security isn’t made easy users’ will simply bypass it. (that may be my experience overwritten by someone’s book) By some guy name Bruce somethin’. He gave the case of a fortune 500 firm who suffered a breach and consequently had the executives provisioned with encrypting cell phones. Executives who continued to use their unencrypted phones because call quality was better.

A meeting to discuss DHS’s solution to the requirement “no sensitive data discussed over unencrypted voice circuits” ran immediately into Border Patrol saying ‘hey we’ve got thousands of miles of border with Canada to patrol eh; and the cell towers are few and far between. Our radios are reliable and necessary.’

Blackberry can do secure voice. And there’s 3rd party apps for Nokia. I don’t know about iPhone or Androids…is there an app for that?

Even if encryption of the communication path is doable (solves user demand and key management) and the hop from cell to tower to POTS to tower to Cell or subscriber handset. . .shouldn’t it be possible to take the conversation from the cell handset itself before the signal is ever encoded? We have seen the case where apparently a villians cell phone was used as an open mike for the LEO.

BF Skinner • May 6, 2010 9:29 AM

@chris “what are payphones?”
Every phone I’ve ever owned.

@Green Squirrel “what options are there for private individuals who want to be able to encrypt their calls?”
The first thing would be to stop taking cell phone calls while they are in the can or sitting next to me on the train. Then we can talk about encryption.

Scott • May 6, 2010 9:35 AM

If the encryption is implemented well, they wouldn’t know that there’s actually anything to tap.

thinker • May 6, 2010 9:56 AM

GSMK sells cryptphones with open source code. http://www.cryptophone.de/en/company/

But many times the actual content of a call is not important – calling patterns and connections (who calls who) give a quite detailed picture of ones social network. And this can be analyzed by computers. Actual speech recognition and placing it into context still requires manpower. Even if someone uses only encrypted phones – eavesdropping can be done using normal bugs in the apartment or even by skillfully exchanging the battery of the used phone (detectable only via high resolution x-raying the equipment).

But I still would wish for strong encryption as a standard feature of all (mobile) phones. Especially since the last breaking of the GSM-encryption standard. http://events.ccc.de/congress/2009/Fahrplan/events/3654.en.html

PlainBrownWrapper • May 6, 2010 10:15 AM

@chris
(sorry for the OT posting…)

The likelihood of finding payphones is directly tied to the demographics of the neighborhood.

Try visiting that area of town “on the other side of the tracks”, and you’ll see what I mean.

OTR_4_all • May 6, 2010 10:34 AM

@thinker

I agree it may be usage pattern that could be just as valuable as content, but surely someone has a voice call system akin to Tor, which allows visits (calls) to websites, without a record being kept/made of the website visited. IE: create a non decentralised distributed VPN 4 VOIP/WiFi etc to make and take encrypted calls. Usage data is of course what ISP’s and Telephone companies already retain, so someone must be seeking to develop privacy enhancing technology to nullify these records.

RandomIMEI • May 6, 2010 10:45 AM

I am sure it would be easy to use mobile phones with encryption facilities, that can also use a throwaway sim card and a have a facility for a random (fake) International Mobile Equipment Identity (IMEI) number. Though I can’t recollect what the Dubai assassins did to frustrate mobile phone call forensics. Though, I seem to remember alot being made of mobile phone geographic monitoring records for an IRA bombing. Well a mobile phone can also be good at being a virtual gps tracker.

Fabio Pietrosanti • May 6, 2010 11:08 AM

I am the CTO of a company doing mobile voice encryption PrivateGSM http://www.privatewave.com
We do what Zfone does on a PC with ZRTP but on smartphones .
Want to tell you my feeling from 6 years in this field doing mobile voice encryption.

Business people understand the risk of illegal or semi-lawful wiretapping.
Business people protect themself ONLY if they are properly suggested by a Security Staff, otherwise alone they do not even understand that it’s possible to protect from wiretapping.
You can’t even immagine how many customer i meet that say “woah! It’s possible to protect from wiretapping? I didn’t know!” .
That’s the real world.

Government people understand the issue and they usually protect themself also because it’s mandated by their policies.

Criminals, fortunately and generally speaking, does not employ encryption because they DON’T NEED TO GET NOTICED, so they don’t need to shop that they are protecting themself.
Criminals NEED ANONIMITY.
Criminals use satellite phones with subscriptions bound to non existing persons brough in dictatorship oriented african countries.

Criminals tend to use a few encryption, because they need anonimity and encryption tend to get noticed by who wiretap.

So this is the real point of the situation:

Government have the need and know how to protect themself (by using crypto)
Business users have the need but does not know how to protect themself (by using crypto)
Criminals have the need and know hot to protect themself (by using anonymous telecommunications)

Ah! Generally speaking, end-users and normal persons doesn’t care about wiretapping…

Additionally i have to tell that for general acceptance voice encryption apply to mobile phones.
I do something like Zfone but on mobile phones (all major smartphones).
Developing on mobile realtime application that play with audio subsystem cost a lot and it’s difficult.
Making it very stable and with an extremely usable UI it’s even more difficult.

So there is an entrance barrier for the company doing this.

I want to decrease such barrier making such kind of tools available for very cheap price and on the basis of opensource voip stack and opensource encryption based on ZRTP.

Technically everything it’s feasible.

The real problem is making things that are secure (open source and open standards), accessible (both in terms of available smartphone platforms and price) and usable (so that even the 60 year old business user member of a board of director will be able to protect himself).

Those are all considerations required to make something that works.

Fabio Pietrosanti (naif)
http://infosecurity.ch (my personal blog)

finid • May 6, 2010 11:51 AM

zfone has actually been implemented into some commercial phones by a few French firms. It’s just not widely available.

RandomIMEI • May 6, 2010 12:06 PM

@
“Ah! Generally speaking, end-users and normal persons doesn’t care about wiretapping…”

Yes, but that does not explain why Skype has enabled encryption by default, normal Skype users benefit from this technology as it protects privacy and this is the model that should be used. IE: End-to-End encryption, without the user even noticing it is there, be they joe public, criminal, government, business or any variant thereof. Most nefarious behaviour has to be tied to actual physical real world activities, that can be noticed, observed and captured or even overheard and recorded as a person speaks into their phone…

Privacy equals $500 • May 6, 2010 12:19 PM

The Privacy Wave license for one cell phone for one year costs $500 dollars. I never realized privacy was so ******* expensive, as I would need to spend at least $1000! Talk is cheap-not. But at least the company is apparently looking at introducing an open source (free?) solution.

NobodySpecial • May 6, 2010 1:31 PM

@Yes, but that does not explain why Skype has enabled encryption by default,

It’s perceived risk by the customer.
Analog cell phones just required somebody within 100m of you to have a VHF radio, it was also trivial to clone phones and steal calls. So customers wanted some security with GSM.

With the internet, users imagine somebody sitting in front of a computer in Tajikistan as being able to hack into their call and so demand encryption.

If POTS was introduced today customers would expect encryption.

jackit • May 6, 2010 2:11 PM

I think criminals have reliable anti-taping solutions available today. What I think is that they are often simply too ignorant to know that.

Never forget that Sammy “the bull” Gravano is spending 30 years in the Big House because, after having been able to avoid several life sentences for 19 killings by collaborating w/ the feds to incriminate John Gotti, he got then caught “masterminding” a drug trafficking operation because he told his own people to feel free to talk w/ Nextel phones “because the FBI uses it and so they can’t be taped”.

b0b • May 6, 2010 2:22 PM

@Yes

The reason Skype uses crypto in the first place is because of its p2p nature. As they say:

“In some cases your Skype communication may be routed via other users in the peer-to-peer network. Skype encryption protects you from potential eavesdropping from malicious users”

I don’t think any commercial company can REALLY fight the American gov, if they decide to listen on you.

Robert • May 6, 2010 7:03 PM

In the distant past, I worked on some POTs voice encryption parts, frankly these products were not at all useful, because the level of encryption that could be achieved was trivial to break.

One of the biggest problems was the need to call a cell phone and keep the whole link encrypted. In a POTs to cell link the call is typically Pot’s all the way to the tower, however over the cell phone RF link the voice is LPC compressed. So the encryption must make sense to the LPC compressor or otherwise you get nothing sensible, to decode, at the cell phone end. Basically the LPC compressor expects a voice signal, so you need to encrypt a voice signal into a signal that looks and behaves like a voice signal (BUT contains no useful information). This is hard to do well and results in big decreases in the understandability of the phone link. Basically cryptographically strong Pots encryption is unintelligible, to the phone user, so guess what, they turn it off ….and never order another part.

Nick P • May 6, 2010 9:34 PM

@ BF Skinner

We’ve discussed this problem before with cell phones. There are cell/SMS encryption solutions on the market that are easy enough and have good call quality. However, their real security is unknown. Such a cellphone must be secured on many levels: SoC (hardware); SoC(firmware); drivers; OS; trusted path; other trusted services; encryption stack. Most cell encryption solutions only secure the encryption stack. GSMK provides a “hardened” Win Mobile OS and separation kernel-like schemes (e.g. OKL4) isolate critical code from untrusted OS. Presumably, Type 1 phones like GD Sectera Edge provide strong security on all of these levels. Everyone does a bit of trusted initialization and delivery, but insider threat is still unmitigated.

The user doesn’t know exactly what’s on the phone and can’t prove that there are no backdoors. It would take a DO-178B or EAL6-7 type of process and the documents/source/binary would have to be openly published. This hasn’t happened and there’s no sign it will. So, most cell encryption solutions ignore most of the security chain and the [expensive] few that secure the system as a whole may be subverted by manufacturers. Nobody encrypting their calls is, I think, a small issue. The big issue is that there is no trustworthy way to do that.

@ thinker

See above. GSMK is one of my favorites but you have to trust them not to be subverting the system. One big-time defense crypto supplier in a “neutral” country turned up a likely NSA front, so what are odds for a similar company in Germany? GSMK publishes source code, but leaves two issues: no proof of correspondence of source to object/assembler code (compilers routinely screw up crypto systems); no proof that hardware is running that object code rather than subverted version. To organizations worried enough to encrypt calls, this is a significant risk.

Nick P • May 6, 2010 9:37 PM

@ AC2 on Skype

Skype is the riskiest secure call platform out there. The Skype people have placed an enormous amount of effort into ensuring nobody knows how their system works. Vulnerabilities were found in Skype by independent researchers, showing the value of all of that obscurity rather than real security. Those hackers reverse engineered the object code itself. One thing I noticed in my own reviews was that their reverse engineered descriptions and those of the cryptographer that reviewed the source code are inconsistent. Did they make sweeping changes after the crypto review? It would seem so. Skype has also showed signs of spyware-like activity, like digging in the BIOS. Finally, there are a number of people out there who think Skype is currently an NSA front and that they are very capable of deciphering it. Not to mention it relies on insecure platforms for its security assurance. Here are some links on the subject:

ultraparanoid on Why Skype is Evil
http://ultraparanoid.wordpress.com/2007/06/19/why-skype-is-evil/

Another tech reporter who thinks NSA financed Skype acquisition
http://www.oreillynet.com/etel/blog/2007/04/skype_revenue_from_national_se_1.html

Another interesting angle I found on potential Skype to NSA connection was the publicized claim that NSA would pay $1 billion for anyone who’d allow them to seemlessly break Skype encryption. It came after the buyout, which put servers under US control/jurisdiction, and increased many unsuspecting people’s confidence in Skype’s security against US intrusion. Many of us couldn’t help but wonder if this was a classic intelligence ploy to get people to use a subverted system. It’s unproven, but both possible and with historical precedents.

When asked if I think it’s an NSA front or massive subversion tool, I will tell you straight up that I don’t know. There’s simply not enough data to be sure one way or another. I do know these things with certainty: the app does a lot of sneaky things; the protocol requires total trust of Skype; the object code’s activity doesn’t match the source code review’s description; Skype goes to insane lengths to obscure its app functionality; Skype has had severe vulnerabilities in the past. These things together are more than enough reason for anyone concerned about privacy to avoid Skype like the plague. The potential NSA connection just adds more Uncertainty to an app whose claims already inspire enough Fear and Doubt. For the first time, I’d say the F.U.D. is quite justified. Skip Skype. 😉

BF Skinner • May 7, 2010 6:32 AM

@Nick P “We’ve discussed this problem before ”

Yeah that’s the problem I see and why I think a Schneier wiki would be nice.

A blog comment is nice for short observations and single notions; but try to develop a thesis of more than one idea and you bore everyone to worse they tears…they skip the post and state the same point without support. Which I find–unhelpful.

skyper • May 7, 2010 10:36 AM

Maybe I missed someone mentioning that but http://www.digitask.de/ offer a ‘Skype-Capture-Software’ for 3500€ per month and suspect.

http://wiki.piratenpartei.de/images/5/54/Bayern-skype-tkue.pdf
Bavarian ministry of justice letter detailing above costs for a suspect.

Nick P • May 7, 2010 1:13 PM

@ BF Skinner

Always been a drawback of Schneier’s blog format. A forum would be ideal: conversations could go on; putting replies under each other in tree structure could isolate sub topics (instead of current ‘read every message’ method); I could code the whole thing in QBasic in like six months (TCP/IP stack and all). Alas, it isn’t so. If I get a blog going, I’m going to have a forum section reposting Schneier’s blog posts just so you guys can have lengthy conversations. How bout that?

@ skyper

Well, I did mention Skype’s secretive behavior, high likelihood of backdoors, poor code quality, misplaced trust, and possible NSA affiliation. But, no, I didn’t mention any such tool. Thanks for the link but it’s all in German. Is there an English article or English version somewhere where we can verify your numbers?

Roger • May 8, 2010 5:10 AM

Ooh, ooh, Clive hasn’t posted yet*, so I’ll chime in with some relevant technical detail on secure audio!!

For a very, very long time, secure audio meant “scrambling”. That is, the analogue audio circuit was modified in some way, without digitisation, so that it could not be understood by the human ear, but the output was still an analogue signal of the same bandwidth and dynamic range.

That isn’t to say that all of these scramblers offered terrible security. Some of the simplest did offer terrible security (apparently, after long experience of listening to a simple frequency inversion scrambler, an interceptor could learn to decode many words by ear) but the best were really quite quite good — well, at least “fairly good”. For example the one military / US Coast Guard system split the signal into multiple frequency bands, and interchanged them several times per second under control of a PRNG based on 3DES. (And such a solution still exists for hand-held radios, making moot the DHS claim that the can’t use secure voice along the US-Canadian border.) However, such systems are still much less secure than real encryption.

Long after sophisticated digital encryption methods were common for data circuits, voice circuits continued to use scramblers, for the simple reason that encryption required digitisation, and the circuits did not have the bandwidth to carry a digitised channel that could carry voice. For example, “telephone quality” PCM digitisation is typically reckoned at about 8 bit depth x 8,000 samples per second. That’s 64 kbps, each way, on a circuit that struggled to carry half that until the late 90s, even on a copper line.

And even c. 2000, wireless modems rarely exceeded 9600 baud, and a 19.2 kbps modem was a very expensive one. Of course WiFi soon greatly exceeded that, but only at very short ranges or with highly directional antennae — neither of which is suitable for a phone network.

The solution, of course, was compression. For example a GSM encoded voice signal can be compressed to as little as 6.5 kbps, making digital encryption easy even in 1989 (even if they chose to use a weak algorithm anyway!!) Similarly, earlier military secure voice systems had relied on the development of compression algorithms like CVSD.

But herein lies the problem: in devices like cellphones, the compression is implemented in hardware, the channel coding and encryption are implemented in hardware, and they are all linked at the hardware level. You really need to get into the nuts-and-bolts of the hardware to drop in a strong encryption algorithm after compression and before channel coding. Consequently, you cannot provide a drop-in solution, you need to sell someone a dedicated secure phone. That means small market volume, high prices.

Alternatively you could do you stuff before the compression — perhaps even creating a device that can be used on any circuit, even a payphone — but then you will:
a) get lousy compression and poor signal quality over a digital wireless network; and
b) be using weak scrambling algorithms, not strong digital encryption.
Some people do buy such gadgets, but there is a really small market for devices which provide lousy security, poor voice quality, and simultaneously attach to your phone a big red flag saying “here is a kook.”

Roger • May 8, 2010 5:11 AM

Oh, the asterisk beside Clive’s name was meant to link to:
*Clive, I hope you are well — not back in hospital?

Porlock Junior • May 8, 2010 1:35 PM

@Nick P
@BF Skinner

The wiki is an outstanding idea. If the right people were in charge of it (hint, hint) and it offered voluntary subscriptions to help defray costs, I’d try to be first to subscribe.

(Personal axe-grinding: Especially if it had a payment option that didn’t go through PayPal and offered a degree of quasi-anonymity. Nothing NSA-grade here, but sending every subscribee a more or less accurate personal identity through a third-party of unknown and completely untrusted security policies is not my cup of tea. Can anybody not a susbscriber to this blog understand that?)

Clive Robinson • May 8, 2010 5:02 PM

@ Roger,

Unfortunately I am back in hospital 8(

But a friendly face has just today dropped a new smart phone in to me (LG GW620) which has the awkwardness of the unfamiliar so… I’m back on line in a way…

With regard to audio encryption yes it has always been a bit of a problem in the “audio” channel (part of the issue can be understood by listening to vocoders in music by the likes of ELO)

Even when audio is encrypted in the digital domain there are still issues.

For instance who developed CELP which gives one of the best audio compression rates?

None other than “our “friends” the NSA…

That alone is enough to make many people avoid it, but importantly it highlights just how much redundancy there is in spoken communications.

However what many people do not appear to realise is that there is still a lot of redundancy still to be wrung out of audio…

And where there is that sort of redundancy there is the possibility for a cryptographer to find a crack into which they can drive a wedge…

So whichever way you slice it spoken audio encryption has a lot of question marks hanging over it, that need to be mitigated in the system design.

And to be honest I cannot remember seeing any academic/public documentation that specifically looks into how you would reasonably go about it..

Or for that matter consider if it does indeed need mitigation (which personaly I think it needs to be atleast considered not ignored)

Nick P • May 8, 2010 10:37 PM

@ Roger

Well, that was nice but you ended up in a false dichotomy later on. You said either they had to squeeze the crypto into hardware or had to ignore the compression. That’s not actually true. The less expensive phones on the market over the past decade, esp. CryptoPhone, use an efficient software compression algorithm then efficient software crypto. Moore’s law allowed us to hit that middle ground years and years ago. Except for public key, crypto is so fast it’s almost unnoticeable on small data streams. The compression, IO, and asymmetric stuff usually takes the longest. In every protocol I’ve designed, I create two symmetric keys at beginning of session: one for encryption and one for authentication. This allows me to either use symmetric or hash for authentication in-session. Sometimes, with careful coding, it can reduce the cache misses on the L1 cache, esp. if you reuse algorithms (AES crypto w/ AES-based MAC). Notice also that many embedded chips support crypto in hardware now and some even come with small FPGA’s (think compression). I see potential for increases in both cases.

@ Porlock Junior

Well, it really depends on who you are. PayPal isn’t usually a huge risk but if you wanted pseudoanonymity on the blog, I could see a few reasons. I think a workable scheme could have these components: long-term public key; certificate with public key, username, previous identity certificates, etc.; reputation tracker. The user would buy an identity with a credit card, possibly prepaid at a library computer. They essentially do this by submitting their certificate and it gets signed by the wiki. They can post signed messages which show a verified sign if the claimed credentials and certificate match. Reputation is essentially based on the time you’ve been on the blog without being kicked for serious misconduct. Any other rep system seems to invite trouble and conspiring among users. The “previous identity” portion is about getting a new identity in case of suspected private key compromise. You just sign the new certificate with your old one, including your old public key in it, and submit it. Then, everyone knows you just got a new cert with a new pub/priv key pair. Very simple. Just pub-priv key pairs embedded in site-specific certificates and used to sign messages. What do you think?

Nick P • May 8, 2010 10:45 PM

@ Clive Robinson

Personally, I don’t think audio compression should have any real impact on the security if the scheme is designed properly. The only way to truly mitigate compression-related risks is to send a constant fixed packet size and keep the line saturated. It’s inefficient but it prevents traffic analysis. This is why almost every military encryption system uses it.

Now, if we are using a fixed-size/rate transmission scheme, the security shouldn’t depend on compression because the encryption function is supposed to make the meaningful data look indistinguishable from a random stream. If the encryption does it’s job and the stream is steady, then there is no security impact by not compressing. It’s only if variable rate bursts are allowed that the security can be compromised by compression, esp. the one that encodes different sounds at different lengths.

I think the fixed-rate/size transmission scheme is just a necessary cost of doing business if you want real COMSEC facing enemies that may employ cryptanalysis (or automated tools). That’s a bigger threat model than some think: even many regular hackers are capable of cryptanalysis based on size or frequency. They learn that in children’s books on the subject. 😉

Clive Robinson • May 9, 2010 7:07 AM

@ Nick P,

I agree it should not be an issue with audio encryption but unfortunatly it can be, and in many cases will continue to be.

I’ll use the issue of an old and known problem, audio frequency inversion to set the stage.

For those that dont know frequency inversion was originaly thought up from channel coding and Single Side Band (SSB) transmission systems. What it did was to turn high frequencies into low frequencies and vis verser, which to the untrained ear makes it unintelligible. However not so for the trained ear which hears the “envelop” of the signal not the content. So the actuall high data content of the audio signal carries little or no intelligence that cannot be “remade” from the low data content envolope. This is why the likes of vocoders can make violins talk.

Well it turns out that for speach even the envolope is increadably redundant as well which means that mucking about with the envolope won’t get you much security either.

Part of this is the way we talk in that the phonems and voiced / unvoiced consonants etc predict each other etc. There are some estimates that put the real data rate of easy speach encoding at around 40bits/sec and hard encoding on a known voice down to just 10 bits/second. Which means as little as three or four bits can be used to get probable information…

Now just code book encoding digital speach is an easy job for the crypto analyst as it is a very simple substitution cipher with inordinatly high redundancy basicaly it gives up the envolope information with little or no effort.

Worse there are many equivalents to binim and trinim short cuts that assist. so much so that even some cipher chaining can give up information as well…

Put simply you need specialised types of cipher modes to ensure you do not leave cracks or hooks that can be used to break the audio out (one of which is to whiten the data going to a block cipher like AES with a stream cipher with an extra twist or two).

This is over and above the normal military “pad” and “constant bit rate” etc.

And unfortunatly this is a problem that is likely to remain due to “human authentication” where you need around 2400bits/second to make a reliable identification “by ear” of the person who is speaking.

If you stand back from the various CELP algorithms you will see that with a few minor changes they are actually better at doing the first stages of speach recognition than they are at speach compression…

Robert • May 9, 2010 9:01 AM

In the voice encryption that I was working on we did the following
1) LPC compress the voice (2kbps)
2) pad the LPC to create a constant rate bitstream 4kbps
3) digitally encrypt the voice stream similar security level as DES
4) transcode the digital encrypted bit stream into an LPC symbol stream, basically make the digitally encrypted and “whitened” bit stream look like a voice stream.

5) add redundancy and forward error correction (FEC) capability. The FEC coding was implemented in LPC symbols.

There were two reasons for step 4, firstly to prevent the stream being automatically tagged as an encrypted voice stream, secondly we needed to create a symbol stream that will work seamlessly across a typical cell phone link.

The FEC stage was needed because all digital cellphone links use some form of LPC compression such as CELP, RELP or MELP) most cell phone LPC voice compressor are designed to extend the last symbol when the actual data is missing, Unfortunately this really messes up the decryption so LPC FEC is essential.

Our marketing believed that we did not have a product if only Land-line encryption was done, we needed to be able to encrypt Cell to Cell, Pots to Cell and cell to pots as well as Cell(GSM) to Cell (CDMA) or even IS94.
Logically a disposable cell phone is the first step to any secure voice link.

the product got canned because of very poor performance of prototypes on Sprint network, (something strange about Qualcom’s CDMA voice compression that made it not accept our “pseudo voice” waveform. I never did find out what was different about Qualcom chips…

Nick P • May 9, 2010 12:36 PM

@ Robert

Interesting. It actually all made sense immediately, as I had the same problem in a design. We weren’t sure exactly where the encryption was applied but what we sent wasn’t getting to the receiver, so we were pretty sure they were compressing it in the comm stack. Modern crypto phones typically use data links like GSM, WiFi, etc. This makes availability a bit more challenging than a model like yours, but is easier to implement.

And, btw, I have no idea why Qualcom’s scheme didn’t work. I wish I could add to that, but I never experienced such troubles.

Clive Robinson • May 9, 2010 5:23 PM

@ Robert,

Like Nick P I cannot think of anything immediately that would answer your Qualcom issue.

But you do highlight some of the pains of “retro fitting” into existing systems with non transparent operation.

It is unfortunately issues just like that, that so often lead to bodges / cludges that provide the cracks into which the attackers wedge is driven.

It is understandable why high levels of lossy compression are used with audio but it sure makes life difficult from the security aspect. Likewise video has similar issues.

The trick of course in a retro fit is to do the encryption and transcoding as a single step, in an up front design to do the encryption as part of the compression… Both of which would require “non standard” encryption, which is fine if you are the NSA but not for the rest of us meer mortals.

One of the fundemental assumptions that most crypto algorithms work on is one to one input to output on the symbol rate and that the output can be random from symbol to symbol or apparently fully independent of each other to a down stream observer.

As a guess I would say that your transcoding did not quite work for Qualcoms system and looked like an “error” to some part of their system. Concevably you where excercising some “bug” in their design that had not appeared during their testing. For instance your transcode may have implied a signal slew rate that was not possible in the system due to say a lowpass filter, and they had a non standard optimisation which ment your transcoded signal jumped the end stop…

Nick P • May 9, 2010 9:24 PM

@ Clive

Your post is amusing because my original post elaborated on a few possibilities about Qualcomm problem and included the words “non-standard optimization.” I also thought that they, probably to be competitive on benchmarks, made an extra assumption or two in their compression scheme. I edited that part out of my post because I have no evidence either way. However, it would make sense for Qualcomm because their requirements didn’t include accepting encrypted voice as input. So, this wouldn’t be a bug: it’s an absence of a feature that one creative user (Robert’s company) thought up.

Robert • May 9, 2010 10:34 PM

@clive
With Qualcom CDMA chips it did not fail instantly, sometimes it would work correctly for up to 30 sec before getting totally lost….
The transcoding to “pseudo voice” created some very weird sounding voice streams. Typically it contained far too many explosives and pitch changes, which were intentionally added to keep the LPC symbol rate very high. We followed some rules to try to keep the “pseudo voice” signal looking and behaving like a real voice signal, but the severe envelop modulation and frequent pitch changing made the “pseudo voice” sound like an angry Chinese transsexual.

I’m not sure that a single step voice to “pseudo voice” encryption would be better and I’m certain it would not be more secure. The way we did it, we could test the digital stream for all the normally desirable crypto features like whiteness and symbol to symbol independence. This should mean that the “pseudo voice” contained zero “plain-text”information about the real voice. Indeed we tested the “pseudo voice” with encrypted actual text messages. and these were indistinguishable from real voice calls.

We tracked one of our problems down to differences in Qualcom’s “comfort noise”. This is the noise intentionally added when there is silence in the conversation, it is added to make the call participants realize that the phone is still connected. As you say, it could be that some simple speech rules are being implemented (ahead of their codec) and that our stream violates one or more of the rules. Unfortunately, unlike GSM ,that is fully documented and compliance tested, none of this is really documented for CDMA especially not for Qualcom’s implementation. Qualcom is also notorious for specifying one thing and implementing a superset of the specification. (of course they patent the superset functions)

Anyway that is all ancient history and these days it makes more sense to use the the Data connections to the mobile host. This eliminates all need for LPC transcoding and means that a standard AES stream cypher can be used. That said you still need to first compress the voice with a very low bit rate codec and fill to whiten ahead of the stream cypher.

Clive Robinson • May 10, 2010 3:28 PM

@ Robert,

Even with good documentation from the chip manufacture retro fitting something that was not considered at the design stage will always be a bit problematic.

I’ve a few years at the coal face bending telco chips into crypto products and vic versa, and it is rarely as painless as it should be 8(

The classic problem I’ve seen is a manufacture has a two chip solution which is a pin to pin wire up. They assume that nobody is going to do anything other than the pin to pin wire up and issue new silicon where they move part of the sfcond chip function and put it in the first chip….

99% of their chip users see no problem the 1% doing something other than pin to pin find their inproduction units failing to get off of the production line as they fail test….

One example I was using a DtoA in an upsampler in a Software Defined Radio system so I did not want a lowpass filter at it’s output. the manufacture upgraded their chip steping due to using new wafers they found they had more real estate and put an on chip lowpass in. Great if you are a PC sound card manufacture, not if you are making an SDR TX up converter…

Thankfully the world has moved on a bit and interfaces get better documentation or you find a micro controller with all the functionality built in. (PIC33)

And as you say a nice transparent data pipe is definitely the way to go when you can.

Aka • May 14, 2010 5:48 PM

Who CAN encrypt their phone calls? That’s some serious James Bond territory. I can’t even encrypt my email because then not a single person I know would have the tool to decrypt it. For a phone, you’d need special hardware and keys for it on both ends – yeah right. I don’t even see that stuff sold in spy shops!

As for Skype… the Chinese version had a concession build into it to filter messages through a central server that could read them, didn’t it? Maybe the English one does, maybe it doesn’t… who knows? I guess you’d first have to crack the crypto yourself, then run a packet sniffer to see what goes where and when. If you can do that, it’s a moot point because if you’ve cracked it, any agency that wants to also will have done so.

I treat Skype as “encrypted” (you know, like ROTT13) – Harder to read than not, but after the Chinese version was revealed, it undermined any claims they make about security of their product going forward. If the Chinese gov’t demands an insecure version and they deliver it, then what’s to stop them if the US gov’t did the same?

Nobody Encrypts their Phone Calls

Comments

Leave a comment Cancel reply