Leserartikel BitLocker Hardware Encryption eDrive
- Ersteller Bob.Dig
- Erstellt am
P4-Freak
Lt. Commander
- Registriert
- Aug. 2004
- Beiträge
- 1.243
Naja, ich wollte mit Bitlocker und TPM verschlüsseln. Also in dem sinn quasi Software und nicht hardware, oder ist dann Bitlocker auch hardware?
PS
benötigt man zwingend secure boot? Da ich ab und zu auf Linux wechseln will, hab ich es deaktiviert, es funtkioniert zwar, aber muss man das setzen?
PS
benötigt man zwingend secure boot? Da ich ab und zu auf Linux wechseln will, hab ich es deaktiviert, es funtkioniert zwar, aber muss man das setzen?
- Registriert
- Dez. 2006
- Beiträge
- 4.204
, aber nach meinem Wissen ist die Situation zusammengefasst wie folgt...
Genau mein Gedanke! Aber sie schreiben ja, dass sie für OEMs entsprechende BIOS Varianten hätten.tox1c90 schrieb:Danke für den Hinweis, damit ist Gigabyte für mich in Zukunft direkt raus.
So eine selten dämliche Begründung... Wer das Feature aktiviert, weiß genau was er tut, und dann droht a) kein versehentlicher Datenverlust und b) geht der Nutzer wenn ein solches Risiko bestünde dieses ganz bewusst ein.
Vielleicht haben sie es einfach nicht auf die Reihe bekommen das Feature korrekt funktionierend umzusetzen und haben sich daher so eine doofe Begründung ausgedacht, das nicht mehr supporten zu müssen.
Ich würde Deine Argumentation so noch mal an den Support schicken und versuchen das Durcheinander TPM/ fTPM / eDrive zu entwirren.
Jetzt dämmert mit, dass möglicherweise einiges durcheinander geworfen wurde. RyZen - und wie ich eben lernte auch Intel - bieten fTPM an. Dieses TPM wird bei einem Biosupdate wohl zurückgesetzt, was für verschlüsselte Laufwerke schlecht wäre. In meinem Gigabyte BIOS kann ich fTPM aktivieren. Es wird aber in Windows kein TPM erkannt. Das diskrete TPM dagegen wird erkannt.
P4-Freak schrieb:
Also laut Spezifikation braucht man Secure Boot eigtl. nicht, allerdings ist es wichtig, dass nativ mittels UEFI und nicht via CSM per normalem BIOS gebootet wird. Streng genommen schreibt die Spezifikation sogar vor, dass das CSM deaktiviert ist. Allerdings nach eigenen Erfahrungen nimmt es z.B. Asrock da nicht so genau, denn dort konnte ich auch schon mit eingeschaltetem CSM vom eDrive booten (solange Windows im UEFI-Modus installiert ist). Idealerweise hast du Windows und Linux aber eh beide im UEFI/GPT-Modus installiert und das CSM einfach deaktiviert.
Ergänzung ()
Bob.Dig schrieb:
Ja, genauso ist es.
Ob mit einem NVMe-eDrive alleine ohne SATA weiß ich zwar nicht, das habe ich nicht getestet (weil ich ohne Adapterspielchen dann nicht mehr zurück käme), allerdings ist das finale Release-BIOS absolut SATA-eDrive untauglich.Meine Empfehlung an Asrock wäre ja, das BIOS in Variante 2 als finales BIOS auszuliefern. Denn damit geht prinzipiell alles außer verschlüsselter NVMe-Boot, insbesondere sollte es da keine Blackscreens geben. Aber naja, müssen die selber wissen ...
palace schrieb:
Aus dem Grund hab ich meine Exkursion zum fTPM auch ganz schnell wieder beendet. Ich hatte ja die gewagte Hoffnung, man hätte das irgendwie intelligent implementiert, sodass die Inhalte des fTPMs bei einem UEFI-Update erhalten bleiben (sollte möglich sein!), aber nein, das wird im Zuge des Updates gnadenlos zurückgesetzt. Der Inhalt der diskreten TPMs bleibt hingegen unangetastet. Großer Vorteil, denn sonst geht nach jedem Update das große Neueinrichten von Windows Hello und Bitlocker los. Denn dann hängt man gerade bei letzterem erstmal im Recovery-Code und das automatische Unlocken von sekundären Data-Laufwerken ist auch erstmal futsch, d.h. beim ersten Hochfahren nach dem Update beschwert sich erstmal alles was geht, dass die Laufwerke alle weg sind.
Zuletzt bearbeitet:
Das mit der Performance und CPU-Last steht eigtl. außer Frage. Bei ner SATA-SSD kann man es ja noch zähneknirschend verschmerzen, aber bei NVMe-SSDs hört der Spaß auf.
Verstehe die Argumentation mit den theoretisch möglichen 7GB/s bei AES-NI auch nicht. Die gibt es ja nicht "on top", sondern das bedeutet, dass die CPU bei 7GB/s dann auch wirklich dicht bzw. 100% ausgelastet ist.
Umgekehrt heißt das, die 3,5GB/s einer NVMe-SSD lasten die CPU zu 50% aus. Und das halte ich für vollkommen inakzeptabel.
Ich kopiere damit ja normalerweise nicht haufenweise "tote" Daten rum, sondern habe irgendeinen meist rechenintensiven Prozess am Laufen, der die Daten so schnell abruft/schreibt. Und der wird dann unter Umständen massiv ausgebremst.
Ganz anderer Nachteil der Softwareverschlüsselung abseits der Performance ist auch, dass wenn man beispielsweise ein Image-Backup auf eine verschlüsselte Partition zurückspielt, diese danach bei fast allen Backup-Tools bis auf ganz wenige Ausnahmen im unverschlüsselten Zustand vorliegt. Weil es ohne Tricks einfach nicht geht, von einer extern gebooteten Wiederherstellungsumgebung aus einem Backup-Archiv (in dem die Daten logischerweise nicht mit Bitlocker verschlüsselt vorliegen) ein korrekt Software verschlüsseltes Bitlocker-Volume zu schreiben. D.h. anschließend muss man das zurückgespielte Volume erstmal wieder erneut komplett softwareverschlüsseln, was ewig dauert!
HW-Verschlüsselung kann man hingegen transparent für Backup-Tools benutzen. Ich unlocke die Partition einfach und bügel das Image-Backup drüber. Da das Laufwerk die Verschlüsselung übernimmt, verschlüsselt das die aus dem Backup zurückgespielten Daten von ganz alleine wieder. Nach einem Neustart ist es wieder locked. HW-Bitlocker ist die einzige mir bekannte Möglichkeit, eine System-Partition wiederherzustellen und Bitlocker dabei intakt zu lassen.
Verstehe die Argumentation mit den theoretisch möglichen 7GB/s bei AES-NI auch nicht. Die gibt es ja nicht "on top", sondern das bedeutet, dass die CPU bei 7GB/s dann auch wirklich dicht bzw. 100% ausgelastet ist.
Umgekehrt heißt das, die 3,5GB/s einer NVMe-SSD lasten die CPU zu 50% aus. Und das halte ich für vollkommen inakzeptabel.
Ich kopiere damit ja normalerweise nicht haufenweise "tote" Daten rum, sondern habe irgendeinen meist rechenintensiven Prozess am Laufen, der die Daten so schnell abruft/schreibt. Und der wird dann unter Umständen massiv ausgebremst.
Ganz anderer Nachteil der Softwareverschlüsselung abseits der Performance ist auch, dass wenn man beispielsweise ein Image-Backup auf eine verschlüsselte Partition zurückspielt, diese danach bei fast allen Backup-Tools bis auf ganz wenige Ausnahmen im unverschlüsselten Zustand vorliegt. Weil es ohne Tricks einfach nicht geht, von einer extern gebooteten Wiederherstellungsumgebung aus einem Backup-Archiv (in dem die Daten logischerweise nicht mit Bitlocker verschlüsselt vorliegen) ein korrekt Software verschlüsseltes Bitlocker-Volume zu schreiben. D.h. anschließend muss man das zurückgespielte Volume erstmal wieder erneut komplett softwareverschlüsseln, was ewig dauert!
HW-Verschlüsselung kann man hingegen transparent für Backup-Tools benutzen. Ich unlocke die Partition einfach und bügel das Image-Backup drüber. Da das Laufwerk die Verschlüsselung übernimmt, verschlüsselt das die aus dem Backup zurückgespielten Daten von ganz alleine wieder. Nach einem Neustart ist es wieder locked. HW-Bitlocker ist die einzige mir bekannte Möglichkeit, eine System-Partition wiederherzustellen und Bitlocker dabei intakt zu lassen.
Update: Nachdem Gigabyte den Ball zu mir zurückgespielt hat und mir meine Karte gab kann ich inzwischen berichten, dass Hardware Encryption über SATA funktioniert (OS als auch Data Disk).
Die NVMe Disk jedoch bekomme ich ums verrecken nicht auf Encryption Enabled State. Das müsste doch eigentlich ganz ohne BIOS Unterstützung zumindest als Data Disk möglich sein? Ich habe es sowohl mit dem MS, als auch Samsung NVMe Treiber probiert.
Die NVMe Disk jedoch bekomme ich ums verrecken nicht auf Encryption Enabled State. Das müsste doch eigentlich ganz ohne BIOS Unterstützung zumindest als Data Disk möglich sein? Ich habe es sowohl mit dem MS, als auch Samsung NVMe Treiber probiert.
Na, die Karte, die mir bescheinigte, dass ich mich zu doof angestellt habe 
. Wie gesagt, SATA SSD funktioniert ja nun. bei der NVMe SSD (Samsung 970 Evo Plus) bekomme ich Hardware Encryption nicht eingeschaltet. Im Prinzip braucht es dazu ja „nur“ ein Secure Erase und ein Initialize mit GPT. Bei der SATA SSD klappte das ja auch - bei der 970 leider nicht. Neben dem Bootstick, der mit Samsung Magician erstellt wird, habe ich auch diesen Weg probiert: https://tinyapps.org/docs/nvme-secure-erase.html
Aber der Status verbleibt auf „zur Aktivierung bereit“.
. Wie gesagt, SATA SSD funktioniert ja nun. bei der NVMe SSD (Samsung 970 Evo Plus) bekomme ich Hardware Encryption nicht eingeschaltet. Im Prinzip braucht es dazu ja „nur“ ein Secure Erase und ein Initialize mit GPT. Bei der SATA SSD klappte das ja auch - bei der 970 leider nicht. Neben dem Bootstick, der mit Samsung Magician erstellt wird, habe ich auch diesen Weg probiert: https://tinyapps.org/docs/nvme-secure-erase.html Aber der Status verbleibt auf „zur Aktivierung bereit“.
- Registriert
- Dez. 2006
- Beiträge
- 4.204
@palace
Ich dachte auch mal, dass es als Data Drive eigtl. immer gehen müsste, aber das ist leider nicht so. Die Sache sieht wohl so aus, dass die Verwaltung der Hardwareverschlüsselung nach TCG Opal 2.0 / eDrive / wieauchimmer über bestimmte Steuer-Kommandos stattfindet, die das UEFI bzw. das ins UEFI eingebaute Speichercontroller-Rom unterstützen muss, sei es nun das SATA-Rom oder das für NVMe. Und das nicht nur fürs booten, sämtliche Steuerkommandos dafür sind in der UEFI-Spezifikation definiert.
Man sieht ja an meinen Blackscreen-Problemen, was passiert, wenn man ein UEFI das von der Hardwareverschlüsselung nix weiß, auf ein damit gesperrtes Laufwerk loslässt, sei es nun OS oder Data-Drive. Für das UEFI ist das dann nichts weiter als eine kaputte Festplatte, weil beim Scannen nach Partitionen nur Kauderwelsch bzw. Antworten zurück kommen, die das UEFI nicht versteht. Ergo hängt sich das dann beim Initialisieren potenziell einfach auf.
Ich dachte auch mal, dass es als Data Drive eigtl. immer gehen müsste, aber das ist leider nicht so. Die Sache sieht wohl so aus, dass die Verwaltung der Hardwareverschlüsselung nach TCG Opal 2.0 / eDrive / wieauchimmer über bestimmte Steuer-Kommandos stattfindet, die das UEFI bzw. das ins UEFI eingebaute Speichercontroller-Rom unterstützen muss, sei es nun das SATA-Rom oder das für NVMe. Und das nicht nur fürs booten, sämtliche Steuerkommandos dafür sind in der UEFI-Spezifikation definiert.
Man sieht ja an meinen Blackscreen-Problemen, was passiert, wenn man ein UEFI das von der Hardwareverschlüsselung nix weiß, auf ein damit gesperrtes Laufwerk loslässt, sei es nun OS oder Data-Drive. Für das UEFI ist das dann nichts weiter als eine kaputte Festplatte, weil beim Scannen nach Partitionen nur Kauderwelsch bzw. Antworten zurück kommen, die das UEFI nicht versteht. Ergo hängt sich das dann beim Initialisieren potenziell einfach auf.
