Une solution sécurisée qui connecte les appareils IoT au cloud

　　Bien que les gens soient de plus en plus conscients du besoin de sécurité, les développeurs se retrouvent souvent à prendre des raccourcis pour connecter les appareils IoT au cloud. Dans de nombreux cas, le conflit entre la complexité des mécanismes de sécurité appropriés, la mémoire et les ressources de traitement limitées disponibles dans les appareils IoT alimentés par microbatteries, et la demande pour le transport de produits semble insurmontable.

　　Pour répondre à ces problèmes et simplifier la mise en œuvre des fonctionnalités de sécurité dans les appareils IoT, Microchip Technology et Google ont collaboré pour créer une méthode combinant les fonctionnalités matérielles sécurisées de Microchip avec une structure de données simple appelée JSON Web Token (JWT). Le résultat est un moyen simple d’assurer une authentification mutuelle entre les appareils IoT et les services IoT core de Google Cloud.

　　Cet article présentera les menaces à la sécurité des appareils IoT et présentera les appareils actuellement utilisés pour y faire face. Il identifiera les vulnérabilités de sécurité et la manière dont les développeurs et concepteurs de systèmes embarqués utilisent JWT pour les désactiver.

　　Vulnérabilités de sécurité dans les appareils IoT

　　Les attaques contre les appareils IoT peuvent prendre de nombreuses formes et ne se limitent pas aux déploiements IoT à grande échelle. Pour les pirates cherchant à exploiter des ressources provenant de nombreux appareils individuels dans des botnets utilisés pour des attaques par déni de service distribué (DDoS), même le plus petit IoT est une cible attrayante. Par conséquent, les concepteurs de tous types d’appareils IoT doivent inévitablement protéger leurs systèmes grâce à des mécanismes de sécurité matériels robustes pour prévenir les attaques.

　　Par exemple, l’utilisation de la mémoire système ou du stockage flash pour stocker des clés privées de chiffrement et d’authentification rend les appareils IoT vulnérables aux attaques. Pire encore, les pirates peuvent voler ces clés et les utiliser pour accéder aux réseaux IoT et à des ressources supplémentaires de l’entreprise.

　　IC de sécurité

　　Les dispositifs de sécurité dédiés tels que les CI CryptoMemory et CryptoAuthentication de Microchip Technology disposent de fonctions matérielles basées sur des mécanismes de protection des clés privées et d’autres données secrètes. Des réseaux EEPROM sont intégrés à ces appareils, offrant un stockage sécurisé et des mécanismes de sécurité de chiffrement accessibles uniquement via l’interface série SPI ou I2C de l’appareil (voir Figure 1). Ainsi, ces appareils offrent un moyen simple d’ajouter un stockage sécurisé et d’autres fonctionnalités de sécurité à toute conception d’appareil IoT.

　　Figure 1 : Les dispositifs de sécurité matériels de la technologie Microchip (tels que AT88SC0204C CryptoMemory IC) fournissent un stockage sécurisé et utilisent des mécanismes de chiffrement intégrés pour protéger l’accès aux EEPROM embarquées. (Image : Technologie de puce électronique)

　　Les membres de la série Microchip CryptoAuthentication (comme ATECC608A) renforcent la base du stockage sécurisé et supportent des algorithmes de chiffrement couramment utilisés dans la conception de sécurité. Parmi ses fonctionnalités matérielles, l’appareil propose une accélération matérielle pour divers algorithmes, notamment :

　　Algorithme de chiffrement asymétrique :

　　Algorithme de signature numérique à courbe elliptique FIPS186-3 (ECDSA)

　　FIPS SP800-56A Courbe elliptique Diffie-Hellman (ECDH)

　　Chiffrement de courbes elliptiques standard P256 du NIST (ECC)

　　Algorithme de chiffrement symétrique :

　　Code de hachage SHA-256

　　Cryptographie par code d’authentification de messages basée sur le hachage (HMAC)

　　Cryptographie AES-128

　　Cryptographie AES-GCM (multiplication de champs de Galois)

　　Fonction de dérivation clé (KDF) :

　　Fonction pseudo-aléatoire (PRF) KDF

　　Extraction basée sur HMAC – et expansion du KDF (HKDF)

　　Pour les experts en crypto, cet ensemble de fonctionnalités de chiffrement représente une liste complète de mécanismes nécessaires pour supporter des protocoles de sécurité de haut niveau. Authentification et échange sécurisé de données. Par exemple, la fonctionnalité KDF fournit les mécanismes de base nécessaires aux protocoles de sécurité de la couche de transport (TLS) pour vérifier les participants aux sessions d’échange de données avant les échanges ou même le début.

　　Dans ce protocole, les sessions TLS envoient des requêtes des clients vers le serveur pour initier une session sécurisée. Le serveur répond en utilisant son certificat numérique, que le client utilise pour confirmer l’identité du serveur. Après que le client ait vérifié le serveur de cette manière, les paramètres de session continuent de générer des clés de session en utilisant la clé publique du serveur pour chiffrer certaines valeurs aléatoires créées avec PRF KDF ou le plus puissant HDKF.

　　Le protocole d’authentification TLS est la base de la sécurité d’Internet. L’ensemble de l’industrie des fournisseurs de certificats, connue sous le nom d’Autorité de Certification (CA), est devenue un élément clé soutenant les communications sécurisées. L’entreprise obtient un certificat de confiance de la CA pour l’installer sur ses propres serveurs, prenant en charge le protocole d’authentification TLS standard mentionné précédemment.

　　Pour les applications IoT, les réseaux sont largement et profondément connectés aux entreprises, et une telle authentification unidirectionnelle est insuffisante pour garantir la protection. Par exemple, des pirates possédant des certificats frauduleux pourraient se présenter comme des serveurs légitimes pour des appareils IoT dans le cadre d’une attaque plus large.

　　Malgré les risques, les développeurs IoT peinent souvent à mettre en place des protocoles d’authentification mutuelle TLS car les certificats, clés et logiciels nécessaires à l’authentification client via TLS peuvent dépasser les capacités de nombreux appareils IoT. Grâce à une collaboration, Microchip Technology et Google ont créé une approche alternative qui combine ATECC608A fonctionnalités avec une structure de données simple appelée JSON Web Token (JWT). Le résultat est un moyen simple d’assurer une authentification mutuelle entre les appareils IoT et les services IoT core de Google Cloud.

　　Authentification basée sur JWT

　　La RFC 7519 précise que JWT est un conteneur standard de l’industrie pour les informations sur l’entité préparant et transmettant JWT, appelé revendication. La structure JWT elle-même se compose de trois parties :

　　Titres, y compris le nom JSON : le nom de l’algorithme cryptographique (« alg ») (par exemple, « EC256 » de l’ECDSA utilise la courbe P-256 du NIST) pour signer des jetons et des types de jetons (« typ ») (le « JWT » de ces jetons)

　　Payload, incluant le nom JSON : paire de valeurs pour chaque revendication

　　Signature : Il utilise l’algorithme spécifié dans l’en-tête pour encoder la clé, l’en-tête et l’ensemble de déclarations, chacun converti individuellement en encodage d’URL base64 avant le chiffrement

　　La RFC 7519 offre une grande flexibilité pour spécifier les réclamations dans les charges utiles ou autres pièces. La norme autorise même des JWT non sûrs créés sans signature ni chiffrement, auquel cas l’en-tête inclura le nom de l’algorithme : paire de valeurs {{alg » :"none"}. Pour les JWT utilisés avec les services IoT core de Google Cloud, Google nécessite une section signature et une charge utile contenant trois déclarations obligatoires, notamment :

　　« iat » - L'« heure d’émission » lors de la création du jeton au format horodatage ISO 8601 UTC, le nombre de secondes depuis 1970-01-01T00:00:00Z (par exemple, 1561896000 12:00 GMT le 30 juin 2019)

　　« exp » - L’horodatage UTC spécifiant l’expiration du jeton, jusqu’à 24 heures dépassant la valeur « IAT » plus une période de grâce de 10 minutes, afin de corriger les différents biais d’horloge système entre client et serveur (par exemple, 1er juillet 2019 1561982400, GMT 00:00 00:00)

　　« aud » – une chaîne contenant l’ID de projet Google Cloud du développeur

　　< p> la solution d’authentification IoT des appareils de Google combine l’authentification serveur conventionnelle basée sur TLS avec JWT, créée à partir de ces déclarations relativement simples pour l’authentification des appareils IoT. Pour lancer une nouvelle session, l’appareil IoT ouvre un socket sécurisé vers le serveur et authentifie le serveur en utilisant le même protocole TLS décrit précédemment.

　　L’étape suivante de ce processus repose sur le protocole léger de transmission de télémétrie en file d’attente de messages (MQTT) de Google IoT Cloud pour les transactions réseau IoT. En utilisant un socket sécurisé vers un serveur authentifié, l’appareil IoT utilise son JWT unique comme mot de passe de connexion pour « se connecter » au service hôte MQTT sur ce serveur (Inventaire 1).

　　Bien que les appareils IoT envoient des noms d’utilisateur dans le cadre de cette séquence de connexion, les noms d’utilisateur ne sont pas utilisés pour l’authentification. Par conséquent, un nom d’utilisateur virtuel (Fiche 2) a été transféré. À la place, l’authentification des appareils IoT est basée sur JWT envoyé comme mot de passe de connexion. Puisque les signatures JWT sont une combinaison d’en-têtes, de charges utiles et de clés privées d’appareils, les services IoT core de Google Cloud peuvent vérifier si JWT provient réellement d’appareils autorisés. Pour cette vérification, Google Cloud IoT Services utilise des clés publiques d’appareils précédemment stockées dans Google Cloud par les développeurs d’appareils IoT via le processus de gestion des clés décrit ci-dessous. Comparé à l’utilisation exclusive de TLS, cette approche offre une authentification mutuelle via une approche hybride, accélérant les processus tout en réduisant les besoins en ressources pour les appareils IoT.

　　Facteurs clés

　　ATECC608A et la fonctionnalité de sa chaîne d’approvisionnement sont des moteurs clés de cette approche. Bien que n’importe quel MCU puisse éventuellement générer des signatures de chiffrement chiffrées à partir des en-têtes et charges utiles JWT, toute méthode uniquement logicielle reste vulnérable aux attaques sans stockage matériel de clés de sécurité. De plus, pour de nombreux appareils ou applications IoT limités en ressources et nécessitant des délais de réponse stricts, la charge du processeur et la latence d’exécution requises pour une implémentation « uniquement logicielle » peuvent être interdites. Enfin, sans algorithmes de sécurité étendus et une expérience plus avancée en protocoles, il est difficile pour les développeurs de mettre en œuvre les fonctions logicielles requises. Microchip répond à ces problèmes via sa bibliothèque CryptoAuthLib (Figure 2).

　　Figure 2 : Parce que CryptoAuthLib utilise la couche d’abstraction matérielle (HAL) pour séparer les fonctions API et les primitives centrales du matériel sous-jacent, les développeurs peuvent positionner leur logiciel pour divers dispositifs supportés. (Image : Technologie de puce électronique)

　　Microchip CryptoAuthLib simplifie la mise en œuvre de fonctionnalités IoT sécurisées, telles que le protocole d’authentification Google JWT, réduisant les opérations de sécurité complexes à un ensemble d’appels de fonctions fournis via l’interface de programmation d’applications (API) CryptoAuthLib. Pour les développeurs IoT, la plus importante est sans doute la fonctionnalité centrale Microchip CryptoAuthLib, qui exploite pleinement les circuits intégrés de chiffrement Microchip tels que ATECC608A pour accélérer l’exécution des fonctionnalités de sécurité dans la conception. Par exemple, dans la Fiche 1, un appel à atca_jwt_finalize() utilise des dispositifs de chiffrement disponibles (comme ATECC608A) pour créer un JWT pour le mot de passe dans la Fiche 2. Dans ce cas, ATECC608A accélérer le chiffrement des signatures JWT, lisez la conception depuis sa clé de stockage sécurisée intégrée jusqu’à compléter le processus de création de signature décrit précédemment.

　　Cependant, même avec des logiciels complexes et des dispositifs de sécurité, les appareils IoT restent vulnérables aux attaques en raison des méthodes traditionnelles de gestion des clés et des certificats. Autrefois, les clés privées devaient être générées en externe et chargées sur des dispositifs de stockage sécurisés lors de la fabrication, de la distribution, voire du déploiement. Même lorsqu’on utilise des modules de sécurité matériels et des installations de sécurité, des secrets brièvement existants au-delà du seul appareil « besoin de les connaître » représentent des vulnérabilités de sécurité qui pourraient être exposées accidentellement ou intentionnellement. En tirant parti de ATECC608A capacités, Microchip et Google ont largement éliminé les vulnérabilités de sécurité traditionnelles.

　　Dans cette nouvelle approche, Microchip utilise la capacité du ATECC608A à générer des paires de clés sans laisser l’appareil avec une clé privée (Figure 3). Microchip utilise ensuite un certificat intermédiaire pour signer la clé publique générée par l’appareil, fournie par le client et stockée sur un serveur sécurisé au sein des installations de sécurité de Microchip. Enfin, Microchip transmet de manière sécurisée la clé publique au compte client dans le Google Cloud IoT Device Manager, qui peut stocker jusqu’à trois clés publiques par appareil pour soutenir les politiques de rotation des clés. Après le déploiement, les appareils IoT peuvent utiliser ATECC608A fonctionnalités de sécurité pour créer des JWT utilisés dans le processus d’authentification mutuelle décrit précédemment.

　　Figure 3 : La combinaison de la technologie Microchip et des services IoT Google Cloud simplifie la configuration des clés et des certificats, offrant un mécanisme protégé visant à renforcer la sécurité des applications IoT. (Image : Google)

　　Cette collaboration entre Microchip et Google permet aux développeurs de se débarrasser complètement de ce processus critique de gestion des clés. Pour les besoins personnalisés, les développeurs peuvent utiliser la fonction API CryptoAuthLib atcab_genkey() pour implémenter leur propre processus de gestion de clés, ce qui permet ATECC608A de générer des paires de clés, de stocker des clés privées dans leur stockage sécurisé et de restituer la clé publique associée. /p>

　　Pour explorer la génération de clés et d’autres fonctionnalités de sécurité ATECC608A, les développeurs peuvent rapidement construire un environnement de développement complet basé sur le kit d’évaluation Microchip SAM D21 Xplained Pro. Basé sur Microchip ATSAMD21J18A Arm ® Cortex-M0 ® 32 bits + MCU, le kit SAM D21 Xplained Pro fournit un pilote matériel complet et un module de code supporté par l’Advanced Software Framework (ASF) de Microchip.

　　Pour évaluer les dispositifs de cryptoauthentification, y compris ATECC608A, les développeurs peuvent simplement insérer la carte additionnelle XPRO-B CryptoAuth dans l’une des deux têtes d’extension de la carte Xplained Pro. Microchip fournit un exemple de logiciel pour évaluer les fonctionnalités de sécurité de CryptoAuthLib et ATECC608A. De plus, les développeurs peuvent insérer la carte accessoire Microchip ATWINC1500-XPRO Wi-Fi dans un autre en-tête pour exécuter un logiciel d’échantillonnage Microchip, qui démontre le processus d’authentification mutuelle décrit dans cet article, incluant l’authentification TLS serveur et l’authentification des appareils JWT.

　　Conclusion

　　Bien que la sécurité des applications IoT implique de multiples exigences, le principal défi réside souvent dans la mise en œuvre d’une authentification mutuelle pour les appareils IoT et les ressources cloud. Dans les systèmes IoT à ressources limitées, les protocoles traditionnels peuvent dépasser la mémoire et les ressources de traitement disponibles. En utilisant la bibliothèque CryptoAuthLib de Microchip Technology et ATECC608A circuit intégré CryptoAuthentication, les développeurs peuvent mettre en œuvre une approche plus efficace basée sur les jetons web JSON pour connecter en toute sécurité les appareils IoT aux services IoT Google Cloud.