B
Bob.Dig
Gast
Nur zur Klarstellung, was man da umstellen kann, betrifft die softwarebasierte Verschlüsselung. An der hardwarebasierten Verschlüsselung kann niemand etwas ändern.5lacker schrieb:
Brauch jetzt auch noch mal Hilfe. Windows 11 Pro 25H2. Samsung 970 Evo als Systemplatte, kein Problem, ist Hardwareverschlüsselt. Aber meine 850 Pro als Datenlaufwerk, die bekomme ich ums verrecken nicht Hardwareverschlüsselt. Im Moment ist sie PSID Reverted und Secure Erase, Status steht auf Zur Aktivierung bereit.
GPO hab ich natürlich gesetzt das NUR Hardwareverschlüsselung erlaubt ist, allerdings kommt da dann ein Fehler wenn ich Bitlocker aktivieren will das Softwareverschlüsselung nicht enabled werden konnte.
Was könnte ich noch versuchen?
Edit.
Hat sich erledigt. Es ging einfach nicht, ich hab es nun mit Win10 1903 gemacht, da ging es sofort. Das Thema finde ich echt wahnsinn bei MS, das man das nicht benutzerfreundlich hinbekommt. Bin jetzt von 1903 auf 22H2, alles läuft wieder wie vorher, ESU ist an. Ich warte dann einfach erstmal weiter ab.
GPO hab ich natürlich gesetzt das NUR Hardwareverschlüsselung erlaubt ist, allerdings kommt da dann ein Fehler wenn ich Bitlocker aktivieren will das Softwareverschlüsselung nicht enabled werden konnte.
Was könnte ich noch versuchen?
Edit.
Hat sich erledigt. Es ging einfach nicht, ich hab es nun mit Win10 1903 gemacht, da ging es sofort. Das Thema finde ich echt wahnsinn bei MS, das man das nicht benutzerfreundlich hinbekommt. Bin jetzt von 1903 auf 22H2, alles läuft wieder wie vorher, ESU ist an. Ich warte dann einfach erstmal weiter ab.
Zuletzt bearbeitet:
F
fan8324
Gast
Aktualisierung im nächsten Beitrag
Zuletzt bearbeitet von einem Moderator:
F
fan8324
Gast
So. Von einer "schweren Geburt" zu sprechen ist noch maßlos untertrieben. Habe nun drei Tage mit dem Mist verbracht. Absolut kein Verständnis dafür warum vor allem Microsoft einem das so schwer macht und verbuggt hat. Z.b. das sedutil erfordert gar keine Neuinstallation (funtkioniert aber dafür nicht mit S3 Standby).
Bisher (softwareverschlüsselt, eDrive disabled) lief als OS Win10 LTSC 2021.
Nach mehreren Versuchen habe ich festgestellt:
Neuinstallation mit Win10 1903: Hardwareverschlüsselung lässt sich aktivieren. Nach Zurückspielen von C: (Win10 LTSC 2021) KEINE Hardwareverschlüsselung möglich.
Neuinstallation mit Win10 LTSC 2021: Hardwareverschlüsselung lässt sich bereits direkt nach Neuinstallation NICHT aktivieren (passt zur Info auf der ersten Seite dass ab 2004 kaputt).
so und jetzt kommt das dubiose: Neuinstallation mit Win10 LTSC 2019: Hardwareverschlüsselung lässt sich aktivieren. Nach Zurückspielen von C: (Win10 LTSC 2021(!)) - anders als bei 1903(!) - plötzlich nun Hardwareverschlüsselung weiterhin möglich! ERFOLG!!!
Einen Bug gibt es aber den nehme ich nun wohl oder übel in Kauf und verzichte auf den Ruhezustand:
Standby (S3) kein Problem. Hochfahren, Neustart, kein Problem. Aber Ruhezustand (S4): Nach Entsperren und Versuch im Explorer irgendwelche Dateien vom Datenlaufwerk zuzugreifen: hängt sich auf. Datenträgerverwaltung: hängt sich auf. Systemsteuerung Bitlocker: Nur Systemlaufwerk sichtbar, Datenlaufwerk gar nicht. 🤮🤮
Nach Abmeldung und Anmeldung: nur noch schwarzer Bildschirm.
Nach Neustart: Alles wieder normal.
Dieser Thread ist einer der hilfreichsten überhaupt. Man findet zwar dutzende Beiträge zu dem Thema im Netz aber da stellen immer nur die Leute fragen und liefern keine Lösungen.
Ein großes Danke vor allem @tox1c90 und @Bob.Dig 👍👍
Ich war wirklich mehrfach am Kotzen als immer wieder nur die Softwareverschlüsselung angeboten wurde. Das ist alles dermaßen inkonsitent und verbuggt.Beneee schrieb:
Genau das hat bei mir (zuerst) nicht funktioniert.tox1c90 schrieb:
Bisher (softwareverschlüsselt, eDrive disabled) lief als OS Win10 LTSC 2021.
Nach mehreren Versuchen habe ich festgestellt:
Neuinstallation mit Win10 1903: Hardwareverschlüsselung lässt sich aktivieren. Nach Zurückspielen von C: (Win10 LTSC 2021) KEINE Hardwareverschlüsselung möglich.
Neuinstallation mit Win10 LTSC 2021: Hardwareverschlüsselung lässt sich bereits direkt nach Neuinstallation NICHT aktivieren (passt zur Info auf der ersten Seite dass ab 2004 kaputt).
so und jetzt kommt das dubiose: Neuinstallation mit Win10 LTSC 2019: Hardwareverschlüsselung lässt sich aktivieren. Nach Zurückspielen von C: (Win10 LTSC 2021(!)) - anders als bei 1903(!) - plötzlich nun Hardwareverschlüsselung weiterhin möglich! ERFOLG!!!
Einen Bug gibt es aber den nehme ich nun wohl oder übel in Kauf und verzichte auf den Ruhezustand:
Das kann ich genau so bestätigen. Systemlaufwerk (nun endlich) hardwareverschlüsselte NVME, Datenlaufwerk (bereits vorher hardwareverschlüsselte) SATA-SSD.tox1c90 schrieb:
Standby (S3) kein Problem. Hochfahren, Neustart, kein Problem. Aber Ruhezustand (S4): Nach Entsperren und Versuch im Explorer irgendwelche Dateien vom Datenlaufwerk zuzugreifen: hängt sich auf. Datenträgerverwaltung: hängt sich auf. Systemsteuerung Bitlocker: Nur Systemlaufwerk sichtbar, Datenlaufwerk gar nicht. 🤮🤮
Nach Abmeldung und Anmeldung: nur noch schwarzer Bildschirm.
Nach Neustart: Alles wieder normal.
Welches Windows 10 war das bei dir? Bei mir wie beschrieben LTSC 2021 mit den zwei Partitionen aus dem 2019-Install.tox1c90 schrieb:
Kannst du mir den Inhalt mal geben? Komme auch mit der Waybackmachine da nicht ran.tox1c90 schrieb:
Dazu ebenso, leider nichts dazu gefunden.tox1c90 schrieb:
Dieser Thread ist einer der hilfreichsten überhaupt. Man findet zwar dutzende Beiträge zu dem Thema im Netz aber da stellen immer nur die Leute fragen und liefern keine Lösungen.
Ein großes Danke vor allem @tox1c90 und @Bob.Dig 👍👍
Gut, dass du es letztlich dann doch irgendwie hinbekommen hast, auch wenn es eine schwere Geburt war! 
Leider komme ich an den Inhalt dieses Technet-Links auch nicht mehr, das war wohl zu alt und wurde irgendwann alles entfernt. Das Problem damals behandelte Aufwachen nicht nur aus S4/Ruhezustand, sondern auch aus S3. Letzteres klappt ja wenigstens (zum Glück).
Ansonsten gibt es zu genau unserem Problem nur noch das hier:
https://learn.microsoft.com/en-us/a...rypted-separate-data-drive-i?comment=question
Dort wurde herausgefunden, dass es genügt, die Disk mit diskpart offline und wieder online zu stellen, danach unlocked Bitlocker automatisch und fehlerfrei. Das kann ich bestätigen, das klappt bei mir dann auch. Und es bestätigt, dass es ein Softwareproblem bzw. Windows-Problem ist. Das habe ich mir auch schon gedacht, denn früher hatte ich es mal mit dem Ruhezustand fehlerfrei am Laufen, das Problem entstand erst im Laufe der Zeit.
Man kann sich als Workaround mit dem Taskscheduler und diskpart was basteln, das die Nicht-OS-Volumes dann einfach nach dem Triggerereignis "Aufwachen" einmal offline und gleich wieder online setzt. Aber sauber ist das nicht, versucht nach dem Aufwachen direkt etwas auf die Laufwerke zu schreiben, geht das ins Leere, weil das natürlich ein paar Sekunden benötigt, in der das Laufwerk nicht verfügbar ist.
Zur Sache mit dem "Einimpfen" einer bestehenden Windows-Installation / C:-Partition:
Wann ich das zum letzten Mal erfolgreich praktiziert habe und mit welcher Version, kann dir ich dir leider nicht mehr sagen, das ist auf jeden Fall schon längere Zeit her.
Wichtig ist, dass im Gerätemanager, wenn du "Ausgeblendete Geräte anzeigen" auswählst, die Kategorie "IEEE 1667-Silo- und Steuergeräte" vorhanden ist und dort pro SSD drei Devices vorhanden sind. In dem Fall wurde es korrekt erkannt, und dann sollte die Aktivierung der Hardwareverschlüsselung eigtl. auch funktionieren.
Die Neuinstallation selber ist ja auch nicht das entscheidende, sondern die Initialisierung des Laufwerks, wo dann auch die GPT-Partitionstabelle erstellt wird.
Ich habe das immer so gemacht, dass ich im Windows-Setup mit Umschalt+F10 die Kommandozeile aufmache, darin diskpart starte, einen "clean"-Befehl auf das Laufwerk loslasse (dabei wird alles komplett gelöscht inkl. Partitionstabelle), und danach dann mit dem Setup fortgefahren habe. Nur dann wird das Laufwerk ja wirklich neu initialisiert. Simples Löschen aller vorhandenen Partitionen und dann vom Setup neu anlegen genügt ja nicht.
Leider komme ich an den Inhalt dieses Technet-Links auch nicht mehr, das war wohl zu alt und wurde irgendwann alles entfernt. Das Problem damals behandelte Aufwachen nicht nur aus S4/Ruhezustand, sondern auch aus S3. Letzteres klappt ja wenigstens (zum Glück).
Ansonsten gibt es zu genau unserem Problem nur noch das hier:
https://learn.microsoft.com/en-us/a...rypted-separate-data-drive-i?comment=question
Dort wurde herausgefunden, dass es genügt, die Disk mit diskpart offline und wieder online zu stellen, danach unlocked Bitlocker automatisch und fehlerfrei. Das kann ich bestätigen, das klappt bei mir dann auch. Und es bestätigt, dass es ein Softwareproblem bzw. Windows-Problem ist. Das habe ich mir auch schon gedacht, denn früher hatte ich es mal mit dem Ruhezustand fehlerfrei am Laufen, das Problem entstand erst im Laufe der Zeit.
Man kann sich als Workaround mit dem Taskscheduler und diskpart was basteln, das die Nicht-OS-Volumes dann einfach nach dem Triggerereignis "Aufwachen" einmal offline und gleich wieder online setzt. Aber sauber ist das nicht, versucht nach dem Aufwachen direkt etwas auf die Laufwerke zu schreiben, geht das ins Leere, weil das natürlich ein paar Sekunden benötigt, in der das Laufwerk nicht verfügbar ist.
Zur Sache mit dem "Einimpfen" einer bestehenden Windows-Installation / C:-Partition:
Wann ich das zum letzten Mal erfolgreich praktiziert habe und mit welcher Version, kann dir ich dir leider nicht mehr sagen, das ist auf jeden Fall schon längere Zeit her.
Wichtig ist, dass im Gerätemanager, wenn du "Ausgeblendete Geräte anzeigen" auswählst, die Kategorie "IEEE 1667-Silo- und Steuergeräte" vorhanden ist und dort pro SSD drei Devices vorhanden sind. In dem Fall wurde es korrekt erkannt, und dann sollte die Aktivierung der Hardwareverschlüsselung eigtl. auch funktionieren.
Die Neuinstallation selber ist ja auch nicht das entscheidende, sondern die Initialisierung des Laufwerks, wo dann auch die GPT-Partitionstabelle erstellt wird.
Ich habe das immer so gemacht, dass ich im Windows-Setup mit Umschalt+F10 die Kommandozeile aufmache, darin diskpart starte, einen "clean"-Befehl auf das Laufwerk loslasse (dabei wird alles komplett gelöscht inkl. Partitionstabelle), und danach dann mit dem Setup fortgefahren habe. Nur dann wird das Laufwerk ja wirklich neu initialisiert. Simples Löschen aller vorhandenen Partitionen und dann vom Setup neu anlegen genügt ja nicht.
Zuletzt bearbeitet:
F
fan8324
Gast
Top danke! Hauptsache S3 funktioniert (tut es unter Neuinstall/Übernahme Partitionen aus LTSC 2019), S4 könnte ich notfalls verschmerzen aber wäre schon prktisch. Werde ich daher mal ausprobieren.tox1c90 schrieb:
Stimmt, also Magician geht immer nach dem Neuinitalisieren des Laufwerks auf "enabled".tox1c90 schrieb:
Aber was einfach extrem seltsam ist in Hinblick dann auf Bitlocker:
a) Mit Win10 LTSC 2021 (womöglich wie im ersten Beitrag geschrieben alles >2004) gar keine Hardwareverschlüsselung möglich.
b) auf demselben Gerät ohne jegliche Änderungen sowohl mit Win10 1903 als auch LTSC 2019 Hardwareverschlüsselung möglich
c) "Einimpfen" der "unverschlüsselten" alten LTSC 2021 in beide (1903 und LTSC 2019) möglich/bootet, aber dann nur bei übernommenen Partitionen aus LTSC 2019 HW-Verschlüsselung in Bitlocker möglich, bei Übernahme aus 1903 nicht
Das ist alles wirklich ein riesen Mist. Ich freue mich zwar umso mehr dass es jetzt läuft bis auf S4 (und bin wie gesagt mega dankbar für diesen Thread) aber da wäre wirklich einiges zu verbessern.
Mit Win11 scheint es ja "besser" zu sein, aber da möchte ich derzeit noch nicht umsteigen
Zuletzt bearbeitet von einem Moderator:
Hinweis: eine sehr gute Alternative zu HW-Bitlocker kann es sein, dass gute alte ATA-Passwort zu verwenden.
Das Bitlocker-HW-Thema hatte mich vor Jahren schon viele Stunden gekostet und ich war nicht mehr bereit diese Zeit zu investieren.
Wenn das ATA PW aktiviert ist, wird der SSD-Schlüssel-für-den-Schlüssel durch den User-Key ersetzt¹.
Das ganze hat mehrere große Vorteile:
1. Keine Abhängigkeit vom Betriebssystem
2. Keine Unsicherheit, ob wirklich alle Partitionen abgesichert
3. Alle Metadaten (Partitionen etc) sind ebenfalls verschlüsselt
4. Kein intransparentes State-Management wie bei Neuinstallation des OS auf einem OPAL/eDrive
Beschränkungen:
1. Länge HD Password ist je nach UEFI begrenzt (Lenovo afaik 10 Zeichen)
2. Nur für ganze Platte möglich (imho aber eh der einzig sinnvolle Weg)
3. Nicht jedes UEFI bietet genügend Komfort-Optionen um das Verhalten bei Neustart, Standby und Co. zu konfigurieren (Lenovo Notebooks haben diese Optionen, zumindest z.B. die P1-Serie)
4. Es gibt Berichte von Machine-specific hashing des Passworts. Afaik ist das unüblich, sollte man aber sicherheitshalber gegenprüfen.
5. Nischenthema, das heißt wenig Informationen zu den Interna online
¹ habe das ganze vor einigen Jahren mal genauer angeschaut. Ich bin nicht mehr sicher, welche Aspekte standardisiert und welche nicht sind. Afaik war es so: man muss schauen wie ein SSD Hersteller das ATA Passwort implementiert. Gängig und sinnvoll ist eben das als neuen Key-für-den-Key zu verwenden, aber ich weiß nicht was der Stand bei aktuellen SSDs ist.
Das Bitlocker-HW-Thema hatte mich vor Jahren schon viele Stunden gekostet und ich war nicht mehr bereit diese Zeit zu investieren.
Wenn das ATA PW aktiviert ist, wird der SSD-Schlüssel-für-den-Schlüssel durch den User-Key ersetzt¹.
Das ganze hat mehrere große Vorteile:
1. Keine Abhängigkeit vom Betriebssystem
2. Keine Unsicherheit, ob wirklich alle Partitionen abgesichert
3. Alle Metadaten (Partitionen etc) sind ebenfalls verschlüsselt
4. Kein intransparentes State-Management wie bei Neuinstallation des OS auf einem OPAL/eDrive
Beschränkungen:
1. Länge HD Password ist je nach UEFI begrenzt (Lenovo afaik 10 Zeichen)
2. Nur für ganze Platte möglich (imho aber eh der einzig sinnvolle Weg)
3. Nicht jedes UEFI bietet genügend Komfort-Optionen um das Verhalten bei Neustart, Standby und Co. zu konfigurieren (Lenovo Notebooks haben diese Optionen, zumindest z.B. die P1-Serie)
4. Es gibt Berichte von Machine-specific hashing des Passworts. Afaik ist das unüblich, sollte man aber sicherheitshalber gegenprüfen.
5. Nischenthema, das heißt wenig Informationen zu den Interna online
¹ habe das ganze vor einigen Jahren mal genauer angeschaut. Ich bin nicht mehr sicher, welche Aspekte standardisiert und welche nicht sind. Afaik war es so: man muss schauen wie ein SSD Hersteller das ATA Passwort implementiert. Gängig und sinnvoll ist eben das als neuen Key-für-den-Key zu verwenden, aber ich weiß nicht was der Stand bei aktuellen SSDs ist.
Zuletzt bearbeitet:
F
fan8324
Gast
Danke für den Hinweis, hatte ich mir tatsächlich die letzten Tage dann auch mehrfach überlegt gehabt.R4Z3R schrieb:
Ich sehe hierbei aber vor allem 2 große Einschränkungen (aber sage explizit dazu da kann ich auch total falsch liegen, bitte ggf korrigieren):
1.) müsste dann jedes Mal für alle 3 Laufwerke 3 Passwörter eingeben
2.) Festplatten können in einem anderen Gerät nicht mehr genutzt werden weil es irgendwie am Mainboard hängt(??)
In der Tat. Ich weiß nicht ob es da Workarounds gibt, aber dass UEFIs dafür was implementieren halte ich für sehr unwahrscheinlich.fan8324 schrieb:
Möglicherweise könnte man selber was scripten, aber es kann sein dass das UEFI schon beim Start alle Passwörter haben will (nicht sicher, hatte immer nur eine Disk drin die auch Boot-Laufwerk war).
Zu 90 % ist das nicht Machine-specific. Es gibt aber Berichte online, dass sowas existiert.fan8324 schrieb:
Daher der Rat, es mal gegenzuprüfen, wenn die Daten wirklich sehr wichtig sind.
Im Endeffekt kommt es drauf an was das UEFI aus dem Passwort macht, damit es die Anzahl Bytes ergibt, die die SSD erwartet. Was da vom ATA-Standard abgedeckt ist und was einzelne UEFIs machen, ist Graubereich.
Hinweis: folgende Möglichkeiten sind denkbar:
- Maschine-specific (z.B. Hash mit Mainboard Serial Number); unwahrscheinlich
- Manufacturer/Product-Series specific (z.B. auffüllen Passwort mit "0" oder ähnlich, before an SSD gesendet wird) - kommt durchaus vor (siehe Beitrag im Thema 'SSD ATA Passwort - Festplatte unbrauchbar' https://www.computerbase.de/forum/t...-festplatte-unbrauchbar.1879512/post-22818107)
- Unabhängig: möglicherweise gibt es einen ATA spec die aber keiner ganz genau einhält
Zuletzt bearbeitet:
F
fan8324
Gast
Das ist für mich (mit 3 Disks) eigentlich das Auschlusskriterium, weil viel unpraktischer als der fehlende Ruhezustand (und vor allem habe ich jetzt so viel Zeit investiert, dass ich da nix mehr ändereR4Z3R schrieb:
).Aber dein Hinweis bleibt trotzdem für andere hilfreich, hatte wie gesagt das ebenfalls in Erwägung gezogen.
F
fan8324
Gast
Habe das jetzt mal getestet, leider ohne Erfolg.tox1c90 schrieb:
Habe ein Batchskript gebaut
Code:
@echo off
setlocal
(
echo select disk 0
echo offline disk noerr
echo online disk noerr
echo select disk 1
echo offline disk noerr
echo online disk noerr
echo exit
) | diskpart.exe >nul 2>&1
endlocalDann eine Aufgabe angelegt mit Trigger (XML-Filter):
XML:
<QueryList>
<Query Id="0" Path="System">
<Select Path="System">
*[System[Provider[@Name='Microsoft-Windows-Kernel-Power'] and EventID=107]]
and
*[EventData[Data[@Name='WakeFromState']=5]]
</Select>
</Query>
</QueryList>So jetzt aber Problem: Sowohl die manuelle Skript-ausführung als auch automatisch hilft nichts was das Problem mit der nicht erfolgten Entschlüsselung anbelangt. Meines Erachtens schafft man es schlicht nicht das Skript rechtzeitig laufen zu lassen, weil in dem Moment bereits alles hängt.
Habe auch mal manuell versucht Eingabeaufforderung zu öffnen und die Befehle manuell einzugeben. Klappt nicht. Man kommt gar nicht dazu weil diskpart vor einer Eingabemöglichkeit (markiert an der Stelle) hängen bleibt, also nicht erfolgreich einliest.
Wundert mich aber auch nicht weil sich dann generell das komplette System aufhängt und eigentlich gar nichts mehr geht (vor allem keine Explorernavigation).
Im Log kommen massenweise solche Fehler:
Leider bleibt also nur den Ruhezustand zu deaktivieren. Workaround funktioniert (zumindest bei mir) nicht und ich habe absolut keine Idee mehr wie ich das verhindern könnte. Müsste Microsoft eben fixen...
F
fan8324
Gast
Tritt dieser Ruhezustands-Bug bei irgendwem eigentlich NICHT auf/wurde in irgendeinem Windows gefixt?
@fan8324 Der wurde irgendwann eingebaut, denn in 2019 hatte ich das mal am Laufen, allerdings noch mit ausschließlich SATA-SSDs. Da konnte ich problemlos aus dem Ruhezustand aufwachen.
Heute geht es jedoch weder mit SATA noch mit NVMe, sobald es sich um ein Nicht-OS-Volume handelt.
Da ich aber zwischenzeitlich auch das Board gewechselt hatte, war ich mir lange nicht sicher, ob es nicht doch eine Frage des BIOS/UEFI ist.
Irgendwas im Unlock-Prozess scheint jedoch einfach zum falschen Zeitpunkt zu kommen.
Beim S3-Standby bleibt das Laufwerk ja im unlocked-State (weshalb Hardwareverschlüsselung in speziell diesem Szenario ja auch als potenziell anfällig für Hot Swap Attacken gesehen wird, bei denen Leute versuchen, ein Laufwerk unter Erhalt der Stromversorgung mit einem anderen Gerät zum Auslesen zu verbinden). Hier muss Windows nach dem Aufwachen nichts extra tun, damit es weiter gehen kann.
S4-Standby macht das Laufwerk jedoch stromlos, es kann dann quasi nicht unterscheiden, ob der PC normal heruntergefahren oder in den Ruhezustand geschickt wurde. Es sperrt sich also. Der Hardwarezustand ist also nicht mehr derselbe, wenn der PC beim nächsten Start aufwacht.
Windows erwartet jedoch beim Aufwachen aus dem S4, dass es den gleichen Hardwarezustand vorfindet. Nun ist jedoch das Laufwerk auf einmal gesperrt. Hier müsste Windows dann aber den Sachverhalt als solchen erkennen, und die Entsperrkommandos erneut abschicken. Das aber scheint jedoch schief zu gehen, bzw. kommt aus dem Tritt.
Offenbar geht Windows davon aus, das Laufwerk müsste noch entsperrt sein, und zeigt es als solches im Explorer an. Es reagiert aber nicht, weil es das halt in Wahrheit nicht ist.
Im dümmsten Fall hat einfach keiner von den Windows-Entwicklern die Sache mit der Hardwareverschlüsselung mehr auf dem Schirm, weil man das ja vor einigen Jahren mehr oder weniger rauskonfiguriert hat. Und dann schlicht „vergessen“, dass man das speziell handlen muss.
Bei Software-Bitlocker ist das kein Problem, da ja hier der Hardwarezustand immer der gleiche ist, egal ob gesperrt oder entsperrt.
Heute geht es jedoch weder mit SATA noch mit NVMe, sobald es sich um ein Nicht-OS-Volume handelt.
Da ich aber zwischenzeitlich auch das Board gewechselt hatte, war ich mir lange nicht sicher, ob es nicht doch eine Frage des BIOS/UEFI ist.
Irgendwas im Unlock-Prozess scheint jedoch einfach zum falschen Zeitpunkt zu kommen.
Beim S3-Standby bleibt das Laufwerk ja im unlocked-State (weshalb Hardwareverschlüsselung in speziell diesem Szenario ja auch als potenziell anfällig für Hot Swap Attacken gesehen wird, bei denen Leute versuchen, ein Laufwerk unter Erhalt der Stromversorgung mit einem anderen Gerät zum Auslesen zu verbinden). Hier muss Windows nach dem Aufwachen nichts extra tun, damit es weiter gehen kann.
S4-Standby macht das Laufwerk jedoch stromlos, es kann dann quasi nicht unterscheiden, ob der PC normal heruntergefahren oder in den Ruhezustand geschickt wurde. Es sperrt sich also. Der Hardwarezustand ist also nicht mehr derselbe, wenn der PC beim nächsten Start aufwacht.
Windows erwartet jedoch beim Aufwachen aus dem S4, dass es den gleichen Hardwarezustand vorfindet. Nun ist jedoch das Laufwerk auf einmal gesperrt. Hier müsste Windows dann aber den Sachverhalt als solchen erkennen, und die Entsperrkommandos erneut abschicken. Das aber scheint jedoch schief zu gehen, bzw. kommt aus dem Tritt.
Offenbar geht Windows davon aus, das Laufwerk müsste noch entsperrt sein, und zeigt es als solches im Explorer an. Es reagiert aber nicht, weil es das halt in Wahrheit nicht ist.
Im dümmsten Fall hat einfach keiner von den Windows-Entwicklern die Sache mit der Hardwareverschlüsselung mehr auf dem Schirm, weil man das ja vor einigen Jahren mehr oder weniger rauskonfiguriert hat. Und dann schlicht „vergessen“, dass man das speziell handlen muss.
Bei Software-Bitlocker ist das kein Problem, da ja hier der Hardwarezustand immer der gleiche ist, egal ob gesperrt oder entsperrt.
F
fan8324
Gast
Also auch in Win11 nicht gefixt? Mist.
"Bringt" es irgendwas den Bug zu melden? Vermutlich nicht. Wüsste auch nicht wo man das so tun kann dass es auch wirklich bei den Entwicklern ankommt und nicht irgendwo in einem tollen "Starten Sie den PC neu und löschen Sie ihre Cookies"-Rateforum landet.
Und was ich noch merkwürdiger finde: Wenn das Bootlaufwerk softwareverschlüsselt ist und die zusätzlichen HW-verschlüsselt ist es kein Problem die zusätzlichen Laufwerke zu entsperren nach Aufwachen.
Wobei das dann sehr Sinn ergeben würde wenn wie es sich bei dir anhört einfach das Bootlaufwerk ebenfalls nicht entsperrt wird, weil da liegen ja die Schlüssel zur automatischen Entsperrung der anderen Laufwerke. Muss ich mal testen wie das ist wenn ich die zusätzlichen Laufwerke rausnehme.
"Bringt" es irgendwas den Bug zu melden? Vermutlich nicht. Wüsste auch nicht wo man das so tun kann dass es auch wirklich bei den Entwicklern ankommt und nicht irgendwo in einem tollen "Starten Sie den PC neu und löschen Sie ihre Cookies"-Rateforum landet.
Das ist soweit gut nachvollziehbar. Mir erschließt sich nur nicht warum das "Boot"laufwerk aber trotzdem entsperrt wird, nur die zusätzlichen Laufwerke Probleme machen (wobei ich mir da gerade nicht mal sicher bin, muss ich mal testen). Werde es übrigens auch nochmal mit deaktiviertem TPM testen wobei das nur ein Versuch ist ohne Hoffnung, würde mich sehr wundern wenn das etwas damit zu tun hat, weil es genau so ist wie du sagst dass Windows die Entsperrung schlicht "vergisst".tox1c90 schrieb:
Und was ich noch merkwürdiger finde: Wenn das Bootlaufwerk softwareverschlüsselt ist und die zusätzlichen HW-verschlüsselt ist es kein Problem die zusätzlichen Laufwerke zu entsperren nach Aufwachen.
Wobei das dann sehr Sinn ergeben würde wenn wie es sich bei dir anhört einfach das Bootlaufwerk ebenfalls nicht entsperrt wird, weil da liegen ja die Schlüssel zur automatischen Entsperrung der anderen Laufwerke. Muss ich mal testen wie das ist wenn ich die zusätzlichen Laufwerke rausnehme.
Ist das so? Das wäre mir tatsächlich neu! So rum hab ich es nämlich noch nicht ausprobiert.fan8324 schrieb:
Bislang hatte ich als Workaround mal HW-verschlüsseltes Bootlaufwerk und SW-verschlüsselte Datenlaufwerke am Laufen, das hat auch funktioniert.
Beim Bootlaufwerk ist das wohl was anderes, weil hier die Preboot-Umgebung zusammen mit dem BIOS die Entsperrung übernimmt. Ohne das käme der Bootloader ja auch gar nicht an das Hibernation-File dran um das Aufwachen zu ermöglichen.fan8324 schrieb:
Zum Booten von HW-verschlüsselten Laufwerken muss das BIOS ja auch explizit Support mitbringen, darum ging das anfangs auch nicht von NVMe-SSDs.
Ich glaube, dass in Bezug auf laufwerkseigene HW-Verschlüsselung nichts mehr kommen wird oder gefixt wird. Es geht ja nun in eine andere Richtung:
https://www.heise.de/news/Bitlocker-bekommt-Verschluesselung-per-Hardware-zurueck-11124708.html
Künftige Chipsätze/CPUs sollen dedizierte Hardwareeinheiten für die Laufwerksverschlüsselung bekommen, was über die üblichen AES-Einheiten aktueller CPUs hinaus geht. Das ist praktisch dann die Hardwareverschlüsselung für alle, unabhängig vom Controller der SSD, und wird die CPU genauso wenig belasten wie das ursprüngliche Verfahren. Die übliche Crypto-Einheit der SSDs wandert praktisch aufs Board und wird dann von Bitlocker genutzt werden.
Zuletzt bearbeitet:
F
fan8324
Gast
tox1c90 schrieb:
Äh ja stimmt. Vollkommen logisch, da hatte ich irgendwie ein Brett vorm Kopf. Klar muss ja, sonst kann es gar nicht fortsetzen.
Jetzt bin ich selbst verunsichert und überprüfen kann ich es aktuell auch nicht weil ich nur noch HW-verschlüsselte Laufwerke habe.tox1c90 schrieb:
Ich hatte aber die letzten paar Wochen als "Zwischenschritt" eben genau das (Boot SW-verschlüsselt, Daten HW-verschlüsselt). Und ich nutze den Ruhezustand schon oft. Kann mir eigentlich nicht vorstellen dass ich den die letzten Wochen nicht genutzt haben soll.
F
fan8324
Gast
Noch ergänzend zu meinen vorherigen Anmerkungen: Leider müsste ich nicht nur bei jedem Start 3x dasselbe Passwort eingeben, nein mein toller Mainboardhersteller bietet schlicht die Möglichkeit überhaupt ein ATA-Passwort zu vergeben gar nicht erst an (Gigabyte A520I AC).R4Z3R schrieb:
Zu dem Ruhezustands-Bug: Heute wurde nach einem "normalen" Hochfahren(!) aus dem komplett ausgeschalteten Zustand nur eines(!) von beiden Datenlaufwerken entsperrt und das andere hing genauso wie beim Fortsetzen aus dem Ruhezustand. Diskpart offline/online unmöglich, weil es einfach tatenlos hing. Das macht mir ziemlich Sorgen. M.E. scheint hier also etwas größeres verbuggt zu sein.
Ich frage daher nochmal:
Ich weiß dass wir hier mit HW-Verschlüsselung und Bitlocker eine sehr kleine Nische sind. Gibt es trotzdem vielleicht noch irgendjemanden der ebenfalls mehrere HW-verschlüsselte Laufwerke mit Bitlocker nutzt? Wäre sehr dankbar.fan8324 schrieb:
Ist der Schnellstart aktiviert? Der ist ähnlich problematisch wie der Ruhezustand. Das einzige, was bei mir reibungslos mit HW-Bitlocker funktioniert, ist komplettes Runterfahren ohne Schnellstart.fan8324 schrieb:
Denn bei aktiviertem Schnellstart besteht Runterfahren+Hochfahren ja auch zum Teil aus dem Ruhezustand, eben nur die grundlegenderen Bestandteile betreffend, aber einschließlich Storage.
