Vertraulichkeit von Daten durch Speicherverschlüsselung auf Embedded-Linux-Geräten

Der Cyber Resilience Act (CRA) führt die Vertraulichkeit von Daten als eine “grundlegende Cybersicherheitsanforderung” auf, die Produkte erfüllen müssen, um auf dem EU-Markt in Verkehr gebracht zu werden¹. Diese Anforderung betrifft viele Embedded-Linux-Geräte, insbesondere solche, die personenbezogene Daten speichern. Dieser Blog-Post ist der erste einer Reihe zu Sicherheitsthemen rund um den CRA.

Vertraulichkeit von Daten bedeutet den Schutz von Daten vor unbefugtem Zugriff und unbefugter Offenlegung. Um Vertraulichkeit umfassend sicherzustellen, muss sie über alle Zustände hinweg gewahrt bleiben, in denen Daten vorliegen können. Je nach Bedrohungsmodell können für jeden Zustand unterschiedliche Technologien erforderlich sein. Zum Beispiel:

• Transport Layer Security (TLS) für Daten während der Übertragung
• Trusted Execution Environments (TEEs) für Daten während der Verarbeitung
• Verschlüsselung ruhender Daten (z. B. Full Disk Encryption) für ruhende Daten

Verschiedene Verfahren können die Vertraulichkeit ruhender Daten gewährleisten, abhängig von den konkreten Anforderungen an die Daten. Um beispielsweise Benutzerpasswörter zu schützen, setzt Linux auf die Shadow-Datei (/etc/shadow), die gesalzene Passwort-Hashes speichert. Dieser Ansatz funktioniert, weil die Authentifizierung lediglich den Vergleich von Hashes erfordert und nicht die Wiederherstellung des ursprünglichen Klartexts. Wenn die Daten jedoch später im Klartext abgerufen werden müssen, ist Verschlüsselung ein gängiger Ansatz.

Speicherverschlüsselung lässt sich auf mehreren Ebenen des Software-Stacks umsetzen. Der feingranularste Ansatz ist die Verschlüsselung auf Anwendungsebene, bei der bestimmte Programme wie Passwortmanager die Ver- und Entschlüsselung intern verwalten. Eine weitere Möglichkeit ist die Verschlüsselung auf Speicherebene, die Daten transparent schützt, unabhängig davon, welche Anwendung darauf zugreift. In diesem Beitrag konzentrieren wir uns auf die Technologien zur Speicherverschlüsselung, die unter Linux verfügbar sind.

Linux bietet innerhalb des Storage-Stacks mehrere Mechanismen zur Verschlüsselung ruhender Daten, wobei dm-crypt², fscrypt³ und eCryptfs⁴ zu den gängigsten Optionen zählen. Auf Blockebene ermöglicht dm-crypt die Verschlüsselung ganzer Festplatten oder Partitionen. Auf Dateisystemebene erlaubt fscrypt eine granulare Verschlüsselung pro Verzeichnis auf unterstützten Dateisystemen. eCryptfs bietet zwar einen ähnlichen Ansatz mit einem gestapelten Dateisystem, ist aber eine ältere Technologie, die weitgehend durch fscrypt abgelöst wurde.

Randnotiz: Was ruhende Daten sind

Ruhende Daten bezeichnen digitale Informationen, die physisch auf einem stabilen Speichermedium abgelegt sind, etwa auf einer Festplatte oder einem Flash-Speicher, und die sich weder gerade durch ein Netzwerk bewegen noch im Arbeitsspeicher verarbeitet werden. Im Kontext der Speicherverschlüsselung werden diese Daten geschützt, indem sie mit kryptographischen Algorithmen in Chiffretext umgewandelt werden. So bleibt ihre Vertraulichkeit selbst dann gewahrt, wenn die physische Hardware gestohlen wird. Der Zugriff auf die Informationen erfordert einen bestimmten Schlüssel zur Entschlüsselung oder ein Passwort, das als letzte Barriere zwischen einem unbefugten Benutzer und den eigentlichen Dateien dient.

Verschlüsselung auf Blockebene mit dm-crypt

Das Device-Mapper-Target dm-crypt setzt unter Linux die Verschlüsselung auf Blockebene um. Es ermöglicht die Verschlüsselung ganzer Festplatten oder Partitionen auf jedem Gerät, das Linux als Block Device bereitstellt, also auf jedem Speichermedium, das Daten in Blöcken fester Größe verarbeitet, etwa HDDs, SSDs, SD-Karten und eMMC-Module. Da es auf Blockebene arbeitet, unterstützt es jedes blockbasierte Dateisystem.

Der Linux Device-Mapper erlaubt das Anlegen virtueller Block Devices, die auf ein oder mehrere zugrunde liegende Block Devices abgebildet werden, die physisch oder virtuell sein können. Ein Device-Mapper-Target verarbeitet Lese- und Schreibanfragen, die an das virtuelle Block Device gestellt werden, und leitet sie an das darunterliegende Gerät weiter. Das Target legt fest, wie Anfragen abgebildet werden und ob die Daten dabei transformiert werden. Ein solches Target ist dm-crypt, das Daten beim Schreiben verschlüsselt und beim Lesen entschlüsselt.

dm-crypt kann zwar ganze Festplatten oder Partitionen verschlüsseln, arbeitet aber ausschließlich mit Block Devices. Daher kann es nicht mit rohem Flash arbeiten, der über das Linux-MTD-Subsystem bereitgestellt wird (z. B. rohes NAND), was in Embedded-Systemen häufig vorkommt. Beachten Sie, dass SSDs und USB-Sticks ebenfalls Flash-basiert sind, ihre internen Controller den rohen Flash jedoch abstrahieren und dem Betriebssystem eine normale Block-Device-Schnittstelle präsentieren.

Das Userspace-Werkzeug cryptsetup⁵ wird üblicherweise zum Konfigurieren von dm-crypt-Volumes verwendet. Alternativ bietet das Werkzeug dmsetup⁶ Low-Level-Kontrolle über den Device-Mapper und kann Mappings für jedes Target verwalten, einschließlich dm-crypt. cryptsetup unterstützt das Format Linux Unified Key Setup (LUKS) (LUKS1⁷ und LUKS2⁸), das einen standardisierten On-Disk-Header zum Speichern der Verschlüsselungs-Metadaten am Anfang des verschlüsselten Block Devices festlegt. Der LUKS-Header enthält mehrere Key-Slots, sodass mehrere Passphrasen dasselbe verschlüsselte Volume entsperren können. Wenn der Benutzer eine Passphrase eingibt, leitet cryptsetup daraus einen Key-Encryption-Key ab und entschlüsselt damit das in einem LUKS-Key-Slot gespeicherte Volume-Key-Material. Gelingt dieser Schritt, lädt cryptsetup den Volume-Key in dm-crypt.

Verschlüsselung auf Dateisystemebene mit fscrypt (oder eCryptfs)

Der Linux-Kernel stellt zwei Mechanismen für die Verschlüsselung auf Dateisystemebene bereit: fscrypt und eCryptfs. Von diesen ist fscrypt die moderne und empfohlene Lösung. Bevor fscrypt eingeführt wurde, kamen häufig Overlay- oder gestapelte Dateisystemansätze wie eCryptfs zum Einsatz. eCryptfs ist selbst ein gestapeltes Dateisystem und gilt in der Community inzwischen weithin als veraltet, mit einer möglichen Entfernung aus dem Linux-Kernel in der Zukunft⁹. Sein Einsatz lässt sich heute daher in der Regel nur in Nischenszenarien rechtfertigen, vor allem dann, wenn Verschlüsselung auf Dateisystemebene erforderlich ist, das zugrunde liegende Dateisystem aber fscrypt nicht unterstützt.

fscrypt bietet transparente Verschlüsselung auf Dateisystemebene. Im Gegensatz zu dm-crypt, das ein ganzes Block Device verschlüsselt, wendet die Verschlüsselung auf Dateisystemebene Richtlinien pro Verzeichnis an und verschlüsselt die Dateien innerhalb des geschützten Verzeichnisbaums. Dieser Aufbau erlaubt es, dass verschiedene Teile desselben Dateisystems unterschiedliche Schlüssel verwenden. So können beispielsweise mehrere Benutzer ihre Home-Verzeichnisse mit jeweils eigenen Schlüsseln verschlüsseln, obwohl alle Home-Verzeichnisse auf demselben zugrunde liegenden Block Device liegen.

Da fscrypt eine Bibliothek ist, in die sich Dateisysteme einklinken können, um transparente Verschlüsselung von Dateien und Verzeichnissen zu unterstützen, muss ein Dateisystem sie ausdrücklich unterstützen. Zu den Dateisystemen, die fscrypt derzeit unterstützen, zählen ext4, f2fs und ubifs. fscrypt ist besonders relevant für tief eingebettete Linux-Systeme, die rohen NAND-Speicher verwenden, bei denen dm-crypt nicht eingesetzt werden kann, weil es nur mit Block Devices arbeitet.

Wichtig zu beachten ist, dass fscrypt Dateiinhalte und Dateinamen verschlüsselt, die meisten Metadaten des Dateisystems jedoch unverschlüsselt lässt. Dazu gehören Eigentümer- und Berechtigungsbits, Zeitstempel und die Verzeichnisstruktur.

Die wichtigsten Erkenntnisse

Linux kann ruhende Daten durch Speicherverschlüsselung schützen, auf Blockebene mit dm-crypt oder auf Dateisystemebene mit fscrypt oder dem älteren eCryptfs. Aus Sicht der Anwendungen ist dieser Schutz transparent, weil der Kernel Daten bei Schreibvorgängen verschlüsselt und bei Lesevorgängen entschlüsselt. Dadurch werden die Daten in verschlüsselter Form auf dem Datenträger gespeichert. Ein Angreifer, der physischen Zugriff auf das Speichermedium erlangt oder ein Offline-Abbild des Datenträgers erhält, kann nur Chiffretext wiederherstellen.

Eine feingranularere Alternative ist die Verschlüsselung auf Anwendungsebene, bei der die Anwendung Ver- und Entschlüsselung intern umsetzt. Dieser Ansatz erhöht die Komplexität, kann aber zusätzlichen Schutz gegen bestimmte Laufzeitangriffe bieten. Stellen Sie sich beispielsweise einen Angreifer vor, der aus der Ferne beliebigen Lesezugriff auf das Dateisystem erlangt. Bei Verschlüsselung auf Anwendungsebene liefern Lesezugriffe auf die Datendateien der Anwendung weiterhin nur Chiffretext, und der Angreifer muss zusätzlich die Anwendung oder ihren Umgang mit den Schlüsseln kompromittieren, um an den Klartext zu gelangen. Bei den zuvor besprochenen Methoden der Speicherverschlüsselung hingegen gibt das Betriebssystem den Klartext im Rahmen des normalen Betriebs über das Dateisystem preis, sobald die Daten entsperrt sind. Ein Angreifer mit ausreichendem Laufzeit-Dateizugriff kann die Daten also direkt lesen.

Verschlüsselung allein gewährleistet jedoch keine Integrität. fscrypt beispielsweise bietet Vertraulichkeit, aber keine Integrität. Ein Angreifer, der Chiffretext verändert, kann so Datenkorruption verursachen oder, schlimmer noch, verschlüsselte Daten so verändern, dass sich Software anders verhält. Um Manipulationen zu erkennen, verwenden Sie authentifizierte Verschlüsselung (AEAD) mit dm-crypt in Kombination mit Integritätsmechanismen wie dm-integrity¹⁰ für beschreibbaren Speicher oder dm-verity¹¹ für schreibgeschützten Speicher.

Ein weiterer Punkt, den es zu bedenken gilt: Auf Embedded-Geräten ist die interaktive Eingabe einer Passphrase beim Booten in der Regel nicht möglich, obwohl sie zum Abrufen des Schlüssels für die Speicherverschlüsselung nötig ist. Der Schlüssel muss daher an einem sicheren Ort abgelegt werden. Embedded-Systeme setzen zu diesem Zweck üblicherweise auf hardwaregestützte Schlüsselspeicherung, etwa auf TPMs oder Secure Elements. Weiterführende Informationen finden Sie in unserem Blog-Post TPM auf Embedded-Systemen.

Welches Verfahren sich am besten eignet, um die Vertraulichkeit von Daten sicherzustellen, hängt von den zu schützenden Daten und vom Bedrohungsmodell ab. Bei der sigma star gmbh empfehlen wir generell, Full Disk Encryption mit dm-crypt mit Verschlüsselung auf Anwendungsebene für sensible Daten zu kombinieren. Für Embedded-Systeme empfehlen wir außerdem, Verschlüsselungsalgorithmen und Cipher-Konfigurationen mit Benchmarks zu vergleichen. Muss die CPU jeden Block in Software ver- und entschlüsseln, können Lese- und Schreibdurchsatz sowie die Bootzeit leiden. Indem wir mögliche Konfigurationen auf der Zielhardware mit Benchmarks vermessen, können wir die leistungsstärkste Option ermitteln, ohne die Sicherheit zu beeinträchtigen.