[ARTICLE] Sécurité de Sigfox

Présentation de la technologie Sigfox

Sigfox est une technologie sans fil propriétaire développée par la start-up française éponyme. La technologie fonctionne sur des bandes radio libres, dédiées aux usages civils, appelées bandes ISM (pour bandes « Industrielle, Scientifique et Médicale »). En Europe, cette bande se situe aux alentours des 868 MHz, et autour de 915 MHz aux Etats-Unis. Sigfox est un protocole qui fonctionne en bande étroite UNB (« Ultra Narrow Band ») pour permettre la cohabitation de nombreuses communications simultanées. Il est à basse consommation, longue portée (de quelques kilomètres en ville à quelques dizaines de kilomètres en campagne) et bas débit (100 bits par seconde et jusqu’à 12 octets sont utilisables en liaison montante), ce qui en en fait un bon candidat pour des usages IoT.

Sigfox couvre la grande majorité du territoire français, avec environ 1500 antennes déployées. D’autres pays européens comme l’Irlande, le Luxembourg, le Portugal, l’Espagne et les Pays-Bas, sont eux aussi complètement couverts. Certains pays sont en cours de couverture par l’opérateur : Australie, Belgique, Brésil, Royaume-Uni, République Tchèque, Danemark, Finlande, Italie, Ile Maurice, Nouvelle-Zélande, et Etats-Unis.  Sigfox ne couvre pas par lui-même l’essentiel des pays à l’étranger. Pour cela, il s’appuie sur des opérateurs partenaires dans chaque pays couvert, appelés SNO (« Sigfox Network Operators »). Une carte de la couverture de Sigfox est proposée sur http://www.sigfox.com/coverage .

Principalement conçu pour être unidirectionnel, il peut toutefois être utilisé en mode bidirectionnel sur demande, de manière opportuniste, par l’envoi de trames spécifiques demandant un acquittement du réseau. Après une courte émission, le périphérique se met alors en écoute pendant un temps court pour récupérer un message descendant du réseau (8 octets sont utilisables).

La récupération des messages envoyés par les périphériques se fait de manière centralisée, soit sur l’interface dédiée de Sigfox, appelée « backend » (https://backend.sigfox.com), soit sur le backoffice dédié d’un intermédiaire Sigfox. Il est possible sur ces interfaces de définir des callbacks métiers, par exemple pour faire des requêtes Web Services automatisées en fonction des messages reçus par une flotte de périphériques Sigfox.

La bande ISM est libre d’usage mais est toutefois soumise à des restrictions légales d’utilisation. En Europe par exemple, un périphérique sur la bande des 868 MHz ne peut émettre plus de 1 % du temps. Cette contrainte légale ne permet, en moyenne, que l’émission d’un message toutes les 10 minutes. Pour cet usage, et pour un seul périphérique Sigfox, l’abonnement annuel est d’environ 10€ par an.

Contexte de l’étude

Le protocole étant propriétaire, il n’existe pas de spécifications publiques de Sigfox, à l’exception de trois documents publiés à l’ETSI en septembre 2014, après diffusion de la technologie, et portant sur les réseaux à bas débit LTN (« Low Throughput Networks »). Ces spécifications, moins techniques que fonctionnelles, ne sont d’ailleurs pas tout à fait conformes au protocole Sigfox lui-même et sont davantage une base de travail pour une normalisation future des protocoles IoT bas débit (documents ETSI GS LTN 001-003 V1.1.1 2014/09).

Dans ce contexte, et suite à de nombreuses demandes de nos clients et prospects concernant la sécurité de Sigfox, nous avons décidé de mener une étude indépendante sur le sujet pour établir quelles sont les fonctionnalités de sécurité exactes de la technologie. Nous avons utilisé deux approches différentes pour sa réalisation : une étude par rétro-ingénierie du protocole radio et une autre portant sur le micrologiciel (firmware) d’un composant Sigfox.

Analyse du protocole radio

A l’émission d’un message Sigfox, 3 trames différentes sont en réalité émises (cf. figure 1) utilisant 3 fréquences légèrement différentes et suivant aussi 3 codages différents.



Vue en chute d’eau de l’émission d’un message Sigfox

La modulation utilisée est une modulation par changement de phase (BPSK), et 100 bits sont transmis par seconde (cf. figure 2).


Forme d’onde en représentation réelle temporelle

Analyse du micrologiciel

Pour notre étude, nous avons utilisé une carte de développement Sigfox de type Arduino, comprenant un SOC (« System On Chip »)  avec un module radio Si4461 et un processeur ARM Cortex-M3. Cette carte a été interfacée matériellement avec 2 dongles USB, un dongle série UART pour le pilotage opérationnel du module Sigfox (envoi de trames), et un dongle SWD pour le débogage de ce module (mise en pause et récupération des mémoires flash et RAM). L’ensemble matériel est présentée en figure 3.


Extraction de la mémoire d’une carte Sigfox

Nous avons choisi de piloter le débogage du module à l’aide du logiciel Open Source OpenOCD. Les entêtes de développements fournies dans le kit de développement ont été utilisées pour identifier les plages et structures de mémoire intéressantes dans les captures. L’extraction de mémoire a permis de récupérer 128 Ko de mémoire flash et 16 ko de mémoire RAM, que nous avons pour l’essentiel analysés avec le logiciel IDA Pro.

L’analyse radio et l’analyse du micrologiciel combinées ont permis de déterminer le format exact d’une trame Sigfox en liaison montante. Cette structure est exposée en figure 4.


Structure d’une trame Sigfox en liaison montante

Fonctions de sécurité de Sigfox

Redondance / résistance au brouillage

Pour résister au brouillage volontaire ou involontaire lié à l’environnement, Sigfox envoie donc chaque message sous forme de 3 trames sur 3 fréquences différentes, avec 3 codages binaires différents, pour minimiser les chances que les 3 trames soient altérées à leur réception. Par ailleurs, le matériel homologué par Sigfox possède un bon niveau de sensibilité, par exemple -125 dbM sur notre périphérique de test. Nous avons par contre constaté d’importantes différences de réception à l’intérieur et l’extérieur des bâtiments. En intérieur, il est préférable d’émettre à proximité de fenêtres pour avoir l’assurance que les messages soient bien reçus. Pour des applications critiques, il faudra veiller à sélectionner des périphériques avec un haut niveau de sensibilité.

Intégrité

Pour vérifier l’intégrité des messages reçus, en plus de leur redondance par émission multiple, Sigfox utilise un code détecteur d’erreur (FCS : « Frame Check Sequence ») sur 16 bits. Nous avons pu déterminer dans notre étude qu’il s’agissait d’un CRC CCITT / XMODEM avec des valeurs d’initialisation et de sortie nulles. Ainsi, un message corrompu a de très fortes chances d’être détecté non valide. De plus, un code d’authentification MAC est utilisé pour authentifier la trame, et joue aussi le rôle de détecteur d’intégrité.

Mécanisme anti-rejeu

A chaque envoi de trame Sigfox, un compteur de trame est incrémenté dans la mémoire flash du périphérique, et le réseau garde la trace des numéros de trames reçus. Un même message réémis est ignoré par le réseau. Sigfox possède donc bien un mécanisme anti-rejeu. Grâce à cette traçabilité, le réseau est même capable de donner le nombre de messages émis mais non reçus, par exemple en zone de non-couverture.

Authentification

Chaque périphérique Sigfox possède son propre identifiant unique de 32 bits, qu’il inscrit dans toutes les trames qu’il émet. Ainsi, il est possible d’identifier le périphérique précis qui a émis une trame en particulier. On peut s’interroger sur le pourquoi d’un identifiant IoT sur seulement 32 bits (4,3 milliards d’objets maximum), alors qu’on parle de plusieurs dizaines de milliards d’objets connecté dans quelques années. Il y a fort à parier que le protocole évoluera en augmentant la taille de ce champ si Sigfox se déploie massivement.

Pour ce qui est de l’authentification, une clé symétrique de 128 bits est enfouie dans chaque périphérique lors de sa fabrication et sert à authentifier chaque message transmis. L’authentification des messages se fait par un code MAC de 16 bits, qui est le résultat du calcul d’une partie de la trame chiffrée en AES-128-CBC, auquel on ne garde que les 2 premiers octets du dernier bloc. Ce chiffré englobe le compteur de trames, ce qui fait que les messages ne sont pas immédiatement rejouables.

Chiffrement

Le protocole Sigfox n’est pas chiffré, toutes les données envoyées sur le réseau sont envoyées en clair et potentiellement interceptables dans le rayon d’émission du périphérique (quelques kilomètres). L’interception peut se faire avec très peu de matériel, nous en reparlerons dans la partie « Vulnérabilités résiduelles et risques ». Il est dommage que les modules Sigfox n’intègrent pas un chiffrement natif et transparent pour l’utilisateur car ils intègrent déjà tous une implémentation de l’algorithme de chiffrement AES-128 et une clé de 128 bits enfouie, tous deux utilisés pour l’authentification des trames.

Portabilité entre intermédiaires Sigfox

Sigfox dispose de plusieurs partenaires pour la commercialisation d’abonnements à son réseau, et ne facture en général pas directement les particuliers et les petites PME. La facturation passe donc parfois par des intermédiaires de facturation, et il est même possible de passer d’un intermédiaire à un autre. Pour ce passage, il est nécessaire, à l’instar des réseaux mobiles traditionnels, de fournir un code de portabilité demandé à l’ancien intermédiaire, et donné au nouveau, sur le même principe que le code RIO mobile. Dans le cas de Sigfox, ce code de 16 chiffres hexadécimaux (8 octets) est appelé le PAC (« Porting Authorisation Code »), et est renouvelé à chaque portabilité.

En principe il est absolument nécessaire de posséder le PAC pour migrer d’un intermédiaire Sigfox à un autre. En pratique, il nous a été possible de demander à Sigfox un rattachement de facturation propre sans PAC, ce qui montre que ce code PAC n’est pas cryptographiquement nécessaire et qu’il est renouvelable par Sigfox en cas de besoin.

 

Vulnérabilités résiduelles et risques

Nous avons relevé principalement quatre vulnérabilités :

Comme nous l’avons vu, les trames sont envoyées en clair et sont donc captables avec un équipement radio adéquat, tels que les clés USB de réception TV TNT basé sur le chipset Realtek RTL2832U (cf. http://hakshop.myshopify.com/products/software-defined-radio-kit-rtl-sdr), périphériques qui connaissent un certain succès actuellement. Très accessibles, autour de 15 euros, elles permettent en réalité de capter les fréquences de 50 MHz à 2200 MHz environ, ce qui en font des outils d’audit déjà très accessibles et très puissants. Ecouter le protocole Sigfox n’est donc pas coûteux pour l’attaquant.

Une vulnérabilité importante pour les systèmes commandés à distance est le fait que les trames sont en partie rejouables. En effet, bien qu’un système anti-rejeu soit présent, il englobe en réalité un compteur de trames sur seulement 12 bits, ce qui fait que les messages et leur signature sont rejouables tous les 212 bits = 4096 messages. A raison d’un message émis toutes les 10 minutes, le compteur de trame boucle en à peine plus de 28 jours, donc les messages et leurs signatures émis pendant un mois redeviennent valides le mois suivant, puis à nouveau le mois suivant et ainsi de suite.

Aucun des périphériques Sigfox actuellement commercialisés n’est muni d’un « Secure Element », ce qui fait que leur clé d’authentification n’est pas correctement protégée. En effet, une clé est provisionnée en usine lors de la fabrication du périphériques Sigfox, et elle est stockée dans une partie de la mémoire flash du périphérique, partie de la mémoire non adressable par l’utilisateur mais accessible par le firmware. Lors de son utilisation, la clé d’authentification est copiée dans la mémoire vive du périphérique, ce qui fait qu’elle se retrouve exposée par un attaquant qui aurait un accès physique ponctuel au périphérique par une interface de débogage ou de reflashage du périphérique. Un accès physique ponctuel à un périphérique Sigfox permet donc d’extraire cette clé de 128 bits puis d’usurper ad vitam æternam le périphérique en émettant des messages arbitraires à sa place.

Enfin, les périphériques transmettant leur identifiant de 32 bits en clair, tous les messages Sigfox émis sont identifiables et rattachables au périphérique qui les a émis. Il est ainsi aisé de connaître tous les messages émis par un périphérique en particulier, lors d’une écoute.

Recommandations de développement et d’intégration

Dans tous les domaines de l’IoT, en raison de contraintes technologiques liées aux capacités des objets communicants, des compromis en termes de sécurité sont nécessaires. Il est donc particulièrement important d’analyser au cas par cas l’environnement de fonctionnement de Sigfox pour adapter le niveau de sécurité selon l’usage qui en est fait, à travers une analyse de risque consciencieuse.

Si des données sensibles sont manipulées (d’un point de vue confidentialité ou disponibilité), il est souhaitable de redonder Sigfox, soit au niveau protocole sans fil, soit au niveau applicatif. Pour la confidentialité, nous conseillons de chiffrer les données. La difficulté réside dans le fait que les données sont de petite taille (12 caractères tout au plus), et donc de taille inférieure à la taille de bloc des algorithmes de chiffrement symétrique qui sont à l’état de l’art. Il n’est donc pas possible d’employer un système de chiffrement par bloc robuste, ce qui ferait grandir la taille de la trame. Une possibilité est d’employer un système de chiffrement par flux avant d’envoyer la donnée, tout en introduisant une nouvelle clé dans le système (car la clé enfouie existante n’est pas facilement accessible au développeur) et en assurant sa sécurité, ce qui n’est pas simple. Concernant la non-usurpation, nous conseillons d’ajouter un ou deux octets au compteur de trames existant, en les consommant sur le contenu utile de 12 octets, de manière à rendre difficile la réutilisation de messages signés. Les experts de Digital Security sont à votre disposition pour vous accompagner dans l’étude de vos besoins de sécurité IoT.