Wie verschlüsselt man vollständig und richtig unter Linux?

Sicherheit
, , ,
1

Hallo zusammen! Bei der Installation bei Linux Mint bekommt man ja die Möglichkeit direkt zu verschlüsseln, wenn man das System neu installiert. Ich habe dazu ein paar Fragen, wobei die technischen Guides mich mehr verwirren als mir helfen.

  1. Wenn ich LVM + Luks anklicke, wird dann die gesamte Festplatte verschlüsselt?

  2. Warum habe ich die Möglichkeit nochmal extra den Homefolder zu verschlüsseln, wenn ich bereits LVM + Luks angewählt habe? Wird dieser bei Punkt 1 nicht mit verschlüsselt?

  3. Ist die Verschlüsselungsmethode Luks sicher oder hat sie bekannte Hintertüren?

  4. Ich habe in Foren gelesen das der Bootloader nicht verschlüsselt wird. Warum ist das wichtig zu wissen bzw. schwächt das meine Verschlüsselung?

  5. Ich habe öfters gelesen, wenn eine SSD verschlüsselt wird, dann wird die TRIM Funktion deaktiviert was dadurch die Lebensdauer von der SSD und die Schreib bzw. Lesegeschwindigkeit stark reduziert. Stimmt das? Falls ja, macht es dann noch Sinn eine Festplatte zu verschlüsseln auf die man jeden Tag zugreift für Filme, Musik, Spiele und so weiter?

  6. Ich habe öfters gelesen bevor man eine Festplatte verschlüsselt, soll man sie mit zufälligen Werten komplett überschreiben, wenn es sich um eine HDD handelt. Warum keine SSD? Warum? Wenn eine Festplatte verschlüsselt wird, dann sollte man doch nichts mehr lesen können ohne passenden Schlüssel oder nicht?

  7. Wenn ich ein Virtuelles System auf einer verschlüsselten Festplatte installiere, habe ich ja wieder die Möglichkeit zu verschlüsseln. Macht das Sinn? Ist der Bootloader dann wieder unverschlüsselt oder wie? Das verwirrt mich etwas.

  8. Wo wird der Key gespeichert der meine Festplatte entschlüsselt? Soweit ich es verstanden habe wird der unverschlüsselt im Ram gespeichert bis er nicht mehr gebraucht wird. Ich nehme an in einen virtuellen System wird er dann im dafür allokierten Rambereich gespeichert? Also auch im Ram? Habe ich das richtig verstanden?

  9. Ich habe öfters gelesen eine verschlüsselte Festplatte soll keinen Swap haben, weil der anscheinend auch nicht verschlüsselt wird. Stimmt das und wie kann man verhindern dass ein Swap erstellt wird? Ich habe noch nie eine Option bei der Linux Mint Installtion dafür gesehen. Meiner Recherche im Netz nach ist der Swap in Linux in etwa das, was die Auslagerungsdatei in Windows ist. Also wenn der Ram voll ist wird auf die Festplatte geschrieben, oder?

Ja also das ist mir erst einmal eingefallen und ich freue mich auf hilfreiche Antworten. Mein Ziel ist es erstmal zu verstehen wie die Dinge funktionieren die ich verwende und darauf dann aufzubauen. Direkt mit Fachartikeln zugeknallt werden hilft mir leider garnicht, auch wenn sie wahrscheinlich technisch korrekt sind.

2

Hallo @Salatpilz,
ich mach mal den Anfang und versuche ein paar Unklarheiten zu beseitigen

Soweit ich weiß zählt LUKS(dm-crypt) zu den sichersten Methoden dein System zu verschlüsseln. Mir ist keine Hintertür (Schwachstelle) bekannt. Die Software ist OpenSource und wenn eine Schwachstelle bekannt wird, dann wird sie auch geschlossen. Kann natürlich immer sein, dass irgendjemand eine Schwachstelle gefunden hat, die niemandem sonst bekannt ist. Aber das würde mich nicht davon abhalten mein System mit LUKS zu verschlüsseln.

Wenn der Bootloader nicht verschlüsselt ist, könnte ein Angreifer sehr einfach einen Keylogger installieren. Sobald du das nächste mal dein Passwort (Passphrase) eingibst, weiß der Angreifer also dein Passwort und hat Zugriff auf deine Dateien. Soetwas betrifft die wenigsten, aber wenn ich politischer Aktivist wäre und Angst davor hätte, dass die Polizei an meine Daten gelangt, dann würde ich mir Gedanken machen, wie ich mit dem Bootloader umgehe.
Wenn du nur sicher gehen willst, dass bei einem Diebstahl deine Daten sicher bleiben und nicht in Fremde Hände geraten, kannst du den Bootloader auch unverschlüsselt lassen.

3

Bei Debian und Derivaten wird bei der Option LVM + Luks in der Regel die Systempartition verschlüsselt während die /boot-Partition unverschlüsselt ist.

Auf einem Notebook habe ich openSUSE Tumbleweed installiert, da es zum Zeitpunkt des Kaufs das einzige Open-Source OS war, das die Hardware voll unterstützte. Da ist es so, das auch /boot verschlüsselt wurde.

4

Das komplette System mit Ausnahme der Boot-Partition.

Ist dafür gedacht, wenn mehrere Leute mit unterschiedlichen Benutzern das System verwenden, damit Nutzer A nicht auf das Home-Verzeichnis von Nutzer B zugreifen kann.

Zitat aus dem Privacy-Handbuch:

dm-crypt/LUKS ist FIPS-2 zertifiziert, wird vom BSI regelmäßig evaluiert und ist in Deutschland und NATO zur Speicherung von Daten bis VS-GEHEIM zugelassen

Eine unverschlüsselte /boot partition ermöglicht es Angreifern den Kernel, den Bootloader und andere wichtige Dateien zu verändern.

Woher hast du denn diese Information?
Die TRIM-Funktion ist für das sichere Löschen der SSD zuständig. Diese Funktion muss man manchmal erst aktivieren.

Wenn man befürchtet, dass die Festplatte schon kompromitiert war und die Daten bei einer Neuinstallation des OS nicht komplett gelöscht werden, kann man das machen um eventuelle schädliche Restdateien zu entfernen. Bei SSDs werden aber mit dieser Methode nicht alle Speicherzellen garantiert gelöscht. Ob sowas notwendig ist, muss man selbst entscheiden (in 99% der Fälle ist es aber nicht notwendig).

Kommt auf das Angriffsszenario an. Sobald du das virtuelle System startest und dich anmeldest sind die Daten entschlüsselt. Danach ist auch jeglicher Zugriff vom Hostsystem aus möglich. Dass heißt, wenn das Hostsystem kompromitiert ist, ist es auch die VM.

Der einzige Schutz würde darin bestehen, dass, wenn die VM noch verschlüsselt ist und dein PC im laufenden Betrieb beschlagnahmt wird, der Angreifer nicht auf die Daten in der VM zugreifen kann.

Das ist richtig, wenn das System entschlüsselt wurde, befindet sich der Key im unverschlüsselten RAM sofern du keinen vPro oder Ryzen Pro Prozessor besitzt.
Ansonsten befindet sich der gehashte Key im LUKS Header.

Wenn ich mich nicht irre, existiert swapping trotzdem, nur wird es weiterhin unverschlüsselt auf die Festplatte geschrieben.
Es wird daher empfohlen Swap zu verschlüsseln und den Kernel anzuweisen, es nur zu verwenden wenn es absolut notwendig ist.

1 „Gefällt mir“
5

  1. Neuere GRUB Versionen erlauben eine verschlüsselte Boot Partition.

  2. und 6.: TRIM erzeugt Bereiche mit Nullen auf der SSD, die Aufschluss geben können, wie die Platte genutzt wird. Wenn die SSD nicht überschrieben wird, können sich alte Daten noch darauf unverschlüsselt befinden (auf einem Server evtl. auch vom vorherigen Kunden) oder es gibt Informationen über die Menge an verschlüsselten Bytes. Ist alles überschrieben mit Zufall, kann es sich auch um Datenmüll handeln.

  3. Zum Auslesen aus dem RAM werden root-Rechte benötigt. Mit diesen Rechten ist eh Zugang zu allen Daten möglich.

  4. Es gibt verschlüsselten Swap, der mit einem Zufallspasswort zwischen jedem Boot neu initialisiert wird.

LUKS sichert nur Daten@Rest. Schon der unbeobachtete Rechner im Suspend hebelt einen Großteil des möglichen Schutzes aus. z.B. kann der Speicherinhalt über DMA ausgelesen werden.

6

Nein, das macht man um eine Plausible Deniability zu haben. Kurzum, kann jemand der die Festplatte analyisiert, nicht sehen, wo genau die Daten liegen. Da bei /dev/random die Festplatte komplett mit Datenschrott überschrieben wird. So kann ein Forensiker nicht sehen, auf welchem Teil der Festplatte „echte“ Daten liegen. Somit erschwert es einen Angriffsvektor auf Teilbereiche zu finden.
https://en.wikipedia.org/wiki/Deniable_encryption

Das ist auch nicht korrekt. In der Regel sollte der SWAP die größe des RAMs haben. Zudem sollte man natürlich auch den SWAP des Systems komplett mit LUKS verschlüsseln. So kann auch ein Angreifer dort nichts mehr auslesen.
https://wiki.archlinux.org/title/dm-crypt/Swap_encryption

Das einzige große Problem an der Verschlüsselung ist, sie ist nur sicher, wenn das System ausgeschaltet ist. Von Side Channel Angriffen (z.b cold boot) usw, reden wir hier gerade nicht.
https://en.wikipedia.org/wiki/Cold_boot_attack

7

ZRAM macht am meisten Sinn für den Durchschnittsnutzer. Dabei wird quasi ein Swap mit Komprimierung im RAM erstellt, also nie auf die Festplatte geschrieben.Wenn man sehr große Mengen Auslagerungsdatei braucht, bietet sich ZSWAP an, was den in-memory Swap mit einer Auslagerungsdatei ergänzt.

8

Okay, das macht mehr Sinn (aber ich würde behaupten die Verschlüsselung der Boot-Partition und eine Verfied-Boot Implementation ist wichtiger, als die Erschwerung, Teilbereiche zu finden, aber dass muss man selbst entscheiden).

Was war an meiner Aussage denn nicht korrekt? Swap existiert trotzdem und ist unverschlüsselt, daher sollte man ihn verschlüsseln. Stand in meinem Post und in deinem hast du es nochmal bestätigt.

Bei Punkt 8 war indirekt die Rede von Side-Channel-Attacks/Cold-Boot:

9

„Wenn ich mich nicht irre, existiert swapping trotzdem, nur wird es weiterhin unverschlüsselt auf die Festplatte geschrieben.“

Es wird nicht unverschlüsselt angelegt. In der Regel bei keiner der gängigen Distris. Weder mit LUKS(dm-crypt) noch mit ZFS. Von daher ist die Aussage falsch.

Verified Boot? Secure Boot?
Sowas in der Art?
https://www.heise.de/hintergrund/Secure-Boot-und-Startverbote-unter-Linux-9672292.html?seite=all (kostenpflichtig)
Danke. Aber nein Danke. Damit die Leute aus Redmond noch mehr Einfluss bekommen.

10

Okay, da waren meine Informationen veraltet. Schön dass das die meisten Distributionen mittlerweile umgesetzt haben.

Das Microsoft angeblich plant die Benutzer von ihren Computern mittels Secure-Boot auszusperren, indem sie nur von Microsoft genehmigte Software ausführen dürfen und somit Linux nicht mehr lauffähig wäre, ist eine falsche Behauptung die sich vor allem im deutschsprachigen Raum festgesetzt hat.

Die Wahrheit ist, Secure Boot stellt die Integrität des Basissystems und der Boot-Kette sicher, um Angriffe durch bösartige Maids und die Persistenz von Malware zu verhindern.
Auszug von Madaidans Blog:

Verified boot ensures the integrity of the boot chain and base system by cryptographically verifying them. This can be used to ensure that a physical attacker cannot modify the software on the device.

Fairer Weise muss man noch hinzufügen, dass Secure-Boot keine vollständige Implementation von Verfied-Boot ist sondern nur den Bootloader und den Kernel verfiziert.

Man kann bei fast jedem Gerät (mit Ausnahme von ein paar OEMs) Microsoft Secure Boot Third-Party Certificate Authority aktivieren womit man dann seine eigenen Keys verteilen kann.

Und der von dir erwähnte Artikel von Heise spekuliert nur, ob Linux gesperrt werden soll.
Zitat aus dem Artikel:

Bis Redaktionsschluss Anfang April 2024 bekamen wir keine Antwort, ob Linuxsysteme von den bevorstehenden zusätzlichen Sperrungen betroffen sein könnten oder nicht.

11

Also stellst Du somit in Abrede, welchen Einfluss Microsoft auf die Entwicklung hat? Und all die Big Player im Linux Segment wie RedHat, Suse, Ubuntu und Co lagen alle falsch, dass die OEMs teilweise das durchgesetzt haben, was MS vorgeben hat? Interessant. Aber Danke, nun habe ich verstanden wie Secure-Boot funktioniert :wink:

Auch Interessant ist, dass Du immer wieder maidaidans github repo verlinkst… Wenn ich mehr Zeit habe, kommt gerne noch mal ausführlich was zu dem anderen Thread…

Aber… vielleicht in Kürze, bevor mir die Zeit weg rennt…
"For example, if a remote attacker has managed to exploit the system and gain high privileges, verified boot would revert their changes upon reboot and ensure that they cannot persist. "
Ref: https://madaidans-insecurities.github.io/guides/linux-hardening.html#verified-boot

Das ist ja regelrecht grandios. Fast wie Magie. Ein infiltriertes System braucht man einfach nur rebooten und der Spuk ist vorbei. Fraglich, warum dann selbst in Enterprise Companies, wo nachweislich Secure Boot auf den Systemen lief, sogar mit der Windows Pest, der ganze Betrieb regelrecht lahmgelegt wurde.
Ganz nach IT-Crowds Manier: „Have You Tried Turning It Off And On Again?“
Ref: https://youtu.be/nn2FB1P_Mn8?t=12

Ganz ehrlich… Besser nicht. Da sollte man dann doch lieber auf andere Quellen verweisen wie z.B CIS, DISA-STIG und vielleicht noch nen Verweis auf SCAP
Refs:
https://public.cyber.mil/stigs/
https://www.cisecurity.org/
https://csrc.nist.gov/projects/security-content-automation-protocol
Oder halt selbst wissen, was man da macht, nicht macht, oder lieber ganz lässt

Just my two Groschen … :smiley:

12

Hammer oder? Und schon seit Jahren Realität in Smartphones unter Android und iOS. Es gibt sogar zuverlässige Remote Attestation.

Konnte nicht den ganzen Artikel lesen, da Paywall, aber in dem Abschnitt der sichtbar war, sagt Heise, dass sie nicht wissen, ob überhaupt und welche Linux-Systeme dadurch unbootbar werden. Red Hats-Systeme funktionieren noch und Arch mit UKI+secure Boot ebenfalls. Im Notfall kann man auch immer noch secure Boot temporär ausschalten und anschließend ein UKI+Secure Boot erstellen. Ist also kein großes Ding. Dass Microsoft hier gravierende Lücken schließt ist ja prinzipiell etwas gutes. Deshalb auf Secure Boot verzichten zu wollen, macht mMn keinen Sinn.

Und wo genau widerspricht da etwas dem Gesagten?

13

Dass Microsoft einen Einfluss auf die Entwicklung hat, habe ich nicht bestritten, nur dass die Behauptung ‚Microsoft will das kein Linux mehr bootet‘ (wie auch der Heise Artikel impliziert) falsch ist.
Und dass ein paar OEMs das Ausrollen von eigenen Schlüsseln unterbinden steht ebenfalls in meinem Post.

Weil es nach wie vor eine gute Quelle ist.

Vielleicht weil diese Angriffe nichts mit Secure Boot zu tun hatten? Secure Boot allein ist kein Allheilmittel, sondern Teil eines sinnvollen Gesamtkonzeptes (wie z.B. bei Android).