Ubuntu Budgie Installation Verschlüsselung: Überschreiben nötig?
Hallo,
ich bin gerade dabei Ubuntu Budgie 18.04 zu installieren. Ich habe mich dazu entschlossen bei der Installation die Verschlüsselung der ganzen Festplatte auszuwählen (ist ein Notebook auf dem viele privaten Daten, etc drauf sind & das ich unterwegs mitnehme). Wenn man nur auf "weiter" klick wird man dazu aufgefordert ein Passwort für die Verschlüsselung einzugeben. Soweit alles klar.
Darunter allerdings kann man noch einen Haken setzen "für erhöhte Sicherheit die ganze Festplatte überschreiben". Da steht allerdings dran das es die Installationszeit deutlich erhöhen wird (& es ist einen 960GB Platte...).
Lohnt sich das bei einer neuen SSD die bisher noch nicht genutzt wurde (frisch aus der Verpackung)? In wie fern gefährdet das die Sicherheit der Verschlüsselung?
Vielen Dank!
3 Antworten
Wenn Du die Platte verschlüsselst und eine Installation durchführst, wirst Du danach noch eine signifikante Anzahl an Sektoren haben, die nicht angefasst wurden und 0en enthalten.
Anhand der belegten Sektoren kann dann z.B. heuristisch bestimmt werden welches Dateisystem vorliegt.
So bekomme ich dann zumindest schonmal ein Cryptotext/Ciphertext-Paar, daß mir bei weiteren Schritten hilft (im Sinne einer Zusicherung z.B., daß ich den richtigen Schlüssel ermittelt habe).
----
Je nachdem,was neben der Grundinstallation noch alles auf die HDD kommt, ist es also nicht zwingend nötig. Du kannst auch später auf das verschlüsselte Gerät einfach einige große Dateien aus 0en schreiben, dadurch hast Du einen ganz ähnlichen Effekt.
Erh, *hust* es muß natürlich Ciphertext/Cleartext-Paar lauten.Verdammich ...
Ja definitiv, Du mußt übrigens nicht /dev/random nehmen /dev/urandom tut es beim Überschreiben, weil Du anhand der Daten nicht die LCG-PArameter direkt rückermitteln kannst.
Trick 17, um es schnell hinzubekommen:
Boote ein Livesystem, richte ein plain Cryptomapping mit Schlüssel aus /dev/random ein. Danach schreibst Du 0en in das Mapping. Das geht deutlich schneller und hat den gleichen Effekt wie ein zuvoriges Überschreiben mit Daten aus /dev/random.
cryptsetup open --type plain -d /dev/random /dev/<block> <mapping>
Danach hast Du ein Blockgerät /dev/mapper/mapping, in welches Du z.B. mit:
dd if=/dev/zero bs=1M of=/dev/mapper/mapping
Einfach 0en pumpen kannst,.
-----
Wie gesagt, entscheiden muß das jeder für sich selbst, ebenso wie die Frage, ob man z.B. DISCARDs/ATA-TRIMs deaktiviert.
------
Nachtrag: Korrekte Implementierung vorausgesetzt, macht ein Secure-Erase im Prinzip genau das Gleiche.
So bekomme ich dann zumindest schonmal ein Cryptotext/Ciphertext-Paar, daß mir bei weiteren Schritten hilft (im Sinne einer Zusicherung z.B., daß ich den richtigen Schlüssel ermittelt habe).
Ich komme nicht ganz mit, wie willst du das denn machen? Es wird doch nur der "neue" Inhalt verschlüsselt und ob auf der Platte mal nullen standen und immernoch stehen, weil sie bis dato noch nicht überschrieben wurden kann doch eigentlich egal sein oder? Oder willst du tatsächlich darauf hinaus das du so leichter erraten kannst welche Blöcke verschlüsselt sind um genau diese gezielt mit Bruteforce zu knacken und um das Passwort so zu ermitteln?
Wäre als Alternativvariante nicht die Methode die Luks benutzt mindestens genauso gut? Nach Eingabe des Passworts (oder in meinem Fall der USB Stick) hat der ja auch blitzschnell überprüft ob der Key stimmt. Meine Vermutung ist, dass die user defined key's die ich anlegen kann im Prinzip den "master key" jeweils verschlüsseln&entschlüsseln mit z.B. AES und das System mit dem master key ver-&entschlüsselt wird damit es zu keiner Datenredundanz kommt bei verschiedenen user defined keys. Trotz alledem wird wohl irgendwo eine kleine verschlüsselte Datei liegen, die einen für das System bekannten Wert von Bedeutung hat und zum Test einfach mal entschlüsselt und geprüft wird (vllt liegt im RAM der Hash (raw von der Platte geladen) und der output vom fd nach dem entschlüsseln wird gehasht & geprüft?).
Hab mich noch nie groß mit den luks internals auseinander gesetzt, würde mich aber mal interessieren.
Fangen wir mit der einfachsten Variante an:
Ich lege nur das Dateisystem an. Zum Beispiel der Ort der Superblöcke. Ebenso z.B. der Speicherort eines Internen Journal und anderer Metadaten.
Ich kann also anhand der belegten Sektoren, auf Basis der offenen Algorithmen und bekannten Strategien das verwendete Dateisystem bestimmen.
Wird nun die Installation vollzogen, werden zwar weitere Blöcke beschrieben, aber die Chancen stehen gut, daß beispielsweise bei EXT* einige der Superblöcke noch brav von 0en umschlossen sind. Solange also dieser Zustand anhälgt kann ich das Dateisystem sicher identifizieren.
Wenn ich aber weiß, welches Dateisystem verwendet wurde, dann weiß ich auch was in diesen Sektoren drin stehen muß und ich kann auslesen was als Ciphertext drin steht.
Das hilft mit natürlich erstmal nicht ein sicheres Verfahren zu brechen und an die verschlüsselte Information zu kommen, aber durch die Paarung kann ich zuverlässig prüfen, ob ein Schlüsselkandidat der richtige ist.
Nehmen wir an, ich meine einen Schlüssel gefunden zu haben. Um diesen zu prüfen muß ich diesen anwenden und anfangen die HDD zu lesen. Sobald ich bekannte Filemagics finde etc. kann ich relativ sicher sein, daß der Schlüssel der richtige ist, der Aufwand ist jedoch höher.
-------
Was LUKS betrifft, bei LUKS stehen im Header alle nötigen Informationen, um den Schlüsselkandidat zu prüfen und zuzusichern, daß es sich um den richtigen Schlüssel handelt. Andererseits ist das zuverlässige Erkennen einen Ciphertext/Cleartext-Paares ggf. auch ein Puzzlestein für eine geeignete Side-Channel-Attacke des verwendeten Verfahrens.
Somit wäre das ein unnötiges 'Geschenk' für die Analyse, das nicht notwendigerweise gemacht werden muß.
Den LUKS-Header kann ich seit einiger Zeit auch bequem detachen und separat aufheben.
Wie arbeitet LUKS nun:
Der Masterkey wird für die Keyslots durch das Passwort verschlüsselt. Das Passwort wird vorher einem Keystrectching unterzogen und mit den AF-Stripes verknüpft. Mit dem Ergebnis wird der MAsterkey neu verschlüsselt und im Slot abgelegt. Dazu kommt ein Hash welches die Prüfung des Schlüsselkandidaten übernimmt. Gebe ich also das PW ein, wird wieder das Stretching angewandt und gegen das Hash geprüft ob das Ergebnis (der Slotschlüssel) zum Hash passt, andernfalls gehe ich von einer Fehleingabe aus. Danach wird aus den Slotdaten mit dem Slotschlüssel der Masterkey entschlüsselt und gegen das hash geprüft. Passt das soweit, geh LUKS davon aus den richtigen Schlüssel vorliegen zu haben.
Deswegen müssen die Hashes (weil Prüfung) auch kryptographisch nicht sicher sein, sie prüfen nur die Plausibilität des Schlüssels, im schlimmsten Falle würde also ein Fehlerhaftes Mapping erzeugt und die Daten bleiben unlesbar. Beim Strechting wiederum ist die Qualität des Hashalgorithmus ausschlaggebend.
-------
Alle Angaben ohne Gewähr, da lediglich aus dem Kopf geschrieben, für weitere Informationen gibt es unter anderem :
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
Die FAQ, die einige Fragen bespricht und auch das LUKS-Format etc. ist offen dokumentiert, wobei für Version2 vieles erneuert wurde (JSON-Format des Headers, flexiblerer Speicherort des Schlüssels ...)
Oh okay, dann lag ich wohl garnicht mal so arg daneben. Danke Dir :)
Man kann eine Festplatte schnell formatieren und man kann sie durch überschreiben formatieren (langsam). Bei dem schnell Formatieren können alte Daten wiederhergestellt werden (In deinem Falle wohl kaum). Ich würde sagen mehr meinen die damit nicht. Die Verschlüsselung betrifft das dann nicht.
Ok, dann ist das nur für den Fall das man bereits vorher eine unverschlüsselte Installation mit Daten hatte, die dann eben noch wiederherstellbar wären?
Nein, das ist nicht nötig.
Vielen Dank!
Ich hab keine HDD, nur die SSD.
Ich hab mal eine 500GB SSD mit dd mit der /dev/zero überschrieben und das hat schon ewig gedauert, aber bei einer 960GB SSD mit der /dev/random (?) dürfte es dann nochmal um ein vielfaches länger dauern?