Mein Geschäft hat mir neues Werkzeug zur Verfügung gestellt: Ein frischer Laptop, zeitgemäß mit einer SSD ausgestattet. Natürlich möchte ich meine Daten nicht nur „einfach so“ ablegen, sondern angemessen gegen den Fall eines Verlusts sichern. Nach kurzem Zögern entschied ich mich für eine Neuinstallation mit komplett verschlüsstelen Partitionen.

Zunächst war da die Wahl der Krypto-Verfahren für die Partitionen. Sabayon benutzt als Default AES/XTS-Plain und SHA1 als Hashfunktion. Eigentlich gilt meine Sympathie eher Twofish; moderne CPUs bieten allerdings (nur) für AES spezielle Assemblerbefehle, so daß ich hier einen deutlichen Geschwindigkeitsvorteil vermute – und den würde ich bei einer SSD auch gerne mitnehmen ;-) XTS ist als Blockmodus wohl in Ordnung, und auch vor SHA1 hat man in diesem Zusammenhang nichts zu fürchten, die Funktion wird nur zum Ableiten des eigentlichen Schlüssels aus dem eingegebenen Kennwort verwendet.

SSDs arbeiten dann besonders schnell bzw. sind länger haltbar, wenn das Betriebssystem ihr mitteilt, welche Bereiche nicht (mehr) verwendet werden. Normalerweise möchte man bei verschlüsselten Partitionen so wenig Information wie möglich nach außen preisgeben – das gilt auch für den Füllungsgrad und die Verteilung der belegten Blöcke, aus diesem Grund füllt man normalerweise einer Partition zunächst komplett mit Zufallszahlen. Ein solches Vorgehen ist der Lebensdauer einer SSD nicht zuträglich, weshalb ich mich entschied, hier Abstriche zu machen. Ein Forensiker so allerdings eine Reihe von Informationen ableiten:

• Wieviel Platz ist mit Daten belegt (welche „Ausbeute“ ist bei einem erfolgreichen Angriff zu erwarten)
• Angriffe können gezielter durchgeführt werden, da man weiß, auf welche Bereiche man sich konzentrieren kann.
• Unterschiedliche Dateisysteme haben bei der Ablage ihrer Verwaltungsstrukturen (und möglicherweise auch der eigentlichen Daten) charakteristische Muster, die so direkt sichtbar sind. Dies kann insbesondere für „Known Plaintext“-Angriffe sehr nützlich sein.

Dieser Blogartikel beschreibt den Sachverhalt nochmals sehr anschaulich. Geht es also um ernstzunehmende Sicherheitsanforderungen, ist von dieser Optimierung dringend abzuraten. Möchte man auf die Vorzüge einer SSD dennoch nicht verzichten, könnte eine mögliche Strategie die sein, einen Teil des verfügbaren Platzes nicht zu nutzen (z.B. nur 75% partitionieren und den Rest blank lassen). Ich habe das nicht ausprobiert, aber theoretisch hat die SSD so genügend „Luft“ für Wear Leveling. Ein hartnäckiger Forensiker würde dann aber sicher versuchen, die SSD-internen Wear-Leveling-Daten auszuwerten, gut möglich, daß sich hieraus wieder Rückschlüsse auf „hot spots“, also häufig veränderte Bereiche schließen lassen, welche wiederum ein Indiz für z.B. zentrale Filesystem-Strukturen sein können. Knifflig :-)

Das „Trim”-Kommando, was freigegebene Plattenbereiche angibt, muß nun vom Dateisystem durch Verschlüsselung und LVM bis zur Platte durchgereicht werden. Hinweise hierzu habe ich in diesem Blogartikel gefunden. Folgende Schritte waren bei mir nötig:

• Mounten der Dateisysteme mit der discard-Option – ein einfacher Eintrag in der /etc/fstab bei den Mount-Optionen erledigt das.
• Durchreichen durch die LUKS-Verschlüsselung. Wird ein LUKS-Container manuell mit cryptsetup geöffnet, geschieht dies durch den Parameter --allow-discards. In der Datei /etc/crypttab wird es mit der Angabe discard erledigt.
• Zu guter Letzt muß auch LVM dazu gebracht werden, mitzuspielen. Dies erreicht man durch Setzen der Option issue_discards = 1 in der Datei /etc/lvm/lvm.conf.
• Abschließend war noch ein letzter Kniff nötig: Damit die Init-Ramdisk das verschlüsselte root-Dateisystem entsprechend öffnet, muß bei Sabayon (bzw. Gentoo) als Bootparameter root_trim=yes übergeben werden. Um dies beim automatischen Generieren der Grub-Konfiguration zu erhalten, mußte ich in der Datei /etc/default/grub die Variable GRUB_CMDLINE_LINUX um diese Angabe ergänzen.

Nun erhält die SSD die Information, welche Blöcke nicht mehr benötigt werden. Um sie tatsächlich freizugeben, ist ein Aufruf von fstrim nötig. Dies kann man z.B. per cron-Job stündlich erledigen lassen.