Laptop – SSD mit dm-crypt/Luks – Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen

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.

Continue reading

dm-crypt/Luks – Begriffe, Funktionsweise und die Rolle des Hash-Verfahrens – II

Im letzten Post

dm-crypt/Luks – Begriffe, Funktionsweise und die Rolle des Hash-Verfahrens – I

bin ich auf ein paar wichtige Elemente und die Funktionsweise von LUKS eingegangen. Auf dieser Grundlage können wir uns nun ein paar Gedanken zum Einsatz von Hash-Verfahren – wie etwa SHA – im Rahmen von LUKS machen.

Folgendes hatten wir bereits herausgearbeitet:
Unter LUKS muss ein PBKDF-Verfahren aus einer beliebig langen Zugangs-Passphrase eine Byte-Sequenz definierter Länge berechnen. PBKDF steht dabei für “Password-based Key Definition Function”; konkret verwendet LUKS1 die Funktion PBKDF2 (RFC2898). Den Ergebnisstring von PBKDF2 hatte ich im letzten Beitrag “PB-Key” genannt. Bitte beachtet: “PB-Key” ist keine offizieller Begriff aus dem LUKS Wortschatz. Ich verwende den Begriff hier im Blog lediglich zur klaren Unterscheidung von anderen LUKS-Keys. Der PB-Key wird zur Ent-/Ver-Schlüsselung des sog. “Master-Keys” [MK] eingesetzt. Der Master-Key wird bei der Initialisierung eines LUKS-Devices zufällig erzeugt und später in einem symmetrischen Krypto-Verfahren zur Verschlüsselung der geheim zu haltenden Daten des Devices herangezogen. Der PB-Key ist im normalen Betrieb also nur ein Hilfsmittel, um den zentralen Master-Key zu ermitteln. Nichtsdestoweniger hängt die Sicherheit des Systems maßgeblich am PBKDF.

Das Erzeugen eines Strings definierter Länge (hier des PB-Keys) aus einem beliebig langen String (hier: der Passphrase) ist eine klassische Aufgabe von Hash-Algorithmen. Wir vermuten also (zu Recht!), dass LUKS im Rahmen des PBKDF Hash-Verfahren benutzen muss. Tatsächlich war das über lange Zeit default-mäßig SHA-1. Siehe etwa die Git-Hub-Dokumentation zu dm-crypt/Luks; unter dem Punkt 5 “Security Aspects” kann man dort lesen, dass LUKS standardmäßig SHA-1 einsetzt
(https://gitlab.com/ cryptsetup/ cryptsetup/ wikis/ FrequentlyAskedQuestions).

Nun gilt aber SHA-1 schon seit längerer Zeit als unsicher. Deshalb findet man im Internet zahlreiche besorgte Diskussionen zum Einsatz von SHA-1 unter LUKS (s. die vielen Links am Ende des Artikels). Wie ist dieses Thema zu beurteilen? Diese Frage hat auch mich als Anwender beschäftigt – u.a. auch wegen der Anforderung der DSGVO, als Dienstleister im regelmäßigen Umgang mit personenbezogenen Daten Sicherheit auf dem Stand der Technik zu belegen. Ich hatte aber auch ein grundsätzliches Interesse an dem Thema.

Continue reading

dm-crypt/Luks – Begriffe, Funktionsweise und die Rolle des Hash-Verfahrens – I

Die DSGVO zwingt Freelancer, sich stärker als zuvor mit der Sicherung von Daten, die im Rahmen von Kundenprojekten auf eigenen Systemen anfallen, zu befassen. Das beinhaltet dann u.a. Sicherungsmaßnahmen für den Verlust/Diebstahl von Laptops. Unter anderen Vorzeichen gilt das Gleiche übrigens auch für Server und PCs eines Home-Office. Man wird dann zum Schluss kommen, dass man eine Teil- oder Vollverschlüsselung seines Storage-Unterbaus vornehmen muss. Unter Linux liegt es nahe, dafür das Duo dm-crypt/LUKS einzusetzen. Recherchiert man im Internet zu diesem Toolset, so stößt man immer wieder auf Fragen zu grundsätzlichen Verfahren, die zum Einsatz gebracht werden. Leider sind die Antworten aus meine Sicht nicht immer so klar, wie man sich das wünschen würde. Gräbt man tiefer, landet man schnell bei relativ komplexen Darstellungen.

Im Rahmen von LUKS kommen u.a. auch Passphrase-Hashes zum Einsatz. Ich selbst bin anfänglich u.a. darüber gestolpert, dass dafür (angeblich) SHA1 herangezogen wird. Bei “SHA1” läuten automatisch ein paar Alarmglocken. Jemand, der mal mit “JtR” oder “hashcat” gearbeitet hat, wird ggf. auch beunruhigt durch Artikel wie
https://articles.forensicfocus.com/2018/02/22/bruteforcing-linux-full-disk-encryption-luks-with-hashcat/
https://dfir.science/2014/08/how-to-brute-forcing-password-cracking.html

Sind diese Sorgen berechtigt? Nein, ein wenig mehr Beschäftigung mit dem LUKS-Verfahren relativiert solche Ängste beträchtlich. Aus Diskussionen weiß, dass das Thema auch andere Linux-Freunde interessiert. Ich möchte in diesem Beitrag deshalb auf einige wichtige Ingredienzen und grundlegende Verfahren von LUKS eingehen – so wie ich sie sehe. Als Beleg werde ich Links zu weiterführender Literatur angeben und auch ein paar kompakte Zitate zu LUKS-internen Verfahrensschritten. Erst auf dieser Grundlage lässt sich dann der Einsatz von Hash-Verfahren vernünftig diskutieren.

Die praktische Anwendung und konkrete dm-crypt/LUKS-Kommandos für die (Voll-) Verschlüsselung eines Laptops behandle ich in einer späteren Serie von Posts.

Continue reading