Verschlüsselte externe USB-HDD ohne Passwort?

[buhtz]

Moin,

die Frage ist noch zu unspezifisch, daher hier in Smalltalk.

Ich bewege mich seit Jahren backup-mäßig auf sehr dünnem Eis: Zu Hause ein Raid-1-NAS in Verbindung mit backintime-qt.

Das Szenario möchte ich nun mit einer externen Platte erweitern, die ich 1x im Monat anhänge und danach außerhalb der Wohnung (z.B. im Büro) lagere. Problem bei externer Lagerung ist die Sicherheit der Daten, weshalb ich die Platte verschlüsseln möchte. Mit sowas hab ich vorher noch nie gearbeitet.

Ich möchte, vermutlich per udev, alles so konfigurieren, dass das Backup beim Anstöpseln am NAS automatisch startet. Das NAS ist headless. Ich möchte nicht extra ein Password eingeben müssen. Kann man die Verschlüsselung der Platte so konfigurieren, dass diese sich automatisch am NAS "irgendwie entschlüsselt"?

Oder kann ich mich von dem Szenario gleich verabschieden?

Danke

[bluestar]

Du könntest das Passeort für die Externe HDD in einer Datei auf deinem NAS ablegen, dann kannst du automatisch entschlüsseln.

Wichtig: Du solltest dir das Passwort auf jeden Fall merken oder notieren um im Restore-Falle an die Daten rankommen zu können.

[TRex]

LUKS kann doch auch mit key files, oder nicht?

[hikaru]

LUKS kann doch auch mit key files, oder nicht?

Ja.

[bluestar]

LUKS kann doch auch mit key files, oder nicht?

Das wäre natürlich auch eine Option, einmal Keyfile auf dem NAS und dder zweite Key-slot von luks für ein Passwort zum Entschlüsseln bei Restore Bedarf.

[buhtz]

Und der Keyfile (oder die Passwort-Datei) auf dem NAS ist dann "sicher", weil nur der betreffende Nutzeraccount Lese- und Schreibrechte (rw-------) darauf hat? Ziere mich immer sowas zu speichern. Theoretisch könnte ich ja auch ein keyfile auf einen USB-Stick legen und mit anstecken. Das mache ich als zweiten Faktor auch für meine KeePassXC Datenbank.

Mhm... Klingt doch mal gut. Muss es jetzt nur mal in Angriff nehmen.

[bluestar]

Und der Keyfile (oder die Passwort-Datei) auf dem NAS ist dann "sicher", weil nur der betreffende Nutzeraccount Lese- und Schreibrechte (rw-------) darauf hat? Ziere mich immer sowas zu speichern.

Die Sicherheit hier ist relativ, da die zu sichernden Dateien ja ohnehin unverschlüsselt auf dem NAS liegen ... Der Key/das Passwort schützen ja nur die Daten auf der externen Platte, die sich - wie du schreibst - ja außerhalb der Backup-Zeiten - an einem Ort befindet, wo deren Inhalt gegen unbefugte Zugriffe geschützt werden muss.

[buhtz]

Ja, richtig. Aber zu Hause haben "Unbefugte" normalerweise keinen Zugriff, es sei den sie brechen ein; physisch oder über den Router. Die Hürde hier ist höher, auch wenn nicht unbedingt wirklich hoch. Hinzu kommt noch, dass das NAS relativ groß ist und dazu auch noch ordentlich verkeilt im Abstellraum steht. Das muss man erst mal da rausbekommen.

Die ausgelagerte Platte liegt allerdings im Büro mit viel Durchgangsverkehr, öffentliches Gebäude, viele Diebstähle und dazu auch noch Brände, etc. Das Risiko ist hier extrem hoch, dass die Platte wegkommt, selbst wenn ich sie irgendwo einschließe. Ein verschlossener Schrank ist hier eher noch ein Appetizer für die Diebesbanden. Klingt nicht sexy, aber mir fällt kein anderer Ort ein, den ich als Alternative zur eigenen Wohnung nutzen könnte.

[bluestar]

Die ausgelagerte Platte liegt allerdings im Büro mit viel Durchgangsverkehr, öffentliches Gebäude, viele Diebstähle und dazu auch noch Brände, etc. Das Risiko ist hier extrem hoch, dass die Platte wegkommt, selbst wenn ich sie irgendwo einschließe. Ein verschlossener Schrank ist hier eher noch ein Appetizer für die Diebesbanden.

Auf der Platte befindet sich das Keyfile/die Passwort-Datei ja ohnehin nur in dem verschlüsselten Dateisystem. Um deine Backup-Platte zu öffnen müsste als jemand zwei Schritte unternehmen:
1. Backup-Platte entwenden
2. Key von deinem NAS zu Hause entwenden

Und wer den 2. Punkt schafft, der hat ohnehin Zugriff auf dein NAS ... Somit entwendet diese Person die Backup-HDD nicht.

Solltest du jedoch den Verlust der Backup-Platte feststellen, so wäre die Vernichtung des Key-Files auf deinem NAS der nächstfolgende Schritt um die Entschlüsselung der Backup-Platte im Idealfall unmöglich zu machen.

[cosinus]

Die ausgelagerte Platte liegt allerdings im Büro mit viel Durchgangsverkehr, öffentliches Gebäude, viele Diebstähle und dazu auch noch Brände, etc. Das Risiko ist hier extrem hoch, dass die Platte wegkommt, selbst wenn ich sie irgendwo einschließe. Ein verschlossener Schrank ist hier eher noch ein Appetizer für die Diebesbanden. Klingt nicht sexy, aber mir fällt kein anderer Ort ein, den ich als Alternative zur eigenen Wohnung nutzen könnte.

Und warum kommst du auf die Idee, die Backupplatte dann ausgerechnet dort zu lagern?
Hast du keinen besseren externen Platz? Anderes Haus bei Verwandten, Freunden oder guten Nachbarn?

Was die Verschlüsselung angeht: kann das Backuptool denn keine Verschlüsselung? Dann würde man auf Dateiebene verschlüsseln und nicht gleich das ganze Dateisystem. Nur als Alternative zur Schlüsseldatei, die das verschlüsselte Dateisystem zu öffnet. Ich weiß aber nicht was man sich da anstellt 1x im Monat so ein Passwort einzugeben, ich mach das hier an meinem Rechner wesentlich öfter wenn es ums Backup und v.a. ständige Logins geht.

[niemand]

Ich möchte, vermutlich per udev, alles so konfigurieren, dass das Backup beim Anstöpseln am NAS automatisch startet. Das NAS ist headless. Ich möchte nicht extra ein Password eingeben müssen. Kann man die Verschlüsselung der Platte so konfigurieren, dass diese sich automatisch am NAS "irgendwie entschlüsselt"?

Du (oder der von dir Beauftragte) schließt die Backupplatte vor Ort an? Dann wäre vielleicht ein FIDO2-Token eine Überlegung für dich: Token reinstecken, Platte anschließen, Token für Freigabe berühren und ab dafür. Vorteil: der Schlüssel wird nirgends in einer Form gespeichert, in der er kopiert werden könnte.

Man könnte es noch weiter ausbauen: etwa, indem man beim Entschlüsseln eine PIN anfordert, die auf dem NAS gespeichert ist und mitgegeben wird. Dann könnte eine Angreiferin das Backup selbst dann nicht entschlüsseln, wenn sie das Backup und das Token stehlen würde.

[ernohl]

Indirekt lese ich heraus, du hast ein (tägliches) Backup über alles und damit sicherst du regelmäßig riesige Datenmengen. Richtig?

Mein Backup-Ansatz ist folgender:
Aus meiner täglichen Datensicherung klammere ich alles aus, was ziemlich statisch ist: Fotos, Videos, Musik, ... (dies wird bei Bedarf manuell auf andere Backup-Medien gesichert. Dies sind auch Dinge, die ich unverschlüsselt im Familienkreis für den Notfall deponieren würde.
Bei mir bleiben dann wenige GB mehr oder wenige sensible Daten für die regelmäßige Datensicherung übrig, jedenfalls so wenige, dass man sie auf einem kleinen Datenträger an allen möglichen Orten "versteckt" lagern könnte.

Unter so einer Prämisse siehst du dein Lagerungsproblem vielleicht mit anderen Augen.

BTW. Ich habe mehrere Sicherungsbereiche definiert, die in einzelne tar-Archive gesichert werden. Die Sicherung pro Bereich wird nur bei Änderung gestartet - meist als diff, nach einem Mindestzeitraum als Vollsicherung. Das allein reduziert die Sicherungsmenge (und -zeit) gewaltig und du kannst bei gleicher Backup-Kapazität auf deutlich ältere Dateiversionen zurückgreifen. Auf dem externen Medium (zur auswärtigen Lagerung) liegt natürlich weniger (SPOF).

[buhtz]

Was die Verschlüsselung angeht: kann das Backuptool denn keine Verschlüsselung?

Doch. Back In Time nutzt optional encfs um nach dem rsync-run, die Destination zu verschlüsseln. Das macht die Destination aber, ohne Back In Time, unbrauchbar und hebelt ein wichtiges Feature von Back In Time aus, nämlich dass man Zugriff auf das Backup hat, ohne das Backup Tool nutzen zu müssen. Nebenbei: Langfristig wird EncFS durch eine Alterantive (evtl. GoCrypt) ersetzt, oder entfernt, wenn sich kein Contributor findet, der das umsetzt (#1549).

Indirekt lese ich heraus, du hast ein (tägliches) Backup über alles und damit sicherst du regelmäßig riesige Datenmengen. Richtig?

Ich unterscheide schon, so wie du auch, zwischen verschiedenen Arten von Daten, deren Intervall und Wichtigkeit.
Aber am Ende muss ich auch die "unwichtigen" Daten mit dem langfristigsten Intervall irgendwann mal aus dem Haus schaffen können.

BTW. Ich habe mehrere Sicherungsbereiche definiert, die in einzelne tar-Archive gesichert werden. Die Sicherung pro Bereich wird nur bei Änderung gestartet - meist als diff, nach einem Mindestzeitraum als Vollsicherung. Das allein reduziert die Sicherungsmenge (und -zeit) gewaltig und du kannst bei gleicher Backup-Kapazität auf deutlich ältere Dateiversionen zurückgreifen. Auf dem externen Medium (zur auswärtigen Lagerung) liegt natürlich weniger (SPOF).

Was ich für das Backup von NAS zu externer Platte nutze, habe ich noch gar nicht entschieden. Back In Time jedenfalls nutzt rsync mit dem Hard-Link feature. Faktisch ist es immer ein Vollbackup (unveränderte Dateien werden mit denen aus dem vorherigen Backup verlinkt), aber technisch nur ein differenzielles (transferiert wird nur, was sich wirklich ändert).

[cosinus]

Das macht die Destination aber, ohne Back In Time, unbrauchbar und hebelt ein wichtiges Feature von Back In Time aus, nämlich dass man Zugriff auf das Backup hat, ohne das Backup Tool nutzen zu müssen.

Wenn ich eine Extra-Backupsoftware verwende kenn ich das garnicht anders. Dann brauche ich auch wieder eben genaue diese Backupsoftware. Im Büro nutzen wir dafür eine eigene virtuelle Maschine, auf der Veeam B&R läuft, die sichert dann alle anderen VMs die mit Linux oder Windows laufen.
Hin und wieder kommt auch noch Drivesnapshot zum Einsatz. Das Tool muss ich dann auch benutzen um was zu recovern.

[wanne]

Ich würde auch nen Keyfile nehmen.

Vorteil: der Schlüssel wird nirgends in einer Form gespeichert, in der er kopiert werden könnte.

Nein. Nachteil: Der Schlüssel wird zusätzlich auf dem FIDO2-Tokengespeichert. Wer auf das NAS Zugriff hat, kann jederzeit sowieso auch a) die Daten direkt auslesen und b) den Masterkey der Platte auslesen. Nun hat man einen Token der verloren gehen kann und getrennt geschützt werden muss. Packt man ihn Zum Backup macht man die Verschüsslung sinnlos und ersetzt bestenfalls den komplexen Key durch eine einfache PIN. Packt man ihn zum NAS ist das Backup nutzlos.

Dann würde man auf Dateiebene verschlüsseln und nicht gleich das ganze Dateisystem.

Prinzipiell haben derartige Verschlüsslungen halt mit weit mehr Sicherheitsproblemen zu kämpfen als Vollverschlüsslungen. (Siehe Padding, Watermarking, Seeds und deren Zufall, Diverse andere Seitenkanalangriffe auf Erstell-/Änderungsdaten und Dateigrößen vor allem in Kombination mit Kompression.) Ja das funktioniert alles immer nur auf bestimmte Daten und es braucht vermutlich etwas mehr Gehirnschmalz sowas abzuwandeln als der übliche Angreifer aufwendet. Aber ich verstehe nicht, warum man solche komplexe Lösungen mit "not our threat model" Poblemen nutzt, wenn es einfache Lösungen gibt, die die Probleme gar nicht erst haben.

[cosinus]

Prinzipiell haben derartige Verschlüsslungen halt mit weit mehr Sicherheitsproblemen zu kämpfen als Vollverschlüsslungen.

Verstehe ich nicht wirklich. Ich muss 1x im Monat das Vollbackup auf eine externe Disk kopieren. Zuerst landet grundsätzlich jedes Backup auf das NAS. Das monatliche Vollbackup wird von Veeam verschlüsselt, ich kopiere das dann auf ein normales unverschlüsseltes ext4 auf der ext. Disk. Wieso soll die Verschlüsselung von Veeam da nun unsicherer sein als ein verschlüsseltes Dateisystem?

wenn es einfache Lösungen gibt, die die Probleme gar nicht erst haben.

Stein des Anstoßes war, dass der TO geschrieben hat, dass er zu faul zum Passworteingeben ist und sich nun auf die Keyfiles verlassen muss. Deswegen erwähnte ich die Alternative.

[niemand]

Nein. Nachteil: Der Schlüssel wird zusätzlich auf dem FIDO2-Tokengespeichert.

Nein. Bei der von mir angesprochenen Methode wird nichts zusätzlich irgendwo gespeichert. Der eigentliche Schlüssel bleibt wie gehabt im LUKS-Header. Das FIDO2-Token gibt bei Eingabe der richtigen PIN (hier: mittels Script) und den richtigen Eingangsdaten den passenden Schlüssel für diesen aus – also das Äquivalent der Passphrase, nur halt sehr viel sicherer als eine übliche Passphrase. Der dazu genutzte private Schlüssel verbleibt auf dem Token, und ist von dort nicht auslesbar (vorausgesetzt, es wird kein entsprechend ausnutzbarer Fehler gefunden – derzeit ist mir für keines der existierenden Tokens sowas bekannt).

Nun hat man einen Token der verloren gehen kann und getrennt geschützt werden muss.

Wenn es zusammen mit dem Backup verlorengeht, löscht man die PIN aus dem Script, bzw. ersetzt sie mit der PIN des Reserve-Tokens. Dann hat der Finder des verlorenen Tokens und des Backups genau acht Versuche, die richtige Passphrase für das Token einzugeben. Anschließend existiert dieser Schlüssel zum Entschlüsseln des Masterkeys im LUKS-Header nicht mehr.

Wenn nur das Token verloren wurde, das Backupmedium aber selbst noch vorhanden ist, löscht man dort halt direkt den entsprechenden Keyslot – dann hat der Finder nicht einmal diese acht Versuche, wenn das Backupmedium später ebenfalls verloren gehen und von ihm gefunden werden sollte.

Hat er zufällig auch das NAS gefunden, hätte er natürlich direkt die PIN – was aber völlig egal wäre, weil er die Daten eh mit dem NAS bekommt, und sie daher gar nicht erst aus dem Backup holen müsste.

[wanne]

Das FIDO2-Token gibt bei Eingabe der richtigen PIN (hier: mittels Script) und den richtigen Eingangsdaten den passenden Schlüssel für diesen aus – also das Äquivalent der Passphrase, nur halt sehr viel sicherer als eine übliche Passphrase.

Nein halt viel unsichererer.

vorausgesetzt, es wird kein entsprechend ausnutzbarer Fehler gefunden

Eben. Genau da liegt die zusätzliche Angriffsfläche. Wie von dir schon gesagt:

Der eigentliche Schlüssel bleibt wie gehabt im LUKS-Header.

Der kann also weiter angegriffen werden.

löscht man dort halt direkt den entsprechenden Keyslot

Womit man einen Angriffsvektor beseitigt, den es ohne nie gegeben hätte.

Dann hat der Finder des verlorenen Tokens und des Backups genau acht Versuche, die richtige Passphrase für das Token einzugeben. Anschließend existiert dieser Schlüssel zum Entschlüsseln des Masterkeys im LUKS-Header nicht mehr.

Doch. – Du kennst ihn nur nicht mehr. Prinzipiell steht dir ein brute-Force weiter offen. Nur halt gegen die 128Bit-FIDO2-HMAC statt gegen den 512Bit Key, den LUKS per default nimmt.

LUKS alleine hast du halt die Angriffsvektor: Fehler in der Implementierung von AES/LUKS, Master und Slot-Key, die beide (hoffentlich) aus dem gleichen Zufallsgenerator (/dev/urandom) kommen und die Daten im Original. Alle bleiben erhalten wenn du FIDO2-Nutzt.
Mit dem FIDO2-Token kommen der Zufallsgenerator im Key, Den KeyAgreementKey, der nicht Quantensicher ist, angriffe auf die PIN und eben angriffe zum Auslensen der Hardware selbst.

Auch wenn ich es jetzt nicht glaube, dass jemand P-256 bricht oder 128Bit brutforcest es ist schlicht und einfach eine zusätzlicher Angriffsvektor, den du sonst nicht hättest. Ich will nicht über die Plausibilität der Angriffe sprechen. (Die zugegeben klein ist.) Ein zusätzlicher Angriffsvektor macht Sachen niemals sicherer.

Das monatliche Vollbackup wird von Veeam verschlüsselt

Ich kenne die Software nicht. Aber wenn ich das korrekt sehe, verschlüsselt Veeam ja doch wieder das volle Dateisystem indem es den vollen VM-Container verschlüsselt. Zumindest wenn du raw-images nutzt ist das natürlich vollständig äquivalent zu LUKS. Könnte mir gut vorstellen, dass die das sogar schlicht direkt nutzen. Das sind dann auch keine differentiellen Backups. Worum es mir ging, war sowas wie rsync auf encfs.

[niemand]

Nein halt viel unsichererer.

Könntest du bitte ausführen, wie ein via hmac-secret generierter Hash „viel unsichererer[sic!]“ als eine Passphrase mit in der Regel deutlich geringerer Entropie sein kann? Ernstgemeinte Frage, ebensolche Antwort erbeten.

Der kann also weiter angegriffen werden.

Dazu müssen ein paar Sachen zusammenkommen – insbesondere muss der Angreifer das Ding erstmal in die Finger bekommen, und dann muss er eine Möglichkeit für genau das vorliegende Token haben, den geheimen Schlüssel von dem Ding zu extrahieren oder den Fehlerzähler für die PIN unwirksam zu machen – und zumindest mir ist kein Fall bekannt, in dem sowas gelungen wäre. Tatsächlich können nur wenige Leute auch „nur“ einen handelsüblichen Microcontroller mit gesetztem Leseschutz auslesen, und das dann auch nur bei einigen wenigen Modellen mit bekannten Schwachstellen – und hier ist im Grunde nichts Anderes als ein Microcontroller am Werk – nur dass hier solche zum Einsatz kommen, bei denen nochmal mehr Augenmerk auf die Sicherheit auch gegen Auslesen gelegt wird.

Wenn du anders siehst, bitte ich ebenfalls um eine möglichst unaufgeregte und sachliche Darstellung deines Einwands.

Doch. – Du kennst ihn nur nicht mehr. Prinzipiell steht dir ein brute-Force weiter offen. Nur halt gegen die 128Bit-FIDO2-HMAC statt gegen den 512Bit Key, den LUKS per default nimmt.

Soweit mir bekannt: Nein, der geheime Schlüssel für die Generierung des Hashes via hmac-secret-Funktion wird unmittelbar nach dem letzten Fehlversuch und unwiderruflich gedroppt, sofern der konkrete Hersteller sich bei dem konkreten Modell keinen konkreten Anfängerfehler bei dieser Funktion geleistet hat. Außerdem wird der via hmac-secret-Funktion gewonnene Hash nicht direkt als Datenträgerschlüssel genommen, sonst wäre es nicht möglich, mehrere Tokens und Passphrases/Keyfiles parallel zu haben, sondern er wird im Weiteren genauso wie eine Passphrase behandelt – incl. Salt, PBKDF und dort rausfallendem 512-Bit-Schlüssel. Du kannst es dir ja problemlos selbst anschauen: wenn du ein FIDO2-Token hinzufügst, wirst du neben dem neuen Eintrag für das Token einen weiteren belegten Keyslot mit den entsprechenden Daten und Parametern im LUKS-Header vorfinden.

Das bedeutet unterm Strich, dass du natürlich weiterhin per B&F versuchen kannst, den Masterkey zu entschlüsseln – aber dabei ähnlich geringe Geschwindigkeit und damit Aussicht auf Erfolg hast, wie mit einer regulären Passphrase ähnlicher Komplexität. Im Grunde bist du da also wohl schneller, wenn du deine Rechenleistung direkt gegen die Datenträgerverschlüsselung wirfst.

Wenn du da andere Informationen hast, bitte ich auch hier um Nennung – idealerweise ebenfalls unaufgeregt und sachlich und gerne auch mit Quellen.

Nicht zuletzt sollte man auch die Verhältnismäßigkeit und insbesondere auch mal den Kontext dieses Threads beachten: Wenn man derart wichtige oder wertvolle Daten hat, dass die von dir skizzierten Szenarien überhaupt eine Rolle spielen, dann hat man vermutlich ganz andere Sorgen als der TE – insbesondere würde man nicht in ’nem öffentlichen Forum fragen, wie man das wohl am besten lösen könnte.

[wanne]

Ich glaube wir reden hier gerade aneinander vorbei.
Im FIDO2-LUKS1-Fall sieht das üblicherweise in etwa so aus:
IV+PIN>P-256>HMAC>Key>PBKDF2>Masterkey>AES.Wobei das grüne im Dongle stattfindet und das Blaue im NAS.
Der Private Key von P-256 wird eventuell nach dem 8. Versuch gelöscht und ist somit (hoffentlich) unwiederbringlich verloren. Man könnte ihn aber mit nem sehr starken Quantencomputer zurückrechnen, wenn man an den Public-Key des Dongles kommt, den der raus gibt. IV ist 64Bit aber nutzlos ohne den oberen private Key. Bekommt man den Dongle aber aufgemacht kann den auslesen kann man mit IV und private P-256 Key problemlos Key wiederherstellen.
Key ist 128Bit und liegt im LUKS-Header. Denn kann man entsprechend ohne Dongle bruteforcen.

Nutzt du dagegen LUKS mit Keyfile hast du den sinnvollerweise so erzeugt um die Keylenge vom dahinter liegenden aes-xts mit 512Bit zu Matchen: head -c 64 /dev/urandom oder head -c 64 /dev/urandom | base64, wenn man ihn für den Notfall auch von Hand eingeben können will. Da es ein Keyfile ist, muss der weder Lesbar noch kurz sein.
Effektiv macht man dann:
Key>PBKDF2>Masterkey>AES
Ist /dev/urandom kaputt ist auch Masterkey kompromittiert und du kannst auch die Variante mit FIDO2 angreifen.

Im FIDO2 Fall ist also der Brute-Force Angriff am Besten auf Key, da der 128Bit ist. Im anderen Fall ist der Optimale Angriff der auf AES-256 mit effektiv 257Bit (Dank XTS hast du 2 256Bit-Keys zu knacken). die deutlich weniger als die 512Bit von Key sind.
Im FIDO2 Fall hat man daneben noch die Möglichkeit den P-256 Key zu knacken oder das devices ohne dass es das merkt auszulesen. – Alle drei Angriffe sind ohne FIDO2 nicht möglich.
Daneben könnte man so Späße versuchen, wie Neue devices anlegen bis man irgend wann den gleichen 64Bit-IV erwischt. Zumal du 32Bit wählen darfst. (Ich hoffe dagegen hat jeder FIDO2-stick was. – Und sei es, dass er schlicht viel zu lahm ist) oder schlicht hoffen, dass man die PIN in den ersten 8 Versuchen schafft.

Wie gesagt: Ja das ist alles solide Crypto die eher nicht kaputt gehen sollte. Aber zu verlässt dich eben auf einen ganzen Haufen zusätzliche Algorithmen und deren Implementierungen.

[niemand]

Man könnte ihn aber mit nem sehr starken Quantencomputer zurückrechnen, wenn man an den Public-Key des Dongles kommt, den der raus gibt.

Ohne dir zu nahe treten zu wollen: dieser Thread hat einen realen Hintergrund. Die letzte großspurig als alles in den Schatten stellend vorgestellte Leistungsdemonstration eines realen Quantencomputers wurde von einem realen C64 in den Schatten gestellt – die rechnen erstmal noch keine privaten Schlüssel aus public keys zurück. Auch ist die Sache mit den FIDO2-Tokens keine asymmetrische Kryptographie, für die ja die theoretischen Möglichkeiten von Quantenrechnern das Schreckenszenario sind, sondern im Grunde die symmetrische Verschlüsselung der im LUKS-Header hinterlegten Daten. Ich sehe also nicht, wie du damit ein Problem mit den FIDO2-Tokens aufzeigen willst.

Ich denke aber, solche Phantastereien sind in dieser Diskussion sowieso nicht zielführend, weil’s eben um die gegenwärtige Realität geht.

Bekommt man den Dongle aber aufgemacht kann den auslesen kann man mit IV und private P-256 Key problemlos Key wiederherstellen.

Auch hier ohne dir zu nahe treten zu wollen: bislang hat keiner so ein Dongle aufgemacht. Wie gesagt: es ist bis auf wenige Ausnahmen nicht möglich, auch nur einen normalen lesegeschützen Microcontroller auszulesen, und die hier verwendeten Controller sind diesbezüglich nochmal aufwendiger gesichert. Wenn du so argumentierst, kannst du genausogut sagen, dass ja die gesamte Verschlüsselungssache unnütz ist – weil die mit der gleichen Wahrscheinlichkeit „problemlos“ direkt aufgemacht werden könne. Was allerdings zumindest in der Realität, in der ich mich aufhalte, nicht der Fall ist.

Ist /dev/urandom kaputt ist auch Masterkey kompromittiert und du kannst auch die Variante mit FIDO2 angreifen.

Ebenfalls ohne dir zu nahe treten zu wollen: wenn dein urandom kaputt ist, ist es völlig egal, ob du ein FIDO2-Token, eine Passphrase oder sonstwas für dein LUKS verwendest – das ist dann alles gleichermaßen kaputt. Entsprechend leuchtet mir nicht ein, warum du das hier anführst.

Nutzt du dagegen LUKS mit Keyfile hast du den sinnvollerweise so erzeugt um die Sicherheit vom dahinter liegenden aes-xts mit 512Bit zu Matchen

Warum sollte da was angepasst werden? Aus der KDF fällt eh immer die gleiche Länge raus, egal, wieviel man auf der anderen Seite reinschiebt. Klar ist längerer Input == besser, aber warum man da irgendwas „matchen“ sollte, erschließt sich mir nicht.

Im FIDO2 Fall ist also der Brute-Force Angriff am Besten auf Key, da der 128Bit ist.

Wo kommen die 128 Bit her? Soweit ich weiß, gibt hmac-secret 256 Bit zurück, und diese 32 Bytes werden anstelle der Passphrase oder des Keyfiles in die PBKDF gegeben. BF kannst du aber nur dagegen, oder direkt gegen den Hauptschlüssel probieren – mit jeweils der gleichen Erfolgsaussicht, also real: Null.

Ich sehe also immer noch nicht, wie ein FIDO2-Token unsicherer sein soll, als eine Passphrase mit üblicherweise deutlich weniger Entropie, oder ein im Klartext gespeichertes Keyfile. Vielleicht könntest du da nochmal kurz drauf eingehen, und dabei idealerweise im Rahmen der gegenwärtigen Realität bleiben?

[cosinus]

Ich kenne die Software nicht. Aber wenn ich das korrekt sehe, verschlüsselt Veeam ja doch wieder das volle Dateisystem indem es den vollen VM-Container verschlüsselt. Zumindest wenn du raw-images nutzt ist das natürlich vollständig äquivalent zu LUKS. Könnte mir gut vorstellen, dass die das sogar schlicht direkt nutzen. Das sind dann auch keine differentiellen Backups. Worum es mir ging, war sowas wie rsync auf encfs.

Veeam erzeugt als Backup ganz normale Dateien. Die werden bei uns erstmal aufs NAS via SMB geschrieben, dann wie gesagt 1x monatlich auf eine HDD kopiert. Diese HDD lass ich unverschlüsselt weil die Backupdatei von Veeam schon verschlüsselt ist.

[wanne]

Auch ist die Sache mit den FIDO2-Tokens keine asymmetrische Kryptographie,

Doch.
Siehe: https://fidoalliance.org/specs/fido-v2. ... -extension
Oder: https://docs.yubico.com/yesdk/users-man ... ecret.html

weil’s eben um die gegenwärtige Realität geht.

Wie gesagt: Du machst das System Unsicherer indem du mit Aufwand zusätzliche Angriffsvektoren schaffst.

Auch hier ohne dir zu nahe treten zu wollen: bislang hat keiner so ein Dongle aufgemacht.

FIDO2 ist nicht sonderlich verbreitet. Entsprechend ist mir keiner bekannt, der das öffentlich demonstriert hat. Wir haben aber gegen Smartphones und Spielekonsolen, die weitestgehend die gleiche Technologie nutzen um Credentials zu "verstecken" diverse Angriffe gesehen. Daneben gab es diverse Attacken gegen Zufallsgeneratoren und das PIN-Eingabelimit. Und zwar sogar gegen die YubiKeys, die als absolute Vorzeigegeräte gelten. Beides öffnet den Weg zum Key.

es ist bis auf wenige Ausnahmen

Ja eben... Gar nicht gespeichert kann unter keine Ausnahme ausgelesen werden.

Ebenfalls ohne dir zu nahe treten zu wollen: wenn dein urandom kaputt ist, ist es völlig egal, ob du ein FIDO2-Token, eine Passphrase oder sonstwas für dein LUKS verwendest – das ist dann alles gleichermaßen kaputt. Entsprechend leuchtet mir nicht ein, warum du das hier anführst.

Genau darum geht es mir doch: Es gibt keinen Angriff, den der Stick vereiteln könnte. Aber eine Menge zusätzliche Angriffsvektoren. Und ich will wirklich nicht über die Komplexität dieser Angriffe reden. Durch zusätzliche Angriffsfläche wird ein System niemals sicherer immer nur Unsicherer. Nie sicherer. Und alle dumme rum lamentiererei wie plausibel diese Angriffe sind, lenkt von diesem Fakt ab, der der einzig relevante ist.

Warum sollte da was angepasst werden? Aus der KDF fällt eh immer die gleiche Länge raus, egal, wieviel man auf der anderen Seite reinschiebt. Klar ist längerer Input == besser, aber warum man da irgendwas „matchen“ sollte, erschließt sich mir nicht.

Dadurch das am Ende eh immer 512Bit raus fallen, ist mehr als 512Bit nicht mehr wirklich besser. Aber weniger macht es halt einfacher gegen den Input zu bruteforcen statt gegen den output. Deswegen nimmt man im Normalfall schlicht das gleiche Entropie wie hinten raus fällt.

Wo kommen die 128 Bit her? Soweit ich weiß, gibt hmac-secret 256 Bit zurück

Die dann auf 16Byte gekürzt werden um mit dem alten CAP-Standard kompatibel zu bleiben, der (optional) MD5 genutzt hat:
https://fidoalliance.org/specs/fido-v2. ... -extension

Ich sehe also immer noch nicht, wie ein FIDO2-Token unsicherer sein soll

Ich habe die ca. 20 mögliche Angriffsvektoren aufgeführt, die zusätzlich existieren. Und du fragst immer noch, warum das unsicherer ist?! Ja jedes mal, wenn mal wieder so ein Hardware-Token gebrochen wird, bringt der Hersteller ein neues raus. Das führt dazu, dass gegen die aktuellsten immer keine Angriffe bekannt sind. Ja bis jetzt hat noch niemand P-256 gebrochen. Aber das gleiche galt auch mal für DES, RC4 und RSA-128. Wenn du irgend eine dumm-Verschlüsslung erfindest, ist die sicher auch "bis jetzt" noch nicht gebrochen. Ich will nicht darüber diskutieren, wie wahrscheinlich es ist, dass da ein erfolgreicher Angriff raus kommt. Ich will dich fragen, warum du sinnlos zusätzliche Angriffsfläche schaffst, die es ohne nicht gäbe.

[wanne]

Veeam erzeugt als Backup ganz normale Dateien.

LUKS erzeugt doch auch ganz normale Dateien (unter /dev) Die kannst du auch auf einen Stick kopieren. Worum es mir geht, dass Veeam eben nicht die zu sichernden Dateien einzeln verschlüsselt, was sehr kompliziert sicher zu bekommen ist. Stattdessen verschlüsselt es das gesamte Dateisystem der VM. Ob du darunter nochmal ein (unverschlüsseltes) Dateisystem hast, ist sowohl LUKS wie auch für die Sicherheit ziemlich wurst.
Zur Veranschaulichung:
https://serverdiary.com/linux/how-to-cr ... ryptsetup/

[niemand]

Doch.
Siehe: https://fidoalliance.org/specs/fido-v2. ... -extension

Dann siehe doch einfach mal selbst dort: „This extension is used by the platform to retrieve a symmetric secret from the authenticator when it needs to encrypt or decrypt data using that symmetric secret.“

FIDO2 ist nicht sonderlich verbreitet. Entsprechend ist mir keiner bekannt, der das öffentlich demonstriert hat.

Microcontroller sind sehr verbreitet. Die stecken milliardenfach irgendwo drin, und ganze globale Firmenimperien basieren darauf, dass keiner ihre Firmware auslesen, und damit einfach eine Kopie des Produktes anbieten kann – denn die restliche Hardware nachzubauen, ist heutzutage trivial.

Wenn du weiter auf diesem Unsinn aka „kann man problemlos auslesen“ bestehst, dann schicke ich dir einen auslesegeschützten ATtiny, das ist ein handelsüblicher Microcontroller für weniger als ’nen Euro, und du demonstrierst mir, wie du den ausliest. Und dann erklärst du mir, wie du einen deutlich mehr auf diesbezügliche Sicherheit getrimmten μC von etwa NXP denn so problemlos auslesen möchtest, wenn du das mit diesem nicht einmal auf Sicherheit optimierten, billigen Teil schon nicht schaffst.

Und das meine ich ernst – schreib mir via PN deine Adresse, und morgen ist ein ATtiny412 zu dir unterwegs, in dessen Flash sich 32 Bytes (entsprechend eines geheimen 256 Bit langen Schlüssels) befinden, die du ja dann problemlos hier präsentieren können wirst.

(An dieser Stelle hab ich irgendwie Déjà vu – ich hab dir schonmal in irgendeinem Kontext angeboten, die von dir aufgestellten Behauptungen, wie einfach man etwas knacken könne, dann auch mal zu belegen. Hast du nie getan …)

Wir haben aber gegen Smartphones und Spielekonsolen, die weitestgehend die gleiche Technologie nutzen um Credentials zu "verstecken" diverse Angriffe gesehen.

Es werden keine Credentials auf dem Token gespeichert oder versteckt! Offensichtlich meinst du irgendeine andere Technologie. Bei der, um die es hier geht, ist ein geheimer Schlüssel auf dem Controller des Tokens gespeichert, dazu eine Anwendung, die damit Sachen verschlüsseln kann.

Die Funktionsweise ist grob: Das Token bekommt die Eingangsdaten von systemd-cryptsetup, verschlüsselt diese bei passender PIN mithilfe des geheimen Schlüssels und gibt das Ergebnis wieder aus. Dieses Ergebnis wird von systemd-cryptsetup wie eine normale Passphrase oder ein Keyfile weiterverarbeitet, im LUKS-Header wird dafür ganz normal ein Keyslot belegt. Der geheime Schlüssel des Tokens (Obacht: nicht zu verwechseln mit dem geheimen/privaten Teil eines Schlüsselpaares – es gibt hier kein Schlüsselpaar!) verlässt den Controller nie, er ist von außen nicht auslesbar, und man kann ihn auch nicht aus einem Speicherdump des μCs extrahieren, weil dieser nämlich den Leseschutz gesetzt hat.

Die dann auf 16Byte gekürzt werden um mit dem alten CAP-Standard kompatibel zu bleiben, der (optional) MD5 genutzt hat:
https://fidoalliance.org/specs/fido-v2. ... -extension

Könntest du die konkrete Stelle bitte zitieren oder direkt verlinken? Ich kann das auch nach mehrfachem Lesen des Dokuments nicht daraus ableiten – im Gegenteil. Auch die cryptsetup-Doku gibt nichts her, das auf eine nachträgliche Kürzung der Ausgabe hinweisen würde.

Genau darum geht es mir doch: Es gibt keinen Angriff, den der Stick vereiteln könnte.

Das ist eine Art Scherz, oder? In diesem Kontext vereitelt diese Methode Brute-Force gegen schwache Passphrases genauso, wie das Abgreifen der ungeschützten Schlüsseldatei. Beides sind reale Bedrohungen, die in der Vergangenheit für Schäden verantwortlich waren, während der von dir konstruierte Kram reine Fiktion ist: Leseschutz millionenfach bewährter μC aushebeln.

Ohne dich irgendwie abwerten zu wollen, aber vielleicht solltest du dich wirklich erstmal mit dieser Technologie beschäftigen, bevor du da solche absurden Behauptungen raushaust.

Aber weniger macht es halt einfacher gegen den Input zu bruteforcen statt gegen den output.

Dass die KDF jeden einzelnen Versuch an dieser Stelle um mehrere Größenordnungen (und das ist wörtlich zu verstehen) verzögert, hast du hier übersehen?

Ich habe die ca. 20 mögliche Angriffsvektoren aufgeführt, die zusätzlich existieren

Du hast nicht einen aufgeführt, bei dem die Nutzung eines FIDO2-Tokens unsicherer wäre, als eine Passphrase mit deutlich geringerer Entropie oder ein Keyfile ganzlich ohne jeden Schutz gegen Auslesen. Stattdessen hast du irgendwelche hypothetischen Szenarien gezeichnet, die einerseits in der Praxis der Gegenwart vollkommen irrelevant sind (z.B. die Quantencomputer (die hier eh nix können würden, wie ich aufgezeigt habe)), und andererseits von Voraussetzungen ausgingen, die nunmal nicht vorliegen (etwa problemloses Auslesen von geschütztem Speicher). Und ich denke, da kommt auch nix Anderes mehr.

Ich möchte an dieser Stelle nochmal auf das obenstehende Angebot hinweisen, dass ich dir einen billigen μC schicke, und du mir zeigst, wie du den problemlos überhaupt ausliest! Und wenn es nur dafür sorgt, dass du dich mal mit dem beschäftigst, über das du hier die ganze Zeit fabulierst – das wäre schon ein enormer Gewinn.

Edits: Typos, Formulierungen, weitere Ausführungen