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

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

Tag Archives: DECT

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

Countermeasures

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)

Upcoming DECT Talk

For those of you that follow my insane ramblings no a regular basis might just remember some posts I’ve made about DECT interception. As part of my ongoing interest in this area I’ve been keeping an eye on the dedected.org site and the researchers responsible for reversing parts of the DECT standard. Although not much has moved since the December 2008 software release and initial research, RalfPhilipp Weinmann (University of Luxembourg) will be making a presentation at the upcoming EUSecWest 2009 in London (27/28 May). The talk, entitled Efficient UAK Recovery attacks against DECT”, seems to hint at possible advances to the project. The UAK (User Authentication Key) is a 128bit key used in the pairing process to Authenticate the PP (Portable Part). Although this isn’t the point we’ve all been waiting for (an attack on DECT Standard Cipher), it does represent the next step forward and could open the door to easier Man in the Middle type attacks. It could also allow attackers to connect to internal DECT systems and route calls through internal call switches. Great for free calls, social engineering, or maybe gaining access to restricted services (modems on listening on internal extensions, voicemail systems, etc..). At the moment this is all speculation however. It’s a pity I can’t be at EUSecWest (I’m already doing too many conferences this year). However I’ll be keeping an eye on the slides as soon as they’re made public.

At present the dedected.org team have released software that allows for capturing unencrypted DECT telephone calls only. This doesn’t mean that encrypted calls can’t be captured, it simply means that they cannot currently be decoded into anything that makes sense. There is the chance the previously captured encrypted calls could be attacked and decoded in the future.

That not withstanding, I doubt that the dedected.org team will be releasing anything new to decode encrypted traffic in the short term. At this stage they’ve already exposed the weaknesses in DECT, and without a solution to the issue, releasing a tool that captures and decodes encrypted traffic would only put individuals and companies using encrypted DECT in danger. That’s not to say their won’t be something in the mid to long term.

To prevent exposure, companies should start looking (if they’ve not already started) at alternative options to DECT telephones and headsets. VoIP seems like a viable alternative if it’s implemented over VPN or other secure channels. Only time will tell if this is the direction that people head however.

DECT Interception

dect_cli

dect_cli

I’ve been playing about with the com-on-air and tools from dedected for a few weeks now. Results are mixed, as those who’ve sat through eth few demos I’ve run can certainly attest to. Things are still in the early phases for the dedected tools and as much as I love what’s already there, it’s not really ready for the mainstream yet. Don’t get me wrong, whats been done is already amazing work, but for the penetration testers amongst you wanting to grab a com-on-air card from ebay and starting running tests, things aren’t always going to be 100%. Still, it makes managers sit up and pay attention if demonstrated correctly.

As an example of the issues, I’ve build the drivers and tools from source on 3 or 4 systems now (Fedora, Debian, and Backtrack 3 and 4). Compiling resulted in mixed results (some compile errors) and random capture failures (just capturing static as if the course was encrpyted). You’ll also probably get a few kernel panics before you learn to respect the driver and not expect hotswap support just yet. After one too many hit and miss captures from the compiled versions, I opted to go for the Chaox-ng boot USB which includes everything (yes I do mean everything) built in. I find that this USB boot option just adds to the effect when it comes to demos. You turn up with a PCMCIA card and a 1 GB USB stick. That and any laptop will do the job.

Wireshark SVN

Wireshark SVN

The Chaox-ng distro includes the drivers and tools compiled to perfection (no capture issues here). The latest version also includes the SVN version of Wireshark (with DECT PCAP support). Kismet newcore is compiled in with the DECT plugin if you want to play about with this as well. About the only thing missing is the Metasploit auxiliary modules, but that always was just a Proof of Concept and not very functional. Personally I stick to using the ‘dect_cli’ tool (alongside pcapstein, pcap2chan and Wireshark). For those that are interested I’ve uploaded a few packet captures for you to take a look at.

Plantronics CS60 Captures (Encrypted B-Channel)

Siemens GIGASET (Unencrypted B-Channel)

  • German Test Call (pcap) — HERE
  • German Test Call (g721, wav) — HERE
kismet-newcore

kismet-newcore

The Plantronics PCAP’s are interesting to look at and see how the communications between the base unit and headset are handled. At this point I’ve not looked too much into the encryption implmented. From a couple of test calls the Plantronics appears to initiate the call and then encrypt a fraction of a second after the call begins. I’m leaning towards a standard implementation of DSC (DECT Standard Cipher) instead of a propriatary Plantronics implementation. Pity, as I was hoping for something in the pairing process that would signal a handshake and key creation process. I’ll leave the encyption work to people much smarter than me however. I just like to play with the new toys 😉

DSAA (DECT Standard Authentication Algorithm) has already been reversed (see details here and the paper on the subject here). So next up will be the DSC hopefully. We’ll have to see how much longer the “Security through obscurity” of DECT works. I hope, for their sake, that they’ve implemented defence-in-depth 😉

Playing with DECT Phones

Thankfully December is over and done with, and it’s a new year. December was very chaotic (pun intended), with both the SANS London event, and the 25C3 in Berlin. Both were great, and both were covered with varying success in posts on the blog. Sorry if the posts from 25C3 came off a little odd, most were general observations written while in presentations using my laptop (when it had a battery) or my blackberry (when I didn’t accidentally delete them). Still, I hope you got something good out of it the comments at least.

One presentation I missed at 25C3 was the DECT talk from the team at unDECTed.org. Although most of the press has been on the MD5 Certificate issues, the DECT presentation also showed that things we take for granted (i.e. closed source encryption and devices in general) are not as secure as we like to think. I’ve order one of the COM-ON-AIR PCMCIA TYP II cards to have a play around myself. So look out for an update coming soon 😉