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’un utilisateur malveillant ne les a pas modifiés. 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. Le service Mise à jour de l’appareil signe ce manifeste de mise à jour.
Une fois les fichiers binaires des mises à jour importés dans le service et stockés dans Azure, le service Stockage Azure les chiffre automatiquement, ainsi que les métadonnées client associées. 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 valide la signature pour déterminer si elle 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 est 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 contient 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. Microsoft contrôle les clés privées correspondantes.
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 service génère le manifeste de mise à jour, 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 ces informations 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, l’agent Device Update fait confiance au manifeste de mise à jour. É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 ne sont pas modifié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 doit ê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 août 2025.
À partir de la version 1.1.0 de l’agent de mise à jour des périphériques, l’agent vérifie automatiquement les modifications apportées aux clés racines à chaque fois qu’une mise à jour est déployée pour ce périphérique. Modifications possibles :
- Une nouvelle clé racine est disponible.
- Une clé racine existante est désactivée (en fait « révoquée »), ce qui signifie qu’elle n’est plus valable pour établir la confiance.
Si l’une ou l’autre est vraie, l’agent Device Update 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 et une liste de clés désactivées contenant des informations sur les clés racines et/ou les clés de signature qui ne sont plus valides. Le paquet de clés racine est lui-même signé avec chaque clé racine, de sorte que la confiance dans le paquet peut être établie à la fois à partir des clés racine originales qui font partie de l’agent DU lui-même, et de toutes les clés racine téléchargées ultérieurement. Une fois le processus de validation terminé, toute nouvelle clé racine est considérée comme fiable pour valider la confiance avec la clé de signature pour un manifeste de mise à jour donné, tandis que toute clé racine ou clé de signature figurant dans la liste des clés désactivées n’est plus fiable à cette fin.
Signatures
Une clé de signature (publique) signée par l’une des clés racines accompagne toutes les signatures. 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 plus rapide que celle des clés racine. Vous devez donc vous attendre à ce que les messages soient signés par différentes clés de signature.
Le service Device Update gère la révocation des clés de signature si nécessaire, 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. Ce dernier cas nécessite la signature numérique du code de l’agent Device Update et l’activation de la prise en charge de l’intégrité du code du système 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.