Eine Verschlüsselung von Daten auf Laptops ist in Zeiten der DSGVO Pflicht, da Laptops verloren gehen oder gestohlen werden können. Mein in die Jahre gekommener Laptop benötigt eh’ eine neue SSD. Zudem muss ich auf Opensuse Leap 15 wechseln. Gute Anlässe, einmal die Verschlüsselung von Betriebssystem- und Daten-Partitionen unter Opensuse Leap 15 zu testen.
Die meisten Linux-Profis setzen die Kombination “dm-crypt/LUKS” zur Verschlüsselung von Partitionen oder Volumes ein. Dabei spielen verschiedene Parameter eine Rolle, für die unter Opensuse normalerweise der YaST-basierte Partitioner Default-Werte vorgibt.
Ich nahm mir allerdings die Freiheit, die LUKS-Partitionen selbst mit eigener Parameter-Setzung vorzubereiten. Danach wurde das ganze Unternehmen unerwartet abenteuerlich und es taten sich etliche Falltüren auf. Es gab u.a. Probleme mit dem SuSE-Installer; nicht mehr bootfähige Systeme, nicht funktionales Kryptographie-Setup, Dracut-Probleme sind nur einige Stichworte. Man glaubt, man hat eine Lösung und schon zieht ein Neuinstallieren des Bootloaders über YaST alles wieder in den Abgrund.
Ich denke, das Thema “Voll-Verschlüsselung eines Linux-Laptops” ist einige Blog-Posts wert … Viele der angestellten Überlegungen und Vorgehensweisen können auch auf Desktops oder einfache Server übertragen werden.
Der ganze Themenkreis erfordert neben praktischen Installations- und Konfigurations-Schritten einige “theoretische” Vorüberlegungen. Verschlüsselung allein bietet keine hinreichende Sicherheit … man muss u.a. auch an Konsequenzen für den praktischen Betrieb des Systems denken – besonders im falle von Laptops. Zudem kann man sehr verschiedene Wege bzgl. des System-Layouts einschlagen. Einige wichtige unter vielen Variationsmöglichkeiten ergeben sich etwa aus der Beantwortung folgender fragen:
- Vollverschlüsselung unter Einschluss des root-Filesystems oder Einsatz von Daten-Containern?
- Vollverschlüsselung des Hosts oder nur darunter virtualisierter Systeme?
- LVM on LUKS oder LUKS on LVM?
Die entsprechende System-Konfiguration erfordert meist Entscheidungen im Vorfeld der praktischen Installation. Ich beginne die Artikelserie deshalb it einer Reihe grundsätzlicher Überlegungen, die praktische Auswirkungen auf die Sicherheit der Daten haben.
Um eine ständige Unterscheidung zwischen LVM-Volumes und Partitionen zu vermeiden, spreche ich nachfolgend generell von “Volumes“. An den Stellen, wo die Unterscheidung wichtig wird, werde ich sie explizit treffen. “Betriebssystem” kürze ich im Weiteren mit OS ab. Das root-Filesystem kürze ich mit “/”-FS ab.
Ich setze ein grundlegendes Verständnis der Arbeitsweise von LUKS voraus. Für Grundlagen können Interessierte einen Blick in frühere Blog-Posts werfen; dort sind auch Links zu weiterführender Literatur im Internet angegeben:
dm-crypt/Luks – Begriffe, Funktionsweise und die Rolle des Hash-Verfahrens – I
dm-crypt/Luks – Begriffe, Funktionsweise und die Rolle des Hash-Verfahrens – II
Unterscheidung Vollverschlüsselung – Teilverschlüsselung
Wir unterscheiden im Folgenden zwischen Voll- und Teil-Verschlüsselung. Unter einer Voll-Verschlüsselung verstehe ich einen Ansatz, in dem
- sowohl das Volume für das OS, mit dem auf die zu schützenden Daten zugegriffen wird,
- als auch separate Volumes zur Lagerung der zu schützenden Daten,
- als
auch Swap-Volumes
verschlüsselt werden. Bei Abweichungen spreche ich von Teil-Verschlüsselung.
Teilverschlüsselung – ist die Ablage von Daten in verschlüsselten Containern ausreichend?
Viele Leute wählen zum Schutz sensibler Daten den “bequemen” Ansatz, diese in verschlüsselten Containern (Files, Loop-Devices) oder speziellen verschlüsselten Partitionen/Volumes zu hinterlegen. Sehr beliebt ist unter Linux und Windows etwa der Einsatz von VeraCrypt. Dabei liegt das OS meist auf einem unverschlüsselten Volume, weil sich die Anwender (z.T. aus guten Gründen) an eine Voll-Verschlüsselung nicht herantrauen. So kenne ich etwa mehrere Leute, die unter Windows ihre sensiblen Daten in verschlüsselten Krypto-Containern auf der Systemplatte ablegen und meinen, nun seien die Daten bei einem Verlust oder Diebstahl des Laptops sicher. Das ist ein Irrtum (nicht nur wegen MS Windows 🙂 ). Die Gründe lassen sich u.a. mit folgenden Stichworten charakterisieren:
- Pufferung von Daten/Dateien durch das Betriebssystem und Anwendungen in “temporären” Verzeichnissen/Dateien/Datenbanken sowie anwendungsspezifische Backup-Dateien.
- Dateianalysatoren und Indexer für schlagwortbasierte Suchverfahren, die ggf. automatisch ganze Verzeichnisbäume und deren Inhalte durchforsten und Ergebnisse in Datenbanken hinterlegen.
Durch solche Verfahren landen Daten oder Datenfragmente bei der Bearbeitung von Dateien des Kryptocontainers (dekryptiert) auf dem unverschlüsselten (!) Filesystem des Betriebssystems [OS].
Zur Bearbeitung muss man die Dateien ja öffnen und ihren Inhalt entschlüsseln. Mindestens im RAM liegen die Daten dann zeitweise im Klartext vor. Würden das OS oder die aktuelle Anwendung vom RAM immer nur auf den Krypto-Container zurückschreiben, wäre die Welt in Ordnung; das ist aber in vielen Anwendungen und Betriebssystemen nicht ohne besondere Einstellungen der Fall. Auch unter Linux landen Daten u.a. im /tmp-Verzeichnis, im home-Verzeichnis des Users oder gar im Swap. Hinzu kommen weitere anwendungsspezifische Orte im Filesystem. Kritisch sind in dieser Hinsicht etwa bestimmte Mail- und Office-Anwendungen. Siehe zur Thematik der Lagerung von Daten in ggf. unverschlüsselten Bereichen des Systems auch die unten angegebenen Links.
Die gleiche Problematik liegt vor, wenn wir nur bestimmte Partitionen/Volumes eines Linux-Laptops für die Aufnahme von Daten verschlüsseln würden – das OS aber auf einem unverschlüsselten Volume desselben Geräts betreiben würden. Hier fungiert dann zwar gleich eine ganze Partition oder ein Volume als “Container”. Das ändert aber nichts daran, dass sensible Daten im unverschlüsselten Filesystem der OS-Installation landen können.
Analoges gilt aber auch bei Einsatz externer Krypto-Container – z.B. auf USB-Sticks oder USB-Platten. Dort sind die Daten zwar gegen den Verlust/Diebstahl des Devices selbst gesichert. Das unverschlüsselte System (z.B. ein Laptop), mit dem die Container-Inhalte regelmäßig ver- oder bearbeitet werden, wird aber nach einiger Zeit selbst Kopien vieler der vertraulichen Datensätze oder Dateien beinhalten. Ein Arzt, Psychotherapeut oder Heilpraktiker, der regelmäßig Patientendossiers aus solchen Containern auf einem unverschlüsselten Laptop öffnet und bearbeitet, hat im Falle des Diebstahls des Laptops also ein Problem.
Erstes Zwischenfazit: Für eine sichere Datenhaltung kommen wir um eine Verschlüsselung der Volumes/Partitionen für das OS (“/”-FS) sowie ggf. separater Datenvolumes und Swap-Bereiche nicht herum. Ansätze, die sich auf die Ablage von Daten in Crypto-Containern beschränken, entsprechen aus meiner Sicht nicht dem Stand der Technik.
Teilverschlüsselung – das Problem mit SSDs
Man könnte bei HDDs noch wie folgt argumentieren: Wenn ich alle Bereiche und Dateien kenne, die das System oder
Anwendungen zur Pufferung, Backups, Indizierung etc. nutzen, könnte ich diese Bereiche regelmäßig löschen und mit Nullen oder Zufallsdaten überschreiben. Das funktioniert leider nicht bei SSDs, die heute in die meisten Laptops eingebaut sind. Die oben diskutierte Thematik schlägt dann voll zu:
SSD-Controller verteilen ankommende Daten zur Begrenzung von Ausfällen z.T. in mehrfacher Kopie auf verschiedene Speicherelemente; das Stichwort ist hier “Wear-Leveling“. Das geschieht für den Anwender transparent im Hintergrund. Ohne Spezialwerkzeuge hat man als normaler User keinen Zugriff auf diese Storage-Bereiche. Selbst wenn man alle Systembereiche für Pufferung etc. kennt und mit zufälligen Daten überschreibt – es blieben unverschlüsselte Reste auf der SSD erhalten. An die kommen Hacker, die physikalischen Zugriff auf die SSD haben, im Zweifelsfall aber mit Spezialwerkzeugen heran. Einer der Entwickler von Veracrypt rät daher grundsätzlich vom Einsatz von SSDs auf Hochsicherheitssystemen ab. Siehe hierzu:
https://sourceforge.net/p/veracrypt/discussion/technical/thread/9cd45bb3/
https://www.veracrypt.fr/en/Security%20Requirements%20and%20Precautions.html
https://www.veracrypt.fr/en/Wear-Leveling.html
Das bedeutet:
Keine schützenswerten Daten dürfen den internen SSD-Controller je unverschlüsselt erreichen.
LUKS und auch Veracrypt sorgen dafür, dass genau das bei der Interaktion mit einem Storage-System passiert. Setzt man SSDs ein, so müssen also alle genutzten Partitionen, auf denen man schützenswerte Daten hält und auf denen ggf. unverschlüsselte Kopien oder Fragmente landen könnten, von Anfang an verschlüsselt werden. Allein hieraus ergibt sich eine Voll-Verschlüsselung für den Linux-Betrieb auf SSDs.
Das bedeutet aus meiner Sicht nicht zwingend, dass die komplette jungfräuliche SSD verschlüsselt werden muss. Aber mit OS-Installationen auf unverschlüsselten Partitionen darf man später NICHTS (!) Geheimhaltungswürdiges anfassen. Das ist in der Praxis gar nicht so einfach – und verlangt erhebliche Selbstdisziplin. Wer sicher gehen will, wird daher entweder die gesamte SSD oder zumindest alle OS-, Daten- und Swap-Partitionen, auf und mit denen regulär gearbeitet wird, verschlüsseln.
SSDs werfen übrigens noch ein zweites Problem im Zusammenhang mit Verschlüsselung auf: das des sog. Trimmens (fstrim-Kommando). Darauf komme ich in einem späteren Blog-Artikel zurück.
Teilverschlüsselung und das Hibernation-Problem
Nicht nur im Fall von Laptops muss man sich auch mit dem Thema “Hibernation” auseinandersetzen. Beim Übergang in den maximal stromsparenden Zustand werden aktuelle RAM-Inhalte auf die Platte geschrieben (unter Linux meist in den SWAP-Bereich). Nach dem Öffnen eines Krypto-Devices wird im RAM aber auch der sog. “Master-Key” für das symmetrische Verfahren zur Datenverschlüsselung vorrätig gehalten. Das ist übriges nicht nur bei LUKS so! Der Master-Key würde im Hibernation-Vorgang also auf der Platte landen … Das gleiche gilt natürlich auch für andere sensible Daten, die zum Hibernation-Zeitpunkt im RAM unverschlüsselt vorlagen.
Auch das ist ein Grund dafür, auf Laptops alle Volumes/Partitionen die vom OS genutzt werden, zu verschlüsseln. Ein Angreifer könnte etwa einen Laptop in die Hände bekommen, der sich schon in einem Hibernation-Zustand befindet oder ihn nach gewisser Zeit erreichen wird. Der typische Fall für Freelancer ist der Verlust beim Umstieg zwischen zwei Zügen. Oder der gezielte Diebstahl in der Mittagspause.
Man sollte sich für seine Distribution in jedem Fall darum kümmern, was als Platz für Hibernation genutzt wird. Natürlicherweise bietet sich der
SWAP an; man kann aber auch speziell vorbereitete Dateien nutzen. Auch unter Opensuse Leap wird für Hibernation standardmäßig der SWAP herangezogen. Siehe etwa:
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.power-mgmt.html
Unter Opensuse müssen wir auf einem System mit aktiviertem Hibernation also unbedingt den SWAP-Space verschlüsseln.
Es gibt übrigens ein ganz ähnliches Problem im Zusammenhang mit Virtualisierung. Dort kann man Gastsysteme in einen “Saved“-Zustand überführen, in dem auch der RAM der virtuellen Maschine in einem vorgegebenen Verzeichnis-Bereich des OS – also ggf. auf einem unverschlüsselten Bereich des Systems gespeichert wird.
Der aufmerksame Leser wird sich natürlich auch fragen, ob den nicht der RAM selbst zum Angriffsziel werden kann, wenn man statt Hibernation etwa des beliebte “Suspend to RAM” [StR] einsetzt. Ja, das ist ein wichtiger Punkt; StR stellt ein Sicherheitsrisiko dar und sollte auf sicherheitsrelevanten Systemen vermieden werden (s. einen späteren Artikel). Aber genug für heute …
Zwischenfazit
Erste einfache Überlegungen sprechen gegen eine Teil-Verschlüsselung von (mobilen) Systemen, die die Sicherheit geheim zu haltender Daten auf dem Stand der Technik garantieren sollen. Im nächsten Beitrag
stelle ich Überlegungen zur Verschlüsselung virtualisierter Systeme bzw. derer Hosts an.
Links zum Thema “Warum Voll-Verschlüsselung?”
https://en.opensuse.org/SDB:Encrypted_root_file_system
https://wiki.archlinux.org/index.php/Disk_encryption