[TRIBUNE by Sébastien Léger, RED MINT] Les analystes prévoient jusqu’à 30 milliards d’objets connectés en utilisation en 2020 (source McKinsey). Cette masse considérable d’objets communicants va changer profondément la nature d’Internet... et poser de très gros problèmes de sécurité. Une des appoches possibles pour sécuriser les objets de l'IoT est de s'appuyer sur l’ajout de signatures de clés numériques au sein du système Linux, comme l'explique ici Sébastien Léger, fondateur et CEO de la start-up Red Mint. ...

Comme de nombreux experts en sécurité l’ont démontré, la plupart des objets connectés sont conçus en ignorant la partie sécurité. Conséquence : il est devenu trivial d’altérer le logiciel de ces divers objets et d’en prendre le contrôle à distance. La communauté des hackers qui a pris la mesure de cette potentialité synchronise ces objets (devenus “esclaves”) pour lancer des attaques informatiques massives de type DDoS (Distributed Denial of Service ou attaques par déni de service distribuées) et ciblées, la plus récente étant la mise en œuvre de Mirai (un logiciel malveillant qui transforme des équipements sous Linux en systèmes contrôlés à distance pour lancer des attaques massives) via un réseau de plus de 100 000 caméras esclaves. La répétition de ce type d’événements à l’avenir est loin d’être une simple vue de l’esprit. Lorsque les zombies (ou les réfrigérateurs) connectés vont arriver en nombre, il sera déjà trop tard – les fans de Robert Rodriguez savent qu’il est complexe de contenir ces créatures !

Le seul espoir est de trouver un vaccin et de l’inoculer à chaque fournisseur d’équipements connectés. Récemment, la Commission européenne a cherché des alternatives venant de l’industrie pour trouver le bon vaccin, avant d’imposer d’éventuelles sanctions. Mais la réalité est que les menaces ne s’arrêtent pas aux frontières de l’Union européenne et tout type d’objet connecté en tout point du réseau peut être contrôlé à distance et cibler tout ce qui se trouve à sa portée : services Internet publics ou infrastructures IT privées. Car au fond aucun terminal n’est vraiment sécurisé.

Nous vivons encore avec le paradigme informatique des années 1980 : “créer une application, l’exécuter partout”. Or il ne correspond plus au monde actuel. Nous devons en changer pour éviter l’usage détourné des technologies à notre insu, passer du modèle “1 vers N” au modèle “1 vers 1”. Avec le modèle “1 vers N”, toute application créée en un exemplaire pour l’architecture choisie (ARM, Mips, Intel, …) peut ainsi s’exécuter sur tout processeur qui comprend le bytecode de la même architecture. Un hacker peut ainsi installer ses “outils” (malwares, etc.) vers les terminaux non sécurisés pour détourner l’objet de son utilisation initiale. L’industrie cherche donc activement des réponses et des solutions à cette situation.

En 2003, Matt Miller, le développeur de Metasploit (un projet open source lié à l’analyse de la sécurité des systèmes informatiques dont l’objet est de fournir des informations sur les vulnérabilités desdits systèmes), connu alors sous le pseudonyme de hacker Skape, a proposé un outil de signature numérique pour les binaires ELF (Executable and Linkable Format), le format des applications lorsqu’elles sont conservées sur un support de stockage. Matt Miller a alors réalisé qu’il manquait une notion essentielle de confiance dans les applications, celle de savoir si une application (un fichier binaire ELF) est issue d’un fournisseur de confiance et non d’un tiers inconnu qui aurait altéré son contenu. Le principe général proposé par Matt Miller est d’utiliser les clés RSA asymétriques pour insérer une signature numérique dans les applications (les binaires ELF). Avec la technique proposée, le fournisseur d’applications est le seul à détenir la clé privée et le seul à pouvoir produire les signatures qui disent : « Ce binaire ELF est bien une application originale livrée par ma société ». Alors que manque-t-il dans l’équation ?

Le système d’exploitation ainsi que les pilotes de périphériques qui communiquent avec le matériel ont eux aussi besoin d’authentification. Une littérature abondante a été produite sur ce dernier point avec l’introduction, lors du démarrage de la couche logicielle UEFI (Unified Extensible Firmware Interface), de la mise en œuvre de paires de clés asymétriques et de certificats intégrés directement dans l’image du système d’exploitation. Vivek Goyal, chercheur en sécurité pour Red Hat, a ainsi proposé en 2013 d’étendre le support des signatures aux applications ELF (comme Matt Miller l’avait proposé en 2003) et de contrôler systématiquement ces signatures lors de l’utilisation des applications. Les signatures peuvent alors être vérifiées par un tiers de confiance : le système d’exploitation.

A l’heure ou cette tribune est publiée, le travail de Vivek Goyal n’a cependant pas été inclus dans une version publique du système d’exploitation Linux. Mais la vision de Miller et Goyal peut devenir une réalité. En fait, l’ajout de signatures RSA aux applications est une solution idéale pour le monde de l’embarqué. Un système embarqué n’est pas un ordinateur personnel, le paradigme « créer une application, l’exécuter partout » ne s’applique pas. Au contraire, un fournisseur d’une application IoT ou d’un système embarqué possède le contrôle total sur les composants logiciels (applications, pilotes de périphériques, système d’exploitation) qu’il inclut dans son produit. L’équation est plus simple à résoudre car la responsabilité n’est pas diluée.

Une solution évidente pour s’assurer que ces composants logiciels n’ont pas été altérés est donc d’appliquer une signature numérique à chacun. C’est la proposition, basée sur un patch kernel Linux à l’intention du monde de l’IoT, que nous proposons (avec un travail réalisé dans un environnement CentOS 7 avec un noyau Linux 3.10 qui possède le support des clés RSA asymétriques). Depuis la version 3.7 du noyau Linux, le support des clés RSA asymétriques, ainsi que la possibilité d’insérer une signature numérique aux pilotes de périphériques, ont été introduits.

Concrètement, pendant la phase de démarrage, le noyau charge automatiquement les certificats et les clés X.509 dans la mémoire du système à partir des clés persistantes disponibles. Un patch à télécharger au noyau Linux permet ensuite la vérification des signatures numériques RSA lors du chargement (lancement) d’un binaire ELF (une application). Après recompilation du noyau Linux, la commande sign-module (disponible dans les sources du noyau Linux) permet de signer tous les pilotes de périphériques ainsi que toutes les applications ELF (sans exception) contenues dans l’image du firmware. Après cette phase de mise en place, le noyau Linux va vérifier systématiquement la signature numérique d’une application chargée en mémoire avant d’autoriser son exécution, ou non. Une application non signée ne pourra pas s’exécuter. Une application signée par un tiers inconnu ne pourra pas s’exécuter.

Pour être clair, ces améliorations ne vont pas prévenir une intrusion mais leur valeur ajoutée va prévenir l’altération du système. Ce dernier pourra uniquement exécuter les applications de confiance et sera donc nettement moins exposé à un usage détourné.

Comme la communauté open source l’a noté lors de la relecture du travail de Goyal et Miller, la proposition ne traite pas le sujet des interprètes ; Python, Bash, Perl et les autres langages de script ne vont pas vérifier qu’un script (texte lisible et aisément altéré) est authentique ou non. Pour aller plus loin, soit les interprètes doivent êtres proscrits totalement (c'est le mieux), soit ils doivent aussi supporter un mécanisme d’authentification. Une alternative élégante est l’utilisation du langage Lua qui est traduit au format ELF et peut ainsi entrer dans le cadre proposé plus haut. Reste que les hackers produisent désormais des malwares en Lua qui ciblent les architectures ARM. Une autre bonne raison qui incite à signer numériquement les applications si l’on utilise le langage Lua dans les images de production !

On le voit, Il est possible, sur le long terme, d’améliorer significativement la sécurité dans l’IoT. Néanmoins le risque zéro n’existe pas et les nouvelles technologies et la multiplication des usages vont encore constituer de réelles menaces pour la sécurité du système d’information d’une entreprise et la sécurité de ses données.