Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IV – Disk-Layout

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
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer

haben wir etliche Vorüberlegungen zur Voll-Verschlüsselung eines Linux-Laptops mit SSD unter Opensuse Leap 15 angestellt. Für die anstehenden Tests muss ich noch planen, welche Partitionen das Layout meine (noch jungfräuliche) SSD prägen sollen. Ich kann hier natürlich nur einen Vorschlag vorstellen, der u.a. durch Platz für virtualisierte Gastsysteme geprägt ist und den Test von "LUKS on LVM", "LVM und LUKS" sowie Hibernation ermöglichen soll. Bei mir persönlich gibt es zudem eine Präferenz für "LUKS on LVM".

Das root-Filesystem bezeichne ich nachfolgend mit "/"-FS.

Weiterlesen

Full encryption with LUKS (SHA512, aes-xts-plain64) – grub2 really slow ….

My German readers know that I work on an article series regarding a reasonable full encryption of customer related Linux laptops and virtual machines with dm-crypt/LUKS. Whilst experimenting with different configurations I found that all my naive assumptions regarding the boot time of fully encrypted systems on standard laptops were wrong.

The boot manager for Linux - Grub2 - can lead to unacceptable long boot times (> n * 10 secs) - despite much smaller and reasonable values for the time required by the kernel to open encrypted devices. Delay factors during boot of more than 7 to 8 are possible and have to be taken into account during the encryption setup.

In my case Grub2 appears to be dead slow regarding a distinct factor which determines the time required during a first boot phase until the graphical Grub menu with choices for bootable installations gets displayed. The time for later boot phases (loaded kernel with initrd-support, access to encrypted volumes by the kernel) is much, much shorter.

A quick test showed that Grub2 is inefficient with respect to the SHA512 and not to the core and aes-based symmetric decryption algorithm.

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