Leserartikel BitLocker Hardware Encryption eDrive

[Bob.Dig]

Dazu hatte ich mich ja schon geäußert und Benches verlinkt.

Habe jetzt ein Asrock Board und die Hardwareverschlüsselung funktioniert!

SecureBoot musste wie immer nicht aktiviert weden. Diesmal habe ich aber das TPM benutzt und musste kein Passwort eingeben. Frage mich wozu das dann gut ist aber war eh nur ein Testlauf.
Das Asrock Board ist auch besser ausgestattet, hätte ich es mal gleich genommen. Ergo bei Asrock und Asus geht es, bei MSI anscheinend nicht.

ENDE

 

[Bob.Dig]

Doch nicht Ende, mit den BIOS-Updates im März: "Support new Athlon 2xxGE series APU" geht auch bei ASRock die BitLocker Hardware Encryption für SED bei AM4 nicht mehr. Katastrophaler Nebeneffekt: Weder bootet das System durch, noch kommt man ins BIOS, wenn auch nur ein einziges Drive die BitLocker Hardware Encryption nutzt. Stattdessen bleibt der Bildschirm einfach schwarz.

 

[tox1c90]

Es ist leider nicht nur bei Asrocks AM4-Plattformen so...

Ich habe ein Asrock Z370-Pro4 und 3 SATA-SSDs (Samsung 840 Evo, Samsung 860 Evo, Crucial MX500) mit aktivierter Bitlocker-Hardwareverschlüsselung, also als eDrive aktiviert.

Hatte mir dann eine Samsung 970 Evo NVMe-SSD zugelegt und bei Asrock angefragt, wie das aussieht mit dem eDrive-Support für NVMe-SSDs und von hardwareverschlüsselten NVMe booten zu können (was die meisten Boards nicht können und ein UEFI-Update benötigen).

Kurz danach kam vom Asrock-Support ein Beta-Update auf UEFI 3.25, in das man laut Support das Encryption-Modul für NVMe-Drives eingebaut hatte.
Nach dem Flash hatte ich damit das exakt gleiche Problem, das du beschreibst. Kurz zeigt sich das Asrock-Logo, dann schwarzer Bildschirm. Kein Boot und kein Zugriff auf das UEFI mehr, komplett tot. CMOS-Reset bringt auch nix.
Habe dann durch schnelles TAB drücken wenn das Logo kommt (und vor dem schwarzen Bildschirm) festgestellt, dass das Board in der SATA-Initialisierungsphase festhängt.

Also alle SATA-SSDs abgesteckt, und sofort ging wieder alles. Sobald eine einzige dran hing, trat der Fehler wieder auf. Hab es dann mit einer unverschlüsselten, leeren SSD probiert -> ging. Nach einigem weiteren Testen hatte ich es raus, dass es definitiv an dem aktivierten eDrive liegt. Habe dann ein Downgrade auf UEFI 3.20 gemacht und alles ging wieder.

Also habe ich dem Asrock-Support von meiner Erkenntnis berichtet, und die meinten sogar sie führen weitere Tests dazu durch. Paar Tage später kam eine Mail zurück, dass sie das Problem reproduzieren konnten, jedoch keine andere Lösung dafür haben als die Hardwareverschlüsselung abzuschalten.

Hier ist die Antwort vom Asrock-Support:

Hello,

feedback from BIOS department:

After checking and experimenting, we get below conclusion regarding hardwareencryption Bitlocker.
If the system is under encrypted status, it cannot boot into Windows again when restart system.
Only re-install OS or remove encrypted HDD and then able to boot properly.

So, please decrypted hardware encryption before shut down or restart system.
Then system is able to work normally.

best regards,

ASRock Support

Der Tipp, die Verschlüsselung vor dem Runterfahren oder Neustart auszumachen, ist natürlich nicht wirklich eine Lösung. Aber der eigtl. Hammer: 2 Wochen später, kam ein UEFI 3.30 als finale Version in den Downloadbereich. Ich gehe natürlich davon aus, sie haben den Fehler in der Zwischenzeit behoben weil sie das final für alle releasen, flashe das finale UEFI und boom, genau der gleiche Fehler.

Kann man wohl nichts anderes machen, außer als Nutzer von hardwareverschlüsselten SSDs in Zukunft einen Bogen um Asrock zu machen

 

[Bob.Dig]

Interessant. Mir ging es aber nicht um das Booten von NVMe als eDrive, die Hoffnung habe ich schon längst aufgegeben. Aber dass es jetzt bei ASRock auch nicht mehr als Zweitlaufwerk geht...

 

[tox1c90]

Das ist bei mir halt das, was super doof ist. Ich gehe mal von aus, das Booten von eDrive-NVMe funktioniert jetzt mit der neuen Version (dafür hat es mir der Asrock-Support ja geschickt). Doch kann ich auf diese nicht updaten, weil dann mit meinen normalen SATA-SSDs nicht mehr funktioniert.

Noch blöder wird's, weil das gerade erst erschienene neue UEFI-Update 4.00 einen rot markierten Hinweis hat, dass man wenn man das aufspielt nicht mehr auf eine frühere Version downgraden kann (offenbar haben die etwas recht Gravierendes geändert in der neuen Version).
Einfach so auf gut Glück flashen und hoffen, dass der SATA-SSD-Bug mittlerweile behoben ist, geht also nicht. Denn ist er das nicht, kann ich nicht downgraden und das Board wird für mich zum Briefbeschwerer.

Ich verwende jetzt seit mehreren Chipsatz-Generationen Asrock-Boards und war immer zufrieden, aber das ist echt enttäuschend und beim nächsten Mal wird es dann wohl auch Asus.

 

[Bob.Dig]

@tox1c90 Ahh, realisiere gerade erst Du sprachst die ganze Zeit von intel.
WTF ASRock??? 🤬

 

[tox1c90]

Haha, ja genau. Gerade darum fand ich das so interessant und habe meine Erfahrungen damit hier noch gepostet.

Ich habe nämlich den Verdacht, die haben den für den Support der Hardwareverschlüsselung zuständigen Teil ihrer UEFIs aktualisiert, um den Support für verschlüsselte NVMe einzubauen, und dabei als Kollateralschaden selbiges auf SATA-SSDs kaputt gemacht. Im Asrock Forum postete nämlich jemand genau wie du dieselbe Geschichte auch auf AM4, ABER der erzählt als Hintergrund die gleiche Vorgeschichte wie ich.
Er wollte eDrive auf NVMe für sein AM4 Board, der Support gab ihm ein neues UEFI und das bootet mit seinen SATA SSDs nicht mehr. Haargenau die gleiche Sache. Ist wohl eindeutig Plattform übergreifend.

http://forum.asrock.com/forum_posts.asp?TID=9794&title=bitlocker-on-data-drive-no-post-ab350-gaming

 

[Bob.Dig]

Hmm, das heißt ich könnte vielleicht ein reines NVMe System als eDrive zum Laufen bekommen? Hab die SATA-SSD nämlich nur drin wegen der ursprünglichen Bootproblematik, brauchen tu ich die gar nicht. Habe aber halt deren ganz normales, finales BIOS.

Cool, danke, werde ich morgen testen.

 

[tox1c90]

So sagt es zumindest der User im Asrock Forum, muss natürlich nicht das identische Verhalten sein, falls du nicht genau das gleiche Board hast wie er.
Aber ich würde mal sagen die Chancen stehen nicht schlecht

Ich selber habe es nur mit NVMe noch nicht getestet, aber ich brauche die anderen SSDs halt unbedingt. Die Alternative bei mir wäre, diese auf Software-Bitlocker umzustellen und nur die NVMe mit Hardwareverschlüsselung zu nutzen.

Software-Bitlocker müsste dem Board eigtl egal sein, den sieht es ja gar nicht.

 

[Bob.Dig]

Na ich bin mal gespannt was morgen bei mir raus kommt. Im schlimmsten Fall muss ich die NVMe wieder ausbauen, was bedeutet den halben Rechner auseinander zu nehmen und dann das Laufwerk in einen anderen PC einzubauen um es zu entschlüsseln, was dann zu einem kompletten Auseinandernehmen eines zweiten Rechners führt... vielleicht sollte ich es doch lassen. Interessant dass sie behaupten, dass man noch Windows erneut installieren könnte, wie das, bei einem schwarzen Bildschirm...

Ergänzung (13. April 2019)

Werde es doch nicht testen, Aufwand zu groß, da beim anderen Rechner der NVMe Slot auf der Rückseite des Mainboards ist und das Board sich kaum in das Gehäuse schrauben lässt. Das war so ein Krampf beim letzten Mal, das will ich nicht noch einmal durchmachen.
Jemand anderes vielleicht?

 

[Bob.Dig]

Hab es doch mal getestet:

Spoiler: ASRock AM4 eDrive

BIOS Downgrade geht ja wie gesagt auch nicht...

 

[tox1c90]

Ach Mist... kann doch alles nicht wahr sein. Selbst wenn von ihren Kunden nur ein geringer Prozentsatz dieses Feature nutzt, wenn dem System der Support dafür gemeldet wird und sich eDrive folglich aktivieren lässt, dann muss es auch einwandfrei funktionieren und darf nicht zum Totalausfall des UEFIs führen.

Sonst dürfen sie dieses Update eben nicht bringen nach dem Motto "Sche*ß auf die paar Hansels, die das benutzen", oder sie müssen ganz offiziell den Support dafür rausnehmen. Das UEFI signalisiert mit einem gesetztem Flag dem Betriebssystem, dass das Authentifizierungsprotokoll für die Hardwareverschlüsselung unterstützt wird. Wenn Asrock das nicht anständig implementieren kann/möchte, müssen sie das abhaken und dann lässt sich eDrive auf ihren Boards eben gar nicht mehr aktivieren. Hundertmal besser als Leute in einen Bootlock rennen zu lassen.

Zu deinem Dilemma: Gibt es vielleicht (USB-)Adapter für NVMe, die das Protokoll durchschleifen, sodass du das ohne Totalumbau wieder entschlüsseln kannst?
SATA-SSDs/Platten hatte ich auch schon mit eSATA-Adapter an meinem Laptop, um sie zu entschlüsseln. mit einem UASP-USB-Adapter sollte das auch gehen, weil der ja die SATA-Kommandos 1:1 durchschleift. Ob es das für NVMe gibt weiß ich leider nicht.

Ganz generell, verstehe ich übrigens auch nicht, dass da nicht mehr Druck von Samsung, Crucial und co. kommt. Die bewerben deutlich ihre NVMe- und SATA-SSDs mit der unterstützten Hardwareverschlüsselung, scheinen jedoch auch keinerlei Zug dahinter zu bringen, dass sich das dann auch wirklich nutzen lässt. Eigtl. müssten die Kompatibilitätslisten etc. führen bzw. sagen, mit welchen Boards sich das von ihnen beworbene Feature auch einwandfrei nutzen lässt.

 

[Bob.Dig]

Ja, so macht MSI das wohl, da lies es sich erst gar nicht aktivieren auf AM4 in meinem Test. Ein solches BIOS-Upgrade produktiv zu setzen und ein Downgrade nicht zu erlauben...

Auf AM4 ist bei ASRock der Softwaresupport eh mies, z.B. die RGB-Software läuft erst seit kurzem einigermaßen smooth. Auf der Website der Boards werden die neueren Versionen der Software eingestellt ohne dass das Datum geändert wird...
ASUS witzelt gerne über den ASRock BIOS Support, vermutlich wissen die von noch viel mehr Sachen als was wir so sehen. ☹

 

[Bob.Dig]

Inzwischen ist über ein Monat verstrichen und ASRock zeigt keinerlei Aktivität das Problem überhaupt anzugehen.
🤬

 

[Bob.Dig]

Das bekommt man also für 7 EUR. Hoffe damit kann ich die SSD in einem anderen Rechner wieder entschlüsseln...

Hoffe, weil das Teil muss erst mal funktionieren und dieses mal war die M.2 auch noch mit TPM verschlüsselt.

Spoiler

Ergänzung (24. April 2019)

Dank Recovery-Key, den ich dieses mal aufgehoben habe, wusste ja, dass es wahrscheinlich Ärger gibt, kein Problem gewesen.

 

[Holt]

Diese Adapter machen nichts weiter als die mechanische Verbindung zwischen den PCIe Lanes des PCIe Slots und des M.2 Slots herzustellen. Ob man einen billigen oder einen teuren nimmt, ändert daran gar nicht, selbst bei den ganz teuren bei denen es noch einen PLX Chip gibt, ist keine besonderen Funktion für die SSD damit verbunden, sondern der PLX Chip ist eben nur einen PCIe Lane Switch und erlaubt es dann mehrere PCIe Geräte (in diesem Fall SSDs) in einem Slot zu betreiben, auch wenn Slot keine PCIe Lane Bifurkation unterstützt.

 

[tox1c90]

Fun fact: Ich habe jetzt mal testweise die Hardwareverschlüsselung auf allen SATA-SSDs deaktiviert vor dem UEFI-Update, um dann zu testen ob es bei mir mit aktuellstem UEFI wenigstens mit der NVMe-SSD funktioniert. Das Lustige ist, eDrive lässt sich auf dieser nach wie vor nicht mal aktivieren, sondern verbleibt laut Samsung Magician nur im "ready"-Zustand. Das heißt der eigtl. Grund, warum ich ursprünglich mit dem ganzen Kram den Asrock-Support kontaktiert hatte, geht immer noch nicht.

Ich glaube ich kapitulier jetzt einfach und schalte Software-Bitlocker ein. Auf einer der SATA-SSDs, auf der ich es ausprobiert habe, konnte ich mit CrystalDiskMark vorher/nachher nichtmal einen messbaren Unterschied feststellen. Das scheint der 8700k ausreichend zu beschleunigen. Mit der NVMe-SSD wird es wohl anders aussehen.
Allerdings liegt die bei mir bisher nur ungenutzt rum, unverschlüsselt wollte ich die nicht in Betrieb nehmen. Insofern ist NVMe+Software-Bitlocker mit leichten Leistungseinbußen gegenüber NVMe+Hardware-Bitlocker vielleicht immer noch besser als sie gar nicht zu benutzen.

 

[Bob.Dig]

Ich habe übrigens den ASRock-Support (D bzw. NL) angeschrieben, die scheinen das Problem überhaupt nicht zu kennen... auf meine weitere Korrespondenz erfolgte dann keine Reaktion mehr.
😥

 

[tox1c90]

Am besten weiter Druck machen... vielleicht hast du ja Glück noch an jemanden zu kommen, der sich etwas zielführender mit dem Problem befasst außer wie in meinem Fall irgendwann einfach das nach dem Motto "geht halt nicht" abzuschließen.

Btw., ich hab mein Windows auf die NVMe umgezogen und jetzt Software-verschlüsselt. CrystalDiskMark 6.0.1 sagt alle Werte gleich wie unverschlüsselt bis auf Random Write 4K Q8T8, der geht von 1322MB/s auf 1167MB/s runter. Damit kann ich erstmal leben.
Allerdings sieht man anhand der CPU-Last schon recht deutlich, dass da Bitlocker-Software am Werk ist. Der "System"-Prozess geht während des Benchmarks auf ~20-30% hoch, zusammen mit CrystalDiskMark wird die CPU dann zu ~80-90% belastet. Allerdings nur so extrem im Sequential, wenn 3,5GB/s transferiert werden. Wäre die CPU anderweitig beschäftigt, würde die Datenrate im Vergleich zur Hardwareverschlüsselung in dieser Situation wohl stark in den Keller gehen.

 

[Bob.Dig]

Meine in meinen Tests auch gesehen zu haben, dass die 970 am wenigsten durch Softwareverschlüsselung verloren hat. Das sah bei den SATA-SSDs etwas anders aus.

Aber interessant, das mit der CPU-Last. Die ist auch bei mir recht hoch mit Softwareverschlüsselung im seq. Test, insgesamt an die 25%. Jetzt fehlt mir leider der unmittelbare Vergleich zur Hardwareverschlüsselung. 🙁

Wenn die Scheiße wieder gehen sollte wird direkt geswiched.
Wenn, ASRock... 🤬