Dr. Falko Strenzke 22. Juni 2021

Hochsicheres IoT

IoT – das Internet der Dinge – erlangt zunehmend Bedeutung. Geprägt wurde der Begriff schon vor mehr als einem Jahrzehnt, doch die wirtschaftliche Entwicklung dieses Bereichs scheint derzeit immer noch deutlich an Fahrt aufzunehmen. Heute unterscheidet man die Bereiche industrielles IoT, Consumer IoT, medizinisches IoT, landwirtschaftliches IoT sowie IoT-Geräte in Smart Home und Smart Building.

Eine kryptographische Identität realisiert man in den meisten Fällen durch sogenannte Public-Key-Kryptographie. © Adobe: Yingyaipumi / stock.adobe.com / 407467484 — © Adobe: Yingyaipumi

Doch wie erreicht man IT-Sicherheit für IoT-Anwendungen? Dies ist ein komplexes Thema, denn IoT-Geräte sind vielfältigen Bedrohungen ausgesetzt und gleichzeitig oft durch verschiedene Parameter in ihren Sicherheitsleistungen eingeschränkt. Zu diesem umfassenden Themengebiet existieren bereits zahllose Veröffentlichungen und eine wachsende Zahl von kommerziellen Anbietern spezialisiert sich auf Teilbereiche davon. Wir wollen uns in diesem Beitrag auf einen wichtigen Teilbereich der IoT-Sicherheit fokussieren: Kryptographie zur Sicherung von Geräteidentitäten und als Grundlage für den sicheren Lebenszyklus von IoT Devices.

Der Aspekt von sicheren Geräteidentitäten erlangt in fast allen Anwendungsbereichen eine zentrale Bedeutung: Wenn IoT-Geräte mit Diensten kommunizieren, so sollen selbstverständlich nur authentische Geräte als solche in Erscheinung treten. Bei der Messwerterfassung in einer industriellen Anlage durch verteilte Sensoren muss beispielsweise sichergestellt sein, dass nur Signale von vom Betreiber installierten Geräte ausgewertet werden. Für akkubetriebene Geräte sollen nur authentische vom Hersteller freigegebene Akkus verwendet werden können, und keine ggf. gefährlichen Fälschungen.

Um einen sicheren Lebenszyklus von IoT-Geräten zu gewährleisten, ist es nötig, sie sowohl vor Manipulationen zu schützen als auch ein sicheres Firmwareupdate zu ermöglichen. In beiden Fällen erfordern die gängigen technischen Lösungen wiederum die Verwendung von Kryptographie.

Sichere Geräteidentitäten durch Kryptographie

Eine kryptographische Identität realisiert man in den meisten Fällen durch sogenannte Public-Key-Kryptographie. Dazu wird das Gerät mit einem geheimen Schlüssel ausgestattet, der normalerweise nirgendwo außerhalb des Geräts existiert. Zu diesem geheimen Schlüssel gibt es einen öffentlichen Schlüssel, mit Hilfe dessen beispielsweise eine digitale Signatur des geheimen Schlüssels überprüft werden kann.

Abb. 1: Darstellung von X.509-Zertifikaten. Das obere Zertifikat stellt das Ausstellerzertifikat dar, mit dessen zugeordnetem geheimen Schlüssel das untere Zertfikat – hier beispielhaft für einen Webserver – signiert wurde. "TBS-Data" bezeichnet die to-be-signed data, also die Daten des Zertifikats, welche von der digitalen Signatur geschützt werden. © Falko Strenzke

Die Zuordnung des geheimen Schlüssels zum öffentlichen Schlüssel findet über ein sogenanntes X.509-Zertifikat statt – eine Datenstruktur, welche den öffentlichen Schlüssel und eine eindeutige Referenz auf das Gerät enthält und selbst eine elektronische Signatur trägt. Letztere wird von einem im jeweiligen Kontext als bekannt vorausgesetzten Schlüssel geleistet, der somit als Vertrauensanker fungiert. Abb. 1 stellt den Zusammenhang zwischen Ausstellerzertifikat und dem ausgestellten Zertifikat graphisch dar.

Ist ein Gerät mit einem derartigen Schlüssel und Zertifikat ausgestattet, so kann es beispielsweise eine vertrauliche und authentische Verbindung zu einem TLS-Server aufbauen oder selbst als ein solcher fungieren.

Sicherer Lebenszyklus durch Kryptographie

Um den Lebenszyklus eines IoT-Geräts abzusichern, ist es in jedem Fall notwendig, sichere Firmwareupdates zu realisieren. Wird ein Softwarefehler bekannt, so muss dieser im Feld durch ein Update behoben werden können. Entsprechend der DID-Richtlinie der EU [1], welche spätestens ab 2022 rechtskräftig umgesetzt sein muss, werden Anbieter unter bestimmten Bedingungen sogar zu Softwareupdates verpflichtet. Ein Mechanismus zur sicheren Realisierung von Firmwareupdates verwendet wiederum digitale Signaturen: Diesmal ist es das IoT-Gerät, welches über einen authentischen öffentlichen Schlüssel verfügen muss, mit welchem es die Authentizität eines einzubringenden Softwareupdates anhand dessen elektronischer Signatur verifizieren kann.

Abb. 2: Schematische Darstellung des Ablaufs eines Secure-Boot Vorgangs. © MTG AG

Weitergehenden Schutz bieten sogenannte Secure-Boot-Lösungen, wie beispielsweise das sehr verbreitete HABv4 von NXP [2]. In einer solchen Lösung wird ein öffentlicher Schlüssel manipulationssicher in der Hardware des Geräts hinterlegt. Wenn das Gerät gestartet wird, wird die Signatur der initial ausgeführten Software, des sogenannten Bootloaders, mit Hilfe dieses Schlüssels verifiziert. Alle weiteren Schritte zum vollständigen Laden des Betriebssystems und der Applikationen können auf die selbe Weise abgesichert werden. Abb. 2 zeigt den schematischen Ablauf dieses Vorgangs. Somit kann ein System realisiert werden, welches – vorausgesetzt die zugrundeliegende Hardware bietet einen ausreichenden Schutz – nicht dauerhaft manipuliert werden kann.

Spätestens nach einem Neustart wäre Malware, welche durch Softwaresicherheitslücken in das Gerät eingebracht wurde, wieder verschwunden. Dies bietet wiederum einen geeigneten Ausgangspunkt für Softwareupdates: zum einen kann ein sicherer Betriebszustand beim Einspielen des Updates gewährleistet werden, zum anderen kann der Mechanismus für den Secure-Boot-Vorgang direkt für die Verifikation von Updates verwendet werden, da in beiden Fällen digital signierte Software zum Einsatz kommt.

Sichere Implementierung von Kryptographie in IoT-Geräten

Beim Einsatz von Kryptographie ist die sichere Handhabung der Schlüssel der entscheidende Faktor. So müssen die privaten Schlüssel über deren gesamten Lebenszyklus sicher gehandhabt werden. Dies bedeutet die sichere Erzeugung, die sichere Speicherung, die kein Auslesen erlaubt, sowie die Absicherung des Zugriffs auf die Schlüssel, wenn diese beispielsweise für die Erstellung von Signaturen verwendet werden sollen. Bei den öffentlichen Schlüsseln, die dem Gerät als Vertrauensanker dienen, ist es dagegen wichtig, dass diese manipulationssicher gespeichert werden.

Dementsprechend ist es empfehlenswert, ausreichend abgesicherte Hardwarebausteine in dem IoT-Gerät zu verwenden. Entsprechende Bausteine sind auf dem Markt unter unterschiedlichen Bezeichnungen erhältlich, wie "Hardware Security Module", "Security Controller" oder "Crypto Chip". Dabei können grob folgende verschiedene Klassen unterschieden werden: Die mit dem geringsten Funktionsumfang bieten einfache serielle Schnittstellen zum Übermitteln von Befehlen für kryptographische Operationen. Sie kommen z. B. häufig dann zum Einsatz, wenn ein Gerät mittels kryptographischer Funktionen seine "Echtheit" beweisen soll. Dann gibt es Controller mit größerem Umfang und komplexeren Interfaces, welche z. B. den gleichen Funktionsumfang bieten können wie ein Smartcard-Security-Controller, d. h. wo sich nicht nur Schlüssel sondern auch diverse andere Datenobjekte sicher speichern lassen. Ferner gibt es die frei programmierbaren Security Controller, welche die größte Flexibilität bieten, aber auch den größten Entwicklungsaufwand erfordern. Im Falle der oben erwähnten Secure-Boot-Lösung von NXP ist die Sicherheitsfunktionalität bereits in den Application-Prozessor integriert – ein großer Vorteil, da in diesem Fall eine Kommunikation mit einem externen Baustein über die Platine, welche einen Angriffspunkt darstellt, entfällt.

Aufgrund des typischen Nutzungsszenerios von IoT-Geräten muss in vielen Fällen davon ausgegangen werden, dass ein Angreifer Geräte unter seine Kontrolle bringen und physikalische Angriffe gegen das Gerät fahren kann. Dazu zählen vor allem die sogenannten Seitenkanal- und Fault-Injection-Angriffe. Die typischste Variante von Seitenkanalangriffen ist die Power-Analysis-Attacke, bei der der Angreifer durch Messen der Stromaufnahme eines Geräts bzw. Bausteins während der Ausführung einer kryptographischen Operation Rückschlüsse auf den geheimen Schlüssel ziehen kann. Bei Fault-Injection-Angriffen werden die Sicherheitsbausteine durch physikalische Einwirkung, z. B. durch elektromagnetische Pulse oder Laser-Beschuss dazu gebracht, geheime Daten auszugeben.

Wichtig für die Bewertung der Sicherheit eines Sicherheitsbausteins gegenüber physikalischen Angriffen ist die Sicherheitszertifizierung, welche dieser durchlaufen hat. Dies sollte mindestens eine Zertifizierung entsprechend FIPS-140-2 [3], einem US-amerikanischen Standard sein. Als deutlich aussagekräftiger werden im Allgemeinen allerdings Zertifizierungen nach dem Common Criteria Standard [4] angesehen. Bei Common Criteria gibt es die sogenannten Evaluation Assurance Levels (EAL) 1 bis 7, die aufsteigend mit wachsenden Sicherheitsanforderungen an die geprüfte Implementierung geordnet sind. Sicherheitscontroller für typische Anwendungsbereiche rangieren häufig im mittleren Bereich EAL 3 bis 4.

Wir wollen in diesem Zusammenhang kurz einen Blick auf ein Beispiel für hochsicheres IoT werfen, nämlich das Smart Metering in Deutschland. Smart Meter Gateways, welche bei den Verbrauchern als Zugangsknoten zu dem internen Netzwerk für die Messeinheiten sowie ggf. zusätzlichen Mehrwertanwendungen fungieren, müssen mit EAL 4+ nach Common Criteria evaluiert sein (EAL 4+ bedeutet etwas erhöhte Sicherheitsanforderungen gegenüber EAL 4). Damit zählt ein Smart Meter Gateway nach den in Deutschland geltenden Regelungen zu den IoT-Geräten mit den höchsten Sicherheitsanforderungen, mindestens im zivilen Bereich. Um die sichere Speicherung der Schlüssel zu gewährleisten, die für die Authentisierung eingesetzt werden, ist gefordert, dass im Smart Meter Gateway ein Hardware-Security-Modul verbaut sein muss, welches ebenfalls mindestens EAL 4+ erfüllt [5].

Allerdings wird es aus Kostengründen nicht in allen Anwendungen möglich sein, dedizierte kryptographische Hardware in den IoT-Geräten einzusetzen. In diesem Fall ist auch die Erzeugung von Schlüsseln auf den Geräten aufgrund der beschränkten Ressourcen oft nicht möglich. Auch bei kostengünstigen Sicherheitsbausteinen ist in manchen Fällen die Schlüsselerzeugung zu zeitaufwändig, um während der Produktion durchgeführt zu werden. In solchen Fällen müssen anderen Lösungen realisiert werden. Ein sogenanntes Key Management System (KMS) kann in diesem Fall die Schlüsselerzeugung übernehmen.

Ferner gibt es Fälle, in denen die IoT-Geräte aus Kostengründen nur über sehr geringe Hardwareressourcen verfügen und auch nicht mit Sicherheitsbausteinen ausgestattet werden können. In diesen Fällen muss man häufig auf die oben eingeführte Public-Key-Kryptographie verzichten und zur sogenannten symmetrischen Kryptographie greifen. Bei solchen Verfahren verfügen beide Seiten über die gleichen geheimen Schlüssel. Somit muss hier auch das Gerät den geheimen Schlüssel dauerhaft und sicher speichern. Auch in solchen Fällen kommt ein KMS zum Einsatz: Wenn die kryptographisch abgesicherte Kommunikation mit dem Gerät aufgebaut werden soll, kann die serverseitige Anwendung über das KMS die entsprechenden Schlüssel verwenden. Das KMS gibt dabei die Schlüssel nicht heraus, sondern übernimmt die Durchführung der kryptographischen Operation. Idealerweise speichert das KMS die Schlüssel auf einem Hardware Security Module, einem HSM. Auch wenn dies der gleiche Begriff ist, der oben bereits im Zusammenhang mit IoT-Geräten verwendet wurde, ist an dieser Stelle mit HSM ein wesentlich leistungsfähigeres Gerät gemeint, welches in IT-Infrastrukturen häufig zum Einsatz kommt, wenn es um die sichere Speicherung von kryptographischen Schlüsseln geht.

Auch hier wollen wir einen kurzen Blick auf das hochsichere IoT des Smart Metering in Deutschland werfen. Die Verwendung von HSMs zu Speicherung der Schlüssel, die zum Zugriff von Anwendungen auf das Smart Meter Gateway verwendet werden, ist dort ebenfalls vorgeschrieben.

Vermeidung von "Hack one – break all'"

Die oben skizzierten Ansätze für den Einsatz von Kryptographie zur Absicherung von IoT-Geräten zeigen Best Practices auf. Allerdings wird es in vielen Fällen Sonderlösungen geben müssen. Der Grund ist, dass jedes entwickelte IoT-Gerät anderen Anforderungen unterliegt. Wie oben bereits angeführt, müssen in manchen Fällen die Stückkosten gering gehalten werden, um die Produkte konkurrenzfähig zu halten. In diesen Fällen wird man manchmal zu Lösungen greifen müssen, die nicht alle wünschenswerten Sicherheitsanforderungen erfüllen.

In allen Fällen sollte jedoch das Gesamtsystem, in welchem das IoT-Gerät eingesetzt wird, einen wirksamen Schutz gegen das schlimmste anzunehmende Szenario bieten, welches man kurz mit "Hack one – break all" beschreiben kann. Dieses Szenario bedeutet, dass ein Angreifer durch das Brechen der Sicherheitsmechanismen eines einzigen Geräts das gesamte System brechen kann. Dies wäre etwa der Fall, wenn auf allen Geräten der gleiche kryptographische Schlüssel eingesetzt wird, und es dem Angreifer gelingt, diesen zu extrahieren. Dann wäre es nicht mehr möglich, auf Basis der kryptographisch abgesicherten Authentisierung authentische Geräte von falschen Geräten zu unterscheiden.

Daher ist es unbedingt notwendig, dieses Szenario abzuwehren. Die wichtigste Voraussetzung ist dabei, unterschiedliche Schlüssel auf allen Geräten zu haben. Somit können als "gebrochen" erkannte Schlüssel im System gesperrt werden. Selbst bei Schutz der geheimen Schlüssel durch als sicher eingestufte Sicherheitsbausteine kann eine solche Maßnahme notwendig werden: Eine vollständige Hardwaresicherheit kann nie garantiert werden. Mit entsprechend hohem Aufwand durch den Angreifer können auch bei als sicher geltenden Bausteinen physikalische Angriffe erfolgreich sein. Unbekannte Sicherheitslücken in der Software der Controller können unter Umständen noch einfachere Angriffswege ermöglichen.

Sicherheit in der Entwicklung

Ein weiterer wichtiger Aspekt bei der Entwicklung von IoT-Geräten ist ein Konzept zur Vermeidung von sicherheitskritischen Softwarefehlern. Fehler im Zusammenhang mit der primären Funktion eines Produktes werden in Qualitätssicherungstests häufig gefunden. Sicherheitsschwachstellen verhalten sich dagegen sehr oft "still": Das Gerät funktioniert auch mit Schwachstellen gut. Ohne entsprechendes Spezialwissen über die eingesetzten Technologien wird es z. B. den Testern meist schwerfallen, überhaupt geeignete Tests zu konzipieren, um Sicherheitsschwachstellen zu finden. Daher sind bei der Entwicklung von Produkten, bei denen ein nennenswertes Sicherheitsniveau angestrebt wird, immer spezielle Maßnahmen nötig, um das nötige Vertrauen in dessen IT-Sicherheitseigenschaften zu schaffen. Das gilt auch, wenn nicht "Hochsicherheit" angestrebt wird, sondern ggf. nur ein Mindestmaß an Sicherheitseigenschaften.

Tatsächlich basieren viele der IoT-Schwachstellen, über die man in den Medien in den letzten Jahren lesen konnte, nicht auf subtilen Fehlern, sondern auf groben: Default-Passworte, mit deren Kenntnis man auf jedes Gerät ungehindert zugreifen kann oder geheime Schlüssel, die in der Firmware ungeschützt und auf allen Geräten gleich sind und noch dazu eine Kompromittierung der Geräte ermöglichen. Das sind grobe Verletzungen der Regeln, wie wir sie oben aufgestellt haben. Diese Tatsache führt uns vor Augen, was so oft beklagt wird: in der IoT-Entwicklung werden heutzutage auch die niedrigsten Sicherheitsstandards unterlaufen. Daraus müssen wir folgern, dass ein Mindestmaß an Sicherheitsmaßnahmen in der Entwicklung in jedem Fall unabdingbar ist. Wird gar ein hohes Sicherheitsniveau angestrebt, so müssen alle relevanten Sicherheitsaspekte im Rahmen des Entwicklungsprozesses berücksichtigt werden. Im Folgenden wollen wir eine Möglichkeit für einen solchen sicheren Entwicklungsprozess aufzeigen.

Um ein sicheres Produkt zu erreichen, genügt es nicht, das fertige Produkt einem Penetration-Test durch eine Sicherheitsfirma überprüfen zu lassen. Genausowenig wie bei anderen Produkteigenschaften lässt sich die Qualität der Sicherheitseigenschaften rein durch Testen sicherstellen. Sicherheitsaspekte müssen von Anfang an in dem Entwicklungsprozess berücksichtigt werden. Dazu müssen zunächst die Sicherheitsanforderungen an das Produkt definiert werden.

Zu diesem Zweck sollten im ersten Schritt die schützenswerten "Assets", mit welchen das Produkt arbeitet, definiert werden. Im Falle des IoT werden dies in vielen Fällen Daten sein. Dabei werden typischerweise data-at-rest (langfristige gespeicherte Daten), data-in-transit (also übertragene Daten) und data-in-use (gerade von der Anwendung verarbeitete Daten) unterschieden. Im nächsten Schritt werden die Bedrohungen definiert, welche diese Assets gefährden. Dabei bietet es sich an, die Sicherheitsziele Confidentiality (Vertraulichkeit bzw. Geheimhaltung), Integrity (Integrität bzw. Authentizität) und Availability (Verfügbarkeit) zusammenfassend abgekürzt als CIA, zu berücksichtigen. Zur Erreichung dieser Ziele werden dann die Sicherheitsanforderungen, d. h. die Anforderungen an die Sicherheitsmechanismen des Produktes abgeleitet.

Wenn man als Hersteller einen sicheren Entwicklungsprozess für die eigenen Produkte etablieren möchte, so kann man maßgebliche existierende Rahmenwerke als Grundlage heranziehen, wie beispielsweise den BSI-Grundschutz [6], Common Criteria [4] oder Microsoft SDL [7].

Die im vorigen Schritt festgesetzten Sicherheitsanforderungen müssen anschließend im Entwicklungsprozess umgesetzt werden. Das beginnt bei der Auswahl der passenden Hardwareplattform, des physischen Designs des Produktes, der Auswahl von Hardware-Sicherheitsbausteinen, eines geeigneten Betriebssystems und geeigneter Software-Bibliotheken. Ferner umfasst dies Regeln für die Erstellung von sicherem Quellcode und einen definierten Quellcode-Reviewprozess für sicherheitsrelevante Funktionen, bis hin zur Implementierung von dedizierten Sicherheitstests, welche die Sicherheitsanforderungen abdecken.

Zu dem Thema der Hardwaresicherheit haben wir weiter oben bereits einige wichtige Punkte diskutiert. Sichere Hardware wird vor allem benötigt, um die Geräte gegen unbefugtes Auslesen oder Manipulation durch einen Angreifer mit direktem physischen Zugriff auf das Gerät zu schützen. Softwaresicherheit ist dagegen oft noch wichtiger, denn Softwarefehler können auch aus der Ferne ausgenutzt werden. Zudem kann ein Hardwareangriff immer nur auf ein konkretes Gerät durchgeführt werden, mit dem entsprechenden Aufwand und dem physischen Zugriff als Voraussetzung. Angriffe unter Ausnutzung von Softwareschwachstellen können dagegen typischerweise auch automatisiert gegen eine beliebig große Zahl an Geräten durchgeführt werden, sofern diese vernetzt sind. Im Falle des IoT ist dies aber grundsätzlich immer der Fall.

Was die Auswahl von Betriebssystem und Bibliotheken angeht, so ist es wichtig sicherzustellen, dass für alle Fremdkomponenten ein angemessenes Vertrauen in die Sicherheitsleistungen gegeben ist und dass man mit ausreichender Wahrscheinlichkeit davon ausgehen kann, dass diese über die Lebensdauer des Produktes mit Sicherheitsupdates versorgt werden. Der Quellcode für Gerätetreiber, der vom Hardwarehersteller bereitgestellt wird, erfüllt diese Anforderungen z. B. nicht immer. Grundsätzlich gilt, dass die Tatsache, ob es sich um freie, kommerzielle oder Software handelt, noch nicht direkt etwas darüber aussagt, wie viel Vertrauen man in die Sicherheitseigenschaften setzten kann. Diese Abschätzung muss immer in einer individuellen Gesamtbetrachtung erfolgen.

Für die Entwicklung im IoT kommt bei stark ressourcenbeschränkten Geräten häufig die Programmiersprache C zum Einsatz. Implementierungen in C sind für ihre Fehleranfälligkeit gegenüber klassischen Schwachstellen wie Pufferüberläufen und anderen Speicherzugriffsfehlern bekannt. Eine große Zahl von IoT-Schwachstellen resultiert aus solchen Programmierfehlern. In jedem Fall müssen, um eine sichere Softwareentwicklung zu gewährleisten, Vorgaben und Richtlinien für die Entwickler existieren, welche die bekannten Sicherheitsschwachstellen, wie sie beispielsweise in den OWASP Top 10 [8] oder den SANS Top 25 [9] aufgeführt sind, wirksam verhindern.

Sicherheitstests sind ein weiterer wichtiger Faktor für die Sicherheit des Produktes. Dabei ist es wie oben erwähnt nicht ratsam, diesen Aspekt vollständig auf Sicherheitsdienstleister auszulagern. Sicherheitstests müssen umfassend sein, und wie Tests für andere Qualitätsaspekte des Produktes müssen sie mit dem Produkt mitwachsen und idealerweise automatisiert durchgeführt werden. Eine wichtiger Testansatz, vor allem wenn "native" Entwicklung in Programmiersprachen wie C und C++ erfolgt, ist dabei das sogenannte Fuzz-Testing. Bei dieser Art des Testens werden im großen Maßstab automatisiert zufällig modifizierte Eingabedaten erzeugt und dem Gerät über eine seiner Schnittstellen, z. B. eine Netzwerkschnittstelle, zugeführt. Gute Fuzz-Testing-Tools nutzen dabei Algorithmen, welche weitaus bessere Erfolgsaussichten haben, Programmfehler zu finden als durch rein zufällige Testdatenmodifikation, wie beispielsweise das Tool American Fuzzy Lop [10]. Große Softwarehersteller setzen heutzutage stark auf Fuzz-Testing. Google bietet mit OSS-Fuzz basierend auf den Erfahrungen in der internen Entwicklung ein Programm für das Fuzz-Testing von Open-Source-Implementierungen [11].

Ein Blick in die Zukunft

Keine Frage, IoT-Security ist eine umfangreiches Thema und stellt hohe Anforderungen an Hersteller. Dem Preisdruck auf der einen Seite stehen auf der anderen Seite für die Zukunft zu erwartende verschärfte Haftungsregeln gegenüber, wie beispielsweise durch die oben erwähnte DID-Richtlinie der EU. Produkte, welche in kritischen Infrastrukturen Funktionen übernehmen, unterliegen ohnehin bereits gesetzlichen Regelungen. Bei der Produktentwicklung muss das richtige Maß an Sicherheitsmaßnahmen getroffen werden – und dieses muss den sich stetig weiterentwickelnden Anforderungen angepasst werden.

Doch es zeichnen sich noch weitreichendere Veränderungen ab, die praktisch alle IT-Produkte betreffen. Das Schlagwort ist Quantencomputer. Dabei handelt es sich um eine neuartige Art von Computern, welche nach den Gesetzen der Quantenmechanik arbeitet und für manche Berechnungsprobleme deutlich effizienter arbeiten kann. Speziell ist klassische Public-Key-Kryptographie, von der oben die Rede war, davon betroffen: Sobald ausreichend leistungsfähige Quantencomputer verfügbar sind, sind sämtliche heute eingesetzten Public-Key-Verfahren unsicher. Wann und ob dies überhaupt geschieht, kann heute wohl niemand sicher prophezeien. Allerdings werden bereits Fakten geschaffen: Die US-Amerikanische Standardisierungsbehörde NIST hat 2016 ein Auswahlverfahren für zukünftige kryptographische Verfahren gestartet [12], welches nach dem Vorliegen der endgültigen Ergebnisse zwischen 2022 und 2024 in Standardisierungen der ausgewählten kryptographischen Algorithmen münden soll. Das Bundesamt für Sicherheit in der Informationstechnik gibt bereits konkrete vorläufige Empfehlungen für Post-Quantum-Algorithmen[13], wie die gegenüber Quantencomputern sicheren Verfahren bezeichnet werden. Einige Forschungsprojekte befassen sich heute schon mit effizienten Implementierungen für ressourcenbeschränkte Plattformen [14]. Hersteller von langlebigen Produkten sollten sich also bereits heute mit den Alternativen zu den derzeit gängigen kryptographischen Verfahren auseinandersetzen.

Fazit

IoT-Security ist zweifellos ein herausforderndes Thema. Die große Diversität an Produkten macht Pauschallösungen, wie sie für Server und PCs schon lange etabliert sind, nicht flächendeckend möglich. Wer sich dieser Herausforderung ernsthaft stellen möchte, braucht ein solides Konzept, welches es ihm ermöglicht, für jedes neu entwickelte Produkt das richtige Maß und die richtigen Methoden zur Erreichung des passenden Sicherheitsniveaus zu finden. Einfach den Anspruch zu stellen, ab jetzt sichere Produkte zu entwickeln, wird das Ziel verfehlen, da immer Abwägungen zwischen Kosten und Sicherheit getroffen werden müssen. Allerdings sollten diese bewusst getroffen werden und nicht dem Zufall überlassen werden.

Quellen