Objets connectés : polémique sur la sécurité du réseau français Sigfox
Une étude montre que Sigfox, le principal réseau d’interconnexion d’objets connectés, ne chiffre pas ses données et qu’il est vulnérable aux attaques par usurpation. Pour autant, le fournisseur estime qu’il n’y a pas péril en la demeure et qu’il existe des solutions.
Des alarmes qui indiquent une intrusion alors qu’il n’y en pas, des panneaux publicitaires et des vélos en libre-service qui signalent des avaries imaginaires, des vannes qui s’ouvrent sans crier gare… Tous ces scénarios plus ou moins graves pourraient bien survenir un jour dans le monde fabuleux des objets connectés, et pas dans n’importe lequel : celui de l’entreprise française Sigfox. En effet, l’étoile montante de l’Internet des objets, qui couvre d’ores et déjà l’intégralité des territoires français et espagnol et qui relie plus de 7 millions d’objets connectés dans le monde, a effectué des choix technologiques contestables au niveau de la sécurité de ses transmissions.
C’est ce qui ressort, en tous cas, d’une étude de sécurité indépendante qui a été réalisée par Renaud Lifchitz, consultant chez Digital Security. Ce rapport a été présenté le 8 mars 2016, à l’occasion de la Journée de la sécurité des systèmes d’information (JSSI), un évènement organisé par l’Observatoire de la sécurité des systèmes d’information et des réseaux (OSSIR).
Ce travail d’analyse montre que les transmissions radiofréquence entre les objets connectés et le réseau Sigfox ne sont pas chiffrées et qu’elles peuvent être lues par n’importe qui au moyen d’un ordinateur muni d’une antenne à 15 euros. Et cela à plusieurs kilomètres à la ronde, étant donné la grande portée des transmissions (20 km en ville, 300 km en rase campagne). Dans les messages, les objets connectés sont clairement identifiés par un code sur quatre octets, permettant de facilement tracer les communications.
Plus grave : un pirate disposant d’un accès physique pourrait usurper l’identité des équipements. Il pourrait ainsi s’arranger pour envoyer des fausses alertes vers le réseau Sigfox ou, à l’inverse, adresser une fausse commande aux objets connectés.
Possibilité d’extraction de clé
D’où proviennent ces vulnérabilités ? Elles sont intimement liées à la technologie que Sigfox a développée. Celle-ci ne prévoit aucun dispositif de chiffrement des messages au niveau du réseau. « Un développeur qui souhaiterait ajouter du chiffrement dans les échanges devra le faire lui-même. L’interface de programmation de Sigfox ne propose rien », souligne Renaud Lifchitz.
La possibilité d’usurpation, quant à elle, est liée à la manière dont se passe l’authentification des messages. Chaque trame dispose d’une signature baptisée HMAC qui résulte d’un calcul réalisé à partir d’une clé secrète AES 128 bits intégrée dans le module Sigfox de l’objet connecté. Mais il est possible d’extraire cette clé à partir du moment où l’on a un accès physique ponctuel, en branchant un logiciel de débogage. Une fois cette clé récupérée, un attaquant peut très bien forger ses propres messages, du réseau vers l’objet et inversement.
Côté Sigfox, on ne remet pas en question ces conclusions. Concernant l’usurpation, le fournisseur estime que de telles attaques seraient assez laborieuses à mettre en œuvre. Néanmoins, il envisage de proposer à l’avenir des modules Sigfox avec puces sécurisées (« Secure Element ») permettant d’éviter toute extraction de clé. « Mais ce ne sera pas obligatoire. Ce sera à la demande du client », souligne Raoul Mallart, vice-président innovation chez Sigfox.
L’absence de chiffrement, en revanche, est plutôt assumée. « Nous avons pris le parti de laisser la responsabilité du cryptage au client, qui est mieux à même de juger s’il a besoin de chiffrer ses messages et de quelle manière. Les messages d’un pot de fleur connecté n’ont pas forcément vocation à être chiffrés. Pour les messages plus sensibles, le client peut ajouter une couche de chiffrement au niveau applicatif. Celle-ci, du coup, sera même de bout en bout », explique Raoul Mallart, vice-président innovation chez Sigfox.
L’art du compromis
La solution du chiffrement applicatif a également été identifiée par le consultant de Digital Security, mais avec un bémol. « Comme le développeur n’a pas accès par l’API (interface de programmation) à la clé enfouie dans le périphérique, il doit mettre en oeuvre une seconde clé secrète dans l’objet connecté pour assurer ce chiffrement applicatif. Cette clé sera toute aussi exposée que l’autre si on n’utilise pas de Secure Element. Il y aurait donc, quoiqu’il arrive, besoin d’un Secure Element, ce qui a un coût pour un objet connecté. Et si on veut faire les choses vraiment bien, il faudrait créer une clé différente pour chaque objet, ce qui implique un effort de gestion important pour l’intégrateur de la solution », ajoute Renaud Lifchitz. Celui-ci préconise une solution intermédiaire : un chiffrement à clés jetables, dérivé de la clé de Sigfox et appliqué au niveau du réseau. « C’est une bonne idée, concède Raoul Mallart. Cela ne résout pas tous les problèmes potentiels, mais pourrait être une solution judicieuse dans certains cas. »
Au final, on voit bien qu’il n’y a pas de solution miracle. Certains mécanismes du réseau Sigfox sont bien implémentés et assurent résilience et intégrité des communications. Mais la confidentialité a été négligée au profit d’une bonne disponibilité du service. Mais ce n’est étonnant qu’à moitié, car le domaine des objets connectés comporte, par nature, de fortes contraintes techniques et économiques (autonomie, longueur des messages, durée d’émission, portée, prix, disponibilité…). Le niveau de sécurité sera forcément le résultat d’un compromis global en fonction du risque envisagé. Il faut espérer que les clients de Sigfox auront fait le bon choix au regard de leurs usages… et de leurs propres clients.
