Schwachstellen einer FDE und Alternativen

Internet Internet Sicherheit
#1

Hallo,
mit Interesse habe ich gestern Nacht folgenden Thread gelesen:
http://www.apfeltalk.de/forum/problem-truecrypt-pre-…
(insb. letzte Seite). Demnach ist eine FullDiskEncryption unsicherer als eine Verschlüsselung einzelner Dateien, da bei einer FDE bereits eine Menge unveränderlicher Klartext an bekannten Stellen (Anfang einer Partition, Ende einer HD unter Windows, Metadaten von ext bei Linux) vorhanden ist.
Wohlgemerkt möchte ich hier nicht auf das Problem von Keyloggern etc. eingehen.

Meine eigentliche Frage ist folgende:
welche vernünftige Verschlüsselungslösung gibt es denn dann bei einer Windows (7) - Installation?

Bisher habe ich mir folgendes gedacht:
ich werde zwei Festplatten haben, eine SSD für Windows und alle Programme die beim Systemstart typischerweise so geladen werden (FF, Thunderbird, Winamp, Miranda, BOINC, etc.) sowie eine normale Festplatte als Storage für Spiele und die ganzen Daten.
Um o.g. Problem zu umgehen, werde ich auf dieser zweiten HD einfach nur einen großen Container erstellen. Darin befindlich nicht nur alle Bilder, Musik, etc. sondern natürlich auch FF und Thunderbird-Profile.
Soweit, so gut.

Das Problem, welches sich jetzt stellt: was ist mit den ganzen anderen sensiblen Daten, die Windows so anlegt? Das heißt ‚Dokumente und Einstellungen‘, Swapfile, etc. Diese in einen Container zu stecken geht wahrscheinlich nicht, da sie Windows beim Systemstart ja benötigt. Eine FDE ist aus oben genannten Gründen unsicherer als ein Container mit gleichem Algorithmus. Also, was tun? Gibt es eine Möglichkeit, solche Dateien zu verschlüsseln, ohne das Windows den Start verweigert und trozdem um eine FDE herum zu kommen?

MfG

#2

mit Interesse habe ich gestern Nacht folgenden Thread gelesen:
http://www.apfeltalk.de/forum/problem-truecrypt-pre-…
(insb. letzte Seite). Demnach ist eine FullDiskEncryption
unsicherer als eine Verschlüsselung einzelner Dateien,

Das ist IMO Quatsch. Denn die Behauptung…

da bei einer FDE bereits eine Menge unveränderlicher Klartext an
bekannten Stellen (Anfang einer Partition, Ende einer HD unter
Windows, Metadaten von ext bei Linux) vorhanden ist.

…ist falsch.

Schauen wir mal die Stellen an:

a) Anfang einer Partition:
Bei FDE weißt du ja noch nicht mal wo überhaupt eine Partition anfängt, da ja die gesamte Platte verschlüsselt ist und somit auch die Partitionstabelle. Man muss die erste Partition ja nicht bei Sektor 0 beginnen lassen, sondern lässt eben ein paar MB am Anfang frei. Dann weißt du nicht mal wo überhaupt die erste Partition anfängt.

b) Ende einer Partition:
Gleiche Argumentation wie bei a)

c) Metadaten:
Wo die Metadaten liegen hängt vom Dateisystem, der Partitionsgröße und dem Beginn der Partition ab. Da du keinen dieser Parameter kennst, hast du auch keinen Peil wo die Metadaten liegen könnten und daher kannst du auch hier keine Known-Plaintext Attacke fahren.

d) Nullen
In dem obigen Thread auf Apfeltalk wurde auch noch als Argument verwendet, dass weite Teile der Festplatte aus Nullen bestehen würden. Das betrifft allerhöchstens nur fabrikneue Platten und selbst da kann man das ganz einfach umgehen in dem man schnell ein dd if=/dev/random of=/dev/sdX macht. Bei Platten die bereits einigermaßen gut genutzt wurden, ist ohnehin fast jeder Sektor schon mal überschrieben worden und da ist nichts mit großen Nullen-Abschnitten.

Also:
Wenn du nicht grad die erste Partition am ersten Sektor anfangen lässt und nicht direkt am letzten Sektor enden lässt, die Festplatte (so sie denn neu ist) mit Zufallsdaten einmal überschreibst, dann ist da überhaupt keine Known-Plaintext Attacke möglich.

Jetzt schauen wir uns im Gegensatz dazu mal die Verschlüsselung einzelner Dateien an, die ja angeblich sicherer wäre, da dort weniger Known-Plaintext vorhanden wäre. Wie oben geschildert gibt es bei FDE überhaupt keinen Known-Plaintext, wenn man das halbwegs vernünftig macht.
Bei Dateien jedoch ergibt sich schon alleine aus dem Dateinamen oder dem Speicherort meist der Dateityp. Und da jeder Dateityp mit einem bestimmten Header beginnt, hast du hier dann fast bei jeder Datei einen Known-Plaintext.

Ganz zu schweigen davon, dass Dateiname und Speicherort alleine meist schon viel über den Inhalt verraten. Der Inhalt einer Datei mit dem Namen „Passwörter.doc.gpg“ ist wohl relativ offensichtlich.

Fazit:
Bei der Verschlüsselung von Einzeldateien gibst du allein schon aufgrund der nicht verschlüsselten Dateinamen und der Speicherorte der Dateien jede Menge Information preis. Außerdem ist durch den Dateiheader viel eher eine Known-Plaintext-Attacke möglich als bei FDE.
Und die Sache mit den unverschlüsselten Dateinamen ist noch dazu hier viel wichtiger, da ein modernen Verschlüsselungsverfahren mit ausreichender Schlüssellänge auch mit noch so vielen bekannten Plaintexten nicht wirklich knackbar ist.

#3

Moin,
danke für deine Antwort. Habe jetzt den ganzen Tag damit zugebracht Schwachstellen von AES (nur theoretischer Natur) und Pre-Boot-Authentication (bei TC größtenteils ausgeräumt) zu recherchieren.

Da ich aber bestenfalls ein gebildeter Laie bin noch eine Frage:
wenn ich jetzt, der Einfachheit halber mit Knoppix, die ganze Platte mit Zufallszahlen überschreibe und anschließend Win7 installiere, was die Platten ja mit NTFS neu formatieren wird, bleiben die Zufallszahlen dann wirklich bestehen? Physisch wahrscheinlich ja, NTFS wird sie wahrscheinlich als frei makieren. Wenn sich aber jetzt TC ans Werk macht, verschlüsselt es dann die physisch vorhandenen Zufallszahlen oder die logisch vorhandenen Nullen?

MfG

#4

wenn ich jetzt, der Einfachheit halber mit Knoppix, die ganze
Platte mit Zufallszahlen überschreibe und anschließend Win7
installiere, was die Platten ja mit NTFS neu formatieren wird,
bleiben die Zufallszahlen dann wirklich bestehen?

Sicher. Sonst müsste Win7 ja die komplette Platte mit Nullen überschreiben bei der Formatierung, was es nicht macht.

Physisch wahrscheinlich ja, NTFS wird sie wahrscheinlich als frei
makieren. Wenn sich aber jetzt TC ans Werk macht,
verschlüsselt es dann die physisch vorhandenen Zufallszahlen
oder die logisch vorhandenen Nullen?

Es gibt keine logisch vorhandenen Nullen. Alles was freier Speicherplatz ist, hat keinen definierten Wert. Außerdem setzt Truecrypt ja direkt auf dem Device auf, d.h. es ist vollkommen egal, was NTFS glaubt, dass ein bestimmter Bereich für einen Wert hätte. Das einzige was zählt ist, was auf dem Raw-Device vorhanden ist, und da sind natürlich die Zufallszahlen drauf.

1 Like