Tag Archives: PBKDF2

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

Posted on by

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 →

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

Posted on by

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.

Continue reading →

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

Posted on by

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 →