Eos vollverschlüsselung

ich möchte euch eigentlich nicht mit noch einem weiteren beitrag zum thema vollverschlüsselung langweilen, zumal es hier im forum eine sehr gute anleitung dazu gibt - allerdings bezogen auf btrfs und lvm und einer swapfile.

das klingt alles sehr reizvoll, ich bin mir aber nicht sicher, ob ich das wirklich möchte bzw benötige. darum also noch einmal von vorne :wink:

ich liebäugele also mit einer vollverschlüsselung von eos (uefi, gpt, ext4 ssd).

nun ist mein laptop nicht wirklich der neuste und dank meldown und spectre updates hat meine arme i5 ivy bridge sowieso schon arg gelitten. also die erste frage vorab:

lohnt sich der spaß mit vollverschlüsselung überhaupt, oder ist die leistungseinbuße danach eine katastrophe?

partinionieren würde ich vorab mit gparted oder partitionmanager, dann manuell mit calamares installieren (klappt das?).

Summary
 /dev/sda1	/boot/efi	1024mb 		fat32		boot
 /dev/sda2	/boot 		1024mb		ext4
 /dev/sda3	/		    25600mb		ext4
 /dev/sda4 	/home		Rest		ext4
 /dev/sda5 	swap		1024mb 		linux-swap

und da beginnen die fragen auch schon.

  • zu /boot/efi habe ich vor langer zeit (glaube es war auf der refind seite) von einer minimalgröße gelesen, die nicht unterschritten werden sollte. es war ein kruder wert, glaube um die 775 mb. da platz nicht mehr die oberste priorität ist, habe ich 1024 mb dafür gewählt.

  • über die notwendigkeit von /boot in bezug auf eine vollverschlüsselung im jahr 2020 bin ich mir nicht wirklich sicher? man liest immer wieder, es sei ein relikt aus vergangenen tagen, wo diese unverschlüsselte partition absolut geboten war.

  • swap oder swapfile oder gar nicht? ich habe aus sentimentalität mal eine swap partition hinzugefügt, die aber wohl mehr als placebo dient, denn in aktion habe ich sie noch nie gesehen. ram sei dank.

habe ich noch etwas essentielles vergessen / gibt es noch etwas zu beachten?

herzlichen dank für euer interesse

Du kannst ohne extra /boot partition und wenn gewünscht auch mit seperater /home partition eos komplett verschlüsselt installieren. Ob mit swap und der option für hibernate ist dir überlassen, es kann auch nachträglich swap-file eingesetzt werden, dann ohne swap installieren und nachträglich swap-file konfigurieren.

Was die Systemgeschwindigkeit angeht sehe ich keinen großen Verlust an verschlüsselten Systemen.
Und wenn es sich um ein Notebook handelt das mobil ist kann eine Verschlüsselung schon zu deiner Sicherheit beitragen, bei Diebstahl z.B.

Dein i5 sollte keine performance Probleme mit der Verschlüsselung machen, ganz alte core2 Prozessoren mit nur 2 Kernen sind da etwas schwächer… ich habe ein altes Thinkpad mit 4GB Ram und einem schnellen Dualcore mit Vollverschlüsselung und das geht auch ohne große Einbußen.

1 Like

danke joe,

dann werde ich definitiv auf /boot verzichten! habe momentan noch so ein layout, da mir das immer als grundbedingung für eine eventuelle (spätere) verschlüsselung im kopf herumgeisterte. alles relikte :slight_smile:

swap partition vs datei, gibt es da unterschiede? falls datei, muß es dann zwingend auf /home sein? vielleicht mache ich bei root die 30gb voll und lege sie dann dort an. eigentlich benutze ich hibernate nicht - ist es von der swapgröße abhängig oder was eigenständiges?

gut das zu wissen, was die performance angeht. ich hatte irgendwo mal etwas von einbußen bis zu 30% auf älteren systemen, wahrscheinlich dann core2, gelesen.

noch etwas in sachen clonezilla:

beim wiederherstellen von luks2 verschlüsseltem /boot/efi und /root muß ich mir doch keine sorgen das passwort betreffend für das ebenfalls verschlüsselte /home machen, oder?

was ist, wenn man aus irgendeinem grund das backup nicht wiederherstellen kann, dann ist /home mit sicherheit verloren, sehe ich das richtig?

ach so, noch was grundlegendes: man wird dann immer im grub 1x nach einem passwort gefragt, das wars? du siehst, es ist echt das erste mal :wink:

genauso wie wenn du /home seperat hast und das backup nicht herstellen kannst… :wink:
Was du meinst ist sicher das wenn /home eine seperate Partition ist kannst du diese auch einfach einzeln wieder herstellen und entschlüsseln… das stimmt,

Backups sind nur dann sicher wenn es mehrere verschiedene varianten auf verschiedenen Festplatten – Speichern gibt.

wenn du nicht seperat verschlüsselst wird nur einmal vor dem Grub start nach dem Entschlüsselungspassword gefragt genau. Wenn ich mich richtig erinnere ist das auch so wenn das selbe Password für seperate Partitionen verwended wird habe ich jetzt aber nicht genau im Kopf.

Könnte ich testen…

1 Like

Du solltest nur einmal gefragt werden. Das Passwort bzw. die Passwörter weiterer zu entschlüsselnden Partitionen, die du selbst gewählt hast, spielen allerdings keine Rolle. Diese kannst du durchaus variieren. Bei der Installation werden i. d. R. automatisch weitere Schlüssel (key files) zu deinen LUKS Partitionen hinzugefügt, damit dein System diese nach der ersten Entschlüsselung mit deinem Passwort ohne dein weiteres Hinzutun entschlüsseln und einhängen kann. Manuel einrichten ist aber auch kein Problem.

Siehe evtl. auch Antwort auf ähnliche Frage.

1 Like

nicht ganz, wenn es unverschlüsselt ist, sind die daten ja noch abrufbar. wenn nun aber verschlüsselt…

natürlich sollte man immer auf backups bauen, aber in dem fall ist man trotz intakter daten ausgesperrt :wink:

klasse, da war ich mir nicht sicher. hatte gelesen, jede partition muß einzeln entsperrt werden. so wie du es beschreibst, kann man ja sogar mehrere passwörter einplanen.

noch etwas wichtiges:

bezieht sich nocheinmal auf einbußen, sollte aber dank ssd auch auf meinem system keine probleme machen.

wie sieht es mit aufnahmen & latenzen in audacity aus? hat da jemand erfahrungen mit einem ähnlichen rechner? clicks, aussetzter usw wären schon ein manko.

glaube zwar fest, das dies möglich ist: ab und zu überprüfe ich alle partitionen auf fehler mit gparted bzw partitionmanager im livemodus.

wie genau funktioniert das dann mit einem komplett verschlüsselten system? wird man beim zugriff auf die ssd bzw den partitionen vorab vom jeweiligen programm (also auch clonezilla etc) nach dem passwort gefragt und kann dann ganz normal fortfahren?

Du solltest beim Bootvorgang ein einziges Mal dein Passwort eingeben müssen, danach müssten alle weiteren Partitionen automatisch entschlüsselt werden.
Die Verschlüsselung ist absolut transparent, d. h. alle deine Programme funktionieren wie sonst auch; wie gesagt, du musst nur beim Start das System einmal freischalten.

Mach dir wegen Latenz und generellen Leistungsverlust keine Sorgen. Ich verschlüssele alle meine Geräte seit über einem Jahrzehnt stets “voll”. War damals schon auch auf schwächeren CPUs meist kein Problem und ist heute erst recht keines. Du wirst es höchstwahrscheinlich überhaupt nicht merken.

1 Like

der start ist also immer die hürde, danach steht jedem system (live usw) die tür offen. dank dir.

habe gerade gesehen, daß meine cpu AES New Instructions unterstützt. das ist doch in dem zusammenhang sicher relevant?

Deine Hardware ist nicht das Problem …:vulcan_salute: Go for it!

Die Erstinstallation ist zugegeben für Neuverschlüsseler eine “kleine” Hürde. Nicht wirklich schwer aber oft sind doch auch manuelle Schritte notwendig.

Einfachste Variante: Du kannst das System komplett mit Calamares (dem EOS Installer) verschlüsseln, hast dann aber keine getrennte /home Partition. Siehe Wiki.

Wenn es getrennte Partitionen sein sollen, kannst du unter anderem auf kleinschrittige Anweisungen hier im Forum zurückgreifen. Siehe BTRFSonLUKS oder LVMonLUKS

1 Like

danke für den hinweis. schade, daß calamares+/home manuell noch nicht so weit ist.

ich hätte jetzt so begonnen wie in post1 (bzw wie von joe angedeutet)?

eine getrennte /home partition ist mir wichtig. bei einer sicherung bzw wiederherstellung möchte ich nicht immer die ganze platte auswählen müssen (nur sda1+2). home spiegel ich dann. eine swapfile lege ich vielleicht noch nachträglich in /root an.

Summary
/dev/sda1	/boot/efi	 1024 mb	fat32		boot
/dev/sda2	/	        30720 mb	ext4
/dev/sda3 	/home		 Rest mb	ext4

die beiträge bin ich zuvor schon mal durchgegangen, verliere mich aber in den vielen details, die für mein “simples” vorhaben gar nicht relevant sind. vielleicht hast du ja noch ein, zwei gezielte tipps für mich? :slight_smile:

Leider ist eine getrennte /home Partition ohne viele dieser Details nicht hinzubekommen.

Du kannst die Tutorials jeweils ab einer bestimmten Stelle abbrechen, wenn es nur auf /home ankommt.

LVMonLUKS bis #16
BTRFSonLUKS bis #05

Kann man stur abtippen/kopieren. Sollte weniger als zehn Minuten Mehrarbeit bedeuten.

1 Like

ich denke, ich werde mich noch sehr viel mehr einlesen müssen, ehe ich das umsetzte.

danke euch beiden ersteinmal bis hierhin.

kurze rückmeldung:

ich habe mich nun für eine komplette neuinstallation inkl. neuer partitionierung & verschlüsselter /home partition via calamares entschieden. die installation verlief übrigens mit ventoy ohne probleme.

login funktioniert einwandfrei (1x passwortabfrage für sda3) und wird bei falschem passwort wiederholt.

mich macht diese einmalige systemfehlermeldung aber stutzig:

Failed to open key file.
Failed to activate with key file ‘/crypto_keyfile.bin’. (Key file missing?)

Eigentlich macht die Fehlermeldung nichts, weil Dein System ja funktioniert. Beseitigen würde ich sie trotzdem.
Schau, ob in Deinem /-Verzeichnis diese Datei liegt. Außerdem schau nach, ob in der Datei /etc/crypttab auf diese Datei verwiesen wird. Wenn die Datei nicht dort liegen sollte und in der Crypttab eine Zeile mit Verweis auf diese Datei drin sein sollte, dann kommentiere diese Zeile mit # in der Crypttab aus.
Aber Achtung! Ggf. startet danach Dein System doch nicht mehr. Du solltest Dir daher erst einen USB-Stick für ein Live-System zur Rettung bereitlegen und dann wissen, wie Du die auskommentierte Zeile in der Crypttab wieder aktivieren kannst.

schönen dank für deine hilfe.

was mich wundert - die calamares installation war reibungslos - wie also kommt es zu dem fehler?

außerdem - ist die datei denn nicht obligatorisch für eine verschlüsselung, bzw kann man sie nachträglich nicht noch generieren?

/crypto_keyfile.bin existiert bei mir nicht - aber /etc/crypttab enthält einen eintrag mit luks…, uuid… und /crypto_keyfile.bin luks

morgen habe ich mehr zeit und ruhe, melde mich dann nocheinmal.

du sagst es.

ich mußte die zeile in crypttab wieder aktivieren, denn das system bootet nicht, wenn auskommentiert.

Ups!
Bitte poste den Inhalt von /etc/crypttab und /etc/fstab
Vermutlich muss die Zeile in der Crypttab so angepasst werden, dass das Passwort im normalen Boot-Prozess abgefragt wird.
@2000: Hast Du noch eine Idee, was da passiert sein kann?

fstab’s /dev/mapper/luks-xxx und crypttab’s luks-xxx sind identisch.

Summary

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=xxx                            /boot/efi      vfat    umask=0077 0 2
UUID=xxx                            /              ext4    defaults,noatime 0 1
/dev/mapper/luks-xxx                /home          ext4    defaults,noatime 0 2
tmpfs                               /tmp           tmpfs   defaults,noatime,mode=1777 0 0
#
# selbst eingetragen:
#
/swapfile none swap defaults 0 0
#
tmpfs                                     /home/xxx/.cache   tmpfs   defaults,noatime,mode=1777 0 0



                                                                                          
# /etc/crypttab: mappings for encrypted partitions.
#
# Each mapped device will be created in /dev/mapper, so your /etc/fstab
# should use the /dev/mapper/<name> paths for encrypted devices.
#
# See crypttab(5) for the supported syntax.
#
# NOTE: Do not list your root (/) partition here, it must be set up
#       beforehand by the initramfs (/etc/mkinitcpio.conf). The same applies
#       to encrypted swap, which should be set up with mkinitcpio-openswap
#       for resume support.
#
# <name>               <device>                         <password> <options>
luks-xxx               UUID=xxx                        /crypto_keyfile.bin luks

noch etwas - /boot/efi flags mußte ich trotz auswahl in calamares nach der installation händisch mit gparted von msftdata zu boot,esp ändern. warum auch immer?

Da du ja nur sda3 (/home) verschlüsselt hast, darf bzw. sollte /crypto_keyfile.bin auf keinen Fall auf sda2 existieren.
Diese Datei wird i. d. R. ja als Schlüssel generiert und auch in deiner verschlüsselten Partition als Schlüssel (Slot 1) eingetragen. Da sda2 allerdings unverschlüsselt ist, wäre es keine besonders gute Idee dort einen Schlüssel zu hinterlassen.

Du entsperrst sda3 beim Booten ganz normal mit deinem, beim Erstellen hinterlegtem, Passwort.

Wie der Eintrag in /etc/crypttab gelangt ist, ist allerdings ein Rätsel.


Versuch doch bitte noch einmal folgendes:

  1. Auskommentieren in /etc/crypttab
  2. Gefolgt von …
sudo mkinitcpio -p linux
sudo grub-mkconfig -o /boot/grub/grub.cfg
  1. Neustart

Mit mkinitcpio -p linux erstellen wir ein neues Kernel-Image ohne Verweis auf die nicht existente Datei. Die Fehlermeldung müsste dann verschwinden.

1 Like

Ah, Mist!
Das hatte ich oben vergessen. Deshalb hat es vermutlich nicht funktioniert.

1 Like