Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Portage de la bibliothèque de mise à jour AWS IoT over-the-air (OTA)
Avec les mises à jour de over-the-air FreeRTOS (OTA), vous pouvez effectuer les opérations suivantes :
-
Déployer les nouvelles images du microprogramme sur un seul appareil, un groupe d'appareils ou l'ensemble de votre flotte.
-
Déployez le microprogramme sur les appareils au fur et à mesure qu'ils sont ajoutés à des groupes, réinitialisés ou reprovisionnés.
-
Vérifiez l'authenticité et l'intégrité du nouveau microprogramme après son déploiement sur les appareils.
-
Surveiller la progression d'un déploiement.
-
Déboguer un déploiement ayant échoué.
-
Signez numériquement le microprogramme à l'aide de Code Signing for AWS IoT.
Pour plus d'informations, consultez les mises à jour en direct de FreeRTOS dans le guide de l'utilisateur de FreeRTOS ainsi que dans la documentation relative à O Update.AWS IoT ver-the-air
Vous pouvez utiliser la bibliothèque de mise à jour OTA pour intégrer la fonctionnalité OTA dans vos applications FreeRTOS. Pour plus d'informations, consultez la bibliothèque de mise à jour de FreeRTOS OTA dans le guide de l'utilisateur de FreeRTOS.
Les appareils FreeRTOS doivent appliquer la vérification de signature de code cryptographique sur les images du microprogramme OTA qu'ils reçoivent. Nous vous recommandons les algorithmes suivants :
-
L’algorithme ECDSA (Elliptic Curve Digital Signature Algorithm)
-
La courbe NIST P256
-
Le hachage SHA-256
Prérequis
-
Complétez les instructions dansConfiguration de votre espace de travail et de votre projet pour le portage.
-
Créez un port d'interface de transport réseau.
Pour plus d’informations, veuillez consulter Portage de l'interface de transport réseau.
-
Intégrez la bibliothèque CoreMQTT. Voir la bibliothèque CoreMQTT dans le guide de l'utilisateur de FreeRTOS.
-
Créez un bootloader capable de prendre en charge les mises à jour OTA.
Portage de plateformes
Vous devez fournir une implémentation de la couche d'abstraction portable OTA (PAL) pour porter la bibliothèque OTA vers un nouveau périphérique. Les API PAL sont définies dans le fichier ota_platform_interface.h
Nom de la fonction |
Description |
|---|---|
|
Arrête une mise à jour OTA. |
|
Crée un fichier pour stocker les blocs de données reçus. |
|
Ferme le fichier spécifié. Cela peut authentifier le fichier si vous utilisez un stockage qui implémente une protection cryptographique. |
|
Écrit un bloc de données dans le fichier spécifié au décalage donné. En cas de succès, la fonction renvoie le nombre d'octets écrits. Dans le cas contraire, la fonction renvoie un code d'erreur négatif. La taille du bloc sera toujours une puissance de deux et sera alignée. Pour plus d'informations, consultez la section Configuration de la bibliothèque OTA |
|
Active ou lance la nouvelle image du microprogramme. Pour certains ports, si le périphérique est réinitialisé par programmation synchrone, cette fonction ne sera pas rétablie. |
|
Fait que ce qui est requis par la plateforme pour accepter ou rejeter l’image la plus récente du microprogramme OTA (ou bundle). Pour implémenter cette fonction, consultez la documentation relative aux détails et à l'architecture de votre tableau (plate-forme). |
|
Permet d'obtenir l'état de l'image de la mise à jour OTA. |
Implémentez les fonctions de ce tableau, si votre appareil intègre une prise en charge de ces dernières.
Nom de la fonction |
Description |
|---|---|
|
Vérifie la signature du fichier spécifié. |
|
Lit le certificat de signataire spécifiée à partir du système de fichiers et le renvoie à l'appelant. |
|
Réinitialise l'appareil. |
Note
Assurez-vous que vous avez un chargeur de démarrage pouvant prendre en charge les mises à jour OTA. Pour obtenir des instructions sur la création du chargeur de démarrage de votre AWS IoT appareil, consultezChargeur de démarrage pour périphériques IoT.
Tests E2E et PAL
Exécutez les tests OTA PAL et E2E.
Tests E2E
Le test OTA de bout en bout (E2E) est utilisé pour vérifier la capacité OTA d'un appareil et pour simuler des scénarios à partir de la réalité. Ce test inclura la gestion des erreurs.
Prérequis
Pour transférer ce test, vous avez besoin des éléments suivants :
Un projet avec une bibliothèque AWS OTA intégrée. Consultez le guide de portage des bibliothèques OTA
pour plus d'informations. Portez l'application de démonstration à l'aide de la bibliothèque OTA avec laquelle interagir AWS IoT Core pour effectuer les mises à jour OTA. veuillez consulter Portage de l'application de démonstration OTA.
Configurez l'outil IDT. Cela exécute l'application hôte OTA E2E pour créer, flasher et surveiller l'appareil avec différentes configurations, et valide l'intégration de la bibliothèque OTA.
Portage de l'application de démonstration OTA
Le test OTA E2E doit disposer d'une application de démonstration OTA pour valider l'intégration de la bibliothèque OTA. L'application de démonstration doit être capable d'effectuer des mises à jour du microprogramme OTA. Vous pouvez trouver l'application de démonstration FreeRTOS OTA dans le référentiel FreeRTOS. GitHub
Étapes de portage
Initialisez l'agent OTA.
Implémentez la fonction de rappel de l'application OTA.
Créez la tâche de traitement des événements de l'agent OTA.
Démarrez l'agent OTA.
Surveillez les statistiques des agents OTA.
Arrêtez l'agent OTA.
Visitez FreeRTOS OTA over MQTT - Point d'entrée de la démo pour obtenir des instructions détaillées
Configuration
Les configurations suivantes sont nécessaires pour interagir avec AWS IoT Core :
AWS IoT Core informations d'identification du client
Configurez DemoConfigRoot_CA_PEM avec les points de terminaison Amazon Trust Services.
Ota_Over_Mqtt_Demo/demo_config.hVoir AWS Authentification du serveur pour plus de détails.Configurez DemoConfigClient_Certificate_pem et DemoConfigClient_Private_Key_PEM avec les informations d'identification de votre client.
Ota_Over_Mqtt_Demo/demo_config.hAWS IoT Consultez les informations relatives àAWS l'authentification des clients pour en savoir plus sur les certificats clients et les clés privées.
Version de l'application
Protocole de contrôle OTA
Protocole de données OTA
Identifiants de signature de code
Autres configurations de bibliothèques OTA
Vous trouverez les informations précédentes dans demo_config.h et ota_config.h dans les applications de démonstration de FreeRTOS OTA. Consultez FreeRTOS OTA over MQTT - Configuration
Vérification des builds
Exécutez l'application de démonstration pour exécuter la tâche OTA. Une fois l'opération terminée avec succès, vous pouvez continuer à exécuter les tests OTA E2E.
La démo de FreeRTOS OTA
Exécution de tests avec l'outil IDT
Pour exécuter les tests OTA E2E, vous devez utiliser AWS IoT Device Tester (IDT) pour automatiser l'exécution. Voir FreeRTOS dans le Guide de l'utilisateur de FreeRTOS AWS IoT Device Tester pour plus de détails.
Cas de test E2E
Cas de test |
Description |
|---|---|
|
Bon test de trajectoire pour les mises à jour régulières de l'OTA. Il crée une mise à jour avec une version plus récente, que l'appareil met à jour avec succès. |
|
Ce test crée 3 mises à jour OTA consécutives. L'appareil devrait être mis à jour 3 fois de suite. |
|
Ce test vérifie que l'appareil revient au microprogramme précédent s'il ne peut pas se connecter au réseau avec le nouveau microprogramme. |
|
Ce test confirme que l'appareil rejette le microprogramme entrant si la version reste la même. |
|
Ce test vérifie que l'appareil rejette une mise à jour si l'image n'est pas signée. |
|
Ce test vérifie que l'appareil rejette une mise à jour si le microprogramme est signé avec un certificat non fiable. |
|
Ce test vérifie que l'appareil rejette une ancienne version de mise à jour. |
|
Différents appareils prennent en charge différents algorithmes de signature et de hachage. Ce test vérifie que l'appareil échoue à la mise à jour OTA s'il est créé avec un algorithme non pris en charge. |
|
Il s'agit d'un test de réussite pour la fonctionnalité de suspension et de reprise. Ce test crée une mise à jour OTA et démarre la mise à jour. Il se connecte ensuite AWS IoT Core avec le même identifiant client (nom de l'objet) et les mêmes informations d'identification. AWS IoT Core puis déconnecte l'appareil. L'appareil est censé détecter qu'il est déconnecté et AWS IoT Core, au bout d'un certain temps, passer à l'état suspendu, essayer de se reconnecter AWS IoT Core et de reprendre le téléchargement. |
|
Ce test vérifie si l'appareil peut se rétablir lui-même si la tâche OTA est annulée alors qu'il est suspendu. Il fait la même chose que le |
|
Lorsqu'une mise à jour OTA est créée, vous pouvez configurer la durée de vie de l'URL pré-signée S3. Ce test vérifie que l'appareil est capable d'effectuer une OTA, même s'il ne peut pas terminer le téléchargement lorsque l'URL expire. L'appareil est censé demander un nouveau document de travail contenant une nouvelle URL pour reprendre le téléchargement. |
|
Ce test crée deux mises à jour OTA d'affilée. Lorsque l'appareil signale qu'il télécharge la première mise à jour, le test force l'annule. L'appareil est censé abandonner la mise à jour en cours, récupérer la deuxième mise à jour et la terminer. |
|
Ce test crée deux mises à jour OTA d'affilée. Lorsque l'appareil signale qu'il télécharge la première mise à jour, le test force l'annule. L'appareil est censé abandonner la mise à jour en cours et récupérer la deuxième mise à jour, puis la terminer. |
|
Ce test vérifie que l'appareil est capable de rejeter une mise à jour lorsque l'image tombe en panne. |
Tests PAL
Prérequis
Pour porter les tests de l'interface de transport réseau, vous avez besoin des éléments suivants :
Un projet capable de créer FreeRTOS avec un port de noyau FreeRTOS valide.
Une implémentation fonctionnelle d'OTA PAL.
Portage
Ajoutez FreeRTOS-Libraries-Integration-Tests
en tant que sous-module dans votre projet. L'emplacement du sous-module dans le projet doit être là où il peut être construit. Copiez
config_template/test_execution_config_template.hetconfig_template/test_param_config_template.hvers un emplacement dans le chemin de construction, et renommez-les entest_execution_config.hettest_param_config.h.Incluez les fichiers pertinents dans le système de compilation. Si vous l'utilisez
CMake,qualification_test.cmakeetsrc/ota_pal_tests.cmakepeut être utilisé pour inclure les fichiers pertinents.Configurez le test en implémentant les fonctions suivantes :
SetupOtaPalTestParam(): défini danssrc/ota/ota_pal_test.h. L'implémentation doit avoir le même nom et la même signature que ceux définis dansota_pal_test.h. Pour le moment, il n'est pas nécessaire de configurer cette fonction.
Implémentez UNITY_OUTPUT_CHAR afin que les journaux de sortie des tests ne soient pas entrelacés avec les journaux des périphériques.
Appelez
RunQualificationTest()depuis l'application. Le matériel de l'appareil doit être correctement initialisé et le réseau doit être connecté avant l'appel.
Test
Cette section décrit les tests locaux des tests de qualification OTA PAL.
Activez le test
Ouvrez test_execution_config.h et définissez OTA_PAL_TEST_ENABLED sur 1.
Danstest_param_config.h, mettez à jour les options suivantes :
OTA_PAL_TEST_CERT_TYPE : sélectionnez le type de certificat utilisé.
OTA_PAL_CERTIFICATE_FILE : chemin d'accès au certificat de l'appareil, le cas échéant.
OTA_PAL_FIRMWARE_FILE : nom du fichier du microprogramme, le cas échéant.
OTA_PAL_USE_FILE_SYSTEM : défini sur 1 si l'OTA PAL utilise l'abstraction du système de fichiers.
Créez et flashez l'application à l'aide de la chaîne d'outils de votre choix. Lorsque le RunQualificationTest() est appelé, les tests OTA PAL s'exécutent. Les résultats des tests sont transmis au port série.
Intégration des tâches OTA
Ajoutez un agent OTA à votre démo MQTT actuelle.
Exécutez des tests OTA de bout en bout (E2E) avec AWS IoT. Cela permet de vérifier si l'intégration fonctionne comme prévu.
Note
Pour qualifier officiellement un appareil pour FreeRTOS, vous devez valider le code source porté de l'appareil par rapport aux groupes de test OTA PAL et OTA E2E avec. AWS IoT Device Tester Suivez les instructions de la section Utilisation AWS IoT Device Tester pour FreeRTOS du Guide de l'utilisateur de FreeRTOS pour configurer la validation des ports. AWS IoT Device Tester Pour tester le port d'une bibliothèque spécifique, le groupe de test approprié doit être activé dans le device.json fichier du AWS IoT Device Tester configs dossier.
Chargeur de démarrage pour périphériques IoT
Vous devez fournir votre propre application de bootloader sécurisée. Assurez-vous que la conception et la mise en œuvre permettent d'atténuer correctement les menaces de sécurité. Vous trouverez ci-dessous la modélisation des menaces à titre de référence.
Modélisation des menaces pour le chargeur de démarrage de périphérique IoT
Contexte
À titre de définition pratique, les AWS IoT appareils embarqués auxquels fait référence ce modèle de menace sont des produits basés sur des microcontrôleurs qui interagissent avec les services cloud. Ils peuvent être déployés dans des environnements grand public, commerciaux ou industriels. Les périphériques IoT peuvent collecter des données sur un utilisateur, un patient, une machine ou un environnement, que ce soit des ampoules, des verrous de porte ou des machines d'usine.
La modélisation des menaces est une approche de la sécurité du point de vue d'un adversaire hypothétique. En tenant compte des objectifs et des méthodes de l'adversaire, une liste de menaces est créée. Les menaces sont des attaques contre une ressource ou un asset réalisées par un adversaire. La liste est priorisée et utilisée pour identifier et créer des solutions d'atténuation. Lors du choix d'une solution d'atténuation, le coût de sa mise en œuvre et de sa maintenance doit être mis en balance avec la valeur de sécurité réelle qu'elle apporte. Il existe plusieurs méthodologies de modèle de menace
FreeRTOS propose des mises à jour logicielles OTA over-the-air () pour les appareils. AWS IoT Le processus de mise à jour associe des services cloud à des bibliothèques logicielles sur périphérique et un chargeur de démarrage fourni par un partenaire. Ce modèle de menace se concentre spécifiquement sur les menaces contre le chargeur de démarrage.
Cas d'utilisation du chargeur de démarrage
-
Signer numériquement et chiffrer les microprogrammes avant le déploiement.
-
Déployer les nouvelles images du microprogramme sur un seul appareil, un groupe d'appareils ou l'ensemble d’une flotte.
-
Vérifier l'authenticité et l'intégrité du nouveau microprogramme après qu'il a été déployé sur les appareils.
-
Les périphériques exécutent uniquement des logiciels non modifiés à partir d'une source approuvée.
-
Les périphériques sont résistants aux logiciels défaillants reçus via OTA.
Diagramme de flux de données
Menaces
Certaines attaques utilisent plusieurs modèles d'atténuation ; par exemple, un réseau man-in-the-middle destiné à fournir une image de microprogramme malveillant est atténué en vérifiant la fiabilité à la fois du certificat proposé par le serveur TLS et du certificat du signataire de code de la nouvelle image du microprogramme. Pour optimiser la sécurité du chargeur de démarrage, toute solution d'atténuation autre que le chargeur de démarrage est considérée comme peu fiable. Le bootloader doit disposer de solutions d'atténuation intrinsèques pour chaque attaque. Les solutions d'atténuation en couches sont connues sous le nom de defense-in-depth.
Menaces :
-
Un pirate détourne la connexion du périphérique au serveur pour diffuser une image de microprogramme malveillante.
Exemple d'atténuation
-
Au démarrage, le chargeur de démarrage vérifie la signature cryptographique de l'image à l'aide d'un certificat connu. Si la vérification échoue, le chargeur de démarrage revient à l'image précédente.
-
-
Un pirate exploite un dépassement de mémoire tampon pour introduire un comportement malveillant dans l'image du microprogramme existante stockée en flash.
Exemples d'atténuation
-
Au démarrage, le chargeur de démarrage procède à une vérification, comme décrit précédemment. Lorsque la vérification échoue et qu'aucune image précédente n'est disponible, le chargeur de démarrage s'arrête.
-
Au démarrage, le chargeur de démarrage procède à une vérification, comme décrit précédemment. Lorsque la vérification échoue et qu'aucune image précédente n'est disponible, le chargeur de démarrage passe en mode OTA à sécurité intégrée uniquement.
-
-
Un pirate démarre le périphérique sur une image précédemment stockée, qui est exploitable.
Exemples d'atténuation
-
Les secteurs Flash stockant la dernière image sont effacés lors de l'installation réussie et du test d'une nouvelle image.
-
Un fusible est grillé à chaque mise à niveau réussie, et chaque image refuse de s'exécuter, sauf si le nombre correct de fusibles a été grillé.
-
-
Une mise à jour OTA fournit une image défectueuse ou malveillante qui détaille le périphérique.
Exemple d'atténuation
-
Le chargeur de démarrage démarre un minuteur de surveillance matériel qui déclenche la restauration de l'image précédente.
-
-
Un pirate applique des correctifs au chargeur de démarrage pour contourner la vérification d'image afin que le périphérique accepte les images non signées.
Exemples d'atténuation
-
Le chargeur de démarrage est en ROM (mémoire en lecture seule) et ne peut pas être modifié.
-
Le bootloader est en OTP (one-time-programmable mémoire) et ne peut pas être modifié.
-
Le bootloader se trouve dans la zone sécurisée d'ARM TrustZone et ne peut pas être modifié.
-
-
Un pirate remplace le certificat de vérification afin que le périphérique accepte les images malveillantes.
Exemples d'atténuation
-
Le certificat se trouve dans un co-processeur cryptographique et ne peut pas être modifié.
-
Le certificat se trouve dans la ROM (ou OTP, ou zone sécurisée) et ne peut pas être modifié.
-
Modélisation plus poussée des menaces
Ce modèle de menace prend uniquement en compte le chargeur de démarrage. Une modélisation plus poussée des menaces pourrait améliorer la sécurité globale. Une méthode recommandée consiste à répertorier les objectifs de l'adversaire, les assets ciblés par ces objectifs et les points d'entrée des assets. Une liste des menaces peut être établie en prenant en compte les attaques sur les points d'entrée destinées à prendre le contrôle des assets. Vous trouverez ci-après des listes d’exemples d'objectif, d'asset et de point d'entrée pour un périphérique IoT. Ces listes ne sont pas exhaustives et ont pour but de stimuler la réflexion.
Objectifs de l'adversaire
-
Extorquer de l'argent
-
Nuire à une réputation
-
Falsifier des données
-
Détourner des ressources
-
Espionner une cible à distance
-
Obtenir un accès physique à un site
-
Provoquer de gros dégâts
-
Instaurer la terreur
Ressources clés
-
Clés privées
-
Certificat de client
-
Certificats racines d’autorité de certification
-
Informations d'identification et jetons de sécurité
-
Informations personnelles identifiables d’un client
-
Implémentations de secrets commerciaux
-
Données de capteur
-
Magasin de données d'analyse dans le cloud
-
Infrastructure cloud
Points d'entrée
-
Réponse DHCP
-
Réponse DNS
-
MQTT via TLS
-
Réponse HTTPS
-
Image logicielle OTA
-
Autre, tel que dicté par l'application, par exemple, USB
-
Accès physique au bus
-
Carte d'interface réseau délimitée
