Leserartikel BitLocker Hardware Encryption eDrive

Secure Boot ist am ehesten vergleichbar mit einer Datenbank von SSL-Zertifikaten, in der alle vertrauenswürdigen und nicht (mehr) vertrauenswürdigen Herausgeber aufgelistet sind.
Bei Secure Boot werden keine nutzerseitigen oder installationsspezifischen Schlüssel im UEFI abgelegt, sondern sowas wie z.B. eine Art Stammzertifikat von Microsoft, mit dem Microsoft ihre Systemdateien signiert. Darum sind die Secure Boot - Keys üblicherweise auch bei allen Leuten absolut identisch, man macht einfach "Install default Secure Boot Keys" oder so und dann wird die aktuell gültige Datenbank reingeladen. Danach wird daran nix mehr geändert.
Custom keys sind nur dafür da, eigene Signaturen einzubauen, die nicht von irgendeiner offiziellen Herausgabestelle signiert wurden. Der Microsoft-Key für Windows-Installationen ist jedoch bei allen Leuten gleich. Es gibt nur ein Szenario, wo der geändert würde: Angenommen Microsoft wird gehackt und die erbeuten die privaten Schlüssel. Dann könnten die Hacker damit Malware signieren und Secure Boot würde diese durchlassen. In diesem Fall müssen die UEFI-Entwickler dann ein neues UEFI bringen, in dem der kompromittierte Key gesperrt und der neue Microsoft-Key hinterlegt wurde.

Kurzum: Hat mit Bitlocker überhaupt nix zu tun und auch nicht mit Keys für eine bestimmte, individuelle Windows-Installation :)
Ich dachte früher mal, dass Secure Boot irgendeine Art Tresor ist, in dem das OS bei seiner Installation irgendwelche Schlüssel erzeugt und ablegt, die spezifisch für die konkrete Installation sind. Aber das ist in echt eigtl. viel primitiver. Da ist einfach von jedem Hersteller (der bezahlt hat? ^^) ein Key drin, fertig.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: R4Z3R, palace und Bob.Dig
Habe spaßeshalber - hätte ja heute zum Zuge kommen können mit dem Ryzen 9 3950X, sollte aber nicht sein - ein Beta-BIOS mit AGESA 1.0.0.4 geflasht. Ich konnte dort teilweise das Drive nur per PowerShell entschlüsseln und andere Scherze. Bin mal gespannt, ob das nur an der nicht ganz geeigneten CPU meinerseits lag oder ob da was anrollt...
 
Vielen Dank für euer Engagement, leider kommt das Thema Verschlüsselung viel zu kurz und wird oft belächelt.
Gibt es eine Kombination (Mainboard+NVMe+AM4) die ihr vorbehaltlos empfehlen könnt? Ansonsten bleibt nur noch die Softwareverschlüsselung.
 
@donut1 Die relevanten Antworten darauf sollten in der Tabelle im Startpost zu finden sein.
 
Mir war nicht klar, dass die Tabelle für sämtliche Chipsets und sämltiche SSD-Hersteller gilt. Dachte da gibt es mehr Unterschiede in der Umsetzung. Wenn dem nicht so ist, umso besser.
 
@donut1 So zumindest der Kenntnisstand. 😇
 
Hatte etwas Zeit nun und hab es jetzt auch endlich geschafft! Nach Wechsel von Asus auf Asrock und mit der Disable Block SID Option klappt nun alles, benutze das neuste Bios fürs B450Pro4, ohne Downgrade oder sonstiges. Danke euch allen, besonders @Bob.Dig
 
  • Gefällt mir
Reaktionen: palace und Bob.Dig
AMD Ryzen 9 3900X + Gigabyte X570 AORUS ULTRA (F11 Bios) + Samsung SSD 970 EVO Plus 1TB
Die Hardwareverschlüsselung lies sich problemlos aktivieren und läuft einwandfrei.
 
  • Gefällt mir
Reaktionen: palace
@Hummerman Danke für die Rückmeldung und das Ausgraben des Accounts. 😁
 
Gibt es eigentlich ein "neutrales" Tool, um einen PSID Reset durchzuführen?

Habe noch ein paar ältere Crucial SSDs (M500, M550, jeweils mit aktuellester offizizieller Firnware). Obwohl ich Bitlocker o. ä. nie (bewusst) verwendet habe, haben sie alle scheinbar ihre Schutzfunktion gegen einen Secure Erase aktiviert.

Crucials Storage Executive erkennt sie nicht als Laufwerke wo die PSID zurückgesetzt werden könnte, kann sie aber auch nicht löschen (Maindboard-SATA-Controller ist im AHCI-Modus).

Habe sie alle vor Jahren schon über Parted Magic ge-Secure-Erased, aktuell geht es aber nicht mit dem Hinweis, dass die Laufwerke dies nicht unterstützen würden und eventuell ein PSID Reset gemacht werden müsse.

Sonst funktionieren sie einwandfrei und stabil (noch 98-99 % ihrer NAND-Lebenserwartung), mich stört es aber eben, wenn man SSDs nicht schnell sicher löschen kann.
 
Zuletzt bearbeitet:
Crucial SSDs sind ab Werk eDrive enabled und werden daher bei der Initialisierung auf einem unterstützten System direkt geswitched (d.h. oft bei Leuten, welche den Microsoft-SATA-Treiber nutzen und nicht den von Intel, der selbiges blockiert). Darum geht dann kein Secure Erase mehr.

Allerdings sollte das Crucial Tool das in jedem Fall erkennen und ein PSID Revert anbieten. Wenn das es nicht tut, wüsste ich auch nicht wie das ein anderes Tool bewerkstelligen könnte. Habe jedoch schonmal gehört, dass es solche gibt und sich das theoretisch auch von einem Linux-Live-System aus machen lässt.

Kann es sein, dass du vielleicht eine Windows-Installation auf dieser gemacht hast (d.h. zu diesem Zeitpunkt noch Microsoft-SATA-Treiber) und anschließend dann den Intel iaStor-Treiber installiert hast? Dieser blockiert die eDrive-Kommandos. Wenn der läuft wird eDrive nicht erkannt und dann geht auch kein PSID-Revert. In dem Fall wäre die Lösung vermutlich zurück zum Microsoft-SATA-Treiber oder woanders anschließen wo nur dieser installiert ist.
 
tox1c90 schrieb:
Crucial SSDs sind ab Werk eDrive enabled und werden daher bei der Initialisierung auf einem unterstützten System direkt geswitched [...]

Ich bitte für die späte Antwort um Entschuldigung!

Ja, Windows wurde mal auf den Crucial M500 SSDs installiert (Intel-Chipsätze)

Nun habe ich sie zum ersten Mal an ein AMD-System (X570, aktuellstes UEFI, SATA-Controller im AHCI-Modus) gehängt und hier meint Crucial Storage Executive leider ebenfalls, dass eine PSID-Wiederherstellung (und sicheres Löschen) von den Laufwerken nicht unterstützt wird :(
 
Habe jetzt für ein anders System, welches keine entsprechenden UEFI-Optionen hat, versucht, weitere Samsung NVMe-Drives in meinem System auf eDrive umzustellen und es hat funktioniert.
Habe diese der Einfachheit halber mittels Adapter bei mir eingebaut, mit Magician vorbereitet, mit diskpart gecleaned und die GP hardwarebasierte Verschlüsselung für Datenlaufwerke aktiviert. Dann musste ich wieder ins UEFI und disbale Block Sid aktivieren (ohne dies ging es nicht). Danach in Windows das Laufwerk in der Datenträgerverwaltung initialisiert und damit war dann eDrive aktiviert. Ich hatte Schiss, ich müsste nun auf jedes Laufwerk Windows installieren, das war aber nicht der Fall. 😌

Man kann die Schritte für eDrive daher wohl wie folgt zusammenfassen:
  1. Ready to Enable mittels Magician
  2. uninitialisiertes Drive
  3. disbale Block Sid im UEFI aktivieren
  4. Windows als reines UEFI-System
  5. (GP Hardwarebasiertes BitLocker in Windows aktivieren)
  6. Initialisieren des Drives in der Datenträgerverwaltung (oder bei der Windowsinstallation).
 
Zuletzt bearbeitet:
JBG schrieb:
[...]

Ja, Windows wurde mal auf den Crucial M500 SSDs installiert (Intel-Chipsätze)

Nun habe ich sie zum ersten Mal an ein AMD-System (X570, aktuellstes UEFI, SATA-Controller im AHCI-Modus) gehängt und hier meint Crucial Storage Executive leider ebenfalls, dass eine PSID-Wiederherstellung (und sicheres Löschen) von den Laufwerken nicht unterstützt wird :(

Manchmal sieht man den Wald vor lauter Bäumen nicht: In neueren Parted Magic-Versionen gibt es im Festplatten-Lösch-Programm eine weitere Funktion zum PSID-Zurücksetzen.

Mit diesem konnte ich die Crucial M500 problemlos zurücksetzen und anschließend ging auch die Secure Erase-Funktion wieder.

Super Software-Qualität von Crucial, dass die eigene Software mit eigenen SSDs nicht klarkommt - da halte ich es für nicht relevant, dass die M500 schon ein altes Eisen ist, durch den MLC-NAND dürften sie noch lange leben, solange die Controller nicht ausfallen.
 
  • Gefällt mir
Reaktionen: palace
Ich habe jetzt noch zusätzlich eine Samsung SSD 860 QVO 4TB SATA als BitLocker eDrive im Einsatz, hat einwandfrei funktioniert.
 
  • Gefällt mir
Reaktionen: palace
Habe hier mit einer Win10 2004 Fresh-Install versucht, die hardwarebasierte Verschlüsselung einzuschalten, ohne Erfolg.
Capture.PNG Capture.PNG Capture2.PNG


Das ist daher auch als Warnung für diejenigen zu verstehen, die nach dem offiziellen Release mit bestehender Verschlüsselung upgraden wollen.​
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: tox1c90
Soweit ich weiß, hatte MS doch die HW-basierte Verschlüsselung deaktiviert. Wobei ich jetzt nicht weiß, ob man sie mit Gruppenrichtlinien erzwingen kann...
 
Darkman.X schrieb:
Soweit ich weiß, hatte MS doch die HW-basierte Verschlüsselung deaktiviert. Wobei ich jetzt nicht weiß, ob man sie mit Gruppenrichtlinien erzwingen kann...

Ja, das wissen wir! Und das lässt sich in der Tat per Gruppenrichtlinie wieder einschalten. Und das hat Bob.Dig auch getan, die Aussage ist, dass es nun neuerdings wohl trotzdem in einen Fehler rennt.
 
  • Gefällt mir
Reaktionen: Bob.Dig
tox1c90 schrieb:
Ja, das wissen wir! Und das lässt sich in der Tat per Gruppenrichtlinie wieder einschalten. Und das hat Bob.Dig auch getan, die Aussage ist, dass es nun neuerdings wohl trotzdem in einen Fehler rennt.
Das Ganze gab es schon einmal in der Win10 Geschichte, damals wurde die Funktionalität mit einem Patchday wieder nachgereicht. Ob das wieder so kommt?

Mich beschleicht auch langsam das Gefühl, dass die hardwarebasierte Verschlüsselung nicht per se unsicherer ist, sondern im Gegenteil, einfach nicht unter der Kontrolle von MS steht und deswegen weg soll, man bedenke den "War On Encryption".
Welche größere Firma setzt Veracrypt ein, eher keine. BitLocker aber ist durchaus in Verwendung.
 
Zuletzt bearbeitet:
Bob.Dig schrieb:
Welche größere Firma würde wohl Veracrypt einstzen, eher keine. Aber BitLocker ist durchaus in Verwendung.
Ja, aber das liegt daran, dass Bitlocker viel einfacher zu managen ist als Veracrypt in größeren Umgebungen.
 
Zuletzt bearbeitet:
Zurück
Oben