IoT et sécurité : une union impossible ?
S'il est une question qui ne cesse de prendre de l'ampleur dans le domaine de l'Internet des Objets, c'est bien celle-ci :
L'IoT a-t-il un avenir malgré son manque inhérent de sécurité ?
Les études montrent qu'en dépit du constat évident que cet écosystème est rempli de failles de sécurité qui peuvent mettre en péril leur fonctionnement, l'intérêt des entreprises pour l'IoT ne faiblit pas. En effet, dans une dynamique pragmatique, les organisations privilégient l'apport indéniable qu'apportent ces technologies sur leur business et leurs méthodes de travail par rapport aux dangers généralement acceptés comme une fatalité. Une étude de l'institut 451 Research démontre que 71% des organisations exploitent peu ou prou des données avec l'Internet des Objets et souhaitent augmenter leurs investissements dans ce domaine pendant les 12 prochains mois. Cependant, la cyber sécurité reste le frein principal à l'émergence de nouveaux usages et d'une adoption totale de ces technologies.
Cela pose donc une question : peut-on réellement considérer les failles constatées comme une fatalité ? Spoiler Alert : La réponse est non ! Nous allons essayer de vous le démontrer dans cet article.
Le mauvais élève
Les évènements décrits ci-dessous sont inspirés de faits réels. Toute ressemblance à des cas et des personnes que vous avez déjà rencontrés n'est pas du tout fortuite.
Ce que vient de faire Gérard est en réalité beaucoup plus dangereux que de laisser la sublime maison sans surveillance. Il vient de créer une énorme brèche sur son réseau local en permettant à n'importe qui de s'y connecter. Il existe aujourd'hui des robots capables de scanner toutes les adresses IPv4 du monde en moins de 24h et de tenter de s'y connecter avec des login/password largement utilisés ("root", "admin", "password", "12345", "qwerty", …). Gérard n'a fait que suivre une documentation incomplète qui ne lui a pas fortement suggéré (voire incité à) de changer d'identifiants. En plus de donner accès au flux vidéo des caméras, ses objets connectés vont pouvoir être utilisés par les robots pour réaliser des attaques dont il sera reconnu comme responsable. De plus, tous les éléments connectés au réseau local de Gérard sont désormais en danger. La solidité d'une chaîne dépend de la solidité de son maillon le plus faible et ici, un maillon très sensible vient d'être ajouté.
Mais l'histoire de Gérard n'est pas terminée. Il vient de s'acheter une sublime voiture allemande avec un logo à 4 anneaux. Pour ouvrir sa voiture, il n'a rien à faire. Il lui suffit d'être à proximité de son véhicule avec sa clé électronique dans sa poche pour qu'elle s'ouvre automatiquement. Ce constructeur avait choisi de ne pas chiffrer les données de la clé qui permettent l'ouverture. Une interception de ce signal RFID est suffisante pour obtenir le code d'ouverture qui se trouve être identique sur des millions de véhicules. Une personne mal intentionnée peut donc récupérer cette clé numérique et ainsi ouvrir et démarrer plus de 100 millions de véhicules dans le monde. Pour couronner le tout, un vol de véhicule sans traces d'effractions n'est pas couvert par les assurances.
Le constructeur allemand a alors choisi d'implémenter un algorithme de chiffrement HiTag2 spécifiquement conçu pour les microcontrôleurs NXP présents dans les véhicules. Cet algorithme qui date de la fin des années 1990, se trouve aujourd'hui assez simplement mis à mal et ne prend que 10 minutes à être contourné avec un matériel coûtant moins de 30 euros. D'autant que pour tous les véhicules produits jusqu'à 2016, la recommandation du constructeur consiste à désactiver le mode "mains libres" de ces clés… Vous voulez savoir si votre véhicule a été piraté ? Si, lors de l'appui sur le bouton de votre télécommande, le véhicule refuse de s'ouvrir (hormis le problème de pile) c'est que le signal a d'ores et déjà été intercepté et utilisé. En effet, pour coupler les nouveaux algorithmes avec une technique plus "rustique", les constructeurs ont ajouté un compteur de réceptions de commandes d'ouverture dans les microcontrôleurs des véhicules. Si ce compteur n'est pas synchronisé avec le nombre d'appuis stockés sur la clé, la commande d'ouverture ne fonctionnera pas.
La sécurité dans l'IoT
Le manque de sécurité dans l'IoT n'est qu'une conséquence de l'impact du business sur les projets. Le Time To Market de plus en plus court et la volonté de "faire de l'IoT" par des acteurs non scrupuleux provoquent une précipitation et des erreurs pourtant simples à éviter.
Il existe des spécificités à ce domaine qui peuvent rendre le point de vue sécurité un peu moins abordable que le simple prototypage. Avec la multiplication des tutoriels DIY (Do It Yourself), la baisse des prix sur le matériel (Microcontrôleurs, capteurs, modules de communications, offre cloud, …) et leurs interfaces de programmations simplifiées, il n'a jamais été aussi facile de créer son propre petit objet communicant. Cependant, dans une optique plus industrielle, il est nécessaire de maîtriser des concepts plus complexes pour contrer les failles spécifiques aux objets connectés.
Il existe 3 types de vulnérabilités :
- Les vulnérabilités matérielles
- Les vulnérabilités logicielles
- Les failles relatives aux communications
Allons au-delà de ces généralités pour entrevoir la lumière au bout du tunnel.
Les vulnérabilités matérielles
Une des failles hardware qui peut sembler anodine mais qui est en réalité la cause de nombreux troubles, c'est l'accès à l'interface de debug. Il est souvent nécessaire pour un développeur de faire remonter des informations à travers ces interfaces pour suivre l'évolution d'un programme au cours du temps. Le problème réside dans la possibilité d'y faire transférer des informations sensibles comme des identifiants ou des trames de données en clair. Les objets les plus sensibles sont ceux qui peuvent nécessiter d'être branchés à un PC via USB. Certaines interfaces comme l'ADB (Android Debug Bridge) permettent même d'exécuter des commandes sur l'objet lui-même. Il suffirait de désactiver cette interface lors de la mise en production des objets pour qu'il soit impossible d'y accéder.
Un outil bien connu des électroniciens peut être la source d'une perte totale de contrôle sur des objets connectés. Le JTAG (Joint Test Action Group) est une interface hardware permettant initialement de réaliser des tests de continuité sur les routes des cartes numériques (absence de courts circuits). Cet outil sert à donner un accès à toutes les broches d'entrées sorties des composants électroniques intégrés. L'objectif consiste à réaliser des tests en boîte noire sur des composants logiques en s'assurant de la conformité des signaux de sortie en fonction d'entrées choisies. Cependant, la force de cet outil ne se limite pas aux tests. On peut aussi choisir de l'utiliser en tant que BDM (Background Debug Module) pour émuler un système embarqué et en récupérer les signaux internes. La récupération de ces signaux peut permettre de reconstituer des données sensibles. Il est même possible de reprogrammer la mémoire flash des objets avec cet outil et d’y implanter son propre code au comportement totalement différent. Cette technique nécessite une connectique particulière qu'il suffit de ne pas mettre à disposition dans la version de production de l'objet en question.
Dans les deux cas, l'exploitation des failles nécessite l'accès direct au matériel. Une bonne pratique consiste à réaliser un bon packaging permettant de rendre le plus difficile possible l'accès au hardware, surtout si l'objet ne nécessite pas d'être chargé. Cela doit être combiné avec une bonne gestion de l'environnement électromagnétique. Il faut bien connaître l'environnement dans lequel va évoluer l'objet pour prendre des contre mesures et éviter qu'il ne soit perturbé.
Un concept de plus en plus répandu dans les microcontrôleurs de dernière génération permet d'isoler l'OS de l'objet et la partie applicative. Le concept de Safezone ou Trustzone permet d'isoler physiquement le code sensible qui exploite le matériel dans sa totalité et le code applicatif. Ces codes vont s'exécuter sur des parties différentes du hardware et l'altération du code applicatif n'aura que très peu de répercussions sur la sécurité globale de l'objet.
Les vulnérabilités logicielles
Dans le monde de l'électronique embarquée, la taille mémoire est souvent réduite (quelques Ko) et cela va causer pas mal de soucis.
Le programmeur doit par exemple souvent manipuler la mémoire à l'ordre de grandeur du registre. Une attention toute particulière doit être apportée au débordement mémoire. Comme dans la programmation sur des architectures classiques, ces erreurs d'implémentations peuvent causer des comportements assez difficiles à prédire et c'est une des premières failles software qu'essaient d'exploiter les hackers.
Nous avons déjà évoqué l'importance de changer les identifiants par défaut qui sont en plus non chiffrés sur le device ou dans les trames de communications. C'est une erreur classique qui serait résolue en imposant à l'utilisateur de changer ses identifiants sous peine de ne plus pouvoir utiliser son matériel.
Une autre contrainte matérielle va avoir de l'impact sur l'implémentation logicielle. Les microcontrôleurs sont généralement dotés d'une faible puissance de calcul qui est souvent ajustée en fonction de l'application cible. Cette faible puissance de calcul limite les opérations cryptographiques possibles. Les librairies nécessaires à l'utilisation d'algorithmes de chiffrement éprouvés sont souvent trop volumineuses pour les objets ce qui implique l'émergence de nouveaux standards. Les opérations de hachage, chiffrement symétrique ou asymétrique sont cependant possibles en utilisant des bibliothèques de tailles raisonnables mais très difficilement interopérables. Il existe d’ailleurs un nombre important de projets open source dans ce sens dont il est difficile d’évaluer la fiabilité.
La solution en vogue consiste à intégrer des fonctions cryptographiques dans le silicium des microcontrôleurs ou de dédier des composants à ces opérations. Cela permet de ne pas diminuer la taille disponible avec des bibliothèques encombrantes (surtout si on en utilise plusieurs) mais l'inconvénient est que cela fixe définitivement les algorithmes utilisés. On imagine mal un technicien dessouder tous les composants de cryptographie pour les remplacer par d'autres en cas de failles découvertes sur un algorithme.
La solution qui semble la meilleure est la cryptographie sur les courbes elliptiques (implémentée dans la libuecc par exemple). Ces opérations sur les logarithmes discrets sont plus simples à réaliser que celles sur les similarités d'entiers (RSA) mais le chiffrement qui en résulte est beaucoup plus complexe à casser. On estime qu'une clé basée sur un chiffrement elliptique de 200 bits est plus sûre qu'une clé RSA de 1024 bits.
La dernière faille software qui se trouve être très dangereuse est la capacité ou non à mettre à jour le logiciel d'un objet connecté. Dans le cas où l’on trouve une faille, il faut pouvoir être en mesure de patcher la faille constatée et ne pas laisser un device vérolé isolé. Pour cela, il faut implémenter la signature des mises à jour et veiller à disposer d'un espace mémoire suffisant. La signature permet d’éviter qu’une personne mal intentionnée puisse utiliser le mécanisme de mise à jour pour prendre le contrôle de l’objet.
Les failles relatives aux communications
C'est la dernière étape présentant des risques concrets. L'authentification est la première problématique rencontrée au vu de la quantité gigantesque potentielle de devices. Des méthodes comme OAuth 2.0 ou OpenID Connect 1.0 peuvent servir à résoudre ce problème or pour l'instant, elles ne sont utilisables qu'en HTTP. Cependant, HTTP n'est pas idéal pour tous les usages (comme les communications device to device) et on va souvent privilégier CoAP ou MQTT. Le prochain challenge va consister à implémenter des méthodes d'authentification efficaces pour ces protocoles.
La (très) grande diversité de protocoles de communication rend très complexe les interopérabilités et nécessite un travail d'appropriation assez long. Il faut aussi penser à l'intégrité des données en effectuant des opérations de checksum ou de redondance pas forcément natives sur certains protocoles. Le checksum consiste à réaliser une opération sur la donnée dont le résultat est envoyé avec la donnée originale. A la réception on applique la même fonction sur la donnée et on vérifie que les résultats sont les mêmes.
Le formidable succès des LPWAN (Sigfox, LoRa, NB-IOT, Qowisio, …) pose aussi certains problèmes. Ces réseaux à basse consommation, faible débit mais très grande portée connaissent un essor impressionnant (près de 300 millions d’euros de fonds levés pour Sigfox). Ce sont des protocoles bien pratiques pour certains usages (Télémetrie, heartbeat, …) mais dont les contreparties sont souvent négligées par les organisations. La tendance consiste à se positionner sur une de ces technologies sans en connaître réellement les limites. Sigfox est, par exemple, un réseau permettant de transmettre au maximum 140 messages par jour de 12 octets de charge utile. Sigfox ne fournit aucun dispositif de chiffrement des messages au niveau du réseau. C’est au développeur d’implémenter des étapes de chiffrement lors des échanges. Les messages descendants vers les objets sont très limités (seulement 4 messages de 8 octets). Il faut donc oublier les mises à jour via ce réseau. Il sera aussi complexe de transmettre des clés de chiffrement par ce moyen. LoRa est en revanche bidirectionnel symétrique mais non simultané. La charge utile est ici de 242 octets , difficilement utilisable là aussi pour des mises à jour. Les données sont par contre chiffrées nativement. Ces réseaux sont conçus pour transmettre les messages sur de longues distances (jusqu'à 40km) et ont une très bonne pénétration indoor. Ils ont donc leurs avantages mais compliquent certaines mesures de sécurité.
Conclusion
Le dernier maillon de l'écosystème IoT, les plateformes Cloud, n'ont pas été abordées car elles représentent les nœuds du système sur lesquels une attention toute particulière a été réservée à la sécurité. Si elles ne sont pas gérées par les organisations elles-mêmes, elles sont gérées par des géants du web (Amazon, IBM, Microsoft, …) qui imposent des standards de sécurité assez stricts.
La sécurité dans l'IoT n'est qu'une question de bonnes pratiques et les failles remarquées ne sonnent pas le glas du domaine. Il suffit de ne pas se précipiter vers un marché encore jeune simplement pour montrer qu'on "en est". Certaines problématiques sont encore en cours de résolution mais cela n'est pas si différent de l'internet classique. Certaines initiatives comme celles menées par la Allseen Alliance ou l'Open Connectivity Foundation tentent même d'unifier les protocoles de communications IoT pour définir un seul et unique standard compréhensible par tous les éléments de l'écosystème.
Les conséquences d'une mauvaise sécurité sont bien entendu plus dramatiques que le destin de notre cher Gérard. La confidentialité de vos données n'est plus garantie. Celles-ci peuvent se retrouver utilisées à des fins commerciales à votre insu. Votre réseau local pourtant bien protégé se retrouve à découvert pour toutes les attaques. Ces attaques peuvent exploiter votre matériel à des fins malveillantes. Vous pouvez par exemple lire ce qu’a pu récemment subir Dyn. De plus, vous êtes responsables des objets que vous possédez, que vous soyez une organisation ou un particulier. Alors tenez compte du danger et faites confiance à des acteurs qui prennent le soin de respecter les bonnes pratiques.