IoT-Security Verdeckte Kosten bei der Absicherung vernetzter Systeme verstehen

Autor / Redakteur: Brent Wilson* / Sebastian Human

Die Sicherheit der Datenübertragung im Internet of Things ist ein wichtiger Punkt – gerade auch im industriellen Einsatz entsprechender Technologie. Doch eine wirksame Verschlüsselung kostet Energie und somit bares Geld, oder?

Firmen zum Thema

Sicherheit ist auch im Internet of Things nicht kostenlos, Versäumnisse in diesem Bereich können jedoch schnell wirklich teuer werden.
Sicherheit ist auch im Internet of Things nicht kostenlos, Versäumnisse in diesem Bereich können jedoch schnell wirklich teuer werden.
(Bild: gemeinfrei / Pixabay )

IoT-Security entwickelt sich stetig weiter. Denn viele vernetzte Produkte am Markt oder im Feld sind entweder nicht sicher oder verfügen nicht über ein robustes Sicherheitsniveau.1 Systementwickler müssen diese Produkte möglicherweise aufrüsten, um Endnutzer oder die Unternehmensmarke zu schützen.

Die Kosten für mehr Sicherheit können verschiedene Formen annehmen: Forschung und Entwicklung, Stückliste, Logistik, Opportunitätskosten und weitere. Dieser Beitrag konzentriert sich speziell auf die Energiekosten bei der Verschlüsselung (kryptografische Berechnungen), die sich auf die Batterielebensdauer eines vernetzten Knotens im Sleep-Modus auswirken können, zum Beispiel bei einem funkbasierten Umgebungs- oder Fenstersensor, einem kostengünstigen tragbaren Gerät oder einem vernetzten Spielzeug.

Aufbau eines sicheren IoT-Produkts

Eine Herausforderung bei der Sicherheit im IoT ist das Fehlen einheitlicher Standards. Obwohl jeder Standard seine eigenen Auslegungen hat, schreiben die meisten vor, die Privatsphäre und die sensiblen Daten der Endnutzer zu schützen. Dabei wird verlangt, dass diese Daten während der Übertragung oder im gespeicherten Zustand verschlüsselt sind.2 Darüber hinaus müssen Systeme vor einer böswilligen Installation schadhafter Firmware geschützt werden, indem man Firmware-Upgrades und Boot-Prozesse absichert.

Aus der Sicht der Hardware unterstützt und verbessert ein MCU (Micro-Controller Unit) oder ein Funk-SoC-Baustein (System on a Chip) die Sicherheitsanforderungen, indem Hardware-basierte Verschlüsselung sowie zusätzlicher Flash- oder anderer nichtflüchtiger Code-Speicher und RAM bereitgestellt werden, um Kryptografie-Treiber und die Betriebsanforderungen zu unterstützen.

Es gibt viele Klassen von IoT-Produkten. Am empfindlichsten in Bezug auf den Stromverbrauch sind funkbasierte SoCs mit einer MCU und Knopfzellenbatterie. Daher beschränkt sich unsere Analyse auf eine typische Anwendung für Systeme dieser Art. Um den Energieverbrauch der Verschlüsselungsfunktionen in einem vertrauten Kontext zu veranschaulichen, wird hier der Betrieb eines batteriebetriebenen Umgebungstemperatursensors, der mit Bluetooth Low Energy (BLE) betrieben wird, beschrieben. Die Auswirkungen und Schlussfolgerungen erstrecken sich dabei auf die überwiegende Mehrheit der kostengünstigen, batteriebetriebenen IoT-Edge-Systeme.

Authentifizierte Verschlüsselung

Um eine Kommunikationsverbindung abzusichern, müssen sich beide Seiten gegenseitig authentifizieren, einen oder mehrere Kryptografie-Schlüssel austauschen und einrichten und dann die Daten vor der Übertragung verschlüsseln. Im Fall von BLE erfordert der Authentifizierungsschritt häufig eine Benutzeraktion und erfolgt während der Kopplung (Pairing) durch Eingabe eines Passkeys.

Bei stromsparenden, sicheren Verbindungen wird der AES-Kryptografie-Schlüssel über Public-Key-Verschlüsselung abgeleitet, das heißt über elliptische Kurven des Diffie-Hellman-Schlüsseltauschs (ECDH). Bei dem unter BLE verwendeten Verschlüsselungsprotokoll handelt es sich um AES-CCM, das eine Verschlüsselung zum Schutz der vertraulichen Daten sowie ein kryptografisches Nachrichten-Tag bietet, was die Integrität und Authentizität der Daten schützt. AES-CCM wird in vielen stromsparenden, standardbasierten Funkprotokollen verwendet, unter anderem für Bluetooth, ZigBee, Thread, Z-Wave.

(Bild: Silicon Labs)

Die meisten Funk-SoCs unterstützen eine gewisse AES-Beschleunigung hardwareseitig. Die Leistungsfähigkeit dieser Hardware kann von Implementierung zu Implementierung erheblich variieren, aber selbst eine einfache Hardware-Implementierung ist einem reinen Software-Ansatz weit überlegen. Unter den Hardwarelösungen können größere Engines den Blockverschlüsselungsbetrieb in weniger Zyklen berechnen – bei höherem Stromverbrauch pro Zyklus in der Beschleuniger-Hardware. Von den beiden Messgrößen (Energiekosten pro Zyklus und Gesamtzahl der Zyklen) hat die Gesamtzahl der Zyklen tendenziell den größten Einfluss auf die gesamte Batterielebensdauer, da sie die Dauer beeinflusst, in der das System aktiv bleiben muss, anstatt in den Sleep-Modus überzugehen. Der Hardware-Beschleuniger selbst trägt nur selten wesentlich zum Gesamtstromverbrauch des Systems bei.

(Bild: Silicon Labs)

Die meisten funkbasierten MCUs für BLE arbeiten im Bereich von 24 bis 96 MHz. Der Einfachheit halber nehmen wir eine CPU-Betriebsfrequenz von 40 MHz und eine Wirkleistung von 10 mW während der Verschlüsselung an (nur CPU, keine Funk-Funktionen aktiviert). Wir gehen auch davon aus, dass die Stromquelle eine CR2032-Lithium-Ionen-Knopfzelle ist, die eine kleine Größe, günstige Energiedichte und geringe Kosten bietet sowie häufig in Consumer-Geräten zum Einsatz kommt. Wir streben eine Batterielebensdauer von fünf Jahren an. Tabelle 1 führt die wesentlichen Systemeigenschaften auf. Tabelle 2 beschreibt die durchschnittliche Batteriekapazität über verschiedene Zeitintervalle.

Zum Vergleich bewerten wir die Leistungsfähigkeit dreier verschiedener Implementierungen: Nur-Software, bei der die Verschlüsselung ausschließlich über die CPU ohne Hardwarebeschleunigung umgesetzt wird; Hardware A, die eine typische Verschlüsselungsfunktion von MCUs darstellt, die vor etwa fünf Jahren (2015) eingeführt wurden; und Hardware B, die eine modernere (2019) Verschlüsselung mit höherer Leistungsfähigkeit gewährleistet.

In allen drei Fällen werden Cortex-M4-CPUs verwendet, die mit einer Taktrate von 40 MHz arbeiten und 10 mW verbrauchen, während der Funkbetrieb deaktiviert ist. Als Maß dient die Anzahl der CPU-Zyklen, die für die AES-CCM-Verschlüsselung eines 1024-Byte-Klartextpuffers erforderlich sind. Zu beachten ist, dass Ver- und Entschlüsselungsvorgänge häufig ein Setup erfordern, um entweder den Verschlüsselungsbeschleuniger zu initialisieren, eine DMA-Transaktion einzurichten oder die AES-Rundungsschlüssel vorzubereiten. In diesem Beispiel wird das Einrichten über viele Blockverschlüsselungsoperationen ausgeglichen (64 Operationen in diesem Beispiel). In einigen Anwendungen muss dieser Setup-Vorgang für jede Transaktion ausgeführt werden, was zu einem höheren Energieverbrauch führt als hier gezeigt. Tabelle 3 führt den Vergleich auf.

(Bild: Silicon Labs)

Die Daten zeigen, dass selbst für die Software-Implementierung die zur Verschlüsselung der Daten mit AES-CCM erforderliche Energie (1,25 µJ) im Vergleich zu der für die Übertragung der Daten erforderlichen Energie (250 µJ) vernachlässigbar ist. Daher hat die Verschlüsselung keinen bedeutenden Einfluss auf die Batterielebensdauer.

Im Beispiel des BLE-Temperatursensors ist die Redundanz bei der Funkübertragung sehr hoch. Jeder Temperaturmesswert wird 30 Mal übertragen (jeweils 10 Mal auf drei verschiedenen Funkkanälen). Was passiert, wenn wir diese Redundanz entfernen und stattdessen jedes Bit nur einmal übertragen?

Das Übertragen von 32 Bit mit 1 MHz dauert 32 µs. Ist der Funksender aktiv, beträgt die Leistungsaufnahme des Systems etwa 30 mW (10 mW für die CPU plus zusätzliche 20 mW für die Funkübertragung bei 0 dBm). Dies führt zu einem Energieverbrauch von 96 µJ, was 7,7-mal mehr ist als bei einer Software-Implementierung der 32-Byte-Verschlüsselung (1,25 µJ). Die hardwarebeschleunigten Fälle haben noch weniger Auswirkungen auf den Energieverbrauch. Obwohl die Verschlüsselung der Daten einen bedeutenderen Energieverbrauch darstellt als im Fall von BLE, ist sie im Vergleich zu der Energie, die für den Transport der Daten über die Funk-Schnittstelle erforderlich ist, immer noch gering.

Schlüsselableitung

AES nutzt Kryptografie mit symmetrischen Schlüsseln. Dies bedeutet, dass der zum Entschlüsseln der Daten verwendete Schlüssel derselbe ist wie der zur Verschlüsselung der Daten verwendete. Das sichere Transportieren des Kryptografie-Schlüssels zum entfernten Knoten während der Phase des Schlüsselaustauschs beziehungsweise der Schlüsselvereinbarung stellt eine Herausforderung dar, wenn das Kommunikationsmedium nicht vertrauenswürdig ist, wie dies bei der Funkkommunikation der Fall ist.

Diffie-Hellman ist ein Schlüsselaustauschalgorithmus, der Kryptografie mit Public Keys verwendet, um sicher einen gemeinsamen AES-Kryptografie-Schlüssel zwischen zwei kommunizierenden Parteien zu erzeugen. Beim klassischen Diffie-Hellman teilt jeder Teilnehmer einen Public-Key mit der anderen Partei und jede Seite leitet den AES-Schlüssel unter Verwendung des empfangenen Public-Key in Verbindung mit ihrem eigenen privaten Schlüssel ab. Public-Keys unterliegen keinen Vertraulichkeitsanforderungen, das bedeutet, ein Hacker, der die ausgetauschten Public-Keys in einem Diffie-Hellman-Schlüsselaustausch erfasst, kann praktisch nicht darauf hoffen, den symmetrischen AES-Schlüssel abzuleiten, ohne auch Zugriff auf einen der zugeordneten privaten Schlüssel beider Parteien zu haben.

(Bild: Silicon Labs)

Implementierungen mit Public-Keys auf MCU-basierten Systemen verwenden aufgrund kleiner Schlüsselgrößen und Recheneffizienz häufig Techniken mit elliptischen Kurven. Die Diffie-Hellman-Variante, die elliptische Kurven verwendet, wird als ECDH bezeichnet. Die in Diffie-Hellman verwendeten Public-Keys können fest sein oder bei Bedarf jedes Mal, wenn sie benötigt werden, nach dem Zufallsprinzip erzeugt werden. Im On-Demand-Fall wird der Public-Key als kurzlebig bezeichnet, und Operationen, die diese Variante verwenden, werden mit einem nachgestellten „E“ gekennzeichnet, also ECDHE.

Die Ableitung des ECDHE-Schlüssels umfasst zwei Operationen: das Erzeugen eines Public-Key, der ein zufälliger Punkt auf der elliptischen Kurve ist, und die Berechnung des gemeinsamen Geheimnisses, mit dem der AES-Kryptografie-Schlüssel abgeleitet wird. Beide Operationen sind rechenintensiv.

Die Ableitung des Schlüssels erfolgt normalerweise, wenn eine Verbindung zum ersten Mal aufgebaut wird und hält für die Dauer der Verbindung an. Es handelt sich in der Regel um eine viel seltenere Operation als die Verschlüsselung.
In unserem Beispiel eines BLE-Temperatursensors erfolgt die Schlüsselableitung nur einmal pro Tag – wenn der Temperatursensor eine Verbindung zu einem Smartphone herstellt, um alle gespeicherten Temperaturprotokolle seit der letzten Smartphone-Verbindung hochzuladen. Obwohl die Berechnung pro Ereignis sehr aufwändig ist, ist die Häufigkeit von Ereignissen recht gering, sodass die Auswirkungen auf die Batterielebensdauer vernachlässigbar sind.

Tabelle 4 zeigt auf, dass ECDHE-Operationen leicht in Millionen von CPU-Zyklen ausgedrückt werden – selbst für die hardwarebeschleunigten Fälle. In diesem Beispiel kommt die NIST-Primkurve P-256 zum Einsatz, die in EDCHE gemäß der Bluetooth-Spezifikation3 verwendet wird und hinsichtlich der Sicherheitsstärke mit AES-1284 gut übereinstimmt.

Der Energieverbrauch der Software-Implementierung beträgt 15,9 mJ und ist damit etwa 15.000 Mal höher als die im vorigen Abschnitt besprochene 32-Byte-Verschlüsselung. Der ECDHE-Energieverbrauch ist jedoch im Vergleich zur durchschnittlichen Tageskapazität von 1100 mJ (etwa 1,4 % der täglichen Gesamtkapazität) immer noch gering. Dies bedeutet, dass das Hinzufügen einer ECDHE-Software-Implementierung mit einer durchschnittlichen Häufigkeit von einmal pro Tag die Batterielebensdauer über einen Zeitraum von fünf Jahren um 1-2 % oder etwa einen Monat verkürzt. Die Hardware-Implementierungen führen zu einer unbedeutenden Verkürzung der Batterielebensdauer (0,5 bis 1,5 Tage über denselben 5-Jahres-Zeitraum).

Auch wenn die Energiebeiträge zu vernachlässigen sind, kann die für den ECDHE-Betrieb erforderliche Zeit beträchtlich sein – insbesondere im Fall der Software.

Die Software-Implementierung benötigt in etwa 1,6 s, was im menschlichen Wahrnehmungsbereich liegt und lang genug ist, um ein Ärgernis für den Nutzer darzustellen. Die Hardware-Implementierungen für ECDHE sind mit 83 und 19 ms eventuell wahrnehmbar, dürften aber kein Problem darstellen.

Firmware-Updates und Boot-Prozess absichern

Sichere Firmware-Updates verwenden Verschlüsselungstools, um die Authentizität und Integrität eines Firmware-Pakets zu überprüfen, bevor die Installation des Updates zugelassen wird.

Sicheres Booten verwendet ähnliche Techniken, um die Authentizität und Integrität der Firmware-Binärdatei im Flash nach einem Reset zu überprüfen, bevor die Ausführung der Firmware zugelassen wird. Sichere Firmware-Updates und sichere Boot-Vorgänge sind in der Regel selten: Erstere können einmal pro Monat bis alle zwei Jahre auftreten; letztere meist nach der Installation von Firmware-Updates oder nach dem Austausch der Batterie. Dies kann jedoch häufiger in Systemen auftreten, die Resets anstelle von Wake-Ereignissen verwenden, um das Gerät aus dem Ruhezustand in den aktiven Zustand zu versetzen.

Starke, sichere Firmware-Updates und sichere Boot-Implementierungen verwenden Verschlüsselungsalgorithmen mit Public-Keys wie ECDSA (Elliptic Curve Digital Signature Algorithm).5 Es gibt auch weniger aufwändige Abläufe, die symmetrische Verschlüsselung auf Basis von AES verwenden. Diese sind jedoch entweder sehr komplex, da jede Produktinstanz einen eindeutigen Signaturprüfschlüssel erhält, oder aus Sicherheitssicht schwach, wenn jedes Produkt denselben Signaturprüfschlüssel erhält. Wird ein einzelnes Produkt gehackt, sind alle Produkte gefährdet und kompromittiert.6
Methoden mit öffentlichen Schlüsseln wie ECDSA ermöglichen die Installation desselben Public-Signaturprüfschlüssels auf allen Produkten. Selbst wenn ein Produkt kompromittiert wird, bleibt dann der Rest der Geräte geschützt.

Mit sicheren Firmware-Updates und sicherem Booten sind zwei Verschlüsselungsvorgänge verbunden: eine kryptografische Hash-Berechnung und eine Überprüfung der digitalen Signatur. Der kryptografische Hash wird über das Image berechnet, was zu einem Wert führt, der als Digest bezeichnet wird. Der Digest-Wert wird mit dem auf dem Gerät gespeicherten Schlüssel zur Überprüfung der Public-Signatur verwendet, um die am Ende des Images angehängte Signatur zu überprüfen.

Die Dauer der Hash-Berechnung hängt von der Image-Länge ab. In diesem Beispiel nehmen wir ein Image mit 512 KB an. Die Dauer der Signaturüberprüfung ist unabhängig von der Image-Größe. Da der Hash von der Datengröße abhängt, führen wir ihn in der Tabelle getrennt auf, was die Zuordnung dieser Ergebnisse zu leserspezifischen Implementierungen und Anwendungen erleichtert. Dieses Beispiel verwendet SHA-256 als Hash-Algorithmus und die NIST-Primkurve P-256 für die ECDSA-Signaturprüfung. Tabelle 5 beschreibt die Daten für sicheres Booten und sichere Updates.

(Bild: Silicon Labs)

Die Software-Implementierung erfordert insgesamt 24 mJ, um das Image zu überprüfen. Obwohl dies selbst im Vergleich zu den ECDHE-Ergebnissen (circa 16 mJ) ein hoher Wert ist, ist die Häufigkeit dieser Vorgänge weitaus geringer (einmal pro Monat bei hoher Häufigkeit), sodass die Auswirkungen auf die Batterielebensdauer vernachlässigbar sind. Bei den beiden Hardware-Implementierungen sind diese Operationen noch weniger von Bedeutung.

Die Software-Implementierung ist mit 2,4 s sehr zeitaufwändig. Wie im Fall von ECDHE liegt dies im menschlichen Wahrnehmungsbereich und kann für Unmut sorgen, wenn das Firmware-Upgrade ohne ordnungsgemäße Benachrichtigung und Kenntnisnahme des Nutzers erfolgt. Die Betriebsanforderungen des Systems müssten auch tolerieren, dass die CPU für diese Dauer offline ist. Die hardwarebeschleunigten Zeiten mit 150 und 43 ms könnten wahrnehmbar sein, sind aber eher kein Ärgernis und führen nicht zu betrieblichen Problemen.

Fazit

Das Hinzufügen von Sicherheitsfunktionen zu einem unsicheren System wirkt sich nicht unbedingt negativ auf die Batterielebensdauer aus, selbst wenn der Hardwareplattform fortschrittliche Funktionen zur Verschlüsselungsbeschleunigung fehlen. Software-Implementierungen bestimmter Vorgänge mit Public-Keys (ECDHE oder ECDSA) können jedoch zu wahrnehmbaren Verzögerungen führen, die ein Ärgernis darstellen, wenn der Nutzer nicht benachrichtigt und informiert wird. In diesen Fällen wird eine Hardwarebeschleunigung empfohlen.

Zusätzlich zur Batterielebensdauer und Benutzererfahrung sind auch sicherheitsrelevante Kompromisse zu berücksichtigen. Seitenkanalangriffe auf Verschlüsselungsfunktionen könnten beispielsweise vertrauliche Informationen wie Schlüssel aus einem Produkt extrahieren, indem der Verlauf des Stromverbrauchs (Power-Analyse) und/oder das Zeitverhalten während eines Verschlüsselungsvorgangs analysiert werden. Die meisten modernen Hardware- und Software-Implementierungen sind resistent gegen Timing-Angriffe, aber nur wenige Implementierungen sind gegen Power-Analyse-Angriffe geschützt, die sich heute allerdings kostengünstig durchführen lassen (etwa 50 US-$ für ein solches Gerät) und immer weiter verbreitet sind.

Leider ist es nicht immer möglich, Software-Implementierungen gegen Power-Analyse-Angriffe abzusichern. Hier helfen Verschlüsselungs-Engines mit Gegenmaßnahmen zur Power-Analyse, die auch im kostengünstigen IoT-SoC-Markt erhältlich sind.

Die Anwendung der hier vorgestellten Analyse auf andere Systeme und Anwendungsfälle kann zu unterschiedlichen Ergebnissen führen. Sicherlich werden die Zahlen anders ausfallen. Unabhängig davon ist ein Upgrade eines unsicheren Systems auf ein sicheres System immer eine kluge Entscheidung.

Referenzen

1National Institute of Standards and Technology, U.S. Department of Commerce. Security Review of Consumer Home Internet of Things (IoT) Products. [PDF] 2019. NISTIR 8267-Draft.

2Recommendations for IoT Device Manufacturers: Foundational Activities and Core Device Cybersecurity Capability Baseline. January 2020. NISTIR 8259-2nd Draft. pp. 13-15

3Bluetooth SIG. Bluetooth Core Specification v5.0. [PDF] 2016. p. 240

4National Institute of Standards and Technology, U.S. Department of Commerce. Recommendation for Key Management. 2016. SP800-57 Part 1 Revision 4. p. 53

5American National Standards Institute. Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Standard (ECDSA). 2005. ANS X9.62.

6LimitedResults. Pwn the ESP32 Forever: Flash Encryption and Sec. Boot Keys Extraction. November 13, 2019.

* Brent Wilson arbeitet als IoT Product Security Engineer bei Silicon Labs.

(ID:47019359)