Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – V – kryptierte Partitionen und Alignment

Nach den Überlegungen in den letzten Artikeln dieser Serie

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IV – Disk-Layout

sind wir gut gerüstet, um für Tests zur Voll-Verschlüsselung eines Laptops passende LVM-Volumes anzulegen und mit einem "LUKS on LVM"-Layer zu versehen. (LVM on LUKS wenden wir uns später zu). Ich sage aus guten Gründen "Tests" - nicht finale Installation. Es gibt Einiges, was man falsch machen kann oder was zu unpraktikablen Konsequenzen führt. Im Besonderen, wenn man sich ein wenig abseits der normalen Installationsprozeduren (hier von Opensuse) bewegt.

Ich werde nachfolgend den Umgang mit einer jungfräulichen SSD diskutieren. Arbeitet ihr nicht mit einer leeren SSD/HDD und wollt ihr alte Installationen nicht verlieren, empfehle ich vorherige vollständige Backups - mit zusätzlichem Aufschreiben von UUIDs plus ggf. separatem Backup der Verzeichnisse "/etc/" und "/boot". Der Verlust vorhandener Daten ist bei Fehlern möglich.

Bevor man eine vorhandene Laptop-SSD mit funktionstüchtigen Installationen komplett durch eine neue SSD ersetzt, liegt es nahe, die Voll-Verschlüsselung zunächst separat zu testen. Dazu nutzt man die neue SSD vorübergehend als externes, bootbares Laufwerk am USB-3-Anschluss eines laufenden Linux-Systems. Im besten Fall kann man die Test-Installation nach einem Einbau in den Laptop und Anschluss an den dortigen SATA-III-Bus direkt weiter nutzen. Dachte ich so ...

Dieses Vorgehen führte bei mir aber zu Problemen mit dem Alignment der anzulegenden Partitionen und Volumes. Das war durchaus lehrreich. Ich werde deshalb darauf eingehen, obwohl es unser Kernthema nur am Rande berührt. Ein weiteres wichtiges Thema dieses Artikels sind die Einstellungen zur Verschlüsselung. Dabei ist vor allem die Anzahl der "PBKDF2"-Iterationen interessant.

Hinweis: Diejenigen, die sich mit der Funktionsweise von LUKS noch nicht so gut auskennen, mögen jetzt einen Blick in den Artikel
crypt/Luks – Begriffe, Funktionsweise und die Rolle des Hash-Verfahrens – I
und den Nachfolge-Artikel werfen. Dort sind etliche weiterführende Links angegeben. Hilfreich ist ferner ein Blick in die man-Seiten zum Kommando "cryptsetup". LVM-Grundkenntnisse setze ich voraus.

Weiterlesen

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer

In den letzten Beiträgen dieser Serie

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

hatten wir Vorüberlegungen zur Verschlüsselung eines Laptops angestellt. Wie in den früheren Beiträgen auch bezeichne ich nachfolgend sowohl Partitionen als auch LVM-Volumes als "Volumes". Wenn eine Unterscheidung notwendig ist, werde ich die explizit treffen. Für das root-Filesystem benutze ich die Abkürzung "/"-FS.

Das wichtigste Ergebnis unserer bisherigen Überlegungen war, dass wir das System, auf dem wir mit den zu schützenden Kundendaten arbeiten, voll verschlüsseln müssen. Das bedeutet, dass wir sowohl das Volume für das "/"-FS, als auch den SWAP sowie auch alle Volumes für Daten verschlüsseln. Es reicht nicht, mit Datencontainern zu arbeiten.

Unser zweites Ergebnis war: Wir sollten diesen Ansatz auf einem Virtualisierungs-System (LVM/QEMU, LXC) zur Sicherheit sowohl auf die Volumes anwenden, die der Host selbst nutzt, als auch auf alle Volumes, die von den Betriebssystemen der Gäste genutzt oder zusätzlich gemountet werden. Sprich: Auch der Virtualisierungshost muss voll-verschlüsselt werden (Root-Filesystem, Swap (!), Daten-Volumes). Es gibt zu viele Faktoren, durch die Inhalte der Gastsysteme auf Host-Filesysteme geraten können.

Wir hatten ferner diskutiert, dass im Prinzip sowohl das Host-System auf dem Laptop als auch die Gast-Systeme selbst ihren Teil zur Verschlüsselung beitragen können. Dieses Thema hat nicht zuletzt auch mit der Schichtung der Zugriffsverfahren auf Storage-Devices und Filesysteme zu tun: Jeder, der mit Linux professionell arbeitet, nutzt früher oder später LVM, um bzgl. der Anpassung der Größe von Filesystemen für Hosts und Gäste flexibel zu werden. Wie bringt man LVM mit der LUKS-Verschlüsselung zusammen? Wie stellt sich das im Fall von Virtualisierung dar?

Ein anderer für die Praxis wichtiger Punkt ist die Kompatibilität von Verschlüsselungsverfahren für Volumes mit Boot-Managern und auch systemd. Kann der unter Linux wohl hauptsächlich eingesetzte Grub2-Manager mit verschachtelten LVM/LUKS- oder LUKS/LVM-Strukturen auf Block-Devices umgehen?

Der nachfolgende Artikel geht aus grundlegender Perspektive auf diese Fragestellungen ein. Spätere Artikel widmen sich dann der praktischen Umsetzung.

Weiterlesen