Mein Ge­schäft hat mir neues Werk­zeug zur Ver­fü­gung ge­stellt: Ein fri­scher Lap­top, zeit­ge­mäß mit einer SSD aus­ge­stat­tet. Na­tür­lich möch­te ich meine Daten nicht nur „ein­fach so“ ab­le­gen, son­dern an­ge­mes­sen gegen den Fall eines Ver­lusts si­chern. Nach kur­zem Zö­gern ent­schied ich mich für eine Neu­in­stal­la­ti­on mit kom­plett ver­schlüs­s­te­len Par­ti­tio­nen.

Zu­nächst war da die Wahl der Kryp­to-Ver­fah­ren für die Par­ti­tio­nen. Sa­ba­yon be­nutzt als De­fault AES/XTS-Plain und SHA1 als Hash­funk­ti­on. Ei­gent­lich gilt meine Sym­pa­thie eher Two­fish; mo­der­ne CPUs bie­ten al­ler­dings (nur) für AES spe­zi­el­le As­sem­bler­be­feh­le, so daß ich hier einen deut­li­chen Ge­schwin­dig­keits­vor­teil ver­mu­te – und den würde ich bei einer SSD auch gerne mit­neh­men ;-) XTS ist als Block­mo­dus wohl in Ord­nung, und auch vor SHA1 hat man in die­sem Zu­sam­men­hang nichts zu fürch­ten, die Funk­ti­on wird nur zum Ab­lei­ten des ei­gent­li­chen Schlüs­sels aus dem ein­ge­ge­be­nen Kenn­wort ver­wen­det.

SSDs ar­bei­ten dann be­son­ders schnell bzw. sind län­ger halt­bar, wenn das Be­triebs­sys­tem ihr mit­teilt, wel­che Be­rei­che nicht (mehr) ver­wen­det wer­den. Nor­ma­ler­wei­se möch­te man bei ver­schlüs­sel­ten Par­ti­tio­nen so wenig In­for­ma­ti­on wie mög­lich nach außen preis­ge­ben – das gilt auch für den Fül­lungs­grad und die Ver­tei­lung der be­leg­ten Blö­cke, aus die­sem Grund füllt man nor­ma­ler­wei­se einer Par­ti­ti­on zu­nächst kom­plett mit Zu­falls­zah­len. Ein sol­ches Vor­ge­hen ist der Le­bens­dau­er einer SSD nicht zu­träg­lich, wes­halb ich mich ent­schied, hier Ab­stri­che zu ma­chen. Ein Fo­ren­si­ker so al­ler­dings eine Reihe von In­for­ma­tio­nen ab­lei­ten:

• Wie­viel Platz ist mit Daten be­legt (wel­che „Aus­beu­te“ ist bei einem er­folg­rei­chen An­griff zu er­war­ten)
• An­grif­fe kön­nen ge­ziel­ter durch­ge­führt wer­den, da man weiß, auf wel­che Be­rei­che man sich kon­zen­trie­ren kann.
• Un­ter­schied­li­che Da­tei­sys­te­me haben bei der Ab­la­ge ihrer Ver­wal­tungs­struk­tu­ren (und mög­li­cher­wei­se auch der ei­gent­li­chen Daten) cha­rak­te­ris­ti­sche Mus­ter, die so di­rekt sicht­bar sind. Dies kann ins­be­son­de­re für „Known Plain­text“-An­grif­fe sehr nütz­lich sein.

Die­ser Blo­g­ar­ti­kel be­schreibt den Sach­ver­halt noch­mals sehr an­schau­lich. Geht es also um ernst­zu­neh­men­de Si­cher­heits­an­for­de­run­gen, ist von die­ser Op­ti­mie­rung drin­gend ab­zu­ra­ten. Möch­te man auf die Vor­zü­ge einer SSD den­noch nicht ver­zich­ten, könn­te eine mög­li­che Stra­te­gie die sein, einen Teil des ver­füg­ba­ren Plat­zes nicht zu nut­zen (z.B. nur 75% par­ti­tio­nie­ren und den Rest blank las­sen). Ich habe das nicht aus­pro­biert, aber theo­re­tisch hat die SSD so ge­nü­gend „Luft“ für Wear Le­ve­ling. Ein hart­nä­cki­ger Fo­ren­si­ker würde dann aber si­cher ver­su­chen, die SSD-in­ter­nen We­ar-Le­ve­ling-Da­ten aus­zu­wer­ten, gut mög­lich, daß sich hier­aus wie­der Rück­schlüs­se auf „hot spots“, also häu­fig ver­än­der­te Be­rei­che schlie­ßen las­sen, wel­che wie­der­um ein Indiz für z.B. zen­tra­le File­sys­tem-Struk­tu­ren sein kön­nen. Kniff­lig :-)

Das „Trim”-Kom­man­do, was frei­ge­ge­be­ne Plat­ten­be­rei­che an­gibt, muß nun vom Da­tei­sys­tem durch Ver­schlüs­se­lung und LVM bis zur Plat­te durch­ge­reicht wer­den. Hin­wei­se hier­zu habe ich in die­sem Blo­g­ar­ti­kel ge­fun­den. Fol­gen­de Schrit­te waren bei mir nötig:

• Moun­ten der Da­tei­sys­te­me mit der discard-Op­ti­on – ein ein­fa­cher Ein­trag in der /etc/fstab bei den Mount-Op­tio­nen er­le­digt das.
• Durch­rei­chen durch die LUKS-Ver­schlüs­se­lung. Wird ein LUKS-Con­tai­ner ma­nu­ell mit crypt­se­t­up ge­öff­net, ge­schieht dies durch den Pa­ra­me­ter --allow-discards. In der Datei /etc/crypttab wird es mit der An­ga­be discard er­le­digt.
• Zu guter Letzt muß auch LVM dazu ge­bracht wer­den, mit­zu­spie­len. Dies er­reicht man durch Set­zen der Op­ti­on issue_discards = 1 in der Datei /etc/lvm/lvm.conf.
• Ab­schlie­ßend war noch ein letz­ter Kniff nötig: Damit die In­it-Ram­disk das ver­schlüs­sel­te root-Da­tei­sys­tem ent­spre­chend öff­net, muß bei Sa­ba­yon (bzw. Gen­too) als Boot­pa­ra­me­ter root_trim=yes über­ge­ben wer­den. Um dies beim au­to­ma­ti­schen Ge­ne­rie­ren der Grub-Kon­fi­gu­ra­ti­on zu er­hal­ten, mußte ich in der Datei /etc/default/grub die Va­ria­ble GRUB_CMDLINE_LINUX um diese An­ga­be er­gän­zen.

Nun er­hält die SSD die In­for­ma­ti­on, wel­che Blö­cke nicht mehr be­nö­tigt wer­den. Um sie tat­säch­lich frei­zu­ge­ben, ist ein Auf­ruf von fstrim nötig. Dies kann man z.B. per cron-Job stünd­lich er­le­di­gen las­sen.