Zertifikatverwendung mit Azure Sphere

Dieses Thema bietet eine Übersicht über das Azure Sphere-Zertifikat "Querformat": die Arten von Zertifikaten, die die verschiedenen Azure Sphere-Komponenten verwenden, woher sie stammen, wo sie gespeichert werden, wie sie aktualisiert werden und wie sie bei Bedarf darauf zugreifen können. Außerdem wird beschrieben, wie das Azure Sphere-Betriebssystem, das SDK und die Dienste die Zertifikatverwaltung für Sie vereinfachen. Wir gehen davon aus, dass Sie mit Zertifizierungsstellen und der Vertrauenskette vertraut sind.

Azure Sphere-Geräte

Jedes Azure Sphere-Gerät basiert auf dem vertrauenswürdigen Stammspeicher, der Teil des Azure Sphere-Betriebssystems ist. Der vertrauenswürdige Stammspeicher enthält eine Liste von Stammzertifikaten, die verwendet werden, um die Identität des Azure Sphere-Sicherheitsdiensts zu überprüfen, wenn das Gerät eine Verbindung für die Geräteauthentifizierung und den Nachweis (Device Authentication and Attestation, DAA), Over-the-Air-Updates (OTA) oder Fehlerberichterstattung herstellt. Diese Zertifikate werden mit dem Betriebssystem bereitgestellt.

Wenn der tägliche Nachweis erfolgreich ist, erhält das Gerät zwei Zertifikate: ein Updatezertifikat und ein Kundenzertifikat. Mit dem Updatezertifikat kann das Gerät eine Verbindung mit dem Azure Sphere-Updatedienst herstellen, um Softwareupdates zu erhalten und Fehlerberichte hochzuladen. Es ist nicht für Anwendungen oder über die Befehlszeile zugänglich. Das Kundenzertifikat, manchmal auch als DAA-Zertifikat bezeichnet, kann von Anwendungen verwendet werden, um eine Verbindung mit Drittanbieterdiensten wie wolfSSL herzustellen, die Transport Layer Security (TLS) verwenden. Dieses Zertifikat ist 24 Stunden lang gültig. Anwendungen können sie programmgesteuert abrufen, indem sie die funktion DeviceAuth_GetCertificatePath aufrufen.

Geräte, die eine Verbindung mit Azure-basierten Diensten wie Azure IoT Hub, Azure IoT Central und Azure IoT Edge herstellen, müssen ihr Azure Sphere-Mandantenzertifizierungsstellenzertifikat vorlegen, um ihren Azure Sphere-Mandanten zu authentifizieren. Der Befehl azsphere ca-certificate download in der CLI gibt das Zertifikat der Mandantenzertifizierungsstelle für solche Verwendungen zurück.

EAP-TLS-Netzwerkverbindungen

Geräte, die eine Verbindung mit einem EAP-TLS-Netzwerk herstellen, benötigen Zertifikate, um sich beim RADIUS-Server des Netzwerks zu authentifizieren. Um sich als Client zu authentifizieren, muss das Gerät ein Clientzertifikat an den RADIUS übergeben. Für die gegenseitige Authentifizierung muss das Gerät auch über ein Zertifikat der Stammzertifizierungsstelle für den RADIUS-Server verfügen, damit der Server authentifiziert werden kann. Microsoft stellt keines dieser Zertifikate zur Verfügung. Sie oder Ihr Netzwerkadministrator sind dafür verantwortlich, die richtige Zertifizierungsstelle für den RADIUS-Server Ihres Netzwerks zu ermitteln und dann die erforderlichen Zertifikate vom Aussteller zu erhalten.

Um die Zertifikate für den RADIUS-Server abzurufen, müssen Sie sich bei der Zertifizierungsstelle authentifizieren. Zu diesem Zweck können Sie das DAA-Zertifikat verwenden, wie bereits erwähnt. Nachdem Sie die Zertifikate für den RADIUS-Server erworben haben, sollten Sie sie im Gerätezertifikatspeicher speichern. Der Gerätezertifikatspeicher ist nur für die Authentifizierung bei einem geschützten Netzwerk mit EAP-TLS verfügbar. (Das DAA-Zertifikat wird nicht im Gerätezertifikatspeicher gespeichert, es wird sicher im Betriebssystem aufbewahrt.) Mit dem Befehl azsphere device certificate in der CLI können Sie den Zertifikatspeicher über die Befehlszeile verwalten. Azure Sphere-Anwendungen können die CertStore-API verwenden, um Zertifikate im Gerätezertifikatspeicher zu speichern, abzurufen und zu verwalten. Die CertStore-API enthält auch Funktionen zum Zurückgeben von Informationen zu einzelnen Zertifikaten, sodass Apps sich auf den Ablauf und die Verlängerung von Zertifikaten vorbereiten können.

Eine vollständige Beschreibung der zertifikate, die in EAP-TLS-Netzwerken verwendet werden, finden Sie unter Verwenden von EAP-TLS, und weitere Informationen finden Sie unter Secure Enterprise Wi-Fi access: EAP-TLS on Azure Sphere on the Microsoft Tech Community( Secure Enterprise Wi-Fi access: EAP-TLS on Azure Sphere).

Azure Sphere-Anwendungen

Azure Sphere-Anwendungen benötigen Zertifikate, um sich bei Webdiensten und einigen Netzwerken zu authentifizieren. Abhängig von den Anforderungen des Diensts oder Endpunkts kann eine App entweder das DAA-Zertifikat oder ein Zertifikat einer externen Zertifizierungsstelle verwenden.

Apps, die mithilfe von wolfSSL oder einer ähnlichen Bibliothek eine Verbindung mit einem Drittanbieterdienst herstellen, können die funktion DeviceAuth_GetCertificatePath aufrufen, um das DAA-Zertifikat für die Authentifizierung abzurufen. Diese Funktion wurde im Header deviceauth.h im SDK 20.10 eingeführt.

Die in Azure Sphere integrierte Azure IoT-Bibliothek vertraut bereits der erforderlichen Stammzertifizierungsstelle, sodass Apps, die diese Bibliothek für den Zugriff auf Azure IoT-Dienste (Azure IoT Hub, Azure IoT Central, Gerätebereitstellungsdienst) verwenden, keine zusätzlichen Zertifikate benötigen.

Wenn Ihre Apps andere Azure-Dienste verwenden, informieren Sie sich in der Dokumentation für diese Dienste, um zu ermitteln, welche Zertifikate erforderlich sind.

Öffentliche Azure Sphere-API

Die öffentliche Azure Sphere-API (PAPI) kommuniziert mit dem Azure Sphere-Sicherheitsdienst, um Informationen zu bereitgestellten Geräten anzufordern und abzurufen. Der Sicherheitsdienst verwendet ein TLS-Zertifikat, um solche Verbindungen zu authentifizieren. Dies bedeutet, dass code oder skripts, die die öffentliche API verwenden, zusammen mit allen anderen Security Service-Clients wie dem Azure Sphere SDK (einschließlich der klassischen Azure Sphere CLI und der Azure Sphere CLI) diesem Zertifikat vertrauen müssen, um eine Verbindung mit dem Sicherheitsdienst herstellen zu können. Das SDK verwendet die Zertifikate im Systemzertifikatspeicher des Hostcomputers für die Überprüfung des Azure Sphere-Sicherheitsdiensts, ebenso wie viele öffentliche API-Anwendungen.

Am 13. Oktober 2020 aktualisiert der Sicherheitsdienst sein ÖFFENTLICHEs API-TLS-Zertifikat auf ein Zertifikat, das vom DigiCert Global Root G2-Zertifikat ausgestellt wurde. Sowohl Windows- als auch Linux-Systeme enthalten das DigiCert Global Root G2-Zertifikat, sodass das erforderliche Zertifikat sofort verfügbar ist. Wie wir jedoch in einem früheren Blogbeitrag beschrieben haben, waren nur Kundenszenarien, in denen Antragsteller, Name oder Aussteller (SNI) angeheftet wurden, Änderungen erforderlich, um dieses Update zu berücksichtigen.

Azure Sphere-Sicherheitsdienst

Azure Sphere-Clouddienste im Allgemeinen und der Sicherheitsdienst im Besonderen verwalten zahlreiche Zertifikate, die in der sicheren Dienst-zu-Dienst-Kommunikation verwendet werden. Die meisten dieser Zertifikate sind intern für die Dienste und ihre Clients, sodass Microsoft Updates nach Bedarf koordiniert. Der Azure Sphere-Sicherheitsdienst hat beispielsweise nicht nur das ÖFFENTLICHE API-TLS-Zertifikat im Oktober aktualisiert, es hat auch seine TLS-Zertifikate für den DAA-Dienst und den Updatedienst aktualisiert. Vor dem Update haben Geräte ein OTA-Update für den vertrauenswürdigen Stammspeicher erhalten, das das neue erforderliche Stammzertifikat enthielt. Es war keine Kundenaktion erforderlich, um die Gerätekommunikation mit dem Sicherheitsdienst aufrechtzuerhalten.

Wie vereinfacht Azure Sphere Zertifikatänderungen für Kunden?

Zertifikatablauf ist eine häufige Ursache für Fehler für IoT-Geräte , die Azure Sphere verhindern kann.

Da das Azure Sphere-Produkt sowohl das Betriebssystem als auch den Sicherheitsdienst enthält, werden die von beiden Komponenten verwendeten Zertifikate von Microsoft verwaltet. Geräte erhalten aktualisierte Zertifikate über den DAA-Prozess, Betriebssystem- und Anwendungsupdates sowie Fehlerberichterstattung, ohne dass Änderungen an Anwendungen erforderlich sind. Als Microsoft das DigiCert Global Root G2-Zertifikat hinzugefügt hat, waren keine Kundenänderungen erforderlich, um DIE DAA, Updates oder Fehlerberichterstattung fortzusetzen. Geräte, die zum Zeitpunkt des Updates offline waren, haben das Update erhalten, sobald sie wieder eine Verbindung mit dem Internet hergestellt haben.

Das Azure Sphere-Betriebssystem enthält auch die Azure IoT-Bibliothek. Wenn Microsoft also weitere Änderungen an Zertifikaten vornimmt, die von den Azure IoT-Bibliotheken verwendet werden, aktualisieren wir die Bibliothek im Betriebssystem, sodass Ihre Anwendungen nicht geändert werden müssen. Darüber hinaus informieren wir Sie in zusätzlichen Blogbeiträgen über Edgefälle oder spezielle Umstände, die Änderungen an Ihren Apps oder Skripts erfordern könnten.

Beide Fälle zeigen, wie Azure Sphere die Anwendungsverwaltung vereinfacht, indem keine Wartungsupdates für Anwendungen erforderlich sind, um Zertifikatänderungen zu verarbeiten. Da jedes Gerät im Rahmen des täglichen Nachweises ein Updatezertifikat erhält, können Sie die Aktualisierung von lokal verwalteten Zertifikaten, die Von Ihren Geräten und Anwendungen verwendet werden, problemlos verwalten. Wenn Ihre Anwendung z. B. die Identität Ihres Branchenservers überprüft (wie dies erforderlich ist), können Sie ein aktualisiertes Anwendungsimagepaket bereitstellen, das aktualisierte Zertifikate enthält. Die von der Azure Sphere-Plattform bereitgestellten Anwendungsupdatedienste stellen diese Updates bereit, wodurch die Sorge beseitigt wird, dass beim Updatedienst selbst ein Zertifikatablaufproblem auftritt.

Weitere Informationen

Azure Sphere Device Authentication and Attestation Service

Zusätzliche Zertifikatupdates für Azure Sphere

Änderungen an Azure TLS-Zertifikaten

Azure IoT TLS: Änderungen kommen! (... und warum Sie sich darum kümmern sollten)