5 meilleures pratiques pour les mises à jour en direct

Dans mon dernier article, j’ai exploré comment les mises à jour OTA sont généralement effectuées à l’aide d’Amazon Web Services (AWS) et de FreeRTOS. Les mises à jour OTA sont d’une importance cruciale pour les développeurs disposant d’appareils connectés. Dans l’article d’aujourd’hui, nous allons explorer plusieurs bonnes pratiques que les développeurs doivent garder à l’esprit lors de la mise en œuvre de leur solution OTA. La plupart de ces pratiques seront génériques, bien qu’il y en ait quelques-unes spécifiques à AWS.

Meilleure pratique n°1 – Nommez votre compartiment S3 avec afr-ota

Il existe une petite astuce avec la création de compartiments S3 pour aider un développeur intégré à simplifier le processus de développement en ne parcourant pas trop de politiques AWS.

Quiconque a tenté de créer une mise à jour OTA avec AWS et FreeRTOS sait qu’il faut configurer plusieurs autorisations pour permettre à une tâche de mise à jour OTA d’accéder au compartiment S3. Une bonne pratique consiste à nommer votre compartiment S3 de sorte qu’il commence par « afr-ota », puis le compartiment S3 sera automatiquement associé à la stratégie gérée AWS AmazonFreeRTOSOTAUpdate. (Voir Créer un rôle de service de mise à jour OTA pour plus de détails). C’est une petite aide, mais une bonne pratique à connaître.

Meilleure pratique n°2 – Chiffrez vos mises à jour de firmware

Les logiciels embarqués peuvent être coûteux à développer car ils prennent du temps à créer et à tester et peuvent consommer un pourcentage important du budget de développement. C’est un mal nécessaire car le logiciel permet la plupart des ensembles de fonctionnalités dans un produit et peut considérablement différencier un produit. Le logiciel est une propriété intellectuelle (IP) qui mérite d’être protégée par cryptage.

Le chiffrement d’une image de micrologiciel offre plusieurs avantages. Premièrement, il peut convertir le binaire de votre firmware en une forme qui semble aléatoire ou dénuée de sens, ce qui rend plus difficile l’étude, l’investigation et l’ingénierie inverse. Cela rend plus difficile pour quelqu’un de le voler et plus difficile à pirater lors d’une cyber-attaque.

En outre, le chiffrement de l’image signifie que l’expéditeur doit disposer d’une clé ou d’un identifiant qui correspond à l’appareil afin de déchiffrer l’image. Il s’agit d’un moyen simple d’authentifier la source, bien qu’il faille faire plus qu’un simple cryptage pour authentifier complètement et vérifier l’intégrité de l’image.

Meilleure pratique n°3 – Ne prend pas en charge les restaurations de firmware

Il y a souvent un débat pour savoir si les restaurations de firmware doivent être prises en charge ou non. Ma recommandation pour une meilleure pratique est que les restaurations de firmware soient désactivées. L’argument en faveur des restaurations est souvent que si quelque chose ne va pas avec une mise à jour du micrologiciel, l’utilisateur peut revenir à une ancienne version qui fonctionnait. Cela semble être une bonne idée au début, mais cela peut être une source de vulnérabilité dans un système. Par exemple, disons que la version 1.7 avait un bogue dans le système qui permettait à des attaquants distants d’accéder au système. Une nouvelle version du firmware, 1.8, corrige cette faille. Un client met à jour son micrologiciel vers la version 1.8, mais un attaquant sait que s’il peut forcer le système à revenir à la version 1.7, il peut contrôler le système. Les restaurations de firmware semblent être une bonne idée, mais dans le monde connecté d’aujourd’hui où nous effectuons de plus en plus de mises à jour OTA, les restaurations de firmware peuvent être une vulnérabilité.

Meilleure pratique n°4 – Sécurisez votre bootloader

La mise à jour du micrologiciel sans fil nécessite plusieurs composants pour s’assurer qu’elle est effectuée en toute sécurité et avec succès. Souvent, l’accent est mis sur l’obtention de la nouvelle image sur l’appareil et son décryptage. Cependant, tout comme dans les mises à jour de firmware traditionnelles, le chargeur de démarrage est toujours un élément essentiel du processus de mise à jour et le chargeur de démarrage doit être sécurisé.

Il existe de nombreuses méthodes sécurisées pouvant être utilisées avec le chargeur de démarrage intégré. Les chargeurs de démarrage sécurisés doivent être capables de vérifier l’authenticité et l’intégrité du micrologiciel avant qu’il ne soit chargé. Certains systèmes utiliseront le code d’application pour vérifier et installer le micrologiciel dans un nouvel emplacement d’application tandis que d’autres s’appuient entièrement sur le chargeur de démarrage. Dans les deux cas, le chargeur de démarrage sécurisé doit pouvoir vérifier l’authenticité et l’intégrité du micrologiciel avant d’accepter la nouvelle image du micrologiciel.

C’est aussi une bonne idée de s’assurer que le chargeur de démarrage est intégré dans une chaîne de confiance et ne peut pas être facilement modifié ou mis à jour. Le chargeur de démarrage sécurisé est un composant essentiel dans une chaîne de confiance qui est nécessaire pour maintenir un système sécurisé.

Meilleure pratique n°5 – Construire une chaîne de confiance

Une chaîne de confiance est une séquence d’événements qui se produisent lors du démarrage de l’appareil et qui garantit que chaque maillon de la chaîne est un logiciel de confiance. Par exemple, j’ai travaillé avec les MCU sécurisés Cypress PSoC 64 livrés avec une racine de confiance matérielle pour authentifier la source sécurisée du matériel. Cette racine de confiance (RoT) est ensuite transférée à un développeur, qui programme un chargeur de démarrage sécurisé et des politiques de sécurité sur l’appareil. Au cours de la séquence de démarrage, le RoT vérifie l’intégrité et l’authenticité du chargeur de démarrage, qui vérifie ensuite l’intégrité et l’authenticité de tout chargeur de démarrage ou logiciel de deuxième étape, qui vérifie ensuite l’authenticité et l’intégrité de l’application. L’application vérifie ensuite l’authenticité et l’intégrité de ses données, clés, paramètres opérationnels, etc.

Cette séquence crée une chaîne de confiance qui est nécessaire et utilisée par les mises à jour OTA du micrologiciel. Lorsque la demande de nouveau micrologiciel est effectuée, l’application doit déchiffrer l’image et vérifier que l’authenticité et l’intégrité du nouveau micrologiciel sont intactes. Ce nouveau micrologiciel ne peut alors être utilisé que si la chaîne de confiance parvient à se frayer un chemin à travers chaque maillon de la chaîne. En fin de compte, un développeur et l’utilisateur final savent que lorsque le système démarre avec succès, le nouveau micrologiciel est légitime.

Conclusion

Les mises à jour OTA sont un composant d’infrastructure critique pour presque tous les appareils IoT intégrés. Bien sûr, il existe des systèmes qui, une fois déployés, ne se mettront jamais à jour, cependant, il s’agit probablement d’un petit pourcentage de systèmes. Les mises à jour OTA sont le mécanisme incontournable pour mettre à jour le micrologiciel sur le terrain. Nous avons examiné plusieurs bonnes pratiques que les développeurs et les entreprises doivent prendre en compte lors de la conception de leurs systèmes connectés. En fait, la meilleure pratique en prime pour aujourd’hui est que si vous construisez un appareil connecté, assurez-vous d’explorer votre solution de mise à jour OTA le plus tôt possible. Sinon, vous constaterez peut-être que la création de cette chaîne de confiance nécessaire dans les déploiements d’aujourd’hui sera beaucoup plus coûteuse et longue à mettre en œuvre.