Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VII – Grundinstallation für LUKS on LVM

In den letzten Beiträgen meiner Serie zu Voll-Verschlüsselung eines Laptops und angrenzenden Themen

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
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – V – kryptierte Partitionen und Alignment
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VI – Key-Slots, PBKDF2- und MK-Iterationen

haben wir uns auf einer externen SSD bereits Partitionen und LUKS-LVM-Volumes (LUKS on LVM / VGs: vga, vgs / LVs: lva1, lvs1) für eine Test-Installation von Opensuse Leap 15.0 erstellt. Das Alignment hatten wir dabei – entgegen den Fake-Informationen des externen USB-Controllers – bereits auf die spätere Nutzung der SSD direkt am SATA-III-Bus des Laptops ausgerichtet. Wir schließen diese Disk nun an den Laptop als externe USB-Disk an und nehmen eine Opensuse-Leap15-Installation vor. Ich greife dabei auf ein ISO-Image für eine Installations-DVD zurück. Der Laptop wird von mir an ein geeignetes LAN-Segment angeschlossen; Firewalls erlauben einen Zugriff auf Update Repositories von Opensuse im Internet.

Der Installationsprozess muss anschließende Boot-Vorgänge von verschlüsselten LVM-Volumes sicherstellen. Das betrifft einerseits reguläre Bootvorgänge, andererseits aber auch einen Bootvorgang aus einem vorhergehenden Hibernation-Zustand. Wir ignorieren letzteres in einem ersten Anlauf – und verzichten zunächst völlig auf die Einbindung eines SWAPs. Das führt zu einer Vereinfachung; der Hauptgrund ist aber, dass der Opensuse-Installer mit der Konfiguration auf Basis vorgefertigter LUKS-Devices Probleme hat.

Ich gehe zu Beginn dieses Artikels kurz auf Schritte und Elemente eines regulären Boot-Vorgangs ein und bespreche erst danach einige wichtige Schritte während der Installation. Das erscheint mir zum besseren Verständnis einiger Aktionen sinnvoll.

Ziel ist zudem keine detaillierte, allgemeingültige Installationsanleitung für Opensuse Leap; ich setze vielmehr voraus, dass der interessierte Leser auf seinem Laptop schon mal eine Standard-Opensuse-Installation durchgeführt hat. Hier geht es lediglich um Besonderheiten, die bei der Installation auf LUKS-Volumes zu beachten sind.

Hinweise: Mein Laptop hat ein Optimus-System (prozessorinterne Grafikkarte + Nvidia-Karte im Verbund). Das macht immer etwas Probleme; in meinem Fall muss man von vornherein bestimmte Video-Einstellungen wählen, um überhaupt den grafischen Install-Bildschirm zu erreichen. Darauf werde ich kurz eingehen. Zudem besitzt mein Test-Laptop noch ein Legacy BIOS. Mit OS kürze ich nachfolgend “Betriebssystem” ab; FS steht für “Filesystem”.

Für die
schlechte Qualität der Bilder entschuldige ich mich; ich habe die am Abend gemacht und die falsche Einstellung am Handy gewählt :-(.

Continue reading

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VI – Key-Slots, PBKDF2- und MK-Iterationen

Im letzten Beitrag meiner Serie zu Voll-Verschlüsselung eines Laptops und angrenzenden Themen

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
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – V – kryptierte Partitionen und Alignment

hatten wir LVM-Volumes angelegt und mit LUKS verschlüsselt. Dabei tauchte das Thema der Anzahl von PBKDF2-Iterationen unter LUKS in zwei Ausprägungen auf:

  • Anzahl der Iterationen pro Key-Slot. Diese Zahl sollte aus Sicherheitsgründen möglichst hoch sein.
  • Anzahl der Iterationen für den Master-Key-Digest (MK-Digest; hash-basierter Fingerprint). Weniger sicherheitsrelevant.

Kann man diese Iterationen individuell steuern oder im Nachhinein irgendwie ändern? Die Antwort ist: Für die sog. Key Slots schon, für den MK-Digest nicht ohne Neu-Anlage des LUKS-Volumes (mit Datensicherung und erneuter Einspielung) und damit Neu-Verschlüsselung oder Neuanlage des LUKS-Headers zum gleichen Master-Key.

Es gibt inzwischen zwar ein Kommando “cryptsetup-reencrypt”, das einen Lauf zur Recryptierung aller vorhandenen Daten in situ durchführt. Die man-Seite bietet aber auch für “cryptsetup-reencrypt” keinen Parameter zur separaten Festlegung der Iterationszahl für den MK-Digest an. Das Kommando gilt zudem als experimentell. Ich selbst habe es noch nie ausprobiert.

Die Iterationsanzahl des MK-Digest kann man beim Anlegen eines LUKS-Devices (indirekt) festlegen. Änderungen erfordern eine Neuanlage oder einen Re-Encrypt-Prozess. Hält man die Anzahl der Iterationen für den Digest für zu klein, sollte man also am besten gleich zu Anfang gegensteuern. Das ist das erste Thema dieses Beitrags.

Das zweite Thema ist, wie man mit Hilfe einer temporären Umschlüsselung die Iterationsanzahl für einen “Key Slot” ändert. Dabei sehen wir nebenbei auch, wie man einen weiteren “Key Slot” anlegt.

Das dritte Thema ist ein Backup des LUKS-Headers.

Zwischenzeitlich hat mich eine Mail erreicht, in der sich ein Leser vor einer weiteren Durchführung von LUKS-Befehlen eine kurze, prägnante Erläuterung von LUKS-Prinzipien und der sog. Key-Slots wünschte. Die nachfolgenden Schritte erfordern tatsächlich ein klares Verständnis des LUKS-Verfahrens. Ich stelle daher eine knappe Zusammenfassung von LUKS an den Anfang.

Continue reading

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.

Continue reading

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.

Continue reading

Linux SSD partition alignment – problems with external USB-to-SATA controllers – II

In my last article
Linux SSD partition alignment – problems with external USB-to-SATA controllers – I
I wrote about different partition alignments parted and YaST’s Partitioner (Opensuse) applied when one and the same SSD (a Samsung 850 Pro) was attached

  • to external USB-to-SATA controllers and the USB bus of a Linux system (1 MiB-alignment: start sectors as multiples of 2048 logical 512 byte blocks)
  • or directly to an internal SATA-III-controller of a Linux system (alignment to multiples of 65535 logical 512 byte blocks).

We saw that different controllers led to the detection of different disk topology parameters (I/O limits) by the Linux system via the libblkid library. For one and the same SSD different values were reported by different controllers e.g. for the following parameters (I/O Limits data) :

physical_block_size,    minimum_io_size,    optimal_io_size

We saw in addition that even different Linux disk tools may report different values; e.g. fdisk showed a different value [512 byte] for the “optimal_io_size” for the SSD on the SATA bus than e.g. lsblk and parted [0].

Guided by a Red Hat article https://people.redhat.com/msnitzer/docs/io-limits.txt we came to the conclusion that at least parted and YaST’s Partitioner use heuristic rules for its alignment decisions. The rules take into account the values for disk “I/O Limits” parameters. They are consistent with a default of “optimal” for the alignment parameter of parted and provide a decision when “the value for “optimal_io_size” is found to be zero. By applying these rules we could explain why we got different partition offsets and alignments for one and the same disk when it was attached to different controllers.

But this insight left us in an uncomfortable situation:

  1. Should we cling to the chosen settings when we use the SSD on external controllers, only? Can we partition SSDs on an external USB-to-SATA controller and move them later directly to a SATA-bus without adjusting partition borders? We saw that “parted” would complain about misalignment when SSD partitions were prepared on a different controller.
  2. As many people discuss the importance of partition alignment for SSD performance – will we see a noticeable drop in performance when we read/write to “misaligned” partitions?
  3. We saw that at least a JMicron controller indicated a bundling of 8 logical 512 byte blocks into a 4096 byte (fake?) “physical block”. Another question might therefore be what happens after an installation and something is written by Grub to the first sector of a disk with GPT layout – and maybe assuming some wrong disk topology? This is not so far fetched as one may think; see the third link at the bottom for a disaster with an MBR.

I cannot answer all these questions in general. But in this article I will at least look a bit into performance issues and answer the last question for my test situation.

Continue reading