NVMe-SSD Samsung SM951: Verschlüsselung, Bitlocker o. auch eDrive/OPAL o.Ä. möglich?

[dark_rider]

Hallo zusammen,

mein T460s hat ja (ab Werk) eine Samsung SM951 NVMe-SSD (512 GB).

Meines Wissens bietet diese leider keine integrierte Hardware-Verschlüsselung (FDE/SED/Opal/eDrive o.Ä.), wie es die 200-GB-HDD in meinem T61p noch hatte - ist das auch Euer Stand? D.h. für eine Verschlüsselung der ganzen SSD kämen nur Software-Lösungen wie z.B. Windows Bitlocker in Frage?

Falls dem so sein sollte: Die NVMe-SSD hat ja eine extreme Performance (Lesen/Schreiben beides über 1.500 MB/s), die ich z.B. beim täglichen Voll-Backup (differentielles Image, d.h. die gesamte SSD wird gelesen, mit dem letzten Voll-Image abgeglichen und nur die Veränderungen werden dann gesichert) auch nutze. Allein das lastet die CPU schon bei 1.000 MB/s Leserate voll aus, d.h. die maximale SSD-Leserate kann dabei bereits nicht mehr erreicht werden. Würde die AES-Verschlüsselung über die CPU, die bei "normalen" Datenraten vielleicht problemlos mitkommt, bei derartigen Geschwindigkeiten ggf. hohe Last erzeugen (sowie eine stetige Grundlast, die ggf. den Lüfter vermehrt anspringen lässt) bzw. die SSD noch stärker ausbremsen?

 

[cyberjonny]

Ja, die SM951 hat leider keine Hardware-Verschlüsselung integriert.

Eine Software-Verschlüsselung z.B. via BitLocker oder TrueCrypt/VeraCrypt dürftest du im Alltagsgebrauch dank AES-NI zwar kaum spüren, aber die maximalen Lese- und Schreibgeschwindigkeiten wird sie natürlich etwas drücken. Wie stark genau, das kann dir vermutlich kaum jemand sagen. Probier es am besten einfach mal aus...

Frage: Worauf schreibst du dein Backup-Image, wenn du dabei auf 1000MB/s kommst?

 

[gestern]

die SSD noch stärker ausbremsen?

die bremst sich selber aus wenn sie heiss genug wird, die maximale schreibleistung bringt die SSD nur wenige minuten das lesen bricht ebenso nach einigen minuten dauerlasst ein.
allerdings spührt man das im "normalen" alltags anwendungen nicht.
nur bei grossen dateiverschieben / kopieren und backups.
das trifft aber auf alle NVME SSDs zu, die am markt sind, (bezogen auf laptops) dazu kommt der kontroller (datenbus) der mit heizt.

 

[s12er]

Linux-Live-DVD starten (z.B. Ubuntu) und dann ausführen:

sudo cryptsetup benchmark

Dann bekommst du eine ganz gute Übersicht, was der Prozessor in welcher AES- (und Nicht-AES-) Modi liefert.

 

[blafoo]

Hier mal ein ASS-Benchmark von einem (verhurten) Win10Pro auf dem X1 mit der SSD und Bitlocker vollverschlüsselung ))

Grüße

 

[s12er]

@blafoo: Der Test ist nicht aussagekräftig, weil einem Tool, das das Blockdevice ausliest vollkommen egal ist, ob eine Softwareverschlüsselungsschicht davor ist. Das Tool liest also die verschlüsselten Daten und entsprechend ist der Test nicht repräsentativ für die Leistung mit Verschlüsselung.

 

[dark_rider]

Probier es am besten einfach mal aus...

Naja, bis das ganze Laufwerk verschlüsselt ist, soll es Stunden dauern. Und ggf. zurück wahrscheinlich auch. Das macht man ja nicht mal so eben nebenbei.

Frage: Worauf schreibst du dein Backup-Image, wenn du dabei auf 1000MB/s kommst?

Wie ich oben schrieb, wird beim differentiellen Backup bei wenig Änderungen kaum etwas geschrieben, d.h. dabei kommt es primär auf die Lese-Performance an. Die 120 GB, die ich derzeit belegt habe, liest Drive Snapshot in 2-3 Minuten und gleicht sie dabei auch mit dem Hashfile des letzten Voll-Image ab. Sofern es wirklich kaum Änderungen gibt (z.B. bis zu 2-3 GB), dauert das Schreiben dieser auch nicht nennenswert lang. Bei größeren Änderungen der Daten oder bei einem Voll-Image dauert das Schreiben mit nur ca. 100 MB/s (NAS via Gigabit-LAN oder USB) natürlich deutlich länger, dann ist der Lesespeed der SSD irrelevant, da bei Weitem nicht ausgelastet. Aber ein Voll-Image erstelle ich nur 1x wöchentlich, die restlichen Tage reicht mir ein inkrementelles, und meistens ändern sich nicht so große Datenmengen.

Was ich allgemein aus Euren Antworten schließe: Auch mit AES-NI (scheinbar eine in der CPU integrierte Verschlüsselungs-Einheit) ist die CPU durch Software-Lösungen wie Bitlocker dennoch ein wenig ausgelasteter als normal, d.h. es läuft nicht völlig unmerklich wie z.B. USB-Traffic (eigener Controller) mit, sondern erzeugt schon etwas Last wie z.B. auch Netzwerk-Transfers (Kopieren vom/aufs NAS erzeugt bei mir z.B. meist 10% CPU-Last, Kopieren von der SSD auf eine externe USB-HDD dagegen keine nennenswerte CPU-Last), korrekt?

 

[cyberjonny]

Naja, bis das ganze Laufwerk verschlüsselt ist, soll es Stunden dauern. Das macht man ja nicht mal soeben eben nebenbei.

Das stimmt natürlich, aber nur so kannst du rausfinden, wie stark die Verschlüsselung tatsächlich bremst bzw. ob für dich dann der Vorteil der gewonnenen Sicherheit oder der Nachteil der verlorenen Geschwindigkeit überwiegt.

Wie ich oben schrieb, wird beim differentiellen Backup bei wenig Änderungen kaum etwas geschrieben, d.h. dabei kommt es primär auf die Schreib-Performance an. Die 120 GB, die ich derzeit belegt habe, liest Drive Snapshot in 2-3 Minuten und gleicht sie dabei auch mit dem Hashfile des letzten Voll-Image ab. Sofern es wirklich kaum Änderungen gibt (z.B. bis zu 2-3 GB), dauert das Schreiben dieser auch nicht nennenswert lang. Bei größeren Änderungen der Daten oder bei einem Voll-Image dauert das Schreiben mit nur ca. 100 MB/s (NAS via Gigabit-LAN oder USB) natürlich deutlich länger, dann ist der Lesespeed der SSD irrelevant, da bei Weitem nicht ausgelastet. Aber ein Voll-Image erstelle ich nur 1x wöchentlich, die restlichen Tage reicht mir ein inkrementelles.

Beim zweiten Lesen hab ichs kapiert!

Was ich allgemein aus Euren Antworten schließe: Auch mit AES-NI (scheinbar eine in der CPU integrierte Verschlüsselungs-Einheit) ist die CPU durch Software-Lösungen wie Bitlocker dennoch ein wenig ausgelasteter als normal, d.h. es läuft nicht völlig unmerklich wie z.B. USB-Traffic (eigener Controller) mit, sondern erzeugt schon etwas Last wie z.B. auch Netzwerk-Transfers (Kopieren vom/aufs NAS erzeugt bei mir z.B. meist 10% CPU-Last, Kopieren von der SSD auf eine externe USB-HDD dagegen keine nennenswerte CPU-Last), korrekt?

AES-NI ist keine "intergierte Verschlüsselungseinheit", sondern ein CPU-Befehlssatz, der bestimmte, AES-basierte Verschlüsselungen effizient(er) berechnen kann und dadurch beschleunigt. Aber ansonsten hast du recht: Selbst dann wird die Performance etwas gebremst. Im Alltag eher unmerklich, aber wenn man ohnehin an den Leistungsgrenzen arbeitet, wird es spürbar.

 

[blafoo]

@blafoo: Der Test ist nicht aussagekräftig, weil einem Tool, das das Blockdevice ausliest vollkommen egal ist, ob eine Softwareverschlüsselungsschicht davor ist. Das Tool liest also die verschlüsselten Daten und entsprechend ist der Test nicht repräsentativ für die Leistung mit Verschlüsselung.

Oi? Danke, das wusste ich nicht, dachte ASS ist File-Basierend! Welche Alterantiven gibt es zu ASS?

Grüße

 

[dark_rider]

mit der SSD

Meinst Du damit zufällig genau meine SSD (Samsung SM 951, 512 GB)?

 

[s12er]

@dark_rider, cyberjohnny:

Laut cpuboss schafft die CPU aus dem T460s 4GB pro Sekunden an AES-Datendurchsatz: http://cpuboss.com/cpu/Intel-Core-i7-6600U. Da ist natürlich nicht klar, welcher Blockmodus das ist und ob das ver- oder entschlüsselnd ist. Aber selbst, wenn das im konkreten Szenario auf die Hälfte hinausläuft, hast du immer noch Puffer bis zu den 1.5GB, die die SSD liefert. Mich würde deshalb umso mehr die Ausgabe von

sudo cryptsetup benchmark

interessieren. Bei Debian https://wiki.debianforum.de/Benchmark_für_Festplattenverschlüsselung haben sie mal eine Liste angefangen, welche CPU wie schnell ist. Die ist aber schon relativ alt. Es sind also keine aktuellen CPUs dabei und außerdem ist der Bau der Testumgebung dank o.g. Befehl nicht mehr nötig.

Hier übrigens die Ausgabe von meinem System (i7-2630QM):

> sudo cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       863736 iterations per second for 256-bit key
PBKDF2-sha256    1036142 iterations per second for 256-bit key
PBKDF2-sha512     692586 iterations per second for 256-bit key
PBKDF2-ripemd160  586451 iterations per second for 256-bit key
PBKDF2-whirlpool  424868 iterations per second for 256-bit key
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   479.6 MiB/s  1584.8 MiB/s
 serpent-cbc   128b    50.7 MiB/s   238.4 MiB/s
 twofish-cbc   128b   136.1 MiB/s   259.2 MiB/s
     aes-cbc   256b   355.4 MiB/s  1217.1 MiB/s
 serpent-cbc   256b    60.2 MiB/s   240.0 MiB/s
 twofish-cbc   256b   139.0 MiB/s   261.4 MiB/s
     aes-xts   256b  1371.3 MiB/s  1368.4 MiB/s
 serpent-xts   256b   243.2 MiB/s   234.7 MiB/s
 twofish-xts   256b   254.2 MiB/s   254.8 MiB/s
     aes-xts   512b  1081.3 MiB/s  1086.6 MiB/s
 serpent-xts   512b   247.1 MiB/s   234.0 MiB/s
 twofish-xts   512b   254.3 MiB/s   256.6 MiB/s

@blafoo: Ich habe gerade mal gesucht und bin auf das hier gestoßen: http://stackoverflow.com/questions/2762844/developers-how-does-bitlocker-affect-performance Dort verwenden sie auch AS SSD und die Unterschiede mit und ohne Verschlüsselung liegen jenseits dessen, was man durch Zufall erklären könnte. Mithin scheint das Tool das wohl doch implizit mit zu berücksichtigen. Unter Linux hätte man ein virtuelles Blockgerät, auf dem man solche Tests ausführen könnte. Vielleicht gibt es das bei Windows auch. Wenn man sich die dort geposteten Bilder anschaut, dann sieht man aber auch, dass das ge-benchmarkte Gerät jeweils identisch ist. Kann ich mir gerade nicht erklären....

Ah, BitLocker kann die Hardware-Verschlüsselung von HDDs/SSDs nutzen. Damit erklärt sich, warum im Link sich das logische Laufwerk nicht ändert. Und für deine Tests heißt das, dass du herausfinden müsstest, ob deine SSD Hardwareverschlüsselung im Zusammenhang mit Bitlocker unterstützt.

edit: Krass, ich habe das Benchmark gerade mal auf einem Core i3-6100 laufen lassen:

> cryptsetup benchmark
# Die Tests sind nur annähernd genau, da sie nicht auf den Datenträger zugreifen.
PBKDF2-sha1      1569724 iterations per second for 256-bit key
PBKDF2-sha256    1783292 iterations per second for 256-bit key
PBKDF2-sha512    1358259 iterations per second for 256-bit key
PBKDF2-ripemd160 1120273 iterations per second for 256-bit key
PBKDF2-whirlpool  799219 iterations per second for 256-bit key
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b  1132,4 MiB/s  3643,2 MiB/s
 serpent-cbc   128b    94,6 MiB/s   731,4 MiB/s
 twofish-cbc   128b   216,7 MiB/s   398,8 MiB/s
     aes-cbc   256b   866,7 MiB/s  2899,0 MiB/s
 serpent-cbc   256b    96,8 MiB/s   732,7 MiB/s
 twofish-cbc   256b   219,3 MiB/s   398,1 MiB/s
     aes-xts   256b  3615,7 MiB/s  3617,1 MiB/s
 serpent-xts   256b   704,2 MiB/s   713,1 MiB/s
 twofish-xts   256b   387,7 MiB/s   393,8 MiB/s
     aes-xts   512b  2879,7 MiB/s  2882,3 MiB/s
 serpent-xts   512b   704,7 MiB/s   713,2 MiB/s
 twofish-xts   512b   388,0 MiB/s   393,6 MiB/s

Die Zahlen von cpuboss sind also vollkommen realistisch und ich denke, du kannst ohne weiteres davon ausgehen, den vollen Datendurchsatz auch bei Software-Verschlüsselung zu erhalten.

 

[Angst]

Würde sowieso VeraCrypt empfehlen.

 

[cyberjonny]

...was aber nichts an der Sache ändert. VeraCrypt nutzt genauso AES wie BitLocker.

 

[vlooe]

@blafoo: Der Test ist nicht aussagekräftig, weil einem Tool, das das Blockdevice ausliest vollkommen egal ist, ob eine Softwareverschlüsselungsschicht davor ist. Das Tool liest also die verschlüsselten Daten und entsprechend ist der Test nicht repräsentativ für die Leistung mit Verschlüsselung.

Wie soll das funktionieren?
Ich glaube nicht, dass man eine im OS eingehängte Platte am OS vorbei direkt Blockweise lesen und schreiben kann.

 

[s12er]

Exemplarisch 1x512 Byte von der eingehängten ersten SSD. Sind dann MBR und Partitionstabelle.

edit: Warum sollte das auch nicht gehen. Das Dateisystem ist schließlich auch nur ein Stück Software, das dem Betriebssystem auf sehr ausgefeilte Weise sagt, was es wo hinschreiben und von wo lesen soll.

> $ sudo dd if=/dev/sda bs=512 count=1 | hexdump -C                                                                                                                                  
1+0 records in
1+0 records out
00000000  eb 63 90 10 8e d0 bc 00  b0 b8 00 00 8e d8 8e c0  |.c..............|
00000010  fb be 00 7c bf 00 06 b9  00 02 f3 a4 ea 21 06 00  |...|.........!..|
512 bytes copied, 0.00013239 s, 3.9 MB/s
00000020  00 be be 07 38 04 75 0b  83 c6 10 81 fe fe 07 75  |....8.u........u|
00000030  f3 eb 16 b4 02 b0 01 bb  00 7c b2 80 8a 74 01 8b  |.........|...t..|
00000040  4c 02 cd 13 ea 00 7c 00  00 eb fe 00 00 00 00 00  |L.....|.........|
00000050  00 00 00 00 00 00 00 00  00 00 00 80 c2 55 01 00  |.............U..|
00000060  00 00 00 00 ff fa 90 90  f6 c2 80 74 05 f6 c2 70  |...........t...p|
00000070  74 02 b2 80 ea 79 7c 00  00 31 c0 8e d8 8e d0 bc  |t....y|..1......|
00000080  00 20 fb a0 64 7c 3c ff  74 02 88 c2 52 be 80 7d  |. ..d|<.t...R..}|
00000090  e8 17 01 be 05 7c b4 41  bb aa 55 cd 13 5a 52 72  |.....|.A..U..ZRr|
000000a0  3d 81 fb 55 aa 75 37 83  e1 01 74 32 31 c0 89 44  |=..U.u7...t21..D|
000000b0  04 40 88 44 ff 89 44 02  c7 04 10 00 66 8b 1e 5c  |.@.D..D.....f..\|
000000c0  7c 66 89 5c 08 66 8b 1e  60 7c 66 89 5c 0c c7 44  ||f.\.f..`|f.\..D|
000000d0  06 00 70 b4 42 cd 13 72  05 bb 00 70 eb 76 b4 08  |..p.B..r...p.v..|
000000e0  cd 13 73 0d 5a 84 d2 0f  83 d8 00 be 8b 7d e9 82  |..s.Z........}..|
000000f0  00 66 0f b6 c6 88 64 ff  40 66 89 44 04 0f b6 d1  |.f....d.@f.D....|
00000100  c1 e2 02 88 e8 88 f4 40  89 44 08 0f b6 c2 c0 e8  |.......@.D......|
00000110  02 66 89 04 66 a1 60 7c  66 09 c0 75 4e 66 a1 5c  |.f..f.`|f..uNf.\|
00000120  7c 66 31 d2 66 f7 34 88  d1 31 d2 66 f7 74 04 3b  ||f1.f.4..1.f.t.;|
00000130  44 08 7d 37 fe c1 88 c5  30 c0 c1 e8 02 08 c1 88  |D.}7....0.......|
00000140  d0 5a 88 c6 bb 00 70 8e  c3 31 db b8 01 02 cd 13  |.Z....p..1......|
00000150  72 1e 8c c3 60 1e b9 00  01 8e db 31 f6 bf 00 80  |r...`......1....|
00000160  8e c6 fc f3 a5 1f 61 ff  26 5a 7c be 86 7d eb 03  |......a.&Z|..}..|
00000170  be 95 7d e8 34 00 be 9a  7d e8 2e 00 cd 18 eb fe  |..}.4...}.......|
00000180  47 52 55 42 20 00 47 65  6f 6d 00 48 61 72 64 20  |GRUB .Geom.Hard |
00000190  44 69 73 6b 00 52 65 61  64 00 20 45 72 72 6f 72  |Disk.Read. Error|
000001a0  0d 0a 00 bb 01 00 b4 0e  cd 10 ac 3c 00 75 f4 c3  |...........<.u..|
000001b0  00 00 00 00 00 00 00 00  41 9f aa ae 00 00 80 41  |........A......A|
000001c0  02 00 83 c2 22 20 00 10  00 00 00 f8 07 00 00 c2  |...." ..........|
000001d0  23 20 83 e9 7f 9a 00 08  08 00 b0 2a c7 1d 00 00  |# .........*....|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200

 

[vlooe]

Klar lesend ist das kein Problem.
Beim schreiben am OS vorbei währen die Partition vom OS verwendet wird geht 100% schief

 

[dark_rider]

Hallo s12er,

@dark_rider, cyberjohnny:

Laut cpuboss schafft die CPU aus dem T460s 4GB pro Sekunden an AES-Datendurchsatz: http://cpuboss.com/cpu/Intel-Core-i7-6600U. Da ist natürlich nicht klar, welcher Blockmodus das ist und ob das ver- oder entschlüsselnd ist. Aber selbst, wenn das im konkreten Szenario auf die Hälfte hinausläuft, hast du immer noch Puffer bis zu den 1.5GB, die die SSD liefert.
...
Die Zahlen von cpuboss sind also vollkommen realistisch und ich denke, du kannst ohne weiteres davon ausgehen, den vollen Datendurchsatz auch bei Software-Verschlüsselung zu erhalten.

Schafft die i7-6600U die 4 GB/s AES-Ver-/Entschlüsselung nebenbei, oder ist die CPU dann insgesamt voll ausgelastet, d.h. wenn sie beim differentiellen Imagen sonst bei 1 GB/s Leserate schon voll ausgelastet ist, um die Datenveränderungen im Vergleich zum Voll-Image festzustellen, geht dann das Entschlüsseln noch zusätzlich nebenbei, oder müsste sich die Datenrate dann nicht um 20% auf ca. 0,8 GB/s reduzieren, weil ca. 20% der CPU-Kapazität für das Entschlüsseln@0,8 GB/s benötigt werden (proportional gerechnet, wenn 4 GB/s 100% CPU-Last ergeben, wie von Dir angegeben)?

@blafoo: Falls Du tatsächlich die gleiche SSD wie ich hast, wäre Dein AS-SSD-Ergebnis schon deutlich unter meinem*, d.h. der Bitlocker würde die Performance schon spürbar drücken.

*
https://thinkpad-forum.de/threads/196243-User-Reviews-T460s?p=1982167&viewfull=1#post1982167
https://thinkpad-forum.de/threads/196243-User-Reviews-T460s?p=1983361&viewfull=1#post1983361

 

[s12er]

@vloee: Na ja, angezweifelt hattest du auch das Lesen. Schreiben ist selbstredend mit mehr Aufwand verbunden. Wenn man einfach willkürlich etwas in Bereiche schreibt, die vom Dateisystem reklamiert werden, dann macht man natürlich was kaputt. Man muss also entweder außerhalb davon schreiben oder erst Platz freischaufeln, den man an anderer Stelle zwischenspeichert. Dann kann man auf den fraglichen Blöcken die Schreibübungen machen und anschließend den alten Zustand wiederherstellen. Nicht umsonst wird bei den entsprechenden Linux-Tools darauf hingewiesen, dass ein Schreibtest im schlimmsten Fall Datenverlust zur Folge haben kann.

@dark_rider: Kann ich nicht sagen. Ich vermute aber, dass die knapp 4,4GB bei voller Auslastung eines Kerns gemessen sind. Ich sehe aber keinen Grund, warum man das nicht parallelisieren können sollte: Ein Kern macht die AES-Entschlüsselung, ein anderer verarbeitet die Daten. Ob das so umgesetzt ist, ist natürlich eine andere Frage, aber naheliegend wäre es.

edit: Ich würde das aber auch nicht zu theoretisch machen. Beziehungsweise: Es ist zwar interessant, sich die Zahlen und die Performance vor Augen zu führen, aber ich halte Verschlüsselung für dermaßen grundlegend, dass ich unter keinen Umständen darauf verzichten würde.

 

[vlooe]

Die AES Erweiterungen sind nur normale CPU Instruktionen die das verarbeiten von Verschlüsselung vereinfachen/beschleunigen.
Somit ist die CPU bei 4GB/s damit dann voll ausgelastet.
Wie stark sich die CPU bei verwendung der Instruktionen erwärmt weiß ich nicht.

@s12er:
Schreiben am Filesystem vorbei ist und bleibt eine blöde idee solange das Filesystem benutzt wird.
Da hat eine Herztransplantation mit einem Presslufthammer mehr aussicht auf erfolg.

 

[dark_rider]

@dark_rider: Kann ich nicht sagen. Ich vermute aber, dass die knapp 4,4GB bei voller Auslastung eines Kerns gemessen sind. Ich sehe aber keinen Grund, warum man das nicht parallelisieren können sollte: Ein Kern macht die AES-Entschlüsselung, ein anderer verarbeitet die Daten. Ob das so umgesetzt ist, ist natürlich eine andere Frage, aber naheliegend wäre es.

Beim inkrementellen Backup sind bei mir aber alle Kerne (2 physische bzw. 4 virtuelle/logische) zu 100% ausgelastet, d.h. es gibt dann keinen freien mehr. Somit würde die Verschlüsselung sicherlich zu Verlangsamungen führen.

edit: Ich würde das aber auch nicht zu theoretisch machen. Beziehungsweise: Es ist zwar interessant, sich die Zahlen und die Performance vor Augen zu führen, aber ich halte Verschlüsselung für dermaßen grundlegend, dass ich unter keinen Umständen darauf verzichten würde.

Die Alternative wäre halt, die NVMe-SSD durch eine solche mit Hardware-Verschlüsselung zu ersetzen. Gibt es das eigentlich? Ich las mal, dass die Samsung 950 Pro das bieten soll?