Le chiffrement des systèmes IoT se montre très vulnérable
Ce n'est pas la faute des fournisseurs d'IoT, mais l'absence d'un sous-système de générateur de nombres pseudo-aléatoires sécurisé sur le plan cryptographique qui rend vulnérables les appareils de l'Internet des objets.
Les garanties de confidentialité et d'intégrité des protocoles de communication modernes reposent sur des algorithmes qui génèrent des jetons secrets que les attaquants ne peuvent pas deviner. Ces algorithmes sont utilisés pour l'authentification, le cryptage, le contrôle d'accès et de nombreux autres aspects de la sécurité moderne. Ils nécessitent tous des nombres aléatoires cryptographiquement sûrs, c'est-à-dire des séquences de nombres ou de symboles choisis de façon à les rendre imprévisibles pour un attaquant. Tous les algorithmes cryptographiques qui impliquent une sorte de génération sécurisée de clés ou de jetons doivent être ensemencés avec des nombres aléatoires. Le processus par lequel ces nombres sont choisis, connu sous le nom de générateurs de nombres aléatoires ou Random Number Generator (RNG), est la base de nombreux systèmes et fonctionnalités de sécurité. Alors que les systèmes d'exploitation et les ordinateurs modernes disposent depuis longtemps de RNG sécurisés, les dispositifs IoT, en particulier les dispositifs à ressources limitées sans beaucoup d'interfaces qui exécutent des systèmes d'exploitation plus simples, ont depuis longtemps un problème pour trouver des sources élevées de caractère aléatoire, également connu sous le nom d'entropie.
Ces dernières années, les fournisseurs de systèmes sur puce (SoC) ont tenté de résoudre ce problème en intégrant à leurs produits des contrôleurs périphériques conçus pour générer des nombres aléatoires que le système d'exploitation peut ensuite utiliser en toute sécurité. Cependant, une équipe de chercheurs de l'entreprise de sécurité Bishop Fox qui s'est intéressée à la manière dont les développeurs IoT utilisaient ces générateurs de nombres aléatoires matériels a constaté des problèmes d'implementation majeurs qui compromettent la sécurité de leurs systèmes. Ils ont récemment présenté leurs conclusions lors de la conférence de sécurité DEF CON organisée à Las Vegas du 11 au 14 août. « La manière dont le périphérique est utilisé à une importance critique, et on ne peut pas dire que l'état actuel de l'art dans l'IoT est insuffisant », ont conclu les chercheurs.
RNG matériel ou RNG logiciel
Les générateurs de nombres aléatoires logiciels sont également connus sous le nom de générateurs de nombres pseudo-aléatoires ou Pseudo-Random Number Generators (PRNG), car ils utilisent des algorithmes logiciels déterministes et ils doivent être ensemencés avec des valeurs aléatoires, généralement à partir d'un pool d'entropie qui combine des valeurs aléatoires provenant de différentes sources : informations réseau, interfaces radio, valeurs de synchronisation diverses, etc. Mais ce n'est pas tout. En général, les PRNG génériques sont utilisés à des fins non sécuritaires et les PRNG cryptographiquement sûrs ou Cryptographically Secure Pseudo-Random Number Generators (CSPRNG) sont conçus pour offrir des garanties de sécurité contre les attaques qui essayent de deviner les valeurs d'amorçage ou de prédire leur sortie dans un délai raisonnable et calculable. Les CSPRNG emploient des chiffres cryptographiques et des fonctions de hachage pour produire des résultats qui sont ensuite utilisés pour des opérations critiques comme la génération de clés. Ils effectuent également des tests pour prévenir les attaques connues. Toutes ces opérations consomment des ressources informatiques et de la mémoire, deux ressources très limitées sur les appareils IoT, ce qui explique pourquoi les fournisseurs de SoC ont ajouté des capacités de RNG matériel. Les générateurs de nombres aléatoires matériels sont également connus sous le nom de True RNG (TRNG) car ils génèrent des nombres aléatoires à partir de processus physiques d'une manière qui ne peut être prédite comme dans le cas des algorithmes logiciels. Les résultats des TRNG sont censés pouvoir être utilisés directement en toute sécurité, mais, comme l'ont constaté les chercheurs de Bishop Fox, les interfaces avec ces systèmes peuvent être ardues et les erreurs peuvent avoir des conséquences désastreuses pour les systèmes de sécurité qui en dépendent.
Aucune vérification des erreurs de RNG matériel
Les fournisseurs de SoC permettent aux développeurs d'interagir avec leur RNG matériel par l'intermédiaire de l'API de la couche d'abstraction matérielle ou Hardware Abstraction Layer (HAL) en appelant différentes fonctions dans leur code C. Les noms de ces fonctions RNG peuvent être très différents. Les noms de ces fonctions RNG peuvent différer d'un fournisseur à l'autre, mais leur résultat est un pointeur vers le nombre aléatoire (entier de 32 bits) et, surtout, une valeur de retour qui indique les erreurs potentielles. « La fonction HAL du périphérique RNG peut échouer pour diverses raisons, mais la raison de loin la plus courante (et la plus exploitable) c'est que le périphérique est à court d'entropie », expliquent les chercheurs dans un rapport. « Les périphériques RNG matériels extraient l'entropie de l'univers par divers moyens (comme des capteurs analogiques ou des lectures EMF de champs électriques et magnétiques), mais ils n'en ont pas en quantité infinie. Ils ne sont capables de produire qu'un certain nombre de bits aléatoires par seconde. Si bien que, si l'on essaye d'appeler la fonction HAL RNG alors qu'elle n'a pas de nombres aléatoires à donner, elle échouera et renverra un code d'erreur. Et, si le dispositif tente d'obtenir trop de nombres aléatoires trop rapidement, les appels commenceront à renvoyer des erreurs ».
Cela peut se produire assez souvent lors de la génération de clés de grande taille. Par exemple, lors de la génération d'une clé privée de 2048 bits, le dispositif appellera la fonction RNG HAL à plusieurs reprises dans une boucle et le matériel ne pourra souvent pas suivre en raison de ses limites et commencera à émettre des erreurs. Le problème est que, sur la base du code trouvé dans GitHub pour interagir avec les SoC et même le code de gestion du RNG dans les OS embarqués populaires comme FreeRTOS, les développeurs ne semblent pas vérifier les erreurs de RNG matériel. « Cela correspond tout simplement au mode de fonctionnement de l'industrie de l'IoT », ont déclaré les chercheurs de Bishop Fox. « On retrouve cette pratique dans presque tous les kits de développement logiciel et les OS IoT ». C'est un problème majeur, car selon le matériel, quand la fonction HAL RNG échoue, la sortie peut être une entropie partielle, le nombre 0 ou une mémoire non initialisée. Aucune de ces sorties n'est sûre pour des usages cryptographiques.
En 2019, lors de l'analyse de 75 millions de certificats numériques basés sur des clés RSA, des chercheurs de Keyfactor ont découvert qu'un certificat sur 172 était vulnérable à des attaques permettant de récupérer leurs clés secrètes. La vulnérabilité était liée à une mauvaise génération de nombres aléatoires, et la plupart des certificats vulnérables se trouvaient dans des appareils IoT et des appareils de réseau intégrés, comme des routeurs, des commutateurs et des pare-feux. Si les nombres premiers utilisés pour générer les clés publiques RSA ne sont pas suffisamment aléatoires, deux clés distinctes partageront probablement un facteur. Il est alors extrêmement facile de récupérer leurs autres facteurs et de les compromettre. « Même si nous ne pouvons pas dire avec certitude que nos recherches expliquent ces résultats... les cas généralisés de clés RSA vulnérables dans les appareils IoT sont exactement ce que l'on s'attend à trouver », ont déclaré les chercheurs de Bishop Fox à propos de leurs conclusions sur la gestion des RNG matériels sur les dispositifs IoT. « Il semble bien que cette faiblesse soit exploitable en pratique à grande échelle, et pas seulement en théorie », ont-ils ajouté.
De mauvaises implémentations forcées
Les chercheurs s'entendent pour dire qu'il ne faut pas se précipiter pour blâmer les développeurs de logiciels IoT pour les mauvaises implémentations, car traiter ces erreurs de manière appropriée présente d'autres inconvénients qui pourraient avoir un impact sur le fonctionnement de l'appareil. « Si la pile réseau est en cours de génération d'une clé cryptographique pour sécuriser des communications, il n'existe vraiment que deux options pour gérer les « erreurs » : soit abandonner, en stoppant l'ensemble du processus, soit tourner en boucle sur la fonction HAL pendant un temps indéfini jusqu'à ce que l'appel soit terminé, en bloquant tous les autres processus et en utilisant 100 % du CPU dans le processus. Aucune de ces solutions n'est acceptable. C'est pourquoi les développeurs ignorent la condition d'erreur. Les alternatives sont terriblement insatisfaisantes et l'écosystème autour du matériel RNG ne les pas aidé ». En plus de cela, peu de dispositifs sont livrés avec une documentation appropriée expliquant comment le générateur de nombres aléatoires est censé fonctionner et comment gérer les erreurs ou les éviter, et ils disposent de peu d'informations sur la vitesse de fonctionnement attendue, les plages de température de fonctionnement sûres ou les preuves statistiques du caractère aléatoire. Même quand la documentation existe, les explications ne sont pas toujours faciles et très claires.
La fiabilité du seul RNG matériel, insuffisante
Les chercheurs de Bishop Fox ont découvert beaucoup d'autres problèmes si l'on tente de se fier uniquement au RNG matériel comme source d'entropie dans l'IoT. Par exemple, en l'absence d'un véritable CSPRNG, de nombreux SDK et systèmes d'exploitation IoT qui prennent en charge les RNG matériels l'utilisent pour ensemencer un PRNG non sécurisé tel que libc rand(), et sa sortie est utilisée à des fins de sécurité alors qu'elle ne devrait pas l'être. « Les PRNG comme libc rand() sont largement peu sûrs, car les nombres qu'ils produisent révèlent des informations sur l'état interne du RNG », ont déclaré les chercheurs. « Ils sont parfaits dans des contextes non liés à la sécurité, car ils sont rapides et faciles à mettre en oeuvre. Mais leur utilisation pour générer des clés de cryptage nuit dramatiquement à la sécurité du dispositif, car tous les nombres sont prévisibles », ont-ils ajouté.
Lors d'un test sur un microcontrôleur LPC54628, les chercheurs ont remarqué que les nombres aléatoires produits par le RNG matériel étaient de mauvaise qualité et ont soupçonné que quelque chose clochait dans leur code. En fouillant plus profondément dans la documentation du fabricant, ils ont trouvé une recommandation contre la concaténation de nombres de 32 bits produits par le RNG pour construire des nombres plus grands. Par exemple, pour obtenir un nombre aléatoire de 128 bits, les développeurs ne doivent pas concaténer quatre sorties 32 bits consécutives du RNG, indique ainsi le fabricant. Á la place, ils doivent utiliser un nombre de 32 bits, rejeter les 32 nombres suivants, puis utiliser le suivant, puis rejeter 32 autres nombres, et ainsi de suite. Ce comportement de l'API est tellement étrange et contre-intuitif qu'il est presque garanti de produire des implémentations vulnérables. Selon les chercheurs, même si les développeurs trouvaient le code correct permettant de rejeter 32 chiffres, ils pourraient le supprimer, car ils le jugent inutile.
En outre, certaines implémentations de RNG matériel testées par les chercheurs ont échoué aux tests d'analyse statistique ou présentaient des schémas clairs dans la distribution relative des octets qu'elles produisaient. Ainsi, même si les développeurs parviennent à surmonter tous les obstacles liés à la gestion des erreurs, aux bizarreries de l'API et à la mauvaise documentation, ils ne doivent pas se fier uniquement à la sortie des RNG matériels. La solution, c'est d'avoir des PRNG cryptographiquement sûrs appropriés pour les IoT où la sortie des RNG matériels n'est qu'une des sources du pool d'entropie. Tous les principaux systèmes d'exploitation comme Linux, Windows, macOS, Android, iOS, BSD ont des sous-systèmes CSPRNG qui sont à l'abri des erreurs et que les développeurs d'applications peuvent facilement utiliser sans interagir directement avec le matériel et s'inquiéter que leur code ne soit pas correct ou que les nombres aléatoires ne soient pas sûrs. « Dans le cas présent, la vulnérabilité principale ne réside pas dans le SDK d'un seul appareil ou dans une implémentation particulière du SoC », ont déclaré les chercheurs. « L'IoT a besoin d'un sous-système CSPRNG. Ce problème ne peut pas être résolu en changeant simplement la documentation et en accusant les utilisateurs. Le lieu le plus approprié pour loger un tel sous-système CSPRNG se situe dans l'un des systèmes d'exploitation IoT de plus en plus populaires. Si vous concevez un nouvel appareil à partir de zéro, nous vous recommandons d'implémenter un CSPRNG dans un système d'exploitation », ont conseillé les chercheurs.
