Normes pour maintenir la sécurité des appareils à jour

Les appareils IoT étant généralement construits avec de faibles marges bénéficiaires et de faibles spécifications de puissance, les fonctionnalités sont généralement limitées à celles qui sont nécessaires. Mais pour un appareil qui devrait durer plusieurs années, il y aura des vulnérabilités et des problèmes de sécurité qui doivent être corrigés (voir le botnet Mirai comme exemple)

En tant que fabricant IoT, comment puis-je activer à distance les correctifs ou la mise à niveau des algorithmes de chiffrement ou des protocoles de sécurité, ou simplement garantir la sécurité de l'appareil? Quelles normes dois-je suivre?

Comment les fabricants IoT permettent-ils de corriger ou de mettre à niveau les algorithmes de chiffrement ou les protocoles de sécurité à distance ou simplement pour garantir la sécurité de l'appareil?

Un grand nombre de fabricants IoT ont une solution simple à cela: "ne vous embêtez pas" . Ce sont généralement les mêmes développeurs qui ajoutent des mots de passe par défaut (ou même immuables) à leurs appareils, ce qui a conduit à Mirai en premier lieu.

Comme mentionné dans la réponse de Rory , il y a des coûts importants à fournir à la fois les mécanismes et le temps de développement réel pour concevoir et déployer les correctifs. Je soupçonne fortement que sans pression réglementaire (ou demande des consommateurs, ce qui ne semble pas être le cas), aucun fabricant ne sera incité à augmenter les prix de ses produits pour plus de sécurité. L'Australie semble prendre cette mesure en envisageant un système de notation de sécurité obligatoire pour tous les appareils IoT.

Je pense que pour la plupart des fabricants, la meilleure idée est de demander à quelqu'un d'autre de gérer la sécurité. Tout comme la plupart des développeurs Web utilisent des frameworks établis comme Django et Ruby on Rails pour éviter de faire les mêmes erreurs encore et encore, les développeurs IoT devraient faire de même. Il existe plusieurs options, selon la complexité de votre appareil:

• Les appareils haut de gamme peuvent utiliser des systèmes d'exploitation comme Ubuntu IoT ou Windows 10 IoT Core, où les mises à jour de sécurité sont effectuées par le développeur du système d'exploitation et transmises automatiquement. Une grande partie de cela n'est pas spécifique à l'IoT, mais il est de loin préférable que chaque appareil IoT utilise un système d'exploitation interne personnalisé qui ne recevra probablement aucune maintenance.

• Les appareils bas de gamme tels que les modules ESP8266 sont peut-être plus limités, car ils ne sont pas en mesure d'exécuter des systèmes d'exploitation complexes et ont tendance à exécuter du code développé spécifiquement pour cet appareil. Il existe encore des options telles que Mongoose OS qui offrent des mises à jour du firmware en direct

Les fabricants IoT devraient généralement tirer parti des solutions existantes lorsqu'elles sont disponibles. Les développeurs Web ne recréent généralement pas de cadre Web pour chaque nouveau site Web, alors pourquoi l'IoT devrait-il être sensiblement différent? La réponse de Rory offre une excellente liste de fonctionnalités qui devraient être implémentées par un bon système d'exploitation pour l'IoT, et le simple fait d'utiliser un "IoT OS" ne résoudra pas tous vos problèmes. Comme l' explique ce guide Windows IoT , il faut prendre des mesures pour s'assurer que le matériel et le micrologiciel sont sécurisés ainsi que le système d'exploitation lui-même. Les idées de la réponse de Rory sont assez complètes à cet égard.

Voici quelques exemples des systèmes d'exploitation que j'ai suggérés concernant les systèmes qu'ils utilisent pour améliorer la sécurité:

• Windows IoT:

  • Fonctionnalité automatique et mises à jour de sécurité lors d'une connexion à Internet
  • Avec Azure IoT Suite, chaque appareil dispose d'un certificat X.509 pour s'authentifier auprès du concentrateur. Cela garantit également que si un appareil est compromis, les autres ne sont pas affectés

• Ubuntu Core :

  • Mises à jour automatiques sans surveillance pour la sécurité
  • "Mises à jour transactionnelles en direct - avec fonctionnalités de restauration complètes"

Moran a publié ce projet de l'IETF intitulé A Firmware Update Architecture for Internet of Things Devices le 30 octobre 2017.

Un résumé clé décrit sur l' ordinateur Bleeping est

• Le mécanisme de mise à jour doit fonctionner de la même manière, même si le micrologiciel binaire est fourni via Bluetooth, WiFi, UART, USB ou d'autres supports.
• Le mécanisme de mise à jour doit fonctionner dans un type de diffusion, permettant aux mises à jour d'atteindre plusieurs utilisateurs à la fois.
• La sécurité de bout en bout (cryptographie à clé publique) doit être utilisée pour vérifier et valider les images du micrologiciel.
• Les attaques de restauration doivent être évitées.
• Toutes les informations nécessaires à un appareil pour prendre une décision concernant l'installation d'une mise à jour doivent tenir dans la mémoire RAM disponible d'un appareil IoT contraint. Cela empêche l'épuisement de l'écriture flash.
• Une panne de courant à tout moment pendant le processus de mise à jour ne doit pas entraîner de panne de l'appareil.
• Le mécanisme de mise à jour du micrologiciel ne doit pas nécessiter de modifications des formats de fichier de micrologiciel existants.
• Le nouveau mécanisme de mise à jour du micrologiciel doit pouvoir fonctionner avec un petit chargeur de démarrage, spécifique à la plupart des appareils IoT.
• Le mécanisme de mise à jour doit prendre en compte plusieurs autorisations. Par exemple, une mise à jour du micrologiciel pour l'équipement d'infrastructure critique devra être signée à la fois par l'auteur du micrologiciel et le propriétaire / opérateur de l'équipement.
• La nouvelle architecture de mise à jour du firmware IoT doit prendre en charge les fichiers manifestes.

Il s'agit bien d'un projet, car il s'agit d'un nouveau domaine. Je m'attends à ce que cela soit davantage dicté par la réglementation que par la demande des consommateurs, car les consommateurs ne se soucient vraiment pas des mises à jour ou de la sécurité à moins qu'ils ne les impactent directement. Toute amélioration dans ce domaine aura un impact sur le coût des appareils.

Si le micrologiciel de votre appareil peut être rendu moins complexe que le chargeur de démarrage requis pour une mise à jour à distance sécurisée, alors n'implémentez pas la mise à jour à distance .

Je sais que le consensus est d'avoir un chargeur de démarrage sécurisé et robuste, avec une authentification cryptographique publique forte, des mécanismes de basculement sûrs, peut-être une pile réseau de base, puis mettre en plus un RTOS, avec une pile réseau IP + TLS complète, puis ajouter en plus de cela, votre application. C'est de la folie pure pour un appareil à faible consommation et à faible coût. À mon humble avis, cela conduit à des produits qui sont mis à jour toutes les semaines environ, ce qui a tendance à déranger les utilisateurs car parfois les mises à jour commencent au mauvais moment, échouent ou cassent quelque chose. Les mises à jour consomment également beaucoup d'énergie, de sorte que l'utilisateur doit charger plus souvent. Et la sécurité est encore loin d'être garantie car la surface d'attaque est grande.

Votre appareil effectue une détection / activation de base, peut-être un certain déclenchement / affichage local mais pas beaucoup? Sautez tout ça.

Écrivez du code nu, utilisez une pile très basique, auditez-la soigneusement, faites une vérification formelle si possible. Et puis, vous pouvez être relativement confiant que votre appareil n'aura pas de problèmes de sécurité pour la prochaine décennie.

Si vous n'avez qu'un marteau, tout ressemble à un clou. Et c'est pourquoi la plupart des codeurs essaient d'écrire du code pour sécuriser leur code existant non sécurisé. Écrire moins de code ne vient pas toujours naturellement.