arch linux von verschlüsselter SSD

Sunday, August 11. 2013

Das Thema ist an sich gut dokumentiert, hier ein paar Links:

https://wiki.archlinux.org/index.php/Encrypted_LVM

https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS

https://wiki.archlinux.de/title/Festplatte_verschl%C3%BCsseln

http://www.marcstraube.de/linux/2012/08/installation-von-archlinux-mit-verschlusseltem-lvm-und-systemd/

 
Medium mit Rauschen initialisieren:
# frandom ist ein wenig schneller /dev/random und dcfldd ist ein erweitertes dd und gibt dem Ungeduldigen eine Fortschrittsanzeige
dcfldd if=/dev/frandom of=/dev/sdb   
 
# für Neugierige und Kontroll-freaks ist
# lde ein DiskEditor, mit dem man sich anschliessend ansehen kann, was nun auf der disk steht
 
lde /dev/sdb   
 
# SSD partitinieren, da wir syslinux einsetzen werden, brauchen wir nur zwei Partitionen für boot und den verschluesselten Rest 
# gdisk ist gpt fdisk, GPT ist bei mehr als 2 TB angesagt
 
gdisk /dev/sdb  
 
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          100351   48.0 MiB    8300  Linux filesystem
   2          100352       250069646   119.2 GiB   8E00  Linux LVM
 
# jetzt luks auf die grosse Partition, vorher einen langen, gut merkbaren Pass-Satz ausdenken
cryptsetup -y  -h sha512 --align-payload=8192 luksFormat /dev/sdb2
cryptsetup luksOpen --allow-discards /dev/sdb2 clvm 
 
# und jetzt die logischen Partitionen der LVM anlegen
pvcreate  --dataalignment 4M /dev/mapper/clvm
vgcreate ssd /dev/mapper/clvm
lvcreate -L 20G ssd -n rootvol
lvcreate -L 80G ssd -n homevol
lvcreate -l 100%FREE ssd -n varvol
 
# boot formatieren, 
mkfs.ext2 /dev/sdb1 -L boot
 
# die übrigen volumes bekommen ext4
mkfs.ext4  -E discard /dev/mapper/ssd-rootvol -L root
mkfs.ext4  -E discard /dev/mapper/ssd-homevol -L home
mkfs.ext4  -E discard /dev/mapper/ssd-varvol -L var
 
# standardmaessig werden immer 5% für root reserviert, auf home brauchen wir das nicht
tune2fs -m 0 /dev/mapper/ssd-homevol
 
# so jetzt kann man sie schon mounten und mit der Installation beginnen
mkdir /mnt/sdb2
mount /dev/ssd/rootvol /mnt/sdb2
mkdir /mnt/sdb2/home
 
mkdir /mnt/sdb2/var
mkdir /mnt/sdb2/boot
mount /dev/sdb1 /mnt/sdb2/boot
mount /dev/ssd/homevol /mnt/sdb2/home
 
mount /dev/ssd/varvol /mnt/sdb2/var
 
# damit die naechsten Schritte aus einem installierten Arch-System (statt archiso) gehen, 
# müssen die arch-install-scripts installiert sein
 
pacstrap /mnt/sdb2 base base-devel syslinux
 
syslinux-install_update -i -a -m -c /mnt/sdb2
 
# das legt uU in /boot/syslinux/ diverse symlinks an, was natuerlich nicht funktioniert,
# wenn die Bootpartition alleine und das Ziel der Links noch verschluesselt ist.
# Also kontrollieren und ggf statt der symlinks die echten dateien einkopieren.
 
# Die erzeugte /boot/syslinux/syslinux.cfg wird man auch kontrollieren und editieren wollen.
# wenn man statt der device -Pfade UUIDs einsetzen will, sieht ein funktionierender Eintrag etwa so aus:
 
LABEL arch
        MENU LABEL Arch Linux
        LINUX ../vmlinuz-linux
        APPEND root=/dev/mapper/ssd-rootvol cryptdevice=UUID=c30af807-1234-1234-1234-5ae7f6803b4d:ssd:allow-discards rw lang=de locale=de_DE.UTF-8
        INITRD ../initramfs-linux.img
 
# fstab erzeugen
#  (-U nutzt die UUID, anschliessend ist Handarbeit angesagt, wg swap etc.
# nuetzlich kommt blkid mit einer Liste aller partitionen und deren Bezeichnungen)
genfstab -U -p /mnt/sdb2 >> /mnt/sdb2/etc/fstab  
 

Anschliessend kann man in das neue System booten und normal installieren...

Und? Ist die SSD wirklich so rasend schnell, bzw. bringt sie überhaupt auf einem älteren Board mit legacy SATA etwas? Und wird die Performance nicht von der Ver-/Entschlüsselung komplett wieder aufgefressen?

Die Stoppuhr sagt: fast doppelt so schnell. Von der alten Platte ist die Kiste in 32sec. beim LoginScreen des KDM und braucht danach noch einmal 18 sec., bis der Desktop sichtbar wird. Von der neuen Platte sind es 16 sec und danach 14.

 

 ich habe es in vorigen Artikeln für debian schon notiert, unter arch sah die Abfolge dann ein wenig anders aus:

# also root
sudo su

# welches /dev/.. ist die neue Platte denn?
fdisk -l

# im Beispiel /dev/sdb. Das zunaechst mit Rauschen fuellen (sonst sehen Angreifer auf den ersten Blick, wo was wohnt
shred -v -n 1 /dev/sdb

# das dauert! eine gute Gelegenheit, mal ins Kino zu gehen, oder die Liebste zu besuchen ...

# dann erst mal 'nen mount point erstellen
mkdir /mnt/schoenerName

# das verschluesselte device einrichten
cryptsetup -c aes-xts-plain64 -y -s 512 luksFormat /dev/sdb

 
# da wird man zweimal nach der PassPhrase gefragt. Je laenger je besser, <11 kann man vergessen
# dann das device oeffnen
cryptsetup luksopen /dev/sdb schoenerName
 
# formatieren 
mke2fs -t ext4 -L schoenerName /dev/mapper/schoenerName

 # und mounten
mount /dev/mapper/schoenerName /mnt/schoenerName

 

# eins noch:
# Jedenfalls bei mir gibt es mit den deviceNames, /dev sdb, /dev/sdc usw, gelegentlich Ärger, plötzlich ist die Platte,

# die beim letzten Boot noch /dev/sdc war, als /dev/sdg in der Liste. Abhilfe schafft die uuid.

 

ls -l /dev/disk/by-uuid/


# da kopiert man sich jetzt die uuid der /dev/sdb 'raus und notiert sich an wohl geschütztem Ort für das nächste Boot diese Abfolge:
 

 

cryptsetup luksOpen /dev/disk/by-uuid/die-rauskopierte-uuid-der-platte schoenerName

1strengGeheimePassPhrase

mount /dev/mapper/schoenerName /mnt/schoenerName

 

 

 

dm-crypt und luks für eine Container-Datei

Wednesday, October 5. 2011

In einem vorigen Eintrag hatte ich die Verschlüsselung kompletter Partitionen und deren Einbindung mit dm-crypt und luks beschrieben, hier als Ergänzung, wie das mit Container-Dateien geht.

# ggf vorbereiten
modprobe loop
losetup -a

#  erstelle 2G container mit zufallsfuellung
dd if=/dev/urandom of=
testfs.bin bs=1M count=2048

# die (leere) Imagedatei auf das naechste freie Loop-Gerät legen, wird angezeigt
losetup -f --show  
testfs.bin

# und zunächst als Partition formatieren
cryptsetup luksFormat /dev/loop0

# dabei wird die Eingabe einer Passphrase verlangt, die gut verschluesselt notieren...

# jetzt kann die Datei-Partition geöffnet werden
cryptsetup luksOpen /dev/loop0 testfs

# mit einem Dateisystem formatiert
mkfs -t ext4 /dev/mapper/testfs

# und schliesslich gemounted werden
mount /dev/mapper/testfs /mnt/testfs

Damit ist ein Dateisystem in einem verschlüsselten Container angelegt und kann benutzt werden. Hier noch mal die Aufrufe im Einsatz, Einbinden und Lösen:

Einbinden:
losetup -f --show 
testfs.bin
cryptsetup luksOpen /dev/loop0 testfs
mount /dev/mapper/testfs /mnt/testfs

Lösen:
umount /mnt/testfs
cryptsetup luksClose /dev/mapper/testfs
losetup -d /dev/loop0

Am Beispiel einer externen Festplatte, die sich nach dem Anstöpseln als /dev/sdc meldet:

fdisk -l
gibt unter anderem:

Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x08040000

Disk /dev/sdc doesn't contain a valid partition table

Die Partition mit ziemlichem Zufall initialisieren und dabei gleichzeitig die Zuverlässigkeit der Platte prüfen:

badblocks -c 10240 -s -w -t random -v /dev/sdc
(dauert ewig.)

Formatieren und mit dem Namen silva einbinden:
luksformat -t ext3 /dev/sdc
cryptsetup luksOpen /dev/sdc silva

Optional die fsck-Frequenz etwas ausdünnen: 
tune2fs -c 1000 /dev/mapper/silva
tune2fs -i 365 /dev/mapper/silva

und ins Dateisystem holen:
mount /dev/mapper/silva /mnt/silva

und zurück:
umount /mnt/silva , falls dass mit device busy hakt, ggf fuser -m /mnt/silva
cryptsetup luksClose /dev/mapper/silva


Mehr Infos

dm-crypt vs. truecrypt:
- beide können einen Container in einer Datei, einer Partition oder einem ganzen device einrichten, beide sind opensource und bier-frei, beide sind schwer genug zu knacken dass es aussichtsreicher ist, das Versteck für den Schlüssel zu finden.
- dm-crypt ist gefühlt paarmal schneller. Bei einem Container mit Passwörtern und Tagebüchern etc. macht das keinen nennenswerten Unterschied, aber bei einer TB-Platte mit der Musiksammlung dann schon.
- dafür hat truecrypt deutlich die Nase vorn, wenn man den Container mal von win*, mal von linux her öffnen möchte
- mit dem Konzept der plausible deniability und hidden volumes hat truecrypt ein Alleinstellungsmerkmal, das unter Umständen den Abstand zwischen Kopf und Kragen regulieren helfen kann.

Vom Einsatz-Szenario her würde ich das Projekte-Device, auf dem unter anderem auch Vorhaben, die unter NDA stehen, gewiss auf dm-crypt legen, dito die Sammlung von vmware und vmbox - Maschinen oder Videos fraglicherer Herkunft.
Die MindMaps, Tagebücher, Liebesbriefe und org/finanzamt wären da eher auf einem trauecrypt-Volumen gut aufgehoben und die Sammlung von Belegen all' der schoflen  Begebenheiten, die irgendwann mal reif für ein Upload nach wikileaks sein wird, käme wohl am besten zu truecrypt in ein hidden volume.

(Page 1 of 1, totaling 4 entries)