| View previous topic :: View next topic |
| Author |
Message |
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5128
Location: Bavaria
|
 Posted: Tue May 12, 2020 5:00 pm Post subject: B4 Verschlüsselung der Festplatte |
 |
|
(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 Du nach dem Lesen von A.4 bemerkt, dass ich kein Freund einer Festplattenvollverschlüsselung bin. Hier meine Erklärung: Weil es Falsch ist !!
(hier ist noch jemand der gleichen Meinung und hat dies ausführlicher begründet: https://linuxinsider.com/story/the-case-against-full-disk-encryption-86774.html )
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.
Edit 2021-03-03: Hier wird auch über Fscrypt gesprochen: https://forums.gentoo.org/viewtopic-t-1129287-highlight-.html
Edit 2021-06-30: Ich wurde erhört !  Siehe den übernächsten Post in diesem Thread
.
Last edited by pietinger on Tue Aug 30, 2022 10:35 am; edited 6 times in total |
|
| Back to top |
|
 |
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5128
Location: Bavaria
|
| Posted: Thu May 14, 2020 2:36 pm Post subject: Alte Methode mit dmcrypt |
|
|
... auf Wunsch ...
Verschlüsselung von home und swap mittels USB-Stick und dmcrypt
Dies ist eine alte - aber höchst sichere - 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 |
Edit 2023-03-09: In Kernel Version 6.1 sind die Crypto-Module verschoben worden in:
| Code: | Cryptographic API --->
Block ciphers --->
[*] AES (Advanced Encryption Standard)
Length-preserving ciphers and modes --->
[*] XTS (XOR Encrypt XOR with ciphertext stealing)
Hashes, digests, and MACs --->
[*] SHA-224 and SHA-256
Userspace interface --->
[*] Hash algorithms
[*] Symmetric key cipher algorithms
Accelerated Cryptographic Algorithms for CPU (x86) --->
[*] Ciphers: AES, modes: ECB, CBC, CTS, CTR, XTR, XTS, GCM (AES-NI)
[*] Hash functions: SHA-1 (SSSE3/AVX/AVX2/SHA-NI)
[*] Hash functions: SHA-224 and SHA-256 (SSSE3/AVX/AVX2/SHA-NI)
[*] Hash functions: SHA-384 and SHA-512 (SSSE3/AVX/AVX2)
[*] CRC32c (SSE4.2/PCLMULQDQ) |
Vorbereitungen
0. Falls Du gerade von A.3 kommst, kannst Du folgendes auslassen. Ansonsten: Wir entfernen temporär den Start von KDE nach dem nächsten boot und starten die Kiste gleich neu:
| Code: | # rc-update del display-manager default
# shutdown -r now |
1. Wir holen das Paket "cryptsetup", geben unserer 4. Partition einen Namen und erstellen einen Mountpunkt für USB-Sticks.
| Code: | # emerge cryptsetup
# parted /dev/sda
> name 4 home
> q
# mkdir -p /mnt/stick |
2. Sticks vorbereiten - mach gleich beide ! Du solltest diese nicht als zusätzlichen Speicher verwenden, daher habe ich auch nur eine (kleine) Partition erstellt. Der Name der Partition ist egal und bedeutet nur: "Partition Mit Master Key" (PMMK). Wenn Du einen anderen Namen vergibst, musst Du das weiter unten anpassen; aber Du MUSST dieser Partition auf beiden Sticks den gleichen Namen geben.
| Code: | - connect your USB stick and wait 3 seconds
# 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 PMMK
> 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/sda2« 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 (weil Du dafür fscrypt verwendest), ließ trotzdem weiter, denn Du musst noch die fstab anpassen. Dies mache ich aber auf einmal im nächsten Kapitel. Du machst also unten beim Punkt 4 (inklusive) weiter, und änderst natürlich nur EINE Zeile in der fstab (welche wohl ).
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. 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=PMMK'
options='-c aes-xts-plain64 -s 512 --allow-discards' |
2. Verschlüssele und formatiere Deine 4. 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 "discard," weg.
| Code: | # cryptsetup -d /mnt/stick/mkey -c aes-xts-plain64 -s 512 --allow-discards create cr /dev/sda4
! type YES in uppercase letters
# mkfs.ext4 -E discard,lazy_itable_init=0,lazy_journal_init=0 /dev/mapper/cr
! wait until finished !!
# umount /mnt/stick |
3. Falls Du gerade von A.3 kommst und Du noch keinen User angelegt hast, kannst Du Dir das umkopieren von /home ersparen und Du machst sofort bei Punkt 4 weiter. Ansonsten: Wenn Du /home bereits benutzt, dann verschiebe es in /oldhome. Falls Du nicht genügend Platz in Deiner root-Partition hast, dann musst Du es auf einen externen Datenträger verschieben:
| 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 your files are complete
# rc-update add display-manager default |
4. Jetzt können wir die Installation abschließen:
| Code: | # rc-update add dmcrypt boot
# nano -w /etc/fstab |
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,nodev,nosuid 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.
Last edited by pietinger on Fri Mar 10, 2023 6:09 am; edited 6 times in total |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5128
Location: Bavaria
|
| Posted: Wed Jun 30, 2021 5:02 pm Post subject: Verschlüsselung von home mit fscrypt |
|
|
... endlich ...
Verschlüsselung von home mit fscrypt
Seit einigen Tagen haben wir ein ebuild für fscrypt und können nun bequem das /home-Verzeichnis damit verschlüsseln. Durch die Anpassung der pam-Profile müssen wir auch nicht das Passwort zweimal eingeben, da mit der User-Anmeldung auch gleichzeitig unser /home-Verzeichnis entschlüsselt wird. Falls Du jetzt fragst, wie wir denn jetzt die swap-Partition verschlüsseln sollen, antworte ich: So wie im vorherigen Post beschrieben (wenn Du nur /swap verschlüsseln willst, benötigst Du ja keinen USB-Stick, da dmcrypt bei jedem Systemstart einen neuen zufälligen Schlüssel dafür verwendet).
Am meisten geholfen hat mir die Konkurrenz mit:
https://wiki.archlinux.org/title/Fscrypt
Daneben kannst Du auch noch einen Blick hier reinwerfen:
https://linuxinsider.com/story/get-no-fuss-file-level-crypto-with-fscrypt-86953.html
https://github.com/google/fscrypt
https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html
Diese Beschreibung ist so verfasst, wie wenn Du gerade von A.3.7 kommst (da wo ich schrieb: Du kannst erstmal pausieren); solltest Du bereits einen User angelegt haben oder Deine /home-Partition bereits erstellt haben, fällt natürlich einiges weg (für das Umkopieren Deiner vorhandenen Daten in Deinem /home lies dann bitte den Link von Archlinux).
Kernel Konfiguration
Das enablen von "FS Encryption" enabled automatisch die benötigten KEYS und Cryptographic APIs (schau' einfach in die Hilfe); da ich einen Intel I7 Gen.6 habe, enable ich aber zusätzlich die dafür optimierten Algorithmen:
| Code: | File systems --->
[*] FS Encryption (Per-file encryption)
Cryptographic API --->
[*] CRC32c INTEL hardware acceleration
[*] SHA1 digest algorithm (SSSE3/AVX/AVX2/SHA-NI)
[*] SHA256 digest algorithm (SSSE3/AVX/AVX2/SHA-NI)
[*] SHA512 digest algorithm (SSSE3/AVX/AVX2)
[*] AES cipher algorithms (AES-NI) |
Edit 2023-03-09: In Kernel Version 6.1 sind diese verschoben worden in:
| Code: | Cryptographic API --->
Accelerated Cryptographic Algorithms for CPU (x86) --->
[*] Ciphers: AES, modes: ECB, CBC, CTS, CTR, XTR, XTS, GCM (AES-NI)
[*] Hash functions: SHA-1 (SSSE3/AVX/AVX2/SHA-NI)
[*] Hash functions: SHA-224 and SHA-256 (SSSE3/AVX/AVX2/SHA-NI)
[*] Hash functions: SHA-384 and SHA-512 (SSSE3/AVX/AVX2)
[*] CRC32c (SSE4.2/PCLMULQDQ) |
Installation
1. Wir bereiten unsere 4. Partition als verschlüsselte /home-Partition vor:
| Code: | # parted /dev/sda
> name 4 home
> q
# mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/sda4
! I have a SSD, therefore -> (skip this with a hdd)
# tune2fs -o discard /dev/sda4
! Now type NOT a NULL
# tune2fs -O encrypt /dev/sda4
? Check with: tune2fs -l /dev/sda4
# nano -w /etc/fstab
=>
[...]
PARTLABEL=home /home ext4 defaults,noatime,nodev,nosuid 0 2 |
2. und holen das fscrypt-Paket (verwende beim emerge NICHT den Parameter "-D"):
| Code: | | # emerge -pv fscrypt |
3. Danach editieren wir zwei pam-Dateien. Füge die drei neuen Zeilen am Ende der jeweiligen Sektion ein. Ich zeige Dir deshalb auch den kompletten Inhalt:
| Code: | # nano -w /etc/pam.d/system-login
add =>
auth optional pam_fscrypt.so
add =>
session optional pam_fscrypt.so
# less /etc/pam.d/system-login
=>
auth required pam_shells.so
auth required pam_nologin.so
auth include system-auth
auth optional pam_fscrypt.so
account required pam_access.so
account required pam_nologin.so
account required pam_time.so
account include system-auth
password include system-auth
session optional pam_loginuid.so
session required pam_env.so envfile=/etc/profile.env
session optional pam_lastlog.so silent
session include system-auth
session optional pam_motd.so motd=/etc/motd
session optional pam_mail.so
-session optional pam_elogind.so
session optional pam_fscrypt.so
# nano -w /etc/pam.d/passwd
add =>
password optional pam_fscrypt.so
# less /etc/pam.d/passwd
=>
auth sufficient pam_rootok.so
auth include system-auth
account include system-auth
password include system-auth
password optional pam_fscrypt.so |
4. Reboote jetzt und melde Dich danach wieder als root an:
5. Du solltest jetzt bei der Status-Abfrage folgendes sehen:
| Code: | # fscrypt status
filesystems supporting encryption: 1
filesystems with fscrypt metadata: 0
MOUNTPOINT DEVICE FILESYSTEM ENCRYPTION FSCRYPT
/ /dev/sda3 ext4 not enabled No
/home /dev/sda4 ext4 supported No |
6. Jetzt starten wir ...
| Code: | # fscrypt setup
Defaulting to policy_version 2 because kernel supports it.
Customizing passphrase hashing difficulty for this system...
Created global config file at "/etc/fscrypt.conf".
Metadata directories created at "/.fscrypt".
# fscrypt setup /home
Metadata directories created at "/home/.fscrypt". |
7. Eine neue Status-Abfrage sollte jetzt so aussehen:
| Code: | # fscrypt status
filesystems supporting encryption: 1
filesystems with fscrypt metadata: 2
MOUNTPOINT DEVICE FILESYSTEM ENCRYPTION FSCRYPT
/ /dev/sda3 ext4 not enabled Yes
/home /dev/sda4 ext4 supported Yes |
8. Fscrypt kann nur leere Verzeichnisse verschlüsseln. Da wir beim Anlegen eines neuen Users aber immer gleich ein paar Dateien in das neue /home-Verzeichnis gelegt bekommen (auch wenn wir den Paramter "-m" nicht benutzen) müssen wir diese erstmal verschieben. Wenn Du nicht Peter heisst, musst Du natürlich noch den Benutzer-Namen anpassen
| Code: | # useradd -g users -G wheel,audio,video,cdrom,usb,cdrw -s /bin/bash peter
# chmod 0700 /home/peter
# passwd peter
# mkdir /tmp/mytmp
# cd /home/peter
# mv .* /tmp/mytmp |
9. Jetzt verschlüsseln wir das neue Verzeichnis. WICHTIG: Du musst Option 1 auswählen. Als Passphrase vergibst Du natürlich wieder Dein Anmelde-Passwort (welches Du gerade in 8. gesetzt hast).
| Code: | # fscrypt encrypt /home/peter/ --user=peter
The following protector sources are available:
1 - Your login passphrase (pam_passphrase)
2 - A custom passphrase (custom_passphrase)
3 - A raw 256-bit key (raw_key)
Enter the source number for the new protector [2 - custom_passphrase]: 1
IMPORTANT: Before continuing, ensure you have properly set up your system for
login protectors. See
https://github.com/google/fscrypt#setting-up-for-login-protectors
Enter login passphrase for peter:
Protector is on a different filesystem! Generate a recovery passphrase (recommended)? [Y/n] n
"/home/peter/" is now encrypted, unlocked, and ready for use. |
10. Verschiebe die Skelett-Dateien zurück:
| Code: | | # mv /tmp/mytmp/.* /home/peter/. |
11. Fertig ! Eine Status-Abfrage sollte Dir folgendes zeigen:
| Code: | # fscrypt status /home/peter/
"/home/peter/" is encrypted with fscrypt.
Policy: 697ce8abe879f49f235d63c56e39f974
Options: padding:32 contents:AES_256_XTS filenames:AES_256_CTS policy_version:2
Unlocked: Yes
Protected with 1 protector:
PROTECTOR LINKED DESCRIPTION
fc0111f561910e74 Yes (/) login protector for peter |
12. Teste es jetzt gleich: Mache einen reboot und melde Dich danach wieder als root an. Schaue dann in dieses Verzeichnis. Du solltest gehashte Datei-Namen sehen und diese nicht öffnen können. Eine Status-Abfrage (wie in 11.) sollte Dir das Gleiche anzeigen mit dem Unterschied => "Unlocked: No"
13. Versuche dann einen manuellen Unlock mit:
| Code: | | # fscrypt unlock /home/peter/ |
(Als Passwort gibst Du natürlich wieder obiges Deines Users ein).
14. Wenn Du Zeit und Geduld hast, machst Du einen letzten Test: Reboote und melde Dich dann mit Deiner User-Kennung an. Du solltest jetzt sofortigen Zugriff auf Deine Dateien in Deinem Home-Verzeichnis haben.
Jetzt gehe wieder zurück nach A.3 und mache dort weiter - aber als User: root. D.H. Du machst ein "exit" und meldest Dich wieder als "root" an. (das Anlegen eines neuen Users brauchst Du jetzt in A.3 natürlich nicht mehr machen).
.
Last edited by pietinger on Thu Mar 09, 2023 12:35 pm; edited 4 times in total |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5128
Location: Bavaria
|
| Posted: Tue Sep 07, 2021 10:35 pm Post subject: |
|
|
Mein Schlusswort zur Festplattenvollverschlüsselung / Full Disk Encryption / FDE
Falls Du das wirklich haben willst, weißt Du auch wirklich wovor es Dich schützt - und wovor nicht ?
Weißt Du auch, dass Du, bei allen mir bekannten Anleitungen, zusätzlich SecureBoot benötigst ?
Warum ?
Weil alle mir bekannten Anleitungen von der Festplatte booten.
Ja, und ?
Es ist völlig egal, ob da ein grub2, ein stub-kernel mit integriertem initramfs, oder sonstein Bootmanager gebootet wird, in allen Fällen gibt es eine Problematik:
Das allererste Programm welches Dein (UEFI-) BIOS lädt ist unverschlüsselt. Muss es auch sein, da kein BIOS irgendetwas entschlüsselt.
Ohne SecureBoot ist FDE aber völlig sinnlos, weil:
Gib mir Dein Notebook mit FDE und ich modifziere Dein allererstes Programm, z.B. grub2, dass es nicht nur seinen eigentlichen Job macht (= Deinen (verschlüsselten) Kernel lädt), sondern zusätzlich gleich mal alle Tastatur-Eingaben auf einen gesperrten Bereich der Festplatte mitschreibt. Da ist dann auch Dein Passwort (um den Kernel / Root-Partition zu entschlüsseln) dabei. Gib mir Dein Notebook wieder und ich greife auf alle Deine verschlüsselten Dateien - mit Deinem Passwort - zu.
Das ganze wäre mir nicht möglich, wenn Du das allererste Programm signierst und SecureBoot einsetzt. Dann prüft SecureBoot ob es verändert wurde (es wird ja der Hash signiert). Falls auch nur ein Byte anders sein sollte, wird SecureBoot dieses Programm nicht starten (und Du weißt dann auch, dass Du gehackt wurdest).
Ohne SecureBoot schützt Dich FDE weder vor OFFLINE TAMPERING, noch vor ONLINE ATTACKEN ... und ist damit komplett sinnlos.
...
Ich habe in A.4. auf eine FDE-Lösung von mir verlinkt (und diese ausdrücklich nicht empfohlen). Diese benötigt kein SecureBoot ! Warum ?
Weil ich komplett von einem USB-Stick boote. Auf diesem ist nichts anderes als ein Stub-Kernel mit integriertem Master-Key. Dieser ist in der Lage eine komplett verschlüsselte Root-Partition zu booten. Das bedeutet: Auf Deiner gesamten Festplatte ist keine einzige unverschlüsselte Datei; weil das allerste Programm eben nicht auf der Festplatte, sondern auf einem USB-Stick liegt. Das bezeichne ich als "echte" Festplattenvollverschlüsselung. (Falls Du eine Swap-Partition hast, kannst Du diese wie in B.4 - Post 2 auch einfach mit dmcrypt verschlüsseln; ich habe gar keine, sondern nur eine einzige große - verschlüsselte - Root-Partition).
Der Unterschied zu allen anderen Anleitungen ist:
1. Du musst diesen USB-Stick immer entfernen (sonst sinnlos),
2. benötigst im Gegenzug aber kein SecureBoot.
...
Ich lese manchmal sehr viel in unserem Forum hier ... die häufigsten Probleme sind ... und ich frage mich dann immer wieder, ob die auch wirklich SecureBoot einsetzen ... ich frage nicht mehr ... sollen sie sich doch in falscher Sicherheit wiegen ... die meisten, die FDE wollen, sind doch eh für einen Geheimdienst uninteressant ... wenn Du aber wirklich ein gefährdeter Journalist bist, dann mache das was ich in A.4 gesagt habe:
Nutze Tails oder QubesOS (*) ... und frage Dich jetzt, warum es wohl auf einen USB-Stick installiert werden muss ...
(*) QubesOS wird von Edward Snowden empfohlen (https://www.qubes-os.org/experts/ , https://de.wikipedia.org/wiki/Edward_Snowden)
. |
|
| Back to top |
|
|
|
|
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
|
|
Deutsches Forum (German) 
