Public-Key-Infrastruktur (PKI) für IoT- und IIoT-Geräteherstellende

Identity und Access Management (IAM) in typischen IT-Umgebungen von Unternehmen stützen sich auf eine Vertrauenskette, die auf menschlichen Identitäten beruht: Zum Beispiel ein Personalausweis, eine Sozialversicherungsnummer und andere offizielle Dokumente, die auf unserer Geburtsurkunde basieren, die von einer Behörde registriert und abgestempelt wurde. PKI-Systeme sind eine Möglichkeit, eine ähnliche Vertrauenskette für Maschinenidentitäten zu replizieren – für verbundene Geräte, die in Fabriken in Massenproduktion hergestellt werden und eine „digitale Geburtsurkunde (Birth Certificate)“ erhalten, die von einer vertrauenswürdigen Zertifizierungsstelle registriert und signiert wird.

Use Cases für IoT-Ökosysteme decken den gesamten Dreiklang von Vertraulichkeit, Integrität und Verfügbarkeit ab:

  • Fälschungssichere Geräteidentitäten (auch Maschinenidentitäten oder IDevIDs genannt, z. B. zum Nachweis der Echtheit des Geräts, um Fälschungen zu verhindern)
  • Starke Geräteauthentifizierung gegenüber Behörden, Verzeichnissen und anderen Netzwerk- oder Cloud-Diensten sowie zwischen Geräten. Da IoT-Geräte vor Ort nicht durch die üblichen IT-Sicherheitskontrollen eines Unternehmens, wie z. B. Perimeter-Firewalls, geschützt sind, sind sie anfälliger für Angriffe, wie z. B. Spoofing von Kontrollservern oder Man-in-the-Middle-Angriffe (MITM). IoT-Geräte, die kompromittiert wurden, können ausgenutzt werden, um Daten von Servern zu extrahieren oder Zugang zu anderen Systemen zu erhalten.
  • Zugangskontrolle für Nutzende, Geräte und Dienste einschließlich APIs
  • Vertraulichkeit und Datenschutz, z. B. durch Verschlüsselung von Daten im Ruhezustand und bei der Übertragung von/zu IoT-Geräten, wie Prozessparameterströme oder medizinische Daten
  • Code-Signierung für Bereitstellung, sicheres Booten und Firmware-/Software-Patches
  • Datenintegrität (z. B. bei medizinischen Geräten oder bei der Zustandsüberwachung von Aktuatoren mit hoher Leistung/hoher Auswirkung wie Ventilen in einer Pipeline oder Drohnenmotoren)
  • Überwachung von Geräten auf ungewöhnliches Verhalten und ggf. Entzug von Berechtigungen,
  • Absicherung von Geräten gegen Angriffe wie Manipulation, Denial-of-Service-Botnets oder Ransomware im Allgemeinen und Schaffung der Voraussetzungen für eine Zero-Trust-Architektur

CyberCompare hat mehrere IoT-Herstellende durch den Prozess der Spezifikation von PKI-Systemen, den Vergleich von Angeboten und die Auswahl von PKI-Anbietern (oder Anbieterkombinationen) unterstützt. Hier sind ein paar Aspekte, die vor einer Entscheidung zu beachten sind.

Ist eine PKI für alle (I)IoT-Geräte zwingend erforderlich oder empfehlenswert?

Während Angriffe auf IoT-Geräte zunehmen, lautet die Antwort eindeutig nein – z. B. für Sensoren, die keine Daten verarbeiten und während ihrer Lebensdauer keine Software-Updates erhalten, kann in den meisten Fällen ein statisches Zertifikat ausreichend sein. Kameras mit Systems on Chip, SPS, elektronische Steuergeräte für Fahrzeugkomponenten, Stromversorgungen oder medizinische Geräte sind typische Beispiele für IoT-Geräte, die in der Regel durch PKI-Systeme geschützt werden. Eine systematische Risiko- und Bedrohungsanalyse sollte immer als Grundlage für die Entscheidungsfindung dienen. Generell gilt: Je höher die Geräte im Purdue-Modell angesiedelt sind, desto wahrscheinlicher ist ein PKI-System die beste Lösung für die Einrichtung eines Identity und Access Managements.

Können sowohl öffentliche als auch private PKI-Infrastrukturen für das Identitätsmanagement von (I)IoT-Geräten genutzt werden?

Herstellende von IoT-Geräten müssen sich auf irgendeine Weise ein Stammzertifikat (in der Regel nach dem X.509-Standard) beschaffen, entweder durch den Kauf bei einer öffentlich vertrauenswürdigen Stammzertifizierungsstelle (CA) oder durch die Ausstellung bei einer privaten CA. Beides ist möglich, mit unterschiedlichen Vor- und Nachteilen (die Verwaltung privater Stammzertifizierungsstellen ist natürlich viel aufwändiger, aber für IoT-Anwendungen üblich). Vor dem Anschluss von Geräten werden die Zertifikate zentral registriert (z. B. in einer der IoT-Plattformen der Cloud-Hyperscaler) und in einer Vertrauenskette signiert.

Was sind typische Einschränkungen für (I)IoT-Geräte, die beim Aufbau der PKI-Architektur berücksichtigt werden sollten?

Das Lifecycle-Management von Zertifikaten, einschließlich Entwurf, Herstellung, Zertifikatsregistrierung, Widerruf und Aktualisierung bis hin zur Außerbetriebnahme (d. h. Trennung von Diensten, Bereinigung von Daten, Zurücksetzen auf die Werkskonfiguration), ist im Allgemeinen eine größere Herausforderung als für menschliche Nutzer:

  • Geräte können jahrzehntelang genutzt werden und in manchen Fällen die besitzhabende Person wechseln. Softwareversionen und -parameter können veraltet oder auch kundenspezifisch sein.
  • Wie kann der Überblick über alle Ihre Geräte, Nutzende und Zertifikate sichergestellt werden? Zertifikatsbestände, die Einblick in die Vertrauenskette, den aktuellen Standort und die Ablaufzeiten bieten, wachsen mit der Zeit und müssen grenzüberschreitend skalierbar sein.
  • Wie kann auf Geräte vor Ort zugegriffen werden, um Zertifikate zu erneuern? Zum Beispiel durch das Wartungspersonal? Die Konnektivität im Feld ist oft intermittierend und kann von der IT/OT-Netzwerkarchitektur des Eigentümers abhängig sein.
  • Gerätezertifikate müssen mit vor- oder nachgelagerten PKI-Systemen kompatibel sein, da die Komponenten Teil eines größeren Systems sein können. Es gibt Anforderungen an die physische Produktion, wie z. B. die Nachverfolgung von Zertifikaten, die zwar ausgestellt, aber nie ausgeliefert wurden (z. B. aufgrund von Qualitätsproblemen). Da die Sicherheit der Betriebstechnik (OT) in der Regel eine direkte Internetanbindung von Montagelinien verbietet, muss eine sichere Batch-Zertifikatsausstellung in regelmäßigen Abständen ermöglicht werden, möglicherweise durch werkseigene Zertifizierungsstellen und sichere Gateways. Die Schlüsselgenerierung auf elektronischen Steuergeräten kann zeitaufwändig sein und zu einem Engpass in der Produktion werden, der die Gesamtproduktionskapazität verringert.

Begrenzte Rechenleistung, RAM-Speicher und Speicherplatz der Geräte können sich darauf auswirken, z. B. indem sie die asymmetrische Verschlüsselung unpraktisch machen und den Austausch symmetrischer Schlüssel erforderlich machen.

PKI-Anbietende und -Dienstleistende

Einige Anbietende bieten nur Komponenten (einschließlich einiger Open-Source-Produkte) wie eine private CA oder eine Zertifikatsverwaltungssoftware an, während andere komplette Systeme sowie verwaltete Dienste (PKIaaS) bereitstellen. Neben großen Beratungsunternehmen und MSSPs gibt es auch kleinere Anbietende, die sich auf PKI spezialisiert haben, darunter z. B. Achelos, IDependant oder PKI Solutions.

Entrust (nCipher), Fortanix, Futurex, IBM, Swissbit, Thales, Utimaco und Yubico  gehören zu den führenden Anbietern von Hardware-Sicherheitsmodulen (HSM). HSMs werden in der Regel über den PKCS#11-Standard mit PKI-Anwendungen verbunden und für sichere und schnelle kryptografische Operationen (wie Anforderungsvalidierung, Signierung, Entschlüsselung, Schlüsselgenerierung) und Schlüsselspeicherung verwendet, so dass private Schlüssel nicht im RAM gespeichert werden müssen.

Einige Faktoren, die bei der Beschaffung einer PKI-Umgebung zu berücksichtigen sind

Eine fundierte Entscheidung sollte auf einer technischen und wirtschaftlichen Bewertung mehrerer Lösungen beruhen. Bei der Auswahl von PKI-Systemen haben sich die folgenden Anforderungen als wiederkehrende Themen herauskristallisiert.

Einhaltung der angestrebten PKI-Architektur und der Prozesse des Nutzungsszenarios, z. B.:

  • Anzahl der CA-EbenenEinsatz von CAs vor Ort / in der Cloud für dezentrale Fabriknetzeprivate oder öffentliche Root-CAsHosting von CAs und Zertifikatsmanagement-Anwendungen, Qualitätssicherungssystem zum Testen von Änderungen (möglicherweise mit emulierten HSMs), Sichere Injektion von Erstzertifikaten in Fabriken für in Produktion befindliche Geräte
    • Weitere Überlegungen betreffen die Anbindung an MES/SCADA-Systeme, die Verwaltung verteilter Zertifizierungsstellen, Verfügbarkeitsanforderungen, Sicherungssysteme, Schlüsselspeicherung, Verwaltung von Vertrauenslisten. Soll z. B. das HSM nur für die Schlüssel der Kunschaft bestimmt sein oder soll es gemeinsam genutzt werden? Wenn es gemeinsam genutzt wird, kann die Übertragung von einem verwalteten Dienstanbietenden schwierig sein
    • Kompatibilität mit bestehender und geplanter Gerätearchitektur, insbesondere für Mikrocontroller (z.B. ARM, Infineon) und Embedded RTOS (ggf. ohne Trusted Platform Module/TPM)
    • Integration in die kundenspezifische Dev(Sec)Ops-Toolkette und IT-Infrastruktur, insbesonderegemeinsame IoT-Lösungen für die Verwaltung mobiler Geräte (z. B. Intune oder SOTI)Cloud-Infrastruktur IoT-Plattformen zur Verwaltung der Geräte und zur Speicherung und Verarbeitung der Daten (z. B. Azure IoT Hub, AWS IoT, PTC ThingWorx, Wipro) 
    • vorhandenes Active Directory oder andere Identitätsdienste
  • Erfahrung mit dem Management des gesamten Gerätelebenszyklus und der Gestaltung der IoT-Infrastruktur durch den Systemanbietenden, wie z. B. die Einrichtung neuer Fertigungsstraßen oder Produktionsstätten in den betreffenden Ländern oder die Aktualisierung von Betriebssystemen oder Anwendungspatches zur Fehlerbehebung und Funktionserweiterung. Wie viele Schlüssel hat die Zertifizierungsstelle des Anbieters bereits an wie viele Feldgeräte ausgegeben? Welche Anwendungen, welche Branchen und wann wurden diese Geräte von der Endkundschaft genutzt? Ist es möglich, ein Referenzklientel zu kontaktieren oder den Betrieb von Rechenzentren zu besuchen?
  • Gemeinsame Protokolle und Standards für automatische Anmeldung, Bereitstellung, Zertifikatsanforderung, Validierung, Schlüsselspeicherung und Kommunikation werden unterstützt (z.B. ACME, CoAP, CEP/CES, CMPv2, CRL, CRMF, EST, MQTT, NDES, OCSP, OPC UA, PKCS#10 / #12,  RFC8628 OAuth2.0, REST, SCEP, SPKAC)
  • Erfüllung allgemein empfohlener Sicherheitspraktiken (siehe unter anderem Cloud Security Alliance IoT Working Group, IOT Security Foundation, NIST SP 800-160 on Systems Security Engineering, NISTIR 8259A IoT Device Cybersecurity Capability Core Baseline oder Microsoft) für PKI-Infrastrukturen, z. B. formale Schlüsselzeremonien für alle Elemente der CA-Hierarchie oder die Möglichkeit der biometrischen Authentifizierung. MFA ist offensichtlich, aber welche Authentifikatoren/Tokens werden in welchen Situationen unterstützt?
  • Unterstützung der stärksten und IoT-spezifischen Verschlüsselungen, Hashing-Algorithmen und Schlüsselgrößen (z. B. Ascon, ECDSA, Edwards, RSA, SHA-2/3)
  • Ist es notwendig, dass Komponenten oder Dienstleistungen bestimmte Zertifizierungen haben (z. B. CC EAL 4+, eIDAS, FIPS L2/3…, PCI DSS, SOC2 Type 2) oder branchenspezifische Normen einhalten (z. B. automotive industry vehicle-to-X, PSDS2, HIPAA, NATO Restricted)? Wenn ja, werden System- und Dienstleistungsanbieter wie Betreiber von Rechenzentren in der Lage sein, diese Audits zu bestehen?
  • Benutzerdefinierte X.509- oder andere Zertifikatsvorlagen und Richtlinien (z. B. Ablageregeln)
  • SLAs für Supportfälle und Dienstleistungen, z. B. Reaktionszeiten und Verfügbarkeit
  • Preis-/Leistungsverhältnis: Die Lizenzierungsmodelle unterscheiden sich erheblich in Bezug auf die einmaligen Kosten für die Einrichtung und Implementierung von Anwendungsfällen, die Abonnementgebühren, die Kosten pro Behörde und die Kosten pro Zertifikat oder Stelle. Einige Anbietende haben ihre Lösungen für die globale Massenproduktion optimiert („Skalierbarkeit“), während andere auch bei großen Stückzahlen kosteneffizient sind. Bietet der Anbieter als Generalunternehmer eine schlüsselfertige Lösung an, oder was genau ist auf Seite der Kundschaft erforderlich, damit alle Schnittstellen ordnungsgemäß funktionieren?

Zusammenfassung

PKI ist eine bewährte Standardlösung für die Feststellung von Maschinenidentitäten und die Gewährleistung der sicheren Nutzung von (I)IoT-Geräten mit angemessener Rechenleistung. Es gibt zahlreiche Anbietende und Dienstleistendde, die Lösungen anbieten. Viele von ihnen haben bewiesen, dass sie in der Lage sind, PKI-Umgebungen für Milliarden von angeschlossenen Geräten einzurichten oder zu betreiben.

Die Auswahl eines PKI-Systems ist unserer Erfahrung nach ein komplexes Projekt, bei dem sich das Zielkonzept mit der Zeit weiterentwickelt und die Liste der Anbieter iterativ auf der Grundlage eines besseren Verständnisses der Angebote reduziert wird. Es tauchen Ausschlusskriterien auf, die anfangs nicht offensichtlich waren, und Merkmale, die als einzigartig galten, werden manchmal neu bewertet, da sie keinen bedeutenden Unterschied machen.

Eine spezialisierte Beschaffungsberatung mit Erfahrung in PKI-Projekten für (I)IoT-Hersteller kann helfen, Zeit und interne Ressourcen zu sparen und gleichzeitig ein gutes Preis-/Leistungsverhältnis zu erzielen.

Vielen Dank an Dall-E2 für die Unterstützung bei der Erstellung der Grafiken.

Übrigens: Der Artikel spiegelt unseren aktuellen Wissensstand wider – aber auch wir lernen jeden Tag dazu. Fehlen aus Ihrer Sicht wesentliche Aspekte, oder haben Sie eine andere Perspektive auf das Thema? Gerne diskutieren wir mit Ihnen und weiteren Experten in Ihrem Hause die gegenwärtigen Entwicklungen vertiefend und freuen uns über Ihr Feedback sowie Anfragen zu einem Austausch.

Und zuletzt noch: Nennungen (oder die fehlende Nennung) von Anbietern stellt keine Empfehlung seitens CyberCompare dar. Empfehlungen sind immer abhängig von der kundenindividuellen Situation.

Nach oben scrollen