Überlegungen zur IoT-Sicherheit

Selten implementiert ein Unternehmen ein IoT-Produkt nur wegen der Technologie. Die Diskussion, wie, wo und warum IoT-Konzepte genutzt werden, um einen unternehmerischen Mehrwert zu schaffen, gehört demzufolge auf die Führungsebene. Je nachdem wie die Antworten ausfallen, sind bestimmte Produkte mehr oder weniger geeignet. Zusätzlich macht man sich Gedanken über Konnektivität und Integrationen, um schließlich eine bestimmte strategische Vision Wirklichkeit werden zu lassen. Die Risikobewertung und Auswahl von Sicherheitstechnologien innerhalb der IoT-Lösung, sind weitere kritische Faktoren. Allerdings werden sie meistens erst zu einem späteren Zeitpunkt im Entwicklungszyklus angesprochen. Diese Risikoprofilierung dient dazu, sämtliche der potentiellen Risiken für Sicherheit und Datenschutz sowie gefährdete Bereiche im Detail zu betrachten.

Die Risikotragweite und die damit verbundenen Bedenken sind von vielen Faktoren abhängig. Zum Beispiel von der allgemeinen Risikoschwelle des Unternehmens selbst und der Branche, aber auch rechtliche Limitierungen spielen eine Rolle. Bei einem Risikoprofil sollten Unternehmen sich darüber klar sein, welche Bereiche erfasst und in Verbindung mit einer IoT-Lösung gegebenenfalls eingegrenzt werden sollten.

Risiken und Angriffsvektoren definieren und bewerten
Betrachten wir zunächst eine Stichprobe potentieller Risiken und Angriffsvektoren. Viele der Attacken im IoT spiegeln traditionelle Cyber-Attacken wider, wie beispielsweise Thing in the Middle, Denial of Sleep, Eavesdropping, Snooping oder eine Replay-Attacke. Die Folgen dieser Attacken sind recht unterschiedlich und hängen von den Eigenschaften des Ökosystems und der Geräteumgebung ab sowie von den bereits erwähnten geschäftlichen Risiken. Es sei gestattet, ein wenig zu verallgemeinern, um das Problem einzugrenzen. Legen wir das Konzept „Thing in the Middle“ zugrunde, können wir uns ein Szenario vorstellen, bei dem feindselige Dritte die Temperaturdaten eines Überwachungsgerätes fälschen. Das würde eine Maschine zum Überhitzen bringen und somit der Betriebsorganisation physischen und finanziellen Schaden zuzufügen. Es gibt eine Reihe technischer Komponenten, die man verwenden kann, um das Risiko einzugrenzen. Letztendlich wollen wir aber doch wissen, ob der Dienst den Daten aus dem Gerät vertrauen kann. Vertrauen ist ohnehin ein ausgesprochen interessantes Konzept in derartigen IoT-Ökosystemen. Das Konzept hängt nicht nur von der Definition des Begriffs ab, sondern auch von den Sicherheitsanforderungen der empfangenden Parteien sowie den technischen Fähigkeiten am Endpunkt der jeweiligen Systeme.

Ein im Kern mit dem Thema Vertrauen verwandtes Konzept ist das der Identität. Wie kann ein Dienst, der Sensordaten empfängt und darauf basierend Entscheidungen trifft, sowohl dem Sender der Daten als auch den empfangenen Daten vertrauen? Zuerst muss der Dienst Vertrauen zur Datenquelle herstellen – das betrifft die Authentifizierung. Zweitens muss er sicher sein, dass die Daten beim Versenden über das Netzwerk nicht modifiziert worden sind – das ist Integrität.

Der überwiegende Teil der Diskussionen konzentriert sich auf die Authentifizierungsseite der Gleichung. Wie authentifiziert das Gerät sich und kann den Diensten beweisen, dass es eine vertrauenswürdige Instanz ist? Authentifizierung ist auf verschiedene Arten möglich: über den Gerätenamen, ein Passwort, ein gemeinsames Geheimnis, API-Keys, symmetrische Keys oder zertifikatbasierte Schlüssel per PKI. Jede dieser Lösungen balanciert zwischen Sicherheit, Vertrauenswürdigkeit, Benutzerfreundlichkeit, Skalierbarkeit, Machbarkeit und nicht zuletzt den Implementierungskosten. Wie kann beispielsweise für die empfangenden Dienste sichergestellt werden, dass ein Gerät seine wahre Identität mitteilt?

Vertrauenswürdigkeit einschätzen
Schauen wir uns das Szenario Gerätename/ Passwort verglichen mit digitalen Zertifikaten und PKI-Nutzung an. Folgende Fragestellungen sind grundlegend:

Starke Identitäts- und Authentifizierungsmechanismen
In diesem Rahmen sprechen wir von einer „Best-Practice“ PKI-Implementierung und vergleichen sie mit dem traditionelleren Gerätenamen/Passwort-Szenario. Ziel soll es sein, das Risiko zu senken und gegenüber Thing-in-the-Middle-Attacken weniger angreifbar zu sein.

Einer der Vorteile von PKI im Kontext eines Gerätes ist, dass man sie einsetzen kann, ohne dass der empfangende Dienst einen Teil des Gerätegeheimnisses kennt. PKI besteht aus zwei Teilen: Einem öffentlichen, oft an ein Identitätszertifikat gebundenen Schlüssel, der öffentlich geteilt werden kann, und privaten Schlüsseln, die genau das auch bleiben sollten. In einer Geräteumgebung empfiehlt es sich, eine sichere Hardware für das Erzeugen und Speichern von privaten Keys zu nutzen, wie etwa ein Trusted-Plattform-Modul oder etwas gleichwertiges. Diese Hardwarecontainer bieten dahingehend einen hohen Sicherheitslevel, dass die privaten Keys nicht offengelegt wurden oder werden. Solche sicheren Hardwarekomponenten sind die Basis um vertrauenswürdige Identitäten aufzubauen.

Die Sicherheit des Key-Speichers erlaubt es dann innerhalb einer zertifikatbasierten PKI-Anwendung, ein digitales Zertifikat herauszugeben, das irgendeine Form von Identitätsinformation mit dem öffentlichen Key verbindet, der zu dem privaten Key passt.

Dieser Prozess wird häufig bei Geräten in Fertigungsstraßen angewandt. Dieses digitale Zertifikat kann nun in einer Reihe von Szenarien verwendet werden. Man kann das Gerät authentifizieren und man kann selbständige Verhandlungen ermöglichen, um die Kommunikation zwischen den empfangenden Diensten zu schützen. Dabei bleibt der private Schlüssel immer geheim.

Vergleicht man diese Herangehensweise mit dem klassischen Modell „Benutzername und Passwort“, werden dessen Nachteile bei der Vertrauenswürdigkeit nur zu schnell offensichtlich. Benutzername und Passwort müssen irgendwo erzeugt werden. Das kann vielleicht auf dem Gerät selbst stattfinden, fällt aber meist in den Bereich anderer Dienste. Sie teilen dann dem Gerät die entsprechenden Daten zu. Und gerade dabei gibt es etliche Stellen, an denen Zugangsdaten potenziell abgefangen werden können.

Schauen wir uns jetzt an wie diese Daten für die Authentifizierung bei Diensten genutzt werden. Idealerweise sollten Zugangsdaten über einen verschlüsselten Kanal transportiert werden, damit sie nicht abgefangen werden. Das Abfangen von Zugangsdaten mit Benutzername/Passwort ist ein erhebliches Risiko. In einem PKI-Szenario ist es deutlich geringer, denn ausgetauscht werden nur der öffentliche Schlüssel und das Zertifikat. Letzteres lässt sich wiederum ohne den entsprechenden privaten Schlüssel nicht nutzen. Und der liegt sicher im Speicher des Geräts.

Ein PKI-Szenario hat aber noch mehr Vorteile. Man kann sich zum Beispiel für einen Authentifizierungsansatz wie Mutual TLS entscheiden. Dabei authentifiziert sich jede der beteiligten Parteien. Gleichzeitig wird durch den Handshake ein sicherer Kanal zwischen den beiden Punkten eingerichtet. Im Szenario Gerätenamen/Passwort wird der sichere Kanal in der Regel erst in einen separaten Vorgang eingerichtet.

Schauen wir uns zuletzt die Lebensdauer der Geräte an. Es ist ganz offensichtlich, dass man Mechanismen braucht, die Geräte zu aktualisieren, während sie im Einsatz sind. Das ist zweifelsohne nicht ganz einfach, sollte aber in jedem Fall machbar sein. Benutzt man eine PKI sollte das Gerät mit sicherer Hardware bei Bedarf neue Keys erzeugen und den Diensten Signieranfragen für aktualisierte Zertifikate zuschicken. Auch in diesem Szenario bleiben die privaten Komponenten privat. Werfen wir demgegenüber einen Blick auf Gerätenamen/Passwort ist gerade das Aktualisieren und Teilen neuer Zugangsdaten eine heikle Angelegenheit. Egal, ob es darum geht neue Zugangsdaten zu erzeugen, zu speichern oder an einen Dienst zu transportieren.

Nur die Spitze des Eisbergs
Identität ist ein riesiges Gebiet. Eine ganzheitliche Herangehensweise hilft dabei, eine sichere und vertrauliche Architektur für ein IoT-Ökosystem aufzubauen. Betreiber und Gerätehersteller sollten unbedingt Partner mit ins Boot nehmen, die erfahren sind und das nötige Fachwissen zu sicheren Kommunikationslösungen mitbringen. Eigenentwicklungen oder angepasste Lösungen erfüllen selten das Anforderungprofil. Sicherheit funktioniert nicht nach dem Baukastenprinzip. Vielmehr muss ein Unternehmen seine Ziele analysieren und diese dann mit den individuell akzeptablen Risiken ausbalancieren. [bl]

Info:
https://www.globalsign.com/de-de/