Prise en charge de TLS (Transport Layer Security) dans IoT Hub

Article
12/22/2024

IoT Hub utilise le protocole TLS (Transport Layer Security) pour sécuriser les connexions provenant d’appareils et de services IoT. Trois versions du protocole TLS sont actuellement prises en charge, à savoir les versions 1.0, 1.1 et 1.2.

Les protocoles TLS 1.0 et 1.1 sont considérés comme hérités et leur obsolescence est planifiée. Pour plus d’informations, consultez Dépréciation de TLS 1.0 et 1.1 pour IoT Hub. Pour éviter tout problème futur, utilisez TLS 1.2 comme seule version TLS lors de la connexion à IoT Hub.

Certificat TLS du serveur d’IoT Hub

Au cours de l’établissement d’une liaison TLS, IoT Hub présente des certificats de serveur à clé RSA pour la connexion des clients. Tous les IoT Hubs dans le cloud Azure global utilisent le certificat TLS émis par DigiCert Global Root G2.

Nous vous recommandons également d’ajouter les certificats Microsoft RSA Root Certificate Authority 2017 à vos appareils pour éviter les interruptions au cas où DigiCert Global Root G2 subit une mise hors service inattendue. Bien que les migrations d’autorité de certification racine soient rares, pour la résilience dans le paysage de sécurité moderne, vous devez préparer votre scénario IoT pour l’événement peu probable qu’une autorité de certification racine est compromise ou qu’une migration d’autorité de certification racine d’urgence est nécessaire.

Nous vous recommandons vivement d’approuver les autorités de certification racines suivantes :

Autorité de certification racine DigiCert Global G2
Autorité de certification racine Microsoft RSA 2017

Pour obtenir des liens vers le téléchargement de ces certificats, consultez détails de l’autorité de certification Azure.

Approbation de certificat dans les SDK

Les SDK d’appareil Azure IoT connectent et authentifient des appareils auprès des services Azure IoT. Les différents SDK gèrent les certificats de différentes façons en fonction de la langue et de la version, mais la plupart reposent sur le magasin de certificats approuvé de l’appareil plutôt que d’épingler des certificats directement dans la base de code. Cette approche offre une flexibilité et une résilience pour gérer des modifications futures dans les certificats racines.

Le tableau suivant résume les versions du SDK qui prennent en charge le magasin de certificats approuvé :

Azure IoT device SDK	Versions prises en charge
C	Toutes les versions prises en charge
C#	Toutes les versions prises en charge
Java	Versions 2.x et ultérieures
Node.JS	Toutes les versions prises en charge
Python	Toutes les versions prises en charge

Épinglage de certificat

L’épinglage de certificat et le filtrage des certificats de serveur TLS (également appelés certificats « feuilles ») et les certificats intermédiaires associés aux points de terminaison IoT Hub sont déconseillés, car Microsoft déploie fréquemment ces certificats avec peu ou sans préavis. Si nécessaire, épinglez uniquement les certificats racines.

Certificat TLS (version préliminaire) du serveur ECC (Elliptic Curve Cryptography)

Le certificat TLS du serveur ECC d’IoT Hub est disponible en préversion publique. Tout en offrant une sécurité similaire aux certificats RSA, la validation des certificats ECC (avec les suites de chiffrement exclusivement ECC) utilise jusqu’à 40 % moins de calcul, de mémoire et de bande passante. Ces économies sont importantes pour les appareils IoT en raison de leur profil et de leur mémoire plus petits, et pour prendre en charge les cas d’usage dans des environnements où la bande passante est limitée.

Nous recommandons vivement que tous les appareils utilisant ECC approuvent les deux autorités de certification racine suivantes :

Autorité de certification racine DigiCert Global G3
Autorité de certification racine Microsoft RSA 2017

Pour obtenir des liens vers le téléchargement de ces certificats, consultez détails de l’autorité de certification Azure.

Pour afficher un aperçu du certificat de serveur ECC d’IoT Hub :

Créez un hub IoT avec le mode aperçu activé.
Configurez votre client pour qu’il inclue uniquement des suites de chiffrement ECDSA et exclue toute suite RSA. Les suites de chiffrement prises en charge pour la préversion publique du certificat ECC sont les suivantes :
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Connectez votre client à la préversion d’IoT Hub.

TLS 1.2 n’est disponible que dans certaines régions

Pour renforcer la sécurité, configurez vos hubs IoT pour autoriser uniquement les connexions client qui utilisent la version 1.2 du protocole TLS et pour appliquer l’utilisation des suites de chiffrement. Cette fonctionnalité n'est prise en charge que dans ces régions :

USA Est
États-Unis - partie centrale méridionale
USA Ouest 2
Gouvernement des États-Unis – Arizona
US Gov Virginie (La prise en charge de TLS 1.0/1.1 n’est pas disponible dans cette région. L’application de TLS 1.2 doit être activée, sinon la création d’un hub IoT échoue.)

Pour activer l’application de TLS 1.2, suivez les étapes décrites dans Créer un hub IoT dans Portail Azure, sauf

Choisissez une région dans la liste ci-dessus.
Sous Gestion -> Avancé -> Protocole TLS -> Version TLS minimale, sélectionnez 1.2. Ce paramètre s’affiche uniquement pour les hubs IoT créés dans une région prise en charge.

Afin d’utiliser le modèle ARM pour la création, approvisionnez un nouveau hub IoT dans l’une des régions prises en charge et définissez la propriété minTlsVersion sur 1.2 dans la spécification de ressource :

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.Devices/IotHubs",
            "apiVersion": "2020-01-01",
            "name": "<provide-a-valid-resource-name>",
            "location": "<any-of-supported-regions-below>",
            "properties": {
                "minTlsVersion": "1.2"
            },
            "sku": {
                "name": "<your-hubs-SKU-name>",
                "tier": "<your-hubs-SKU-tier>",
                "capacity": 1
            }
        }
    ]
}

La ressource IoT Hub créée à l’aide de cette configuration refuse les clients d’appareil et de service qui tentent de se connecter à l’aide des versions 1.0 et 1.1 du protocole TLS. De même, la négociation TLS est refusée si le message ClientHello ne liste aucun des chiffrements recommandés.

Remarque

La propriété minTlsVersion est en lecture seule et ne peut pas être modifiée une fois votre ressource IoT Hub créée. C’est pourquoi il est essentiel de tester et de valider correctement que tous vos appareils et services IoT sont compatibles avec le protocole TLS 1.2 et les chiffrements recommandés au préalable.

Lors des basculements, la propriété minTlsVersion de votre IoT Hub reste effective dans la région jumelée géographiquement après le basculement.

Suites de chiffrement

Les hubs IoT configurés pour accepter uniquement TLS 1.2 appliquent également l’utilisation des suites de chiffrement recommandées suivantes :

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Pour les hubs IoT non configurés pour l’application de TLS 1.2, ce protocole fonctionne quand même avec les suites de chiffrement suivantes :

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA(ce chiffrement sera déconseillé le 10/01/2022 et ne sera plus utilisé pour les liaisons TLS)

Un client peut suggérer une liste de suites de chiffrement plus élevées à utiliser pendant ClientHello. Toutefois, certaines d’entre elles peuvent ne pas être prises en charge par IoT Hub (par exemple, ECDHE-ECDSA-AES256-GCM-SHA384). Dans ce cas, IoT Hub tente de suivre la préférence du client, mais finit par négocier seulement la suite de chiffrement avec ServerHello.

Configuration TLS pour le Kit de développement logiciel (SDK) et IoT Edge

Utilisez les liens ci-dessous pour configurer TLS 1.2 et les chiffrements autorisés dans les Kits de développement logiciel (SDK) clients IoT Hub.

Langue	Versions prenant en charge TLS 1.2	Documentation
C	Balise 2019-12-11 ou ultérieure	Lien
Python	Version 2.0.0 ou ultérieure	Lien
C#	Version 1.21.4 ou ultérieure	Lien
Java	Version 1.19.0 ou ultérieure	Lien
NodeJS	Version 1.12.2 ou ultérieure	Lien

Les appareils IoT Edge peuvent être configurés pour utiliser TLS 1.2 lors des communications avec IoT Hub. À cet effet, consultez la page de documentation d’IoT Edge.

Authentification des appareils

Après l’établissement de la liaison TLS, IoT Hub peut authentifier un appareil à l’aide d’une clé symétrique ou d’un certificat X.509. Pour l’authentification par certificat, il peut s’agir de n’importe quel certificat X.509, y compris ECC. IoT Hub valide le certificat par rapport à l’empreinte ou à l’autorité de certification (CA) que vous fournissez. Pour plus d’informations, consultez Certificats X.509 pris en charge.

Prise en charge du protocole Mutual TLS

L’authentification mutuelle TLS garantit que le client authentifie le certificat du serveur (IoT Hub) et que le serveur (IoT Hub) authentifie le certificat client X.509 ou l’empreinte X.509. L’autorisation est effectuée par IoT Hub une fois l’authentification terminée.

Pour les protocoles AMQP et MQTT, IoT Hub demande un certificat client dans la négociation TLS initiale. Si un certificat est fourni, IoT Hub authentifie le certificat client, et le client authentifie le certificat IoT Hub. Ce processus est appelé authentification TLS mutuelle. Chaque fois qu’IoT Hub reçoit un paquet de connexion MQTT ou qu’un lien AMQP s’ouvre, IoT Hub effectue l’autorisation pour le client demandeur et détermine si le client a besoin d’une authentification X.509. Si l’authentification TLS mutuelle a été effectuée et que le client est autorisé à se connecter en tant qu’appareil, ce dernier est autorisé. Toutefois, si le client nécessite une authentification X.509 et que l’authentification du client n’a pas été effectuée pendant la négociation TLS, IoT Hub rejette la connexion.

Pour le protocole HTTP, lorsque le client effectue sa première demande, IoT Hub vérifie si le client nécessite l’authentification X.509 et si l’authentification du client a été terminée, IoT Hub effectue l’autorisation. Si l’authentification du client n’a pas été terminée, IoT Hub rejette la connexion

Négociation de la longueur maximale des fragments TLS (préversion)

IoT Hub prend également en charge la négociation de longueur maximale des fragments TLS, parfois appelée négociation de la taille de images TLS. Cette fonctionnalité est en version préliminaire publique.

Utilisez cette fonctionnalité pour spécifier la longueur maximale du fragment de texte en clair sur une valeur inférieure à 2^14 octets par défaut. Une fois la négociation terminée, IoT Hub et le client commencent à fragmenter les messages pour s’assurer que tous les fragments sont plus petits que la longueur négociée. Ce comportement est utile pour le calcul ou les appareils ayant une mémoire restreinte. Pour plus d’informations, consultez la spécification officielle de l’extension TLS.

La prise en charge officielle du Kit de développement logiciel (SDK) pour cette fonctionnalité d’évaluation publique n’est pas encore disponible. Pour commencer

Créez un hub IoT avec le mode aperçu activé.
Quand vous utilisez OpenSSL, appelez SSL_CTX_set_tlsext_max_fragment_length pour spécifier la taille du fragment.
Connectez votre client à la préversion d’IoT Hub.

Étapes suivantes

Pour en savoir plus sur la sécurité et le contrôle d’accès d’IoT Hub, consultez Contrôler l’accès à IoT Hub.
Pour en savoir plus sur l’utilisation du certificat X.509 pour l’authentification des appareils, consultez Authentification des appareils à l’aide de certificats d’autorité de certification X.509.

Partager via