Sicherheit und Standards für das Internet of Things

Gegen Ende eines Jahres überwiegen in vielen technologischen Veröffentlichungen Jahresrückblicke und Prognosen für die kommenden Jahre. Eines der zentralen Themen ist gerade jetzt immer wieder das Internet of Things (IoT). Meist als einer der „Future Trends“ identifiziert, gibt es kaum einen Hersteller, keine Publikation und keinen Zukunftsausblick, die ohne dieses Thema auskommen. Das Potenzial scheint unermesslich, doch stellt man die Frage, welche „Dinge“ eigentlich betrachtet werden, so erschöpfen sich Antworten doch sehr schnell in den Standard-Antworten, also den Sensoren im Haus und am Körper von Fitnessfanatikern, der Smartwatch, der Heimautomatisierung und dem vernetzten Auto. Doch das IoT ist viel umfassender und wird erheblich umfangreichere Bereiche des alltäglichen Lebens betreffen.

Negativ-Schlagzeilen

Parallel zu diesen vielversprechenden Ausblicken vergeht kaum eine Woche, in der nicht ein neues sicherheitstechnisches IoT-Schreckensszenario aufgedeckt wird. Dies zeigt, dass sich das IoT in vielen Bereichen evolutionär noch in seiner Wild-West-Phase zu verorten ist. Hacks gegen medizinische Geräte, Industrieanlagen, Autos oder Consumer-Elektronik im Kinderzimmer beweisen, dass die Realität und der Anspruch in Bezug auf Sicherheit & Datenschutz oft noch diametral auseinandergehen. Im Kern der Entwicklung heute verfügbarer, erster Produkte steht immer wieder die reine Produktfunktionalität. Sicherheit wird, wenn überhaupt, erst sehr spät im Entwicklungsprozess und dann auch notgedrungen oft nur unzureichend implementiert. Kommt dann noch mangelnde Praxiserfahrung bei der Implementation von Sicherheitsinfrastrukturen hinzu, wie sie sich kürzlich in eklatanter Weise anhand der Wiederverwendung von Private Keys in einer Vielzahl von unterschiedlichen embedded systems gezeigt hat, kann dies die Sicherheit und Vertraulichkeit einer Vielzahl an Geräten von Routern bis Kameras ganz real gefährden.

Eingebaute Sicherheit und Privatsphäre

Die von Fachleuten stattdessen eingeforderte Orientierung hin zu einem fundamental auf „Security by Design“ und „Privacy by Design“ ausgerichteten Architekturkonzept lässt noch auf sich warten. Der Vergleich mit der Entwicklung, die das Thema Cloud in den letzten Jahren in Bezug auf Sicherheit, Governance und Compliance genommen hat, nicht zuletzt getrieben durch große Cloud-Anbieter Amazon, Microsoft oder auch SAP, liegt nahe.  Waren erste Cloud-Infrastrukturen strategisch auf Kostenersparnis und Funktionalität ausgerichtet, war Sicherheit anfangs eher ein Seitenaspekt, was den Einsatz in Sicherheits-relevanten Kunden-Umfeldern erschwerte bis verhinderte. Heutige Cloud-Infrastrukturen erreichen zum Teil durchaus ein Niveau an Sicherheit und Compliance, das in dieser Qualität in Firmen-Rechenzentren schwer zu erreichen sein kann.

Solche ersten Bemühungen finden sich nun auch im IoT-Umfeld, interessanterweise wieder getrieben gerade wieder durch die Cloud-Anbieter: Beispielsweise hat Amazon AWS im Nachgang der Re:Invent in Las Vegas eine Beta-Version seiner Vision für die Anbindung des IoT an die AWS Cloud Services vorgestellt.[Update 7.1.2016: AWS IoT steht nun generell zur Verfügung.] Interessant ist in diesem Zusammenhang, dass Amazon hier für die Kommunikation zwischen Dingen und den Diensten neben HTTPS auf den Einsatz des im traditionellen IoT-Umfeld etablierten und durch die OASIS standardisierten Protokolls MQTT (Message Queue Telemetry Transport) setzt. Als funktionale Besonderheit ist zu sehen, dass dieses Protokoll nicht nur auf TCP/IP, also den klassischen Internet-Protokollen, aufsetzen kann. Daneben ist es vielmehr auch in der Lage, in eingebetteten Systemen wie ZigBee Kommunikation zu ermöglichen.

Device-Zertifikate als eindeutige ID

Aus Sicherheits-technischer Sicht aber viel relevanter ist die Tatsache, dass in diesem Konzept durchgängig die Möglichkeit und Anforderung besteht, dass einzelne Devices durch individuelle Zertifikate identifizierbar werden und auf dieser Basis dann auch via TLS kommunizieren können. Hier findet sich also in größerem Rahmen für die Anwender von AWS-Systemen ein API-inhärenter Ansatz für „Security by Design“. Auch wenn dies nur einen eingeschränkten Teil der Sicherheitsanforderungen einer gesamten IoT-Landschaft abdeckt, so ist die Orientierung hin zu offenen Standards im Zusammenhang mit erprobter und auditierter, aktueller Verschlüsselung doch ein positives Zeichen.

Komplexität als Herausforderung

Während in diesem Konzept die einzelnen Dinge ihre Identität in Form eines Zertifikates erhalten, bleibt ein wichtiges Thema in diesem Kontext nicht adressiert: die Verbindung und die Beziehung von Identitäten untereinander. Die Beziehung zwischen Dingen untereinander (Auto und Garagentor, Temperaturfühler und Heizungsthermostat), aber auch Personen zu Maschinen (Fahrer zu Auto) müssen angemessen modelliert werden. Ist dies bei 1:1-Verbindungen noch durchaus intuitiv möglich, stellen insbesondere komplexere Relationen und deren Modellierung Technik, Security und Compliance vor neue Herausforderungen. Die komplexen Beziehungsgeflechte, die sich beispielsweise ergeben, wenn man gemeinschaftlich genutzte „Dinge“ betrachtet, müssen in Zukunft auch ihren Niederschlag in Authentifizierung- und Autorisierungskonzepten finden. Dies lässt sich gut am Beispiel eines gemeinschaftlich genutzten Autos in einer Familie oder Wohngemeinschaft illustrieren: Die unterschiedlichen Rollen und Kommunikationswege, die zwischen Auto, Fahrzeughalter, gelegentlichen Fahrern, Garagentor, Fahrzeugschlüssel, Vertragswerkstatt, Tankkarte, etc. entstehen, stellen die Themen IoT, Security, aber auch das Identity und Access Management vor neue Herausforderungen. Hier angemessenen Autorisierungskonzepte zu entwickeln, die Sicherheit, Privatsphäre und eine intuitive Nutzbarkeit gleichermaßen berücksichtigen. Und hier reichen Plattform- und Herstellerspezifische Konzepte nicht aus, vielmehr ist Interoperabilität die Grundlage für Security und Privacy als essentielle Querschnittsfunktion.