Une solution plus simple pour connecter des dispositifs IoT au cloud en toute sécurité

Malgré une prise de conscience croissante quant au besoin de sécurité, les développeurs prennent trop souvent des raccourcis en matière de sécurité pour connecter des dispositifs IoT au cloud. Dans de nombreux cas, les conflits entre la complexité des mécanismes de sécurité appropriés, les ressources de traitement et de mémoire limitées disponibles dans des dispositifs IoT miniatures alimentés par batterie et la nécessité de lancer le produit, semblent insurmontables.

Pour résoudre ces problèmes et simplifier l'implémentation de fonctionnalités de sécurité dans les dispositifs IoT, Microchip Technology et Google ont collaboré à la mise au point d'une approche associant les capacités matérielles de sécurité de Microchip à une structure de données simple appelée JSON Web Token (JWT). Cette collaboration s'est traduite par une méthode simple destinée à garantir une authentification mutuelle entre les dispositifs IoT et les services Google Cloud IoT Core.

Le présent article fait état de la menace qui plane sur les dispositifs IoT vis-à-vis de leur sécurité et présente des dispositifs actuellement utilisés pour y faire face. Il met en évidence les lacunes en matière de sécurité et indique la façon dont la structure JWT peut être utilisée par les développeurs et les concepteurs de systèmes intégrés afin de les combler.

La faille de sécurité des dispositifs IoT

Les attaques dirigées contre les dispositifs IoT peuvent prendre différentes formes et ne se limitent en aucun cas aux déploiements IoT à grande échelle. Même le plus petit réseau IoT représente une cible intéressante pour les pirates informatiques cherchant à regrouper les ressources de nombreux dispositifs individuels dans des botnets destinés à lancer des attaques par déni de service distribué (DDoS) ou autres. Par conséquent, les concepteurs de toutes les catégories de dispositifs IoT sont inévitablement confrontés à la nécessité de protéger leurs systèmes à l'aide de mécanismes de sécurité matérielle efficaces capables de déjouer les attaques.

À titre d'exemple, l'utilisation de la mémoire système ou d'une mémoire Flash afin de stocker des clés privées utilisées pour le cryptage et l'authentification rend le dispositif IoT vulnérable. Pire encore, les pirates informatiques peuvent voler ces clés et les utiliser afin d'accéder au réseau IoT ainsi qu'aux ressources de l'entreprise présentes sur ce réseau.

Circuits intégrés de sécurité

Les dispositifs de sécurité spécialisés, comme les circuits intégrés CryptoMemory et CryptoAuthentication de Microchip Technology présentent des mécanismes de sécurité matérielle destinés à protéger les clés privées et d'autres données secrètes. Intégrée à ces dispositifs, une matrice EEPROM offre un stockage sûr accessible uniquement par l'intermédiaire de mécanismes sécurisés de façon cryptographique, eux-mêmes accessibles via l'interface série SPI ou I²C du dispositif (Figure 1). Ces dispositifs représentent ainsi une solution simple pour ajouter du stockage sécurisé et d'autres fonctionnalités de sécurité à n'importe quelle conception de dispositif IoT.

Figure 1 : Les dispositifs de sécurité matérielle de Microchip Technology, comme le circuit intégré CryptoMemory AT88SC0204C, fournissent un stockage sécurisé à l'aide de mécanismes cryptographiques intégrés destinés à protéger l'accès à la mémoire EEPROM embarquée. (Source de l'image : Microchip Technology)

Les produits de la gamme CryptoAuthentication de Microchip, comme l'ATECC608A, améliorent cette base de stockage sécurisé grâce à la prise en charge d'algorithmes de cryptographie fréquemment utilisés dans les conceptions sécurisées. Parmi ses fonctionnalités matérielles, le dispositif inclut une accélération matérielle pour de multiples algorithmes, notamment :

• Algorithmes de cryptographie asymétrique :
  • Algorithme de signature numérique à courbe elliptique (ECDSA) FIPS186-3
  • Échange de clés Diffie-Hellman à courbe elliptique (ECDH) FIPS SP800-56A
  • Cryptographie à courbe elliptique (ECC) NIST P256
• Algorithmes de cryptographie symétrique :
  • Cryptographie par hachage SHA-256
  • Cryptographie de code d'authentification de message basée sur le hachage (HMAC)
  • Cryptographie AES-128
  • Cryptographie AES-GCM (multiplication de corps de Galois)
• Fonctions de dérivation de clé (KDF) :
  • KDF de fonction pseudo-aléatoire (PRF)
  • KDF d'extraction/expansion basée HMAC (HKDF)

Pour les experts en cryptographie, cet ensemble de fonctionnalités cryptographiques représente une liste complète des mécanismes requis pour prendre en charge des protocoles de sécurité de niveau supérieur destinés à l'authentification et aux échanges de données sécurisés. À titre d'exemple, la capacité KDF fournit les mécanismes indispensables au protocole de sécurité TLS pour authentifier les participants à une session d'échange de données avant même que l'échange ne commence.

Dans ce protocole, une session TLS commence par l'envoi au serveur, par un client, d'une demande de lancement de session sécurisée. En guise de réponse, le serveur envoie son certificat numérique, que le client utilise pour confirmer l'identité du serveur. Lorsque le serveur a ainsi été authentifié par le client, la configuration de la session se poursuit par la génération, par le client, d'une clé de session à l'aide de la clé publique du serveur, afin de crypter certaines valeurs aléatoires créées grâce à une fonction KDF PRF ou à une fonction HKDF plus puissante.

Le protocole d'authentification TLS est un élément essentiel pour la sécurité sur Internet. Toute une industrie de fournisseurs de certificats, appelés Autorités de certification, a évolué afin de prendre en charge ce composant indispensable des communications sécurisées. Les entreprises obtiennent des certificats de confiance auprès des autorités de certification afin de les installer sur leurs propres serveurs pour prendre en charge le protocole standard d'authentification de serveur TLS mentionné ci-dessus.

Pour les applications IoT impliquant une connexion plus poussée des réseaux à des sources d'entreprise, ce type d'authentification unilatérale ne suffit pas pour assurer la protection. Par exemple, des pirates informatiques possédant de faux certificats pourraient se faire passer pour des serveurs légitimes auprès de dispositifs IoT dans le cadre d'une attaque plus vaste.

Malgré le risque, les développeurs IoT rencontrent souvent des difficultés à implémenter le protocole TLS d'authentification mutuelle, car les certificats, les clés et les logiciels nécessaires à l'implémentation de l'authentification client avec le protocole TLS dépassent les capacités de nombreux dispositifs IoT. Grâce à leur collaboration, Microchip Technology et Google ont créé une approche alternative qui associe les capacités de l'ATECC608A à une structure de données simple appelée JSON Web Token (JWT). Cette collaboration s'est traduite par une méthode simple destinée à garantir une authentification mutuelle entre les dispositifs IoT et les services Google Cloud IoT Core.

Authentification JWT

Spécifié dans la norme RFC 7519, JWT est un conteneur d'informations standard. Ces informations sont appelées revendications et concernent l'entité qui prépare et transmet le jeton JWT. La structure JWT se compose de trois sections :

• L'en-tête, qui inclut des paires nom:valeur JSON pour le nom (« alg ») de l'algorithme de cryptographie (par exemple, « EC256 » pour ECDSA utilisant la courbe NIST P-256) utilisé pour signer le jeton, et pour le type (« typ ») de jeton (« JWT » pour ces jetons)
• La charge utile, qui inclut des paires nom:valeur JSON pour chaque revendication
• La signature, qui utilise l'algorithme indiqué dans l'en-tête pour coder une clé secrète ainsi que l'ensemble en-tête/revendications, chaque élément étant individuellement converti en représentation URL codée Base64 avant le cryptage

La norme RFC 7519 offre une grande flexibilité pour spécifier des revendications dans la charge utile ou d'autres sections. La norme permet même des JWT non sécurisés, créés sans signature ni cryptage, auquel cas l'en-tête inclut la paire nom:valeur {"alg":"none"} pour l'algorithme. Pour les JWT utilisés avec les services Google Cloud IoT Core, ce dernier exige la section signature ainsi qu'une charge utile comprenant trois revendications obligatoires, notamment :

• « iat » – l'heure d'émission (issued at) indiquant l'heure de création du jeton au format d'horodatage UTC ISO 8601 sous forme de secondes depuis 1970-01-01T00:00:00Z (par exemple, 1561896000 pour le 30 juin 2019 à 12:00:00 PM GMT)
• « exp » – l'horodatage UTC spécifiant l'expiration du jeton avec un maximum de 24 heures après la valeur « iat », plus une période de grâce de dix minutes pour les éventuels décalages entre l'horloge système des différents clients et serveurs (par exemple, 1561982400 pour le 1er juillet 2019 à 12:00:00 PM GMT)
• « aud » – une chaîne contenant l'identifiant de projet Google Cloud du développeur

Le schéma Google concernant l'authentification des dispositifs IoT associe une authentification de serveur normale basée sur le protocole TLS à une authentification du dispositif IoT à l'aide d'un jeton JWT créé grâce à ces revendications relativement simples. Pour démarrer une nouvelle session, un dispositif IoT ouvre un socket sécurisé sur le serveur et authentifie ce dernier à l'aide du même protocole TLS précédemment décrit.

L'étape suivante du processus repose sur l'utilisation, par le cloud Google IoT, du protocole MQTT (Message Queueing Telemetry Transport) léger pour les transactions de réseau IoT. Grâce au socket sécurisé sur le serveur authentifié, le dispositif IoT « se connecte » aux services d'hébergement MQTT de ce serveur, son jeton JWT unique lui servant de mot de passe de connexion (Liste 1).

Copier /* Populate the buffer with the username */ int config_get_client_username(char* buf, size_t buflen) {     if(buf && buflen)     {         int rv = snprintf(buf, buflen, "unused");           if(0 < rv && rv < buflen)         {             buf[rv] = 0;             return 0;         }     }     return -1; }   /* Populate the buffer with the user's password */ int config_get_client_password(char* buf, size_t buflen) {     int rv = -1;       if(buf && buflen)     {         atca_jwt_t jwt;                 uint32_t ts = time_utils_get_utc();           rv = atcab_init(&cfg_ateccx08a_i2c_default);         if(ATCA_SUCCESS != rv)         {             return rv;         }           /* Build the JWT */         rv = atca_jwt_init(&jwt, buf, buflen);         if(ATCA_SUCCESS != rv)         {             return rv;         }           if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "iat", ts)))         {             return rv;         }           if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "exp", ts + 86400)))         {             return rv;         }           if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_string(&jwt, "aud", config_gcp_project_id)))         {             return rv;         }          rv = atca_jwt_finalize(&jwt, 0);           atcab_release();     }     return rv; } 

Liste 1 : Inclus dans le référentiel d'exemples logiciels de Microchip Technology pour la plateforme Google Cloud IoT Core, un module fournit des routines permettant de générer un faux nom d'utilisateur et un objet JWT à utiliser en tant que mot de passe pour l'authentification client à l'aide d'un hôte MQTT. (Source du code : Microchip Technology)

Bien que le dispositif IoT envoie un nom d'utilisateur dans le cadre de cette séquence de connexion, le nom d'utilisateur n'est pas utilisé pour l'authentification. Un faux nom d'utilisateur est alors transmis (Liste 2). L'authentification du dispositif IoT se base en réalité sur le jeton JWT envoyé en tant que mot de passe de connexion. Étant donné que la signature JWT résulte de l'association de l'en-tête, de la charge utile et de la clé privée du dispositif, les services Google Cloud IoT Core peuvent vérifier que le jeton JWT provient véritablement d'un dispositif autorisé. Pour effectuer cette vérification, les services Google Cloud IoT utilisent la clé publique du dispositif qui a été précédemment stockée sur le cloud Google par le développeur du dispositif IoT à l'aide du processus de gestion de clés décrit ci-dessous. Contrairement à l'utilisation du protocole TLS seul, cette approche offre une authentification mutuelle par l'intermédiaire d'une approche hybride qui accélère le processus, tout en réduisant les besoins en ressources du dispositif IoT.

Copier /* Connect the MQTT Client to the host */ static int client_connect(void* pCtx) {     MQTTPacket_connectData mqtt_options = MQTTPacket_connectData_initializer;     struct _g_client_context* ctx = (struct _g_client_context*)pCtx;     size_t buf_bytes_remaining = CLIENT_MQTT_RX_BUF_SIZE;       mqtt_options.keepAliveInterval = MQTT_KEEP_ALIVE_INTERVAL_S;     mqtt_options.cleansession = 1;       /* Client ID String */     mqtt_options.clientID.cstring = (char*)&ctx->mqtt_rx_buf[0];     if(config_get_client_id(mqtt_options.clientID.cstring, buf_bytes_remaining))     {         return MQTTCLIENT_FAILURE;     }       /* Username String */     mqtt_options.username.cstring = mqtt_options.clientID.cstring + strlen(mqtt_options.clientID.cstring) + 1;     buf_bytes_remaining -= (mqtt_options.username.cstring - mqtt_options.clientID.cstring);     if(config_get_client_username(mqtt_options.username.cstring, buf_bytes_remaining))     {         return MQTTCLIENT_FAILURE;     }       /* Password String */     mqtt_options.password.cstring = mqtt_options.username.cstring + strlen(mqtt_options.username.cstring) + 1;     buf_bytes_remaining -= (mqtt_options.password.cstring - mqtt_options.username.cstring);     if(config_get_client_password(mqtt_options.password.cstring, buf_bytes_remaining))     {         return MQTTCLIENT_FAILURE;     }       return MQTTConnect(&ctx->mqtt_client, &mqtt_options); } 

Liste 2 : Fournie dans le référentiel d'exemples logiciels de Microchip, cette fonction illustre l'utilisation d'un objet JWT en tant que mot de passe pour authentifier le dispositif IoT sur le serveur MQTT durant la phase de connexion initiale. (Source du code : Microchip Technology)

Activateurs cruciaux

Les capacités de l'ATECC608A et son approvisionnement sont les activateurs cruciaux de cette approche. Même si n'importe quel microcontrôleur peut au final générer une signature cryptée de façon cryptographique à partir d'un en-tête et d'une charge utile JWT, toute approche exécutée uniquement avec un logiciel resterait vulnérable en l'absence de stockage sécurisé de clés basé sur le matériel. En outre, la charge du processeur et le délai d'exécution nécessaires à une implémentation « uniquement logicielle » peuvent être rédhibitoires pour de nombreux dispositifs IoT aux ressources limitées ou de nombreuses applications nécessitant des temps de réponse très rapides. Enfin, les développeurs qui n'ont pas d'expérience approfondie dans les algorithmes de sécurité et les protocoles de niveau supérieur se retrouveraient en difficulté au moment d'implémenter la fonctionnalité logicielle requise. La bibliothèque CryptoAuthLib de Microchip est destinée à répondre à ces préoccupations (Figure 2).

Figure 2 : Étant donné que la bibliothèque CryptoAuthLib utilise une couche d'abstraction matérielle (HAL) pour séparer les fonctions API et les primitives principales du matériel sous-jacent, les développeurs peuvent cibler leur logiciel vers une vaste gamme de dispositifs. (Source de l'image : Microchip Technology)

La bibliothèque CryptoAuthLib de Microchip simplifie l'implémentation de fonctionnalités IoT sécurisées, comme le protocole d'authentification JWT de Google, réduisant les opérations de sécurité complexes à un ensemble d'appels de fonction fourni via l'interface de programmation d'applications (API) CryptoAuthLib. L'aspect qui revêt peut-être la plus grande importance aux yeux des développeurs IoT est que les fonctions de base de la bibliothèque CryptoAuthLib de Microchip tirent pleinement parti des circuits intégrés de cryptographie de Microchip, comme l'ATECC608A, pour accélérer l'exécution des fonctionnalités de sécurité dans une conception. Par exemple, l'appel à atca_jwt_finalize() dans la Liste 1 utilise un dispositif de cryptographie disponible, comme l'ATECC608A, pour créer le jeton JWT utilisé en tant que mot de passe dans la Liste 2. Dans ce cas, l'ATECC608A accélère le cryptage de la signature JWT en lisant la clé privée de la conception à partir de son stockage sécurisé intégré, afin de terminer le processus de création de la signature précédemment décrit.

Malgré l'utilisation de logiciels et de dispositifs de sécurité sophistiqués, les dispositifs IoT peuvent rester vulnérables en raison des méthodes traditionnelles nécessaires pour gérer les clés et les certificats. Par le passé, des clés privées devaient être générées en externe et chargées dans des dispositifs de stockage sécurisés pendant la fabrication, la distribution ou encore le déploiement. Malgré l'utilisation de modules de sécurité matériels et d'installations sûres, l'existence éphémère de ces secrets en dehors du seul dispositif « devant les connaître » représente une faille de sécurité qui peut les exposer de manière accidentelle ou intentionnelle. En tirant parti des capacités de l'ATECC608A, Microchip et Google ont en grande partie éliminé cette faille de sécurité traditionnelle.

Dans cette nouvelle approche, Microchip utilise la capacité de l'ATECC608A à générer des paires de clés sans jamais extraire de clés privées du dispositif (Figure 3). Microchip signe ensuite les clés publiques générées par le dispositif à l'aide d'un certificat intermédiaire fourni par le client et stocké sur un serveur sécurisé au sein de l'installation sécurisée de Microchip. Enfin, Microchip transmet les clés publiques en toute sécurité au compte du client dans le gestionnaire de dispositifs Google Cloud IoT, qui peut stocker jusqu'à trois clés publiques pour chaque dispositif afin de prendre en charge les politiques de rotation des clés. Une fois déployé, un dispositif IoT peut utiliser les fonctionnalités de sécurité de l'ATECC608A pour créer le jeton JWT utilisé au cours du processus d'authentification mutuelle précédemment décrit.

Figure 3 : Les services Google Cloud IoT et Microchip Technology se combinent afin de simplifier le provisionnement de clés et de certificats, fournissant un mécanisme protégé conçu pour renforcer la sécurité des applications IoT. (Source de l'image : Google)

Cette collaboration entre Microchip et Google permet aux développeurs de se décharger complètement de ce processus critique de gestion des clés. En cas d'exigences particulières, les développeurs peuvent toutefois implémenter leur propre processus de gestion des clés à l'aide de la fonction API atcab_genkey() de la bibliothèque CryptoAuthLib, qui permet à l'ATECC608A de générer une paire de clés, de stocker la clé privée dans son stockage sécurisé et de renvoyer la clé publique associée.

Pour étudier la génération de clés et d'autres capacités de sécurité de l'ATECC608A, les développeurs peuvent rapidement configurer un environnement de développement complet à partir du kit d'évaluation SAM D21 Xplained Pro de Microchip. Basé sur le microcontrôleur Arm^® Cortex^®-M0+ 32 bits ATSAMD21J18A de Microchip, le kit SAM D21 Xplained Pro fournit une plateforme matérielle complète, prise en charge par la structure Advanced Software Framework (ASF) de Microchip composée de pilotes et de modules de code.

Pour évaluer les dispositifs CryptoAuthentication, notamment l'ATECC608A, les développeurs peuvent simplement relier une carte d'extension CryptoAuth XPRO-B à l'une des deux embases d'extension de la carte Xplained Pro. Microchip fournit un logiciel d'exemple afin d'évaluer la fonctionnalité de sécurité de la bibliothèque CryptoAuthLib avec l'ATECC608A. Pour aller plus loin, les développeurs peuvent relier une carte d'extension Wi-Fi ATWINC1500-XPRO de Microchip à l'autre embase pour exécuter le logiciel d'exemple de Microchip qui présente le déroulement de l'authentification mutuelle décrite dans le présent article, notamment l'authentification de serveur TLS et l'authentification de dispositif JWT.

Conclusion

Bien que la sécurité des applications IoT crée de nombreuses exigences, l'implémentation d'une authentification mutuelle pour les dispositifs IoT et les ressources du cloud constitue souvent un défi de taille. Dans les systèmes IoT limités en ressources, les protocoles conventionnels peuvent dépasser la mémoire disponible et les ressources de traitement. Grâce à la bibliothèque CryptoAuthLib et au circuit intégré CryptoAuthentication ATECC608A de Microchip Technology, les développeurs peuvent adopter une approche plus efficace, basée sur les jetons JSON Web, afin de connecter en toute sécurité des dispositifs IoT aux services Google Cloud IoT.