Utilisation de certificats avec Azure Sphere

Article
11/05/2024

Important

Il s’agit de la documentation Azure Sphere (héritée). Azure Sphere (hérité) prend sa retraite le 27 septembre 2027 et les utilisateurs doivent migrer vers Azure Sphere (intégré) pour l’instant. Utilisez le sélecteur de version situé au-dessus du TOC pour afficher la documentation Azure Sphere (intégrée).

Cette rubrique fournit une vue d’ensemble du certificat Azure Sphere « paysage » : les types de certificats utilisés par les différents composants Azure Sphere, où ils proviennent, où ils sont stockés, comment ils sont mis à jour et comment y accéder si nécessaire. Il décrit également comment le système d’exploitation, le SDK et les services Azure Sphere facilitent la gestion des certificats pour vous. Nous partons du principe que vous connaissez les autorités de certification et la chaîne de confiance.

Appareils Azure Sphere

Chaque appareil Azure Sphere s’appuie sur le magasin racine approuvé, qui fait partie du système d’exploitation Azure Sphere. Le magasin racine approuvé contient une liste de certificats racines utilisés pour valider l’identité du service de sécurité Azure Sphere lorsque l’appareil se connecte pour l’authentification et l’attestation de l’appareil (DAA), la mise à jour OTA (over-the-air) ou la création de rapports d’erreurs. Ces certificats sont fournis avec le système d’exploitation.

Lorsque l’attestation quotidienne réussit, l’appareil reçoit deux certificats : un certificat de mise à jour et un certificat client. Le certificat de mise à jour permet à l’appareil de se connecter au service de mise à jour Azure Sphere pour obtenir des mises à jour logicielles et de charger des rapports d’erreurs ; il n’est pas accessible aux applications ou via la ligne de commande. Le certificat client, parfois appelé certificat DAA, peut être utilisé par les applications pour se connecter à des services tiers tels que wolfSSL qui utilisent tls (Transport Layer Security). Ce certificat est valide pendant 24 heures. Les applications peuvent la récupérer par programmation en appelant la fonction DeviceAuth_GetCertificatePath.

Les appareils qui se connectent à des services Azure tels qu’Azure IoT Hub, Azure IoT Central et Azure IoT Edge doivent présenter leur certificat d’autorité de certification de locataire Azure Sphere pour authentifier leur locataire Azure Sphere. La commande azsphere ca-certificate download dans l’interface CLI retourne le certificat d’autorité de certification client pour ces utilisations.

Connexions réseau EAP-TLS

Les appareils qui se connectent à un réseau EAP-TLS ont besoin de certificats pour s’authentifier auprès du serveur RADIUS du réseau. Pour s’authentifier en tant que client, l’appareil doit transmettre un certificat client au RADIUS. Pour effectuer l’authentification mutuelle, l’appareil doit également disposer d’un certificat d’autorité de certification racine pour le serveur RADIUS afin qu’il puisse authentifier le serveur. Microsoft ne fournit pas l’un de ces certificats ; vous ou votre administrateur réseau êtes chargé de vérifier l’autorité de certification appropriée pour le serveur RADIUS de votre réseau, puis d’acquérir les certificats nécessaires auprès de l’émetteur.

Pour obtenir les certificats du serveur RADIUS, vous devez vous authentifier auprès de l’autorité de certification. Vous pouvez utiliser le certificat DAA, comme mentionné précédemment, à cet effet. Après avoir acquis les certificats pour le serveur RADIUS, vous devez les stocker dans le magasin de certificats de l’appareil. Le magasin de certificats d’appareil est disponible uniquement pour l’authentification auprès d’un réseau sécurisé avec EAP-TLS. (Le certificat DAA n’est pas conservé dans le magasin de certificats d’appareil ; il est conservé en toute sécurité dans le système d’exploitation.) La commande de certificat d’appareil azsphere dans l’interface CLI vous permet de gérer le magasin de certificats à partir de la ligne de commande. Les applications Azure Sphere peuvent utiliser l’API CertStore pour stocker, récupérer et gérer des certificats dans le magasin de certificats d’appareil. L’API CertStore inclut également des fonctions permettant de retourner des informations sur des certificats individuels afin que les applications puissent se préparer à l’expiration et au renouvellement des certificats.

Pour plus d’informations, consultez Utiliser EAP-TLS pour obtenir une description complète des certificats utilisés dans la mise en réseau EAP-TLS, et voir Accès Wi-Fi d’entreprise sécurisé : EAP-TLS sur Azure Sphere sur Microsoft Tech Community.

Applications Azure Sphere

Les applications Azure Sphere ont besoin de certificats pour s’authentifier auprès des services web et de certains réseaux. Selon les exigences du service ou du point de terminaison, une application peut utiliser le certificat DAA ou un certificat d’une autorité de certification externe.

Les applications qui se connectent à un service tiers à l’aide de wolfSSL ou d’une bibliothèque similaire peuvent appeler la fonction DeviceAuth_GetCertificatePath pour obtenir le certificat DAA pour l’authentification. Cette fonction a été introduite dans l’en-tête deviceauth.h dans le Kit de développement logiciel (SDK) 20.10.

La bibliothèque Azure IoT intégrée à Azure Sphere approuve déjà l’autorité de certification racine nécessaire. Les applications qui utilisent cette bibliothèque pour accéder aux services Azure IoT (Azure IoT Hub, Azure IoT Central, service d’approvisionnement d’appareils) ne nécessitent pas de certificats supplémentaires.

Si vos applications utilisent d’autres services Azure, consultez la documentation de ces services pour déterminer quels certificats sont requis.

API publique Azure Sphere

L’API publique Azure Sphere (PAPI) communique avec le service de sécurité Azure Sphere pour demander et récupérer des informations sur les appareils déployés. Le service de sécurité utilise un certificat TLS pour authentifier ces connexions. Cela signifie que tout code ou scripts qui utilisent l’API publique, ainsi que tous les autres clients du service de sécurité tels que le SDK Azure Sphere (y compris l’interface CLI classique Azure Sphere et l’interface CLI Azure Sphere), doivent approuver ce certificat pour pouvoir se connecter au service de sécurité. Le Kit de développement logiciel (SDK) utilise les certificats dans le magasin de certificats système de l’ordinateur hôte pour la validation du service de sécurité Azure Sphere, comme pour de nombreuses applications d’API publique.

Le 13 octobre 2020, le service de sécurité a mis à jour son certificat TLS d’API publique vers un certificat émis à partir du certificat DigiCert Global Root G2. Les systèmes Windows et Linux incluent le certificat DigiCert Global Root G2. Le certificat requis est donc facilement disponible. Toutefois, comme nous l’avons décrit dans un billet de blog précédent, seuls les scénarios clients qui ont impliqué l’objet, le nom ou l’émetteur (SNI) épinglant des modifications requises pour prendre en charge cette mise à jour.

Service de sécurité d’Azure Sphere

Les services cloud Azure Sphere en général et le service de sécurité en particulier gèrent de nombreux certificats utilisés dans la communication de service à service sécurisé. La plupart de ces certificats sont internes aux services et à leurs clients. Microsoft coordonne donc les mises à jour selon les besoins. Par exemple, en plus de mettre à jour le certificat TLS de l’API publique en octobre, le service de sécurité Azure Sphere a également mis à jour ses certificats TLS pour le service DAA et le service de mise à jour. Avant la mise à jour, les appareils ont reçu une mise à jour OTA vers le magasin racine approuvé qui incluait le nouveau certificat racine requis. Aucune action du client n’a été nécessaire pour maintenir la communication de l’appareil avec le service de sécurité.

Comment Azure Sphere facilite-t-il les modifications de certificat pour les clients ?

L’expiration du certificat est une cause courante d’échecs pour les appareils IoT qu’Azure Sphere peut empêcher.

Étant donné que le produit Azure Sphere inclut à la fois le système d’exploitation et le service de sécurité, les certificats utilisés par ces deux composants sont gérés par Microsoft. Les appareils reçoivent des certificats mis à jour par le biais du processus DAA, des mises à jour du système d’exploitation et des applications et des rapports d’erreurs sans nécessiter de modifications dans les applications. Lorsque Microsoft a ajouté le certificat DigiCert Global Root G2, aucune modification du client n’a été nécessaire pour continuer la DAA, les mises à jour ou les rapports d’erreurs. Les appareils qui étaient hors connexion au moment de la mise à jour ont reçu la mise à jour dès qu’ils se sont reconnectés à Internet.

Le système d’exploitation Azure Sphere inclut également la bibliothèque Azure IoT. Par conséquent, si Microsoft apporte d’autres modifications aux certificats utilisés par les bibliothèques Azure IoT, nous allons mettre à jour la bibliothèque dans le système d’exploitation afin que vos applications n’aient pas besoin d’être modifiées. Nous vous informerons également par le biais de billets de blog supplémentaires sur les cas de périphérie ou les circonstances spéciales susceptibles de nécessiter des modifications apportées à vos applications ou scripts.

Ces deux cas montrent comment Azure Sphere simplifie la gestion des applications en supprimant la nécessité de mises à jour de maintenance des applications pour gérer les modifications de certificat. Étant donné que chaque appareil reçoit un certificat de mise à jour dans le cadre de son attestation quotidienne, vous pouvez facilement gérer la mise à jour des certificats gérés localement par vos appareils et applications. Par exemple, si votre application valide l’identité de votre serveur métier (comme il le faut), vous pouvez déployer un package d’images d’application mis à jour qui inclut des certificats mis à jour. Les services de mise à jour d’application fournis par la plateforme Azure Sphere fournissent ces mises à jour, en supprimant l’inquiétude que le service de mise à jour lui-même entraîne un problème d’expiration de certificat.