UbuntuFlo
Anmeldungsdatum: 8. Februar 2006
Beiträge: 12317
Wohnort: /home/flo
|
Grüß Dich, linrunner ☺ linrunner schrieb: Ich halte diese Interpretation in mehreren Punkten für fehlerhaft.
Unter anderem aus dieser Quelle habe ich das: c't: SSD verschlüsseln. Kannst Du näher erläutern wo der Fülleffekt auf Schicht 1 herkommen soll?
Durch das Füllen mit Nullen ist kein Platz mehr auf der SSD, um Daten gemäß Wear Levelling und TRIM zu verschieben oder löschen zu können. So habe ich das zumindest bisher verstanden. ps2. Respekt für diese außergewöhnliche Artikelreihe!
Danke! Liebe Grüße, Flo
|
ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
Ich schlage hier mal eine pragmatische Lösung für diesen Artikel vor: Wir haben im Moment 3 prinzipiell verschiedene Möglichkeiten zur Verschlüsselung: 1. eCryptFS ist "SSD-tauglich", da es nur einzelne Dateien im Verzeichnisbaum verschlüsselt. TRIM und Müllabfuhr (garbage collection) sind nicht betroffen. Die Sicherheit zumindest unter Lucid ist allerdings fragwürdig, s. c't 11/2011, S. 192ff im Abschnitt "Abgewogen". 2. dm-crypt gibt ein Höchstmaß an Sicherheit, ist aber kaum "SSD-tauglich", da die komplette SSD mit Daten gefüllt wird und damit TRIM und Müllabfuhr ins Leere laufen. 3. Hardware-Verschlüsselung intern in der SSD ist derzeit noch im Anfangsstadium und mir nur für die neuestem Intel-Modelle bekannt. Dies ist jedoch die einzig wirklich sinnfvolle Art und Weise für SSD's. Sollten wir nicht deshalb den Artikel mit heutigem Stand der Technik unterbrechen und dies irgendwo im Kopf mit Datum vermerken. Sobald mehr und Details zur Nutzung der SSD-internen Hardware-Verschlüsselung unter Linux bekannt sind, kann der Artikel dann auf den neuesten Stand gebracht werden. Dann könnte der Artikel zumindest ins Wiki verschoben werden. Viele Grüße, Ingo
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7651
|
linrunner schrieb: Nach meinem Verständnis sind zwei Speicher-Schichten zu unterscheiden:
Nach meinem Verständnis ging es darum hier gar nicht. Wir bewegen uns ausschließlich auf der Nennkapazität...
die oben erwähnte hypothetische Möglichkeit von Kryptoattacken.
In der von mir zitierten Mail gehts darum, daß die SSD nach einem TRIM an der Stelle dann Nullen liefert, und damit dann freier Speicher auf der verschlüsselten Partition sichtbar wird. Für Normaluser ist das ein vollkommen vernachlässigbarer Effekt.
Es gibt eine modifizierte Version von wiper.sh die LUKS und LVM kann:
wiper.sh & co sind hochgefährlich und zwar derart, daß man davon ganz abraten sollte. Ansonsten hat man Datenverlust ohne das sofort zu merken. Die Idee ist nicht schlecht aber die Umsetzung als Shellscript ist haarsträubend. Und solange nicht geprüft wird daß an der freizugebenden Adresse auch tatsächlich die erwarteten Rohdaten liegen, einfach fahrlässig. UbuntuFlo schrieb: Durch das Füllen mit Nullen ist kein Platz mehr auf der SSD, um Daten gemäß Wear Levelling und TRIM zu verschieben oder löschen zu können. So habe ich das zumindest bisher verstanden.
Kommt auf die SSD an. Eine gute SSD macht immer Wear Leveling, auch wenn sie ganz voll ist. Es werden dann einfach zwei Bereiche miteinander vertauscht. Das funktioniert einwandfrei, wenn man davon absieht, daß es nicht besonders schnell ist. Mit freiem Speicher (sei es nun frei gelassener oder mit TRIM als frei markierter) geht es halt viel schneller, weil man dort dann die alten Inhalte nicht retten muss und sich somit den Lese/Schreibvorgang spart.
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17442
|
Hardwareverschlüsselung der SSD ist je nach SSD genauso dämlich wie Hardwareverschlüsselung bei USB Sticks, den genau hier wurde gezeigt wie unfähig Hersteller sind. Noch dazu kommt das bei einer Verschlüsselung, egal ob in Hard oder Software kein Wearing Level greifen kann da nach wie vor nur Müll in die Speicherzellen geschrieben wird, einzig TRIM kann damit dann natürlich wieder funktionieren. mfg Betz Stefan
|
ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
encbladexp schrieb: Hardwareverschlüsselung der SSD ist je nach SSD genauso dämlich wie Hardwareverschlüsselung bei USB Sticks, den genau hier wurde gezeigt wie unfähig Hersteller sind.
Ok, das betraf USB-Sticks für ein paar Euronen und auch nicht die großen Hersteller. Bei dem Wert heutiger SSD's kann sich das sicher kein rennomierter Hersteller erlauben, da zu schlampen. Intel hat jetzt den Anfang gemacht - da werden andere nachziehen. Und da das der einzig wirklich vernünftige Weg bei einer SSD ist, erwarte ich dort eine solide Lösung. Das wird dann sicher auch von unabhängiger Seite getestet werden - da bin ich sicher. An so einem Produkt haben dann auch gewisse Behörden Interesse, und die zahlen dafür dann sogar richtig Geld 😉 Warte mal bis Ende dieses Jahres oder im nächsten Jahr, dann weiß man sicher näheres. Viele Grüße, Ingo
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7651
|
ingo2 schrieb: Und da das der einzig wirklich vernünftige Weg bei einer SSD ist, erwarte ich dort eine solide Lösung.
Der vernünftige Weg ist, die Verschlüsselung per CPU zu beschleunigen und das ist ja gerade das was bei den aktuellen CPUs dank AES-NI passiert. Die Flexibilität und Sicherheit die mir cryptsetup/LUKS bietet will ich ganz ehrlich nicht gegen eine in Hardware gegossene, proprietäre Lösung eintauschen.
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17442
|
frostschutz schrieb: Der vernünftige Weg ist, die Verschlüsselung per CPU zu beschleunigen und das ist ja gerade das was bei den aktuellen CPUs dank AES-NI passiert.
Full ACK
Die Flexibilität und Sicherheit die mir cryptsetup/LUKS bietet will ich ganz ehrlich nicht gegen eine in Hardware gegossene, proprietäre Lösung eintauschen.
Und genau so ist es auch richtig, so lange man nicht den Sourcecode der Treiberfirmware ansehen kann weis man einfach nicht ob das wirklich Verschlüsselt gespeichert ist, oder ob es nur als besserer Passwortschutz durchgeht. Auch ist noch ungeklärt wie AES verwendet wird, 128 Bit sind ja nicht die Welt (wenn auch noch genug), doch bekommt man nirgends eine Info ob den jetzt wirklich XTS oder sonstwas genutzt wird. Das ist ein weiterer Unsicherheitsfaktor, was bringt AES wenn die gleich mal ordentlich am Rest geschlampt haben. mfg Betz Stefan
|
linrunner
Anmeldungsdatum: 7. August 2007
Beiträge: 3271
|
ingo2 schrieb: 2. dm-crypt gibt ein Höchstmaß an Sicherheit, ist aber kaum "SSD-tauglich", da die komplette SSD mit Daten gefüllt wird und damit TRIM und Müllabfuhr ins Leere laufen.
Exakter wäre: die komplette Partition (bei der Vollverschlüsselung auch der LVM darin) wird gefüllt. cryptsetup macht das aber nicht per Default beim Anlegen. Da muß der Benutzer schon nachhelfen. Bei Truecrypt ist anscheined der Default anders (s. oben), TC füllt aber auch nur die Partition.
linrunner schrieb: Nach meinem Verständnis sind zwei Speicher-Schichten zu unterscheiden:
Nach meinem Verständnis ging es darum hier gar nicht. Wir bewegen uns ausschließlich auf der Nennkapazität...
Ich würde es auseinanderfieseln, damit das "Füllen" und das Wear Leveling nicht beim Leser durcheinandergeraten.
|
Spacemarine
Anmeldungsdatum: 19. Dezember 2007
Beiträge: 49
|
frostschutz schrieb: wiper.sh & co sind hochgefährlich und zwar derart, daß man davon ganz abraten sollte.
Warum? Was genau ist das Problem?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7651
|
Das Script prüft nirgends wirklich, ob das was es tut, auch richtig ist. Die Idee sowas zu machen ist vollkommen in Ordnung, aber es ist halt keine Aufgabe die man in Bash lösen sollte. Der Autor des Scripts macht da auch keinen Hehl daraus. Um nur mal zwei Zeilen aus der dem wiper.sh beiliegenden README zu zitieren: This script may be EXTREMELY HAZARDOUS TO YOUR DATA.
DO NOT USE THIS SCRIPT if you cannot afford losing your data!! Ich kenne leider keine Alternative die wirklich den Schritt weiter geht und z.B. die freizugebenden Areale auf Korrektheit prüft.
|
B601
Anmeldungsdatum: 10. Juli 2009
Beiträge: 105
Wohnort: Wien
|
Ich möchte auch ein paar Gedanken einfließen lassen: Dass man Bereiche frei lässt, um Wearlevelling zu erleichtern, macht spätestens mit TRIM nicht viel Sinn. Die Platte hat ohnehin mehr Speicherzellen zur Verfügung, als Nettokapazität ausgegeben wird; dies nennt man Reservebereich. Er hat zwei Aufgaben:
Er soll im "Schadensfall" defekte Blöcke ersetzen, ohne dass die Platte Kapazität verliert oder Daten beschädigt werden. Er dient dem Wearlevelling: Jeder Schreibvorgang ohne TRIM läuft so ab: Die Daten werden auf den am wenigsten häufig beschriebenen Block im Reservebereich geschrieben, geprüft (kaputte Speicherblöcke lassen sich iA. lesen, aber nicht mehr beschreiben, ein Vorteil ggü. magnetischen Platten, siehe "Schadensfall") und anschließend wird der "alte", also eigentlich zu überschreibende, Block mit diesem Reserveblock, der den neuen Inhalt hat, getauscht.
Sind zu wenige Reserveblöcke für einen bestimmten Schreibvorgang zur Verfügung, tauscht das Wearlevelling zusätzlich die Inhalte besonders häufig mit denen besonders selten beschriebener Blöcke aus. Das ist letztlich das, was ohne TRIM eine Platte immer langsamer macht. Wenn man Blöcke frei lässt, gibt es zwei Möglichkeiten: Entweder von Anfang an (bzw. nach Factory-Erase), oder innerhalb des Filesystems, dh. man darf die Partition nicht voll beschreiben. Ein einmal verwendeter Bereich, der durch Verkleinerung von Partitionen frei wird, bleibt für den Controller beschrieben! TRIM: Mit TRIM werden keine Blöcke gelöscht (das wäre ja ein weiterer, unnötiger, Schreibvorgang), sondern sie werden nur als gelöscht gekenzeichnet. Wird ein "getrimmter" Block ausgelesen, schickt der Controller einfach Dauernullen ohne echten Lesevorgang. (Durch die bedeutend höhere, sprich Schnittstellengeschwindigkeit, also z.B. bei SATA II ca. 360 MB/s, kann man das überprüfen.) Beim Beschreiben entfällt der o.a. Vorgang - es wird direkt geschrieben. Truecrypt: In der derzeitigen stabilen Release unterstützt Truecrypt mit Sicherheit kein TRIM, in welcher Form auch immer. Verschlüsselung allgemein: Ein wesentliches Kriterium bei SSD-Betrachtung ist, dass verschlüsselte Daten immer mehr Platz benötigen als unverschlüsselte. Bei Verschlüsselung gesamter Partitionen werden daher Blöcke auf Filesystemebene auf mehr als einen Block auf physikalischer Ebene geschrieben, was denselben Effekt hat wie eine falsche Partitionsausrichtung: Die Schreibvorgänge werden mehr oder weniger verdoppelt, und die Platte wird wesentlich langsamer (und die Lebensdauer halbiert sich auch). Wird nicht die zusätzliche Sicherheit einer Partitionsverschlüsselung benötigt, sind daher Dateiverschlüsselungen wie Ecryptfs und Encfs, die auf Filesystemebene transparent sind, zu bevorzugen. Ich persönlich verwende für Partitionsverschlüsselung magnetische Platten, wenn möglich. Einen Unterschied macht es ev., wenn der Controller Verschlüsselung unterstützt. Inwieweit er dann aber die Block-Schreibvorgänge optimiert, weiß ich nicht. Übrigens: 128-Bit-Verschlüsselung ist längst nicht mehr Standard und quasi ein Übungsobjekt für Nachwuchshacker. Großrechner knacken so etwas in Minutenschnelle. Ich würde daher auf die HW-Verschlüsselung verzichten und eine "ordentliche" Softwarelösung nehmen...
|
linrunner
Anmeldungsdatum: 7. August 2007
Beiträge: 3271
|
B601 schrieb: Verschlüsselung allgemein: Ein wesentliches Kriterium bei SSD-Betrachtung ist, dass verschlüsselte Daten immer mehr Platz benötigen als unverschlüsselte.
Bei Verschlüsselung gesamter Partitionen werden daher Blöcke auf Filesystemebene auf mehr als einen Block auf physikalischer Ebene geschrieben
Kannst Du das genauer erklären oder hast Du dafür eine Quelle? Die nutzbare Volumegröße wird IMHO lediglich um den LUKS-Header verringert.
|
B601
Anmeldungsdatum: 10. Juli 2009
Beiträge: 105
Wohnort: Wien
|
linrunner schrieb: B601 schrieb: Verschlüsselung allgemein: Ein wesentliches Kriterium bei SSD-Betrachtung ist, dass verschlüsselte Daten immer mehr Platz benötigen als unverschlüsselte.
Bei Verschlüsselung gesamter Partitionen werden daher Blöcke auf Filesystemebene auf mehr als einen Block auf physikalischer Ebene geschrieben
Kannst Du das genauer erklären oder hast Du dafür eine Quelle? Die nutzbare Volumegröße wird IMHO lediglich um den LUKS-Header verringert.
Die "Volumengröße" sagt gar nichts aus, denn das ist ja das leere Medium! Sie ändert sich natürlich nicht oder nur sehr wenig, weil nicht bekannt ist, wie viel Platz die Dateien, Inodes, Journale etc. tatsächlich belegen werden. (Es gibt ja auch Filesystem wie XFS und BTRFS, die Inodes und Journale dynamisch anpassen.) Ich weiß nicht, ob es Verschlüsselungsverfahren gibt (außer dem simplen Austauschen von "Buchstaben", wie es Volksschulkinder machen), bei denen es rein mathematisch überhaupt möglich ist, dass die Verschlüsselung den Platzbedarf nicht erhöht. Ich würde gefühlsmäßig sagen, nein, schon deshalb, weil gute Verfahren "Salt" verwenden, also Zufallsdaten einfügen, die sich beim korrekten Entschlüsseln herausrechnen, aber inkorrekte Versuche erheblich erschweren. Ein Beispiel für encfs: | xxx@YYY:~/.daten/-dF-kI4$ ls -la
-rw-rw-r-- 1 xxx xxx 5622469 2011-07-09 16:17 BiaEZ)FD7(loLZeaOl0
xxx@YYY:~/.daten/-dF-kI4$ ls -la ../../Scanner/0469800.jpg
-rw-rw-r-- 1 xxx xxx 5534613 2011-07-09 16:17 ../../Scanner/0469800.jpg
|
Es handelt sich um dieselbe Datei, wie man schon am Datum erkennen kann. Die verschlüsselte Datei (aes256) ist rund 100 kB oder 2 % größer. Noch eine Amerkung zu Truecrypt in der derzeitigen Implementierung: Truecrypt schreibt die Daten "statisch verteilt" (natürlich nicht wirklich statistisch, es ist vom Verschlüsselungsalgorithmus, Passwort, Key usw. abhängig). Ich weiß nicht, inwiefern Truecrypt das tut. Da Truecrypt derzeit nichts von SSDs weiß (und es nur mehr mäßig "sicher" ist, ganze Eraseblocks mit 128 kB oder sogar Vielfachen davon zu mixen), erhöht das die Blockschreibvorgänge erheblich, im Extremfall beduetet das also, dass jeder Schreibvorgang auf SSD-Ebene 256 Schreibvorgänge oder sogar mehr auslöst, und nur mehr die Intelligenz des Controllers und der Cache dafür sorgen, dass es doch weniger werden (können).
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17442
|
B601 schrieb: ...dass die Verschlüsselung den Platzbedarf nicht erhöht.
Dieser theoretische Platzbedarf ist für die Katz, eine Verschlüsselung auf Blockebene, z.B. durch TrueCrypt/LUKS vergrößert den Platzbedarf von Dateien nicht. Lediglich das Dateisystem bekommt einen Header außen rum gepackt, der etwas Platz braucht - und eine fixe Größe hat. Das Verschlüsselungsverfahren - auch mit Salt - z.b. nur 512 Byte Blöcke Verschlüsseln können ist unerheblich. Die Festplatte und Dateisysteme arbeiten schon immer mit Festen Block Größen, d.h. eine Datei mit 3 KByte braucht nen ganzen 4 KByte Sektor im Dateisystem. Windows hat dafür ne schöne Anzeige für Dateien, die zeigt an wie viel Platz die Datei braucht, und wie viel auf dem Dateisystem.
...weil gute Verfahren "Salt" verwenden.
Ein Salt vergrößert aber nicht die Datenmenge, wenn ein Verfahren nur 512 Byte am Stück bearbeiten kann wird es auch mit Salt nur 512 Byte brauchen. Es gibt dann noch Verschlüsselungsalgorithmen die Datenströme Verschlüsseln, und nicht Blockorientiert arbeiten.
Ein Beispiel für encfs...
ecryptfs arbeitet ja Oberhalb vom Dateisystem, d.h. eine Art Header muss an jede Datei, sonst hat diese Bastellösung keine Möglichkeit eine Datei richtig und vor allem sicher zu verschlüsseln. mfg Betz Stefan
|
linrunner
Anmeldungsdatum: 7. August 2007
Beiträge: 3271
|
In diesem Artikel sind zu viele nicht belegte bzw. falsche Aussagen, z.B.: Gegen eine Komplettverschlüsselung spricht, dass der Controller der SSD kein Wear Levelling durchführen kann, da dieser nicht zwischen einer komplett gefüllten (vollgeschriebenen) und einer verschlüsselten SSD unterscheiden kann.
Ein SSD-Controller macht immer Wear Levelling beim Schreiben. Entscheidend ist nicht der Blockinhalt, sondern wie oft ein Block geschrieben wird. Für das Umschichten ist die Spare Area da. Dies kann allerdings dazu führen, dass (verschlüsselte) Daten vom Controller in den unpartitionierten Bereich geschrieben werden;
Falsch, habe ich oben erklärt. Das passiert auf der nicht sichtbaren Schicht 2 (Spare Area), nicht jedoch im "unpartitionierten Bereich" der Schicht 1. Ebenso nicht belegt oder gar schlüssig erklärt sind unterschiedliche Auswirkungen von Voll- und Teilverschlüsselung. Der allgemeine Teil sollte bis auf eine kurze Einleitung komplett entfallen und zutreffende Aussagen in spezifische Abschnitte
wandern. Unter dem Strich bleibt IMHO folgende Auswirkung von dm-crypt/LUKS auf den Verschleiß: Enthaltene Dateisysteme unterstützen kein TRIM (egal ob Voll- oder Teilverschlüsselung), d.h. der Controller bekommt nicht vom Filesystem mitgeteilt welche Schicht-1-Blöcke frei sind. Stattdessen muss die SSD alleine klarkommen: wenn also ein Schicht-1-Block überschrieben und gleichzeitig auf der Schicht 2 umgelagert wird, dann ist der alte Schicht-2-Block wieder frei und wandert in den Pool der freien Schicht-2-Blöcke. Im Artikel könnte man das Zusammenfassen mit: die Effizienz des Wear Levelling sinkt in verschlüsselten Bereichen aufgrund des fehlenden TRIM
Und ja, ein Vergrößern der Spare Area verringert den Verschleiß. Das ist aber auch ohne Verschlüsselung so. Von der ganzen Verschleißthematik abzugrenzen wären eventuelle SSD-spezifische Angriffsmlöglichkeiten auf die Verschlüsselung. IMHO spielt sich das aber auf Schicht 2 ab und ist daher nur mit großem technischen Aufwand und nicht mit Bordmitteln von Linux durchführbar.
|