Modèle de sécurité de Device Update
Device Update pour IoT Hub offre une méthode sécurisée pour déployer des mises à jour de microprogrammes, images et applications sur vos appareils IoT. Le workflow offre un canal sécurisé de bout en bout avec un modèle de chaîne de responsabilité complet permettant à l’appareil de s’assurer qu’une mise à jour est approuvée, non modifiée et intentionnelle.
Chaque étape du workflow Device Update est protégée par le biais de divers processus et fonctionnalités de sécurité pour garantir que les transferts entre chaque étape du pipeline sont sécurisés. Le code de référence de l’agent Device Update identifie et gère correctement toutes les demandes de mise à jour illégitimes. L’agent de référence vérifie également chaque téléchargement pour s’assurer que le contenu est approuvé, non modifié et intentionnel.
Résumé
Lorsque les mises à jour sont importées dans une instance Device Update, le service charge et vérifie les fichiers binaires de mise à jour pour s’assurer qu’ils n’ont pas été modifiés ou remplacés par un utilisateur malveillant. Après cette vérification, le service Device Update génère un manifeste de mise à jour interne avec des codes de hachage de fichier à partir du manifeste d’importation et d’autres métadonnées. Ce manifeste de mise à jour est ensuite signé par le service Device Update.
Une fois importés dans le service et stockés dans Azure, les fichiers binaires des mises à jour et les métadonnées client associées sont automatiquement chiffrés au repos par le service de stockage Azure. Le service Device Update ne fournit pas automatiquement un chiffrement supplémentaire, mais il permet aux développeurs de chiffrer eux-mêmes le contenu avant qu’il n’atteigne le service Device Update.
Lorsqu’une mise à jour est déployée sur des appareils à partir du service Device Update, un message signé est envoyé à l’appareil via le canal IoT Hub protégé. L’agent Device Update de l’appareil vérifie que la signature de la demande est authentique.
Tout téléchargement de fichier binaire qui en résulte est sécurisé par vérification de la signature du manifeste de mise à jour. Le manifeste de mise à jour contient les codes de hachage de fichiers binaires. Ainsi, quand le manifeste est approuvé, l’agent Device Update approuve les codes de hachage et les met en correspondance avec les fichiers binaires. Quand le fichier binaire de mise à jour a été téléchargé et vérifié, il est transféré au programme d’installation sur l’appareil.
Informations d’implémentation
Pour garantir que le service Device Update effectue un scale-down pour adapter les capacités aux appareils simples aux performances faibles, le modèle de sécurité utilise des clés asymétriques brutes et des signatures brutes. Elles utilisent des formats JSON, par exemple des jetons JSON Web Token et des clés web JSON.
Sécurisation du contenu des mises à jour avec le manifeste de mise à jour
Le manifeste de mise à jour est vérifié à l’aide de deux signatures. Les signatures sont créées avec une structure associant clés de signature et clés racine.
L’agent Device Update a des clés publiques incorporées qui sont utilisées pour tous les appareils compatibles avec Device Update. Ces clés publiques sont les clés racines. Les clés privées correspondantes sont contrôlées par Microsoft.
Microsoft génère également une paire de clés publique/privée qui n’est pas incluse dans l’agent Device Update ni stockée sur l’appareil. Cette clé est la clé de signature.
Quand une mise à jour est importée dans le service Device Update pour IoT Hub et que le manifeste de mise à jour est généré par le service, le service signe le manifeste à l’aide de la clé de signature et inclut la clé de signature elle-même, signée par une clé racine. Quand le manifeste de mise à jour est envoyé à l’appareil, l’agent Device Update reçoit les données de signature suivantes :
- La valeur de signature elle-même.
- L’algorithme utilisé pour générer #1.
- Les informations de clé publique de la clé de signature utilisées pour générer #1.
- La signature de la clé de signature publique dans #3.
- L’ID de clé publique de la clé racine utilisé pour générer #3.
- L’algorithme utilisé pour générer #4.
L’agent Device Update utilise les informations définies ci-dessus pour vérifier que la clé de signature publique est signée par la clé racine. Ensuite, l’agent Device Update vérifie que le manifeste de mise à jour est signé par la clé de signature. Si toutes les signatures sont correctes, le manifeste de mise à jour est approuvé par l’agent Device Update. Étant donné que le manifeste de mise à jour comprend les codes de hachage de fichier correspondant aux fichiers de mise à jour eux-mêmes, les fichiers de mise à jour peuvent également être approuvés si ces codes correspondent.
L’utilisation de clés racine et de signature permet à Microsoft de déployer périodiquement la clé de signature, ce qui s’inscrit dans les bonnes pratiques de sécurité.
Signature web JSON (JWS)
La updateManifestSignature est utilisée pour vérifier que les informations contenues dans le updateManifest n’ont pas été falsifiées. La updateManifestSignature est générée à l’aide d’une signature web JSON avec des clés web JSON, ce qui permet de vérifier la source. La signature est une chaîne encodée en Base64Url avec trois sections délimitées par « . ». Reportez-vous aux méthodes d’assistance jws_util.h pour analyser et vérifier les clés et jetons JSON.
La signature web JSON est une norme proposée par l’IETF largement utilisée pour la signature de contenu à l’aide de structures de données JSON. Elle offre un moyen de garantir l’intégrité des données en vérifiant la signature des données. Pour plus d’informations, consultez le document RFC 7515 sur la signature web JSON (JWS).
JSON Web Token
Les jetons JSON Web Token offrent une méthode standard ouverte pour représenter les revendications de manière sécurisée entre deux parties.
Clés racine
Chaque appareil Device Update doit contenir un jeu de clés racine. Ces clés sont la racine de confiance pour toutes les signatures de Device Update. Toute signature doit être chaînée par le biais de l’une de ces clés racine pour être considérée comme légitime.
L’ensemble de clés racine change au fil du temps. En effet, la rotation périodique des clés de signature est une bonne pratique de sécurité. Par conséquent, le logiciel de l’agent Device Update devra être mis à jour avec le jeu de clés racine le plus récent à des intervalles spécifiés par l’équipe Device Update. La prochaine rotation de clé racine planifiée aura lieu en mai 2025.
À compter de la version 1.1.0 de l’agent Device Update, l’agent case activée automatiquement les modifications apportées aux clés racines chaque fois qu’un déploiement d’une mise à jour sur cet appareil se produit. Modifications possibles :
- Une nouvelle clé racine est disponible.
- Une clé racine existante est désactivée (effectivement « révoquée »), ce qui signifie qu’elle n’est plus valide pour établir une approbation.
Si l’un ou l’autre des deux éléments ci-dessus est vrai, l’agent Device Update se télécharge automatiquement à partir du service DU un nouveau package de clé racine. Ce package contient l’ensemble complet de toutes les clés racines, ainsi qu’une liste désactivée contenant des informations sur les clés racines et/ou les clés de signature qui ne sont plus valides. Le package de clé racine est lui-même signé avec chaque clé racine, afin que l’approbation du package puisse être établie à partir des clés racines d’origine qui font partie de l’agent DU lui-même, ainsi que toutes les clés racines téléchargées par la suite. Une fois le processus de validation terminé, toutes les nouvelles clés racines sont considérées comme approuvées dans le but de valider l’approbation avec la clé de signature pour un manifeste de mise à jour donné, tandis que toutes les clés racines ou clés de signature répertoriées dans la liste désactivée ne sont plus approuvées à cet effet.
Signatures
Toutes les signatures s’accompagnent d’une clé de signature (publique) signée par l’une des clés racines. La signature identifie la clé racine qui a été utilisée pour signer la clé de signature.
Un agent Device Update doit vérifier les signatures en commençant par vérifier que la signature de la clé de signature (publique) est correcte et valide et que cette clé est signée par l’une des clés racine approuvées. Quand la clé de signature a été vérifiée, la signature elle-même peut être vérifiée à l’aide de la clé publique de signature désormais approuvée.
La cadence de rotation des clés de signature est bien supérieure à celle des clés racine. Vous devez donc vous attendre à ce que les messages soient signés par différentes clés de signature.
La révocation d’une clé de signature est gérée par le service Device Update. Les utilisateurs ne doivent donc pas tenter de mettre en cache les clés de signature. Utilisez toujours la clé de signature qui accompagne une signature.
Sécurisation de l’appareil
Il est important de s’assurer que les ressources de sécurité liées au service Device Update sont correctement sécurisées et protégées sur votre appareil. Les ressources telles que les clés racine doivent être protégées contre toute modification. Il existe plusieurs façons de protéger les clés racines. Par exemple, vous pouvez utiliser des dispositifs de sécurité (TPM, SGX, HSM, etc.) ou les coder de manière irréversible dans l’agent Device Update, comme c’est le cas aujourd’hui dans l’implémentation de référence. Dans ce dernier cas, le code de l’agent Device Update doit être signé numériquement et la prise en charge de l’intégrité du code du système doit être activée pour empêcher toute modification du code de l’agent par des utilisateurs malveillants.
Des mesures de sécurité supplémentaires peuvent être justifiées. Vous pouvez notamment vous assurer qu’un transfert d’un composant à un autre est effectué de façon sécurisée. Par exemple, l’inscription d’un compte isolé spécifique pour exécuter les différents composants et la limitation des communications réseau (par exemple les appels d’API REST) à localhost uniquement.