Lorsque Ryan Castellucci a récemment installé des panneaux solaires et un système de stockage d’énergie pour leur domicile situé juste à l’extérieur de Londres, ce qui les a attirés, c’est la possibilité d’utiliser un tableau de bord open source pour surveiller et contrôler le flux d’électricité généré. En réalité, ils ont obtenu beaucoup, beaucoup plus : environ 200 mégawatts de capacité programmable pour charger ou décharger le réseau à volonté. Suffisamment d’énergie pour alimenter environ 40 000 foyers.
Castellucci, qui utilise les pronoms ils/eux, a obtenu ce contrôle remarquable après avoir eu accès au compte administrateur de GivEnergy, le fournisseur de gestion énergétique basé au Royaume-Uni qui a fourni les systèmes. En plus du contrôle d’environ 60 000 systèmes installés, le compte admin — qui correspond à un contrôle total des produits connectés au cloud de l’entreprise — leur a également permis d’énumérer les noms, adresses email, noms d’utilisateur, numéros de téléphone et adresses de tous les autres clients de GivEnergy (ce que le chercheur n’a d’ailleurs pas fait).
« Mon plan est de configurer Home Assistant et de l’intégrer avec ça, mais en attendant, j’ai décidé de le laisser communiquer avec le cloud, » a écrit Castellucci jeudi, en parlant de l’équipement récemment installé. « J’ai mis en place une programmation de charge, puis j’ai commencé à expérimenter avec l’API. Le soir suivant, j’avais le contrôle d’une centrale électrique virtuelle composée de dizaines de milliers de batteries connectées au réseau. »
Toujours défaillant après toutes ces années
La cause de la vulnérabilité d’authentification découverte par Castellucci était une interface de programmation protégée par une clé cryptographique RSA de seulement 512 bits. Cette clé signe les jetons d’authentification et équivaut à une clé maître. La taille en bits a permis à Castellucci de factoriser la clé privée qui sous-tendait l’ensemble de l’API. La factorisation a coûté 70 $ pour le calcul en cloud et a pris moins de 24 heures. GivEnergy a introduit un correctif dans les 24 heures suivant la divulgation privée de la vulnérabilité par Castellucci.
La première instance connue publiquement de factorisation d’un RSA de 512 bits remonte à 1999 par une équipe internationale de plus d’une douzaine de chercheurs. Cet exploit a nécessité un supercalculateur et des centaines d’autres ordinateurs pendant sept mois. En 2009, des amateurs ont mis environ trois semaines pour factoriser 13 clés RSA de 512 bits protégeant le firmware de calculatrices Texas Instruments contre la copie. En 2015, des chercheurs ont démontré la factorisation en tant que service, une méthode utilisant le cloud d’Amazon, coûtant 75 $ et prenant environ quatre heures. À mesure que la puissance de traitement augmente, les ressources requises pour factoriser les clés ont considérablement diminué.
Il est tentant de critiquer les ingénieurs de GivEnergy pour avoir fondé la sécurité de leur infrastructure sur une clé qui est triviale à casser. Cependant, Castellucci a déclaré que la responsabilité devait plutôt être attribuée aux créateurs des bibliothèques de code sur lesquelles les développeurs comptent pour mettre en œuvre des processus cryptographiques complexes.
« S’attendre à ce que les développeurs sachent que le RSA de 512 bits est peu sécurisé ne fonctionne clairement pas, » a écrit le chercheur en sécurité. « Ils ne sont pas cryptographes. Ce n’est pas leur travail. L’échec n’était pas que quelqu’un ait utilisé le RSA de 512 bits. C’est que la bibliothèque dont ils avaient besoin les a laissé faire. »
Castellucci a noté qu’OpenSSL, la bibliothèque de code cryptographique la plus utilisée, offre toujours l’option d’utiliser des clés de 512 bits. Il en va de même pour la bibliothèque crypto de Go. Coïncidence, la bibliothèque de cryptographie Python a supprimé cette option il y a seulement quelques semaines (le commit pour le changement a été réalisé en janvier).
Dans un courriel, un représentant de GivEnergy a renforcé l’évaluation de Castellucci, écrivant :
Dans ce cas, l’approche de cryptage problématique a été adoptée via une bibliothèque tierce il y a de nombreuses années, alors que nous étions une toute petite startup avec seulement deux développeurs logiciels assez juniors et une expérience limitée. Leur hypothèse à l’époque était que parce que ce chiffrement était disponible dans la bibliothèque, il était sûr de l’utiliser. Cette approche a été maintenue au fil des années et cette partie du code n’a pas été changée de manière significative depuis son implémentation (elle n’a donc pas passé par la révision de l’équipe plus expérimentée que nous avons maintenant en place).
En tant que journaliste de LesNews, je trouve que cet incident soulève des questions cruciales sur la sécurité des infrastructures énergétiques modernes. Dans un contexte où de plus en plus de foyers s’équipent de technologies de gestion de l’énergie, il est impératif que les entreprises garantissent la robustesse de leurs systèmes de sécurité. L’importance d’une formation continue pour les développeurs et d’une révision régulière des bibliothèques utilisées ne saurait être trop insistée. La confiance du public dans de telles technologies repose non seulement sur leur efficacité, mais aussi sur leur sécurité.
