SSD Setup

Hi
Ich hab mir heute eine Samsung 470series 128 GB SSD gekauft und will die Morgen mal einrichten. Allerdings habe ich ein paar Fragen:
Es kommt ein Win 7 x64 vollverschlüsselt mit Truecrypt drauf. Mein Plan ist es eine 100gb Partition für Windows zu machen und den Rest unpartioniert zu lassen. Weiß der Controller dann von dem freien Speicherplatz und kann ihn für TRIM benutzen?

Man liest ja allerhand "Tweakingtips" wie z.B. Firefox Disk cache ausschalten etc. Bringt das wirklich was?

Danke schonmal

ein truecrypt verschlüsseltes systemlaufwerk auf ner SSD könnte zu einigen Problemen mit trim führen, da sich truecrypt zwischen windows udn die platte klinkt und somit kein direkter zusammenhang mehr zwischen den datenblöcken die windows sieht und denen die auf der platte liegen besteht.

Hier mal was ganz aktuelles.
http://www.pc-experience.de/wbb2/thread.php?threadid=30040

Die Optimierungen bringen wirklich was!

Ob der Controller das erkennt kann ich dir nicht sagen. Warum willst du sie denn nicht partitionieren?

@rainbow6261: Wenn man fest dran glaubt bestimmt. Kannst du in Zahlen ausdrücken was die konkreten Optimierungen so bringen?

Gewisse Dinge sind sicher Pflicht, das meiste davon macht Windows 7 aber eh (wie z.B. Alignment, Defragmentierung).

Vieles ist schlicht und einfach nur unnötig... man sollte jeden Punkt davon kritisch hinterfragen... manches ist meiner Meinung nach sogar kontraproduktiv (wie Index-Dienst abschalten).

Und wer paranoide Angst vor Schreibzugriffen auf der SSD hat, sollte sich besser keine holen ...

Verschlüssele am besten nur die Dateien, dann kannst Du auch die volle Kapazität nutzen. Ansonsten bitte nur die Partition, denn wenn Du die ganze Platte verschlüsselst, dann musst Du womöglich die Anzahl der verfügbaren LBAs reduzieren, damit die nicht doch alle belegt werden, nur um zu verschleiern wo wirklich Daten liegen und wo nicht.

Mein Plan war ja einfach eine 100GB Partition zu erstellen, da Windows drauf zu installieren, es mit TC zu verschlüsseln und den Rest garnicht anzufassen.
Eine Alternative wäre den Rest zu partionieren und dann nichts draufzupacken/verschlüsseln.
Welches ist besser? Und gibt es eine einfache Möglichkeit zu testen ob TRIM vernünftig funktioniert?

Also zum Trim und TrueCrypt:
das kann nicht funktionieren und wäre sogar sicherheitstechnisch eher kontraproduktiv.

Trim ermöglicht ja nur, dass das Betriebssystem dem Controller mitteilen kann, welche Bereiche leer sind - vereinfacht gesagt also mit Nullen gefüllt. Ein solcher Bereich besteht verschlüsselt allerdings nicht mehr nur aus Nullen... Ergo kein Trim.

Deswegen soll ja auch nicht die ganze 128gb SSD verschlüsselt werden sondern nur eine 100gb große partition.

Damit hilfst du vielleicht dem Wear-Leveling-Algorithmus, am (nicht möglichen) Trim ändert das aber nichts.

Ob die SSD nun so intelligent ist und beim Schreiben dann einen der ungenutzten Blöcke verwendet und danach den alten Block leert, weiß ich nicht... aber ich würd mich auhc nicht verrückt machen diesbezüglich, die Vorteile der SSDs liegen in den Zugriffszeiten, darin dass konkurrierende Zugriffe sich kaum gegenseitig in den Keller ziehen...

Hab mal ein bisschen gegoogelt:

Zumindest beim Einsatz von verschlüsselten Systempartitionen leitet TrueCrypt das TRIM Kommando an die SSD weiter. Dies gilt für alle Partitionen, die durch die Systemverschlüsselung geschützt sind, nicht jedoch beim Verschlüsseln von herkömmlichen Partitionen und Containern. Durch das Weiterreichen des TRIM-Kommandos kann ein Angreifer feststellen, wie viele Daten tatsächlich auf der SSD gespeichert sind. Bei versteckten Betriebssystemen wird das TRIM-Kommando nicht durchgereicht, um die glaubhafte Abstreitbarkeit zu gewährleisten.[10]

Möglicherweise ist es bei der Verschlüsselung ganzer SSD-Laufwerke oder ganzer Partitionen empfehlenswert, einen Teil des Speicherplatzes der SSD ungenutzt (unpartitioniert) zu belassen, um dem SSD-Controller die Möglichkeit zu geben, die freien Blöcke für das Wear-Leveling zu nutzen und so die Langlebigkeit der SSD zu erhöhen. Bei Systempartitionen ohne verstecktes Betriebssystem ist dies nicht notwendig (s.o.).

Zum Vergrößern anklicken....

aus: http://de.wikipedia.org/wiki/TrueCrypt#Funktionalit.C3.A4t_mit_Solid_State_Drives_.28SSD.29

==>Also: Ganze SSD mit TC verschlüsseln. Oder weiß dann der Wear-Leveling Algorithmus nicht bescheid was frei ist?

"Durch das Weiterreichen des TRIM-Kommandos kann ein Angreifer feststellen, wie viele Daten tatsächlich auf der SSD gespeichert sind." => wie gesagt, sicherheitskritisch meiner Meinung nach.

Und "TrueCrypt leitet wieter klingt lustig", wie wenn es aktiv was machen würde... die Macher selbst sagen "TrueCrypt does not block the trim operation". Hier auch der Text dazu. http://www.truecrypt.org/docs/?s=trim-operation

Also wenn du das "Risiko" Trim eingehen willst kannst auch den gesamten Speicher nehmen ja... dann kommt auch das Wear-Leveling damit klar, Den ganzen Speicher ohne Trim zu nutzen würde heißen, dass der Speicher der SSD als vollständig belegt angesehen wird. Optimal wäre dies wohl nicht.

Lies mal hier über TRIM und GC, dann wird Dir klar, dass TRIM nur den Zeitpunkt verschiebt, wann der Controller merkt, dass Daten ungültig geworden sind und von der GC eliminiert werden und beim Löschen eines Blocks nicht mehr kopiert werden müssen. Diese spielt dann aber keine Rollen, wenn die Verschlüsselungssoftware die Adressen (LBAs) die von gelöschten Dateien belegt waren, soweiso wieder überschreibt (damit eben keiner erkennen kann, wo Daten liegen und wo nicht). Für eine SSD ist es besser, wenn man nur die Dateien selbst verschlüsselt und nicht die ganze Partition oder gar die ganze Platte (dann ist der ganze Bereich der Partition/der Platte immer für den Controler voll). So groß ist der Sicherheitsnachteil nicht, wenn jemand weiß wo Daten liegen und welcher Speicherbereich frei ist. Bei verschlüsselten Dateien ist sind dann ja auch nur das pagefile.sys und hipernate.sys kritisch, die sollten auch verschlüsselt sein, da sonst Fragmente der Daten dort im Klartext stehen könnten.

@Holt: Wie soll ein Controller ohne Trim erfahren, dass Daten "ungültig" geworden sind?
Und irgendwie finde ich deine Erklärung zu Trim merkwürdig.

1668mib schrieb:

"Durch das Weiterreichen des TRIM-Kommandos kann ein Angreifer feststellen, wie viele Daten tatsächlich auf der SSD gespeichert sind." => wie gesagt, sicherheitskritisch meiner Meinung nach.

Zum Vergrößern anklicken....

Was ist daran sicherheitskritisch? Wenn der Angreifer die SATA Befehle mitlesen kann, dann ist es bei Heimanwendern immer ein Prozess der läuft und der kann dann auf alle Daten sowieso im Klartext zugreifen. TC schützt nicht gegen Softwareangriffe wie den Bundestrojaner. Solche Datenverschlüsselung schützt davor, dass jemand der die Platte (den ganzen Rechner) in die Finger bekommt, die Daten daruf lesen kann. Niht mehr und nicht weniger und deshalb reicht es normalerweise auch, wenn man nur die Dateien verschlüsselt und nicht gleich die ganze Partition. Wer soll sich denn dafür interessieren, wie groß die Dateien sind, die er nicht lesen kann?

1668mib schrieb:

Und "TrueCrypt leitet wieter klingt lustig", wie wenn es aktiv was machen würde... die Macher selbst sagen "TrueCrypt does not block the trim operation". Hier auch der Text dazu. http://www.truecrypt.org/docs/?s=trim-operation

Zum Vergrößern anklicken....

Wie schon gesagt: Wenn die LBAs die von einer gelöschten Datei belegt waren gleich wieder überschrieben werden, dann ist TRIM wirkungslos und es damit total egal, ob die TRIM Befehle durchkommen oder nicht.

Also ob man sehen kann wieviele Daten die verschlüsselte Partition enthält ist für mich jetzt nicht so kritisch.
Dann werde ich wohl eine 100gb Truecrypt Systempartition erstellen und den Rest freilassen um sicherzugehen.
Nur einzelne Dateien zu verschlüsseln ist für mich leider keine Option, es soll schon die ganze Systempartition sein

Wer reder von ATA-Befehle mitlesen? Darum geht es mir gar nicht.
Wenn die Blöcke via Trim als leer markiert werden, wird sie die Firmware der SSD früher oder später auch mit Nullen füllen. Insofern kann ein Angreifer leere Sektoren direkt erkennen usw. Bei einem potentiellen Angriff sind das zumindest Informationen, die man nicht unbedingt preisgeben muss.#

"Wenn die LBAs die von einer gelöschten Datei belegt waren gleich wieder überschrieben werden" => Kontext? Passt doch gar nicht zu meiner Aussage...
und LBA ist kein Block sondern ein Verfahren...

@hdthtfhf: Es geht mir auch weniger darum, dass man die Menge erfahren kann, sondern dass solche Kenntnisse einen Angriff eventuell erleichtern können. Wobei bei vernünftiger Verschlüsselung ein Angriff die nächsten Jahrzehnte eh eher theoretischer Natur ist...

1668mib schrieb:

@Holt: Wie soll ein Controller ohne Trim erfahren, dass Daten "ungültig" geworden sind?
Und irgendwie finde ich deine Erklärung zu Trim merkwürdig.

Zum Vergrößern anklicken....

Wie kann er es denn erfahren? Doch nur indem die selbe Adresse (LBA) wieder beschrieben wird. Damit weiß er dann automatisch, dass die Daten die vorher unter dieser Adresse gespeichert waren, jetzt nicht mehr gültig sind, weil sie eben überschrieben wurden. Alternativ könnte er es sonst nur erfahren, wenn er das Filesystem selbst interpretiert, was aber bei verschlüsselten Partitionen, RAID, etc. fehlschlagen muß. Deshalb ist ja ohne TRIM für den Controller alles belegt, was jemals beschrieben wurde und man sollte in dem Fall auch einen Teil unpartitioniert lassen. Da nur jene Adressen die nie beschrieben wurden für den Controller frei sind, lässt man ohne TRIM eben am Besten einen Teil der Kapazität unpartitioniert. Nur damit kann man sicherstellen, dass eine Adresse nicht beschrieben wird, weil Windows eben freigewordene LBAs nicht immer sofort wieder überschreibt.

Nur LBAs die für den MFT reserviert sind, werden erst dann mit anderen Daten beschrieben, wenn es sonst keinen freien Speicher mehr gibt und dann wird der MFT auch auf andere Adressen geschrieben. Deswegen und weil man den MFT nicht defragmentieren kann, werden HDDs auch so langsam, wenn man sie einmal zu voll hat werden lassen. Den gleichen Effekt hat man eben auch bei einer SSD ohne TRIM, nur eben aus einem anderen Grund.

Gibt es eine Möglichkeit zu testen ob Wear leveling und TRIM vernünftig funktionieren?
Falls ja werde ich das Morgen mal probieren und die Ergebnisse posten.

1668mib schrieb:

Wer reder von ATA-Befehle mitlesen? Darum geht es mir gar nicht.
Wenn die Blöcke via Trim als leer markiert werden, wird sie die Firmware der SSD früher oder später auch mit Nullen füllen. Insofern kann ein Angreifer leere Sektoren direkt erkennen usw.

Zum Vergrößern anklicken....

Wie soll der Angreifer bitte an diese Information kommen, wenn nicht durch mitlesen der SATA Befehle? Für den Controller ist es ja egal, wieso er Flashpages als ungültig markiert hat. Das kann eben durch Überschreiben oder trimmen der LBA (Logical Block Address) passieren.

1668mib schrieb:

Bei einem potentiellen Angriff sind das zumindest Informationen, die man nicht unbedingt preisgeben muss.#

Zum Vergrößern anklicken....

Was soll ihm diese Information nutzen? Beim Lesen einer getrimmten LBA bekommt man die alten Daten sowieso nicht mehr zu sehen (sondern i.d.R. nur Nullen) und aus der LBA kann man auch nicht so einfach die Flashadresse wiederherstellen. Und wenn doch, so stehen die Daten doch sowieso gecryptet dadrin.

1668mib schrieb:

"Wenn die LBAs die von einer gelöschten Datei belegt waren gleich wieder überschrieben werden" => Kontext? Passt doch gar nicht zu meiner Aussage...

Zum Vergrößern anklicken....

Du hattest über TRIM als "Risiko" geschrieben und die Aussage die Macher selbst sagen "TrueCrypt does not block the trim operation" getätigt. Daher habe ich die Belanglosigkeit von TRIM für diesen Fall dargestellt. Außerdem: Muss denn alles was ich schriebe einen Bezug zu Deiner Aussage haben?

1668mib schrieb:

und LBA ist kein Block sondern ein Verfahren...

Zum Vergrößern anklicken....

LBA ist auch der Name für die Adresse, deswegen steht in den Datenblättern von SSDs i.d.R. auch der "User Adressable Space" in LBAs. Eine Adressierung über Zylinder, Kopf und Sektor macht bei SSDs ja auch gar keinen Sinn und ist auch bei HDDs schon lange aus der Mode. Außerdem ist die Angabe von LBA als kleinste Einheit die der Host Controller adressiert viel eindeutiger als von Sektoren zu sprechen. Davon gibt es gewöhnlich drei, die phys. Sektoren der Platte (zunehmend 4k), den LBA und den Sektor des Filesystems, auch Cluster genannt.

1668mib schrieb:

@hdthtfhf: Es geht mir auch weniger darum, dass man die Menge erfahren kann, sondern dass solche Kenntnisse einen Angriff eventuell erleichtern können.

Zum Vergrößern anklicken....

Der entfernten Möglichkeit einen Angriff zu erleichtern stehen also handfeste Nachteile für Performance und Lebensdauer der SSD gegenüber.

1668mib schrieb:

Wobei bei vernünftiger Verschlüsselung ein Angriff die nächsten Jahrzehnte eh eher theoretischer Natur ist...

Zum Vergrößern anklicken....

Auf Jahrzehnte zu planen ist ebenso unnötig wie unmöglich. Die Entwicklung der Rechenleistung ist nicht vorhersehbar, wer hätte vor Jahren erwartet, dass MD5 Hashes dank GPU-Computation heute binnen kürzester Zeit geknackt werden können? Unnötig ist es, weil die verschlüsselten Daten danach wohl kaum noch relevant sind, weil das Geschäft dann abgeschlossen ist, das Patent erteilt oder schon längst abgeleufen ist, die Starftat verjährt ist, etc.

@Holt:
Richtig, ohne Trim kann der Controller gar nicht erfahren, dass etwas gelöscht wurde.

Holt schrieb:

Wie soll der Angreifer bitte an diese Information kommen,

Zum Vergrößern anklicken....

hat jemand selbst beantwortet:

Holt schrieb:

sondern i.d.R. nur Nullen

Zum Vergrößern anklicken....

Sorry du verstehst nicht was ich meine. Du benutzst das Wort in falschen Kontext. LBA ist keine Einheit. Es ist ein Verfahren. Es steht für Logical Block Addressing und wie man daraus lesen kann handelt es sich um die adressierten Elemente um "Blöcke" oder auch logische Sektoren oder sonst was. Aber LBA ist ein Verfahren und wenn du von Speichereinheiten sprichst, dann ist LBA nun mal das falsche Wort. Wäre wie wenn ich sage, dass auf meiner alten Festplatte einige CHS ausgefallen sind ...
Der Name der Adresse könnte man auch als LBA abkürzen, aber eigentlich ist es eine LBA-Adresse... aber das ist dann schon wieder Haarspalterei.