SSD Innenleben: Disk- vs. Datenmanagment

[Korfox]

Wieso asymmetrische Verschlüsselung? Das macht man garantiert nicht so. Auch PGP macht das nicht so. Einerseits aus Performancegründen und zweitens ist die asymetrische Verschlüsselung prizipiell nicht für die direkte Verschlüsselung vom Daten geeignet (deterministisch, Klartextangriff ist möglich).

Hier wird garantiert AES-Verschlüsselung gemacht und beim Setzen des Passwortes der AES-Schlüssel via Trap-Door-Funktion verschlüsselt. Solange kein Passwort gesetzt ist, ist der Schlüssel in der SSD unverschlüsselt gespeichert, vermutlich in einem nur durch den Controller zugänglichen Bereich, wie du schon geschrieben hast.

Du hast natürlich recht. Ich verdreht die Anwendungsgebiete.
Die Daten werden mit einem generierten Schlüssel symmetrisch verschlüsselt. Wenn man "Verschlüsselung aktiviert" wird dieser generierte Schlüssel auch verschlüsselt.

 

[Schwartz]

Immerhin wurde da durch Wear Leveling der Systembereich ausgelagert auf den regulären NAND. Habe schon Horrorstories gehört dass bei manchen Controllern das gar nicht passiert. Wenn man dann den Systembereich durch bestimmte Nutzungsverhalten stark belastet kann der NAND durchaus noch gut sein, nur der Systemteil ist zu tode geschrieben.

 

[rennradler]

Allgemein guter Talk zum Thema, einer der interessantesten die ich live gesehen hab.

Ich bin mir fast sicher, daß die NSA beim Design beratend mitgewirkt hat. So schlecht kann man es doch gar nicht machen, außer man möchte Hintertürchen schaffen.

Ich würde nur Linux mit LUCS oder anderen Open-Source-Lösungen wie das genannte Veracrypt vertrauen.

Auf die Möglichkeit von Data Recovery würde ich sowieso nicht bauen. Hab da ein paar youtube-Videos angeschaut. Meist ist da nichts zu holen - jedenfalls nicht mit vertretbarem Aufwand. Also: Backup haben oder Daten weg.

 

[ebastler]

Mein Problem mit Software verschlüsselung ist der Performance Impact und der Ärger mit Dualboot, da ich eigentlich Filesystem Zugriffe zwischen den Systemen will.

HW encryption habe ich ca. 1mio IOPS, mit bitlocker in Software knapp 100k. Das ist schon ein arger unterschied, der sich auch im Alltag bemerkbar macht. Manche Anwendungen starten langsamer und reagieren träger wenn sie was IO lastiges machen.

 

[Schwartz]

Es hat sich bei mir im Vergleich auch herausgestellt, dass BitLocker deutlich langsamer war.. trotz der Beteuerungen, er sei mit den simplen Settings wie 128bit dann doch schneller als VeraCrypt. In beiden Fällen war das mit AES-Hardwarebeschleunigung des CPUs - nicht die der SSD.

 

[Ambrosius]

Mir war gar nicht klar, dass Verschlüsselungen in HW doch sehr viel kontroverser sind, als nach außen kommuniziert wird. Es scheint doch als seien SED's nicht der heilige Gral. Dass Bitlocker, Veracryp oder LUKS auch Nachteile haben ist durchaus realistisch. Jeder Layer der zusätzlich die Lese- und Schreibvorgänge trübt sorgt für zusätzlichen 'Widerstand' mag ich fast sagen. Wenn SED's der technische de facto Standard geworden ist, kann man das Feature auch wieder händisch deaktivieren oder ist der Prozess mit dem Controller verheiratet?

Und wir verhält sich denn bei der Wiederherstellung die Firmware (i.e. Controller) und der NAND Flash Speicher selbst? Hier steht:

Um erstmal an die Daten der Festplatten zu kommen wurde zunächst versucht, die ausgefallenen Controller wieder in Gang zu bringen. Durch Reparatur der Firmware auf den Controllern ließen sich dann die verschlüsselten Daten auslesen und auf einem externen Speichermedium ablegen. /L

Wie wahrscheinlich ist es dass eine SSD-Firmware die beispielsweise während eines Updatevorgangs gebrickt wurde (aus welchen Gründen auch immer) reparabel ist? Ich bin davon ausgeganen, dass die Mapping Table, also die Liste die der Controller verwaltet und auflistet auf welchen Sektoren und Blöcken welche Datei liegt, der Controller selbst im D-Ram abspeichert. Wäre es also möglich die Mapping Table zu extrahieren und den Nand heraus zu operieren und auf ein Board mit gesundem identischen Controller zu transplantieren? Die Mapping Table zu transferieren und den Zugriff auf die Daten so wieder herzustellen?

Es scheint als hätte man sich bei aller Liebe zum Fortschritt die Tür zum eigenen Heim selbst zugeknallt und dass auch noch fast irreversibel. Wieso ist die Architektur so filigran und ausgefeilt, aber man schafft es nicht wieder ins Haus zu kommen, hat man sich einmal ausgesperrt?

 

[TheGrey]

Verschlüsselung ist irgendwie so gar nicht meins, hab immer Angst, dass ich nicht mehr rankomme. Aber Deine allerletzte Frage ist einfach zu beantworten. Bei klassischer Sicherheitstechnik (Haus, Tür, Tresor) will man ja verhindern, dass unbefugte Zutritt erlangen.
Bei Daten ist das ja gar nicht so anders. Nur mit dem Effekt, dass es eben möglichst keine Hintertürchen gibt und so gehen bei HW Defekt die Daten eben über den Jordan.
Denk mal an den Panik Modus mancher Smartphones, die dann alle Daten bzw den Schlüssel dazu überschreiben, wenn man genügend oft Fehlersuche oder an/aus/an/usw. in bestimmer Frequenz drückt.
Und deswegen gibt es bei Daten ja Backups

EDIT: Tippfehler vom Smartphone korrigiert.

 

[rennradler]

Mein Problem mit Software verschlüsselung ist der Performance Impact und der Ärger mit Dualboot, da ich eigentlich Filesystem Zugriffe zwischen den Systemen will.

Bei Verschlüsselung wird m.E. oft gelogen was die Performance angeht (absichtlich (wer will schon sagen, Verschlüsselung ist saumäßig langsam) oder unabsichtlich oder die Augen verschließend). Da wird aus den Performance-Tests von cryptsetup geschlossen, daß Verschlüsselung nicht relevant bremst. Beispielsweise ergibt sich auf meinem T480s
mit aes-xts 2742,9 MiB/s.
Da könnte man sagen, daß das im Bereich dessen ist, das die SSD liefern kann. Was dann aber effektiv ankommt, ist doch mehr als enttäuschend, wenn man diesem Artikel glaubt (ähnliche AES-Werte wie bei mir):
https://blog.cloudflare.com/speeding-up-linux-disk-encryption/
Ursache ist laut dem Artikel ein ausgefeilter Queuing-Mechanismus im Kernel, der zu heftigen Latenzen führt. Der Artikel spricht von einem Faktor 1/7 bei der Transferrate gegenüber unverschlüsselten Daten. Glaubt man dem Artikel, ist das Verfahren historisch gewachsen und nicht auf die aktuelle Technik angepaßt. Selbst die Verbesserungen, die da vorgeschlagen werden, bedeuten nur Verdopplung, als immer noch 1/4 der unverschlüsselten Transferrate.

Fazit für mich: man sollte sich überlegen, was man zu schützen hat. Ist es wirklich nötig, alle Partitionen zu verschlüsseln? Welchen Sinn macht es, daß z.B. das Root-Filesystem verschlüsselt ist und dann Programme langsamer laden - man also doch deutlich was merkt? Reicht es vielleicht nicht, nur /home zu verschlüsseln, weil das wichtigste Bedrohungsszenarion ist, daß der Laptop geklaut wird?

 

[xxxx]

Selbst die Verbesserungen, die da vorgeschlagen werden, bedeuten nur Verdopplung, als immer noch 1/4 der unverschlüsselten Transferrate.

Aber in dem verlinkten Artikel wird dann auch konzediert (und mit einem schönen Graphen illustriert ["snapshot of the production impact"]), dass deren Patch in der realen, harten Cloudflare-Welt phantastisch funktioniert: "As we can see the default Linux disk encryption implementation has a significant impact on our cache latency in worst case scenarios, whereas the patched implementation is indistinguishable from not using encryption at all." [Hervorhebung von mir.] "These patches have been running across our wide network of more than 200 data centres on five generations of hardware, so can be reasonably considered stable."
In einer allgemeineren Form sind diese Patches seit der Kernel-Version 5.19 in den Linux-Kernel integriert (die zwei Flags "no_read_workqueue" und "no_write_workqueue"; siehe https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-crypt.html).
Das heißt, wenn man diese Flags gesetzt hat, dürfte man im Alltag trotz Verschlüsselung keine Performance-Einbußen merken. Oder, wie es im Cloudflare-Blogbeitrag flapsig formuliert wurde: "[…] we basically get it [the encryption] for free! That’s a win!"

 

[rennradler]

Aber in dem verlinkten Artikel wird dann auch konzediert (und mit einem schönen Graphen illustriert ["snapshot of the production impact"]), dass deren Patch in der realen, harten Cloudflare-Welt phantastisch funktioniert:

Es mag grotesk klingen: das könnte bei Desktopeinsatz anders sein. Warum? Die berühmte c't-Schwuppdiness. Wie lange dauert das Starten einer großen Anwendung usw. - also die gefühlte Performance. (Das ist m.E. einer der schlimmsten Fehler von Ubuntu und deren snap-Packages - es fühlt sich alles deutlich zäher an also ohne den Mist, obwohl es dann beim Arbeiten keinen Unterschied mehr macht).

 

[xxxx]

[…] einer der schlimmsten Fehler von Ubuntu und deren snap-Packages […]

Genau. snap ist einer der schlimmsten Fehler von Ubuntu. Das meine ich wirklich. Was den strukturellen Flurschaden angeht genauso wie den Aufbau und die Distribution dieser "Apps".
Wer snap nutzt, ist selbst schuld - und ich glaube, wer seinen Kernel selbst kompiliert, weil er/sie ein bestimmtes Flag setzen will, für den kommt snap nicht in Frage. Das ist wirklich ein anderes Universum.

 

[Ambrosius]

Die berühmte c't-Schwuppdiness.

Ah ja die Schwuppdizität...

Ich glaub auch, dass Root zu verschlüsseln gut sein kann, aber nicht immer zwingend notwendig sein muss. Vielleicht tuts dann auch einfach der BIOS-seitige Power On PW als Alternative

 

[Schwartz]

Das ganze OS zu verschlüsseln halte ich für Overkill. Im Windows gibt's noch das rustikale EFS womit man das bequem per Ordner machen kann. Das hängt dann an den jeweiligen Nutzerpasswörtern und wird beim Logon entschlüsselt. Im Linux würd ich ebenso bequem nur /home verschlüsseln.

Gegen diese Container-isierung hab ich auch eine Aversion. Okay, darf es geben weil im Linux prinzipell alles "darf", aber doch nicht als Standard und auch nicht mit nur Canonical als Verteiler.