[Aufgegeben] Echte Full Disk Encryption

[cosinus]

und bei Tests komplett und gründlich versagt.

Hier möchte ich nochmal nachhaken. Bitte verlinke mal diese Tests, die du meinst.
Ich hatte letztes Jahr u.a. mit @MSfree über passwortgesicherte Platten/SSD gesprochen und auch er war da der Meinung, dass es nicht unmöglich aber extrem aufwändig sei, so ein Passwort zu umgehen. [ viewtopic.php?p=1329918#p1329918 ]

[MSfree]

Ich hatte letztes Jahr u.a. mit @MSfree über passwortgesicherte Platten/SSD gesprochen ...

Ich halte die Passwortsicherung nicht für ideal.

Einerseits ist die Sicherung umgehbar, indem man z.B. einen neuen Controller nutzt. Im einfachsten Fall besorgt man sich eine baugleiche, nicht gesperrte Platte und nimmt dessen Platine und steckt sie auf die geschützte Platte. Damit wird man aber wahrscheinlich scheitern, weil die Hersteller auch wissen, daß das zu einfach wäre. Ggfls. sind Lötmaßnahmen nötig, um Chips, auf denen sich die Firmware befindet, auf der Platine auszutauschen.

Datenrettungsfirmen sind im Besitz von Informationen, wie man an gesperrte Daten rankommt, wenn ein Passwortschutz existiert. Die habe zwar ein NDA mit dem Hersteller unterzeichnet, aber was Rettungsfirmen können, können subversive Subjekte auch, im Zweifel besorgen die sich die nötigen Informationen beim Datenretter per Einbruch in deren IT.

Wenn es um Industriespionage oder Geheimdienste geht, stellt die Sperre per Passwort keine Hürde dar. Ich würde so einer Sperre auch nicht so weit trauen, wie ich die Platte werfen könnte.

Eine gesperrte Platte läßt sich nicht weiterverkaufen, die funktioniert beim Abnehmer nämlich nicht. Also muß man sie entsperren und deren Inhalt löschen, bevor man sie verkaufen kann.

Verschlüsselte und nicht gesperrte Platten sind aus vielerlei Gründen sinnvoller. Sollte einem so einem Platte abhanden kommen (Diebstahl des Notebooks), hat der neue "Besitzer" zwar funktionierende Hardware, kann aber nicht an die Dateien ran. Auch kann eine verschlüsselte Platte einfach veräußert werden, der Abnehmer muß halt neu partitionieren und formatieren (und ggfls. neu verschlüsseln), kann aber die Hardware problemlos weiternutzen.

[cosinus]

Ich halte die Passwortsicherung nicht für ideal.

Es war nicht die Rede davon, dass das eine 10000% sichere Nummer ist. Ich finde aber die Diskussionen hier tw. merkwürdig oder gehts auch in diesem Thread darum, dass man Daten vor Geheimdiensten und Industriespionage schützen muss? Der 0815-Dieb wird von einem 0815-Debian-User doch nicht so einen Aufwand fahren um an private Mails, Bilder und Video zu kommen.

Ich halte so ein Disk-Passwort für eine gute Alternative zwecks Absicherung. Und wenn man will kann man es ja immer noch mit LVM/LUKS kombinieren, dann ist ein unverschlüsseltes /boot auch nicht mehr das große Problem bzw. Thema.

(BTW: im Zweifel gilt eh xkcd und der 5$ wrench )

[rhHeini]

und bei Tests komplett und gründlich versagt.

Hier möchte ich nochmal nachhaken. Bitte verlinke mal diese Tests, die du meinst.

I am sorry, kann ich nicht und will ich nicht. Das ist mein knapp 70-jährige Lebenserfahrung bzw. das angesammelte Wissen aus vielen Artikeln z.B. aus der c't und anderen Zeitschriften, dem Internet etc. Ich bleib dabei, für mich taugt das nicht. luks macht genau das was ich will.

Und so ein gesetztes ATA-Passwort oder eine Platte mit eingebauter angeblicher Verschlüsselung ist nebenbei nicht automatisch hochfahrbar wie die Entschlüsselung von luks-Devices gegen einen externen Schlüssel auf OS-Ebene.

[cosinus]

//edit: irrelevant

[speefak]

Zusätzlich: dem Ansatz vertraue ich in keinster Weise. Dazu haben sich zu viele Akteure auf dem Markt mit grossen Versprechungen hervorgetan und bei Tests komplett und gründlich versagt.

Nein, es geht nicht am Thema vorbei, es ist eine Alternative. Aber hier im DFDE wollt ihr immer eine 200%-Lösung auch wenn die einfache Lösung, nämlich das Disk-Passwort, in den allermeisten Fällen schon ausreicht. Vllt mal dran denken, dass nicht hinter jedem der Mossad her ist.

Der Mossad vllt nicht aber die NSA Wenn ich das so lese ist hier eine gewisse Beratungsresistenz zu erkennen.
Das BIOS PW ist wie bereits genannt nicht sicher ( gut das muss jeder selbst wissen ). Wenn es nun aber um Datenkonsistenz und Kompatibilität geht ist LUKS die einzige Alternative:

1. Platte kann einfach neu formatiert werden
2. Platte kann an anderen Systemen entsperrt werden
3. LUKS ist die einzige 100%tige Lösung
4. Was erwartest du sonst in einem Debian Forum ? 10% Mumpitz ?

"Der 0815-Dieb wird von einem 0815-Debian-User doch nicht so einen Aufwand fahren um an private Mails, Bilder und Video zu kommen"
=> Und in Zeiten von KI hat die Gegenseite sehr mächtige Werkzeuge und da wäre ich mir mit o.g. Aussage nicht so sicher.

[cosinus]

DDas BIOS PW ist wie bereits genannt nicht sicher ( gut das muss jeder selbst wissen ).

Ich weiß nicht, wer hier vom BIOS-Passwort spricht - ich jedenfalls nicht.
Ich meine das Disk-Passwort. Auch bekannt als NVMe-Passwort oder ATA-Security-Feature. Dabei wird das Passwort direkt in der Disk gesetzt. Und so eine Disk lässt sich ohne das korrekte Passwort nicht mehr ansprechen, man kann dort weder etwas lesen noch drauf schreiben. Auch nicht wenn du diese Disk rausrupfst und in einem anderen Computer einbaust.

[speefak]

Ok Ich war beim BIOS Passwort, es mag sein, das es aktuell neue "Features" gibt. Dennoch würde ich auf Kompatibilitätsrüden immer zu LUKS raten.

Gibt bei der SSD direkt Verschlüsselung auch die Funktionen von LUKS ?

- 8 Passwort Slots
- Passwort ohne formatierung änderbar
- Encryption Header separat sicherbar
- Möglichkeit langer Passwörter und Nutzung sämtlicher Sonderzeichen ?

[niemand]

Hier gibt’s eine ganz gute Übersicht: https://wiki.archlinux.org/title/Self-encrypting_drives

OT: du plenkst.

[cosinus]

Gibt bei der SSD direkt Verschlüsselung auch die Funktionen von LUKS ?

Das Disk-Passwort ist als schnelle Sicherung gedacht, die Disk wird damit gesperrt, die Daten selbst sind nicht verschlüsselt. Natürlich nicht 1000%ig sicher, aber auch LUKS ist nicht 1000%ig sicher. Ich nenn es aber gern als Alternative v.a. für User, die sich nicht mit LUKS beschäftigen wollen kann das sinnvoll sein. Man kann es auch mit LUKS kombinieren weil man idR bei LUKS ja immer noch ein unverschlüsseltes /boot hat.

Für mein Notebook und Desktop reicht mir dieses Passwort allein aus, zumindest für die interne SSD. Bin aber nun dabei meine Backupplatten auf LUKS umzustellen.

Und das ist auch kein neues Feature, das gibt es sei 20 Jahren vgl. https://www.heise.de/ratgeber/Baerendienst-289866.html

[Livingston]

Ich meine das Disk-Passwort.

Da die Feinheiten des Disk-Passwort-Algorithmus unbekannt sind, weiß ich nicht, wie stark dieser ist und auch nicht, ob ein Masterkey existiert, den ich nicht sehen kann.
LUKS dagegen habe ich komplett unter Kontrolle. Da bleibe ich lieber bei letzterem.

[cosinus]

ob ein Masterkey existiert, den ich nicht sehen kann

Öffentlich ist nichts bekannt. In irgendwelchen Foren wurden gern mal irgendwelche Masterpasswörter genannt, hab aber noch keinen Thread gefunden in denen diese auch tatsächlich funktionierten. Auch @MSfree schrieb ja, dass man etwas Aufwand betreiben muss -> andere Controller besorgen und umbauen/umlöten. Also "mal eben so" das Passwort umgehen ist nicht - der 0815-Dieb kann mit so einer gesicherten Disk nichts anfangen, wenn überaupt nur ein Secure Erase machen um sie dann gewipet wiederverwenden zu können. Sofern dieser Secure Erase durchführbar ist.

[Livingston]

Ich dachte auch nicht an 08/15-Diebe, sondern an Unfälle wie z.B. bei M$ Azure: Irgendwer klaut den Masterkey und schwupps sind Millionen von Konten offen. So was bei einem namhaften Festplattenhersteller und Millionen Elektroschrottentsorger wundern sich, warum sich die Überfälle auf ihre Lager um 10000% steigern. Da steigt dann plötzlich der Schrottwert auf Goldwert an.
Es geht nicht um den Einbruch vor Ort, sondern um Nachvollziehbarkeit und Unwägbarkeiten solcher Art.
Sollen sich evtl. Abzocker doch lieber an 256 Bit AES ranwagen. Dauert ein bissel länger, bis sie an die Schnäppchen kommen.

[cosinus]

also ich bearbeite alte Festplatten gerne mit dem Hammer bevor sie in die Schrotttonne wandern. Ansonsten bewahre ich sie auf, wenn sie noch funktionieren und nulle sie mit dd.

Wie gesagt ist das Disk-Passwort keine 100% Lösung, aber für den Homeuser in den meisten Fällen ausreichend v.a. dann wenn man sich nicht mit LUKS oder Bitlocker herumschlagen will.

[Livingston]

Jep, für zuhause (und später Hammer druff) reicht das dicke.
Ich stell mir nur vor, wie ich mal wieder 'ne SSD in einer Arztpraxis austausche und der Onkel Doc später die gesammelte Patientendaten doppelt vorliegen hat: Auf seinem Server und in der Erpresser-Mail. Der fragt dann erst mal mich, wo ich denn die Daten gespreadet habe. Da bleibe ich lieber bei dem, was ich gelernt habe und auch einheitlich (unabhängig vom Festplattentyp, BIOS/UEFI) händeln kann.

[rhHeini]

Nach langer Zeit:

Dieser Faden ist ein typisches Beispiel dafür wie viele Protagonisten versuchen einzig und allein ihre Meinung und ihr Vorgehen als das einzig richtige anzupreisen und durchzusetzen, und nicht darauf einzugehen was der OP vorhat und haben will. Man brauch sich nur die 2te Seite ansehen ...

Ich habs jedenfalls für Debian/Devuan aufgegeben, eine echte FDE mit automatischer Entschlüsselung geht nicht. Ich bleib auch bei Devuan Excalibur (das Triexie-Pendant bei Devuan) bei der klassischen Methode mit unverschlüsseltem /boot.

Arch macht das irgendwie ganz anders, da geht FDE ohne gross noch an Parametern und Einstellungen rumzuschrauben ungefähr mit gleichen Aufwand wie für die klassische Debian-Methode. Ich geh da durch meine Notizen, und die funktionieren nach 4 Jahren immer noch. Aber auf Arch mag ich nicht umswitchen, das Rolling Release ist mir für meinen Desktop zu anstrengend. Ich habs probiert, Devuan Stable ist mir lieber.

[tobo]

Ich habs jedenfalls für Debian/Devuan aufgegeben, eine echte FDE mit automatischer Entschlüsselung geht nicht.

Ein /boot verschlüsselt mit LUKS2/PBKDF2 zählt für dich noch nicht zur FDE?

[Blue]

@rhHeini:
"...Hat schon mal jemand eine echte FDE mit Debian hinbekommen? Wenn ja, wie?..."

MSFree hat doch schon oben alles Nötige zum Thema gesagt (21.05.2024 10:12:48 ).
Wer einen wirklich sicheren Schutz haben will, sollte bei der Debian-Installation die "echte" Full-Disk-Encryption LUKS vornehmen.
Bei mir gehört das zur Standardinstallation genau so wie das Anlegen externer Backups.
Ein Dieb hat dann beim Verwenden einer guter Paraphrase nur die Hardware, aber keine persönlichen Daten ergattert.
Es sei denn, er hat 20 bis 30 Jahre Zeit für ein "Brute Force" oder einen Quantencomputer zur Verfügung.

Siehe auch:
https://www.thomas-krenn.com/de/wiki/De ... stallieren (unter "Laufwerkseinstellungen > Wählen Sie die Partitions-Methode")
https://www.passwarden.com/de/help/use- ... a-password

[slu]

Was genau ist den der Grund /boot zu verschlüsseln?
Ich habe seither immer den Debian Installer mit Verschlüsselung ausgeführt dann bleibt ein /boot unverschlüsselt übrig und der Rest ist LUKS2.

Ist das nicht gut oder was genau ist die Gefahr? /boot Manipulieren und beim nächsten starte das Passwort auslesen?
Wird das Gerät entwendet sind die Daten doch erst mal sicher auch ohne verschlüsseltes /boot?

[uname]

Ich lese den Thread heute zum ersten Mal.

Ich weiß nicht wie oft Festplatten unterwegs oder z. B. aus Arztpraxen für Erpressungen gestohlen werden. Aber ich denke der Erpresser greift eher online über Malware direkt auf die unverschlüsselten Daten zu und erpresst z. B. durch eine ungewollte Festplattenverschlüsselung. Und das wäre mit Linux eher nicht passiert. Nicht weil Linux so sicher ist, eher weil es mit 1% oder weniger in Arztpraxen kein lukratives Ziel gegenüber vielleicht 95% Windows ist. Gilt im Übrigen auch für Internet-Banking. Und warum /boot verschlüsselt sein sollte, weiß ich auch nicht. Ohne den Key wird man den Rest nicht entschlüsseln können - egal was in /boot steht. Es ist eben ein Verschlüsselungsverfahren. Nicht die Software muss sicher sein, sondern der Algorithmus und der Key.

Ist das nicht gut oder was genau ist die Gefahr? /boot Manipulieren und beim nächsten starte das Passwort auslesen?
Wird das Gerät entwendet sind die Daten doch erst mal sicher auch ohne verschlüsseltes /boot

Das Sicherheitsrisiko fängt doch schon damit an, dass man das Passwort direkt auf dem Gerät (PC) eingibt, wo auch die Festplatte enthalten ist. Das Gerät könnte schon manipuliert sein und die Tastenandrücke könnten mitgelesen werden. Wie beim Internet-Banking benötigt man eigentlich ein weiteres Gerät wie z. B. ein Smartphone oder TAN-Generator zur Erstellung einer unabhängigen TAN. Oder minidestens eine USB-Stick mit dem (privaten) Schlüssel drauf, der den USB-Stick nie verlässt.

[MSfree]

Und warum /boot verschlüsselt sein sollte, weiß ich auch nicht.

Weil man ohne verschlüsseltes /boot dort Rootkits unterbringen kann.

OK, dagegen soll (angeblich) secure Boot helfen. Wenn es um Geheimdienste oder Staatstrojaner geht, würden die einfach ein signiertes Rootkit installieren, so daß secure Boot das einfach durchwinkt.

Das Problem eines verschlüsselten /boot ist aber das Henne-Ei-Problem. Wie soll z.B. grub starten, wenn es verschlüsselt wäre? OK, man gebe hier eine Passphrase ein, aber wer soll die Passphrase abfragen, wenn die dazu nötige Software verschlüsselt wäre?

Eine Vollverschlüsselung kann es also nicht geben, ohne zumindest einen minimalen unverschlüsselten Bootloader.

[cosinus]

Weil man ohne verschlüsseltes /boot dort Rootkits unterbringen kann.
...
Eine Vollverschlüsselung kann es also nicht geben, ohne zumindest einen minimalen unverschlüsselten Bootloader.

Und GENAU deswegen wurde das Diskpasswort von mir vorgeschlagen, was hier aber nur zerredet und als Durchboxen meines Dings Dings tituliert wurde.

[Blue]

Weil man ohne verschlüsseltes /boot dort Rootkits unterbringen kann.
...
Eine Vollverschlüsselung kann es also nicht geben, ohne zumindest einen minimalen unverschlüsselten Bootloader.

Und GENAU deswegen wurde das Diskpasswort von mir vorgeschlagen, was hier aber nur zerredet und als Durchboxen meines Dings Dings tituliert wurde.

Das sehe ich auch so.
Und das Aufblähen durch UEFI und Secure-Boot mit Benutzeroberflächen in KDE-Anmutung gibt breitere Angriffsflächen.
Sinnvoll wäre imho das gute alte extrem minimalistische Bios, welches nur mit aufwändigem Flashen modifiziert werden könnte.
Und noch einmal betonen möchte ich unames Vorschlag eines weiteren externen Authentifizierungs-Geräts wie zum Beispiel das Sealone der Postbank.

[tobo]

Eine Vollverschlüsselung kann es also nicht geben, ohne zumindest einen minimalen unverschlüsselten Bootloader.

Auf einem BIOS-System ist das der Bootsektor und dieser 1. Sektor (MBR) ist 512 Bytes groß und darauf liegen ~400 Bytes unverschüsselter GRUB Stage1 (ähnlich für GPT).
Aber das wurde hier ja schon geschrieben und daran hat sich in den letzten Monaten auch nichts geändert.

[MSfree]

Auf einem BIOS-System ist das der Bootsektor und dieser 1. Sektor (MBR) ist 512 Bytes groß und darauf liegen ~400 Bytes unverschüsselter GRUB Stage1 (ähnlich für GPT).

Genau genommen sind im MBR 446 Bytes Platz für Maschinencode. Das reicht aber nicht, um dort eine Entschlüsselng samt Passphraseeingabe zu realisieren, um die nächste Bootphase verschlüsselt zu laden.

Davon abgesehen beherrschen neuere Systeme kein MBR-Boot mehr. Mein rund 4 Jahre alter NUC11 kann z.B. ausschließlich UEFI-Boot von einer unverschlüsselten FAT-Partition.