Verschlüsselung nachträglich umsetzen

für normale Benutzer

Gegeben 

Eine ganz normale Linux Installation (im Beispiel Ubuntu 18.10; für Ubuntu 20.04 Focal Fossa ebenso),
Ziel: das "home" oder eine Datenablage in eigener Partition (Zielpartition)
Bisher sind keine Laufwerke verschlüsselt.
GRUB ist nicht quiet, nicht silent (wg fehlerhaftem Plymouth)

Vorbereitung

Soll der komplette, eigene mountpoint  /home verschlüsselt werden, ist ein Start von einer Live-DVD / USB-Gerät ratsam. Dazu gleiche OS-Distro und -Version benutzen.
Das /home muss in einer eigenen Partitionen liegen, ggf. verschieben (Gparted funktioniert einfach und sicher).

LUKS installieren 
	sudo apt-get install cryptsetup

Zielstellung:


Eine Lösung

Nachträglich verschlüsseln mit LUKS, nur den Bereich.

Vorteil:

Das Vorgehen:
  1. Daten von der Zielpartition 2x sichern (Original geht unter)
  2. Aufsetzen von LUKS auf der Zielpartition
  3. Mapping erzeugen, für unverschlüsselten Zugriff
  4. Dem Mapping einen Namen geben, zum mounten
  5. Ein Dateisystem auf dem neuen "Laufwerk" erzeugen
  6. Einen mount point erzeugen
  7. Automatisches Entschlüsseln und mapping durch den Kernel veranlassen: Eintrag in die crypttab
  8. Mount in die fstab eintragen
  9. Dateien aus der Sicherung zurückkopieren in die neue Crypt-Partition.
Fertig.

Gute Literatur

und viele weitere ...

Backup and recovery:
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery




Die Schritte im einzelnen:

0. Darstellung im Beispiel

<device> = /dev/sda3
<name> = luks-56956....0ab51

Die Namen in Beispielen sind evtl. nicht konsistent (von verschiedenen Computern).

1. Sichern:

Wie gewohnt, bitte 2x, weil die Originaldateien untergehen.
In unserem Beispiel sei es die /dev/sda3
Löschen ist nicht erforderlich.

2. Aufsetzen von LUKS auf der Zielpartition

Die bestehende Partition, auf der bisher die Daten waren, wird wiederverwendet.
Erzeugt wird hier ein neuer LUKS Container.  
generisch: cryptsetup luksFormat <device>
sudo cryptsetup  luksFormat -s 256 -y  -c  twofish /dev/sda3
Rückfragen mit y / ja beantworten.
Es gibt mehrere Typen von Schlüsseln, die bereitstehen (nicht alle denkbaren by default; Ubuntu 20.10: --cipher twofish-ecb wird IMHO nicht mehr korrekt unterstuetzt).

Es besteht die Möglichkeit, den Schlüssel als key file zu übergeben, statt interaktiver Password-Abfrage. Diese Option wird in der man page ausführlich dargelegt. Aus Erwägung von Zuverlässigkeit und Sicherheit  wird hier auf Abfrage beim booten gesetzt (unvorteilhaft wäre: USB-Stick versagt oder wird mit-beschlagnahmt;  hier fand ich eine kurze Anleitung zur Nutzung von key-files).

Nun haben wir LUKS aufformatiert in unsere Zielpartition.

Prüfen

Stimmt das Ergebnis?
Verifiziere, dass erfolgreich ein LUKS System da ist:
generisch: cryptsetup -v isLuks <device>
sudo cryptsetup -v isLuks /dev/sda3
Das zeigt "Command successful" bzw. "Befehl erfolgreich.", wenn -v oder --verbose als Option (sonst echo $?)

Zeige Details zur Überprüfung an:
generisch: cryptsetup luksDump <device>
sudo cryptsetup  luksDump  /dev/sda3

3. Mapping erzeugen

Erzeuge ein Mapping (eine Zuordnung), um den Zugriff auf die entschlüsselten Inhalte des Geräts zu ermöglichen.
Ein Mapping ist wie ein normales, unverschluesseltes block device (z.B. Festplatte).
Dies macht das Gerät über Mapping zugänglich (eine eingebaute Kernelfunktion!)

Den device name in Form einer UUID ermitteln: 
generisch: cryptsetup luksUUID <device>
sudo cryptsetup luksUUID /dev/sda3

4. Dem Mapping einen Namen geben

Aus der UUID wird der neue Name erstellt, Muster: luks-[UUID]
Dieser wird für das mapping benutzt: 
generisch: cryptsetup luksOpen <device> <name>
sudo cryptsetup luksOpen /dev/sda3 luks-595682c3-cb1f-4315-a20c-db20bfa1bc42
Achtung: Das Mapping ist selbst kein mount!

Prüfen

Dieses mapping muss nun vorhanden sein, Aufruf: 
cryptsetup -v isLuks <device>
sudo cryptsetup -v isLuks /dev/sda3
(Antwort "Command successful." bzw. "Befehl erfolgreich.") und mit  
	ls -latr  /dev/mapper/
die Bezeichnung prüfen.

Es sollte jetzt einen device node (Geräteknoten) geben, 
/dev/mapper/<name> 
der das entschlüsselte Gerät darstellt.



Dieses block device (Blockgerät) kann wie jedes andere unverschlüsselte Blockgerät gelesen und geschrieben werden.

Prüfen des neuen device node: 
generisch: dmsetup info <name>
sudo dmsetup info luks-595682c3-cb1f-4315-a20c-db20bfa1bc42
Hier wird ein Bericht zurückgegeben: 
Name:              luks-595682c3-cb1f-4315-a20c-db20bfa1bc42
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      253, 0
Number of targets: 1
UUID: CRYPT-LUKS1-595682c3-cb1f-4315-a20c-db20bfa1bc42-luks-595682c3-cb1f-4315-a20c-db20bfa1bc42

5. Ein Dateisystem erzeugen

Formatieren

Das fertige device wird formatiert, um ein Dateisystem zu bekommen: 
generisch: mke2fs /dev/mapper/<name>
sudo mkfs.ext4  -v   -c  -L home0home_crypt  /dev/mapper/luks-595682c3-cb1f-4315-a20c-db20bfa1bc42
hier mit -L volumelabel hat eine Länge von 16bytes (1-4bytes per char...).
Ausgabe beobachten.

6. Einen mount point erzeugen

Testweise das neue device (Gerät) wie ein normales device auf einen mountpoint mounten: 
generisch: mount /dev/mapper/<name> /mnt/test
sudo mount /dev/mapper/luks-595682c3-cb1f-4315-a20c-db20bfa1bc42 /mnt/test/
und mit 
mount
das Ergebnis prüfen (Beispiel):
/dev/mapper/luks-595682c3-cb1f-4315-a20c-db20bfa1bc42 on /mnt/test type ext4 (rw,relatime,data=ordered)
Anschliessend un-mounten (Aushängen).


7. Eintrag in die crypttab

Das device (Gerät) wird durch einen Eintrag in die (ggf. neu zu schaffende) /etc/crypttab entschlüsselbar und beim Booten zugeordnet, bevor anhand der fstab es gemountet (eingehängt) wird. Das wird vom OS ohne weitere Installation von Tools erledigt!

Hier besteht die Möglichkeit, das zum Entschluesseln erforderliche password in einer Datei zu hinterlegen (ggf. USB Stick?) oder ein Password abzufragen.
Gezeigt wird die Option Passwordabfrage.
Editor aufrufen
sudo vim /etc/crypttab
In /etc/crypttab: 

generisch: <name>  <device>  none options   (alle 4 Felder erforderlich)
luks-69fe88d8-00o0-9b76-qr20-f242a64a9320    UUID="69fe88d8-00o0-9b76-qr20-f242a64a9320"    none    luks,tries=5,timeout=3000
„none“ im dritten Feld, dem "key field", ist für interaktives password / kein keyfile (Schlüsseldatei).
Diese Parameter funktionieren gut, mehr dazu in der man page für crypttab.

Hinweis

Damit die Password-Abfrage erkennbar ist, sollte kein "silent" oder "quiet"  in der Grub-Konfiguration wirksam sein.

Bekanntes Problem: Die Password-Abfrage bleibt am unteren Bildschirmrand unsichtbar. Wahrscheinlich ein Bug in Plymouth (z.B. #1731769 und viele weitere).
Abhilfe: Enter drücken (unschädlich). 


An dieser Stelle ist ein Neustart sinnvoll, wenn nicht von Live-DVD gearbeitet wird.

8. Mount in die fstab eintragen

Das entschlüsselte device wird in /etc/fstab eingetragen, um beim Booten gemountet zu werden:
Editor aufrufen
sudo vim /etc/fstab
Eintrag
/dev/mapper/luks-69fe88d8-00o0-9b76-qr20-f242a64a9320 /home ext4    rw,users,defaults    0 2

An dieser Stelle ist ein Neustart erforderlich, wenn nicht von Live-DVD gearbeitet wird.

Das entschlüsselte device nun über den Ziel-Mountpoint mounten
sudo mount /mnt/home

Prüfen


Mit 
mount
muss  die "neue" Partition sichtbar werden, im Beispiel erscheint 
/dev/mapper/luks-595682c3-cb1f-4315-a20c-db20bfa1bc42 on /home type ext4 (rw,relatime)

9. Daten zurückkopieren

Die a.O. gesicherten Daten auf /home zurückspielen.


An dieser Stelle ist ein Neustart in das normale System erforderlich.



Prüfen und Wartung

Die Integritätsprüfung mit e2fsck geht auf das NICHT gemountete, entschlüsselte device: 
generisch: e2fsck  /dev/mapper/<name>
sudo umount /dev/mapper/luks-595682c3-cb1f-4315-a20c-db20bfa1bc42
sudo e2fsck -cvf /dev/mapper/luks-595682c3-cb1f-4315-a20c-db20bfa1bc42
respektive
sudo btrfs check /dev/mapper/luks-595682c3-cb1f-4315-a20c-db20bfa1bc42

Die Intervalle für vollautomatische extn- filesystem checks (Prüfungen) beim booten werden analog mit tune2fs eingestellt.
Verifikation: 
sudo tune2fs -l /dev/mapper/luks-f0cbbdc2-8252-434f-8c24-898cea30c36a
setzen: 
sudo  tune2fs -c 4 -i 1w  /dev/mapper/luks-595682c3-cb1f-4315-a20c-db20bfa1bc42

Zusammenfassung der typischen Tests

sudo cryptsetup -v isLuks /dev/sda3  (it verifies the header!)

sudo cryptsetup  luksDump  /dev/sda3  (shows entire header info)

sudo dmsetup info <name>  (info on the mapped device)

look into /dev/mapper/    
look into /etc/crypttab
look into /etc/fstab
optional: look at /etc/crypttab.initramfs

generisch:  blkid -p <device>
sudo  blkid -p /dev/sda4

Unmount = close

1) Das Gerät (device) unmounten:
sudo umount /dev/mapper/luks-595682c3-cb1f-4315-a20c-8d48bfa0ab51
2) Das LUKS-Mapping beenden (close the luks-mapping)

Verifikation

Mit "dmsetup info" den vorher und den nachher Status überwachen: 

sudo dmsetup info /dev/mapper/luks-595682c3-cb1f-4315-a20c-8d48bfa0ab51
zeigt vorher
Name:  luks-595682c3-cb1f-4315-a20c-8d48bfa0ab51
....

Mapping schließen (luksClose)

sudo cryptsetup -v luksClose luks-595682c3-cb1f-4315-a20c-8d48bfa0ab51

Password ändern, zurückziehen

Es können mehrere Passwörter (parallel) in "slots" vergeben und auch wieder gelöscht werden.
Auch hier kann die key-Phrase von einer Datei kommen, siehe man page für cryptsetup.

Einen Überblick (mit root Rechten) über die Nutzung der slots 0 bis 7 gibt 
	cryptsetup luksDump <device>
Anm: Version 2 hat eine umfangreichere (unuebersichtlichere) Darstellung, hier auf das Wort "slot" bzw. "Keyslots:" achten.


Zum Hinzufügen eines Passwords wird luksAddKey benutzt. 
	generisch: cryptsetup luksAddKey <device>
	
	sudo cryptsetup luksAddKey /dev/sdb3
	Enter any existing passphrase: 
	Enter new passphrase for key slot: 
	Verify passphrase:
Es gibt keine Ausgabe, welcher slot für welches Password benutzt wurde.  


Löschen eines Passwords: 
Vorsicht: Man kann damit den letzten Zugang fuer immer loeschen. Siehe man page!

Backup

Das Backup der Daten (Nutzdaten) kann aus dem entschlüsselten Gerät erfolgen.

Wichtig ist die Möglichkeit, den sog. Header des verschlüsselten LUKS-Containers zu sichern (Vorsicht: Diese Header-Sicherung gesichert aufbewahren, Missbrauch möglich).
Detaillierte Backup Hinweise sind in der man page auffindbar.

Backup des Headers

eines LUKS crypt Containers

generisch: cryptsetup luksHeaderBackup --header-backup-file <file> <device>
oder
generisch: cryptsetup luksHeaderBackup /dev/<device> --header-backup-file /mnt/<backup>/<file>.img
mit
<device> ist die Partition, die das LUKS volume (<device> = /dev/sda3) enthält.



Restore Header 

generisch: cryptsetup luksHeaderRestore --header-backup-file <file> <device>
Header testen ohne zu schreiben mit der --header Option:
cryptsetup --header <file> luksOpen <device> </dev/mapper/luksname>
Erfolgskriterium: Das abgefragte Password wird akzeptiert.
Im Detail siehe:   https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery



Resize a LUKS partition

A)
GParted ab ca. Version 0.32.0 kann fuer ext3, ext4 sämtliche Schritte selbst übernehmen
Wichtig: Voraussetzung ist, dass das Mapping aktiv ist, jedoch KEIN mount des Mappings zu einem Mountpoint besteht.
Simple Umsetzung: LUKS-Laufwerk vollstaendig mounten, dann umount auf den Mountpoint, pruefen, ob /dev/mapper das mapping weiter anzeigt. 
Bei btrfs kann manuelles Aendern der Partition über parted erforderlich sein.
Resize in gParted übernimmt alle Prüfungen und setzt die maximale Ausdehnung - es sei denn, es erkennt die neue Geometrie nicht korrekt. Dann Pech.
Zum Partitionen ändern sollte man vom separaten Medium starten, schon wegen der swapoff - Problematik in extended partitions.

B)
Idea:
resize partition > resize LUKS > resize2fs > DONE.

Overview:
First the area has to be unmounted and unmapped by luksClose! \\ First I booted into a different Linux. Then I enlarged with gparted (0.30.0 on Fedora27). GParted recognises the LUKS correctly \\ cryptsetup resize only works after mapping the device, see man page! and it works perfect. \\ finally do resize2fs on the device (represented by the mapping). Asks for a e2fsck first, fine!

Make backup for data on partition.

Boot separate Linux (e.g. Fedora27)

Start GParted. Unmount and swapoff all devices on the HD.
Increase size of LUKS-partition.

Check LUKS-partition is still valid (Header!): 
        sudo cryptsetup -v  isLuks /dev/sda14

Check for existing mappings
        ls -latr /dev/mapper/

Else map the device (using interim name fressluke instaed of proper luks- .....) : 
        sudo cryptsetup -v luksOpen /dev/sda14 fressluke
        ls -latr /dev/mapper/

Resize the LUKS
LUKS has to be mapped for resizing.  We work on the virtual device (partition).  
        sudo cryptsetup -v resize fressluke
or (other example)
	sudo cryptsetup -v resize  /dev/mapper/luks-595682c3-cb1f-4315-a20c-8d48bfa0ab51
Expected answer: "Command successful." bzw. "Befehl erfolgreich."

Filesystem remediation:

LUKS has to be mapped and unmounted!
        sudo e2fsck -fv  /dev/mapper/fressluke 
        sudo resize2fs /dev/mapper/fressluke

Now test-mount the „new“ device (partition)
        mount /dev/mapper/fressluke /mnt/test/
check mount with 
        mount 
        ls -latr /mnt/test/
Works fine!

UUID is the same like before, right?
        sudo cryptsetup -v  luksDump  /dev/sda14
Yes, no adaption should be necessary in fstab and crypttab.


------- end -----------


ipv6 test








G