Die Diskussion stellt die Fortsetzung von Artikel zu SSD dar. Evtl wird auf dortige Posts bezug genommen.

UbuntuFlo schrieb:

noisefloor schrieb:

• Baustelle/SSD/Verschlüsselung - ist der Artikel fertig?

Nee, alles andere als das. Das war der letzte in der Reige der Serie und daher der „liegengebliebene“.

UbuntuFlo schrieb:

stfischr schrieb:

Im Verschlüsselungs-Artikel steht:

Dies kann allerdings dazu führen, dass Daten von dem Controller in den unpartitionierten (unverschlüsselten) Bereich geschrieben werden, welche dann eventuell einsehbar sind.

Das klingt, als würden die Daten entschlüsselt in den unpartitionierten Bereich geschrieben. Wie wäre es mit:

Dies kann allerdings dazu führen, dass Daten von dem Controller (weiterhin verschlüsselt) in den unpartitionierten Bereich geschrieben werden, welche dann eventuell für Kryptoattacken nutzbar sind..

Ja, klingt logischer. Danke!

Ich habe den Satz mal so eingebaut:

Dies kann allerdings dazu führen, dass (verschlüsselte) Daten vom Controller in den unpartitionierten Bereich geschrieben werden; diese könnten unter Umständen für Kryptoattacken nutzbar sein.

Liebe Grüße,

Flo

Wie siehts hier aus? Fertig für die abschliesßende Prüfung?

Nee, leider noch nicht.

Der Sandforce-Controller-Abschnitt muss noch eingedeutscht werden und der dm-crypt/LUKS-Abschnitt muss noch mit rein.

Gibt es noch andere Verschlüsselungen, die im Artikel fehlen? Habe bisher nur TrueCrypt und dm-crypt/LUKS behandelt.

Liebe Grüße,

Flo

UbuntuFlo schrieb:

Gibt es noch andere Verschlüsselungen, die im Artikel fehlen?

Laut Daten verschlüsseln fehlt z.B. noch ecryptfs.

Ich schaue es mir an, sobald ich ein wenig Luft habe.

Flo

Zu "Problematik bei Komplettverschlüsselung":

Das Problem ist doch, daß dm-crypt, also die unter Linux übliche Verschlüsselungsmethode, TRIM nicht unterstützt. Technisch wäre es sonst kein Problem. Der Kernel hinkt da mit der Unterstützung halt ein wenig hinterher, TRIM auf LVM hatte bis vor kurzem noch das gleiche Problem, Unterstützung dafür ist auch erst kürzlich dazu gekommen. Die Begriffe TRIM und Wear Leveling werden in dem Abschnitt auch vermischt / falsch verwendet. So wird z.B. behauptet daß TRIM funktioniert wenn man einen Bereich auf der SSD frei läßt. Das stimmt nicht. Wear Leveling funktioniert (dank dem freien Bereich) aber TRIM wird durch die Verschlüsselung einfach nicht gemacht.

Dies kann allerdings dazu führen, dass (verschlüsselte) Daten vom Controller in den unpartitionierten Bereich geschrieben werden; diese könnten unter Umständen für Kryptoattacken nutzbar sein.

Verläßliche Quelle dazu wäre nett, oder eine bessere Erklärung dazu, was da überhaupt das Problem ist.

Ich habe dazu nur diese Diskussion gefunden: http://www.linux-archive.org/device-mapper-development/474243-trim-support-discard.html

Supporting discards in dm-crypt means that information about unused blocks is leaked (SSD ususally returns zeroes instead of expected random data for discarded blocks) and it it can be security problem in some situations.

Demnach ist das eigentliche Problem also, daß der freie Speicher als Nullen auftaucht. Und das ist wieder ein ganz klassisches Problem, das man bei neuen Festplatten auch hat, wenn man sie vor dem Verschlüsseln nicht mit Zufallszahlen beehrt. Es läßt sich also möglicherweise eine Aussage darüber machen, wieviel Daten überhaupt gespeichert sind auf der verschlüsselten SSD und wo diese liegen. An die Daten selbst kommt man deswegen noch lange nicht ran und alternative Lösungen wie ecryptfs geben da noch viel mehr Information preis (Anzahl und Größe der Dateien, Ordnerstruktur). Das ist also ein Sicherheitsproblem auf ganz hohem Niveau...

Solange dm-crypt kein TRIM unterstützt, dürfte das der Vorteil von ecryptfs sein. Da ecryptfs ja nur verschlüsselte Dateien auf einem normalen unverschlüsselten Dateisystem ablegt, steht da TRIM nichts im Weg...

Huhu!

frostschutz schrieb:

Verläßliche Quelle dazu wäre nett, oder eine bessere Erklärung dazu, was da überhaupt das Problem ist.

Ich schaue zu Hause nochmal in der LInksammlung nach. Wie gesagt: Dieser Artikel ist der unfertigste von allem. Wenn Du Dich in der Thematik auskennst, würde ich mich über Hilfe freuen.

Auch FITRIM und batched discard sowie LVM bräuchten noch eine Abhandlung.

Liebe Grüße,

Flo

Habt ihr auch wo zahlen die belegen das die SSD bald kaputt geht oder lahm wird?

mfg Betz Stefan

encbladexp schrieb:

Habt ihr auch wo zahlen die belegen das die SSD bald kaputt geht oder lahm wird?

Hatte ich mal drin im Wiki-Artikel "smartmontools":

• http://wiki.ubuntuusers.de/Festplattenstatus?rev=241287#Achtung-bei-SSD-s

wurde dann aber wieder von Jemand rausgekürzt. Wichtig ist dabei das Attribut 0xE9:

233 Media_Wearout_Indicator 0x0032   100   100   000    Old_age   Always       -       0

Wenn der Wert auf 1 abgesunken ist, naht ihr Ende wegen Erreichens der maximalen Schreibzyklen. Ab Werten <=1 erlischt bei Intel die "5 jährige Garantie".

Viele Grüße,
Ingo

P.S.: Du wolltest ja handfeste Links sehen:

Betr. SMART-Attribut

Betr. Garantie

Was für einer Nutzung entspricht das in etwa? Das man von Garantieversprechen nichts halten braucht ist ja nicht wirklich ne Neuigkeit. Man sollte aber versuchen den Artikel auf ein Minimum an Panikmache zu reduzieren bevor man genauere Daten hat.

Den so liest man immer und überall das SSDs ja ne Sonderbehandlung brauchen, sonst sterben die wie sonstwas. Das ist nämlich nicht richtig, klar wäre es schön wenn man die SSD Softwareseitig anders verwendet, aber deren Existenz sollte nicht davon abhängen ob man das tut oder nicht.

mfg Betz Stefan

Huhu ebx,

der Artikel soll auch nicht so rüberkommen, als dass die SSD bald stirbt. Er soll nur darlegen, dass Wear Levelling und TRIM durch die „komplette Füllung“ bei einer Komplettverschlüsselung der SSD obsolet werden.

Natürlich geht dadurch eine SSD nicht übern Jordan. Nur widerspricht es dem Prinzip der SSD, dass sie diese Funktionen, die sie ja vom Controller bzw dem Kernel erhält, nicht durchführen kann.

Liebe Grüße,

Flo

Edit: Das wird hier auch nochmal erklärt. Ich habe in allen Artikeln versucht, das Thema „Tod der SSD“ zu entkräften, weil eben nichts mehr dran ist.

encbladexp schrieb:

Was für einer Nutzung entspricht das in etwa?

Beispiele stehen hier im Artikel Grundlagen: http://wiki.ubuntuusers.de/Baustelle/SSD/Grundlagen#Praxiserfahrungen

MfG, Ingo

Thema Verschlüsselung, ist mir gerade erst wieder eingefallen:

Da hat inzwischen sogar Intel schon dran gedacht und bei der neuen "320 Serie" werden die Daten AES128 verschlüsselt abgelegt. Man braucht als nur noch das zu aktivieren und ein Passwort setzen. S. hier

Im Prinzip macht das "secure erase" dann nichts anderes mehr, als das Password zu löschen -> reset to factory defaults.

Viele Grüße,

Ingo

P.S.: Konkret, ich zitiere von hier:

Superior built-in data protection features

The new Intel SSD 320 Series contains built-in features to protect your data from external threats and internal system snags.

The Intel SSD 320 Series comes pre-configured with Advanced Encryption Standard (AES) 128 bit encryption capabilities2. In the event of theft or loss of your computer, you have the peace of mind that your personal data is secured by advanced encryption technologies.

Additionally, two new data protection features guard your data from internal system mishaps. To reduce potential data loss, the Intel SSD 320 Series detects and protects from an unexpected system power loss. The drive saves all cached data in the process of being written before shutting down, thereby minimizing potential data loss.

Erwartet bitte nicht von mir, daß ich das an meinem System ausprobiere, habe keine Lust mich unwiderruflich auszusperren und alle Systeme auf der SSD wieder neu einzurichten

P.S. #2:

Realisieren kann man das alles unter Win$ oder auch mit hdparm. Aber da gibt es eine ernst zu nehmende Empfehlung:

nur die Subcommands an die Platte schicken, die der Hersteller explizit dokumentiert hat

Anwender, die unbedingt vollverschlüsseln wollen oder müssen, sollten darauf achten, einen Bereich der SSD unformatiert und damit unverschlüsselt zu lassen, so dass der Controller der SSD auf diesen zugreifen und das Wear Levelling dorthin verlagern kann. Auch TRIM kann dann wieder den Anforderungen entsprechend arbeiten. Dies kann allerdings dazu führen, dass (verschlüsselte) Daten vom Controller in den unpartitionierten Bereich geschrieben werden; diese könnten unter Umständen für Kryptoattacken nutzbar sein.

Ich halte diese Interpretation in mehreren Punkten für fehlerhaft.

Nach meinem Verständnis sind zwei Speicher-Schichten zu unterscheiden:

1. Logische Schicht: stellt die Nenn- oder Nettokapazität der SSD zur Verfügung. Ist per SATA für das OS sichtbar und von der Anzahl der Blöcke her fixiert.

2. Physische Schicht: stellt die Summe des Flashspeichers der SSD einschließlich Reserveblöcken dar - ist nach außen/für das OS nicht sichtbar

Zwischen diesen beiden Schichten "übersetzt" die Firmware. Durch den Wear Leveling Algorithmus ändert sich ständig das Mapping zwischen 1. und 2.

Ein OS schreibt niemals in den unpartitionierten Bereich von Schicht 1. Zugriff auf Schicht 2 und damit Kryptoattacken sind nur per direktem Auslesen des Flash (unter Umgehung des SSD-Controllers) mit Spezialhardware im Labor denkbar.

Die Blocknutzung bei einer LUKS-Partition ist abgesehen von einem Offset durch den Header 1:1 identisch zu einer unverschlüsselten Partition, da stets blockweise verschlüsselt geschrieben wird, ohne Seiteneffekte auf andere Blöcke. Kannst Du näher erläutern wo der Fülleffekt auf Schicht 1 herkommen soll?

Einen Teil der Schicht 1 freizulassen, erhöht zwar künstlich die Zahl der Reservesektoren, IMHO ist der dadurch erzielbare Gewinn an Lebensdauer aber für den durchschnittlichen User irrelevant. Genauso wenig wird dadurch automatisches TRIM einer gecrypteten Partition möglich, kein aktueller Kernel kann das. Entwicklerargument gegen eine Implementierung ist bisher (soweit ich weiß, hab die Quelle leider nicht zur Hand) die oben erwähnte hypothetische Möglichkeit von Kryptoattacken.

Es gibt eine modifizierte Version von wiper.sh die LUKS und LVM kann: TRIM support on LVM and dm-crypt. Für Lucid auch erhältlich als modifizierter hdparm-Backport in meinem PPA - NUTZUNG AUF EIGENE GEFAHR!

ps. zum Thema Hardwareveschlüsselung in der SSD (FDE) empfehle ich die Lektüre von Warum bricken im Moment alle ihre SSDs? .

ps2. Respekt für diese außergewöhnliche Artikelreihe!