Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

26C3: DECT (part II)

Last years talk on DECT (in)security was one of the highlights of my
conference. It also prompted me to grab one of the com-on-air cards and
start playing with DECT a little more. Hopefully this talk gives me
some more fun things to play with in 2010.

What has changed in DECT security after one year

“This talk will provide an update on the security of encrypted DECT
calls (using the DSC cipher), which can currently not be broken by
passive eavesdropping. We will also show what has been done so far to
improve DECT security and what you can do to get a secure DECT system”

GSM cellphones have a lot in common with in-house cordless telephones. The security of both devices were designed by the same group of people, with only a few years between them. They share a number of the same issues as a result.

Communication within the industry has been a lot better with DECT insecurities however, and plans are being discussed on how to make things more secure. The same cannot  be said however for GSM issues.

DECT overview

  • Standard for short range portable phones
  • Frequency 1,9 Ghz
  • Range up to 300 meters
  • invented in 1992
  • more than 670,000,000 devices

Standard of security – 1 year ago

DECT uses two proprietary protocols

  • DSAA: DECT Standard Authentication Algorithm
  • DSC: DECT Standard cipher
  • Both are OPTIONAL!

There are devices in the market the do not use authentication or encrypt.

Project deDECTed.org in 2007/8 jointly worked on disclosing DECT security

  • Reversing DSAA
  • Partial Reversing of DSC
  • Attacks on DSAA, PRNGs and DECT itself
  • Open-source sniffer for DECT PCMCIA card

This culminated in the talk at 25C3 to disclose the vulnerabilities and raise awareness. This talk invoked public interest, resulting in extensive media coverage, and the implementation of a DECT stack for Linux (Patrick McHardy). DECT vendors, BSI and other security companies started engaging with deDECTed.org. The first consumer phones with improves security appear in early 2009 (shortly after the 25C3 talk). These looked to fix some of the more serious issues. Some firmware upgradable phones were also provided with upgrades.

Open implementation of DECT

  • PCMCIA Type III card now supported
  • Additional support for audio codecs
  • Better audio quality

New research

DSC was reverse engineered

  • Similar to A5/1
  • 4 LFSRs, 3 irregularly clocked
  • Output combiner with 1 bit memory
  • 40 Blank rounds – Largest weakness found

DSC can be accessed from the SC14421’s firmware

The level of access granted by the D_WRS state allowed for complete control and debugging of the encryption process. This meant that, like the Legic prime talk, a reverse engineering was possible without the need to look at the silicon. However, they still did, as it was fun.

A5/1 is stronger tan DSC in only one dimension –> in A5/1 there are 100 pre-cipher rounds, compared in only 40 in DSC.

This appears to be a tweak implemented by engineers to improve speed. However this 1 flaw causes serious issues with the encryption and makes it significantly weaker than A5/1. Without this change, the encryption would be significantly better than A5/1 in every way (see slides for a full breakdown)

DSC Cryptanalysis

  • Imagine all the registers would be regularly clocked
  • The internal state would be a linear combination of IV and key bits
  • Two consecutive bits of output cut down the key space by half
  • You can repeat that !
  • However, LFSR’s are clocked irregularly

The use of irregular clocking makes it a lot more secure. However…

You can guess the number of clocks correctly (for 1 register, chances are 12%, for all 3 registers, the chances are 0,2%, which may seem low, but is significant). Access to 500,000 different keystreams reveals the key in 1 day on a PC  using a fast GPU. Full details of this attack will be released mid-January at a Cryptographic conference.

Using the C-Channel (A-Field) (to gather keystream data)

A-Field is ony encrypted when C-Channel data is present

The base station is responsible for updating the handset through C-Channel data. The C-Channel transports :

  • Dial Strings
  • Display updates
  • Keys pressed on the numpad
  • RSS newsfeeds

This provides lots of guessable plaintext, and can provide the 500,000 required keystreams with in 24h.

Using the B-Field (to gather keystream data)

B-Field transports voice data

  • Very hard to guess, except if there is silence or the B-Field is unused
  • Mute one end of the communication !

3 hours silence is enough to generate the required data.

Other Problems

  • DSC key only depends on random numbers sent by the FP
  • Phones create guessable B-fields


For the user :

  • Restrict to short calls
  • Avoid silence

For the manufacturer :

  • change the key during the call
  • Avoid guessable content in C-Channel
  • Replace the algorithm

Next Generation of the DECT standard

  • ETSI and the DECT forum are now working on a new standard
  • deDECTed helped where possible
  • Changes will be made in two stages – Short-Term fixes, Longer-Term redesign
  • The new standards DSAA2, DSC2 will be openly published and use established algorithms

Where possible, firmware updates will be made available to fix some issues (such as re-keying, forced encryption, …)

A set of security requirements will be standardized in spring 2010. Phones implementing this will be certified.

More information can we found :

Some publications released in 2009 in regards to DECT security :

  • “Security of Digital Enhanced Cordless Telecommunications” by Alexandra Mengele (PDF)
  • “An efficient FPGA Implementation for an DECT Brute-Force Attack Scenario” by Kei Ogata (Article)

One response to “26C3: DECT (part II)

  1. Pingback: DECT (Phone) Interception made Easy « Bernd Marienfeldt

%d bloggers like this: