"Best practices" für Komplettverschlüsselung von SSDs?

[Atomic]

Hallo zusammen,

ich wollte mir in nächster Zeit (eilt nicht besonders) eine SSD für meinen Laptop zulegen und diese dann komplett verschlüsseln.

Allerdings kursieren ja regelrechte "Horrorgeschichten" zu diesem Szenario im Netz. Dass TRIM nicht bzw. nicht richtig funktioniert; dass Wear-Leveling mehr oder weniger ausgehebelt wird und ähnliches.

Daher die Frage: Kristallisiert sich da schon sowas wie "best practices" heraus?
Einfach trotzdem verschlüsseln und aufs Beste hoffen, mag ich nicht Auch der Vorschlag, 10-20% nicht zu partitionieren, ist jetzt nicht wirklich das, was ich mir unter "best practice" vorstelle^^

Wie schaut es mit SSDs aus, die die Verschlüsselung selbst übernehmen im Controller. Erstens funktionieren damit die oben genannten Mechanismen noch, zweitens wird Last von der CPU genommen (ich hab keine HW-Beschleunigung )
Andererseits habe ich davon noch nicht viel gehört und traue der Sache daher nicht so^^ Wo gebe ich das Passwort ein? Wie funktioniert das? Funktioniert das überhaupt?

Das Problem ist doch, dass die notwendigen Informationen (für TRIM &c.) vom Dateisystem nicht durch die Verschlüsselungsschicht an den Controller kommen (vereinfacht ausgedrückt. Stimmt das so?), oder? Das Dateisystem also "gar keine Ahnung" hat, was es da schreibt? Was aber, wenn das Dateisystem selbst die Verschlüsselung übernimmt? ZFS soll sowas ja beispielsweise können (und BTRFS dann vielleicht irgendwann auch?).

Das sind in Kürze die Gedanken, die mir in den Kopf kommen. Für mehr Anregungen bin ich sehr dankbar!

Viele Grüße
Atomic

[syssi]

Meine "best practice" bei SSDs ist mittlerweile bei cryptfs angekommen und ich verschluessel nur noch mein Homeverzeichnis. Hier im Forum findet sich ein Thread mit einer simplen AES-Benchmark Anleitung. Dabei sieht man schnell, wie wenig Durchsatz CPUs machen, wenn es nicht gerade ein i5/i7 ist. Folglich nimmt man einer SSD/HDD jegliche Geschwindigkeitsvorteile. Das TRIM bisher nicht unterstuetzt wird und manche Leute nur Teile der SSD partitionieren, um Wear-Leveling zu erhalten ist ebenfalls laestig. Deshalb habe ich lieber ein schnell bootendes/laufendes System und ein wenig Sicherheit ueber meine Daten, sollte das Laptop mal verloren gehen.

Gruss syssi

[Atomic]

Hallo syssi,

vielen Dank für deine Antwort.

ich verschluessel nur noch mein Homeverzeichnis.

Das ist für mich leider keine Option. Es mag vielleicht rational nur schwer begründbar sein, aber ich fühle mich bei so einer Konstellation unwohl. Gerade bei Laptops.

Hier im Forum findet sich ein Thread mit einer simplen AES-Benchmark Anleitung. Dabei sieht man schnell, wie wenig Durchsatz CPUs machen, wenn es nicht gerade ein i5/i7 ist.

Das Problem dürfte ja wegfallen, wenn sich die SSD selbst um die Verschlüsselung kümmert. Abgesehen davon, ist der reine Datendurchsatz für mich gar nicht der entscheidende Punkt für eine SSD.

Gibt es noch weitere Meinungen? Oder sind die SSDs bei den paranoiden Leuten noch nicht so verbreitet?^^

Viele Grüße
Atomic

[habakug]

Hallo!

Das Problem ist doch, dass die notwendigen Informationen (für TRIM &c.) vom Dateisystem nicht durch die Verschlüsselungsschicht an den Controller kommen (vereinfacht ausgedrückt. Stimmt das so?)

Ja, das stimmt, die Trim-Kommandos könnten einem Angreifer Anhaltspunkte über das Dateisystem und die verwendeten Blöcke liefern. Dennoch läßt sich seit Kernel 3.1 mit ":allow-discards" als Zusatz zur "cryptdevice"-Option diese Verhalten abschalten. Es soll aus genannten Sicherheitsgründen jedoch nicht/nie default werden [1].

Gruß, habakug

[1] http://article.gmane.org/gmane.linux.ke ... evel/14134

[debianoli]

Hat man diese Probleme bei der Leistung mit SSDs auch, wenn man eine sehr große Image-Datei per dd erstellt, diese verschlüsselt und Loop mountet? Wäre zumindest eine Lösung für wichtige Daten. Ich nutze solche verschlüsselten img-Container-Dateien auf meinen USB-Sticks.

[Atomic]

Hallo!

die Trim-Kommandos könnten einem Angreifer Anhaltspunkte über das Dateisystem und die verwendeten Blöcke liefern.

Das verhält sich für den Angreifer dann also ähnlich wie Festplatten, die vorher nicht mit Zufallszahlen überschrieben wurden? Es ist also unter anderem möglich, den Füllstand der Festplatte abschätzen zu können.
Klar ist das nicht optimal, aber darin sehe ich ein kleineres Sicherheitsrisiko als bei einem unverschlüsselten "/", wie von syssi vorgeschlagen. Oder unterschätze ich die Gefahr?

Gleichzeitig bedeutet das dann aber, dass die SSD in keiner Weise mehr "kastriert" wird, richtig?

Hat man diese Probleme bei der Leistung mit SSDs auch, wenn man eine sehr große Image-Datei per dd erstellt, diese verschlüsselt und Loop mountet?

(Achtung, das beruht auf dem, was ich inzwischen verstanden habe. Ich lasse mich gerne eines besseren belehren)
Prinzipiell denke ich: Ja. Zumindest dann, wenn das Image-File sehr groß wird und mit Zufallswerten erstellt wurde. Dann dürftest du in das selbe Problem laufen wie bei einer Komplettverschlüsselung (für den Controller ist die komplette SSD gefüllt, Performance sinkt). Bei kleineren Imagegrößen sollte das etwa der Lösung eines verschlüsselten "/home" entsprechen.

Viele Grüße
Atomic

[syssi]

Alles dreht sich darum, dass Flash-Bausteine auf SSDs eine beschraenkte Lebensdauer besitzen. Damit die gesamte SSD gleichmaessig abgenutzt wird arbeitet der Controller der SSD in langweiligen Momenten daran Bloecke auf ungenutzte Bereiche zu kopieren und den alten Speicherort wieder auszunullen. Partitioniert man also eine SSD von Anfang bis Ende und schreibt in diese Partition(en) Zufallszahlen, so gibt es auf dem Datentraeger keine freien Stellen mehr. Das Feature Wear-Leveling hat man damit also ausgehebelt. Manche befehlen sich damit, indem sie einfach einen unpartitionierten Bereich uebrig lassen oder alternativ auch unverschluesselte Partitionen besitzen, so dass es noch ein wenig Platz zum "haushalten" gibt.. aber selbst das ist nicht optimal.

TRIM ist ein weiteres Helferlein in diesem Problemkomplex. Dateien, die man auf einer Festplatte loescht werden in der Regel nur als geloescht markiert. Verschwinden tut der Inhalt einer Datei erst, wenn er von einer anderen Datei ueberschrieben wird. Ohne TRIM fuellt sich ein Medium also auch mit "Zufallszahlen" und nach einiger Zeit bleiben keine "ausgenullten" Bereiche mehr. An diesem Punkt setzt TRIM an und sorgt dafuer, dass Dateien (wenn die SSD sich langweilt) ausgenullt werden und wieder Platz fuers Wear-Leveling zur Verfuegung steht.

Wenn Cryptdevice mittlerweile TRIM unterstuetzt, dann waere noch interessant, ob auch LVM mittlerweile unterstuetzt wird. Ich vermute mal, ja.

[crhn]

Also ich kann dir jetzt nicht sagen ob das "the best practice" ist, aber ich hab meine SSD seit 2 Jahren und bis jetzt passt immer noch gleich viel drauf wie am ersten Tag.
Ich hab ne unverschlüsselte /boot Partition und der Rest ist in nem verschlüsseltem (dm-crypt/ luks) LVM (mit / /home und swap).
Mein Laptop ist nen X200 Thinkpad mit nem Intel Core 2 Duo. Der hat so ne AES Hardwarebeschleunigung oder sowas, jedenfalls gibt's dafür nen aes_x86_64 Kernelmodul mit dem das ganze nicht Sonderlich auf die CPU geht, im Prinzip garnicht.
Wenn ich den Benchmark aus dem Wiki mach komm ich auf 222MB/s lesend, schreibend muss ich erst noch raussuchen (oder ich mach's nochmal falls dir das helfen würde).
Als System hab ich nen Debian Testing. Der Kernel unterstützt TRIM (das lässt sich mit nem discard in der fstab aktivieren) soweit ich weiß.

Wegen der CPU. In meinem "Server", ein Alix Board mit 200MHz CPU gibt's wohl auch so nen Stück Hardware das AES kann. Da gibt's dann auch so nen Modul für. Allerdings ist da nur ne CF Karte drin. Aber soweit ich das beurteilen kann geht da die Ent-/Verschlüsselung dort auch nicht auf die CPU.

Jedenfalls halte ich diese Horrorgeschichten für genau das. Wie in so nem billigen Horrorfilm wo nur die hübscheste Schauspielerin überlebt und alle anderen nacheinander beim rausgehen....

[syssi]

Wenn ich den Benchmark aus dem Wiki mach komm ich auf 222MB/s lesend, schreibend muss ich erst noch raussuchen (oder ich mach's nochmal falls dir das helfen würde).

Was auch immer du da gemessen hast... das war kein Durchsatz deiner Crypto. Wuerde mich jedenfalls sehr wundern. Ich betreibe ebenfalls ein X200. Das eingesetzte AES-Modul ist das Standard-Modul fuer i686 Prozessoren und hat nichts mit einer HW-Implementierung zu tun. Deshalb falle ich vom Glauben ab sollte der Core 2 Duo 222MB/s an Cryptdevice-Durchsatz schaffen.

Gruss syssi

[Atomic]

Hallo zusammen,

[...]Ohne TRIM fuellt sich ein Medium also auch mit "Zufallszahlen" und nach einiger Zeit bleiben keine "ausgenullten" Bereiche mehr. An diesem Punkt setzt TRIM an und sorgt dafuer, dass Dateien (wenn die SSD sich langweilt) ausgenullt werden und wieder Platz fuers Wear-Leveling zur Verfuegung steht.

Zusammengefasst: Für die Verschlüsselung ist ein volles Laufwerk ideal, für die SSD der worst case?

Jedenfalls halte ich diese Horrorgeschichten für genau das. [...]

Naja, wie sehr sich das letztendlich wirklich auf die Performance und/oder Lebensdauer auswirkt, sei mal dahingestellt. Dass es zumindest nicht optimal ist, erscheint mir nach den Ausführungen hier sehr nachvollziehbar.

Wenn ich den Benchmark aus dem Wiki mach komm ich auf 222MB/s lesend[...]

Das eingesetzte AES-Modul ist das Standard-Modul fuer i686 Prozessoren und hat nichts mit einer HW-Implementierung zu tun. Deshalb falle ich vom Glauben ab sollte der Core 2 Duo 222MB/s an Cryptdevice-Durchsatz schaffen.

Warum erscheint dir die Zahl so unwahrscheinlich? Selbst mein betagter T5670 schafft im Benchmark ~140MB/s (zugegeben, mit Truecrypt getestet, da geht's so schön einfach ). So übertrieben finde ich den Wert daher gar nicht.

Nachdem ich eben noch ein paar weitere Gruselgeschichten, diesmal zum Thema der integrierten Verschlüsselung, gelesen habe, sieht für MICH die beste Idee im Moment so aus: SSD per Software komplett verschlüsseln und die kleine(?) Sicherheitslücke in Kauf nehmen und TRIM aktivieren -- sofern das alle Schichten (LVM) können. (Oder doch auf eine SSD verzichten^^)

Oder hat doch noch jemand einen Masterplan und wartet noch darauf, den großen Auftritt damit hinlegen zu können?

Viele Grüße
Atomic

Edith warnt: Lesen gefährdet die Blödheit!
Ich hätte mir natürlich auch einfach mal den Benchmark im Wiki anschauen können Da komme ich auf ziemlich genau die Hälfte des Truecrypt-Wertes (Multithreading?). Damit erscheint mir der Wert tatsächlich auch ziemlich gut. Naja... meine CPU ist wohl noch älter als gedacht^^

[crhn]

Was auch immer du da gemessen hast... das war kein Durchsatz deiner Crypto. Wuerde mich jedenfalls sehr wundern. Ich betreibe ebenfalls ein X200. Das eingesetzte AES-Modul ist das Standard-Modul fuer i686 Prozessoren und hat nichts mit einer HW-Implementierung zu tun. Deshalb falle ich vom Glauben ab sollte der Core 2 Duo 222MB/s an Cryptdevice-Durchsatz schaffen.

Du hast wohl recht. Da war wohl der / Teil der Platte noch unverschlüsselt. Ich hab's jetzt nochmal gemacht und kommt auf 86.6 MB/s.
Trotzdem kann ich meinen Laptop um 90 Grad drehen um Fotos im Hochkantformat anzuschauen!

[syssi]

[...]Ohne TRIM fuellt sich ein Medium also auch mit "Zufallszahlen" und nach einiger Zeit bleiben keine "ausgenullten" Bereiche mehr. An diesem Punkt setzt TRIM an und sorgt dafuer, dass Dateien (wenn die SSD sich langweilt) ausgenullt werden und wieder Platz fuers Wear-Leveling zur Verfuegung steht.

Zusammengefasst: Für die Verschlüsselung ist ein volles Laufwerk ideal, für die SSD der worst case?

Korrekt. Obwohl man sich noch streiten koennte, ob ein Laufwerk voller Zufallszahlen nun voll ist. Abe ja... es ist dann nicht erkennbar, wie gross die Menge an Nutzdaten ist.

Wenn ich den Benchmark aus dem Wiki mach komm ich auf 222MB/s lesend[...]

Das eingesetzte AES-Modul ist das Standard-Modul fuer i686 Prozessoren und hat nichts mit einer HW-Implementierung zu tun. Deshalb falle ich vom Glauben ab sollte der Core 2 Duo 222MB/s an Cryptdevice-Durchsatz schaffen.

Warum erscheint dir die Zahl so unwahrscheinlich? Selbst mein betagter T5670 schafft im Benchmark ~140MB/s (zugegeben, mit Truecrypt getestet, da geht's so schön einfach ). So übertrieben finde ich den Wert daher gar nicht.

Fuehre ich den Benchmark von

http://wiki.debianforum.de/BenchmarkFes ... hlüsselung

einfach mal aus, dann erhalte ich folgende Ergebnis:

Code: Alles auswählen

1071644672 Bytes (1,1 GB) kopiert, 13,4482 s, 79,7 MB/s
1071644672 Bytes (1,1 GB) kopiert, 13,265 s, 80,8 MB/s
1071644672 Bytes (1,1 GB) kopiert, 13,1166 s, 81,7 MB/s
1071644672 Bytes (1,1 GB) kopiert, 13,1875 s, 81,3 MB/s
1071644672 Bytes (1,1 GB) kopiert, 13,2911 s, 80,6 MB/s

Vergleicht man die Zahlen mit dem Wiki, dann sieht man, dass *alle* CPUs, die kein AES-NI (nur bei Core i5/i7 vorhanden) besitzen weit unter den 200MB/s liegen.

Gruss syssi