IoT-Geräte senden und empfangen Daten und Befehle über das weltweite Internet. Dadurch sind sie einer deutlich größeren Vielfalt von Gefahren ausgesetzt, als das bei älteren Produkten, die nur die M2M-Kommunikation über ein geschlossenes privates Netzwerk unterstützen, der Fall war.
Das ursprünglich von Microsoft entwickelte STRIDE-Modell zur Bedrohungsklassifizierung führt folgende mögliche Sicherheitsrisiken auf, denen ein IoT-Gerät (IoT: Internet der Dinge) oder dessen Benutzer ausgesetzt ist: Spoofing (Vortäuschen einer falschen Identität), Tampering (Verändern von Daten), Repudiation (Abstreiten von Aktionen), Information Disclosure (Preisgabe von Informationen), Denial of Service (Störung eines Diensts) und Elevation of Privilege (unbefugtes Erlangen von Rechten).
Sicherheitsfunktionen und Ressourcen, die benötigt werden, um ein IoT-Gerät vor diesen Bedrohungen zu schützen, sind heute als diskrete Spezial-ICs verfügbar, z.B.
Der Einsatz solcher diskreter ICs in IoT-Geräten erhöht jedoch die Anzahl der Bauteile, die Komplexität und die Materialkosten im Vergleich zu Designs, die die integrierten Sicherheitsfunktionen der Host-MCU (oder in einigen Fällen eines Anwendungsprozessors) nutzen. Die wichtige Frage für die Entwickler von IoT-Geräten ist daher, ob die Leistung der Host-MCU ausreicht, um die im STRIDE-Modell beschriebenen Bedrohungen zu beherrschen.
Dieser Artikel untersucht die Sicherheitsanforderungen von IoT-Geräten für Konsum und Industrie in der Praxis und beschreibt die Sicherheitstechnologien, die die nächste Generation von MCUs für das IoT bieten muss, um diese Anforderungen zu erfüllen.
Die Notwendigkeit mehrerer Schutzebenen
IoT-Geräte sind aufgrund ihrer Vernetzung verwundbar. Ein vernetztes Armband, das z.B. die Herzfrequenz und den Sauerstoffgehalt im Blut eines Patienten überwacht, kann ständig sensible persönliche Daten über eine drahtlose Verbindung an eine medizinische Anwendung senden, die bei einem Cloud-Dienstleister gehostet wird.
Es hilft, sich die Verwundbarkeit dieser Art von Geräten – und damit den erforderlichen Schutz – in mehreren Ebenen vorzustellen. So ist z.B. eine Ebene die Verbindung im persönlichen Netzwerk, gewöhnlich eine BLE-Funkverbindung (BLE: Bluetooth Low Energy) zu einem Smartphone oder Tablet, mit dem das Armband gekoppelt ist. Eine Erweiterung dieser Ebene könnte die WiFi-Verbindung dieses Smartphones oder Tablets zu einem Router oder Gateway sein. Die zweite Ebene ist die Cloud-Plattform, wie Microsoft Azure oder Amazon AWS, und die dritte Ebene ist die Anwendung selbst, die in der Cloud läuft. Je nach Architektur können noch weitere Ebenen definiert werden. Natürlich erwartet der Anwender des Armbands, das Gerät nutzen zu können, ohne sich Gedanken über potenzielle Sicherheitsbedrohungen machen zu müssen. Die folgenden Bedrohungen aus dem STRIDE-Modell kommen in Frage:
Das Armband kann für eine oder mehrere dieser Bedrohungen anfällig sein und das auf jeder der vorher beschriebenen Ebenen. Darüber hinaus ist es nicht empfehlenswert, nur einen Sicherheitsmechanismus für das gesamte vernetzte System einzusetzen. So ist zum Beispiel der Fall einer einzelnen Verwundbarkeit der Sicherheit bei Yahoo durch die Medien gegangen, bei dem Angreifer mit gefälschten Cookies zugangsberechtigte Benutzer vorgetäuscht haben (ein Spoofing-Angriff) und danach ohne Passwort auf die Benutzerkonten zugreifen konnten.
Ein derartiger Spoofing-Angriff auf einen Cloud-Dienst könnte den Kanal des Armbands zur Cloud für illegale Aktivitäten öffnen. Es ist daher unbedingt erforderlich, dass die Sicherheitsmechanismen, die die übrigen Ebenen schützen – die in der Cloud gehostete Anwendung ebenso wie die WiFi- und BLE-Verbindungen zum Internet – getrennt implementiert werden. Zum Beispiel sollte die Verschlüsselung der Herzfrequenzdaten, die an die Anwendung in der Cloud übertragen werden, mit einem anderen Schlüssel erfolgen als die Authentifizierung des Armbands gegenüber dem Cloud-Dienst.