Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
B4 Verschlüsselung der Festplatte
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Deutsche Dokumentation
View previous topic :: View next topic  
Author Message
pietinger
Guru
Guru


Joined: 17 Oct 2006
Posts: 418
Location: Bavaria

PostPosted: Tue May 12, 2020 5:00 pm    Post subject: B4 Verschlüsselung der Festplatte Reply with quote

(Dieser Post ist Teil einer Installation-Anleitung. Falls nicht schon geschehen lies bitte: Installation Guide for Paranoid Dummies)



B.4 Verschlüsselung der Festplatte

Falls Du A.4 nocht nicht gelesen hast, bitte ich Dich dringend, dies jetzt gleich nachzuholen (bevor Du weiter liest) =>
https://forums.gentoo.org/viewtopic-t-1112894-highlight-.html

Möglicherweise hast nach dem Lesen von A.4 bemerkt, dass ich kein Freund einer Festplattenvollverschlüsselung bin. Hier meine Erklärung: Weil es Falsch ist !!


Integritäts-Management

Verschlüsselung ist kein Ersatz für eine ordentliche Integritäts-Prüfung (die Sicherheitsexperten unter Euch wissen das genauso und können diesen Teil gerne überspringen). Oder sollte es zumindest nicht sein. Verschlüsselung ist für Daten da; nicht für Binaries oder System-Einstellungen. Lasse mich kurz (grob) erklären, wie es sein sollte:

Nachdem Du den Part (A) komplett installiert hast, gibst Du dem Kernel (oder einem dafür verantwortlichen Programm) die Information/Befehl, sich den aktuellen Stand zu merken: Für alle ausführbaren Programme und wichtige Dateien aus /etc werden dann die Hash-Werte berechnet und gespeichert. Dieser Stand wird an einer Stelle gespeichert die unveränderlich und unerreichbar für alle anderen Menschen ist - egal ob sie mit CDROM (USB-Stick) booten, die Festplatte ausbauen oder das BIOS kurzschließen um da reinzukommen. Häh - wo soll das sein ?

Früher gab es nur eine Stelle: Ein Speicher-Medium welches entfernt werden kann (und wurde), z.B. eine Diskette (schau mal bei WikiPedia nach, was das ist); heute könnte es auch ein Stick sein. Das war ... nervig. Und so erfand man das TPM. Ein Ort wo nur der Kernel nachsehen darf, welche Werte drin sind. Aber nicht irgendein Kernel, sondern nur der, von dem sicher ist, dass es der richtige - von Dir installierte - ist. Dazu muß er signiert sein, damit Dein PC prüfen kann ob es der Originale ist (das nennt man SecureBoot). Wenn ja, bekommt er alle Hash-Werte zurück (im Detail ist es anders) und kann ab sofort prüfen, ob Deine "bash" und Deine "fstab" im Original-Zustand sind. Wenn diese verändert wurden, wird er Dich warnen und die Bash nicht starten. (wenn Du eine neue bash installierst, musst Du natürlich wieder bescheid geben, dass dieser neue Stand i.O. ist)

Falls jemand einen anderen Kernel über USB bootet, bekommt dieser vom TPM keine Daten - basta. Gut, er könnte dann alles mögliche in Deinem Root-Verzeichnis ändern. Aber er kann die passenden Hash-Werte im TPM (oder auf der entfernten Diskette) nicht so anpassen, dass sie zu seinen installierten Programmen passen. Sobald Du Deinen PC startest - mit Deinem sauber signierten richtigen Kernel - wird dieser sofort Alarm geben (und Du darfst dann Dein System neu installieren). Ach ja, wenn ein Angreifer versucht, Deinen echten Kernel auch noch auszutauschen, startet Dein PC nicht, weil er merkt dass die Signatur falsch ist.

Was ist jetzt der Unterschied zu einem verschlüsselten Root-Verzeichnis ? Da kann mir doch auch niemand etwas installieren, wenn ich nicht da bin, weil /root ja verschlüsselt ist. Stimmt - wenn Dein PC ausgeschaltet ist. Nicht aber wenn Dein PC eingeschaltet ist und Verbindung ins Internet hat ... und ein Angriff aus dem Netz auf Deinen PC erfolgreich war !

Dann kann folgendes passieren: Du hast mit Deinem Browser eine böse Seite erreicht, die einen Bug in Deinem Browser ausnutzt und diesen veranlasset etwas auszuführen, was Dein Browser normalerweise nicht tun würde. Dieser böse Teil merkt aber, dass Dein Browser in einer Sandbox läuft und keinen Zugriff auf Deine Daten hat. Deshalb versucht es jetzt einen Bug im Kernel auszunutzen um nicht als User "sandbox" sondern als "root" zu laufen (https://de.wikipedia.org/wiki/Rechteausweitung). Dann tauscht es die installierte "bash" gegen seine eigene Version. Du hast von alldem gar nichts bemerkt. Demnächst startest Du ein Terminal-Fenster und dann werden urplötzlich alle Deine Daten aus dem /home verschlüsselt um Dich damit zu erpressen. (In diesem Beispiel, siehst Du auch, wie wichtig ein gehärteter Kernel ist, denn ohne ausnutzbaren Kernel-Bug funktioniert das nicht so einfach / gar nicht.) Eine ordentliche Integritäts-Prüfung läuft nicht nur beim Systemstart, sondern laufend, und hätte Dich das Terminal-Fenster gar nicht starten lassen, sondern Alarm gegeben.

Fazit: Eine Festplattenvollverschlüsselung schützt nur gegen Offline-Angriffe. Wenn der PC aus ist und Du nicht da bist. Ein verschlüsseltes Root-Verzeichnis ist dagegen ungeschützt sobald Du angemeldet bist.

Wieso haben wir also keine ordentliche Integritäts-Prüfung ? TPM gibt es nun doch schon seit vielen Jahren ... IMA und EVM sind doch auch schon im Kernel ?

Dazu will ich eigentlich nichts sagen, nur soviel: Wenn Unternehmen nicht für den Kunden, sondern aus Eigeninteresse etwas entwickeln, passiert folgendes: Die, die es unbedingt benötigen versuchen andere Lösungen zu finden und die, die es gebrauchen könnten, lassen es ganz sein, weil es den Aufwand nicht wert ist UND alle LINUX-User die man aussperren wollte, haben viele Jahre Verzug und nutzen heute noch eine Krücke namens Festplattenvollverschlüsselung.


Verschlüsselung von /home

Ja ... ähm ... eigentlich wollte ich Dir hier eine schöne, neue und aktuelle Lösung präsentieren, die aktiv weiterentwickelt wird und bei Android schon im Einsatz ist: Fscrypt. Leider warte ich schon seit Monaten darauf dass Gentoo ... :-(

Hier der Link zur Konkurrenz:
https://wiki.archlinux.org/index.php/Fscrypt
Sieh auch hier:
https://github.com/google/fscrypt

Es gibt bereits diverse (tlw. uralte) Lösungen, die aber leider alle nicht sehr empfehlenswert sind. eCryptfs wird auch nicht mehr aktiv weiter entwickelt und kann ich deshalb nicht mehr empfehlen. Weißt Du was, warten wir einfach noch ein paar Tage ...

... und dann wird das hier von mir ergänzt sobald wir das ordentlich emergen können, statt zu basteln.


Last edited by pietinger on Mon Jun 01, 2020 10:02 am; edited 1 time in total
Back to top
View user's profile Send private message
pietinger
Guru
Guru


Joined: 17 Oct 2006
Posts: 418
Location: Bavaria

PostPosted: Thu May 14, 2020 2:36 pm    Post subject: Alte Methode mit dmcrypt Reply with quote

... auf Wunsch ...



Verschlüsselung von home (und swap) mittels USB-Stick

Dies ist eine alte Lösung, die nur dmcrypt verwendet und kein LUKS (auch kein LVM). Dein Stick ist der einzige Schutz vor dem Auslesen von /home. Wird Dein Notebook mit dem Stick gestohlen, existiert kein Schutz. Deshalb empfehle ich dringend, diesen nach dem Booten - gleich beim Erscheinen des Logins - abzuziehen und in einer Tasche zu verstauen ... Nein - nicht die Notebook-Tasche :-)

Ein USB-Stick wird als "/dev/sdX" eingebunden. Heutige Festplatten sind beinahe ausnahmslos SATA-Platten und werden deshalb ebenfalls als "/dev/sd", statt wie früher als "/dev/hd" eingebunden. Steckst Du einen Stick vor dem Einschalten des PCs an, kann Deine Festplatte als /dev/sdb statt /sda eingebunden werden. Steckst Du Deinen Stick erst bei Aufforderung ein, ist es genau umgekehrt. Um den Zeitpunkt des Einsteckens zu egalisieren, verwenden wir ausschließlich Labels (oder die UID). Solltest Du bereits einen Stub-Kernel verwenden und "root=/dev/sdXY" in der "Built-in kernel command line" haben, ändere es trotzdem auf die Verwendung mit UID, so wie unten beschrieben.

Verwende bitte wirklich zwei Sticks und stecke den zweiten danach in den Safe. Sticks können gerne mal defekt gehen. Ohne einen Ersatz kannst Du sonst nur noch auf Dein Backup von /home hoffen - auf Deiner Platte ist der Inhalt von /home sonst unwiederruflich verloren !

Kernel Konfiguration

Die Option "Built-in command line overrides boot loader arguments" ist (stand:heute) bei Verwendung des Grub notwendig. Eine andere Möglichkeit wäre, den Grub umzukonfigurieren wie hier beschrieben (aber wenn Du eh schon in der Konfig bist, ist das halt das schnellste und einfachste):
https://forums.gentoo.org/viewtopic-t-1111788-highlight-.html
Im Kernel musst Du folgendes fest eingebunden haben (nicht als Modul):
Code:
Processor type and features  --->
 [*] Built-in kernel command line
  (root=PARTUUID=abcdefgh-1234-1234-1234-abcdefgh1234 ro) Built-in kernel command string
 [*]   Built-in command line overrides boot loader arguments

Device Drivers --->
 [*] Multiple devices driver support (RAID and LVM)  --->
 [*]   Device mapper support
 [*]     Crypt target support
 
Cryptographic API --->
 [*]   XTS support
 [*]   SHA1 digest algorithm (SSSE3/AVX/AVX2/SHA-NI)
 [*]   SHA256 digest algorithm (SSSE3/AVX/AVX2/SHA-NI)
 [*]   SHA512 digest algorithm (SSSE3/AVX/AVX2)
 [*]   SHA224 and SHA256 digest algorithm
 [*]   AES cipher algorithms
 [*]   AES cipher algorithms (AES-NI)
 [*]   User-space interface for hash algorithms
 [*]   User-space interface for symmetric key cipher algorithms


Vorbereitungen

1. Wir holen das Paket "cryptsetup", geben unserer 5. Partition einen Namen, erstellen einen Mountpunkt für USB-Sticks und entfernen temporär den Start von KDE nach dem nächsten boot. Nimm aber noch nicht "dmcrypt" in das Runlevel "boot" auf (das kommt erst später).
Code:
# emerge cryptsetup
# parted /dev/sda
> name 5 home
> q
# mkdir -p /mnt/stick
# rc-update del xdm default

2. Sticks vorbereiten - mach gleich beide ! Du solltest diese nicht als zusätzlichen Speicher verwenden, daher habe ich auch nur eine (kleine) Partition erstellt. Wenn Du einen anderen Namen vergibst, musst Du das weiter unten anpassen; aber gib beiden Sticks wenigstens den gleichen Namen.
Code:
- connect your USB stick
# lsblk --fs
# blkid
! check if /dev/sdb is really your stick; (probably it is /dev/sdc or /sdd if you have more than one hd or ssd; then use this instead of sdb in the next commands)
# parted -a optimal /dev/sdb
> mklabel gpt
> unit mib
> mkpart primary 1 2
> name 1 crypto
> q
# mkfs.fat -F 32 /dev/sdb1
- change your sticks and start with parted again for the second stick


Key auf dem Stick erstellen

Stecke einen Deiner beiden Sticks ein und lasse diesen drin, bis ich Dich um einen Wechsel zum anderen bitte.
Code:
# mount -t vfat /dev/sdb1 /mnt/stick
# dd if=/dev/random of=/mnt/stick/mkey bs=1 count=64


Swap verschlüsseln

Wir könnten zwar alles auf einmal in der /etc/conf.d/dmcrypt editieren. Ich mache es jedoch in zwei Schritten, falls Du (so wie ich) gar kein Swapping benutzen solltest. Dann fällt dieses Kapitel natürlich komplett weg.

1. Gehe in o.g. Datei zur Stelle der Swap partitions, und editiere die beiden letzten Zeilen wie folgt (falls Du in A.1 bei der Partitionierung Deiner Festplatte andere Namen vergeben hast, musst Du natürlich Deine Namen verwenden). Ändere nicht die Reihenfolge in dieser Datei - ändere nur dort wo es bereits steht:
Code:
#--------------------
# dm-crypt examples
#--------------------

## swap
# Swap partitions. These should come first so that no keys make their
# way into unencrypted swap.
# If no options are given, they will default to: -c aes -h sha1 -d /dev/urandom
# If no makefs is given then mkswap will be assumed
swap=crypt-swap
source='PARTLABEL=swap'

2. Da wir swap schon mal in Benutzung hatten, gibt es eine einmalige Warnung, die wir jetzt gleich "abholen" und und mit der Eingabe von "YES" erledigen:
Code:
# swapoff -a
# /etc/init.d/dmcrypt start
dmcrypt           | * Caching service dependencies ...                                                                           [ ok ]
[...]
dmcrypt           |WARNING!
dmcrypt           |========
dmcrypt           |Gerätesignaturen auf »/dev/sda3« erkannt. Wenn Sie fortfahren, könnte das bestehende Daten beschädigen.
dmcrypt           |
dmcrypt           |Are you sure? (Type uppercase yes): YES                                                                       [ ok ]
dmcrypt           | *     pre_mount: mkswap /dev/mapper/crypt-swap ...                                                           [ ok ]
---
# /etc/init.d/dmcrypt stop

3. Falls Du nur die Swap-Partition verschlüsseln willst (?) und nicht auch /home, ließ trotzdem weiter, denn Du musst noch die fstab anspassen. Dies mache ich aber auf einmal im nächsten Kapitel.

Home verschlüsseln

Theoretisch könnten wir alles vom dmcrypt-script erledigen lassen. Da Du aber vermutlich schon Daten in Deinem vorhandenen Home-Verzeichnis hast, gehe ich etwas anders vor. Du solltest trotzdem sicherheitshalber eine aktuelles Backup von Deinem /home machen / gemacht haben. Zuerst bereiten wir alles vor, booten den PC, so dass Du auf der Kommando-Zeile statt in KDE (SDDM) landest, dort kümmern wir uns dann um das vorhandene /home und kopieren alles um. Zuletzt booten wir noch einmal um alles zu prüfen. Lasse Deinen Stick ruhig drin, so siehst Du gleich ob im Kernel und der fstab alles auf Label (und UID) umgestellt ist. Wenn nicht, könnte es sein, dass der Systemstart nicht funktioniert.

1. Editiere /etc/conf.d/dmcrypt an der Stelle die bereits vorgegeben ist, wie folgt. Wenn Deine Festplatte KEINE SSD ist, lasse den Parameter "--allow-discards" weg.
Code:
 ## /home with regular keyfile on removable media(such as usb-stick)
target=crypt-home
source='PARTLABEL=home'
key='/mkey'
remdev='PARTLABEL=crypto'
options='-c aes-xts-plain64 -s 512 --allow-discards'

2. Verschlüssele und formatiere Deine 5. Partition WENN dies Deine leere home-partition ist. Passe ansonsten den Befehl an ! Wenn Deine Festplatte KEINE SSD ist, lasse die Parameter "--allow-discards" und "-E discard" weg.
Code:
# cryptsetup -d /mnt/stick/mkey -c aes-xts-plain64 -s 512 --allow-discards create cr /dev/sda5
! type YES in uppercase letters
# mkfs.ext4 -E discard /dev/mapper/cr
# umount /mnt/stick
# shutdown -r now

3. Melde Dich als Root an und führe das folgende aus:
Code:
# mkdir /oldhome
# cd /oldhome
# mv /home/* .
# /etc/init.d/dmcrypt start
# mount /dev/mapper/crypt-home /home
# rsync --stats --progress --numeric-ids -axAhHSP /oldhome/ /home/
! go into your home and check if all files are allright
# cd
# /etc/init.d/dmcrypt stop
# rc-update add dmcrypt boot
# rc-update add xdm default
# nano -w /etc/fstab

4. Editiere Deine /etc/fstab und ersetzte für die vorhandenen home- und swap- Partition das "PARTLABEL=..." mit "/dev/mapper/..."
Code:
/dev/mapper/crypt-swap   none      swap    sw                 0 0
/dev/mapper/crypt-home   /home     ext4    defaults,noatime   0 2

5. Führe einen Reboot aus und prüfe ob alles i.o. ist. Falls ja, löscht Du das "/oldhome" aus dem root-Verzeichnis. Jetzt solltest Du noch die Datei "mkey" vom Stick irgendwo in Dein home-Verzeichnis kopieren (welches ja verschlüsselt ist und daher zur Aufnahme des "mkey" geeignet). Danach diesen 1. Stick unmounten und raus. Den 2. Stick rein, mounten und "mkey" auf den 2. Stick kopieren. Umount und raus und in den Tresor. :-)


Nochmals: Dies ist nicht meine Ziel-Lösung für das Home-Verzeichnis.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Deutsche Dokumentation All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum