IoT von Hardware bis Applikation sichern: Ein Layer-für-Layer-Blaupause

Von Wouter van der Beek

In der heutigen vernetzten Welt ist IoT-Sicherheit nicht mehr optional – sie ist regulatorisches Gebot. Neuere Gesetzgebung verlangt, dass Geräte „angemessene Sicherheitsfunktionen“ einbetten, was unterstreicht, dass die Kosten der Sicherung eines Geräts das Risiko bei Weitem überwiegen, es ungeschützt zu lassen.

Sicherheit ist in Schichten architektiert. Das Fundament beginnt bei der Hardware, gefolgt vom Netzwerk und schließlich der Applikation. Dieser Artikel fokussiert auf die Thread-Netzwerkschicht – ein kostengünstiges, energiesparendes, mesh-basiertes IP-Netzwerk – und die OCF-Applikationsschicht, die Geräteinteraktionen regelt.

Hardware-Sicherheit

Ressourcenbeschränkte Mikrocontroller müssen sich gegen bösartige Firmware und Hardware-Spionage schützen. Sichere Hardware erzwingt eine verifizierte Boot-Sequenz, signiert die Firmware und isoliert Speicher- und Peripheriezugriff. Nur ein vertrauenswürdiges, gut definiertes API kann kritischen Code erreichen, wodurch die Angriffsfläche minimiert und eine robuste Basis für höhere Sicherheitslayer geschaffen wird.

Netzwerksicherheit

Thread schützt Daten im Flug mit einem netzwerkweiten AES-CCM-Schlüssel. Jedes Paket erhält einen Authentifizierungstag und wird verschlüsselt, was Integrität, Vertraulichkeit und Authentizität sicherstellt. Der Schlüssel wird periodisch mittels einer counter-basierten Ableitung erneuert, um Kompromittierung zu verhindern.

Wenn ein neues Gerät beitritt, muss es den Netzwerkschlüssel sicher erwerben – ein Prozess, der als Commissioning bekannt ist. Thread nutzt Password-Authenticated Key Exchange (PAKE), Teil von DTLS, um ein niedrigstarkes Shared Secret in einen starken Schlüssel zu transformieren. Dies erlaubt dem Thread Commissioner (z. B. einem Smartphone), den Netzwerkschlüssel über einen verschlüsselten Kanal an das beitretende Gerät zu übertragen.

Applikationssicherheit

Auf Applikationsebene bietet die Open Connectivity Foundation (OCF) einen umfassenden Ownership-Transfer und Device-Provisioning-Flow. OCF stellt Gerätezertifikate aus und pflegt eine sichere Datenbank, die gegenseitige Authentifizierung via PKI-Infrastruktur ermöglicht.

Provisioning-Anweisungen werden über DTLS-verschlüsselte Kanäle übermittelt. Der Workflow beginnt mit Ownership-Transfer, durchläuft Statusübergänge und berücksichtigt Eigentümerwechsel, indem ein Hardware-Reset zum initialen Zustand verlangt wird.

OCF bietet zudem rollenbasierte Zugriffskontrolle und Manufacturer Usage Descriptors, die zusätzliche Schutzschichten gegen netzwerkbasierte Bedrohungen hinzufügen.

OCF-over-Thread auf ressourcenbeschränkter Hardware implementieren

Der Einsatz von OCF über Thread auf Low-Cost-Mikrocontrollern ist aufgrund begrenzten Codespeichers, Speichers und CPU-Ressourcen herausfordernd. Die Lösung liegt in Code-Wiederverwendung – das Teilen eines einzelnen kryptografischen Kerns (mbedTLS) über beide Stacks, da sowohl OCF als auch Thread auf DTLS basieren.

Kryptografische Primitiven profitieren von Hardware-Beschleunigung, was Commissioning-Zeit und Stromverbrauch drastisch reduziert. Das Management des Zugriffs auf diese Hardware via mbedTLS ist kritisch für Performance und Sicherheit.

Sowohl OCF- als auch Thread-Gruppen veröffentlichen Open-Source-Implementierungen, was Ambiguität eliminiert und Interoperabilität für Entwickler sicherstellt.

Wenn Applikations-, Netzwerk- und Hardware-Layer eng integriert sind, resultiert eine best-in-class sichere IoT-Plattform, die heute bereit für Deployment ist.

Autoren: Wouter van der Beek, Senior IoT Architect, Cisco Systems und Technical Working Group Chair, Open Connectivity Foundation; Bruno Johnson, CEO, Cascoda, Mitglied der Open Connectivity Foundation.