GlobalSign Blog

07 Dez 2015

Sichere IoT-Ökosysteme: Von oben nach unten aufbauen

Welche Form von IoT-Sicherheit?

Es gibt viele Ansätze zur Identifizierung und Authentifizierung von Geräten bei Diensten. Letztendlich sollten und werden die Mechanismen, für deren Verwendung sich ein Unternehmen entscheidet, von der gewählten Strategie bestimmt sein und diese Entscheidungen aus Sicht der Führungsebene getroffen werden.

Zu einer IoT-Strategie gehören zwei zentrale Faktoren. Sehr 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 aufgrund ihrer Fähigkeiten 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.

Risikobewertung und die Auswahl von Technologien, die innerhalb der IoT-Lösung das Risiko eingrenzen, sind weitere kritische Faktoren, die auf jeden Fall analysiert werden sollten. 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, die Gefahr von Betrug und sonstige gefährdete Bereiche zu betrachten. Die Risikotragweite und die mit jedem Bereich verbundenen Bedenken sind von vielen Faktoren abhängig. Zum Beispiel von der allgemeinen Risikoschwelle des Unternehmens selbst, die Branche, aber auch rechtliche Limitierungen spielen eine Rolle. Bei einem Risikoprofil sollten Unternehmen sich darüber klar sein, welche Bereiche es erfassen und es in Verbindung mit der IoT-Lösung gegebenenfalls eingrenzen sollte.

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 eingrenzen zu können. Legen wir das Konzept „Thing in the Middle“ zugrunde, können wir uns ein Szenario vorstellen, wo 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 vertrauende Dienst den Daten aus dem Gerät vertrauen kann. Vertrauen ist ohnehin ein sehr interessantes Konzept in derartigen IoT-Ökosystemen. Es 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 basierend darauf 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 seit dem Versand ü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 unterschiedliche Art und Weise 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:

  • Wie sind die Zugangsdaten generiert worden?
  • Wie sind sie dem Gerät mitgeteilt worden?
  • Wie sind sie auf dem Gerät gespeichert?
  • Sind die Zugangsdaten jemals als Klartext versandt worden, sodass Dritte sie hätten abfangen können?
  • Sind die Zugangsdaten nach der Zuteilung aktualisiert worden und falls ja, war diese Aktualisierung sicher?

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 bieten eine großartige 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 die Nachteile für die 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 durch 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 haben. 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.

Artikel teilen