Cryptanalysis of the DECT

New cryptanalysis of the proprietrary encryption algorithm used in the Digital Enhanced Cordless Telecommunications (DECT) standard for cordless phones.

Abstract. The DECT Standard Cipher (DSC) is a proprietary 64-bit stream cipher based on irregularly clocked LFSRs and a non-linear output combiner. The cipher is meant to provide confidentiality for cordless telephony. This paper illustrates how the DSC was reverse-engineered from a hardware implementation using custom firmware and information on the structure of the cipher gathered from a patent. Beyond disclosing the DSC, the paper proposes a practical attack against DSC that recovers the secret key from 215 keystreams on a standard PC with a success rate of 50% within hours; somewhat faster when a CUDA graphics adapter is available.

News.

Tags: , , , ,

Posted on April 8, 2010 at 1:05 PM • 24 Comments

Comments

Nobody Special • April 8, 2010 1:40 PM

The paper doesn’t make clear what a keystream is and how often it’s sent.
Is it once each time somebody on the phone speaks?

So how signficant it is depends on if 2^15 keystreams represents a few seconds of call time or requires you to log every packet from the phone for days.

arclight • April 8, 2010 2:13 PM

It’s not terribly surprising that there would be problems with an algorithm which was:

  1. Developed in secrecy by non-cryptographers who did not have their work peer-reviewed
  2. Optimized for low-cost implementation

I’m pleasantly surprised that the system isn’t more broken. What remains to be seen is how the various vendors implement it – i.e. poorly seeded/implemented PRNG, leaking of some or all of the key into the communication, etc.

When it comes down to it, an algorithm that can withstand a few hours of cracking on a PC is probably sufficient for this rather low-security application.

Arclight

Tony H. • April 8, 2010 2:35 PM

It’s interesting, but I doubt there’s any practical significance. Almost certainly the kind of cheap components used in a fairly low end consumer item will lead to all kinds of side emissions, modulation of the carrier with the analogue signal, power supply leakage, etc. etc. that are at least as easy to snaffle as decrypting the digital data stream. We programming types tend to analyze/attack what we know, but there are often easier ways.

Bob • April 8, 2010 4:34 PM

Am I the only one getting a certificate error on the pdf site? It says it’s signed by cacert.org, but I’ve already imported the cacert root certificate and it still says it’s an unknown authority. Weird…

Erik Tews • April 8, 2010 5:17 PM

Hi

A keystream is send once per 10 ms in DECT by every device communicating. This allows you to recover at most 100 keystreams per second with a normal conversation. However, the first 40 bits of the keystream are only used to encrypt control traffic. If there is currently no control traffic, these 40 bits are not used. So if you are interested in recovering keystreams including their first 40 bits, you might perhaps only be able to recover 5 keystreams a second or less.

Unix Ronin • April 8, 2010 5:28 PM

Bruce,

This is off-topic, but I hope you’ll forgive me that. I want to call your attention to a C|Net article, http://news.cnet.com/8301-11386_3-20002029-76.html, talking about HP’s memristors, and in particular about a recent realization by HP that the memristor is capable of far more than they had initially thought. In particular, they’ve discovered that a memristor device can process data as well as store it, and are speculating about the potential for a machine that does not have a distinct CPU, but instead has its processing capability built into its memristor-based memory cells and does its processing right there in the memory, effectively an embedded CPU distributed across the entire memory space. This would be taking the concept of massively parallel architectures one step further; I’ve taken the liberty of penciling in the term “fully parallel architecture” for the concept. (I’ve posted some preliminary thoughts on the subject at http://unixronin.livejournal.com/740822.html.)

I’d be very interested to hear your thoughts on this and its potential impact on cryptography.

wumpus • April 8, 2010 6:13 PM

@Tony H.

While you would ordinarily assume that anyone willing to use cryptanalysis on a captured wireless signal could in this situation capture the audio signal with less difficulty, I think that this is likely going to lead to nosy neighbors trolling through phone messages with a downloaded app.

Anyone want to make make an app that does that and then alerts the police to what you are doing?

Daniel • April 8, 2010 6:33 PM

@wumpus.

The problem isn’t the programming. The problem is that the necessary hardware for sniffing is difficult to come by. It used to be that DECT cards went for $10. Starting last year they can now sell upwards to $500 each on eBay; assuming you can find one. I just checked and none are for sale in the USA.

So I don’t think one has to worry about a rash of nosy neighbors.

Seiran • April 8, 2010 7:40 PM

@Daniel

Given the widespread availability of software-controlled radio boards, I’m surprised the DECT cards are selling for that much.

http://en.wikipedia.org/wiki/Universal_Software_Radio_Peripheral

I would also guess that you can even build your own with some analog hardware and a USB logic analyzer, which will allow you to process the signal coding in software. Most embedded radio cores are made with a DSP chip (the radio chipset) that will decode a specific encoding scheme for you, such as MCS; you add the radio hardware. Companies like Broadcom make these chips.

And, the newer system-on-chips will manage power, output, frequency, and now, they even have the PLL and the antenna embedded right inside.

I’ve never built this kind of hardware myself, but I’m sure there are people who can. (And then of course, they sell this educational hardware as a turn-key solution to wardrivers, “spy shops”, hobbyists and PIs at a profit)

Anton • April 8, 2010 8:05 PM

@Tony H

“It’s interesting, but I doubt there’s any practical significance.”

A few years ago I consulted to a private bank in Switzerland who wanted answers on this very question. Needless to say, the bank did not introduce DECT handsets for their key staff.

GreenSquirrel • April 9, 2010 3:17 AM

@ Bob at April 8, 2010 4:34 PM

No, I get the certificate error as well – I assumed it was some weird artifact of my work PC system setup (IE 7).

Lots of sites have been churning out certificate errors over the past few days (including Virgin Atlantic….)

Simon_c • April 9, 2010 4:14 AM

Isn’t the real risk not that nosey neighbors would listen in on phone conversations, but that anyone sitting outside with a laptop could use your phone line for making calls.
Making calls to premium rate numbers could net them quite a lot of money in just a few hours.

If the DECT boards have gone from $10 to $500 on ebay, that would make me think the crims are onto this already…

Mark • April 9, 2010 5:01 AM

Daniel: those fixes were for the previous attacks. They are currently planning to use a different system, however.

Nostromo • April 9, 2010 7:59 AM

@Arclight “I’m pleasantly surprised that the system isn’t more broken”:

We don’t know that it isn’t more broken. This is just the first attempt at cryptanalysis. There will be more.

aikimark • April 9, 2010 8:24 AM

It wasn’t the conversation snooping that worried me as much as the use of this (now broken) encryption to transmit swiped credit card information to a base station (phone line) in restaurants. If it only takes 10 minutes to break that, then you could start monitoring credit card data by the time your appetizers arrive.

Peter A. • April 9, 2010 8:50 AM

@aikimark: huh?

DECT is basically a wireless interface to the POTS line. Whatever you can get by decrypting DECT link you can also get by simply tapping the line itself. If CC data was sent over the phone line in the clear you’ll be already bankrupt as well as millions others.

BTW, I haven’t seen a single DECT POS on this side of the Great Water, all wireless ones use GSM.

DECT credit card teminal, anyone?

aikimark • April 9, 2010 12:48 PM

@Peter A.

My concern reflects this part of the Register article:
“In others – such as where DECT is used in restaurants and bars to wirelessly zap payment card details – the time needed to crack the key could be dramatically shorter, Nohl said. The time can also be sped up in a variety of other ways, including by adding certain types of graphics cards to beef up the power of the attacking PC. In some cases, the attack can retrieve the secret key in 10 minutes.”

The article doesn’t say anything about the encryption over the POTS, just the wireless in-restaurant data.

===========
“…all wireless ones use GSM.”
One of the related articles’ links covered the cryptanalysis of the A5/1 GSM encryption standard, which should also be considered broken.

mashiara • April 10, 2010 12:54 PM

The credit cards terminals setup end-to-end encryption between the terminal and the payment processor at the bank anyway so cracking the link-layer encryption (DECT or GSM, matters not) is not a problem (also the DECT basestations connect to the unencrypted POTS, so relying on them for “end-to-end” security would be monumentally stupid)

The terminals have other problems though as seen in this blog…

b • April 11, 2010 11:15 PM

@mashiara

Depends where the encryption is performed.

For example, a DECT credit card terminal is likely to be paired with some sort of base station.

Crypto may be processor-intensive, and a portable terminal may offload the encryption to the base station to save battery.

In this scenario, the connection between the terminal and the base station would be encrypted using only DECT.

Oscar Soriano • November 2, 2010 8:41 AM

Hi
Apart from that published in “FSE2010-166.pdf” which is a portion of the code for the decryption of the plots by collecting IVS between the PP and PF. Someone has released this information to complete? scripts, type aircrack-ng for the discovery of the key? or just that people have dedected.org to prevent abuse of the protocol?
Thank you very much

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.