before I get into the above title, lets step back, and let me drop a few word about our very first practical attack against DECT.
impersonating a FP (basestation)
In the DECT standard a mutual authentication between PP (portable part, the "phone") and FP (fixed part, the basestation) is forseen, but it is optional. In all cases we have examined only the PP is authenticated by the FP, but not vice-versa. That means a FP can be sure what PP it is talking to, but a PP is left blind as to whether the basestation is really the one it once was shipped with.
think of a victim's PP which ran out of batteries, is switched off or out of radio range
the victim's FP will still broadcast its identity, the RFPI (radio fixed part identifier)
the attacker takes another FP of her choice and modifies it to broadcast the victim's RFPI
the attacker modifies her FP to accept any PP without authentication
the victim's PP comes back (batteries loaded, switched on or comes into radio range)
the victim's PP will try to find its known FP by RFPI and chooses probably either the first seen, or strongest radio signal
in case the victim's PP decides to use the attacker's FP, the victim lost. All outgoing calls will be sent over the attacker's FP
in case the victim's PP hears both FPs equally loud, the attacker's chance to succeed is 50% (and directional antennas help)
The attack has been proven to be practical in spring 2008. Any further details or implemetaions weren't and won't be released by the dedected.org team.
The attack is possible due to two big fuckups:
the DECT standard enforces that a PP will aways accept unauthenticated/unencrypted FPs/calls. Even if a PP usually does all possible authentications and ecryptions, it will fall to the attacker, as she accepts the victim's PP without all those bells and whistles
the DECT manufacturers seemingly never implemented mutual authentication, atleast for what we have examind
Please, get that fixed!
In this scenario the attacker still has a lot of margin. As mentioned above, directional antennas can help, but the second idea is to jam the original basestation just by radio interference. So our idea in the early stages of the project was to first implement a DECT radio jammer with the com-on-air card. But at that timeframe the com-on-air card was still a big miracle to us, and really being able to use it only started at december 4th 2008. While the com-on-air jammer is technically possible we have never gotten down to implementing it, maybe one bored day we will...
Now back to the title and jamming with gigasets:
During the 25c3 BeF from the POC showed me a litte trick you can do whith almost all Siemens gigasets (or magenta clones):
switch off your gigaset.
press 1 4 7 simultaneously and keep them pressed while powering on again
now by pressing random numbers you will get some nice screen or display tests, which heavily depend on the model you have.
now restart, switch the gigaset off and on again, keeping 1 4 7 pressed, and once the [service] screen shows up, enter 76200. This will lead you to the service menu.
here you can do various stuff, reading the IPUI, SW-version. Interesting is the "Metering mode".
on the right you see
090 : RSSI value of the FP
1 : channel number (0-9)
01 : timeslot number (0-11)
16H : least significant byte of the RFPI
100 : 100-bit error rate in %
this is fun so far, but doesn't jam yet. Now for jamming re-enter the service menu (keep 1 4 7 pressed while powering on, enter 76200), and select SAR from the menu. SAR means "specific absorption rate" and is a measure of the radio emission a device creates. When selecting SAR you will end up in another menu "1 slot"/"1slot low"/"2 slot" or the like... select the "biggest" one. The menu items probably heavily depends on what your phone supports of halfslot/fullslot/longslot/doubleslot/ecomode. Finally you're confronted with another selection fLOW/fCENTER/fHIGH. Select fLOW for jamming channel 0, fCENTER for jamming channel 5, and fHIGH for jamming channel 9.
here's my measurement setup using a spectrum analyzer with a crappy GSM antenna and a recent gigaset
The gigaset guys seem to have gotten the channel/frequency mapping wrong, their fLOW is the highest DECT frequency, their fHIGH is the lowest DECT frequency; DECT channels go from 0-9 starting at the highest frequency, and channel 9 being the lowest frequency. Here's what I measure with the gigaset jammer:
Now if our attacker is lucky she find's the victim's FP in channel 0, 5 or 9. She can also wait until it jumps there. She adds a directional antenna to her crappy old gigaset, pointing to the victim's PP, and is much more efficient with the above attack.
For the first time in almost a decade I contributed more than "being there and having fun" to the annual CCC conference in Berlin. We held a talk on DECT, the out-of-the-box-it-works standard for cordless home phones, being widely spread in Europe an Asia.
We could show that pretty much of the phones out there are completely unencrypted, and can be intercepted by a 20Euro Laptop card, and a linux driver and toolset that krater and I hacked up within the last months. On top of this the cryptographers of our team could show up various weaknesses in the remaining encrypted setups:
impersonating a basestation, as-in: hijacking all your neighbours phones
implementation weaknesses in the random number generator of various manufactureres, as-in: doing phonecalls on you neighrbour's installation
cryptographic attacks on the key-exchange algorithm between a base-station and a handset
direct attacks on the stream cipher which is supposed to keep your privacy during a phonecall
All-in-all we hopfully communicated that you'd better not use your cordless phone for any purpose. If you try to resist feel yourself manipulated by what you read here, and better know: they're all listening!
Now one of our main intents and expectations from what we did is that we all can buy really secure cordless phones within a year from today in our favorite supermarket.
the (probably incomplete) catalogue of demands to the DECT industry includes:
AES, blowfish, serpent, or some other publicly worn-off robust cipher for the phonecall
RSA, ElGamal, ECC, or some other publicly worn-off robust key exchange between basestation and handset
mutual authentication, that means both the handset and the basestation cryptographically know who they're talking to, not as today where a victim's handset will happily accept talking to a hacker's fake basestation
perfect forward security. PFS means that even if an eavesdropper records your encrypted calls for days and nights, then intrudes to your home and steals the phone to recover key material, with all skills (s)he may not recover your recent phonecalls
a clear (although technichal) display to the user which key-exchange and which stream-cipher is currently being used. Maybe being a lock icon in the display, which one can gater context information about
DECT is just another proof that security by obscurity does not work. So much of CCC's work ends up just in this one mantra "security by obscurity does not work". So now everybody stand up and say it loud "security by obscurity does not work".
back to the fun part of Berlin's visit:
a dect-sniffer in Berlin, still hiding behind the balustrade
a dect-sniffer in front of the chinese embassy, I do admit they have the better antennas (top right)
a dect-sniffer not so much hiding in Berlin on Jannowitzbruecke, heading for 25c3
This time I went to Berlin by ICE, the fast german trains. And those trains run some kind of DECT installations, I saw three basestations in both of the ICEs going to Berlin and back, and they had sequential RFPI numbers.
The board personel seems to use the installation for communication using normal handsets, the recordings show B-fields in normal fullslots, and no encryption. But then exactly at the moment an announcement over the ICE speakers started, my tools began recording a new pcap file with double-slots.
So seemingly the ICE board speakers can be controlled using DECT, and the audio is some kind of high quality wideband audio codec which is being transported in DECT doubleslots, i.e. using twice the bandwidth of normal DECT calls.
As of now our tools only support one type of audio codec, the widespread G.721/G.726 ADPCM codec. So if you're into codecs or the DECT story, get the file
and try your best to get some audible fragments out of it. This will only work like 50%, as our driver firmware currently cuts off reception after the length of a fullslot. So if you want to contribute, try to get that running, this would be a high motivation for us to really support doubleslots in the firmware, too.
To read the DECT standard in all of its glory go to ETSI.org, register by email, and download all EN 300 175-[1-8] standards.
Not all ICEs have such high quality wideband audio DECT doubleslot installations. Some announcements come in crappy telephone quality:
after pausing for one year I am back at 25c3 the annual CCC conference in Berlin between Xmas and New Year.
So far it's been very nice to meet up with friends and people I work with for some time now. The last two month I was busy getting the Dosch+Amand DECT card to do something useful. And it seems we're getting somewhere.
There will be a talk on day 3 at 17.15h in Saal 1, and its simply named "DECT". We'll have fun with the protocol, its security, and yes, we'll have quite a bunch of open-source code going public after tha talk. For now we keep our stuff still under the hood on dedected.org.
If you're around and want to meet me, my DECT number is 6299, "mazz". We'll see if that one still works after the talk :P
DECT today is seldomly found in the context of PCs. One of the few solutions out there is a Com-On-Air PCMCIA card, originally manufactured by Dosch+Amand, today solely sold by ARC Computer.
They're designed to be used with a Windows software, which then turns the PC to a DECT-VoIP (SIP) gateway.
I got my self one of the Type III and one the Type II PCMCIA cards, but figured out that there's no Windows around here. I hope to get something working on that card under linux, and I can think of more than only a DECT basestation.
As there's no public documentation for the DECT-baseband processor, I probably have to do some (and learn!) reverse-engineering to get linux-support. For now I had a look at the Windows drivers using the HT Editor which seems a brilliant (free) way to reverse-engineer all sorts of Win-SW (and even VxD LE driver binaries) under other OSes.
The CR16 CPU in the baseband processor can be programmed using AS.
- National Semiconductor PCMCIA/PCcard interface PCM16C010 (datasheet, local copy)
- National Semiconductor DECT-baseband processor SC14421CVF, contains a CR16 CPU (no public documentation, share your knowledge!)
- 2kByte microwire EEPROM 93LC86, organized as 1k*16 (datasheet, local copy)
- 512kByte Flash PAI001, only on the Type III card (no datasheet either)
- HCT04 hex inverter
- analog radio Type III card: LMX3161 radio transceiver (datasheet, local copy)
- analog radio Type III card: 2205AF .5W RF power amp
- analog radio Type II card: didn't look at the (availability of datasheets of) devices yet
- only Type III has a LED
If you happen to know anything about
- the DECT baseband chip SC14421CVF or others from the SC144xx family
- the flash PAI001, and why it is only on the Type III card
- the SW architecture/split of the Windows SW that comes with the cards
- any open source driver using the PCM16C010 PCMCIA/PCcard chip (OK, it's documented, but ...)
please contact me and share your knowledge.
com-on-air Type III card HW porn:
top side overall:
DECT baseband controller:
bottom side overall:
flash and EEPROM:
com-on-air Type II card HW porn:
top side overall (bottom side has no components):
Type II digital chipset (only differs from Type III in that it has no flash)
radio (all different than on Type III):
Update: the "512kByte Flash PAI001" was identtifies as hex inverter.