PKI-Zertifikate (PKI – Public Key Infrastructure) sind aktuell die beste Möglichkeit, um im Internet der Dinge (IoT) eine sichere Kommunikation, Zugangskontrolle und Code-Sicherheit zu gewährleisten. Die PKI-Prozesse müssen jedoch sorgfältig geplant werden. In diesem Text erklärt der PKI-Experte Tamás Horváth, wie die Zertifikate in IoT-Geräten validiert werden.
PKI ist die beste verfügbare Technologie, um Kommunikationssicherheit, Zugangskontrolle und Code-Sicherheit in IoT-Anwendungen zu gewährleisten. In einem kürzlich erschienenen Blog-Artikel habe ich den besonderen Aspekt des Zertifikat-Lebenszyklusmanagements im Hinblick auf die Vielfalt der möglichen Produktlieferketten und Betriebsszenarien im IoT beschrieben. In diesem Blog geht es um eine bisher wenig beachtete Komponente einer IoT PKI: Die Validierung von Zertifikaten in IoT-Geräten
Der Widerruf gehört zu den integrierten PKI-Funktionen
PKI-Standards –- seit der Version X.509 in den 1990er Jahren – definieren eine Revokationsinfrastruktur für Zertifikate: Wird der private Schlüssel des Zertifikatsinhabers kompromittiert, steht er im Verdacht, kompromittiert worden zu sein oder wird er nicht mehr benötigt, kann das entsprechende Zertifikat über den Revokationsdienst der ausstellenden Zertifizierungsstelle (CA) widerrufen werden. Die CA informiert andere PKI-Parteien auf zwei Arten öffentlich über den Widerruf:
- Zertifikatssperrlisten (CRLs) können von einem zentralen CRL Distribution Point (CDP) heruntergeladen werden. Eine CRL enthält alle widerrufenen Zertifikate im Kontext der CA.
- Der Sperrstatus (widerrufen oder nicht widerrufen) eines einzelnen Zertifikats kann bei einem OCSP-Dienst (Online Certificate Status Protocol) abgefragt werden.
Diese Dienste ermöglichen es einer validierenden Partei, also einer Partei, die das Zertifikat einer anderen Partei überprüfen möchte, den Widerrufstatus abzufragen. Im Wesentlichen werden die entsprechenden Dienste zentral bereitgestellt, können aber auch an vielen Stellen des Netzes für eine bessere Verfügbarkeit und globale Zugänglichkeit vorgehalten werden. Sowohl CRLs als auch OCSP-Antworten haben ein Gültigkeitsdatum und im Wesentlichen den gleichen Inhalt. Entsprechend bieten sie die gleiche Qualität für den Validierungsservice. CRLs und OCSP-Antworten können auch in den beteiligten Komponenten zwischengespeichert werden, um den Zugang zu verbessern.
Widerruf im IoT
Das klassische Verfahren zur Zertifikatsvalidierung (entsprechend RFC5280) beinhaltet die Überprüfung des Zertifikat-Widerrufstatus basierend auf einer aktuell abgerufenen oder zwischengespeicherten CRL oder OCSP-Antwort. Für eine IoT-Anwendung bedeutet es, dass:
die Validierungssysteme brauchen einen Online-Zugriff auf einen CDP (CRL Distribution Point), einen OCSP-Responder oder auf eine andere Caching-Komponente (die Zertifikate zwischenspeichert und Zugriff auf CDP oder OCSP-Responder hat). Zudem muss der CDP oder OCSP-Dienst möglicherweise eine große Zahl von Anfragen bearbeiten.
In der klassischen PKI wird der Widerruf durch menschliche Benutzer ausgelöst, die eine Gefährdung eines Geräts erkennen und die Meldung an ein Supportsystem senden. Für eine IoT-Anwendung, die einen Widerruf initiiert, muss ein Benutzer oder eine Verwaltungsanwendung (Gerätemanagementsystem, IoT-Plattform oder ähnliches) den Widerruf des jeweiligen Zertifikats bei der CA beantragen. Dies geschieht typischerweise über eine Zertifikatsverwaltungsschnittstelle der CA und nicht über einen Supportdienst der CA.
Für die betreffende IOT-Anwendung sind die folgenden Fragen zu berücksichtigen:
- Ist es wirklich sinnvoll und notwendig, das Zertifikat eines Geräts zu widerrufen?
Besteht kein materielles oder finanzielles Risiko im Zusammenhang mit dem Verlust eines IOT-Geräts, ist eine Infrastruktur für den Widerruf nicht erforderlich. Leider gibt es keinen einheitlichen Standard, um für ein Zertifikat anzugeben, dass kein Widerrufsdienst vorhanden ist. Das Verhalten der Validierungssoftware sollte für den Fall untersucht werden, dass keine URLs für den CDP- oder OCSP-Dienst im zu validierenden Zertifikat verfügbar sind. In diesem Fall KÖNNTE die Validierungssoftware davon ausgehen, dass keine Statusvalidierung erforderlich ist.
- Gibt es eine Person, die eine Gefährdung eines Geräts über ein Support-System melden kann? Gibt es ein Managementsystem, das den Widerruf für Geräte oder Identitäten auslösen kann, wenn diese nicht mehr verwendet oder geändert werden?
Liegt kein sinnvoller Grund vor, einen Widerrufsfall zu melden, kann die Widerrufsinfrastruktur entfallen.
Zertifikatsverlängerung im IoT
In einer herkömmlichen PKI wird die Zertifikatsgültigkeit in der Regel an die garantierte Lebensdauer des Trägergerätes (z. B. Smartcard oder IT-Gerät) oder an die Gültigkeit der ausstellenden CA (die die Länge von CRLs häufig beschränkt) angepasst. Die Gültigkeit kann auch durch andere Richtlinien eingeschränkt werden, z. B. um eine Überprüfung der Identität des Betreffenden oder der Genehmigung des Zertifikatsinhabers durchzusetzen. Eine Erläuterung dazu, warum Zertifikate überhaupt eine Gültigkeit haben, finden Sie in diesem interessanten Artikel: https://security.stackexchange.com/questions/58025/why-are-certificates-limited-in-time
Die Zertifikatserneuerung (Re-Keying oder Re-Zertifizierung) erfordert den Zugriff auf die zentrale CA-Infrastruktur und stellt damit ähnliche Anforderungen an die Verbindungssicherheit im IoT.
Für die IoT-Anwendung stellen sich also die folgenden Fragen:
- Wie hoch ist die erwartete Lebensdauer des Geräts? Gibt es organisatorische oder technische Gründe, die die Gültigkeit des Zertifikats beschränken?
Falls nicht, kann die Gültigkeit des Zertifikats so gewählt werden, dass sie die erwartete Lebensdauer abdeckt, praktisch unendlich (z. B. Jahr 9000) oder undefiniert ist (entspricht 99991231235959Z nach RFC 5280). Der Validierungsalgorithmus MUSS in der Lage sein, die Gültigkeitsdaten richtig zu interpretieren. In diesem Fall können der Erneuerungsprozess und die entsprechende Schnittstelle entfallen.
- Ist es notwendig, die Identität des Geräts zu ändern?
Ist dies nicht der Fall, und die Zertifikatsgültigkeit erstreckt sich über die Lebensdauer des Geräts, können der Erneuerungsprozess und die entsprechende Schnittstelle entfallen.
Validierung mit instabiler Internetverbindung
Im herkömmlichen PKI-Setup hat der validierende Partner einen zuverlässigen Zugriff auf den CDP oder OCSP-Dienst. Dabei können diese Dienste problemlos auf mehrere parallele Knoten verteilt werden, um eine höhere Verfügbarkeit und den globalen Zugriff zu gewährleisten. Sind im Standard-Validierungsalgorithmus keine gültigen Widerrufsinformationen verfügbar, führt die Validierung zu einem negativen Ergebnis und verweigert beispielsweise den Zugriff auf einen Dienst. So werden „False Positives“ vermieden, z. B., dass ein widerrufenes Zertifikat erfolgreich validiert wird. Diese Regel verbessert die Sicherheit des Systems, wofür ein möglicher Verlust der Serviceverfügbarkeit in Kauf genommen wird.
In einigen IoT-Szenarien kann der Zugang zum Internet jedoch vorübergehend blockiert sein. Beispiele dafür sind Geräte, die sich über ein Gateway (z. B. ein mobiles Gerät) oder über ein anderes Gerät (z. B. eine Ladestation für Elektrofahrzeuge) mit dem Internet verbinden. Es kann sich auch um ein Gerät handeln, das nur im Normalbetrieb mit anderen Geräten verbunden ist und sich nicht auf eine stabile Internetverbindung (z. B. Car2Car) verlassen kann. In solchen Fällen muss man die folgenden Fragen berücksichtigen:
- Was passiert, wenn das vertrauenswürdige IoT-Gerät das Zertifikat eines anderen Geräts oder Dienstes nicht validieren kann? Führt dies zu einer Denial-of-Service-, zu einem Usability- oder sogar zu einem Sicherheitsproblem?
Steht ein häufiger Verlust der Gerätefunktionalität einer geringen Wahrscheinlichkeit und einem potenziell geringen finanziellen Schaden einer „False Positive“ Validierung gegenüber, kann die Anwendung eine höhere Toleranz für „False Positives“ zu Gunsten einer besseren Verfügbarkeit der Funktionalität definieren. Geht es jedoch um hohe Sicherheitsrisiken, ist die strengere Regelung zu bevorzugen.
- Ist es möglich, Widerrufsinformationen im vertrauenswürdigen Gerät oder in einem anderen verfügbaren Gerät (z. B. im Gateway) zwischenzuspeichern?
Ein Beispiel ist eine Ladestation für Elektrofahrzeuge, das CRLs für die Zertifikate aller Fahrzeuge zwischenspeichert, die zum Aufladen angeschlossen werden können. Das kann sehr effizient sein. Wenn die CA jedoch für eine große Anzahl von Fahrzeugen genutzt wird, kann das Herunterladen und Speichern der CRLs die Übertragung großer Datenmengen und viel Speicherplatz erfordern. In solchen Fällen könnte die Verwendung von OCSP zur Validierung eine bessere Option sein.
- Kann die Last der Beschaffung von Widerrufsinformationen auf den Authentifizierer verlagert werden, wenn dieser über eine zuverlässige Verbindung verfügt?
Diese Technik wird als OCSP Stapling (RFC 6066) bezeichnet. Im zuvor genannten Beispiel kann die Ladestation bei der Authentifizierung am angeschlossenen Elektroauto eine OCSP-Antwort übermitteln. OCSP Stapling wird für die TLS-Server-Authentifizierung unterstützt. Für die TLS-Client-Authentifizierung wird es leider nicht unterstützt, es könnte jedoch auf der Anwendungsebene der Kommunikation implementiert werden.
- Kann der Widerrufsprozess durch eine häufige Verlängerung von kurzlebigen Zertifikaten ersetzt werden?
Damit wäre ein Zugriff der validierenden Partei auf den CDP oder den OCSP-Dienst nicht mehr erforderlich. Stattdessen erneuert der Authentifizierer sein Zertifikat mit einer ähnlichen Frequenz, mit der auch die CRLs ausgegeben würden. Der Effekt ist ähnlich wie beim OCSP Stapling. Der Vorteil besteht darin, dass keine CDP oder OCSP-Dienste benötigt werden, wodurch die PKI-Dienstinfrastruktur vereinfacht wird. Die CA muss stattdessen eine interne Blacklist (oder Whitelist) führen und die Zertifikatsverlängerung für Geräte, die deaktiviert wurden oder auf der Blacklist sind, ablehnen. Die Verlängerung wird durch Standardprotokolle zur Zertifikatsverwaltung wie SCEP, CMP oder EST unterstützt. Andererseits kann die Verteilung des Erneuerungsdienstes auf mehrere Knoten schwieriger sein als bei CDP oder OCSP. Meiner Meinung nach eignet sich dieser Ansatz für Fälle, in denen die Zertifikate ohnehin häufig aktualisiert werden müssen, z. B. aus Datenschutzgründen, um eine Rückverfolgung zu verhindern oder die Minimierung der Codegröße im Validierungsgerät wichtig ist.
Widerruf einer Root-CA
In einer herkömmlichen PKI wird der Widerruf einer Root-CA über einen Out-of-Band-Mechanismus angekündigt, beispielsweise über eine unabhängige Webseite, eine offizielle Bekanntmachung oder einen anderen öffentlich zugänglichen und vertrauenswürdigen Kanal. Verantwortliche Anbieter und IT-Administratoren werden dann aufgefordert, das Zertifikat der Root-CA aus vertrauenswürdigen Zertifikatsspeichern (Trust Stores) zu entfernen.
Ein IoT-Gerät, das an einem Standort installiert ist, verfügt in der Regel über keinen zweiten Mechanismus, um den Widerrufstatus von Root-Zertifikaten zu überprüfen. In diesem Fall ist die folgende Überlegung hilfreich:
- Gibt es einen Wartungsdienst in der Infrastruktur, der widerrufene Root-Zertifikate aus dem Trust Store der Geräte entfernen kann?
Dies ist häufig der Fall bei Fahrzeugen, die über einen Telematikdienst mit den Backend-Systemen des Herstellers kommunizieren. Die Pflege von Trust Stores kann auch mit dem Software-Wartungsprozess des Geräts verknüpft werden. Um diese Art der Kommunikation zu sichern, wird ein unabhängiges PKI-System empfohlen, das die Liste der vertrauenswürdigen Zertifikate signiert. Andernfalls deaktiviert eine kompromittierte Root-CA die Überprüfung der aktualisierten Trust-Liste.
- Die Ankündigung des Widerrufs der Root-CA in der eigenen CRL der Root-CA ist eine ungewöhnliche, aber effektive Vorgehensweise. Ist dies eine geeignete Möglichkeit für Ihre IoT-Anwendung?
Es ist ein interessanter Ansatz, die Kompromittierung der Root-CA über die CRL der Root-CA selbst bekannt zu geben, welche mit dem kompromittierten Schlüssel signiert ist. Der Vorteil ist, dass kein zweiter Kanal oder Wartungsmechanismus benötigt wird, aber das Gerät selbst kann die Kompromittierung der Root-CA erkennen. Voraussetzung dafür ist, dass der CDP-Dienst nicht beeinträchtigt wird. Beachten Sie auch, dass der Standard-Validierungsalgorithmus (RFC 5280) dieses Vorgehen nicht unterstützt, so dass hier eine kundenspezifische Implementierung erforderlich ist. Der Vorteil ist, dass der reguläre Validierungsalgorithmus ohne Verwendung eines zweiten Kanals und zusätzlichen Codes das Ergebnis „falsch“ liefert.
Fazit
Der klassische Validierungsalgorithmus, wie er in RFC 5280 definiert ist, geht von einer zuverlässigen Verbindung zu einer zentralen Widerrufs- und Validierungsinfrastruktur aus, d. h. zu einem CDP und/oder einem OCSP-Dienst. Im Internet der Dinge ist die Verbindung zu einem solchen zentralen Dienst für einen zuverlässigen Betrieb möglicherweise nicht so ausfallsicher wie gewünscht. Außerdem kann die Verbindung zu zentralen Diensten auch indirekt über ein Gateway oder ein anderes System erfolgen. Die strikte Anwendung des Standard-Validierungsprozesses kann zu einem Verlust der Verfügbarkeit und des Benutzerkomforts führen. In diesem Blog haben wir eine Reihe von möglichen Überlegungen aufgelistet, welche die Verfügbarkeit und den Benutzerkomfort des IoT-Dienstes verbessern können. Dazu gehören geringfügige Änderungen in der Verwendung der Zertifikatsgültigkeit (lebenslange Gültigkeit, kurzlebige Zertifikate) und des Validierungsalgorithmus sowie Mechanismen wie das Zwischenspeichern von Widerrufsinformationen, OCSP Stapling oder Erneuerungen sowie die Ankündigung einer Kompromittierung der Root-CA. Fazit: Die Entwickler sollten auf jeden Fall die Art der Anwendung berücksichtigen und dementsprechend aus mehreren Optionen wählen, um die Gesamt-Performance der IoT-PKI zu optimieren. Bitte beachten Sie, dass die Überlegungen in diesem Blog-Artikel lediglich als Denkanstöße dienen sollen und keinen Anspruch auf Vollständigkeit erheben.