Tag Archives: LUKS

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 →

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

Posted on by

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 →

Cryptsetup close – not working for LVM on LUKS – device busy

Posted on by

I am working right now on some blog posts on a full dmcrypt/LUKS-encryption of Laptop SSDs. Whilst experimenting I stumbled across the following problem:

Normally, you would open an encrypted device by

cryptsetup open /dev/YourDevice cr-YourMapperLabel

(You have to replace the device-names and the mapper-labels by your expressions, of course). You would close the device by

cryptsetup close cr-YourMapperLabel

In my case I had created a test device “/dev/sdg3”; the mapper label was “cr-sg3”. However, whenever I tried to close this special crypto-device I got the following message: 

mytux:~ # cryptsetup close  cr-g3
Device cr-g3 is still in use.

Ops, had I forgotten a mount or was something operating on the filesystem inside cr-sg3 still? Unfortunately, lsof did not show anything. No process seemed to block the device … 

mytux:~ # lsof /dev/mapper/cr-g3
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1111/gvfs
      Output information may be incomplete.

But 

mytux:~ # dmsetup info -C  
Name                Maj Min Stat Open Targ Event  UUID                                                                
....
cr-g3               254  16 L--w    2    1      0 CRYPT-LUKS1-Some_UUID_Info-cr-g3                  
....

Note the “2” in the Open column. Clearly, there was a count of 2 of “something” that had a firm grip on the device. I also tried 

mytux:~ # dmsetup remove -f cr-g3
device-mapper: remove ioctl on cr-g3  failed: Device or resource busy
Command failed

After this trial the dmsetup table even showed an error: 

mytux:~ # dmsetup table
...
cr-g3: 0 218034943 error 
...

What the hack? On the Internet I found numerous messages related to similar experiences – but no real solution.

https://www.linuxquestions.org/ questions/ linux-kernel-70/ device-mapper-remove-ioctl-on-failed-device-or-resource-busy-4175481642/
https://serverfault.com/ questions/ 824425/ cryptsetup-cannot-close-mapped-device
https://gitlab.com/ cryptsetup/ cryptsetup/ issues/315
https://askubuntu.com/ questions/ 872044/ mounting-usb-disk-with-luks-encrypted-partion-fails-with-a-cryptsetup-device-al

Whatever problems these guys had – I tested with other quickly created encrypted filesystems. In most cases I had no problems to close them again. It took me a while to figure out that the cause of my problems was LVM2! Stupid me! Actually, I had defined a LVM volume group “vg1” inside the encrypted partition – on purpose. The related volumes could, of course, be seen in the “/dev/mapper/” directory 

mytux:~ # la /dev/mapper 
total 0
drwxr-xr-x  2 root root     440 Nov  8 15:53 .
drwxr-xr-x 28 root root   12360 Nov  8 15:53 ..
crw-------  1 root root 10, 236 Nov  8 15:46 control
lrwxrwxrwx  1 root root       8 Nov  8 16:12 cr-g3 -> ../dm-16
...
lrwxrwxrwx  1 root root       8 Nov  8 15:54 vg1-lvroot -> ../dm-17
lrwxrwxrwx  1 root root       8 Nov  8 15:53 vg1-lvswap -> ../dm-18
...

r

and also in “dmsetup”

mytux:~ # dmsetup info -C  
Name                Maj Min Stat Open Targ Event  UUID                                                                
.... 
vg1-lvswap          254  18 L--w    0    1      0 LVM-Some_UUID_Info
vg1-lvroot          254  17 L--w    0    1      0 LVM-Some_UUID_Info
....
cr-g3               254  16 L--w    2    1      0 CRYPT-LUKS1-Some_UUID_Info-cr-g3                  
....

So do not let yourself get confused by the fact that “lsof” may not help you to detect processes which access the crypto devices in question! It may be the kernel (with its LVM component) itself! (triggered by udev …). This problem will always appear when you work with LVM on top of LUKS. It also explained the count of 2. The solution was simple afterwards:

mytux:~ # vgchange -a n vg1
  0 logical volume(s) in volume group "vg1" now active
mytux:~ # cryptsetup close cr-g3
mytux:~ #

Conclusion:
Always remember to explicitly deactivate LVM volume groups that may exist on LUKS encrypted partitions before closing the crypto-device! Have a look with the commands “lvs” or “vgdisplay” first!

Addendum 12.11.2018:
The last days I have read a bit more on crypto-partitions and volumes on the Internet. I came across an article which describes the deactivation of the volume groups before closing the crypto-device clearly and explicitly:
https://blog.sleeplessbeastie.eu/ 2015/11/16/ how-to-mount-encrypted-lvm-logical-volume/